System Administration Guide, Volume 3

Chapter 14 Overview of IPv6

The Internet Protocol, version 6 (IPv6), is a new version of Internet Protocol (IP) designed to be an evolutionary step from the current version, IPv4. It is a natural increment to IPv4. Deploying IPv6, using defined transition mechanisms, does not disrupt current operations. IPv6 adds increased address space and improves Internet functionality using a simplified header format, support for authentication and privacy, autoconfiguration of address assignments, and new quality-of-service capabilities.

IPv6 Features

The changes between IPv4 to IPv6 fall primarily into the following categories:

Expanded routing and addressing capabilities - IPv6 increases the IP address size from 32 bits to 128 bits to support more levels of addressing hierarchy, provide a much greater number of addressable nodes, and employ simpler auto-configuration of addresses.

The addition of a scope field improves the scalability of multicast routing to multicast addresses.

A new type of address, called an anycast address, is defined. It identifies sets of nodes, where a packet sent to an anycast address is delivered to one of the nodes. The use of anycast addresses in the IPv6 source route allows nodes to control the path over which their traffic flows.
Header format simplification - Some IPv4 header fields have been dropped or made optional. This reduces the common-case processing cost of packet handling and keeps the bandwidth cost of the IPv6 header as low as possible, despite the increased size of the addresses. Even though the IPv6 addresses are four times longer than the IPv4 addresses, the IPv6 header is only twice the size of the IPv4 header.
Improved support for options - Changes in the way IP header options are encoded allows for more efficient forwarding, less stringent limits on the length of options, and greater flexibility for introducing new options in the future.
Quality-of-service capabilities - A new capability is added to enable the labeling of packets belonging to particular traffic flows for which the sender requests special handling, such as non-default quality of service or real-time service.
Authentication and privacy capabilities - IPv6 includes the definition of extensions that provide support for authentication, data integrity, and confidentiality.

IPv6 Header and Extensions

The IPv6 protocol defines a set of headers, including the basic IPv6 header and the IPv6 extension headers.

Header Format

The following figure shows the elements that appear in the IPv6 header and the order in which they appear.

Figure 14-1 IPv6 Header Format

The following list describes the function of each header field.

Version - 4-bit Internet protocol version number = 6
Priority - 4-bit priority value (see "Priority")
Flow Label - 24-bit field (see "IPv6 Quality-of-Service Capabilities")
Payload Length - 16-bit unsigned integer, which is the rest of the packet following the IPv6 header, in octets
Next Header - 8-bit selector. Identifies the type of header immediately following the IPv6 header. Uses the same values as the IPv4 protocol field (see "Extension Headers").
Hop Limit - 8-bit unsigned integer. Decremented by 1 by each node that forwards the packet. The packet is discarded if Hop Limit is decremented to zero.
Source Address - 128 bits. The address of the initial sender of the packet (see "IPv6 Addressing").
Destination Address - 128 bits. The address of the intended recipient of the packet (not necessarily the recipient if an optional Routing Header is present)

Extension Headers

IPv6 includes an improved option mechanism over IPv4. IPv6 options are placed in separate extension headers that are located between the IPv6 header and the transport-layer header in a packet. Most IPv6 extension headers are not examined or processed by any router along a packet's delivery path until it arrives at its final destination. This facilitates a major improvement in router performance for packets containing options. In IPv4, the presence of any options requires the router to examine all options.

The other improvement is that, unlike IPv4 options, IPv6 extension headers can be of arbitrary length and the total amount of options carried in a packet is not limited to 40 bytes. This feature, plus the manner in which they are processed, permits IPv6 options to be used for functions that were not practical in IPv4. A good example of this is the IPv6 authentication and security encapsulation options.

To improve performance when handling subsequent option headers (and the transport protocol that follows), IPv6 options are always an integer multiple of 8 octets long so that alignment of subsequent headers is retained.

The following IPv6 extension headers are currently defined.

Routing - Extended routing (like IPv4 loose source route)
Fragmentation - Fragmentation and reassembly
Authentication - Integrity and authentication; security
Encapsulation - Confidentiality
Hop-by-Hop Option - Special options that require hop-by-hop processing
Destination Options - Optional information to be examined by the destination node

IPv6 Addressing

IPv6 addresses are 128-bits long and are identifiers for individual interfaces and sets of interfaces. IPv6 addresses of all types are assigned to interfaces, not nodes (hosts and routers). Because each interface belongs to a single node, any of that node's interfaces' unicast addresses can be used as an identifier for the node. A single interface can be assigned multiple IPv6 addresses of any type.

The three types of IPv6 addresses are: unicast, anycast, and multicast.

Unicast addresses identify a single interface.
Anycast addresses identify a set of interfaces in such a way that a packet sent to an anycast address is delivered to a member of the set.
Multicast addresses identify a group of interfaces in such a way that a packet sent to a multicast address is delivered to all of the interfaces in the group.

