IPv6 Essentials | O'Reilly Media

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The IP version currently used in networks and the Internet is IP Version 4 (IPv4). IPv4 was developed in the early '70s to facilitate communication and information sharing between government researchers and academics in the United States. At the time, the system was closed with a limited number of access points, and consequently the developers didn't envision requirements such as security or quality of service. To its credit, IPv4 has survived for over 30 years and has been an integral part of the Internet revolution. But even the most cleverly designed systems age and eventually become obsolete. This is certainly the case for IPv4. Today's networking requirements extend far beyond support for web pages and email. Explosive growth in network device diversity and mobile communications, along with global adoption of networking technologies, are overwhelming IPv4 and have driven the development of a next-generation Internet Protocol.

IPv6 has been developed based on the rich experience we have from developing and using IPv4. Proven and established mechanisms have been retained, known limitations have been discarded, and scalability and flexibility have been extended. IPv6 is a protocol designed to handle the growth rate of the Internet and to cope with the demanding requirements on services, mobility, and end-to-end security.

When the Internet was switched from using Network Control Protocol (NCP) to Internet Protocol (IP) in one day in 1983, IP was not the mature protocol that we know today. Many of the well-known and commonly used extensions were developed in subsequent years to meet the growing requirements of the Internet. In comparison, hardware vendors and operating system providers have been supporting IPv6 since 1995 when it became a Draft Standard. In the decade since then, those implementations have matured, and IPv6 support has spread beyond the basic network infrastructure and will continue to be extended.

There is certainly a need for caution when considering adoption of IPv6—there is still work to be done to reach parity with the maturity of IPv4 (refer to Chapter 10 for more details). The missing pieces of IPv6 will be developed in the coming years, just the way it happened with IPv4. And many enterprises are not finding enough reasons to adopt it right now. However, it is very important for organizations to pay attention to the introduction of IPv6 because its use is inevitable in the long term. If IPv6 is included in strategic planning; if organizations think about possible integration scenarios ahead of time; and if its introduction is considered when investing in IT capital expenditures, organizations can save considerable cost and can enable IPv6 more efficiently when it is needed.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The Internet Engineering Task Force (IETF) began the effort to develop a successor protocol to IPv4 in the early 1990s. Several parallel efforts to solve the foreseen address space limitation and to provide additional functionality began simultaneously. The IETF started the Internet Protocol—Next Generation (IPng) area in 1993 to investigate the different proposals and to make recommendations for further procedures.

The IPng area directors of the IETF recommended the creation of IPv6 at the Toronto IETF meeting in 1994. Their recommendation is specified in RFC 1752, "The Recommendation for the IP Next Generation Protocol." The Directors formed an Address Lifetime Expectation (ALE) working group to determine whether the expected lifetime for IPv4 would allow the development of a protocol with new functionality, or if the remaining time would allow only the development of an address space solution. In 1994, the ALE working group projected that the IPv4 address exhaustion would occur sometime between 2005 and 2011 based on the available statistics.

For those of you who are interested in the different proposals, here's some more information about the process (from RFC 1752). There were four main proposals: CNAT, IP Encaps, Nimrod, and Simple CLNP. Three more proposals followed: the P Internet Protocol (PIP), the Simple Internet Protocol (SIP), and TP/IX. After the March 1992 San Diego IETF meeting, Simple CLNP evolved into TCP and UDP with Bigger Addresses (TUBA), and IP Encaps became IP Address Encapsulation (IPAE). IPAE merged with PIP and SIP and called itself Simple Internet Protocol Plus (SIPP). The TP/IX working group changed its name to Common Architecture for the Internet (CATNIP). The main proposals were now CATNIP, TUBA, and SIPP. For a short discussion of the proposals, refer to RFC 1752.

CATNIP is specified in RFC 1707; TUBA in RFCs 1347, 1526, and 1561; and SIPP in RFC 1710.

The Internet Engineering Steering Group approved the IPv6 recommendation and drafted a Proposed Standard on November 17, 1994. RFC 1883, "Internet Protocol, Version 6 (IPv6) Specification," was published in 1995. The core set of IPv6 protocols became an IETF Draft Standard on August 10, 1998. This included RFC 2460, which obsoleted RFC 1883.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

IPv6 is an evolution of IPv4. The protocol is installed as a software upgrade in most devices and operating systems. If you buy up-to-date hardware and operating systems, IPv6 is usually supported and needs only activation or configuration. Currently available transition mechanisms allow the step-by-step introduction of IPv6 without putting the current IPv4 infrastructure at risk.

Here is an overview of the main changes:

Extended address space: The address format is extended from 32 bits to 128 bits. This provides an IP address for every grain of sand on the planet. In addition, it also allows for hierarchical structuring of the address space in favor of optimized global routing.
Autoconfiguration: Perhaps the most intriguing new feature of IPv6 is its Stateless autoconfiguration mechanism. When a booting device in the IPv6 world comes up and asks for its network prefix, it can get one or more network prefixes from an IPv6 router on its link. Using this prefix information, it can autoconfigure for one or more valid global IP addresses by using either its MAC identifier or a private random number to build a unique IP address. In the IPv4 world, we have to assign a unique IP address to every device, either by manual configuration or by using DHCP. Stateless autoconfiguration should make the lives of network managers easier and save substantial cost in maintaining IP networks. Furthermore, if we imagine the number of devices we may have in our homes in the future that will need an IP address, this feature becomes indispensable. Imagine reconfiguring your DHCP server at home when you buy a new television! Stateless autoconfiguration also allows for easy connection of mobile devices, such as a mobile phone or handheld, when moving to foreign networks.
Simplification of header format: The IPv6 header is much simpler than the IPv4 header and has a fixed length of 40 bytes. This allows for faster processing. It basically accommodates two times 16 bytes for the Source and Destination address and only 8 bytes for general header information.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

For historic reasons, organizations and government agencies in the United States use approximately 60 percent of the allocatable IPv4 address space. The remaining 40 percent is shared by the rest of the world. Of the 6.4 billion people in the world, approximately 330 million live in North America, 807 million in Europe, and 3.6 billion in Asia. This means that the 5 percent of the world's population living in the United States has 60 percent of the address space allocated. Of the 3.6 billion people living in Asia, approximately 364 million have Internet access, and the growth rate is exponential. This is one explanation of why the deployment of IPv6 in Asia is much more common than in Europe and the United States. (All statistics are based on 2005 numbers.)

An interesting resource site for statistics can be found at: http://www.internetworldstats.com/stats.htm.

The IPv4 address space has a theoretical limit of 4.3 billion addresses. However, early distribution methods allocated addresses inefficiently. Consequently, some organizations obtained address blocks much larger than they needed, and addresses that could be used elsewhere are now unavailable. If it were possible to reallocate the IPv4 address space, it could be used much more effectively, but this process is not possible, and a global reallocation and renumbering is simply not practical. We also have to be aware of the fact that today, as the IPv4 address space approaches exhaustion, only about 14 percent of the world's population has Internet access. If we want to provide Internet access to only 20 percent of the world's population, we will need the IPv6 address space. And this calculation does not take into account that in the future we will need IP addresses for billions of devices. Vendors in all industries are developing monitoring, control, and management systems based on IP.

As the previous section shows, the IPv6 working group has done more than extend the address space. For many complex networks of today and tomorrow, and for the number of IP devices of all types, the autoconfiguration capability of IPv6 will be a necessity. The management of such services can't be accomplished with traditional addressing methods, and Stateless autoconfiguration will also help to reduce administrative costs for organizations.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

When considering all these advantages, maybe the question should be: "Why not IPv6?" When talking to customers, we often find that they share a similar set of misconceptions preventing them from considering IPv6. Here are the most common ones:

"The introduction of IPv6 puts our current IP infrastructure—our networks and services—at risk.": This concern is unsubstantiated. A major focus in IPv6's development was to create integration mechanisms that allow both protocols to coexist peacefully. You can use IPv6 both in tandem with and independently of IPv4. It is possible to introduce IPv6 and use it for access to new services while retaining IPv4 to access legacy services. This not only ensures undisrupted access to IPv4 services, but it also allows a step-by-step introduction of IPv6. I discuss these mechanisms in Chapter 10.
"The IPv6 protocol is immature and hasn't proven that it stands the test of time or whether it is capable of handling the requirements.": This is only partially true. IPv6 has been implemented in most router and operating systems for almost a decade, and has been tested and optimized extensively. There are substantial international research efforts and test networks for deployment that are further optimizing integration methods. One of the largest tests currently running is Moonv6 (http://www.moonv6.com). Moonv6 is a test network where the U.S. Department of Defense (DoD), IPv6 developers and vendors, and various academic and industry bodies conduct extensive interoperability and conformance testing of the IPv6 base features, as well as extended features such as quality of service, mobility, and security. You can find a more detailed description of Moonv6 in Chapter 10.
"The costs of introducing IPv6 are too high.": There will certainly be costs associated with adopting IPv6. In many cases, newer networks will find that the level of IPv6 support in their current infrastructure is actually high. Regardless, the transition will necessitate some hardware and software costs. Organizations will need to train their IT staff, and, depending on the speed at which integration must occur, they may need to seek outside expertise.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

If the rest of the world moves to IPv6 while you insist on continuing to use IPv4, you will exclude yourself from global communication and reachability. This might not be a critical issue today, but times are changing fast these days. The risks if you wait too long include losing potential customers and access to new markets and the inability to use new IPv6-based business applications until you implement it.

There is a golden rule in IT: "Never touch a running system." As long as your IPv4 infrastructure runs well and fulfills your needs, there is no reason to change anything. But from now on, whenever you invest in your infrastructure, you should consider IPv6. An investment in the new technology gives it a much longer lifetime and keeps your network state-of-the-art.

These are the main indicators that it may be time for you to consider switching to or integrating IPv6:

You need to extend or fix your IPv4 network or NAT implementation.
You are running out of address space.
You want to prepare your network for applications that are based on advanced features of IPv6.
You need end-to-end security for a large number of users and you do not have the address space, or you struggle with a NAT implementation.
You need to replace your hardware or applications that are at the end of their lifecycles. Make sure you buy products that support IPv6, even if you don't enable it right away.
You want to introduce IPv6 while there is no time pressure.

The following provisions can be taken in order to prepare for IPv6 adequately:

Build internal knowledge, educate IT staff, and create a test network.
Include IPv6 in your IT strategy.
Create integration scenarios based on your network and requirements.
Put IPv6 support on all of your hardware and software shopping lists. Be specific about which features (RFCs) must be supported.
Compel your vendors to add IPv6 support to their products.

If you do this, you can determine the right moment for the introduction of IPv6 in your network. You can also assess whether a further investment in your IPv4 infrastructure makes sense or whether introducing IPv6 would be a better way to go.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The oldest IPv6 network is the 6Bone (http://www.6bone.net). It was started in 1996, and by 2004 it connected more than 1,000 hosts in more than 50 countries across the world. Originally, it was used as a test network for the IETF working groups. Over time it became an international project in which everybody was welcome to participate. The address allocation had not been standardized at that time, so the 6Bone received the special prefix 3FFE. Today, the IPv6 address allocation is specified and open for registration, and the 6Bone will gradually be moved to the official IPv6 address space by mid-2006. Their web site is still accessible for historical and statistical reasons. The 6Bone proved that IPv6 is stable and can be used globally. It was also used to get experience with routing and network management processes, as well as to test transition mechanisms and IPv6 applications and services.

If we look at the global deployment of IPv6, the scenarios are different on each continent. The International IPv6 Forum (http://www.ipv6forum.com) coordinates the worldwide activities. The International Task Force (http://www.ipv6tf.org) coordinates the regional Task Forces all over the world. There is a North American IPv6 Task Force (http://www.nav6tf.org), a European Task Force (http://www.eu.ipv6tf.org), and different Task Forces in Asia and other parts of the world. They can all be found from the main Task Force Site. The regional Task Forces coordinate the activities in their regions. In Europe, for example, there is a Task Force in almost every country.

In Asia, IPv6 is already a reality. The high population and accelerated Internet growth rate, combined with the limited IPv4 address space, does not leave any other choices.

Japan was one of the first countries to take the lead. In March 2001, they published the "e-Japan Priority Policy Program," announcing that they would build the largest IPv6 network. The Japanese Task Force can be found at http://www.v6pc.jp/en/index.phtml.

In Japan there is a showroom where vendors demo their IPv6-capable devices. Sony, for instance, announced that in the near future, all Sony devices will include IPv6 support. To give you an idea of the status of IPv6 in Japan, here are some things you can see in this showroom:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

As previously mentioned, IPv6 is implemented in most up-to-date versions of routing and operating systems. For standard applications, assume that IPv6 support will be added with their next major release at the latest. For creating an IPv6 integration plan for your corporate network, you will need to assess the status and degree of IPv6 support with each vendor individually. Many vendors have an information site that can often be found at http://www.<vendor>.com/ipv6.

It can be said that IPv6 support up to the network layer is mature, tested, and optimized. This includes routing, transition mechanisms, and DNS. DHCPv6 was standardized in 2004, and early implementations have been available in select platforms since 2005.

Development is most active in the quality of service, security, IPv4/IPv6 MIB integration, and Mobile IPv6 areas. Currently, there is a lack of support in the areas of network management, firewalls, and proxies. Vendors such as Cisco, Checkpoint, Juniper, and many others are working on these areas. The application area is continuously developing, and new applications will appear on the market that will make use of the advanced features of IPv6. Thanks to the transition mechanisms mentioned earlier, you can still use IPv4 applications in IPv6 networks. Worldwide development goes beyond infrastructure, as the showroom in Japan demonstrates.

Find more information on the status of application and vendor support in Chapter 10.

Now you know why you should care about IPv6. The rest of the chapters in this book aim to make learning about IPv6 a joy. So please read on.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Here's a list of the most important RFCs and Drafts mentioned in this chapter. Sometimes I include additional subject-related RFCs for your personal further study.

RFC 1, "Host Software," 1969
RFC 318, "Telnet Protocol," 1972
RFC 454, "FILE TRANSFER PROTOCOL," 1973
RFC 1347, "TCP and UDP with Bigger Addresses (TUBA)," 1992
RFC 1526, "Assignment of System Identifiers for TUBA/CLNP Hosts," 1993
RFC 1561, "Use of ISO CLNP in TUBA Environments," 1993
RFC 1631, "The IP Network Address Translator (NAT)," 1994
RFC 1707, "CATNIP: Common Architecture for the Internet," 1994
RFC 1710, "Simple Internet Protocol Plus White Paper," 1994
RFC 1752, "The Recommendation for the IP Next Generation Protocol," 1995
RFC 1883, "Internet Protocol, Version 6 (IPv6) Specification," 1995
RFC 2235, "Hobbes' Internet Timeline," 1997
RFC 2324, "Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)," 1998
RFC 2460, "Internet Protocol, Version 6 (IPv6) Specification," 1998
RFC 2663, "IP Network Address Translator (NAT) Terminology and Considerations," 1999
RFC 3022, "Traditional IP Network Address Translator (Traditional NAT)," 2001
RFC 3027, "Protocol Complications with the IP Network Address Translator," 2001
RFC 3315, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)," 2003

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

This chapter explains the structure of the IPv6 header and compares it to the IPv4 header. It also discusses Extension headers, which are new in IPv6.

Understanding the structure of a protocol header and the type of information that can be transported with it is the best foundation for working with a protocol. This understanding helps you to identify how the protocol can best be configured and what the options are. It also helps you to identify possible sources of problems and issues when troubleshooting.

The header structure of an IPv6 packet is specified in RFC 2460. The header has a fixed length of 40 bytes. The two fields for Source and Destination addresses each use 16 bytes (128 bits), so there are only 8 bytes for general header information. The IPv6 header is therefore much simpler and leaner than the IPv4 header, allowing for more efficient processing and, as we will see, more flexibility in extending the protocol to meet future needs.

In IPv6, five fields from the IPv4 header have been removed:

Header Length
Identification
Flags
Fragment Offset
Header Checksum

The Header Length field was removed because it is not needed in a header with a fixed length. In IPv4, the minimum header length is 20 bytes, but if options are added, it can be extended in 4-byte increments up to 60 bytes. Therefore, with IPv4, the information about the total length of the header is important. In IPv6, options are defined in Extension headers (covered later in this chapter).

The Identification, Flags, and Fragment Offset fields handle fragmentation of a packet in the IPv4 header. Fragmentation happens if a large packet has to be sent over a network that supports only smaller packet sizes. In that case, the IPv4 router splits the packet into smaller slices and forwards multiple packets. The destination host collects the packets and reassembles them. If only one packet is missing or has an error, the whole transmission has to be redone; this is very inefficient. In IPv6, a host learns the Path Maximum Transmission Unit (MTU) size through a procedure called Path MTU Discovery

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In IPv6, five fields from the IPv4 header have been removed:

Header Length
Identification
Flags
Fragment Offset
Header Checksum

The Header Length field was removed because it is not needed in a header with a fixed length. In IPv4, the minimum header length is 20 bytes, but if options are added, it can be extended in 4-byte increments up to 60 bytes. Therefore, with IPv4, the information about the total length of the header is important. In IPv6, options are defined in Extension headers (covered later in this chapter).

The Identification, Flags, and Fragment Offset fields handle fragmentation of a packet in the IPv4 header. Fragmentation happens if a large packet has to be sent over a network that supports only smaller packet sizes. In that case, the IPv4 router splits the packet into smaller slices and forwards multiple packets. The destination host collects the packets and reassembles them. If only one packet is missing or has an error, the whole transmission has to be redone; this is very inefficient. In IPv6, a host learns the Path Maximum Transmission Unit (MTU) size through a procedure called Path MTU Discovery . If a sending IPv6 host wants to fragment a packet, it will use an Extension header to do so. IPv6 routers along the path of a packet do not provide fragmentation as they did with IPv4. So the Identification, Flags, and Fragment Offset fields were removed from the IPv6 header and will be inserted in an Extension header by the source host if needed. I explain Extension headers later in this chapter.

Path MTU Discovery is explained in Chapter 4.

The Header Checksum field was removed to improve processing speed. If routers do not have to check and update checksums, processing becomes much faster. At the time when IPv4 was developed, checksumming at the media access level wasn't common, so the checksum field in the IPv4 header made sense. Today, the risk for undetected errors and misrouted packets is minimal. There is also a checksum field at the transport layer (UDP and TCP). With IPv4, a UDP checksum is optional; with IPv6, a UDP checksum is mandatory. IP is a

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

By becoming familiar with the fields of the IPv6 header, you will better understand how IPv6 works.

For a detailed description of all the fields in an IPv4 header, refer to Novell's Guide to Troubleshooting TCP/IP (Wiley).

Figure 2-1 provides an overview of the IPv6 header. The fields are discussed in detail in the following paragraphs.

Figure 2-1: Fields in the IPv6 header

Figure 2-1 shows that even though the header has a total size of 40 bytes, which is twice as long as a default IPv4 header, it has actually been streamlined because most of the header is taken up by the two 16-byte IPv6 addresses. That leaves only 8 bytes for other header information.

This is a 4-bit field containing the version of the protocol. In the case of IPv6, the number is 6. The version number 5 could not be used because it had already been assigned to the experimental stream protocol.

This field replaces the "Type of Service" field in IPv4. It facilitates the handling of real-time data and any other data that requires special handling, and sending nodes and forwarding routers can use it to identify and distinguish between different classes or priorities of IPv6 packets.

RFC 2474, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers," explains how the Traffic Class field in IPv6 can be used. RFC 2474 uses the term DS Field to refer to the "Type of Service" field in the IPv4 header, as well as to the Traffic Class field in the IPv6 header. Refer to Chapter 6 for more information.

This field distinguishes packets that require the same treatment in order to facilitate the handling of real-time traffic. A sending host can label sequences of packets with a set of options. Routers keep track of flows and can process packets belonging to the same flow more efficiently because they do not have to reprocess each packet's header. The flow label and address of the source node uniquely identify the flow. Nodes that do not support the functions of the Flow Label field are required to pass the field unchanged when forwarding a packet and to ignore the field when receiving a packet. All packets belonging to the same flow must have the same Source and Destination IP address.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The IPv4 header can be extended from a minimum of 20 bytes to a maximum of 60 bytes in order to specify options such as Security Options, Source Routing, or Timestamping. This capacity has rarely been used because it causes a performance hit. For example, IPv4 hardware forwarding implementations have to pass the packet containing options to the main processor (software handling).

The simpler a packet header, the faster the processing is. IPv6 has a new way to deal with options that has substantially improved processing: it handles options in additional headers called Extension headers. Extension headers are inserted into a packet only if the options are needed.

The current IPv6 specification (RFC 2460) defines six Extension headers:

Hop-by-Hop Options header
Routing header
Fragment header
Destination Options header
Authentication header
Encrypted Security Payload header

There can be zero, one, or more than one Extension header in an IPv6 packet. Extension headers are placed between the IPv6 header and the upper-layer protocol header. Each Extension header is identified by the Next Header field in the preceding header. The Extension headers are examined or processed only by the node identified in the Destination address field of the IPv6 header. If the address in the Destination address field is a multicast address, the Extension headers are examined and processed by all the nodes belonging to that multicast group. Extension headers must be strictly processed in the order in which they appear in the packet header.

There is one exception to the rule that only the destination node will process an Extension header. If the Extension header is a Hop-by-Hop Options header, the information it carries must be examined and processed by every node along the path of the packet. The Hop-by-Hop Options header, if present, must immediately follow the IPv6 header. It is indicated by the value 0 in the Next Header field of the IPv6 header (see Table 2-1 earlier in this chapter).

The first four Extension headers are described in RFC 2460. The Authentication header is described in RFC 2402, and the Encrypted Security Payload header in RFC 2406.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The following is a list of the most important RFCs and drafts mentioned in this chapter. Sometimes I include additional subject-related RFCs for your personal further study.

RFC 791, "Internet Protocol," 1981
RFC 1812, "Requirements for IP Version 4 Routers," 1995
RFC 1819, "Internet Stream Protocol Version 2," 1995
RFC 1981, "Path MTU Discovery for IP version 6," 1996
RFC 2401, "Security Architecture for the Internet Protocol," 1998
RFC 2402, "IP Authentication Header," 1998
RFC 2406, "IP Encapsulating Security Payload (ESP)," 1998
RFC 2460, "Internet Protocol, Version 6 (IPv6) Specification," 1998
RFC 2473, "Generic Packet Tunneling in IPv6 Specification," 1998
RFC 2474, "Definition of the Differentiated Services Field (DS Field)," 1998
RFC 2475, "An Architecture for Differentiated Services," 1998
RFC 2507, "IP Header Compression," 1999
RFC 2675, "IPv6 Jumbograms," 1999
RFC 2711, "IPv6 Router Alert Option," 1999
RFC 3175, "Aggregation of RSVP for IPv4 and IPv6 Reservations," 2001
RFC 3514, "The Security Flag in the IPv4 Header," April 1, 2003

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

An IPv4 address has 32 bits and looks familiar. An IPv6 address has 128 bits and looks wild at first glance. Extending the address space was one of the driving reasons to develop IPv6, along with optimization of routing tables, especially on the Internet. This chapter will help you become familiar with the extended address space and will also explain how IPv6 addressing works and why it has been designed to be the way it is. The IPv6 addressing architecture is defined in RFC 4291, which obsoletes RFC 3513.

The 32 bits of the IPv4 address space provide a theoretical maximum of 2³² addresses, equal to approximately 4.29 billion addresses. The current world population reaches approximately 6.4 billion people. So even if it were possible to use 100 percent of the IPv4 address space, we would not be able to provide an IP address for everyone on the planet. As a matter of fact, only a small fraction of this address space can be used. In the early days of IP, nobody foresaw the existence of the Internet as we know it today. Therefore, large address blocks were allocated without considerations for global routing and address conservation issues. These address ranges cannot be reclaimed, so consequently there are many unused addresses that are not available for allocation.

Are you aware that today only about 14 percent of the world's population has Internet access?

If we wanted to provide Internet access to only 20 percent of the world population, the IPv4 address space could never cover the demand. Calculations have shown that this would require around 390 Class A (/8) IPv4 address blocks, but there were only 64 Class A address blocks left in the unallocated IANA pool as of the end of 2005. And the evolution of the Internet and our services shows that in the future, not only are addresses for users and computers needed, but we'll also need more and more addresses for all sorts of devices that need permanent Internet connections, such as cell phones, PDAs, webcams, refrigerators, cars, and many more items. Car manufacturers, as one example, who are designing the networked car of the future, need at least 20 IP addresses per car. These addresses will be used for monitoring and maintenance as well as for access to services such as weather and traffic information. There is a prototype of a Renault car with an integrated Cisco router and a Mobile IPv6 implementation. Most of the big car manufacturers have similar plans and prototypes.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The 32 bits of the IPv4 address space provide a theoretical maximum of 2³² addresses, equal to approximately 4.29 billion addresses. The current world population reaches approximately 6.4 billion people. So even if it were possible to use 100 percent of the IPv4 address space, we would not be able to provide an IP address for everyone on the planet. As a matter of fact, only a small fraction of this address space can be used. In the early days of IP, nobody foresaw the existence of the Internet as we know it today. Therefore, large address blocks were allocated without considerations for global routing and address conservation issues. These address ranges cannot be reclaimed, so consequently there are many unused addresses that are not available for allocation.

Are you aware that today only about 14 percent of the world's population has Internet access?

If we wanted to provide Internet access to only 20 percent of the world population, the IPv4 address space could never cover the demand. Calculations have shown that this would require around 390 Class A (/8) IPv4 address blocks, but there were only 64 Class A address blocks left in the unallocated IANA pool as of the end of 2005. And the evolution of the Internet and our services shows that in the future, not only are addresses for users and computers needed, but we'll also need more and more addresses for all sorts of devices that need permanent Internet connections, such as cell phones, PDAs, webcams, refrigerators, cars, and many more items. Car manufacturers, as one example, who are designing the networked car of the future, need at least 20 IP addresses per car. These addresses will be used for monitoring and maintenance as well as for access to services such as weather and traffic information. There is a prototype of a Renault car with an integrated Cisco router and a Mobile IPv6 implementation. Most of the big car manufacturers have similar plans and prototypes.

The IPv6 address space uses a 128-bit address, meaning that we have a maximum of 2¹²⁸ addresses available. Do you want to know what this number looks like? It equals 340,282,366,920,938,463,463,374,607,431,768,211,456, or 6.65 × 10

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

IPv4 knows unicast, broadcast, and multicast addresses. With IPv6, the broadcast address is not used anymore; multicast addresses are used instead. This is good news because broadcasts are a problem in most networks. The anycast address, a new type of address introduced with RFC 1546, has already been used in the IPv4 world but will probably be used on a wider basis with IPv6.

An IPv6 address can be classified into one of three categories:

Unicast: A unicast address uniquely identifies an interface of an IPv6 node. A packet sent to a unicast address is delivered to the interface identified by that address.
Multicast: A multicast address identifies a group of IPv6 interfaces. A packet sent to a multicast address is processed by all members of the multicast group.
Anycast: An anycast address is assigned to multiple interfaces (usually on multiple nodes). A packet sent to an anycast address is delivered to only one of these interfaces, usually the nearest one.

IPv6 addresses are assigned to interfaces as in IPv4, not to nodes as in OSI, so each interface of a node needs at least one unicast address. A single interface can also be assigned multiple IPv6 addresses of any type (unicast, multicast, and anycast). A node can therefore be identified by the address of any of its interfaces. It is also possible to assign one unicast address to multiple interfaces for load-sharing reasons, but if you do this, you need to make sure that the hardware and drivers support it.

With IPv6, all zeros and ones are legal values for any field in an address.

IPv6 supports addresses of different scopes . There are global and non-global (e.g., link-local) scopes. Operationally, the use of non-global addresses has been introduced with IPv4 by using IP addresses from the private range or administratively scoped multicast addresses. The design of IPv6 includes the address scope in the base architecture. Every IPv6 address other than the unspecified address has a specific scope, which is a topological span within which the address may be used as a unique identifier for an interface or set of interfaces. The scope of an address is encoded as part of the address. You can find a description of scopes in the "Multicast Address" section later in this chapter, and refer to RFC 4007, "IPv6 Scoped Address Architecture" for an explanation of scopes.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

An IPv6 address has 128 bits, or 16 bytes. The address is divided into eight 16-bit hexadecimal blocks separated by colons. For example:

2001:DB8:0000:0000:0202:B3FF:FE1E:8329

To make life easier, some abbreviations are possible. For instance, leading zeros in a 16-bit block can be skipped. The example address now looks like this:

2001:DB8:0:0:202:B3FF:FE1E:8329

A double colon can replace consecutive zeros or leading or trailing zeros within the address. If we apply this rule, our address looks as follows:

2001:DB8::202:B3FF:FE1E:8329

Note that the double colon can appear only once in an address. The reason for this rule is that the computer always uses a full 128-bit binary representation of the address, even if the displayed address is simplified. When the computer finds a double colon, it expands it with as many zeros as are needed to get 128 bits. If an address had two double colons, the computer would not know how many zeros to add for each colon. So the IPv6 address 2001:DB8:0000:0056:0000:ABCD:EF12:1234 can be represented in the following ways (note the two possible positions for the double colon):

2001:DB8:0000:0056:0000:ABCD:EF12:1234
2001:DB8:0:56:0:ABCD:EF12:1234
2001:DB8::56:0:ABCD:EF12:1234
2001:DB8:0:56::ABCD:EF12:1234

In environments where IPv4 and IPv6 nodes are mixed, another convenient form of IPv6 address notation is to put the values of an IPv4 address into the four low-order byte pieces of the address. An IPv4 address of 192.168.0.2 can be represented as x:x:x:x:x:x:192.168.0.2, and an address of 0:0:0:0:0:0:192.168.0.2 can be written as ::192.168.0.2. If you prefer, you can also write ::C0A8:2.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The notation for prefixes has also been specified in RFC 4291. A global routing prefix is the high-order bits of an IP address used to identify the subnet or a specific type of address (refer to Table 3-2). It was called the format prefix in earlier RFCs. The prefix notation is very similar to the way IPv4 addresses are written in Classless Interdomain Routing (CIDR) notation, and it is also commonly used for subnetted IPv4 addresses. The notation appends the prefix length, written as a number of bits with a slash, which leads to the following format:

IPv6 address/prefix length

The prefix length specifies how many left-most bits of the address specify the prefix. This is another way of noting a subnet mask. Remember, a subnet mask specifies the bits of the IPv4 address that belong to the network ID. The prefix is used to identify the subnet that an interface belongs to and is used by routers for forwarding. The following example explains how the prefix is interpreted. Consider the IPv6 prefix notation 2E78:DA53:1200::/40. To understand this address, let's convert the hex into binary as shown in Table 3-1.

Table 3-1: Understanding prefix notation
Hex notation	Binary notation	Number of bits
2E 78	0010 1110 0111 1000	16
DA 53	1101 1010 0101 0011	16
12	0001 0010	8
		Total: 40

The compressed notation (replacing a sequence of zeros with a double colon) is also applicable to the prefix representation. It should be used carefully, though, because there are often two or more ranges of zeros within an address, and only one can be compressed.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Table 3-2 outlines the current assignment of reserved prefixes and special addresses, such as link-local addresses or multicast addresses. The major part of the address space (over 80 percent) is unassigned, which leaves room for future assignments.

Table 3-2: List of assigned prefixes
Allocation	Prefix binary	Prefix hex	Fraction of address space
Unassigned	0000 0000	::0/8	1/256
Reserved	0000 001		1/128
Global unicast	001	2000::/3	1/8
Link-local unicast	1111 1110 10	FE80::/10	1/1024
Reserved (formely Site-local unicast)	1111 1110 11	FEC0::/10* * deprecated	1/1024
Local IPv6 address	1111 110	FC00::/7
Private administration	1111 1101	FD00::/8
Multicast

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Global unicast addresses are identified by the binary prefix 001, as shown earlier in Table 3-2. RFC 4291 defines the global unicast address format as shown in Figure 3-1.

Figure 3-1: Format of the global unicast address

The global routing prefix identifies the address range allocated to a site. This part of the address is assigned by the international registry services and the Internet service providers (ISP) and has a hierarchical structure. The subnet ID identifies a link within a site. A link can be assigned multiple subnet IDs. A local administrator of a site assigns this part of the address. The interface ID identifies an interface on a subnet and must be unique within that subnet.

You may find the terms top-level aggregation identifier (TLA), next-level aggregation identifier (NLA), and site-level aggregation identifier (SLA) in certain IPv6 documents. They originate in an earlier specification (RFC 2374) and are not used anymore. The current specification has a much simpler address format and is more flexible for hierarchical allocation.

The international allocation of IPv6 addresses has been delegated to several regional registry services: ARIN (American Registry for Internet Numbers) for North America and sub-Saharan Africa; RIPE NCC (Réseau IP Européens Network Coordination Center) for Europe, the Middle East, Central Asia, and North Africa; APNIC (Asia Pacific Network Information Center) for the Asia/Pacific region; and LACNIC (Latin American and Caribbean Internet Addresses Registry) for Latin America. AfriNIC (African Network Information Center) went into operation in 2005 to cover Africa in the future.

Each of these registries has information on their site about address allocation issues, current practices, and procedures.

Several allocations have been made, as listed in Table 3-3.

Table 3-3: Current allocations
Prefix	Allocation

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

There are a number of special addresses that we need to discuss. The first part of the IPv6 address space with the prefix of 0000 0000 is reserved. Out of this prefix, special addresses have been defined as follows:

The unspecified address: The unspecified address has a value of 0:0:0:0:0:0:0:0 and is therefore also called the all-zeros address . It is comparable to 0.0.0.0 in IPv4. It indicates the absence of a valid address, and it can, for example, be used as a Source address by a host during the boot process when it sends out a request for address configuration information. If you apply the notation conventions discussed earlier in this chapter, the unspecified address can also be abbreviated as ::. It should never be statically or dynamically assigned to an interface, and it should not appear as a destination IP address or within an IPv6 routing header.
The loopback address: The IPv4 loopback address, 127.0.0.1, is probably familiar to you. It is helpful in troubleshooting and testing the IP stack because it can be used to send a packet to the protocol stack without sending it out on the subnet. With IPv6, the loopback address works the same way and is represented as 0:0:0:0:0:0:0:1, abbreviated as ::1. It should never be statically or dynamically assigned to an interface.

The next sections describe different types of addresses that have been specified to be used with different transition mechanisms. These virtual interfaces are called pseudo-interfaces . A description of the transition mechanisms can be found in Chapter 10.

Because the transition to IPv6 will be gradual, two special types of addresses have been defined for backward compatibility with IPv4. Both are described in RFC 4291:

IPv4-compatible IPv6 address: This type of address is used to tunnel IPv6 packets dynamically over an IPv4 routing infrastructure. IPv6 nodes that use this technique are assigned a special IPv6 unicast address that carries an IPv4 address in the low-order 32 bits. This address type has so far rarely been used and is deprecated in RFC 4291. New or updated implementations will no longer need to support this type of address.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

With IPv4, organizations often use IP addresses from the private range as defined in RFC 1918. The addresses reserved for private use should never be forwarded over Internet routers but should instead be confined to the organization's network. For connection to the Internet, Network Address Translation (NAT) maps internal private addresses to publicly registered IPv4 addresses.

The original IPv6 specification allocated two separate address spaces (scopes) for link- and site-local use, both identified by their prefixes. In the meantime, the site-local address has been deprecated. Too many problems arose in the application of this address. A link-local address is for use on a single link and should never be routed. It doesn't need a global prefix and can be used for autoconfiguration mechanisms, for neighbor discovery, and on networks with no routers, so it is useful for creating temporary networks. Let's say you meet your friend in a conference room and you want to share files on your computers. You can connect your computers using a wireless network or a cross-cable between your Ethernet interfaces, and you can share files without any special configuration by using the link-local address.

The replacement for site-local addresses is called unique local IPv6 unicast address , or local IPv6 address for short. It is specified in RFC 4193. These addresses are globally unique but should not be routed to the global Internet. They are designed to be used within corporate sites or confined sets of networks.

The characteristics of unique local IPv6 unicast adresses are the following:

Have a unique, global prefix, which allows for filtering at network boundaries
Allow for private connection of networks without the risk of address conflicts and the consequence of having to renumber one of the sites
Are independent of ISP
Can be used for internal communication without an Internet connection
If accidentally routed to the global Internet, no address conflicts arise
Can be used by applications just like regular Global unicast addresses

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Anycast addresses are designed to provide redundancy and load balancing in situations where multiple hosts or routers provide the same service. Anycast was not created for IPv6; it was defined in RFC 1546 in 1993 as an experimental specification to be used with IPv4. The RFC allots a special prefix for anycast, which would make an anycast address recognizable as such based on the prefix. Anycast was meant to be used for services such as DNS and HTTP. The RFC discusses possible modifications to TCP to deal with these addresses that are not globally unique.

In practice, anycast has not been implemented as it was designed to be. Often a method called shared unicast address is chosen. This method is implemented by assigning a regular unicast address to multiple interfaces and creating multiple entries in the routing table. In this case, the network and transport layer assume that it is a globally unique IP address. If it is not, the mechanism to deal with ambiguous addresses needs to be built into the application. An exception to this rule is if the application uses independent stateless request/reply transactions—for instance, DNS over UDP. The root DNS servers in the Internet are set up using shared unicast addresses. As this procedure does not require any support from the network layer, it can also be used with IPv6.

From the beginning, the IPv6 developers considered anycast to be incorporated in the network layer according to RFC 1546. No special prefix was assigned. IPv6 anycast addresses are in the same address range as global unicast addresses, and each participating interface must be configured to have an anycast address. Within the region where the interfaces containing the same anycast addresses are, each host must be advertised as a separate entry in the routing tables. If the anycast interfaces have no definable region, each anycast entry (in the worst case) has to be propagated throughout the Internet, which obviously does not scale. It is expected, therefore, that support for such global anycast addresses will be either unavailable or very restricted.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Table of Contents