Internet Protocol Version 6 (Ipv6)

By Thomas Lee, Joseph Davies

Chapter 9 of Microsoft Windows 2000 TCP/IP Protocols and Services Technical Reference reprinted with permission from Microsoft Press. For more information, go to https://www.microsoft.com/mspress/.

ISBN: 0-7356-0556-4

Get complete details on TCP/IP and Windows 2000 with this must-have reference!

Find the in-depth technical information you need to support TCP/IP on the Windows 2000 platform with the MICROSOFT® WINDOWS 2000 TCP/IP PROTOCOLS AND SERVICES TECHNICAL REFERENCE. It steps you through TCP/IP protocols layer by layer in the OSI model, while offering details to help you handle daily connectivity tasks. Weaving concepts with practical examples, it presents a detailed picture of TCP/IP protocols and services for Windows 2000 networks and discusses how to use these protocols and services to maximize LAN/WAN performance. It includes utilities to help you monitor your network and provides expert instruction so you understand:

• The Network Access Layer: How the network architectures that Windows 2000 supports carry data in a TCP/IP network

• Internet Layer Protocols: How IP provides a reliable end-to-end delivery system for individual datagrams, both for one-to-one and for one-to-many communication

• Transport Layer Protocols: How TCP and UDP use IP to let applications running on Windows 2000–based PCs communicate with other applications and PCs, plus how TCP manages the reliable flow of data between sender and receiver

• Application Layer Protocols and Services: How Windows 2000 implements key RFC-compliant application protocols

Chapter 9 – Internet Protocol Version 6 (Ipv6)

Over the course of the evolution of the current IP version, version 4 (IPv4), the inevitable exhaustion of the address space has become increasingly apparent. While mechanisms such as Classless Inter-Domain Routing (CIDR) and the use of proxies have served to increase the longevity of IPv4, development of a larger, more flexible version of IP, version 6 (IPv6), is well underway.

In its original inception, the Internet (then ARPANET) was designed primarily to facilitate communication between research entities and military organizations. However, the extraordinary longevity and functionality of the TCP/IP protocol suite has allowed the Internet to become a communications mechanism of an enormity that couldn't have been foreseen in its early stages.

Now there are even newer arenas that require the addressing and routing capabilities that IP provides. Cellular phones, pagers, and personal digital assistants (PDAs) have become ubiquitous accessories whose nature dictates that mechanisms be available for secure, portable communication. Entertainment media such as digital television and real-time audio require similar connectivity, with the imperative of guaranteed delivery rates. Additionally, the still largely untapped area of power and device management will demand the same capabilities. The once fantastic "home of the future," with electronically controlled temperature, lighting, and gadgetry is fast approaching reality.

If these markets are to utilize IP rather than be forced into developing proprietary solutions, mechanisms will be required that aren't easily provided in IPv4. Rather than investigate methods to extend an already strapped address space with limited future potential, research has been heavily dedicated to devising a new version of IP—IPv6. To successfully meet current and future needs, the following are several key capabilities that must be addressed by this new IP version:

• First and foremost, any new IP version must be capable of coexistence and interoperability with current IP specifications. Attempts to make a sweeping conversion from one version to the next would be both unrealistic and chaotic. Therefore, IPv6 must have inherent mechanisms for communicating with both IPv4 and IPv6 hosts.

• IPv6 must support an exponentially larger address space than IPv4.

• IPv6 packets must be as lightweight as possible to facilitate transmission of IPv6 over diverse media.

• Quality of Service (QoS), or the ability to prioritize traffic and allocate bandwidth, must be built into IPv6 to accommodate functionality required by low-latency applications.

• IPv6 routing capabilities must be designed so that intermediate nodes on a path can be specified in the packets themselves, similar to IPv4's Record Route and Loose Source routing options.

• Mechanisms for secure transmission of data must be inherent in IPv6's structure.