IPv6 has no broadcast addresses: multicast addresses took over.

IPv6 supports addresses that are four times the number of bits as IPv4 addresses (128 vs. 32). This is 4 billion times 4 billion times the size of the IPv4 address space. Realistically, the assignment and routing of addresses requires the creation of hierarchies that reduce the efficiency of address space usage, thus reducing the number of available addresses. Nonetheless, IPv6 provides enough address space to last into the foreseeable future.

The leading bits in the address specify the type of IPv6 address. The variable-length field containing these leading bits is called the format prefix (FP). The following table shows the initial allocation of these prefixes.

Table 14-1 Format Prefix Allocations


Allocation	Prefix (binary)	Fraction of Address Space
Reserved	0000 0000	1/256
Unassigned	0000 0001	1/256
Reserved for NSAP Allocation	0000 001	1/128
Reserved for IPX Allocation	0000 010	1/128
Unassigned	0000 011	1/128
Unassigned	0000 1	1/32
Unassigned	0001	1/16
Aggregate Global Unicast Address	001	1/8
Unassigned	010	1/8
Unassigned	011	1/8
Reserved for Neutral-Interconnect-Based Unicast Addresses	100	1/8
Unassigned	101	1/8
Unassigned	110	1/8
Unassigned	1110	1/16
Unassigned	1111 0	1/32
Unassigned	1111 10	1/64
Unassigned	1111 110	1/128
Unassigned	1111 1110 0	1/512
Link Local Use Addresses	1111 1110 10	1/1024
Site Local Use Addresses	1111 1110 11	1/1024
Multicast Addresses	1111 1111	1/256

The allocations support the direct allocation of aggregate global unicast addresses, local-use addresses, and multicast addresses. Space is reserved for NSAP (Network Service Access Point) addresses, IPX (Internetwork Packet Exchange Protocol) addresses, and neutral-interconnect addresses. The remainder of the address space is unassigned for future use. This remaining address space can be used for expansion of existing use (for example, additional aggregate global unicast addresses) or new uses (for example, separate locators and identifiers). Notice that anycast addresses are not shown here because they are allocated out of the unicast address space.

Approximately fifteen percent of the address space is initially allocated. The remaining 85% is reserved for future use.

Unicast Addresses

IPv6 unicast address assignment consists of the following forms:

Aggregate global unicast address
Neutral-interconnect unicast address
NSAP address
IPX hierarchical address
Site-local-use address
Link-local-use address
IPv4-capable host address

Additional address types can be defined in the future.

Aggregate Global Unicast Addresses

Aggregate global unicast addresses are used for global communication. They are similar in function to IPv4 addresses under CIDR (classless interdomain routing). The following table shows their format.

Table 14-2 Aggregate Global Unicast Addresses Format


3 bits	13 bits	8 bits	24 bits	16 bits	64 bits
FP	TLA ID	RES	NLA ID	SLA ID	Interface ID

Where:

FP	Format Prefix (001)
TLA ID	Top-Level Aggregation identifier
RES	Reserved for future use
NLA ID	Next-Level Aggregation identifier
SLA ID	Site-Level Aggregation identifier
INTERFACE ID	Interface identifier

The first 48 bits represent the public topology. The next 16 bits represent the site topology.

The first 3 bits identify the address as an aggregate global unicast address. The next field, TLA ID, is the top level in the routing hierarchy. The next 8 bits are reserved for future use. The NLA ID field is used by organizations assigned a TLA ID to create an addressing hierarchy and to identify sites.

The SLA ID field is used by an individual organization to create its own local addressing hierarchy and to identify subnets. This is analogous to subnets in IPv4 except that each organization has a much greater number of subnets. The 16 bit SLA ID field supports 65,535 individual subnets. The Interface ID is used to identify interfaces on a link. They are required to be unique on that link. They can also be unique over a broader scope. In many cases, an interface identifier is the same or is based on the interface's link-layer address.

Local-Use Addresses

A local-use address is a unicast address that has only local routability scope (within the subnet or within a subscriber network), and can have a local or global uniqueness scope. These addresses are intended for use inside of a site for plug and play local communication and for bootstrapping up to the use of global addresses.

Two types of local-use unicast addresses are defined. These are link-local and site-local. The Link-Local-Use is for use on a single link and the Site-Local-Use is for use on a single site. The following table shows the Link-Local-Use address format.

Table 14-3 Link-Local-Use Addresses Format


10 bits	`n` bits	118-`n` bits
1111111010	0	Interface ID

Link-Local-Use addresses are used for addressing on a single link for purposes such as auto-address configuration.

The following table shows the Site-Local-Use address format.

Table 14-4 Site-Local-Use Addresses


10 bits	`n` bits	`m` bits	118-(`n`+`m`) bits
1111111011	0	Subnet ID	Interface ID

