Section 12.1. IPv6: An Overview


12.1. IPv6: An Overview

In its infancy, what we now call the Internet was a research and development network; Chapter 1 tells the story of these early years. There was little if any expectation that this internetworking of academic, military, and corporate networks would have the phenomenal commercial success it has since enjoyed. As a result, great blocks of IP addresses were taken by universities, companies, and government organizations involved in this internetwork with the assumption that the IPv4 address space was fairly inexhaustible. The vast majority of those early address allocations were made in the United States, where most of the early research and development was taking place.

You know the rest of the story. Many university students exposed to this internetwork understood its potential and went on to build companies to exploit that potential. The World Wide Web became the first of the "killer apps" that popularized the Internet with the general public and caused an explosion of new users. Suddenly, what was once assumed to be a vast supply of available IP addresses was quickly becoming depleted. In the mid-1990s, a number of analyses predicted that based on existing allocation trends, the IPv4 address space would be used up in a few short years.

The solution to IP address exhaustion was to develop a new version of IP, with a larger address space. That solution, which was first called IPng (ng for "next generation") and eventually became IPv6, quadrupled the size of the address to 128 bits. This larger address size means an exponentially larger number of available addressesyou will see how much larger in the following section. But it was understood that a short-term solution was needed to slow IP address exhaustion while the long-term IPng was being developed. The short-term solution was to create "private" IP addresses, as defined in RFC 1918, and a mechanism that allowed many of these non-unique private addresses to share one or a few globally unique IP addresses: Network Address Translation, or NAT.

NAT and dynamic private IP addresses have become so widely accepted that they are a part of most modern networks, from small multi-computer home networks to large enterprises. And the mechanism has been so successful in slowing the depletion of IPv4 addresses that as of this writing many question the need for IPv6 in the near future. But NAT is increasingly viewed as an inhibitor to innovation in application development. Peer-to-peer applications, for example, are made more difficult if not impossible when the end systems are hidden behind NAT devices. Likewise, VoIP, security, quality-of-service, and multicast applications are more difficult when run from behind NAT. Moving NAT back to what it was originally intended to bea short-term solution to the IP address exhaustion problemand moving the IP world to IPv6 will re-energize the innovative thinking of the earlier Internet and result in new and unexpected kinds of applications.

The early push for widespread adoption of IPv6 has been in Asia, with its large consumer electronics industries. These industries, and the governments that back them, understand that to continue selling new network-enabled devices and services a large pool of readily available, globally unique IP addresses is needed. Additionally, Asia is aggressively building new Internet infrastructures. However, because large portions of the IPv4 address space were allocated in the United States in the early days of the Internet, acquiring the addresses necessary to support the burgeoning Asian Internet is increasingly difficult. In India, you can find hierarchical NAT architectures five layers deep to compensate for that lack of IP addresses.

A single fact clearly explains the Asian interest in IPv6: Some 65 percent of the total IPv4 address space has been allocated, leaving approximately 1.3 billion globally unique addresses still available. The population of the Peoples' Republic of China is also, it turns out, about 1.3 billion. So by giving a single IPv4 address to each person in China, all of the remaining IPv4 addresses would be used up.

Which is not to say that IPv4 addresses will be used up, by China, India, or anyone else. The reality is that the IPv4 address space will never be completely depleted. Can you imagine the justification required to get the last IPv4 address?

Already, stringent guidelines are in place to ensure that globally routable IPv4 addresses are not given out frivolously. If you are a service provider or enterprise network operator, you must provide careful justification for the address space you request. If you run a small business or home network, you likely have to pay your service provider for static IP addresses, if you can get them at all. As the number of available IPv4 addresses continues to shrink, they will become increasingly more difficult and expensive to obtain. It is predicted that at some point those companies and institutions that acquired a surplus of address space in the early days of the Internet will recognize their spare IPv4 addresses as a valuable commodity, and a private market for IPv4 addresses will spring up. So, this is the true driver for IPv6: a new, plentiful source of easily obtainable IP addresses.