With both an eye turned toward future needs and an awareness of past and current issues, the IETF IPv6 working group continues to work to develop a solution.

Chapter Contents

This chapter looks at the current specifications for IPv6. Related RFCs are included on the companion CD-ROM.

Microsoft Research IPv6

The most current version of the Microsoft Research IPv6 stack may be downloaded at https://www.research.microsoft.com/msripv6. This implementation runs as a separate protocol stack on both Microsoft Windows NT 4.0 and Microsoft Windows 2000. There are no plans to im.plement IPv6 for the Microsoft Windows 95 or Windows 98 operating systems at this time.

The stack currently supports the following: basic IPv6 header processing; hop-by-hop options; destination options; fragmentation and routing headers; neighbor discovery; stateless address autoconfiguration; Internet Control Message Protocol version 6 (ICMPv6); Ethernet and FDDI media; automatic and configured tunnels; IPv6 over IPv4; IPv6 to IPv4 tunneling; UDP and TCP over IPv6; correspondent node mobility; host and router functionality; and IP Security (IPSec) authentication. Version 1.3 doesn't yet support full mobility and encryption.

Also available for download at the research site are several IPv6 applications, including the following: ping6; tracert6; Test TCP 6 (ttcp6) (over both User Datagram Protocol [UDP] and TCP); File Transmission Protocol v6/File Transmission Protocol Daemon v6 (ftp6/ftpd6); wininet.dll, which adds IPv6 functionality to Microsoft Internet Explorer; multicast conferencing applications; an IPv6 FTP client; an IPv6/v4 translator; and a protocol parser for Network Monitor that allows the capture and display of IPv6 packets.

A mailing list is also available to help users keep abreast of developments in the implementation. To subscribe, send mail to listserv@list.research.microsoft.com. In the body of the mail, include the following:

subscribe msripv6-users yourfirstname yourlastname

This chapter contains the following sections:

• Introduction to IPv6 A description of IPv6 and its intended function, as well as an introduction to terminology in IPv6

• IPv6 Addressing An overview of addressing in IPv6

• IPv6 Header Format A look at header formats in IPv6

• Transition Mechanisms A brief description of the intended methodology for integration of IPv6 with current formats

This chapter doesn't cover every detail of IPv6, nor does it attempt to fully describe its integration with Windows 2000 services.

Introduction to IPv6

As RFC 2460 describes, IPv6 is the intended replacement for IPv4. It increases the size of IP addresses from 32 to 128 bits, allowing for 296 (2128-32) times the number of addresses in IPv4. This gives a total of 340,282,366,920,938,463,463,374,607,431,768,211,456 addresses, a seemingly endless supply. This increase in the address space not only provides for more hosts, but also for an expanded addressing hierarchy.

More Info IPv6 specifications are defined in RFC 2460, which can be found in the \RFC folder on the companion CD-ROM.

Packet headers have been improved by dropping some IPv4 header fields, making others optional, and utilizing extension headers. Extension headers are separate headers that, with one exception, aren't examined by any hosts on a path between the source and destination, helping to improve routing efficiency. Additionally, they allow for more flexibility in options encoding and expansion capabilities for future options.

Flow labeling is introduced in IPv6, which allows packets to be designated as belonging to a specific "flow" of traffic, thus allowing for QoS handling and bandwidth management without having to parse TCP and UDP headers. Extensions also have been introduced that allow for authentication, data integrity assurance, and optional packet encryption.

Before looking at IPv6 in detail, it's important to understand some of the basic terminology used in the protocol specifications.

Nodes, Routers, Hosts, and Interfaces

A node is any device that implements IPv6. It can be a router, which is a device that forwards packets that aren't directed specifically to it, or a host, which is a node that doesn't forward packets. An interface is the connection to a transmission medium through which IPv6 packets are sent. While a distinction is made between routers and hosts, it's possible, albeit unlikely, for a single node to have multiple interfaces, and potentially be forwarding packets addressed to other nodes on only a subset of its interfaces. Thus, this device would be acting both as a host (on its non-forwarding interfaces) and as a router (on its forwarding interfaces).