For both types of local-use addresses, the interface ID is an identifier that must be unique in the domain in which it is being used. In most cases these will use a node's IEEE-802 48 bit address. The Subnet ID identifies a specific subnet in a site. The combination of the Subnet ID and the interface ID to form a local-use address allows a large private internet to be constructed without any other address allocation.

Local-use addresses allow organizations that are not yet connected to the global Internet to operate without the need to request an address prefix from the global Internet address space. If the organization later connects to the global Internet, it can use its Subnet ID and Interface ID in combination with a global prefix (for example, Registry ID + Provider ID + Subscriber ID) to create a global address. This is a significant improvement over IPv4, which requires sites that use private (non-global) IPv4 addresses to manually renumber when they connect to the Internet. IPv6 automatically does the renumbering.

IPv6 Addresses With Embedded IPv4 Addresses

The IPv6 transition mechanisms include a technique for hosts and routers to tunnel IPv6 packets dynamically under IPv4 routing infrastructure. IPv6 nodes that utilize this technique are assigned special IPv6 unicast addresses that carry an IPv4 address in the low-order 32-bits. This type of address is called an IPv4-compatible IPv6 address and its format is shown in the following table.

Table 14-5 IPv4-compatible IPv6 Address Format


80 bits	16 bits	32 bits
0000.......................................0000	0000	IPv4 Address

A second type of IPv6 address that holds an embedded IPv4 address is also defined. This address is used to represent an IPv4 address within the IPv6 address space. It is mainly used internally within the implementation of applications, APIs, and the operating system. This type of address is called an IPv4-mapped IPv6 address and its format is shown in the following table.

Table 14-6 IPv4-mapped IPv6 Address Format


80 bits	16 bits	32 bits
0000..............................0000	FFFF	IPv4 Address

Anycast Addresses

An IPv6 anycast address is an address that is assigned to more than one interface (typically belonging to different nodes), where a packet sent to an anycast address is routed to the nearest interface having that address, according to the routing protocol's measure of distance.

Anycast addresses, when used as part of a route sequence, permit a node to select which of several Internet service providers it wants to carry its traffic. This capability is sometimes called source selected policies. You implement this by configuring anycast addresses to identify the set of routers belonging to Internet service providers (for example, one anycast address per Internet service provider). You can use these anycast addresses as intermediate addresses in an IPv6 routing header, to cause a packet to be delivered by a particular provider or sequence of providers. You can also use anycast addresses to identify the set of routers attached to a particular subnet or the set of routers providing entry into a particular routing domain.

You can locate anycast addresses from the unicast address space by using any of the defined unicast address formats. Thus, anycast addresses are syntactically indistinguishable from unicast addresses. When you assign a unicast address to more than one interface, that is, turning it into an anycast address, you must explicitly configure the nodes to which the address is assigned in order to know that it is an anycast address.

Multicast Addresses

An IPv6 multicast address is an identifier for a group of interfaces. An interface can belong to any number of multicast groups. The following table shows the multicast address format.

Table 14-7 Multicast Address Format


8 bits	4 bits	4 bits	112 bits
11111111	FLGS	SCOP	Group ID

11111111 at the start of the address identifies the address as a multicast address. FLGS is a set of 4 flags: 0,0,0,T.

The high-order 3 flags are reserved and must be initialized to 0.

T=0 - Indicates a permanently assigned (well-known) multicast address, assigned by the global Internet numbering authority.
T=1 - Indicates a non-permanently assigned (transient) multicast address.

SCOP is a 4-bit multicast scope value used to limit the scope of the multicast group. The following table shows the SCOP values.

Table 14-8 SCOP Values


0	Reserved	8	Organization-local scope
1	Node-local scope	9	(unassigned)
2	Link-local scope	A	(unassigned)
3	(unassigned)	B	(unassigned)
4	(unassigned)	C	(unassigned)
5	Site-local scope	D	(unassigned)
6	(unassigned)	E	Global scope
7	(unassigned)	F	Reserved

Group ID identifies the multicast group, either permanent or transient, within the given scope.

IPv6 Routing

Routing in IPv6 is almost identical to IPv4 routing under CIDR, except that the addresses are 128-bit IPv6 addresses instead of 32-bit IPv4 addresses. With very straightforward extensions, all of IPv4's routing algorithms (such as OSPF, RIP, IDRP, IS-IS) can be used to route IPv6.

IPv6 also includes simple routing extensions that support powerful new routing functionality. These capabilities include:

Provider selection (based on policy, performance, cost, and so on)
Host mobility (route to current location)
Auto-readdressing (route to new address)

You obtain the new routing functionality by creating sequences of IPv6 addresses using the IPv6 routing option. An IPv6 source uses the routing option to list one or more intermediate nodes (or topological group) to be visited on the way to a packet's destination. This function is very similar in function to IPv4's loose source and record route option.