Asian governmentsparticularly those of Japan, South Korea, Taiwan, and Chinasee IPv6 as essential to the security and continued growth of their technology-based economies. Similar interest is growing in Europe for much the same reason. And in North America, where the relative wealth of IPv4 addresses has until recently kept enthusiasm for IPv6 low, government interestparticularly from the militaryis expected to drive development of new IPv6 applications that will in turn drive commercial deployment.

This section does not come close to providing a complete treatment of IPv6. Instead, it provides a brief overview of its most important characteristics before we delve into how OSPF and IS-IS are extended to route this new version of IP.

12.1.1. IPv6 Features and Functions

The most understood feature of IPv6 is its 128-bit address size. This larger address means a total address space that is almost incomprehensibly larger than that of IPv4: some 340 trillion trillion trillion addresses, as opposed to 4.3 billion IPv4 addresses. To put the relative sizes of these two address spaces into some perspective, suppose each IPv4 and IPv6 address weighed 1 gram. If so, the entire IPv4 address space would weigh approximately one seventeenth the weight of the Empire State Building.[1] In contrast, the IPv6 address space would be 56.7 billion times the weight of planet Earth![2]

[1] According to www.gibnet.org/heavy.htm, the Empire State Building weighs 365,000 tons, or 328.5 billion grams.

[2] According to www.howstuffworks.com/question30.htm, the Earth, based on gravitational measurements, weighs 6.00e + 27 grams. My gratitude to Brian McGehee, from whom I shamelessly stole this example.

In addition to the larger address size, several significant features of IPv6 are:

  • A neighbor discovery protocol

  • The ability of nodes to statelessly autoconfigure their interface addresses

  • A simplified header format

  • The use of extension headers to add information to the header

  • Integrated authentication and encryption

Subsequent sections briefly examine each of these new features. But first, we look more closely at IPv6 address format and representation.

12.1.2. IPv6 Address Format

There are three basic types of IPv6 address, defined in RFC 3513:

  • Unicast addresses specify a single interface.

  • Multicast addresses identify a group of interfaces. A packet with a multicast destination address should be delivered to all members of the multicast group.

  • Anycast addresses also identify a group of addresses. The difference between an anycast address and a multicast address is that a packet with an anycast destination address is delivered to only one member of the groupnormally the member closest to the source. Anycast addresses are used, for example, to create redundant routers.

Unlike IPv4, IPv6 does not have a broadcast address.

Figure 12.1 shows the format of the IPv6 global unicast address. Like the IPv4 address, the IPv6 address includes a host part (identifier) and a network part (location). However, the IPv6 address format is much more rigid, making address management easier. The host part in IPv6 is called the Interface Identifier, and with few exceptions is 64 bits long. Preceding the Interface ID is the Subnet ID. Unlike IPv4, where the subnet portion of the address always uses a part of the host portion of the address and can be of variable length, the IPv6 Subnet ID is a part of the prefix and is usually 16 bits long.[3] Having a fixed 16-bit Subnet ID might seem wasteful to you. After all, only the largest networks are likely to have anything close to the 65,535 subnets this field can represent, yet if you get an IPv6 prefix you are likely to get exactly that. The rationale, like that of the Interface ID, is that the simplified manageability associated with fixed address fields is worth the tradeoff.

[3] The 16-bit subnet field is recommended by RFC 3177 for the majority of allocations. However, a 17-bit field (leaving 47 bits of prefix) might be assigned to a very large enterprise, and an allocation with no subnet ID field at all (64-bit prefix) might be assigned when only one subnet is needed.

Figure 12.1. The IPv6 global unicast address format.


The 48 bits preceding the Subnet ID is the globally unique prefix. The first 3 bits of this and other IPv6 address types make up the Format Prefix field. For currently assigned global unicast addresses, these 3 bits are always 001.

