The article is a more in-depth look at residential IPv6, the final installment of the 2 part series. If you’ve missed it, the 1st article can be found here.
After having established a successful connection to an IPv6 broker server, I fired up wireshark to see what is going on over the wire. We immediately observe IPv6, and in outgoing packets, we can also see the IPv6 in IPv4 encapsulation I mentioned previously:
You can see the inner IPv6 header, encapsulated within a UDP IPv4 datagram on the outside. This transition method is the whole reason why isolated IPv6 “islands” can talk to each other over an as-of-yet predominantly IPv4 internet. As I noted in part 1, observers will note that I did not need any sort of DHCP server to get IPv6 addresses on other nodes in my home network. While DHCPv6 still does play a very important role, another, more automatic method has been introduced in IPv6. This is the router solicitation and router advertisement method. We can see two such packets here:
The first packet, a router solicitation, is sent from a nodes link local address to the “all routers” address (ff02::2). A router will answer with the second packet, a router advertisement, always using the link local address, which looks something like this:
Among the myriad of options, the most important to note is the “prefix information”, which the client uses to build it’s unique global address, using a combination of this prefix and it’s MAC address, without the need of any DHCP server. Similarly, IPv6 has done away with broadcasts, which also includes IPv4’s cornerstone ARP. Instead of ARP, IPv6 uses a similar mechanism to the one presented above, called neighbor solicitation and neighbor advertisement. It serves exactly the same function as ARP… translating a L3 IP address to a L2 MAC address, yet instead of using broadcasts which every node on the link must process, it uses a special form of multicast which only a few nodes will process. For example, we see two such packets here:
In the above screenshot you see the first packet as a “neighbor solicitation” for fe80::5e26:aff:fe15::772f“. Note I drew a relationship between the IP being asked for and the multicast address which the solicitation is being sent on. The multicast’s address last few octets match the MAC address, in fact this multicast address is built from the MAC address. While this is not a one-to-one relation (more than one node may process this multicast), it does significantly reduce the number of nodes that do actually process this packet. The second packet is the “neighbor advertisement” which you can see returns the MAC address.
While sniffing, we also see a bunch of ICMP “packet too big” packets:
These are because of another difference between IPv6 and IPv4: fragmentation. In IPv4, as many admin know, fragmentation can occur at any point along the packet’s path. In fact, in some cases modifying a gateway router/firewalls MTU can solve a number of issues. However, in IPv6, fragmentation can only be done by the end nodes – the PCs themselves. In order for PCs to be able to determine the path MTU, they rely on ICMP “packet too big” messages to figure out what size of packets are acceptable. This points to a valid lesson when building out IPv6 networks… do not block all ICMP traffic like we used to be able to do in IPv4! As you can see above, ICMP in IPv6 is an integral part of the protocol and it would not work without ICMP.
And finally…. a small screenshot of normal HTTP traffic over IPv6:
That is the end of this short IPv6 tutorial / primer, many thanks for reading!
David Vassallo's Blog 