In order to make address sequences a general function, IPv6 hosts are required, in most cases, to reverse routes in a packet it receives (if the packet was successfully authenticated using the IPv6 authentication header) containing address sequences in order to return the packet to its originator. This approach makes IPv6 host implementations support the handling and reversal of source routes. This is the key that allows them to work with hosts that implement the new features, such as provider selection or extended addresses.

IPv6 Neighbor Discovery

IPv6 solves a set of problems related to the interaction between nodes attached to the same link. It defines mechanisms for solving each of the following problems.

Router discovery - Hosts locate routers that reside on an attached link.
Prefix discovery - Hosts discover the set of address prefixes that define which destinations are attached to the link (sometimes referred to as on-link). (Nodes use prefixes to distinguish destinations that reside on a link from those only reachable through a router.)
Parameter discovery - A node learns link parameters, such as the link MTU (maximum transmission unit), or Internet parameters, such as the hop limit value, to place in outgoing packets.
Address autoconfiguration - Nodes automatically configure an address for an interface.
Address resolution - Nodes determine the link-layer address of a neighbor (an on-link destination) given only the destinations's IP address.
Next-hop determination - Algorithm determines mapping for an IP destination address into the IP address of the neighbor to which traffic for the destination should be sent. The next-hop can be a router or the destination itself.
Neighbor unreachability detection - Nodes determine that a neighbor is no longer reachable. For neighbors used as routers, alternate default routers can be tried. For both routers and hosts, address resolution can be performed again.
Duplicate address detection - Node determines that an address it wants to use is not already in use by another node.
Redirect - A router informs a host of a better first-hop node to reach a particular destination.

Neighbor discovery defines five different ICMP (Internet Control Message Protocol) packet types: a pair of router solicitation and router advertisement messages, a pair of neighbor solicitation and neighbor advertisements messages, and a redirect message. The messages serve the following purpose:

Router solicitation - When an interface becomes enabled, hosts can send out router solicitations that request routers to generate router advertisements immediately, rather than at their next scheduled time.
Router advertisement - Routers advertise their presence together with various link and Internet parameters, either periodically, or in response to a router solicitation message. Router advertisements contain prefixes that are used for on-link determination or address configuration, a suggested hop limit value, and so on.
Neighbor solicitation - Sent by a node to determine the link-layer address of a neighbor, or to verify that a neighbor is still reachable by a cached link-layer address. Neighbor solicitations are also used for duplicate address detection.
Neighbor advertisement - A response to a Neighbor Solicitation message, node can also send unsolicited neighbor advertisements to announce a link-layer address change.
Redirect - Used by routers to inform hosts of a better first hop for a destination, or that the destination is on-link.

Router Advertisement

On multicast-capable links and point-to-point links, each router periodically multicasts a router advertisement packet announcing its availability. A host receives router advertisements from all routers, building a list of default routers. Routers generate router advertisements frequently enough that hosts will learn of their presence within a few minutes, but not frequently enough to rely on an absence of advertisements to detect router failure; a separate neighbor unreachability detection algorithm provides failure detection.

Router Advertisement Prefixes

Router advertisements contain a list of prefixes used for on-link determination or autonomous address configuration; flags associated with the prefixes specify the intended uses of a particular prefix. Hosts use the advertised on-link prefixes to build and maintain a list that is used in deciding when a packet's destination is on-link or beyond a router. A destination can be on-link even though it is not covered by any advertised on-link prefix. In such cases a router can send a redirect informing the sender that the destination is a neighbor.

Router advertisements (and per-prefix flags) allow routers to inform hosts how to perform address autoconfiguration. For example, routers can specify whether hosts should use stateful (DHCPv6) or autonomous (stateless) address configuration.

Router Advertisement Messages

Router advertisement messages also contain Internet parameters, such as the hop limit that hosts should use in outgoing packets and, optionally, link parameters such as the link MTU. This facilitates centralized administration of critical parameters that can be set on routers and automatically propagated to all attached hosts.

Nodes accomplish address resolution by multicasting a neighbor solicitation that asks the target node to return its link-layer address. Neighbor solicitation messages are multicast to the solicited-node multicast address of the target address. The target returns its link-layer address in a unicast neighbor advertisement message. A single request-response pair of packets is sufficient for both the initiator and the target to resolve each other's link-layer addresses; the initiator includes its link-layer address in the neighbor solicitation.

Neighbor Solicitation and Unreachability

Neighbor solicitation messages can also be used to determine if more than one node has been assigned the same unicast address.