Links, Neighbors, Link MTUs, and Link Layer Addresses

A link is the medim over which IPv6 is carried. Neighbors are nodes that are connected to the same link. A link maximum transmission unit (MTU) is the maximum packet size that can be carried over a given link medium, and is expressed in octets. A Link Layer address is the "physical" address of an interface, such as media access control (MAC) addresses for Ethernet links.

Unicast, Multicast, and Anycast Addresses

In IPv6, all addressing is directed to interfaces rather than to nodes. A unicast address specifies that a packet be sent to a particular interface. A multicast address is sent to a set of interfaces, typically encompassing multiple nodes. An anycast address, while identifying multiple interfaces (and typically multiple nodes), is sent only to the interface that's determined to be "nearest" to the sender. Each of these types of addressing will be discussed in more detail later in this chapter.

Note: Unless otherwise specified, terms used in this chapter refer to IPv6.

Addressing

Text Representation of IPv6 Addresses

Perhaps the most obvious difference between IPv4 and IPv6 is the increase in the number of bits used for addressing. Instead of using 32-bit dotted-decimal notation, IPv6 uses 128-bit addressing expressed in hexadecimal format. Text depiction of these addresses might vary, with the following three acceptable representations:

• In the preferred text representation, addresses are listed as eight 16-bit hexadecimal sections, separated by colons. For example, an IPv6 address for an interface would look like:

  ABCD:EF12:3456:7890:ABCD:EF12:3456:7890

  Any field containing leading zeros doesn't need to display the leading zeros, although no field can be left blank. For example:

  1234:0:0:0:ABCD:123:45:6

• Because of the mechanisms for address allocation in IPv6, long strings of zero bits will be common. Consequently, an alternate form of address representation allows "::" to be used to represent a portion of the address containing zero bits. The "::" placeholder can be used to represent more than one section of zero bits, but may not be used more than once in an address.

  For example:

  1234:0:0:0:ABCD:0:0:123

  could be represented as:

  1234::ABCD:0:0:123

  or

  1234:0:0:0:ABCD::123

  but not

  1234::ABCD::123

• The third method of textually displaying addresses is used in environments with a mixture of IPv4 and IPv6 nodes. In this notation, the six high-order (leftmost) 16-bit sections are displayed in hexadecimal, but the remaining bits are displayed in the familiar dotted-decimal notation.

  For example, an address might appear in any of these formats:

  0:0:0:0:0:0:131.107.6.100 or

  ::131.107.6.100 (compressed format)

  0:0:0:0:0:FFFF:131.107.4.99 or

  ::FFFF:131.107.4.99 (compressed format)

  ABCD:EF:12:34:0:0:131.107.2.98 or

  ABCD:EF:12:34::131.107.2.98 (compressed format)

More Info IPv6 addressing architecture is described in detail in RFC 2373, which can be found in the \RFC folder on the companion CD-ROM.

Unicast Addresses

A variable-length field of leading bits, referred to as the Format Prefix (FP), identifies the type of address in IPv6. An FP value of 11111111 (FF) identifies an address as a multicast address. Any other value in the high-order bits identifies the address as a unicast address. Anycast addresses are taken from the unicast space, and will be discussed in the "Anycast Addresses" section of this chapter. Unicast addresses refer to a single node on the link; however, a single unicast address can be assigned to multiple interfaces on that node, provided that the interfaces are presented to upper layer protocols as a single entity. Unicast addresses can be of several types, including Aggregatable Global unicast addresses, link local unicast addresses, site local unicast addresses, and IPv6 Addresses with Embedded IPv4 Addresses.

Reserved Unicast Addresses

