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:

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.

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.

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.

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


Prefix (binary) 

Fraction of Address Space 


0000 0000 



0000 0001 


Reserved for NSAP Allocation 

0000 001 


Reserved for IPX Allocation 

0000 010 



0000 011 



0000 1 





Aggregate Global Unicast Address 









Reserved for Neutral-Interconnect-Based Unicast Addresses 













1111 0 



1111 10 



1111 110 



1111 1110 0 


Link Local Use Addresses 

1111 1110 10 


Site Local Use Addresses 

1111 1110 11 


Multicast Addresses 

1111 1111 


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:

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 






Interface ID 



Format Prefix (001) 


Top-Level Aggregation identifier 


Reserved for future use 


Next-Level Aggregation identifier 


Site-Level Aggregation identifier 


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


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


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 



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 



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 




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.

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


Organization-local scope 

Node-local scope 


Link-local scope 






Site-local scope 



Global scope 



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:

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.

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 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.

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.

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:

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.


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:

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



Uncharacterized traffic 

"Filler" traffic (for example, netnews) 

Unattended data transfer (for example, email) 


Attended bulk transfer (for example, FTP, HTTP). 


Interactive traffic (for example, telnet, X) 

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.