Chapter 1 IPv6 (Overview)

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

This chapter contains the following information:

• IPv6 Features

• IPv6 Header and Extensions

• IPv6 Addressing

• IPv6 Routing

• IPv6 Neighbor Discovery

• IPv6 Stateless Address Autoconfiguration

• IPv6 Mobility Support

• IPv6 Quality-of-Service Capabilities

• IPv6 Security Improvements

• 6to4 Tunnels Over IPv4 Networks

IPv6 Features

Changes from IPv4 to IPv6 are described in 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. In addition, IPv6 provides a greater number of addressable nodes. IPv6 also employs simpler autoconfiguration of addresses.

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

  IPv6 defines a new type of address that is called an anycast address. An anycast address identifies sets of nodes. A packet that is 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 have been made optional. This change reduces the common-case processing cost of packet handling. This change also 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 allow for more efficient forwarding. Also, the length of options has less stringent limits. The changes also provide greater flexibility for introducing new options in the future.

• Quality-of-service capabilities – This capability enables the labeling of packets that belong to particular traffic flows for which the sender requests special handling. For example, the sender can request 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 the elements appear.

Figure 1–1 IPv6 Header Format

The following list describes the function of each header field.

• Version – 4-bit Version number of Internet Protocol = 6.

• Traffic Class – 8-bit traffic class field. See Traffic Class.

• Flow Label – 20-bit field. See IPv6 Quality-of-Service Capabilities.

• Payload Length – 16-bit unsigned integer, which is the rest of the packet that follows the IPv6 header, in octets.

• Next Header – 8-bit selector. Identifies the type of header that immediately follows the IPv6 header. Uses the same values as the IPv4 protocol field. See Extension Headers.

• Hop Limit – 8-bit unsigned integer. Decremented by one 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. The intended recipient is 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 the packet arrives at its final destination. This feature is a major improvement in router performance for packets that contain options. In IPv4, the presence of any options requires the router to examine all options.

Unlike IPv4 options, IPv6 extension headers can be of arbitrary length. Also, the number of options that a packet carries are not limited to 40 bytes. This feature, plus the manner in which IPv6 options are processed, permits IPv6 options to be used for functions that are not practical in IPv4. A good example of IPv6 options 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 eight octets long. The integer multiple of eight octets retains the alignment of subsequent headers.

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. IPv6 addresses are identifiers for individual interfaces and for sets of interfaces. You can assign IPv6 addresses of all types to interfaces, rather than hosts and routers as in IPv4. Because each interface belongs to a single node, any of the interface's unicast addresses can be used as an identifier for the node. A single interface can be assigned multiple IPv6 addresses of any type.

IPv6 addresses consist of the following types: unicast, anycast, and multicast.

• Unicast addresses identify a single interface.

• Anycast addresses identify a set of interfaces. A packet that is sent to an anycast address is delivered to a member of the set.

• Multicast addresses identify a group of interfaces. A packet that is sent to a multicast address is delivered to all of the interfaces in the group.

In IPv6, multicast addresses replace broadcast addresses.

IPv6 supports addresses that are four times the number of bits as IPv4 addresses, that is, 128 in contrast to 32. Thus, the number of potential addresses is four 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. Consequently, the reduction in efficiency reduces the number of available addresses. Nonetheless, IPv6 provides enough address space for the foreseeable future.

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

Table 1–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
Reserved for 6to4 Router Address	1000 0000 0000 10

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

Approximately 15 percent of the address space is initially allocated. The remaining 85 percent 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. These addresses are similar in function to IPv4 addresses under classless interdomain routing (CIDR). The following table shows their format.

Table 1–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

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 that are 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. Use of the SLA ID field 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. The Interface ID must be unique on that link. The Interface ID can also be unique over a broader scope. In many instances, an interface identifier is the same. In many instances, an interface identifier 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. A local-use address can only be used within the subnet or within a subscriber network. These addresses are intended for use inside of a site for plug and play local communication. These addresses are also used for bootstrap operations for the use of global addresses.