Currently, RFC 2373 defines two specialized reserved unicast addresses. The first is called the unspecified address. The unspecified address, 0:0:0:0:0:0:0:0, or :: in compressed format, can't be assigned to any node, nor can it be used as the source address in IPv6 packets or routing headers. Typically, it's used while nodes are initializing IPv6, and indicates that they haven't yet "learned" their own addresses. The second reserved unicast address, 0:0:0:0:0:0:0:1, or ::1 in compressed format, is the loopback address, which is used by a node to send a packet to itself—much like the loopback address of 127.0.0.1 in IPv4.

Aggregatable Global Unicast Addresses

In IPv4, under Classless Inter-Domain Routing (CIDR), ISPs (Internet Service Providers) allocate addresses in "pools." Aggregatable Global unicast addresses in IPv6 function in a similar manner, and will be used for global communication on the IPv6-enabled portion of the Internet. The format of an Aggregatable Global unicast address is shown in Figure 9-1.

More Info The format of an Aggregatable Global unicast address is defined in RFC 2374, which can be found in the RFC folder on the companion CD-ROM.

Figure 9-1: An Aggregatable Global unicast address format.

Before looking at the internal structure of an Aggregatable Global unicast address, it's important to understand the overall structure of these addresses. Aggregatable addresses will be organized into a three-tiered hierarchical structure. The top level of this hierarchy will be the Public Topology, or the portion of the address space that will be managed by entities that provide public Internet services. The Public Topology will provide a mechanism for what are referred to as long-haul transit providers and public exchanges to provide aggregates, or collections, of addresses. These providers will be responsible for providing routing that occurs outside an organization's internal corporate structure.

Because organizations maintain internal routing topologies, a portion of an aggregatable address is devoted to allowing for internal routing. This is the Site Topology portion of the address, and represents the bits that will identify internal routing paths. One of the chief advantages to this three-tiered approach to address allocation is that if a company changes long-haul transit providers, or uses multiple providers, that company won't need to obtain reassigned Site Topology addresses.

The interface identifier of an aggregatable address is the portion that identifies individual interfaces on the organization's physical links. Similar to how IPv4 addresses use network IDs and host IDs, IPv6 addresses will use Site and Interface identifiers. Table 9-1 summarizes the structure of an Aggregatable Global unicast address.

Table 9-1

Abbreviation	Field	Length	Description
FP	Format Prefix	3 bits	"001" indicates that this is an Aggregatable Global unicast address.
TLA ID	Top-Level Aggregation	13 bits	TLAs will be responsible for maintaining the upper levels of the public routing hierarchy. The use of 13 Identifier bits for these IDs allows for 8192 TLAs.
RES	Reserved	8 bits	Reserving these bits allows for the expansion of TLA and NLA fields, should future needs dictate.
NLA ID	Next-Level Aggregation Identifier	24 bits	NLAs will be used by organizations that are assigned a TLA to create an internal addressing hierarchy, and to allow transit providers to identify sites that they service. The use of 24 bits for this identifier will allow each TLA to service approximately 16 million sites if used in a flat fashion, or roughly the equivalent of the entire IPv4 address space if used hierarchically.
SLA ID	Site-Level Aggregation Identifier	16 bits	SLAs allow organizations to create an internal routing structure independent of the external public routing topologies. Approximately 65,536 internal sub-nets will be supported by the use of 16 bits for SLAs.
Interface ID	Interface Identifier	64 bits	Interface IDs must be unique to the link, might often match the Link Layer address, and actually might be assigned to multiple interfaces on a single node, thus allowing for load balancing over multiple interfaces.

Local-Use Unicast Addresses

Link-local unicast addresses, shown in Figure 9-2, are used for communication within a single link. They are used on links where no routers are present, or for purposes such as address autoconfiguration (the process by which nodes obtain an IPv6 address) and neighbor discovery (a method used for finding other nodes on a link).

Figure 9-2: Link-local unicast address format.

Site-local unicast addresses, shown in Figure 9-3, are the equivalent of IPv4 private addresses and are used for addressing and communication within a single private organization. Routers must not forward these packets outside the site where they're used.