Neighbor unreachability detection detects the failure of a neighbor or the failure of the forward path to the neighbor. Doing so requires positive confirmation that packets sent to a neighbor are actually reaching that neighbor and being processed properly by its IP layer. Neighbor unreachability detection uses confirmation from two sources. When possible, upper-layer protocols provide a positive confirmation that a connection is making forward progress, that is, previously sent data is known to have been delivered correctly (for example, new TCP acknowledgments were received recently). When positive confirmation is not forthcoming through such hints, a node sends unicast neighbor solicitation messages that solicit neighbor advertisements as reachability confirmation from the next hop. To reduce unnecessary network traffic, probe messages are sent only to neighbors to which the node is actively sending packets.

In addition to addressing the above general problems, neighbor discovery also handles the following situations.

Link-layer address change - A node that knows its link-layer address has been changed can multicast a few (unsolicited) neighbor advertisement packets to all nodes to update cached link-layer addresses that have become invalid. The sending of unsolicited advertisements is a performance enhancement only. The neighbor unreachability detection algorithm ensures that all nodes will reliably discover the new address, though the delay might be somewhat longer.
Inbound load balancing - Nodes with replicated interfaces might want to load-balance the reception of incoming packets across multiple network interfaces on the same link. Such nodes have multiple link-layer addresses assigned to the same interface. For example, a single network driver could represent multiple network interface cards as a single logical interface having multiple link-layer addresses.

Load balancing is handled by allowing routers to omit the source link-layer address from router advertisement packets, thereby forcing neighbors to use neighbor solicitation messages to learn link-layer addresses of routers. Returned neighbor advertisement messages can then contain link-layer addresses that differ, depending on who issued the solicitation.
Anycast addresses - Anycast addresses identify one of a set of nodes providing an equivalent service, and multiple nodes on the same link can be configured to recognize the same anycast address. Neighbor discovery handles anycasts by setting nodes to expect to receive multiple neighbor advertisements for the same target. All advertisements for anycast addresses are tagged as being non-override advertisements. This invokes specific rules to determine which of potentially multiple advertisements should be used.
Proxy advertisements - A router willing to accept packets on behalf of a target address that is unable to respond to neighbor solicitations can issue non-override neighbor advertisements. There is currently no specified use of proxy, but proxy advertising could potentially be used to handle cases like mobile nodes that have moved off-link. However, it is not intended as a general mechanism to handle nodes that, for example, do not implement this protocol.

Comparison With IPv4

The IPv6 neighbor discovery protocol corresponds to a combination of the IPv4 protocols ARP (Adress Resolution Protocol), ICMP Router Discovery, and ICMP Redirect. In IPv4 there is no generally agreed upon protocol or mechanism for neighbor unreachability detection, although host requirements do specify some possible algorithms for dead gateway detection (a subset of the problems that neighbor unreachability detection tackles).

The neighbor discovery protocol provides a multitude of improvements over the IPv4 set of protocols.

Router discovery is part of the base protocol set; there is no need for hosts to snoop the routing protocols.
Router advertisements carry link-layer addresses; no additional packet exchange is needed to resolve the router's link-layer address.
Router advertisements carry prefixes for a link; there is no need to have a separate mechanism to configure the netmask.
Router advertisements enable address autoconfiguration.
Routers can advertise an MTU for hosts to use on the link, ensuring that all nodes use the same MTU value on links lacking a well-defined MTU.
Address resolution multicasts are spread over 4 billion (2^32) multicast addresses, greatly reducing address-resolution-related interrupts on nodes other than the target. Moreover, non-IPv6 machines should not be interrupted at all.
Redirects contain the link-layer address of the new first hop; separate address resolution is not needed upon receiving a redirect.
Multiple prefixes can be associated with the same link. By default, hosts learn all on-link prefixes from router advertisements. However, routers can be configured to omit some or all prefixes from router advertisements. In such cases, hosts assume that destinations are off-link and send traffic to routers. A router can then issue redirects as appropriate.
Unlike IPv4, the recipient of an IPv6 redirect assumes that the new next-hop is on-link. In IPv4, a host ignores redirects specifying a next-hop that is not on-link, according to the link's network mask. The IPv6 redirect mechanism is analogous to the XRedirect facility. It is expected to be useful on non-broadcast and shared media links in which it is undesirable or not possible for nodes to know all prefixes for on-link destinations.
Neighbor unreachability detection is part of the base significantly improving the robustness of packet delivery in the presence of failing routers, partially failing or partitioned links, and nodes that change their link-layer addresses. For instance, mobile nodes can move off-link without losing any connectivity due to stale ARP caches.
Unlike ARP, neighbor discovery detects half-link failures (using neighbor unreachability detection) and avoids sending traffic to neighbors with which two-way connectivity is absent.
Unlike in IPv4 router discovery, the router advertisement messages do not contain a preference field. The preference field is not needed to handle routers of different stability; the neighbor unreachability detection detect dead routers and switch to a working one.
The use of link-local addresses to uniquely identify routers (for router advertisement and redirect messages) makes it possible for hosts to maintain the router associations in the event of the site renumbering to use new global prefixes.
Because neighbor discovery messages have a hop limit of 255 upon receipt, the protocol is immune to spoofing attacks originating from off-link nodes. In contrast, IPv4 off-link nodes can send both ICMP (Internet Control Message Protocol) redirects and router advertisement messages.
Placing address resolution at the ICMP layer makes the protocol more media-independent than ARP and makes it possible to use standard IP authentication and security mechanisms as appropriate.

