More IPv6 basics
More basics of IPv6 explained - how does IPv6 Multicast work, More about IPv6 ICMP (ICMPv6), Router Solicitation and Router Advertisements. We’ll have a look at SLAAC and DHCPv6. Follow up on my first “IPv6 from Scratch” episode.
Watch the video on YouTube
Click to view the entire transcript
Where have we stopped after the first IPv6 episode? Let’s check the cheat sheet in Marc’s github repository quickly. We had defined IPv6 addresses, subnets and scopes. We are now able to have IPv6 communication between two nodes. Let’s call that Unicast, because it goes from one single node to another single node. A node can be a laptop, a phone or a PC – anything with network connection really. Just now – our nodes obviously want to talk to the internet. For this, they need a router. But how could they find or let’s say solicit a router?
(Multicast use cases – DAD and Router solicitation)
Let’s do it this way: We will allow a single IPv6 node to shout or rather multicast into the network. We could use this for two things. First of course the IPv6 node may shout “Hey, is there a router in the house? I want to go global”. All solicited routers may then answer and advertise themselves. They could come back with more info, such as the prefix to use, where to find a DNS server and so on.
The second use case for IPv6 multicast into the network could be the following: let’s say I have picked or rather defined an IPv6 address for myself with SLAAC. Now I just want to check if that is OK with everyone in the IPv6 network. I would therefore do a duplicate address detection (DAD) by multicasting my desired address into the network. Rather than having everyone talk back I would just assume that silence means acceptance. So if no one replies back to my DAD then I can safely assume that no one else has claimed that address.
What would we need for all this?
(Multicast addresses)
All we would need is another address range that allows us to shout into the network. A multicast address. Which address range do we still have available? We have already used fc and fd for Unique Link, we have used fe for link local – let’s use ff then. Let’s say if ever we send out a packet to the IPv6 address ff02::1 then all IPv6 nodes in the link local scope shall be reached. We can actually ping this address. If I ping the address ff02::1 then every node on this link replies to my ping. Unless a switch or router in between would filter it. So one ping out, ten replies in. Quite funny.
Cool. But not every node is a router. For the first use case we only need the routers. Let’s say we define another address ff02::2 which does essentially the same thing but only for the routers. So if I ping ff02::2 then only routers should reply.
Now – which protocol would we use in order to send out a duplicate address detection or a router solicitation? Yes – good choice! Let’s use our swiss IPv6 army knife, the IPv6 ICMP protocol. But first and before we forget it – let’s write down the IPv6 multicast addresses into the IPv6 cheat sheet. All nodes – ff02::1. All routers ff02::2 – let’s actually define some more – all DHCP servers ff02::1:2, all NTP servers, and maybe some others. Here we go.
(IPv6 ICMP types)
OK – we want to use IPv6 ICMP for this. What’s so special about our ICMP protocol? If we use TCP or UDP or QUIC for network communication, then we need to connect to a specific port on the target machine. Like e-mail would listen on TCP port 25, mDNS would listen on UDP port 5353, http3 with QUIC on port 443 and so on. With ICMP we are not using ports. But then - how would the other node know what we expect it to do? If we do an echo request or ping (which is ICMP as well), how does the other node know that it is supposed to reply to my echo request? And how would we know that the packet coming from the other node is such a reply to an echo request? You know what? Let’s define types of IPv6 ICMP packets.
We will need a couple of IPv6 ICMP types here to control very basic stuff in our network. Let’s say I am trying to browse to Google. For some reason the IPv6 router can’t reach Google. It should be able to tell me that. Let’s arbitrarily say that it should use an IPv6 ICMP packet of type 1 to do so. IPv6 ICMP type 1 shall therefore be named “Destination unreachable”. We can even take it further and define sub types. Like 0 could be – we have no IPv6 route to that server. Or sub type 2 could mean that we are in the wrong scope. Let’s again register all these types and numbers to the IANA, the Internet Assigned Numbers Authority. Here we go. Type 1. Subtypes. Each sub type shall also be explained in detail in a larger document, a so called Request for comment, an RFC.
What number should we assign to our ping or IPv6 echo request? Should we use two or three or four? Well, an echo request is not THAT important, right? So let’s say that the really important stuff shall get the numbers 1,2,3 and so on. And the not so important stuff shall get the higher numbers. Let’s start with 128. Echo request. Then 129. Echo reply. In a nutshell, whenever an IPv6 node receives an ICMP packet of type 128 it shall immediately reply back to the IPv6 source of that packet with another ICMP packet of type 129.
We can actually visualize these packets. Let’s use a software called Wireshark to do so. Wireshark captures and visualizes those packets. Just – there are so many packets going over the network. We need to look really fast up here in the list of captured packets, right? No – not really. We just need to use the right filter. Wireshark is not a good tool if you don’t know what you are looking for. But it is awesome if you know it. We are looking for icmpv6 of type 128 or 129. Let’s type this into the filter line here. When I now do the ping I can see only those packets. Here we go. Echo request and echo reply. At the very bottom of the Wireshark window I can see the raw packet content. In the middle I can see the details or rather how we interpret the packet. The packet contains the source address, the destination address, the IPv6 ICMP type, in this case 128 or 129 plus 56 bytes of arbitrary data that we had sent.
(Router Solicitation)
Let’s just define another IPv6 ICMP type which we call Router solicitation. Let’s use the number 133 for that. The router should reply to that solicitation and advertise itself. Let’s use the IPv6 ICMP number 134 for this. Router Advertisement. The router can then use this in order to tell me more about the network, such as the IPv6 prefix, its own IPv6 address, maybe the MAC address and additional information – such as – should I really use SLAAC ? Or could the IPv6 router even give me an IPv6 address which I could use? Also, where could I find a DNS server? Let’s modify our filter here in wireshark and listen to icmpv6 packets of type 133 or 134. Then I will just down the link of the network interface and bring it up again. Here you go. Router solicitation to multicast ff02::2, then my router comes back with a router advertisement packet of type 134 – and if we look at the details then we can see things such as the MAC address of the IPv6 router, the IPv6 prefixes it uses, the IPv6 DNS address and much more.
Cool. Let’s not forget to write down our findings in the IPv6 cheat sheet. ICMP types and subtypes. Router solicitation, router advertisement. Here we go.
(DHCPv6)
Awesome. If you come – like probably most of us – from the IPv4 world, then this whole SLAAC and self-defining IPv6 addresses thing might sound like – well – voodoo or black magic to you. Fair enough. We might want to have more control over the IPv6 addresses that our nodes get. We might want to configure them in a central place. Like in the IPv4 world. Why and when would we want to do that?
Well, if your client is a workstation or a phone or tablet, then you don’t really care which IPv6 address it gets. You can use SLAAC. But what if it is a server or a device which you want to have a firewall rule for? Such as a piHole or adguard Home server that filters DNS? You would need to create a firewall rule that allows or forbids or redirects packets to that device. But how could you do that if the IPv6 address changes all the time? Of course, you could use the MAC address as an identifier. Or you could give it a static IPv6 address. But how could you give it a static address if you don’t own the prefix? If the ISP assigns you a new prefix every 24 hours or the like? This is what Deutsche Telekom are doing for me. My IPv6 prefix in the 2003:de:something range changes every 24 hours. That’s great with regards to privacy. Also that’s the reason why I am so freely showing all my IPv6 addresses to you. They just change every day.
This is where DHCPv6 comes into play. The Dynamic Host Configuration Protocol. Rather than us assigning ourselves addresses with SLAAC, a DHCPv6 server could do that in a centralized way. I could have a static definition for servers and just use dynamic addresses for clients. Or even put them on different networks and use SLAAC for the clients – for better privacy.
How can we make that work? Let’s arbitrarily define the following things. A DHCPv6 server shall answer requests that come from UDP port 546 to UPD port 547. The multicast address for all DHCPv6 servers in my network scope shall be ff02::1:2. So if we send out a packet from UDP port 546 to UDP port 547 to all DHCPv6 servers, then they reply back from port 547 to port 546 with IPv6 addresses and options that I can use. Pretty similar to the old IPv4 world. Just there it was port numbers 67 and 68. Here is what that looks like in Wireshark. DHCPv6 solicitation and DHCPv6 reply.
In this case we wouldn’t really need router solicitation and router advertisement. Right? Correct. But watch this. In the terminal window you can see which IPv6 address I get on my workstation. In the Wireshark Window you can see the router solicitation, advertisement and dhcpv6 packets. My network interface is disabled. Let me activate it. And – surprise – I get two IPv6 addresses. Why? That’s because my router allows both mechanisms. SLAAC and DHCPv6. And because my client is set to automatic, it can and it will hence use both mechanisms. SLAAC and DHCPv6. Now this is really messy, isn’t it? But fear not, this can be configured on the client side and on the router side. Here is how. On the client side I can set my IPv6 interface to automatic or to automatic, DHCP only. If I set it to automatic, then it will do both – router solicitation and DHCPv6 solicitation. If I set it to “Automatic, DHCP only” then it will not do router solicitation but only DHCPv6 solicitation.
Now – tweaking those things on the client does not look like a good option to me. I would rather want to define this in a central place – on the router itself and I would expect clients to behave in a way that the router defines for them. So let’s say – if the clients do Router solicitation then we should be able to tell the clients if they are allowed to use SLAAC or not and if they should use DHCPv6 or not. We can use a couple of fields here on the router advertisement packet. The Managed address configuration field says DHCP yes or no and further down in the prefix information we can tell our client if they should use SLAAC or not. On my OpenWrt router I can set these options under the DHCP server options of the interface. Enable or disable SLAAC and/or managed config.
I have compiled a little table here that summarizes our choices. Depending on the options that we set on the router or on the client we are able to change the IPv6 address attribution mechanisms. You will – of course – find this table in the IPv6 cheat sheet.
Initially I wanted to talk about dual stack in this episode. That means how the old IPv4 world coexists with the new IPv6 world. Many of you left me comments here on YouTube with regards to that. But when I wrote the script for this episode I realized that the episode would get too long. Therefore there will be another episode. I’m sorry for this. I had not planned for a longer series in the beginning but just realized that dual stack is definitely worth an episode on its own because most of us have existing IPv4 infrastructure and want or even need to have both worlds coexist.
Oh – just one thing before we close. We had talked about Unicast which is the communication from one node to a second single node. How is Multicast different from broadcast which we know from the IPv4 world? Well, in order to receive Multicasts you need to first subscribe to a group that can receive them. So in the real world broadcast is a bit like someone shouting in the street. Whoever walks by, hears it. Like it or not. Multicast is more like radio. Whoever has the radio on and tuned in to the right frequency receives it. If you are on a different frequency then you can’t hear it. So you can chose which messages you want to receive. But it’s still one sender and many receivers. Now in IPv6 there is another type - Anycast. Anycast is more like calling the emergency phone number. 911 or 999 or here in Germany it’s 112. If I live in smaller city then at daytime that number will be routed to the local police department. At night time, I can call the same number but it will automatically be routed to the next bigger city like Cologne, Munich, Berlin or Hamburg. So Anycast is the same address for any target with that same address. In any case, the sender only needs to send out one packet and the distribution is done by the switch or the router.
That’s it guys - watch out for that next dual stack and / or OpenWrt episode. Many thanks for watching, liking, subscribing, commenting and – like always – stay safe, stay healthy, bye for now!