Figure 9-3: Site-local unicast address format.

IPv6 Addresses with Embedded IPv4 Addresses

To successfully facilitate the transition from IPv4 to IPv6, mechanisms have been developed for tunneling IPv6 packets over IPv4 infrastructures. One mechanism for encoding packets allows nodes to carry an IPv4 address in the low-order bits of the IPv6 packet, which uses a specialized unicast address. This type of packet is referred to as an IPv4-compatible IPv6 address, as seen in Figure 9-4, and zeros out all fields in the interface identifier except for the 32 low-order IPv4 bits. A second type of transition packet exists to allow nodes to specify addresses for nodes that don't use IPv6 in any form, and precedes the 32 bits of the IPv4 address with "FFFF" to indicate that this is what is termed an "IPv4-mapped IPv6 address."

Figure 9-4: IPv6 with embedded IPv4 address format.

Anycast Addresses

Anycast addresses are structurally identical to other unicast addresses, and are pulled from the pool of available unicast addresses in a given organization. However, rather than being assigned to a single node, as with unicast addresses, the anycast address is assigned to a group of nodes, typically routers on the site. Each of the routers is assigned the same address, and configured to use it as an anycast address.

When a source node wishes to send a packet to this address, it uses a discovery mechanism to find the nearest node that owns the address. Thus, the source node doesn't need to have knowledge that the address is an anycast address, as subsequent communication occurs only between the source node and the nearest router configured to use the anycast address.

As RFCs 2373 and 2526 state, anycast addresses are currently subject to certain limitations as research progresses. At this time, anycast addresses can't be used as the source address in any IPv6 packet, and can be used only by routers, not by hosts. Additionally, routers are required to support the anycast addresses for each subnet to which they are connected, to ensure that a local router will receive the packet sent to an anycast address on that subnet.

Multicast Addresses

As defined in RFCs 2373 and 2375, multicast addresses are used for IPv6 multicast traffic and replace broadcast addresses in IPv6. A multicast address is assigned to a group of nodes, but unlike an anycast address, all nodes configured with the multicast address will receive packets sent to that address. A node can belong to more than one multicast group; however, no node can use a multicast address as a source address in any packet; nor can a multicast address be used in routing headers. Figure 9-5 shows the format of an IPv6 multicast address.

More Info Read about multicast addresses and IPv6 traffic in RFCs 2373 and 2375, which can be found in the \RFC folder on the companion CD-ROM.

Figure 9-5: IPv6 multicast address format.

Table 9-2 describes each of the fields in a multicast address.

Table 9-2

Abbreviation	Field	Length	Description
FP	Format Prefix	3 bits	"11111111" indicates that this is a multicast.
Flgs	Flags	4 bits	The first 3 bits of the Flags field are reserved, and must be zeroed out. If the fourth flag is "0," this indicates a permanently assigned multicast address; if it's "1," the multicast address is "transient," or not assigned by the Internet Assigned Numbers Authority (IANA).
Scop	Scope	4 bits	Scope values limit the scope of the multicast group. Values of "0" or "F" are reserved; "1" indicates a node-local scope; "2" indicates a link-local scope; "5" indicates a site-local scope; "8" indicates an organization-local scope; "E" indicates a global scope; and all other values are currently unassigned.
Group ID	Group	112 bits	This is a unique identifier for the multicast group Identifier that will accept packets sent to this address.

For example, the following multicast addresses are used to address packets to groups of routers:

FF01:0:0:0:0:0:0:2 Node-local; all routers.

This address identifies all routing interfaces on a single node.

FF02:0:0:0:0:0:0:2 Link-local; all routers.

This address identifies all routers on a link.

FFO5:0:0:0:0:0:0:2 Site-local; all routers.

This address identifies all routers in a site.

Neighbor Discovery