IPv6 Stateless Address Autoconfiguration

A host takes several steps to decide how to autoconfigure its interfaces in IPv6. The autoconfiguration process includes creating a link-local address and verifying its uniqueness on a link, determining what information should be autoconfigured (addresses, other information, or both), and, in the case of addresses, whether they should be obtained through the stateless mechanism, the stateful mechanism, or both. This section describes the process for generating a link-local address, the process for generating site-local and global addresses by stateless address autoconfiguration, and the duplicate address detection procedure.

Stateless Autoconfiguration Requirements

IPv6 defines both a stateful and stateless address autoconfiguration mechanism. Stateless autoconfiguration requires no manual configuration of hosts, minimal (if any) configuration of routers, and no additional servers. The stateless mechanism allows a host to generate its own addresses using a combination of locally available information and information advertised by routers. Routers advertise prefixes that identify the subnet(s) associated with a link, while hosts generate an interface identifier that uniquely identifies an interface on a subnet. An address is formed by combining the two. In the absence of routers, a host can generate only link-local addresses. However, link-local addresses are only sufficient for allowing communication among nodes attached to the same link.

Stateful Autoconfiguration Model

In the stateful autoconfiguration model, hosts obtain interface addresses or configuration information and parameters from a server. Servers maintain a database that keeps track of which addresses have been assigned to which hosts. The stateful autoconfiguration protocol allows hosts to obtain addresses, other configuration information, or both, from a server. Stateless and stateful autoconfiguration complement each other. For example, a host can use stateless autoconfiguration to configure its own addresses, but use stateful autoconfiguration to obtain other information.

When to Use Stateless and Stateful Approaches

The stateless approach is used when a site is not particularly concerned with the exact addresses hosts use, so long as they are unique and properly routable. The stateful approach is used when a site requires tighter control over exact address assignments. Both stateful and stateless address autoconfiguration can be used simultaneously. The site administrator specifies which type of autoconfiguration to use through the setting of appropriate fields in router advertisement messages.

IPv6 addresses are leased to an interface for a fixed (possibly infinite) length of time. Each address has an associated lifetime that indicates how long the address is bound to an interface. When a lifetime expires, the binding (and address) become invalid and the address can be reassigned to another interface elsewhere. To handle the expiration of address bindings gracefully, an address goes through two distinct phases while assigned to an interface. Initially, an address is preferred, meaning that its use in arbitrary communication is unrestricted. Later, an address becomes deprecated in anticipation that its current interface binding will become invalid. While in a deprecated state, the use of an address is discouraged, but not strictly forbidden. New communication (for example, the opening of a new TCP connection) should use a preferred address when possible. A deprecated address should be used only by applications that have been using it and would have difficulty switching to another address without a service disruption.

Duplicate Address Detection Algorithm

To ensure that all configured addresses are likely to be unique on a given link, nodes run a duplicate address detection algorithm on addresses before assigning them to an interface. The duplicate address detection algorithm is performed on all addresses, independent of whether they are obtained by stateless or stateful autoconfiguration.

The autoconfiguration process specified in this document applies only to hosts and not routers. Because host autoconfiguration uses information advertised by routers, routers need to be configured by some other means. However, it is expected that routers will generate link-local addresses using the mechanism described in this document. In addition, routers are expected to pass successfully the duplicate address detection procedure on all addresses, prior to assigning them to an interface.

IPv6 Protocol Overview

This section provides an overview of the typical steps that take place when an interface autoconfigures itself. Autoconfiguration is performed only on multicast-capable links and begins when a multicast-capable interface is enabled, for example, during system startup. Nodes (both hosts and routers) begin the autoconfiguration process by generating a link-local address for the interface. A link-local address is formed by appending the interface's identifier to the well-known link-local prefix.

Before the link-local address can be assigned to an interface and used, however, a node must attempt to verify that this tentative address is not already in use by another node on the link. Specifically, it sends a neighbor solicitation message containing the tentative address as the target. If another node is already using that address, it returns a neighbor advertisement saying so. If another node is also attempting to use the same address, it sends a neighbor solicitation for the target as well. The number of neighbor solicitation transmissions or retransmissions, and the delay between consecutive solicitations, are link-specific and can be set by system management.

If a node determines that its tentative link-local address is not unique, autoconfiguration stops and manual configuration of the interface is required. To simplify recovery in this case, it should be possible for an administrator to supply an alternate interface identifier that overrides the default identifier in such a way that the autoconfiguration mechanism can then be applied using the new (presumably unique) interface identifier. Alternatively, link-local and other addresses will need to be configured manually.