The two types of local-use unicast addresses are link-local and site-local. The Link-Local-Use address is for a single data link layer medium, such as an Ethernet or Frame Relay link. The Site-Local-Use is for use on a single site. The following table shows the Link-Local-Use address format.

Table 1–3 Link-Local-Use Addresses Format

10 bits	54 bits	64 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 1–4 Site-Local-Use Addresses

10 bits	38 bits	16 bits	64 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 its domain. In most instances, the identifier uses a node's IEEE-802 48–bit address. The Subnet ID identifies a specific subnet in a site. The Subnet ID and the interface ID form a local-use address. Consequently, a large private internet can be constructed without any other address allocation.

Organizations that are not yet connected to the global Internet can use local-use addresses. Local-use addresses enable organizations to operate without the need to request an address prefix from the global Internet address space. If the organization later connects to the Internet, the Subnet ID, Interface ID, and a global prefix can be used to create a global address. For example, the organization can use the Registry ID, Provider ID, and the Subscriber ID to create a global address. This enhancement is a significant improvement over IPv4. IPv4 requires sites that use private (non-global) IPv4 addresses to manually renumber when sites 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. The address format is shown in the following table.

Table 1–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. This address 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. The address format is shown in the following table.

Table 1–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, the address belongs to different nodes. A packet that is sent to an anycast address is routed to the nearest interface that has that address.

Anycast addresses can be used as part of a route sequence. Thus, a node can select which of several Internet service providers that the node wants to carry its traffic. This capability is sometimes called source-selected policies. You implement this capability by configuring anycast addresses to identify the set of routers that belongs to Internet service providers. For example, you can configure one anycast address per Internet service provider. You can use the anycast addresses as intermediate addresses in an IPv6 routing header. Then, the packet is delivered by a particular provider. Or, the packet is delivered by a sequence of providers. You can also use anycast addresses to identify the set of routers that are attached to a particular subnet. You can also use anycast addresses to identify the set of routers that provide 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, you turn the unicast address into an anycast address. However, you must explicitly configure the nodes to which the address is assigned in order to know that the address 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 1–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 four flags: 0,0,0,T.

The high-order 3 flags are reserved. These flags must be initialized to zero.

• T=0 – Indicates a permanently assigned, well-known, multicast address. This multicast address is assigned by the global Internet authority that assigns numbers.

• 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 1–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. The only difference is 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 capabilities. The following list describes the new routing capabilities:

• Provider selection that is 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 capability by creating sequences of IPv6 addresses that use 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 instances, to reverse routes in a packet that a host receives. The packet must be successfully authenticated by using the IPv6 authentication header. The packet must contain address sequences in order to return the packet to its originator. This technique forces IPv6 host implementations to support the handling and reversal of source routes. The handling and reversal of source routes is the key that enables providers to work with hosts that implement the new features. The new features include provider selection and extended addresses.

IPv6 Neighbor Discovery

IPv6 solves a set of problems that are related to the interaction between nodes that are attached to the same link. IPv6 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 maximum transmission unit (MTU). A node also learns 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, with only the destinations's IP address.

• Next-hop determination – An algorithm determines mapping for an IP destination address into the IP address of the traffic destination neighbor. The next-hop can be a router or the destination.

• Neighbor unreachability detection – Nodes determine that a neighbor is no longer reachable. For neighbors that are used as routers, alternate default routers can be tried. For both routers and hosts, address resolution can be performed again.

• Duplicate address detection – A node determines that an address that the node 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 Internet Control Message Protocol (ICMP) packet types. One type is a pair of router solicitation and router advertisement messages. Another type is a pair of neighbor solicitation and neighbor advertisement messages. The fifth type is a redirect message. The messages serve the following purpose:

• Router solicitation – When an interface becomes enabled, hosts can send router solicitations. The solicitations request routers to generate router advertisements immediately, rather than at their next scheduled time.