"Discovery" can be a misleading term, as nodes use discovery mechanisms to both advertise their presence to other nodes on the network and to determine parameters such as node location, router availability, link MTU, and address configuration. Some discovery methods are specific to the physical link type, although RFC 2461 defines general discovery mechanisms. Discovery mechanisms are often implemented as multicasts, and replace IPv4 functionality such as ARP, ICMP router discovery, Internet Group Management Protocol (IGMP), and ICMP redirect.

Router Discovery Mechanisms

Routers use discovery for a multitude of purposes. Both at regular intervals and in response to router solicitation requests, routers issue router advertisements. These advertisements can include information that informs nodes of Link Layer router addresses, link prefixes (the approximate equivalent to the IPv4 netmask), suggested hop limits, and link MTU.

By advertising its own physical address, each router enables other nodes on the network to ascertain the router's existence. Router advertising of link prefixes allows nodes to determine to which subnet they're attached, and thus to build their internal routing tables. In IPv6, packets are now decremented by hop, rather than by Time-to-Live (TTL) values. By sending suggested hop limits, a router aids nodes in determining whether a destination is reachable by a given path. Additionally, for multicasting to function correctly on a link, all nodes must use the same MTU. Router advertisements enable nodes to configure their packets correctly for the link MTU.

Using Router Advertisement, routers also can be configured for inbound load balancing. A router can have multiple interfaces to a given link. However, these interfaces can be presented as a single interface with multiple bound addresses, and the router can omit the source address in its router advertisement packets. Consequently, hosts wanting to send packets to the router would use a neighbor solicitation request to obtain a router interface's address. The router can then provide different addresses in response to requests from different hosts. All hosts will believe that they're sending packets to a single interface with multiple addresses when, in reality, the router might divide incoming traffic over all connected interfaces.

Host Discovery

Hosts use discovery mechanisms primarily as an investigative tool, although they'll also respond to requests for information regarding their own configuration. Upon initializing, a host might use discovery to query a router as to whether it should configure its address via "stateless" or "stateful" configuration. Stateful autoconfiguration is used to issue host address parameters via Dynamic Host Configuration Protocol (DHCP). As defined in RFC 2462, stateless autoconfiguration enables the host to assign itself an address, issue a discovery packet to determine if the address is being used by any other node on the link, and configure remaining link and site parameters based on the information the host received in the router advertisement packet.

More Info Stateless autoconfiguration is defined in RFC 2462, which can be found in the \RFC folder on the companion CD-ROM.

When a node wants to communicate with another node, it issues a neighbor solicitation to the solicited node multicast address of the target node requesting its Link Layer address. The source node includes its own Link Layer address in the solicitation packet so that the target node can cache the results and thus doesn't need to issue its own solicitation. In response, the target node issues a neighbor advertisement listing its own Link Layer address.

When communication between two nodes is actively occurring, each node relies on upper layer protocols to provide confirmation that packets are successfully being sent and received. If this confirmation isn't forthcoming, a node uses neighbor unreachability detection to determine if the other node is still functional by sending a unicast neighbor solicitation directly to its partner. If two-way connectivity isn't confirmed, the node will stop sending packets to the target.

More Info RFC 2463 discusses how ICMP addresses error handling in IPv6. This RFC can be found in the \RFC folder on the companion CD-ROM.

Should a node's Link Layer address change, it will issue an unsolicited multicast neighbor advertisement to announce the change to other nodes on the network. By issuing the announcement immediately, other nodes can purge cached Link Layer addresses for that node, and thus decrease the likelihood that they will attempt communication with an unreachable node.

IPv6 Header Format and Routing Mechanisms

Address information in IPv6 comprises only a portion of each packet header. The remainder of an IPv6 header contains information necessary for nodes to effectively evaluate and process each packet. Figure 9-6 shows the general format of an IPv6 header.

Figure 9-6: General format of an IPv6 header.

Table 9-3 discusses the fields in an IPv6 header.

Table 9-3

