Welcome to part 2 of my blog on the top 10 IPv6 RFCs! Part 1 covered the first 5 while this time around we’ll discuss 6-10 of the most essential IPv6 RFCs. If you need a refresher on why IETF RFCs are important (or just want to know what the heck an RFC is!), be sure to check out part 1. So without further ado, here they are:
RFC 3315: Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
RFC 3315 defines DHCP for IPv6, or DHCPv6. Most IT administrators are intimately familiar with DHCP for IPv4 (or just DHCP as it’s usually referred to). As a result, it’s a commonly mistaken belief that DHCPv6 is just DHCP with support for IPv6 “bolted on.” As the RFC describes, however, DHCPv6 is a more-or-less complete redesign of DHCP. Most critically, the reliance on Layer 2 broadcast is replaced by the leveraging of the Layer 3 link-local addresses that all IPv6 nodes configure themselves with upon activation. This ensures that the DHCPv6 transaction between client and server takes place at Layer 3 with the added efficiency of multicast to ensure that nodes on the link don’t have to process DHCP traffic not intended for them.
From an operational standpoint, DHCPv6 provides an alternative to the auto-addressing functionality that’s already included in IPv6 in the form of SLAAC (RFC 4862: IPv6 Stateless Address Autoconfiguration) and since most IT networks have come to rely heavily on DHCP for IPv4, the opportunity to maintain operational consistency as dual-stack is deployed makes DHCPv6 the first choice for most enterprise networks. Unfortunately, the lack of DHCPv6 support for Android means that those same enterprises may have to sacrifice support for Android devices if they don’t want to have to deploy and maintain both DHCPv6 and SLAAC.
Another critical change to DHCPv6 from DHCP for IPv4 is the use of a new set of identifiers (beyond just the client MAC address) including the DHCP Unique Identifier (or DUID, which is, alas, an acronym containing another acronym — stop the madness!). According to the RFC, “each DHCP client and server has a DUID. DHCP servers use DUIDs to identify clients for the selection of configuration parameters and in the association of IAs with clients. DHCP clients use DUIDs to identify a server in messages where a server needs to be identified.” (For more detail on the DUID and its role, see my earlier blog post on DHCPv6 and the Trouble with MAC Addresses). The IA is an identity association and is used by the DHCPv6 server to identify, group, and manage sets of related, assigned IPv6 addresses. Client interfaces have multiple IPv6 addresses but one IA is assigned per interface.
As you can see, there is significantly more complexity to DHCPv6 and that makes this RFC a must-read for enterprise IT administrators planning to deploy IPv6 and DHCPv6.
RFC 4291: IP Version 6 Addressing Architecture
A quick glance at the table of contents of this RFC suggests why it’s on the list. It’s the definitive source for IPv6 address architecture and address type definitions. It deals with how IPv6 addresses are constructed, formatted, and represented as well as the basic rules for shortening them. The various address types, reservations, and scopes are covered, including loopback, multicast, link-local, and global unicast.
It also includes some legacy transition address types that are not widely deployed. These IPv6 Addresses with Embedded IPv4 Addresses include IPv4-Compatible IPv6 Addresses and IPv4-Mapped IPv6 Addresses. You’ll sometimes hear it suggested that IPv6 reserves addresses to be reserved for anycast usage and that definition is included in the RFC (i.e., Subnet-Router anycast addresses). From my experience, these don’t seem to be commonly used in operational settings.
This RFC has been updated by many additional ones. You’ll probably want to check out RFC 5952: A Recommendation for IPv6 Address Text Representation, which, as the title suggests, offers some additional recommendations for more consistently representing IPv6 addresses. Among these recommendations are the preferred use of all lower-case and which contiguous zero hextets should be shortened.
RFC 6724: Default Address Selection for Internet Protocol Version 6 (IPv6)
Once you’ve deployed dual-stack hosts, you’ll need to know how a given host chooses between using an IPv4 or an IPv6 address when sending or receiving application traffic. RFC 6724 provides this critical information. The two algorithms it covers deal with source address selection and destination address selection and suggest how applications or OSes might be programmed to behave — though with the proviso that they don’t have to follow the suggested behavior.
Still, when troubleshooting an application on a dual-stack host, the RFC provides a helpful framework for expected behavior and preference for all address types in both address families. It also suggests a method for altering a host’s policy table to influence which addresses are selected and used.
The examples offered in the RFC are instructive, particularly the destination address selection. Here’s a brief excerpt:
Candidate Source Addresses: 2001:db8:1::2 or fe80::1 or 169.254.13.78
Destination Address List: 2001:db8:1::1 or 198.51.100.121
Result: 2001:db8:1::1 (src 2001:db8:1::2) then 198.51.100.121 (src
169.254.13.78) (prefer matching scope)
Candidate Source Addresses: fe80::1 or 198.51.100.117
Destination Address List: 2001:db8:1::1 or 198.51.100.121
Result: 198.51.100.121 (src 198.51.100.117) then 2001:db8:1::1 (src
fe80::1) (prefer matching scope)
As the RFC suggests, address selection where a wide range of address types within each address family are deployed can get quite complicated. Fortunately, most deployments are somewhat limited to private IPv4 and link-local and GUA IPv6 source addresses, somewhat simplifying the address selection process.
For a deep operational dive (with tons of test scenarios), be sure to check out Enno Rey’s great presentation from RIPE 74.
RFC 8106: IPv6 Router Advertisement Options for DNS Configuration
As mentioned above, if you’re planning on supporting Android in your dual-stack enterprise network, you’ll need to support SLAAC as Android doesn’t have (and isn’t planning to add) support for DHCPv6. The next logical question is how will a SLAAC-enabled host learn the additional configuration information normally provided by DHCP. RFC 8106 “specifies IPv6 Router Advertisement (RA) options (called “DNS RA options”) to allow IPv6 routers to advertise a list of DNS Recursive Server Addresses and a DNS Search List to IPv6 hosts. Microsoft recently released support for this RFC for Windows 10 (though Windows 10 hosts will still prefer DNS information learned via DHCPv6).
RFC 7381: Enterprise IPv6 Deployment Guidelines
Finally, this informational RFC is now nearly three years old but still contains a wealth of information that should prove valuable to the enterprise deployer of IPv6. It emphasizes the standard approach, which is to say the transition from IPv4-only to dual-stack to IPv6-only (for more on the last step, read our very own Ed Horley’s blogs here and here).
The basic method recommended is one we have long championed variations of here at the Infoblox IPv6 CoE: a phased approach, generally consisting of three phases, that starts with planning (obtaining IPv6 addresses and connectivity) then moves on to the external network (especially web content and DNS) before deploying IPv6 internally (on the corporate LAN).
Further, the RFC points out some of the more potentially challenging and critical aspects of IPv6 deployment for enterprises; namely, the IPv6 readiness of the applications the organization uses. As we’ve pointed out frequently, most of an enterprise’s network infrastructure as well as servers and end-user devices long ago introduced and refined their IPv6 support. What remains questionable are all the legacy applications that many enterprises must continue to run as part of their business. This RFC offers a critical reminder that validating the readiness of these applications may prove the most difficult and time-consuming part of an IPv6 adoption effort.
That’s it for our top 10 RFCs! You may have other RFCs you feel are critical to your IPv6 adoption efforts. If so, please leave a comment indicating which ones and why!
