Part 1: Top IPv6 RFCs 1-5 (Part 2 will be published later and contain Top IPv6 RFCs 6-10)
Introduction
In the middle of the last century, the existentialist philosopher and author Albert Camus famously wrote: “I sometimes think of what future historians will say of us. A single sentence will suffice for modern man: he … read the papers.” [Ed. Note: those ellipses, as is sometimes said in the literature biz, are “doing significant work” but I’ll leave the rest of the quote to be discovered by our more intrepid readers.]
As for us here in 2017, the dead tree papers are rapidly going the way of the dodo. So, we’ll have to modify the object of we modern’s attention generally to blogs and online articles, and in particular to everyone’s either favorite or hated subgenre: the listicle!
Depending on your taste, we’ve been either merciful or neglectful not including more listicles on our IPv6 CoE blog. So, either rejoice or bear with me as we explore the top 10 IPv6 RFCs (and why you should read them).
Before we start in on our list though, I want to make sure we’re all on the same page about what RFCs are (as well as where to find them). If that’s old hat to you feel free to skip ahead.
What the Heck is an RFC?
If you’ve been wrangling data networks for any significant amount of time, you’re likely already quite familiar with what RFCs are and the role that they play in said networking.
But for those that don’t know (or need reminding), an RFC (short for “Request for Comment”) is a document dealing with some relatively specific aspect of computer networking. (Early RFCs were more like detailed notes shared between the early Internet protocol pioneers, which over time became more formalized documents.) The specific aspect might be a protocol as in the original RFC for the Internet Protocol (version 4), RFC 791 “Internet Protocol” from way back in 1981. Or the RFCs for the Domain Name System (1034 “Domain names – concepts and facilities” and 1035 “Domain names – implementation and specification”), from 1987. Can you remember where you were in 1981 and 1987?
An example of a more recent RFC covering a networking protocol (and one perhaps near and dear to our hearts in the IPv6 community), RFC 8156 “DHCPv6 Failover Protocol” from June of this year.
Another aspect of networking an RFC might cover is network operations. For example, DNS operations are included in multiple RFCs but RFC 1033 (“Domain Administrators Operations Guide”) is an early one.
A careful reader may have noticed that the DNS operations RFC is earlier in sequence number than the protocol definition RFCs 1034 and 1035, though they were all released contemporaneously.
Network architecture is also a subject sometimes detailed in RFCs. For example, deployers of MPLS might be familiar with RFC 7625 “Architecture of an IP/MPLS Network with Hardened Pipes.”
Arguably, among the different types, protocol definition RFCs are the most read, reviewed, and referred to. Vendors, for instance, rely heavily on the definitions they provide in order to design their software and hardware and deploy those protocols in their products. Therefore, lack of precision in the protocol specifications can lead to bugs and lack of vendor interoperability.
It’s not hyperbole to say that all computer networks up to and including the Internet can trace their characteristics back to the technological DNA provided by the RFCs.
So where do they come from?
RFCs are created collaboratively by participants in the Internet Engineering Task Force and IETF participation is open to anyone, anywhere who has something to contribute. Computer scientists, researchers, software engineers, network operators and architects (both service provider and enterprise), vendor product managers, graduate students and many other roles — men and women from all over the world — are represented in the IETF RFC process. Indeed, the IETF enshrines this kind of techno-democratic ideal in its document The Tao of IETF: A Novice’s Guide to the Internet Engineering Task Force: “We reject kings, presidents and voting. We believe in rough consensus and running code.” I personally find it very stirring that something as massive and revolutionary as the Internet is largely a product of such open and free collaboration.
There’s plenty more info about RFCs — and related IETF documents, such as BPCs (i.e., “Best Current Practices”) and IDs (i.e., Internet Drafts, often precursors to RFCs) — at the link above. And if you’re not already participating (or at least following along) in one or more of the Working Groups, you might want to consider it. There is rarely a dull moment for those striving for “rough consensus and running code.”
But now, on with our top IPv6 RFCs and why you should read them. (This entry will cover the first five.)
In the spirit of the late (for television), great David Letterman, I would have liked to attempt to count down from the (arguably) less important IPv6 RFCs to the more important ones. But at least 8 out of 10 of the RFCs listed are what should be considered “foundational”; i.e., critical to a thorough understanding of how IPv6 is designed and how it is supposed to behave in most deployments. So, we’ll just go (mostly) in the order in which the original RFCs appeared.
You’ll probably notice when you follow the links that some of the RFCs contain a field indicating “Obsoletes” or “Updated by.” As you might imagine, once the vendor and open source code employing the guidance in the RFCs makes contact with real world deployments, technical issues arise. Some of these issues are merely operational or due to software bugs. Others may reveal something problematic with the underlying RFC. For example, sometimes network technology advancements that couldn’t have been foreseen by the authors or reviewers lead to the need for RFC updates (i.e., additional RFCs that serve to expand the standard into a new tech domain). Sometimes components of the RFC go entirely unused in code and subsequent deployment and are omitted in a new RFC that obsoletes the original one.
The Top IPv6 RFCs
#1:
RFC 2460: Internet Protocol, Version 6 (IPv6) Specification
Love IPv6 or hate it (and if you hate it, why are you torturing yourself reading this blog?), this is the RFC that started the IPv6 revolución. Well, technically, that was RFC 1883, which was obsoleted (see above) by this one. RFC 2460 is the first document to lay out the basic design of the IPv6 protocol and resulting packet: the 128-bit address; the IPv6 packet, the fixed (40-byte) header, the various extension headers and formats for each (including the original effort to make IPv6 more secure with authentication and security extensions); flow labels for Layer 3 QoS; the restriction of fragmentation to end nodes; etc.
The long list of “updated by” RFCs are mostly related to operational challenges in implementing extension headers (as well as handling fragments in real-world deployments). The flexibility and functionality promised by these headers as originally conceived in this RFC has largely not materialized for more than one reason, but the primary impediment has been the secure processing of these headers by routers, switches, security appliances and middle boxes. As a result, for example, RFC 5095 deprecates the Type 0 Routing Header to avoid it being exploited for traffic amplification in denial-of-service attacks.
[Author’s note: And just literally hours after I finished the first draft of this blog, the IETF published RFC 8200: Internet Protocol, Version 6 (IPv6) Specification moving IPv6 from a Draft Standard to an Internet Standard, indicating the highest level of technical maturity a protocol can achieve. For more information on the distinctions between standards, refer to RFC 2026.]
#2
A big part of the IPv6 standard is a from-the-ground-up redesign of IPv4. In other words, while adding 96 more address bits to overcome IPv4’s limited supply was and is the most significant aspect of IPv6, the early IETF IPv6 effort went beyond it to focus on additional ways in which IPv4 could be enhanced or improved. If you say to yourself, “I already know ICMP, I don’t need to read this RFC”, then think again. ICMPv6 is much different than ICMP for IPv4. You won’t get far into IPv6 without understanding the differences.
One of the most impactful parts of this redesign is Neighbor Discovery (or ND — something that shows up in its own RFC, which we’ll cover below). ND is a total redesign of IPv4 ARP (Address Resolution Protocol) and it relies on ICMPv6 to function properly. While the ICMPv6 messages used in ND are not discussed in RFC 4443, it is still worth being familiar with for the specifications it includes: e.g., general message format and message types.
In particular, the new Packet Too Big message type is uniquely important to IPv6, given that packet fragmentation is not permitted or done by intermediate network nodes.
#3
RFC 4861: Neighbor Discovery for IP Version 6 (IPv6)
As mentioned above, Neighbor Discovery is a total redesign of IPv4 ARP. The early IETF IPv6 effort focused on ways it might be possible to make the process for establishing and maintaining Layer 2 to Layer 3 mappings more efficient. Neighbor Discovery in IPv6 is the result of those efforts. As summarized in the RFC abstract, IPv6 “nodes (hosts and routers) use Neighbor Discovery to determine the link-layer addresses for neighbors known to reside on attached links and to quickly purge cached values that become invalid. Hosts also use Neighbor Discovery to find neighboring routers that are willing to forward packets on their behalf. Finally, nodes use the protocol to actively keep track of which neighbors are reachable and which are not, and to detect changed link-layer addresses. When a router or the path to a router fails, a host actively searches for functioning alternates.”
This RFC (as with many of the others) is really an essential reference document, in this case for how ND is supposed to operate and the messages it exchanges to provide the functions described above. It’s worth reviewing the RFC more closely to gain a better understanding of each of the ND functions (e.g., Address Resolution; Router, Prefix, and Parameter Discovery; Neighbor Unreachability and Duplicate Address Detection; etc.) are defined and supposed to behave.
#4
RFC 4862: IPv6 Stateless Address Autoconfiguration
Another aspect of the redesign of IPv4 that greatly interested the designers of IPv6 was the potential ability for a node to configure its own addresses (whether locally or globally scoped). The invention of DHCP was a response to the lack of this feature in IPv4 driven by network operators who wanted a way to get nodes online without direct manual configuration of each node. It was successfully argued early on that IPv6 should include this functionality at the protocol level. IPv6 Stateless Address Autoconfiguration is the result.
The RFC covers the interaction of routers and hosts using Router Solicitations and Router Advertisements as defined in Neighbor Discovery and the mechanism combining an interface identifier with a prefix that results in a globally scoped address. Other areas of significance in the RFC include how address lifetimes (e.g., Valid and Preferred) are intended to be handled in IPv6 and allow for rapid renumbering of nodes.
#5
RFC 3596: DNS Extensions to Support IP Version 6
As proved time and again — most recently with increased attacks on elements of the global DNS infrastructure, the Internet and all computer networks are rendered largely useless when DNS isn’t working properly. The existing structure of IPv4 DNS wasn’t sufficient to support a 128-bit address so extensions to the DNS had to be made. Among the shortest of all the IPv6 RFCs, this one defines AAAA (or “Quad A”) records for the forward mapping of domain names to IPv6 addresses. It also defines the ip6.arpa domain to handle reverse mapping of IPv6 addresses to domain names.
That’s it for this installment! Be sure to check back for the second part of the article, which will include the remaining 5 essential IPv6 RFCs.