• Router advertisement – Routers advertise their presence, various link parameters, and various Internet parameters. Routers advertise 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. Also, sent by a node 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 that announces its availability. A host receives router advertisements from all routers, building a list of default routers. Routers generate router advertisements frequently enough that hosts learn of their presence within a few minutes. However, routers do not advertise frequently enough to rely on an absence of advertisements to detect router failure. A separate detection algorithm that determines neighbor unreachability provides failure detection.

Router Advertisement Prefixes

Router advertisements contain a list of prefixes that is used for on-link determination. The list of prefixes is also used for autonomous address configuration. Flags that are 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. The list is used to decide when a packet's destination is on-link or beyond a router. A destination can be on-link even though the destination is not covered by any advertised on-link prefix. In such instances, a router can send a redirect. The redirect informs the sender that the destination is a neighbor.

Router advertisements, and per-prefix flags, enable 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. Optionally, router advertisement messages also contain link parameters, such as the link MTU. This feature enables centralized administration of critical parameters. The parameters can be set on routers and automatically propagated to all hosts that are attached.

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. This detection requires positive confirmation that packets that are sent to a neighbor are actually reaching that neighbor. And, that packets are 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. Data that was sent previously 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. These messages 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 previous 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 unsolicited, neighbor advertisement packets. The node can multicast to all nodes to update cached link-layer addresses that have become invalid. The sending of unsolicited advertisements is a performance enhancement only. The detection algorithm for neighbor unreachability ensures that all nodes 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 can represent multiple network interface cards as a single logical interface that has multiple link-layer addresses.

  Load balancing is handled by allowing routers to omit the source link-layer address from router advertisement packets. Consequently, neighbors must 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 that provide an equivalent service. 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. Non-override advertisements invoke specific rules to determine which of potentially multiple advertisements should be used.

• Proxy advertisements – A router that accepts packets on behalf of a target address can issue non-override neighbor advertisements. The router can accept packets for a target address that is unable to respond to neighbor solicitations. Currently, the use of proxy is not specified. However, proxy advertising can potentially be used to handle cases like mobile nodes that have moved off-link. However, the use of proxy is not intended as a general mechanism to handle nodes that do not implement this protocol.

Comparison With IPv4

The neighbor discovery protocol of IPv6 corresponds to a combination of the IPv4 protocols Address Resolution Protocol (ARP), ICMP Router Discovery, and ICMP Redirect. IPv4 does not have a generally agreed on protocol or mechanism for neighbor unreachability detection. However, host requirements do specify some possible algorithms for dead gateway detection. Dead gateway detection is a subset of the problems that neighbor unreachability detection solves.

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

• Router discovery is part of the base protocol set. Hosts do not need 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. A separate mechanism is not needed to configure the netmask.

• Router advertisements enable address autoconfiguration.

• Routers can advertise an MTU for hosts to use on the link. Consequently, all nodes use the same MTU value on links that lack 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 on 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 instances, hosts assume that destinations are off-link. Consequently, hosts send the traffic to routers. A router can then issue redirects as appropriate.

• Unlike IPv4, the recipient of an IPv6 redirect message assumes that the new next-hop is on-link. In IPv4, a host ignores redirect messages that specify 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. The redirect mechanism is useful on non-broadcast and shared media links. On these links, nodes should not check for all prefixes for on-link destinations.

• Neighbor unreachability detection improves packet delivery in the presence of failing routers. This capability improves packet delivery over partially failing or partitioned links. This capability also improves packet delivery over nodes that change their link-layer addresses. For instance, mobile nodes can move off-link without losing any connectivity because of stale ARP caches.

• Unlike ARP, neighbor discovery detects half-link failures by using neighbor unreachability detection. Neighbor discovery 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 detects dead routers and dead switches to a working router.

• By using link-local addresses to uniquely identify routers, hosts can maintain the router associations. The ability to identify routers is required for router advertisements. The ability to identify routers is required for redirect messages. Hosts need to maintain router associations if the site uses 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 Internet Control Message Protocol (ICMP) redirect messages. IPv4 off-link nodes can also send router advertisement messages.

