My Journey to IPv6: Part 1 – IPv6 Basics

Background

I’ve been an IT infrastructure engineer for more than 20 years. Cut my teeth in the early days of campus L3 switching. I was lucky enough to have one of my first jobs at a public educational institution that owned a PI Class-B. Those were heady days. Like so many others out there, I looked at IPv6 as something I could hopefully avoid until retirement. The inability to reel off an entire IP subnetting scheme for a company from memory was too dear to my heart. But the times they are a changin…. About a week ago while debugging an issue on my home network I discovered that Verizon had enabled IPv6 on my FiOS circuit. I don’t use their router, only the ONT. Instead I use a Fortigate 40F running FortiOS 7.2.2 as my router and firewall. I host several websites and a media server on my home network. My goal was to move as much traffic as possible to native IPv6 without disrupting the services that were already functional under v4.

Part one of this series covers some of the background on how IPv6 hands out addresses and configuration. Subsequent parts will cover how to configure a Fortigate firewall with IPv6 on Verizon FiOS and some challenges that I overcame with serving up workloads on IPv6.

Stop. Do not pass go. Do not think like its v4.

Many articles that I read along the way started with a statement along the lines of “forget everything you knew about IPv4” or “Get rid of your IPv4 mindset.” In some ways, this is valid advice. Forget NAT, ARP and CIDR its now GUAs, NDP and /64s. In other ways these statements are an example of both why IPv4 sticks around and why IPv6 adoption has been slow (both of those things are independently true) – IPv6 proponents assume some pretty rigid design standards and criteria whereas IPv4 is an amalgamation of features and standards that “make it work.” A lot of “make it work” kludgyness is exactly what IPv6 was intended to fix and it has, but we don’t all work in enterprises or carrier networks with beautifully hierarchical networks and clear boundaries. There are religious debates about IPv6 methodology that would make the crusades look like a casual chat; I’m not going to wade into those debates in this article. Suffice to say – I adopted the network “design” for my IPv6 implementation that was best supported by my equipment, software and “business needs.” It may not be perfect, but it works cleanly enough for me.

If you want the whole truth and nothing but the truth, try Cisco Press. I dramatically oversimplify several topics, jump around without foundation and make assumptions for demonstration purposes. There are many many MANY sites out there that will tell you how to read and shorten an IPv6 address, the history of IPv6 etc etc. I had read a good number of them myself and could speak the vocabulary of IPv6 but it wasn’t untilI dove in, rolled up my sleeves and gave it a shot that I learned what I really needed to know. This series is intended to be some real world advice and guidance from someone who crash coursed their own home network and servers into being IPv6 native.

IPv6 IP Address Assignment

The typical procedure for a home Internet setup would be to enable DHCP, plug in, get your “WAN” IP and move along. DHCPv6 is a thing so similar procedure to get your IPv6 address? Not exactly. There are three main reasons the procedure is different:

• Your firewall doesn’t need, and may not get, a WAN IP
• There is no NAT in IPv6 (there is but it’s like Fight Club)
• DHCPv6 (usually) doesn’t hand out addresses

Wait. Wut?

YOU get a routable IP and YOU get a routable IP….

A primary tenant of IPv4 networking is that your WAN IP is the “gateway” to the Internet. You can’t send traffic to a 192.168/16, 172.16/12 or 10/8 IP across the Internet, only to a routable IP. While there is an IPv6 equivalent to those private address spaces (but using it is one of those religious battles I mentioned above), the RIGHT way to do it is to put a routable IP on every device. That’s right. Every device gets a real, routable IP. Notice that I keep saying routable and not public. That’s because – routability is not a security feature. NAT was invented because we were running out of IP’s not because the world wanted to hide stuff. The hiding stuff was a “bonus” that network and security engineers alike have taken advantage of over the years. Being hidden does not make you safe in fact it can make it worse because you are assuming your lack of visibility is making you safer.

Just because an address is routable doesn’t mean its public. Remember I said I worked at a place with a public class B network? We didn’t NAT. Anything. All of the computers on campus had a real IP address – but that doesn’t mean you could get to them. You still had to traverse the firewall at the edge (well, once we HAD a firewall, that’s for a different post). The same is true for IPv6, everything gets a real IP address that is routable over the Internet; the firewall decides what is allowed to go to and from it. There is no “front door” address that everyone goes through.

Link local addresses for fun and profit

OK fine, so everyone has a public IP then why doesn’t my router have one? It doesn’t need one – bear with me. Have you ever seen a 169 IP on your computer? If so, you have seen what is known as a link local address. In IPv6 these start with fe80::. In IPv4 if you see one of these it pretty much means something is broken. If you DON’T see these in IPv6 then it definitely means something is broken. Link local means just that – it is an address that is local to a given link which in most cases means the ethernet or wireless SSID you are connected to. You can’t send traffic to a 169 IP that is on a network you aren’t directly connected to. If you have a 169 IP as your only IP, your traffic will never leave your local network and you’ll never get to the Internet. So why isn’t it a breakage when you have an fe80:: address and why can my router be on the Internet with only an fe80:: address?

When you send a packet, v4 or v6, the header contains the address of the source and the address of the destination. It does NOT tell you how to get from A to B, that’s what the router is for. The router receives the packet, looks at the destination says “what the next step to get there” and sends it to the next hop. That process continues until it reaches the router with the destination directly attached. The point is – the next step only matters to that router so only that router has to be able to talk to the next step.

