By Mark A. Miller, P.E, President, DigiNet Corporation
If we review the very first article in this series , we see that perhaps the most important reason that the IPv6 development was undertaken in the mid-1990s was the concern that the existing 32-bit IPv4 address space (with its theoretical maximum of 4.3 billion addresses) would become exhausted. This prediction did, in fact, come to pass, as the last block of existing addresses was assigned on January 31, 2011. Many factors contributed to this event, including the worldwide proliferation of the Internet, the somewhat inefficient Class A-B-C address block delineations, plus the rise of IP-connected smart phones and tablet computers. Taken together, this expansive growth made the existing Internet protocol suite a victim of its own success, meaning that a protocol upgrade was more mandatory than optional.
So when the Internet Engineering Task Force (IETF) IPng (IP Next Generation) Working Group set out to design a replacement for the existing IPv4, a retool of the addressing scheme was at the top of the priority list. After months of debate, an address field size of 128 bits was decided upon. This result yielded to the concern that an increase in the address space from the IPv4-size of 32 bits to 64 bits might only provide short-term relief, and that the possibility existed that another revision in the future (even if that was a decade or two away) was just too great of a risk to take. So the conclusion was to move to a 128 bit addressing field in IPv6. This produced quite an increase in available addresses (since the total number increases as a power of two) – a number which has been likened to the number of protons on the earth, or the number of grains of sand on the seashore. Needless to say, the resulting number should last long after all of us have retired, and are contemplating other things.
The IPv6 addressing scheme was first published as RFC (IETF Request for Comments document) 1884, IP version 6 Addressing Architecture (December 1995), and since that time, has undergone several revisions. The current document, RFC 4291 (see ftp://ftp.rfc-editor.org/in-notes/rfc4291.txt), was published in February 2006, and is updated by RFCs 5952 and 6052.
In addition to the dramatic increase in the number of available addresses, the IPv6 addressing architecture brings several new concepts into the world of Internet addressing:
Address Types: IPv6 defines three different types of addresses. Unicast Addresses identify a single interface. When a packet is sent to a unicast address, it is delivered to the interface specified by that address. Anycast Addresses identify a set of multiple interfaces, typically belonging to different nodes. When a packet is sent to an anycast address, it is delivered to the “nearest” interface (according to the routing protocol’s measure of distance) of that set of interfaces. Multicast Addresses identify a set of interfaces, typically belonging to different nodes. When a packet is sent to a multicast address, it is delivered to all of the interfaces that are identified by that address. Note that the concept of the IPv4 Broadcast Address no longer exists, as its function can be provided by the IPv6 Multicast Address.
Address Representation: say goodbye to your familiar IPv4 dotted decimal notation (e.g. 10.41.75.1), and replace that with a string of hexadecimal characters separated by colons. For example:
X:X:X:X:X:X:X:X
represents an IPv6 address. Each “X” specifies 16 bits of the IPv6 address, hence eight of these 16 bit chunks are required (8 x 16 = 128). Each 16-bit value is then represented by one to four hexadecimal (numerical base 16) characters (0,1,2 … A,B,C,D,E,F). Thus, an example (from RFC 4291) of a unicast address would be:
2001:DB8:0:0:8:800:200C:417A
Note that there are eight “chunks”, but that some of the leading zeros have been omitted (e.g. “8” instead of “0008”) for simplicity. Other shorthand methods of address representation are also detailed in RFC 4291.
Address Identification: an IPv6 address is divided into two general sections, a Prefix, which consists of n bits), and an Address (which consists of 128-n bits). The prefix portion identifies the type of address in question (unicast, anycast or multicast), while the address portion provides the addressing details. For example, the prefix for multicast addresses is binary 11111111 (or hexadecimal FF). The purpose of the prefix is to enable quicker routing decisions, as only the first few bits need to be processed for a preliminary routing judgement to be made. These prefix assignments are controlled by the Internet Assigned Numbers Authority (IANA), and freely available on the IANA pages (see http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xml).
As you can see, there is a lot to learn with the IPv6 addressing structure, and we have only scratched the surface of RFC 4291’s 25 pages of documentation (not to mention the other RFCs that provide details for specific applications). Interested readers are encouraged to dig in and learn this new language. A good place to start is the RFC Editor’s website (see http://www.rfc-editor.org/), and then enter the search phrase “IPv6 address” in the RFC Search box. After you see the 90 or so matches, you can select your favorite(s) for some interesting summer vacation reading!
Author’s Biography
Mark A. Miller, P.E. is President of DigiNet Corporation®, a Denver-based consulting engineering firm. He is the author of many books on networking technologies, including the Internet Technologies Handbook, published by John Wiley & Sons.