• By placing address resolution at the ICMP layer, the protocol becomes more media independent than ARP. Consequently, standard IP authentication and security mechanisms can be used.

IPv6 Stateless Address Autoconfiguration

A host performs several steps to autoconfigure its interfaces in IPv6. The autoconfiguration process creates a link-local address. The autoconfiguration process verifies its uniqueness on a link. The process also determines which information should be autoconfigured, addresses, other information, or both. The process determines if the addresses should be obtained through the stateless mechanism, the stateful mechanism, or both mechanisms. This section describes the process for generating a link-local address. This section also describes the process for generating site-local and global addresses by stateless address autoconfiguration. Finally, this section describes the procedure for duplicate address detection.

Stateless Autoconfiguration Requirements

IPv6 defines mechanisms for both stateful address and stateless address autoconfiguration. Stateless autoconfiguration requires no manual configuration of hosts, minimal (if any) configuration of routers, and no additional servers. The stateless mechanism enables a host to generate its own addresses. The stateless mechanism uses local information as well as non-local information that is advertised by routers to generate the addresses. Routers advertise prefixes that identify the subnet or subnets that are associated with a link. Hosts generate an interface identifier that uniquely identifies an interface on a subnet. An address is formed by combining the prefix and the interface identifier. 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 that are 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 checks which addresses have been assigned to which hosts. The stateful autoconfiguration protocol allows hosts to obtain addresses and other configuration information 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 concerned with the exact addresses that hosts use. However, the addresses must be unique. The addresses must also be properly routable. The stateful approach is used when a site requires more precise control over exact address assignments. 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 experiences two distinct phases while the address is 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 becomes invalid. When the address is in a deprecated state, the use of the 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 the address. Applications that cannot switch to another address without a service disruption can use a deprecated address.

Duplicate Address Detection Algorithm

To ensure that all configured addresses are likely to be unique on a particular link, nodes run a duplicate address detection algorithm on addresses. The nodes must run the algorithm before assigning the addresses to an interface. The duplicate address detection algorithm is performed on all addresses.

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

Autoconfiguration Process

This section provides an overview of the typical steps that are performed by an interface during autoconfiguration. Autoconfiguration is performed only on multicast-capable links. Autoconfiguration 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.

A node must attempt to verify that a tentative link-local address is not already in use by another node on the link. After verification, the link-local address can be assigned to an interface. Specifically, the node sends a neighbor solicitation message that contains the tentative address as the target. If another node is already using that address, the node returns a neighbor advertisement saying that the node is using that address. If another node is also attempting to use the same address, the node also sends a neighbor solicitation for the target. The number of neighbor solicitation transmissions or retransmissions, and the delay between consecutive solicitations, are link specific. These parameters 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 instance, an administrator can supply an alternate interface identifier that overrides the default identifier. Then, the autoconfiguration mechanism can be applied by using the new, presumably unique, interface identifier. Alternatively, link-local and other addresses need to be configured manually.

After a node determines that its tentative link-local address is unique, the node assigns the address 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, the routers send router advertisements that specify what type of autoconfiguration a host should perform. If no routers are present, stateful autoconfiguration is invoked.

Routers send router advertisements periodically. However, the delay between successive advertisements is generally longer than a host that performs autoconfiguration can 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 that indicate 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 that stateless address autoconfiguration uses to generate site-local and global addresses. The stateless address and stateful address autoconfiguration fields in router advertisements are processed independently. A host can use both stateful address and stateless address autoconfiguration simultaneously. One option field that contains prefix information, the autonomous address-configuration flag, indicates whether the option even applies to stateless autoconfiguration. If the option field does apply, additional option fields contain a subnet prefix with lifetime values. These values indicate how long addresses that are created from the prefix remain preferred and valid.

Because routers generate router advertisements periodically, hosts continually receive new advertisements. Hosts process the information that is contained in each advertisement as described previously. Hosts add to the information. Hosts also refresh the information that is received in previous advertisements.

Address Uniqueness

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