Consider the diagram above. The two routers in the middle are ISP transit routers and the client and server are connected to the Internet. The client and server have routable IPs, the routers do not.

Client generates a packet with a destination of 2001:0DBF::1 and its default gateway is fe80::1233 which is on RTR A. Packet reaches RTR A which says “whats the fastest way to get to 2001:0DBF::1?” “Why I’ll fling the packet at fe80::1234 and hope for the best.” BUT BUT BUT! What about the duplicate IP??

No one would ever set their network up this way but I did it to make a point. Link local addresses only have to be unique on a given link. So then how does the system know which of the duplicate addresses to source the traffic from? Another IPv6 wrinkle – when you set a static route to a link local address you have to specify the link (interface) that it should use unlike IPv4 which will derive the interface from the next hop.

So while your “WAN” interface is the one connected to the internet, its really just inside of someone else’s network. The traffic from the client to the server doesn’t need to hit the WAN IP anymore because the server has a routable IP. And so since user/Internet traffic doesn’t have end to end conversations with WAN interfaces and routers (they are just a hop along the way) there is no need to put a routable IP on the WAN interface of the firewall, only on the devices that will actually need end to end Internet communication.

FWIW – This technically isn’t a feature of IPv6, routing is similar enough in IPv4 that you could use private addresses this way but it isn’t nearly as common.

What’s my block?

We know the firewall’s WAN interface wont get an IP but its still the device connected to the ISP so it must be involved in getting a routable IP onto the clients on the network. But what addresses should it hand out? In the IPv4 days we would select a subnet from the RFC 1918 space and we could choose whatever we wanted because the addresses only have to be unique within our own network. Since IPv6 addresses must be globally unique we can’t just select them ourselves the ISP must assign them and then tell us what addresses we’re allowed to use. Verizon FiOS (and many other ISP’s) uses DHCPv6 Prefix Delegation (PD) to inform a router what addresses it should hand out. I mentioned above that in IPv6 DHCP isn’t used to hand out addresses. It can be but that’s not the typical design. Instead, DHCPv6 usually gives you everything OTHER than your IP address and one of those things is what prefix has been delegated to you by your ISP to assign to the clients in your network.

What’s my address?

If DHCPv6 doesn’t tell you what your IP is, what does? In the IPv6 world you build it yourself with some help from your local router. When an IPv6 capable router is connected to a link it sends advertisements and listens for solicitations about the network it routes for. It uses ICMPv6 to send these messages. We usually think of ICMP as ping in the IPv4 world. In IPv6 it takes on a much larger role. When you connect a client to an IPv6 network it listens for the advertisements from the local router. That advertisement says “Here is subnet of the network you are on” and then the client generates its own address in that subnet. This conversation all takes places over fe80:: link local addresses that are generated by running a hash against the MAC address of the interface.

The space between

In IPv6 while addresses are 128 bits and use the same / notation for subnetting as IPv4, there is a rule everyone follows: 64 Bits for the network and 64 bits for this host. The first half of the address is the subnet and the second half is the client itself, a /64 subnet. All subnets are /64s. So taking this example:

2001:0DB8:95fa:e900:0000:0000:0000:ffff/64

• Network – 2001:0DB8:95fa:e900
• Host – 0000:0000:0000:ffff

You may have realized by now that this means there can be a lot of hosts in a subnet. 18,446,744,073,709,551,616 to be exact. Play the tape to the end – yes, on a home network with 2 laptops, an iPhone and an Apple TV there will be over 18 quintillion free IP’s in that subnet. That may seem wasteful but its one of the things it’s best just to get zen about if you’re going to work with IPv6.

Putting it together

As a client I have a subnet I know I’m in from a router advertisement and I know I have 64 bits to fill with a (hopefully) unique value to make a full IPv6 address. I mentioned earlier that the fe80:: link local address is generated by hashing the MAC address. A similar hash of the MAC address is tacked on to the end of the subnet in the router advertisement to create the IP that the client assigned to itself. This process, the advertisements, MAC hashing and IP self assignment is called Stateless Address Auto-Configuration or SLAAC. There is a lot more to SLAAC under the hood including checking multiple times for conflict. If you would like that level of detail, check out this excellent article from Network Academy.io

Since the second half of an IPv6 address is based on a known method of hashing a MAC address it is possible to envision how easy it would be to track a given MAC address (and its owner) as it moved from network to network. That would be a serious security and privacy concern. To combat this, modern implementations of SLAAC generate (at least) two addresses. One address is based on the MAC hash, is assigned “permanently” to the interface and is used for general IP communication. An additional private (sometimes called temporary) IPv6 address is generated using a random algorithm. This address is used as the source when browsing the web or performing other activities that the OS determines shouldn’t be tracked with your device. The OS will roll over this address to a new random value on a regular basis.

Whats in a name?

The client now has a routable IP and a link local next hop to get to the Internet. What’s missing? It’s always DNS. The original SLAAC protocol didn’t include a method for distributing DNS servers along with IP information and without DNS the Internet is pretty boring. Re-enter DHCPv6. It is very common to run DHCPv6 along side SLAAC just for distributing DNS servers. There are updates to the SLAAC protocol to allow it to distribute DNS servers but this is the a common configuration. I personally configured both.

Until Next Time

That’s all for part 1… next time I’ll take a look at how to implement the process from this article on a Fortigate firewall with Verizon FiOS.