You might have seen diagrams of the global unicast IPv6 address in which the global routing prefix divided into Top-Level Aggregate (TLA), Next-Level Aggregate (NLA), and Subnet-Local Aggregate (SLA) sections. This earlier format was defined in RFC 2374, but has been obsoleted in favor of the format in Figure 12.1 in RFC 3587.

In addition to the global unicast address, which is of course globally unique, there are other scopes of uniqueness:

  • Link-local unicast addresses are unique only within the scope of a single link. Packets with link-local addresses are therefore never forwarded by routers to other links. The first 10 bits of link-local addresses are always 1111111010 (FE80::/10).

  • Site-local unicast addresses are unique only within a specified site. In this, their function is similar to that of private IPv4 addresses defined in RFC 1918. The first 10 bits of site-local addresses are always 1111111011 (FEC0::/10).[4]

    [4] At this writing, there is an argument within the IETF IPv6 working group about whether to deprecate site-local addresses, and it appears at this time that the deprecation will happen.

Figure 12.2 shows the format of an IPv6 multicast address. The first 8 bits of this address are always all 1s (FF00::/8). The next 4 bits are flags, and at present only the last flag is used. This T flag specifies whether the address is a permanently assigned ("well-known") multicast address such as those used by OSPFv3, or a transient multicast address. The next 4 bits specify the scope of the address, and the remaining 112 bits identify the multicast group.

Figure 12.2. The IPv6 multicast address format.


Anycast addresses are defined by application, rather than a format. In this, they are indistinguishable from unicast addresses. However, the node to which an anycast address is assigned must know that the address is anycast, to avoid the erroneous generation of duplicate address errors.

12.1.3. IPv6 Address Representation

IPv4 addresses, as you know, are written in four decimal segments, each representing 8 bits and separated by dots (dotted decimal). IPv6 addresses are written in eight hexadecimal segments, each segment representing 16 bits and separated by a colon. For example:

3ffe:3700:1100:0001:0210:a4ff:fea0:bc97 

Such an address is, of course, hard to write and almost impossible to remember. Fortunately, many IPv6 addresses contain strings of 0s, and there are two rules for using those strings to reduce the size of the address. The first rule is that you can leave off leading 0s in any 16-bit segment. Consider the following address:

fe80:0210:1100:0006:0030:a4ff:000c:0097 

By leaving off the leading 0s in each segment, the address can be written:

fe80:210:1100:6:30:a4ff:c:97 

Note that only the leading 0s can be "compacted." If trailing 0s were also left off, you could not tell where the 0s belong.

The second rule for compacting IPv6 addresses is that if one or more complete 16-bit segments consist entirely of 0s, you can represent one entire string with a double colon. For example, the address:

ff02:0000:0000:0000:0000:0000:0000:0001 

Can be written:

ff02::1 

An address of all 0swhich is called the unspecified address, and is used in several link-local operations such as neighbor discoverycan be represented simply as:

:: 

However, you can only use the double colon once in an address. If it is used more than once, the length of the 0 strings becomes ambiguous. Take, for instance, the following address:

2001:0000:0000:0013:0000:0000:0b0c:3701 

This can be written in one of two ways:

2001::13:0:0:b0c:3701 

Or

2001:0:0:13::b0c:3701 

But the address cannot be written like this:

2001::13::b0c:3701 

This last case is illegal because it is not clear where all the 0s go. It could represent any one of the following three addresses:

2001:0000:0000:0013:0000:0000:3701 2001:0000:0000:0000:0013:0000:3701 2001:0000:0013:0000:0000:0000:3701 

12.1.4. The Neighbor Discovery Protocol

Just as ICMP is the core maintenance protocol for IPv4, ICMPv6 (RFC 2463) is the core maintenance protocol for IPv6. Many of the functions and messages are the same between these protocols, such as:

  • Destination unreachable

  • Packet too big

  • Time exceeded

  • Parameter problem

  • Echo request

  • Echo reply

Five new messages have been defined for ICMPv6 that enable the IPv6 Neighbor Discovery Protocol (RFC 2461):

  • Router Solicitation (RS)

  • Router Advertisement (RA)

  • Neighbor Solicitation (NS)

  • Neighbor Advertisement (NA)

  • Redirect