To accelerate the autoconfiguration process, a host can generate its link-local address, and verify its uniqueness, while the host waits for a router advertisement. A router might delay a response to a router solicitation for a few seconds. Consequently, the total time necessary to complete autoconfiguration can be significantly longer if the two steps are done serially.

IPv6 Mobility Support

Routing is based on the subnet prefix in a packet's destination IP address. Consequently, packets that are destined for a mobile node, do not reach the node when the node is not attached to the node's home link. The home link is the link where the node's home IPv6 subnet prefix exists. In order to continue communication, a mobile node can change its IP address each time that the node moves to a new link. However, the mobile node does not maintain transport and higher-layer connections when the node changes location. Consequently, IPv6 mobility support is particularly important when recognizing that mobile computers become a significant population of the Internet in the future.

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

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

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

• The ability to handle links with partial reachability, such as typical wireless networks. However, a movement detection procedure addresses some aspects.

• Access control on a link that is being visited by a mobile node.

IPv6 Quality-of-Service Capabilities

A host can use the flow label and the traffic fields in the IPv6 header. A host uses these fields to identify those packets for which the host requests special handling by IPv6 routers. For example, the host can request 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 20-bit flow label field in the IPv6 header. A source can use this field to label those packets for which the source requests special handling by the IPv6 routers. For example, a source can request 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. Some hosts or routers do not support the functions of the flow label field. These hosts or routers are required to set the field to zero when originating a packet. Hosts or routers forward the field without changes when forwarding a packet. Hosts or routers ignore the field when receiving a packet.

What Is a Flow?

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

Active flows from a source to a destination can be multiple. Active flows can also contain traffic that is not associated with any flow. The combination of a source address and a nonzero 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 randomly, in a “pseudo” manner. New flow labels must also be chosen uniformly from the range 1 to FFFFF hex. This random allocation makes any set of bits within the flow label field suitable for use as a hash key by routers. The routers can use the hash key to look up the state that is associated with the flow.

Packets Belonging to the Same Flow

All packets that belong to the same flow must be sent with the same source address, same destination address, and same nonzero flow label. If any of those packets include a hop-by-hop options header, then the packets must be originated with the contents of the hop-by-hop options header. The next header field of the hop-by-hop options header is excluded. If any of those packets include a routing header, then the packets must be originated with the same contents in all extension headers. The same contents include all extensions before the routing header and the routing header. The next header field in the routing header is excluded. The routers or destinations are permitted, but not required, to verify that these conditions are satisfied. If a violation is detected, the violation should be reported to the source. The violation is reported by a problem message for an ICMP parameter, Code 0. The violation points to the high-order octet of the flow label field. The high-order octet is offset one octet within the IPv6 packet.

Routers are free to set up the flow-handling state for any flow. Routers do not need explicit flow establishment information from a control protocol, a hop-by-hop option, or other means. For example, when a router receives a packet from a particular source with an unknown, non-zero flow label, a router can process its IPv6 header. The router processes any necessary extension headers in the same way that the router processes extension headers with the flow label field set to zero. The routers also determine the next-hop interface. The routers might also update a hop-by-hop option, advance the pointer and addresses in a routing header, or decide how to queue the packet. The decision to queue the packet is based on the Traffic Class field of the packet. The routers can then choose to remember the results of the processing steps. Then, the routers can cache the information. The routers use the source address and 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. The routers do not need to examine all those fields. The routers can assume that the fields are unchanged from the first packet that is checked in the flow.

Traffic Class

The nodes that originate a packet must identify different classes or different priorities of IPv6 packets. The nodes use the Traffic Class field in the IPv6 header to make this identification. The routers that forward the packets also use the Traffic Class field for the same purpose.

The following general requirements apply to the Traffic Class field:

• The service interface to the IPv6 service within a node must supply the value of the Traffic Class bits for an upper-layer protocol. The Traffic Class bits must be in packets that are originated by that upper-layer protocol. The default value must be zero for all of the 8 bits.