After a node ascertains that its tentative link-local address is unique, it assigns it to the interface. At this point, the node has IP-level connectivity with neighboring nodes. The remaining autoconfiguration steps are performed only by hosts.

Obtaining Router Advertisement

The next phase of autoconfiguration involves obtaining a router advertisement or determining that no routers are present. If routers are present, they send router advertisements that specify what sort of autoconfiguration a host should perform. If no routers are present, stateful autoconfiguration is invoked.

Routers send router advertisements periodically, but the delay between successive advertisements are generally longer than a host performing autoconfiguration wants to wait. To obtain an advertisement quickly, a host sends one or more router solicitations to the all-routers multicast group. Router advertisements contain two flags indicating what type of stateful autoconfiguration (if any) should be performed. A managed address configuration flag indicates whether hosts should use stateful autoconfiguration to obtain addresses. An other stateful configuration flag indicates whether hosts should use stateful autoconfiguration to obtain additional information (excluding addresses).

Prefix Information

Router advertisements also contain zero or more prefix information options that contain information used by stateless address autoconfiguration to generate site-local and global addresses. It should be noted that the stateless and stateful address autoconfiguration fields in router advertisements are processed independently of one another, and a host can use both stateful and stateless address autoconfiguration simultaneously. One prefix information option field, the autonomous address-configuration flag, indicates whether or not the option even applies to stateless autoconfiguration. If it does, additional option fields contain a subnet prefix with lifetime values, indicating how long addresses created from the prefix remain preferred and valid.

Because routers generate router advertisements periodically, hosts continually receive new advertisements. Hosts process the information contained in each advertisement as described above, adding to and refreshing information received in previous advertisements.

Address Uniqueness

For safety, all addresses must be tested for uniqueness prior to their assignment to an interface. In the case of addresses created through stateless autoconfiguration, however, the uniqueness of an address is determined primarily by the portion of the address formed from an interface identifier. Thus, if a node has already verified the uniqueness of a link-local address, additional addresses created from the same interface identifier need not be tested individually. In contrast, all addresses obtained manually or by stateful address autoconfiguration should be tested individually for uniqueness. To accommodate sites that believe the overhead of performing duplicate address detection outweighs its benefits, the use of duplicate address detection can be disabled through the administrative setting of a per-interface configuration flag.

To speed up the autoconfiguration process, a host can generate its link-local address (and verify its uniqueness) in parallel with waiting for a router advertisement. Because a router might delay responding to a router solicitation for a few seconds, the total time needed to complete autoconfiguration can be significantly longer if the two steps are done serially.

IPv6 Mobility Support

Because routing is based on the subnet prefix in a packet's destination IP address, packets destined for a mobile node, host or router, do not reach the node when unattached to its home link (the link where its home IPv6 subnet prefix exists). In order to continue communication, regardless of a node's movement, a mobile node could change its IP address each time it moves to a new link. However, the mobile node would not maintain transport and higher-layer connections when it changes location. Consequently, IPv6 mobility support is particularly important when recognizing that mobile computers might account for a significant population of the Internet in the future.

IPv6 mobility support solves this problem. It enables a mobile node to move from one link to another without changing the mobile node's IP address. It accomplishes this through the assignment of an IP address to the mobile node within its home subnet prefix on its home link. This is known as the node's home address.

Thus, packets routed to the mobile node's home address reach their destination regardless of the mobile node's current point of attachment to the Internet. The mobile node can continue to communicate with other nodes (stationary or mobile) after moving to a new link.

Though IPv6 mobility support solves the problem of transparently routing packets to and from mobile nodes while away from home, it does not solve all the problems related to the use of mobile computers or wireless networks. In particular, it does not attempt to solve the following problems:

Handling links with partial reachability, such as typical wireless networks (though a movement detection procedure addresses some aspect)
Access control on a link being visited by a mobile node

IPv6 Quality-of-Service Capabilities

A host can use the flow label and the priority fields in the IPv6 header to identify those packets for which it requests special handling by IPv6 routers, such as non-default quality of service or real-time service. This important capability enables the support of applications that require some degree of consistent throughput, delay, or jitter. These types of applications are known as multi-media or real-time applications.

Flow Labels

A source can use the 24-bit flow label field in the IPv6 header to label those packets for which it requests special handling by the IPv6 routers, such as non-default quality of service or real-time service. This aspect of IPv6 is still experimental and subject to change as the requirements for flow support in the Internet become clearer. Hosts or routers that do not support the functions of the flow label field are required to set the field to zero when originating a packet, forward the field unchanged when forwarding a packet, and ignore the field when receiving a packet.

What Is a Flow?