Field	Length	Description
Version	4 bits	"0110" indicates version 6.
Traffic Class	8 bits	Used to identify traffic "class," or priority, so that packets can be forwarded at different priorities to ensure QoS.
Flow Label	20 bits	Packets that belong to a specific traffic class stream are labeled to identify to which "flow" they belong.
Payload Length	16 bits	Length, in octets, of the remainder of the packet, including extension headers.
Next Header	8 bits	Identifies the type of header immediately following the IPv6 header, and uses the same values as the IPv4 protocol field (RFC 1700).
Hop Limit	8 bits	Number of links on which the packet can travel before be-ing discarded. Each forwarder decrements this field by 1.
Source Address	128 bits	Sending node's address.
Destination Address	128 bits	Target node's address, which can be the final destination, or an intermediate node.

Following the IPv6 header there can be one or more extension headers, which are used to provide additional information about the packet, such as routing information, whether the packet has been fragmented, and the next hop on the path specified by the sender. With the exception of a header called the Hop-by-Hop Options header, no node along the routing path processes these headers. Only the destination node specified in the packet (whether this is the final destination or an intermediate destination node) must evaluate and process all extension headers. Each extension header is a multiple of 8 octets long to preserve packet alignment and to allow nodes that don't need to process the extension headers to pass over them. Figure 9-7 shows the structure of an IPv6 packet containing extension headers.

Figure 9-7: IPv6 extension headers.

Packets can include all, some, or none of the extension headers in IPv6, but should always implement them in the order shown in Figure 9-7. Each extension header shouldn't occur more than once in a packet, with the exception of the Destination Options header, which can be used once to specify IP options, and used a second time to specify upper layer options. Extension headers of all types use a next-header field, which is 8 bits in length and specifies the type of header following this header. If this field contains the value "59," this indicates that there are no subsequent headers.

Hop-by-Hop Options Header

Each node along the delivery path must examine the Hop-by-Hop Options header, shown in Figure 9-8. Multiple options can be encoded in the header, must be processed in order, and define actions that occur at intermediate hops along the routing path. The 8-bit next-header field identifies the header that follows this one, as mentioned above. The header extension length field specifies the length of this extension header in octets. The option type 8-bit identifier specifies what action a node takes if the options in the packet aren't recognized by that node. As instructed by this identifier, the node can discard the packet, skip the option, and continue through the rest of the header, or send an ICMP Unrecognized Option Type message to the source address.

Figure 9-8: Hop-by-Hop Options header.

Destination Options Header

The Destination Options header is nearly identical to the Hop-by-Hop Options header, except that it's examined only by the packet's destination node and not by intermediate nodes on the path. A next-header value of 60 in the preceding header indicates the presence of the Destination Options header. Hop-by-Hop and Destination Options are identical.

Figure 9-9: Destination Options header.

Routing Header

In IPv6, a source node can list one or more stops along the packet's path. The Routing header, shown in Figure 9-10, isn't examined until the packet reaches the destination listed in the IPv6 header. This destination then examines the Routing header, processes it according to the algorithm specified in the Routing Type field, and uses the results to send the packet to the next destination address specified in the packet. The 8-bit Segments Left field specifies the number of addresses remaining to be visited, and the 32-bit Reserved field is zeroed and ignored on transmission. As the packet is sent to each node specified in the Routing header, the visited addresses are stripped from the packet and the hop count is decremented, eventually resulting in the packet reaching its final destination.

Figure 9-10: Routing header.

Fragment Header