• Nodes that support some of the Traffic Class bits or all of the Traffic Class bits can change the value of those bits. The nodes can change only the values in packets that the nodes originate, forward, or receive, as required for that specific use. Nodes should ignore and leave unchanged any bits of the Traffic Class field for which the nodes do not support a specific use.

• The Traffic Class bits in a received packet might not be the same value that is sent by the packet's source. Therefore, the upper-layer protocol must not assume that the values are the same.

IPv6 Security Improvements

The current Internet has a number of security problems. The Internet lacks effective privacy and effective authentication mechanisms beneath 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, an extension header that is called the IPv6 Authentication Header (AH), provides authentication and integrity, without confidentiality, to IPv6 datagrams. The extension is algorithm independent. The extension supports many different authentication techniques. The use of AH is proposed to help ensure interoperability within the worldwide Internet. The use of AH 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. Upper-layer protocols and upper-layer services currently lack meaningful protections. However, the placement of the header at the Internet layer helps provide host origin authentication.

The second option, an extension header that is called the IPv6 Encapsulating Security Payload (ESP), provides integrity and confidentiality to IPv6 datagrams. Though simpler than some similar security protocols, ESP remains flexible and is algorithm independent. Similar security protocols include SP3D and ISO NLSP.

IPv6 Authentication Header and IPv6 Encapsulating Security Payload are features of the new Internet Protocol Security (IPsec). For an overview of IPsec, see “IPsec (Overview)” in System Administration Guide: IP Services. For a description, of how you implement IPsec, see “Implementing IPsec Task Map” in System Administration Guide: IP Services

6to4 Tunnels Over IPv4 Networks

To better enable the transition from IPv4 to IPv6, the Solaris operating system now supports the 6to4 transition mechanism. This mechanism enables the tunneling of packets from an isolated 6to4 IPv6 site across IPv4 networks to another isolated IPv6 site. 6to4 enables you to use one global IPv4 address and derive a complete 48-bit IPv6 global prefix for your site. To obtain technical information about 6to4 routing, refer to RFC 3056, "Connection of IPv6 Domains via IPv4 Clouds".

Consider implementing 6to4 if either or both of the following conditions exist at your IPv6 site:

• Your IPv6 site does not have an IPv6 connection to the Internet.

• Your isolated IPv6 site needs to communicate with another isolated IPv6 site

In the past, isolated IPv6 sites could not communicate with other IPv6 sites. 6to4 routing enables the isolated sites to transfer packets through a tunnel over an IPv4 network. The only requirement is a boundary router with a globally unique IPv4 address for the interface that connects to the IPv4 network.

You can configure more than one interface on a router for 6to4 support, provided that the interface meets the previously mentioned requirements. You do not need to manually configure hosts for 6to4 support. On receipt of a prefix advertisement from the 6to4 router, an IPv6 host automatically reconfigures an IPv6 interface with a 6to4 address.

The router encapsulates outbound IPv6 packets in an IPv4 header. An automatic tunnel is then constructed between the 6to4 router and the destination 6to4 site, over an IPv4 network. On receipt, the remote 6to4 router decapsulates the packets. The remote 6to4 router delivers the now standard IPv6 packets to the appropriate IPv6 nodes.

The 6to4 router can also tunnel packets to a native IPv6, non-6to4 site. In this instance, the 6to4 router sets up a tunnel over an IPv4 network to a 6to4 relay router. The relay router forwards the packets to an IPv6 network.

For More Information About 6to4 Routing

Configuring 6to4 routing is a straightforward task. The next table shows where to go for 6to4 configuration tasks and technical details.

Task or Detail	For Information
To configure a 6to4 router	How to Configure a 6to4 Router
To configure a 6to4 relay router	How to Configure a 6to4 Tunnel to a 6to4 Relay Router
For 6to4 modifications to ifconfig	IPv6 Extensions to the ifconfig Utility
For information about the 6to4relay command	6to4relay Command
For details about 6to4 site topology	Participants in a 6to4 Tunnel
For details about 6to4 addressing	6to4-Derived Addressing
For detailed information about 6to4 relay routers	Considerations for Tunnels to a 6to4 Relay Router