As the names of these messages suggest, using the Neighbor Discovery Protocol a node can solicit information about a neighbor or router. A neighbor or router can also advertise unsolicited information about itself. In all cases, these messages have a link local scope and are not forwarded by any router.

Redirects are just as you understand them for IPv4, but are redefined under the Neighbor Discovery Protocol for IPv6 because IPv6 hosts build default gateway lists based on the information learned from Router Advertisements.

Neighbor Discovery also takes over functions performed by other protocols in IPv4. For example, IPv6 does not have ARP. Instead, NS and NA messages are exchanged for a similar link-layer address resolution.

The major functions performed by Neighbor Discovery are:

  • Link-layer address resolution

  • Router discovery

  • Local prefix discovery

  • Address autoconfiguration

  • Link parameter discovery

  • Next-hop determination

  • Neighbor and router reachability detection

  • Duplicate address detection

  • Redirects

Although all of these functions are of interest, most are beyond the scope of this book. The functions that are important for our discussion are address autoconfiguration and duplicate address detection, as described in the next section.

12.1.5. Stateless Address Autoconfiguration

IPv6 addresses can be configured on hosts manually, of course. But more importantly, they can be automatically configured either statefully or statelessly. Stateful address autoconfiguration happens with IPv6 just as it does with IPv4, using DHCP,[5] and is useful when you want strong control over local host address allocation. Stateless address autoconfiguration, using the Neighbor Discovery Protocol, eliminates the need for DHCP servers and simplifies mobile IP infrastructures.

[5] IPv6 uses DHCPv6, specified in RFC 3315.

A host statelessly autoconfigures its address in four steps:

1.

Determine the Interface ID (the last 64 bits of the IPv6 address).

2.

Determine the link-local IPv6 address.

3.

Determine whether there are other hosts using the derived address (duplicate address detection).

4.

Determine the global IPv6 address.

If a host's interface has a MAC address (which almost all hosts do nowadays), it uses a simple procedure called MAC-to-EUI-64 conversion to derive an Interface ID that should, in most cases, be universally unique. The MAC-to-EUI-64 conversion changes the 48-bit MAC address into a 64-bit Interface ID by inserting the 16-bit value 0xFFFE between the first three octets and the last three octets of the MAC address, and then setting the Universal/Local (U/L) bit to a value of 1 to give the address universal scope.

For example, take the MAC address:

000a:958b:3cba 

Inserting 0xFFFE into the middle, the address changes from 48 bits to 64 bits:

000a:95ff:fe8b:3cba 

The U/L bit is the seventh bit in the MAC address. Flipping that bit from 0 to 1 results in an address of:

020a:95ff:fe8b:3cba 

This is the resulting Interface ID.

Next, the host must determine its link-local address. Recall that link-local addresses always have the first 10 bits set to FE80::/10. By adding this well-known prefix to the previously derived Interface ID, the host now has its link-local address:

fe80::20a:95ff:fe8b:3cba 

The host now has an IP address that can be used to communicate with any other device on the local link. However, before going further, the host must verify that no other device on the link uses that address. Although unusual, it is possible for another interface to have the same MAC address and therefore derive the same link-local address. So, the host performs a duplicate address check. In a nutshell, the host multicasts a Neighbor Solicitation message on the link that includes its new link-local address. If another device has the same address, it responds with a Neighbor Advertisement including the disputed address. The host must now fall back to some other procedure, such as manual configuration, to solve the problem.

If the host verifies that no duplicate address exists on the link, it sends a Router Solicitation message to the well-known All-Routers multicast address FF01::2. Assuming there is at least one router on the link, that the router's interface has been configured with at least one IPv6 address, and that Neighbor Discovery Protocol has been enabled on its interface, the router will respond to the host's RS with a Router Advertisement that includes (among other things) the prefix assigned to the link. The host can then add that prefix onto its Interface ID and has a global (or perhaps site) IP address. For example, suppose the router's interface has an assigned IPv6 address of:

3ffe:2650:1200:15::116/64 

When the host receives the RA containing the 64-bit prefix, it adds the prefix to the Interface ID for a resulting IPv6 address of:

3ffe:2650:1200:15:20a:95ff:fe8b:3cba 

Neighbor Discovery has other options that allow flexibility in how the address is auto-configured. For example, the RA contains flags that allow the router to tell the host to go to a DHCP server for all its parameters, or to take the prefix from the RA but go to a DHCP server for other address parameters.

12.1.6. IPv6 Header Format

Figure 12.3 shows a side-by-side comparison of the IPv4 and IPv6 header formats.[6] The most interesting detail, and probably the first thing you noticed, is that although the IPv6 source and destination addresses are each four times as large as the IPv4 source and destination addresses, the IPv6 header is not much larger than the IPv4 header. The reason, as you can also see in Figure 12.3, is that there are fewer fields in the IPv6 header.

[6] You can read a more comprehensive coverage of the IPv6 header and extension headers in RFC 2460.

Figure 12.3. IPv4 and IPv6 headers.


The fields in the IPv6 header (not including the Address fields, which are self-explanatory) are:

Version is the same 4-bit field as in the IPv4 header, except that of course its value is 6 instead of 4.

Traffic Class is an 8-bit field that is to be used for differentiated services (DiffServ). In recent usage the bits of the IPv4 header's Type-of-Service (ToS) field have been redefined to support DiffServ. So in this regard, the IPv6 Traffic Class field can be said to correspond to the IPv4 ToS field. You can read more about DiffServ code points in RFC 2474.

Flow Label is the only field in the IPv6 header that has no similar field in IPv4. This new 20-bit field is intended to identify packets belonging to a single communication stream, so that they can forwarded differently than default best-effort service. That is, the Flow Label field is intended to enable quality-of-service (QoS) forwarding. Although there has been much discussion about how the Flow Label field might be used, as of this writing no consensus has been reached. The field might eventually be applied as is, or it might be modified in some way in the future. You can read more about the original plans for the Flow Label field in RFC 1809.

Payload Length is a 16-bit field whose value, obviously, specifies the length of the payload (in octets) encapsulated by the header. This field serves as something of a replacement for the IPv4 Header Length and Datagram Length fields, but does not correspond directly. The IPv4 Options field makes the IPv4 header variable length, so machines determine the payload length by subtracting the header length value from the datagram length (payload + header length) value. The IPv6 header, in contrast, is always a fixed length of 40 octets, so the payload length can be specified directly.

Next Header is an 8-bit field that corresponds directly to the IPv4 Protocol field. So for example, if a UDP header immediately follows the IPv6 header the next header value is 17, if OSPF the value is 89, and so on. The reason for the name change is that in IPv6 the next header is not always that of an upper-layer protocol. It might be an IPv6 extension header, as described in the next section.

Hop Limit is an 8-bit field that performs the same function as the IPv4 Time-To-live (TTL) field. The only reason for the name change is, as Christian Huitema says, for "truth in advertising." The original intention of the TTL was that as a packet is queued in a router during transport to its destination, the TTL value would be decremented once each second. The reality is that no router does this. Routers just decrement the TTL once as the packet passes through, no matter how long it is queued. If the TTL reaches 0, the packet is discarded. So the TTL value has always been a hop limit, and is named accordingly in IPv6.

Figure 12.4 illustrates the corresponding fields we have been discussing, and shows the IPv4 fields that have no directly equivalent field in the IPv6 header in gray. As you can see, those fields (in addition to the Header Length and Datagram Length fields we have already mentioned) are the Datagram ID, Flags, Fragment Offset, and Options fields.

Figure 12.4. IPv4 fields that have functionally corresponding fields in IPv6, and fields that have no equivalent function in IPv6.


