The whole reason we do all this work is to connect hosts together to facilitate actual human communication. At a fundamental level, networks are simply allowing a bunch of hosts with applications to connect to each other. We take for granted the ease with which we share information today, often assuming that a connection to the Internet is an essential function for our daily lives.
These hosts can be servers, clients, mobile devices, sensors, appliances, cars, airplanes, buildings, etc. you get the idea. Because IPv4 was the de facto standard networking protocol at the critical time of growth of the Internet, we must make some specific assumptions around how IPv4 is leveraged and the methods used with IPv4 for defining host behavior. In short, I would argue the following:
- Most hosts obtain their IPv4 addresses via DHCP
- DHCP provides the method of obtaining a name resolution server
- DHCP provides the default gateway on a given network
- RFC 1918 defines the most common address range used for IPv4 hosts
- Internet Edge network gear, Firewalls, VPN, proxies and load balancers are configured with publicly routable IPv4 address space
- Manual assignments for hosts must include an IPv4 address, default gateway and name server information
- The vast majority of hosts do NOT have multiple IPv4 addresses on a single interface
- Some hosts have multiple interfaces – each with an IPv4 address – but only one interface is actively being used
While the list isn’t perfect I think it summarizes pretty well the current view of how hosts are configured using IPv4 and strongly implies their resulting interaction (as well as how we might expect them to behave on an IPv4 network).
Do the models and methods we have used for our IPv4 design and thinking where hosts are concerned remain consistent when introducing IPv6 into the equation? The answer is complex. As with any next generation technology, there were perceived improvements, technical modifications and operational changes made that provide us a new configuration and architecture landscape. Is that landscape any better than what IPv4 provided? I think it depends on your vantage point. So let’s dig into the changes and tackle them one by one from the list above.
Most hosts obtain their IPv4 addresses via DHCP. One of the interesting developments with IPv6 was the idea that self-provisioning of an address should be possible by a host in the absence of any DHCP service. This lead to the formation of Stateless Address Auto Configuration or SLAAC. Part of the goal was for de-centralized networks, ad hoc networks and isolated networks to be able to function still with limited intervention of technical staff. This function is absent in IPv4.
While IPv4 has Automatic Private IP Addressing or APIPA, it has minimum value. It is possible with APIPA to get an ad hoc or isolated networking functioning. However, it is not possible to make a network globally accessible in any easy way. This greatly limits the deployment and use cases. In contrast, with SLAAC you can assign global unicast address prefixes, provide default gateway information, and include DNS name server information – all in messages from a router via a Router Advertisement (RA). It provides a scalable, self-assigning network address method for IPv6 that makes operating networks of sensors and systems with minimal host intelligence much easier.
In IPv4 DHCP typically provides the method of obtaining a name resolution server. The functional role of DHCPv6 in IPv6 is similar to that of DHCP in IPv4. Hosts continue to obtain name server information from a DHCPv6 server – however, there is an additional method.
As mentioned earlier, SLAAC allows for hosts to automatically provision their own address (i.e., when the A-bit of the Prefix Information Option is set to 1). There are two methods for SLAAC: stateful and stateless. Stateful uses a flag in the RA message to tell the host to obtain its DNS server information from a DHCPv6 server. In the stateless case, it assumes the host already has some sort of DNS server information, either from the IPv4 side or optionally from the use of RFC 6106. (RFC 6106 provides DNS server information in the RA message.)
Unfortunately, there is a small rift in the IPv6 community around DHCPv6 and SLAAC support in regards to which method should be providing information. In summary, the current situation is that Android does not have a native DHCPv6 client and relies on SLAAC and RFC 6106. Linux supports both DHCPv6 and SLAAC (with RFC 6106 option) as does OSX and iOS. Windows has a full DHCPv6 client and supports SLAAC but without RFC 6106. In short, if you want to run a network that has both Android devices and Windows devices you need to run both DHCPv6 and SLAAC with RFC 6106.
DHCP provides the default gateway on a given network. Because of the introduction of the RA and Router Solicitation (RS) messages (which are part of the Neighbor Discovery process in IPv6) default gateway information is not provided in the DHCPv6 process. Default gateway information is instead carried in RA messages.
In theory, this is operationally simpler for a network team as they always own the single source of truth on where the default gateway is configured for any given network segment. One of the operational challenges of IPv4 has been that changes in a network might not be updated on the DHCP server because different teams were maintaining the two systems. In IPv6, the network team completely owns that responsibility. (It also means that they own securing and protecting the RA process. See Scott Hogg’s post on IPv6 first hop security for more details.)
The downside to this change is that it does not match the operational model that has been working for IPv4. This is a rather significant but subtle change and you need to be aware of this shift of responsibility and how it will be managed in your organization.
RFC 1918 provides the most common address range for IPv4 hosts. One of the biggest benefits of IPv6 is the virtually unlimited address space it provides. With such a large space, there is nothing to be gained by using address preservation methods like NAT so IPv6 naturally uses global unicast address space for almost all use cases. There is other reserved address space available but unless you are running very special networks (nuclear power, military, counter intelligence, or other super-secure networks) you will very likely make use of global unicast addresses. This means that you need to think about your address planning and security posture very differently than in IPv4. First, your address plan doesn’t need to be constrained in the same was that it was with IPv4. This is a deep topic and it is best to point you to a book to understand all the details so go pick up to understand the work involved. Second, your security profile looks different. You should no longer rely exclusively on the concept of “inside” and “outside” network operational boundaries. This paradigm in security was proven ineffective years ago but still persists. In-depth defense with application, host, network, and edge security is likely far more effective and is independent of an addressing plan or address space. Having a global unicast address actually makes this method more effective overall in implementation. Your applications and OS are no longer hiding behind stateful NAT devices making them brittle and prone to poor failover behavior. You get actual end-host-identifiable information that is globally unique. In terms of the address planning, you can make your life even easier by defining prefixes with specific functions.
Internet-edge network gear, Firewalls, VPN, proxies and load balancers are configured with publicly routable IPv4 address space. As previously mentioned, your IPv6 address space will be from the global unicast address space. Because of this, your network configuration in IPv6 may look quite different than your one in IPv4. One advantage in IPv6 is the ability to handle asymmetrical routing situations much better than in IPv4. For instance, a pitfall in IPv4 is the use of multi-homing without using BGP and provider independent address space. You can use NPTv6 to solve this in IPv6 but it is not widely supported and has not gained any popularity among the IPv6 community. Keep an eye on the IETF homenet working group as they are using IPv6 to potentially solve many of the common home and small business configuration challenges resulting from multi-homing.
Manual assignments for IPv4 hosts must include an IPv4 address, default gateway and name server information. For a host that is manually assigned an IPv6 address this process doesn’t change. It is possible to do some intermediate configurations that would only require a manual address be assigned to the host in IPv6 but as a general rule of thumb the work involved is identical for IPv4 and IPv6. The one thing that might be odd at first is that you will provide a link-local address as the next hop (default gateway) in IPv6. So knowing the statically assigned link-local address of the router will be important.
The vast majority of hosts do NOT have multiple IPv4 addresses on a single interfaces. In IPv6 however it is common to have multiple IPv6 addresses from the same prefix on the same interface. This is because IPv6 leverages the concept of temporary addresses. These addresses are used for a short duration of time and then discarded and replaced with a new one. Their value is the fact that they are short-lived and therefore increase the privacy of the host (potentially providing better end-user security). The host will still have a permanent IPv6 address. It will use either the EUI-64 or random method to establish its permanent IPv6 address. This address is registered in DNS. The temporary address is used for any outbound sessions from the host to remote systems. Things like web traffic, DNS queries, NTP requests and any other traffic that a host might need from the public Internet will appear from that temporary address. You don’t have to enable temporary addresses if you don’t want them but they do give IPv6 hosts a bit of time-based security defense in the form of privacy.
Some hosts have multiple interfaces – each with an IPv4 address – but only one interface actively being used. This situation doesn’t change with IPv6. You may have an active wired and wireless interface at the same time. This is more typical with a laptop in a docking station than any other scenario but it does happen. Mobile phones also fall into this situation when on cellular and Wi-Fi at the same time. Each OS has specific behavior to inform the host how to behave and switch back and forth between each radio or interface. The additional challenge with IPv6 is that you may have multiple addresses per interface and the host will either have to use Happy Eyeballs (RFC 6555) or source/destination address selection (RFC 6724) to determine which interface and address to use. Clearly, a helpdesk team will have challenges understanding all the nuances and differences and, as a result, troubleshooting can be much harder. Just as with IPv4, avoiding multiple interfaces on a host is likely a good thing. Leave routing tables and multiple interfaces to the networking team. That is their domain of knowledge and you will likely be better off in the long term.
Hosts are assumed to live in only one network domain at a time. For IPv6 there were several solutions designed to allow a host to live not on just one but multiple network domains at the same time. Mobile IPv6 and the ability to support multiple prefixes demonstrate this. Mobile IPv6 never took off and very few implementations of the IPv6 networking stack include Mobile IPv6 support. However, multiple prefixes are widely supported – that’s how you can easily perform zero-downtime network re-addressing in IPv6. This concept is new as there is no equivalent process in IPv4. In IPv6 it is possible to re-address a network if you are using SLAAC or DHCPv6 and run multiple network prefixes at the same time. While novel, in a practical sense it doesn’t address the fact that most operational practitioners would rather get an entire network segment cut over in one event in a single maintenance window rather than a drawn out, multiple stage event. In any case, it seems that the vision of a host living in multiple network domains at the same time is now shifting. The concepts of NFV, micro service architecture and containers really diminish the need for a single host to live in multiple network domains in the first place. While the IPv6 protocol better supports this concept I don’t see an immediate need for this capability.
So, do all the assumptions hold true? As you can see, it’s complicated. As a result, a good IPv6 adoption plan (and the understanding required to develop it) will make the process much easier and more successful. Don’t forget that the end-user applications and network hosts are really what this is all about. If you keep that key concept in focus you will more quickly identify and understand the critical issues you may encounter adopting IPv6. Adopting IPv6 shouldn’t be a roadblock in delivering applications and running hosts on your network, you just need to understand the differences so it all happens smoothly.
You can find me on twitter as @ehorley and remember…
IPv6 is the future and the future is now!