Figure 9-11 shows the structure of an IPv6 Fragment header. IPv6 requires a minimum link MTU of 1280 octets; any links that don't support this specification must provide link-specific mechanisms for fragmentation and reassembly below the IPv6 layer. If the link MTU is at least 1280 octets, but the packet being sent is too large for this MTU, IPv6 provides its own fragmentation mechanisms. In IPv6, the source node performs the fragmentation rather than the routers. The presence of a Routing header, however, can require intermediate nodes to fragment the packet as a result of different MTUs along the path. Because each of these hops becomes the source node as it sends the packet to the next address, the node need be only concerned with the MTU of the link between itself and the destination, rather than know the MTU of all the network links. The Fragment Offset field determines packet reassembly order at the target node, and each fragmented packet is assigned a unique value in the Identification field to facilitate retransmission of lost packets. An M flag value of "0" indicates that this is the last of the fragments, and a value of "1" indicates that more fragments are to follow.

Figure 9-11: Fragment header.

Authentication Header

Authentication headers can be used alone or in conjunction with Encapsulating Security Payload (ESP) headers, and provide verification of data source and integrity. However, Authentication headers don't provide data encryption; in IPv6, this is ESP's responsibility. Authentication and ESP header formats are outlined in RFCs 2402 and 2406, and IP security is discussed in Chapter 20, "Securing IP Communications with IP Security (IPSec)." The 8-bit Payload Length field in an Authentication header specifies the length of that header in 32-bit words. The 16-bit Reserved field isn't currently used, and must be set to "0." The Security Paremeters Index (SPI) field is an arbitrary 32-bit value. In conjunction with the destination node address and security protocol negotiated between two nodes, this value uniquely identifies the packet's security association. The 32-bit Sequence Number field is incremented by 1 for each packet, and this counter isn't allowed to "roll over" without the sending and receiving nodes first establishing a new security association. The authentication data length can vary, but it must be a multiple of 32 bits and is padded when necessary to meet this requirement.

Figure 9-12: Authentication header.

Transition Mechanisms

Mechanisms for transitioning from IPv4 to IPv6 are defined in RFC 1933, and are continuing to be developed at this time. The primary goal in the transition process is a successful coexistence of the two protocol versions until such time as IPv4 can be retired if, indeed, it's ever completely decommissioned. Transition plans fall into two primary categories: dual-stack implementation, and IPv6 over IPv4 tunneling.

More Info Mechanisms for transitioning from IPv4 to IPv6 are defined in RFC 1933, which can be found in the \RFC folder on the companion CD-ROM.

Dual-Stack Implementation

The simplest method for providing IPv6 functionality allows the two IP versions to be implemented as a dual stack on each node. Nodes using the dual stack can communicate via either stack. While dual-stack nodes can use IPv6 and IPv4 addresses that are related to each other, this isn't a requirement of the implementation, so the two addresses can be totally disparate. These nodes also can perform tunneling of IPv6 over IPv4. Because each stack is fully functional, the nodes can configure their IPv6 addresses via stateless autoconfiguration or DHCP for IPv6, while configuring their IPv4 addresses via any of the current configuration methods.

IPv6 Over IPv4 Tunneling

The second method for implementing IPv6 in an IPv4 environment is by tunneling IPv6 packets within IPv4 packets. These nodes can map an IPv4 address into an IPv4-compatible IPv6 address, preceding the IPv4 address with a 96-bit "0:0:0:0:0:0" prefix. Routers on a network don't need to immediately be IPv6-enabled if this approach is used, but Domain Name System (DNS) servers on a mixed-version network must be capable of supporting both versions of the protocol. To help achieve this goal, a new record type, "AAAA," has been defined for IPv6 addresses. Because Windows 2000 DNS servers implement this record type as well as the IPv4 "A" record, IPv6 can be easily implemented in a Windows 2000 environment. For more information on DNS in Windows 2000, see Chapter 16, "Domain Name Service (DNS)."

Summary

While IPv4 will undoubtedly continue to be implemented for years to come, IPv6 provides extensibility and configuration capabilities that will provide IP functionality far beyond what is currently possible. IPv6 development continues as of this writing, but the protocol is fast approaching a completed state. When it is finally deployed on a wide scale, IPv6 will give an estimated 1500-plus unique addresses for every square meter on the planet, and may well serve to provide networking options that have previously been considered science fiction.