Elimination of these IPv4 fields simplifies the IPv6 header, but what happens when the functions they support are needed? Datagram ID, flags, and fragment offset are needed whenever the packet is fragmented, and Options is needed for functions such as source routing and route recording. IPv6 supports these and other functions with extension headers.

12.1.7. Extension Headers

IPv6 keeps its packet header simple by including only fields that are always used.[7] When some optional function must be supported, IPv6 adds an extension header that contains whatever information the function requires. Like the IPv6 header, every extension header has a Next Header field so that multiple extension headers can be inserted between the IPv6 header and the upper-layer protocol header. Table 12.1 lists the extension headers that have been defined as of this writing, along with their assigned next header values and a description of what each header does.

[7] The flow label field is currently an exception to this, but if it ever becomes used as intended the field will need to be in the packet header for efficient processing.

Table 12.1. Defined Extension Headers for IPv6

Extension Header

NH Value

Description

Hop-by-hop options

0

Options that must be processed by every node along the forwarding path, such as Jumbo Payload and Router Alert

Destination options

60

Information to be examined either by the ultimate packet destination or by some specific node along the forwarding path

Routing

43

Source routing and route recording

Fragment

44

Information required to reassemble fragmented packets

Authentication

51

Information that allows nodes to authenticate each other before beginning communication

Encapsulating security payload (ESP)

50

Data encryption and decryption (IPSec)


Figure 12.5 illustrates the use of extension headers. The first packet shown contains no extension headersa TCP segment is encapsulated behind the IPv6 header. In this case, the value of the Next Header field in the IPv6 header is 6 (the TCP protocol number). In the second packet, the originator is using authentication. Notice that the next header value in the IPv6 header is 51, indicating that the next header is the authentication header. The authentication extension header carries an NH value of 6, indicating that the following header is TCP. In the third example, the originator is both authenticating and fragmenting the packet. Here the NH value in the IPv6 header is 44 (fragment extension header), the NH value in the fragment header is 51 (authentication), and the NH value of the authentication header is 6. In the last example, the originator is performing a route trace, so the routing extension header (NH value 43) is used. Because a route trace is the only reason for sending the packet, no other data is encapsulated. The NH of the routing header is set to 59, a value that indicates no further headers.

Figure 12.5. Extension headers, when used, are inserted between the IPv6 header and the upper-layer protocol header.


Extension headers have two distinct advantages. First, as you have seen, they allow simplification of the IPv6 header. Optional information is added to IPv6 packets only when it is needed. Second, new types of extension headers can be easily defined in the future, as new optional capabilities are needed, greatly adding to the extensibility and overall flexibility of the protocol.

IPv6 and Packet Fragmentation

Because Fragmentation extension headers have been mentioned, I want to point out another significant difference between IPv4 and IPv6. As you likely know, IPv4 packets can be fragmented by routers anywhere along the path, when a link is encountered whose MTU is smaller than the size of the packet. IPv6 discontinues this practice. It is up to the originating IPv6 node to decide whether to fragment a packet; if an IPv6 router receives a packet that is larger than the MTU of the link over which the packet must be forwarded, the router drops the packet.

A host can adhere to this new rule in two ways. First, the host can perform MTU path discovery (PD), as defined in RFC 1981. A host sends packets and watches for ICMPv6 Packet Too Big error messages. If any error messages are received, the host adjusts the packet size downward or fragments its packets until the errors are no longer received.

The second way to adhere to the new rule is to take advantage of known MTU rules. RFC 2460, Section 5, specifies that every IPv6-capable link must have an MTU of at least 1280 bytes (1500 is recommended). Knowing this, hosts that do not want to perform MTU PD can simply ensure that they do not send packets larger than 1280 bytes (by size limitation or fragmentation).





OSPF and IS-IS(c) Choosing an IGP for Large-Scale Networks
OSPF and IS-IS: Choosing an IGP for Large-Scale Networks: Choosing an IGP for Large-Scale Networks
ISBN: 0321168798
EAN: 2147483647
Year: 2006
Pages: 111
Authors: Jeff Doyle

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net