A flow is a sequence of packets sent from a particular source to a particular (unicast or multicast) destination for which the source desires special handling by the intervening routers. The nature of that special handling might be conveyed to the routers by a control protocol, such as a resource reservation protocol, or by information within the flow's packets themselves, for example, in a hop-by-hop option.

Active flows from a source to a destination can be multiple and can contain traffic that is not associated with any flow. The combination of a source address and a non-zero flow label uniquely identifies a flow. Packets that do not belong to a flow carry a flow label of zero.

The flow's source node assigns a flow label to a flow. New flow labels must be chosen (pseudo-)randomly and uniformly from the range 1 to FFFFFF hex. This random allocation makes any set of bits within the flow label field suitable for use as a hash key by routers for looking up the state associated with the flow.

Packets Belonging to the Same Flow

All packets belonging to the same flow must be sent with the same source address, same destination address, and same non-zero flow label. If any of those packets includes a hop-by-hop options header, then they must all be originated with the same hop-by-hop options header contents (excluding the next header field of the hop-by-hop options header). If any of those packets includes a routing header, then they must all be originated with the same contents in all extension headers up to and including the routing header (excluding the next header field in the routing header). The routers or destinations are permitted, but not required, to verify that these conditions are satisfied. If a violation is detected, it should be reported to the source by an ICMP parameter problem message, Code 0, pointing to the high-order octet of the flow label field (that is, offset 1 within the IPv6 packet).

Routers are free to opportunistically set up the flow-handling state for any flow, even when no explicit flow establishment information has been provided to them from a control protocol, a hop-by-hop option, or other means. For example, upon receiving a packet from a particular source with an unknown, non-zero flow label, a router can process its IPv6 header and any necessary extension headers as if the flow label were zero. That processing would include determining the next-hop interface, and possibly other actions, such as updating a hop-by-hop option, advancing the pointer and addresses in a routing header, or deciding how to queue the packet based on its Priority field. The router can then choose to remember the results of those processing steps and cache that information, using the source address plus the flow label as the cache key. Subsequent packets with the same source address and flow label can then be handled by referring to the cached information rather than examining all those fields that, according to the requirements of the previous paragraph, can be assumed unchanged from the first packet seen in the flow.

Priority

The 4-bit priority field in the IPv6 header enables a source to identify the desired delivery priority of its packets, relative to other packets from the same source. The priority values are divided into the following two ranges:

Values 0 through 7 specify the priority of traffic for which the source provides congestion control, that is, traffic that backs off in response to congestion, such as TCP traffic.
Values 8 through 15 specify the priority of traffic that does not back off in response to congestion, for example, real-time packets being sent at a constant rate.

For congestion-controlled traffic, the priority values are recommended for particular application categories. The following table shows the priority values.

Table 14-9 Priority Values


Priority	Meaning
0	Uncharacterized traffic
1	"Filler" traffic (for example, netnews)
2	Unattended data transfer (for example, email)
3	(Reserved)
4	Attended bulk transfer (for example, FTP, HTTP).
5	(Reserved)
6	Interactive traffic (for example, telnet, X)
7	Internet control traffic (for example, routing protocols, SNMP)

For non-congestion-controlled traffic, you should use the lowest priority value (8) for those packets that the sender is most willing to have discarded under conditions of congestion (for example, high-fidelity video traffic). You should use the highest value (15) for those packets that the sender is least willing to have discarded (for example, low-fidelity audio traffic). There is no relative ordering implied between the congestion-controlled priorities and the non-congestion-controlled priorities.

IPv6 Security Improvements

The current Internet has a number of security problems and lacks effective privacy and authentication mechanisms below the application layer. IPv6 remedies these shortcomings by having two integrated options that provide security services. You can use these two options either individually or together to provide differing levels of security to different users. Different user communities have different security needs.

The first option, and extension header called the IPv6 Authentication Header, provides authentication and integrity (without confidentiality) to IPv6 datagrams. While the extension is algorithm-independent and supports many different authentication techniques, the use of keyed MD5 is proposed to help ensure interoperability within the worldwide Internet. This eliminates a significant class of network attacks, including host masquerading attacks. When using source routing with IPv6, the IPv6 authentication header becomes important because of the known risks in IP source routing. Its placement at the Internet layer helps provide host origin authentication to those upper layer protocols and services that currently lack meaningful protections.

The second option, an extension header called the IPv6 Encapsulating Security Header, provides integrity and confidentiality to IPv6 datagrams. Though simpler than some similar security protocols (for example, SP3D, ISO NLSP), it remains flexible and algorithm-independent. To achieve interoperability within the global Internet, DES CBC is being used as the standard algorithm for use with the IPv6 Encapsulating Security Header.

The IPv6 Authentication Header and IPv6 Encapsulating Security Header are features of the new Internet Protocol Security (IPsec). For an overview of IPsec, see Chapter 18, Overview of IPsec. For a description of how you implement IPsec, see Chapter 19, Implementing IPsec.