I did a short presentation at the spring 2020 roundtable of the UK IPv6 Council. The talk was about a case study I did with my NTP server listed in the NTP Pool project: For 66 days I captured all NTP requests for IPv6 and legacy IP while analyzing the returning ICMPv6/ICMPv4 error messages. (A much longer period than my initial capture for 24 hours.) Following are my presentation slides along with the results.
I gave a session about IPv6 at SharkFest’19 EUROPE, the annual Wireshark developer and user community conference, named “IPv6 Crash Course: Understanding IPv6 as seen on the wire“. The talk is about the IPv6 basics, which are: IPv6 addresses & address assignment, link-layer address resolution, and ICMPv6. Tips for using Wireshark coloring rules and display filters round things up.
As I have not yet published the slides, here they are. Unfortunately, we were not able to record the session due to technical problems. Neither the video nor the audio. ;( Hence, here are only mere slides.
In the previous post, I released my Ultimate PCAP which includes every single pcap I had so far on my blog. But that’s not all: I have some packets in there that were not yet published up to now. That is, here are some more details about those (probably well-known) protocols. These are:
For the last couple of years, I captured many different network and upper-layer protocols and published the pcaps along with some information and Wireshark screenshot on this blog. However, it sometimes takes me some time to find the correct pcap when I am searching for a concrete protocol example. There are way too many pcaps out there.
This is supposed to change now:
I am using the WHOIS client a lot these days since I am migrating some RIPE objects such as ASes, inetnum/inet6num, etc. Meanwhile, I recognized that I have never captured this TCP port 43 protocol, nor looked at it with Wireshark. That’s what this post is all about, incl. a downloadable pcap for your own analysis.
VoIP calls, using the network protocols SIP/SDP and RTP, are the de-facto standard when it comes to voice calls. Wireshark offers some special features to analyze those calls and RTP streams – even with a nice “Play Streams” option, which discretely decodes your calls. Ouch. Again and again, frightening which privacy-related protocols are completely unencrypted on the Internet!
Here are some hints for Wireshark as well as a downloadable pcap with three calls in there. ;) Have fun!
Some time ago I published a post called DNS Test Names & Resource Records which lists many different FQDNs with lots of different RRs. You can use those public available DNS names to test your DNS servers or the like. However, I was missing a packet capture showing all these resource records as they appear on the wire. So now, here it is. If you are searching for some packets to test your tools for whatever reason, feel free to download this pcap.
If you’re into DNSSEC, you’ll probably have to troubleshoot or at least to verify it. While there are some good online tools such as DNSViz, there is also a command-line tool to test DNSSEC signatures onsite: delv.
As you might have noticed, I am playing a lot with NTP these days. Having a networking background I also like Power over Ethernet. So what’s more obvious than using a PoE-powered NTP display for test purposes? ;D
Probably the biggest prejudice when it comes to IPv6 is: “I don’t like those long addresses – they are hard to remember.” While this seems to be obvious due to the length and hexadecimal presentation of v6 addresses, it is NOT true. In the end, you’ll love IPv6 addresses in your own networks. This is why – summed up in one poster:
I am currently working on a network & security training, module “OSI Layer 4 – Transport”. Therefore I made a very basic demo of a TCP and UDP connection in order to see the common “SYN, SYN-ACK, ACK” for TCP while none of them for UDP, “Follow TCP/UDP Stream” in Wireshark, and so on. I wanted to show that it’s not that complicated at all. Every common application/service simply uses these data streams to transfer data aka bytes between a client and a server.
That is: Here are the Linux commands for basic lab, a downloadable pcap, and, as always, some Wireshark screenshots:
During my analysis of NTP and its traffic to my NTP servers listed in the NTP Pool Project I discovered many ICMP error messages coming back to my servers such as port unreachables, address unreachables, time exceeded or administratively prohibited. Strange. In summary, more than 3 % of IPv6-enabled NTP clients failed in getting answers from my servers. Let’s have a closer look:
I am participating in the NTP Pool Project with at least one NTP server at a time. Of course, I am monitoring the count of NTP clients that are accessing my servers with some RRDtool graphs. ;) I was totally surprised that I got quite high peaks for a couple of minutes whenever one of the servers was in the DNS while the overall rate did grow really slowly. I am still not quite sure why this is the case.
For one month I also logged all source IP addresses to gain some more details about its usage. Let’s have a look at some stats:
You have a running NTP server with a static IP address? What about joining the NTP Pool project by adding your server to the pool? You will give something back to the Internet community and feel good about it. ;)
It doesn’t matter if you’re running a Raspberry Pi with GPS/DCF77 on your home, or a fully-featured NTP appliance such as the ones from Meinberg on your enterprise DMZ. Just a few clicks and your server will be used by the NTP Pool’s round-robin DNS. Here’s a simple tutorial: