DOC HOME SITE MAP MAN PAGES GNU INFO SEARCH PRINT BOOK
 
Introducing the Internet protocols

Internet Protocol version 6 (IPv6)

Internet Protocol version 6 (IPv6) represents the latest evolution of the Internet Protocol from version 4 (IPv4). While IPv4 has allowed the development of a global Internet, its future is limited by two factors:

To summarize, even if IPv4 routing could be scaled up, the Internet will eventually run out of network numbers.

IPv6 extends the maximum number of Internet addresses by using 128-bit addressing. Such a large address space should be able to handle the ever-increasing number of Internet addresses well into the future. As both IPv4 and IPv6 protocols may coexist on the same network, an orderly migration from IPv4 to IPv6 may be made without seriously disrupting an operational network.

Finally, IPv6 has been designed to provide the additional benefits over IPv4 of simplified packet header processing and improved option support.

IPv6 address notation

IPv6 addresses consist of eight 16-bit words, that together form a single 128-bit address. For comparison, IPv4 addresses consist of four 8-bit words resulting in a 32-bit address. The increased size of the IPv6 address greatly increases the number of available IP addresses.

The standard notation for IPv6 addresses is to represent the address as eight 16-bit hexadecimal words, each separated by a ``:'' (colon), for example: 

2EDC:BA98:0332:0000:CF8A:000C:2154:7313
This notation is capable of some simplification. It is not necessary to specify the leading zeros of a word, provided that there is at least one numeric value in each field of the address. The above address could also be written as: 
2EDC:BA98:332:0:CF8A:C:2154:7313.
As a large number of IPv6 addresses contain multiple words with value 0, the notation ``::'' can be used to represent a single contiguous group of zero-value words within the address. Some examples are shown below: 
   3762:0:0:0:0:B03:1:AF18            3762::B03:1:AF18
   2EDC:BA98:332:0:CF8A:C:2154:7313   2EDC:BA98:332::CF8A:C:2154:7313
   FF02:0:0:0:0:1:FF54:7313           FF02::1:FF54:7313
   FF0E:0:0:0:0:0:0:101               FF0E::101
   0:0:0:0:0:0:0:1                    ::1
   0:0:0:0:0:0:0:0                    ::

NOTE: ``::'' can only be used once in an address.

IPv4 addresses that are encapsulated within IPv6 addresses can be represented using the original IPv4 dot (.) notation, for example: 

0:0:0:0:0:0:172.32.67.15
0:0:0:0:0:FFFF:172.32.67.15
Using compressed notation, these addresses would be represented as: 
::172.32.67.15
::FFFF:172.32.67.15

IPv4-mapped IPv6 addresses

In previous releases of UnixWare, the IPv6 implementation was implemented within the networking libraries over an IPv4 network stack. This meant that any IPv6 address had to be able to be mapped directly onto an IPv4 address. This is achieved using an ``IPv4-mapped IPv6 address'' with the following format: 

   0000:0000:0000:0000:0000:FFFF:x1.a2x.x3.x4
which may be written in compressed form as: 
   ::FFFF:x1.x2.x3.x4
where x1.x2.x3.x4 is a valid IPv4 address. The 0000:0000:0000:0000:0000:FFFF: part was prefixed or removed by a library routine to simulate the use of IPv6 addresses. No IPv6 addresses actually passed through the network layer.

In UnixWare 7 Release 7.2, the networking stack supports both IPv4 and IPv6, and frames containing both types of datagram may be transmitted across the same physical network. IPv4-mapped IPv6 addresses allow IPv6 applications on Release 7.2 systems to service requests from both IPv4 and IPv6 hosts coexisting on the same network.

NOTE: The server system must be configured with both IPv4 and IPv6 addresses. The IPv6 address can either be an IPv4-mapped IPv6 address or it can be a real IPv6 address.

All applications that use an IPv6 listening socket bound to the IPv6 wildcard address (::) will be able to respond to requests from both IPv4 and IPv6 systems on the same network. If the source address was from a system with an IPv4 address, this will be automatically converted to an IPv4-mapped IPv6 address when a connection is accepted. The stack, not the library, handles all necessary conversion between IPv4-mapped IPv6 and IPv4 addresses for transmission on the network. ``Operation of an IPv6 server on a dual-stack host'' illustrates how the kernel handles incoming requests to a server process that is listening on an IPv6 listening socket.

Operation of an IPv6 server on a dual-stack host

NOTE: A server application that uses an IPv4 listening socket can only respond to requests from clients with IPv4 addresses.

When an application on a dual-stack host opens a TCP socket or sends a UDP datagram, the form of the destination address determines whether an IPv4 or an IPv6 datagram is sent over the network, as illustrated in ``Operation of a dual-stack host for outgoing datagrams''.

Operation of a dual-stack host for outgoing datagrams

IPv4-compatible IPv6 addresses

IPv4-compatible IPv6 addresses are IPv4 addresses represented in IPv6 format, padded with nulls in the high-order words: 

   0000:0000:0000:0000:0000:0000:x1.x2.x3.x4
which may be written in compressed form as: 
   ::x1.x2.x3.x4
where x1.x2.x3.x4 is a valid IPv4 address. This form of address may be used by IPv6 systems that need to communicate, but which are separated by routers or gateways which cannot route IPv6 datagrams. The stack on the transmitting system encapsulates the IPv6 datagram by prepending an IPv4 header to create a IPv4 datagram. This allows IPv6 datagrams can be ``tunneled'' over existing unmodified IPv4 networks and routers.

NOTE: Currently, Release 7.2 only supports host-to-host automatic tunneling. See ``Tunneling'' for more details.

Expanded routing and addressing

IPv6 increases the IP address size from 32 bits to 128 bits. This allows it to support nested levels of addressing hierarchy, a much greater number of addressable hosts, and simple autoconfiguration of addresses.

IPv6 has three types of addresses (defined in RFC 2373):

Autoconfiguration

Mechanisms that allow a node to boot up and start communicating with other nodes over an IPv4 network include static configuration, RARP, BOOTP, and DHCP. These work fairly well, but each has its drawbacks. Static configuration makes it difficult to change addresses, RARP does not supply other useful configuration information, and RARP, BOOTP and DHCP all require that the host broadcast and are dependent on a remote server.

IPv6 introduces the concept of ``link-local scope'' to IP addresses. This allows a host to construct a valid address from the predefined ``link-local prefix'' and its local identifier. The local identifier is typically derived from the medium access control (MAC) address of the interface to be configured. Using this address, the node can multicast rather than broadcast to a server. For a fully-isolated subnet, a host may not need any other address configuration.

Meaningful addresses

With IPv4, the only generally recognizable meaning in addresses are broadcast (typically all 1's or all 0's), and classes (for example, class D is multicast). With IPv6, the prefix can be quickly examined to determine scope (for example, link-local), multicast versus unicast, and a mechanism of assignment (provider-based, geography-based, and so on).

Routing information may be explicitly loaded into the upper bits of addresses as well, but this has not yet been finalized by the IETF (for provider-based addresses, routing information is implicitly present in the address).

Duplicate address detection

When an interface is initialized or reinitialized, it uses autoconfiguration to associate a tentative link-local address with that interface (the address is not yet assigned to that interface in the traditional sense). At this point, the interface joins the all-nodes and solicited-nodes multicast groups, and sends a neighbor discovery message to these groups. By using the multicast address, the node can determine whether the link-local address has been previously assigned. If necessary, it can choose an alternative address. This reduces the chance of the common error in network management of assigning the same address to two different interfaces on the same sunbet. However, it is still possible to create duplicate global-scope addresses for nodes that are not on the same subnet.

Neighbor Discovery

The Neighbor Discovery Protocol (NDP) for IPv6 is used by nodes (hosts and routers) to determine the link-local addresses for neighbors known to reside on attached subnets. and maintain per-destination routing tables for active connections. Hosts also use Neighbor Discovery to find neighboring routers that are willing to forward packets on their behalf and detect changed link-local addresses. NDP uses the Internet Control Message Protocol version 6 (ICMPv6) which has its own unique message types. In general terms, NDP corresponds to a combination of the IP v4 Address Resolution Protocol (ARP), ICMP Router Discovery (RDISC), and ICMP Redirect (ICMPv4), but with many improvements over these IPv4 protocols.

Stateless address autoconfiguration

IPv6 defines both 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 subnets associated with a network, while hosts generate an interface token that uniquely identifies an interface on a subnet. An address is formed by combining the two. In the absence of routers, a host can only generate link-local addresses. However, link-local addresses are sufficient for allowing communication among nodes attached to the same subnet.

Routing simplification

To simplify routing, IPv6 addresses may be broken into two components: a prefix and an ID. This may not seem any different to the IPv4 net-host address scheme, but it does offer two advantages:

``Aggregatable global unicast IPv6 address format (RFC 2374)'' illustrates how RFC 2374 breaks the globally used IPv6 address format into several hierarchical divisions.

Aggregatable global unicast IPv6 address format (RFC 2374)

The address has the following components:


001
The standard 3-bit format prefix for aggregatable global unicast IPv6 addresses. This means that all such addresses start with hexadecimal values in the range 20 through 3F.

TLA ID
Top-level aggregation identifier assigned by the Internet Assigned Numbers Authority (IANA; http://www.iana.org/) to the Regional Internet Registries (RIRs; http://www.arin.net/, http://www.apnic.net/, and http://www.rice.net/). The TLA will be used to divide the address space into geographical regions and major subdivisions of these such as countries, states, and broad organizational types. Routers at the top level will have a routing table entry for every active TLA ID as well as additional lower-level entries for their TLA. This field has room for 2^13 or 8,192 TLA IDs.

NLA ID
Next-level aggregation identifier assigned by the RIRs to service providers and large organizations. The NLA will be used to divide the address space selected by a TLA ID between Internet service providers (ISPs) and individual large organizations such as governments and multinational companies. This field has room for 2^24 or over 16 million NLA IDs per TLA ID. The first 8 bits of this 32-bit field are reserved for future expansion.

SLA ID
Site-level aggregation identifier assigned within an organization. The SLA allows each site to allocate up to 2^16 or 65,536 subnets per NLA ID. Organizations that require additional subnets can achieve this by aggregating ranges of NLA IDs. The fixed length (48 bits) of the aggregated prefix to an SLA ID allows a degree of flexibility when moving between ISPs, or when making a site accessible via several different ISPs.

Interface ID
Identifies an individual interface on a system. If a LAN interface (with a hardware MAC address) is automatically configured with an IPv6 address, the interface ID is formed from an IEEE EUI-64 64-bit global identifier:

  1. A 48-bit MAC address of the form cccccceeeeee, where cccccc and eeeeee are hexadecimal strings, is transformed by inserting the string FFFE to produce an EUI-64 address with the format ccccccFFFEeeeeee.

    This step does not change the hardware address if it was already in EUI-64 form.

  2. The EUI-64 address is transformed by setting bit 7 (the universal/local bit) to 1 to indicate local rather than global scope. This effectively adds 2 to the first hexadecimal digit.

For example, the 48-bit MAC address 00A0244BEA8C becomes 00A024FFFE4BEA8C in EUI-64 format. Setting bit 7 to 1 produces the value 20A024FFFE4BEA8C which corresponds to the interface ID 20A0:24FF:FE4B:EA8C when written in IPv6 notation.

Interface IDs for nodes without hardware addresses (such as PPP link endpoints) must either be statically configured in software, assigned randomly, or assigned dynamically from a pool of available IDs.

The format prefix, TLA ID, and NLA ID define the location of an address within the public topology of the IPv6-based Internet. The SLA ID defines the topology of an organization's subnetworks, although, in practice, a service provider may only make part of this space available to an individual site depending on the requirements of the organization. The first 64 bits always define the network portion of an aggregatable global unicast IPv6 address, and the final 64 bits always define the host portion. The boundary between these does not move as is the case with IPv4 addresses.

Header format simplification

IPv6 simplifies the IP header by moving some IPv4 fields to an extension header or by removing other fields entirely. It also defines a more flexible format for optional information (extension headers). The format of an IPv6 header is illustrated in ``IPv6 header format''.

IPv6 header format

Specifically, IPv6 omits the following fields:

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

Another improvement is that IPv6 extension headers, unlike IPv4 options, can be of arbitrary length and the total amount of options that a packet carries is not limited to 40 bytes. This feature, and the manner in which it is processed, permit IPv6 options to be used for functions that were not practical in IPv4, such as the IPv6 Authentication and Security Encapsulation options.

By using extension headers, instead of a protocol specifier and options fields, newly defined extensions can be integrated more easily into IPv6.

Following are some example IPv6 extension headers defined in current specifications:

Improved quality-of-service and traffic control

While quality of service can be controlled by using a control protocol such as RSVP, IPv6 uses the priority field in the IP header to provide an explicit priority definition. A node can set this value to indicate the relative priority of a particular packet or set of packets. The node, routers, or the destination host can use the value to decide what to do with the packet, such as letting it pass or dropping it.

IPv6 specifies priorities for congestion-controlled and non-congestion-controlled traffic. No relative ordering is implied between the two types.

Congestion-controlled traffic is defined as traffic that responds to congestion through a ``back-off'' or other limiting algorithm. Priorities for congestion-controlled traffic are:


0
uncharacterized traffic

1
``filler'' traffic such as netnews

2
unattended data transfer such as electronic mail

3
reserved

4
attended bulk transfer such as FTP

5
reserved

6
interactive traffic such as telnet

7
control traffic such as routing protocols

Non-congestion-controlled traffic is defined as traffic that responds to congestion by dropping (or simply not resending) packets. Examples are video, audio, or other real-time traffic. The ordering or the priority values is similar to that for congestion-controlled traffic with the lowest and highest values being used for traffic that the source is most and least willing to have discarded respectively.

Priority control is only applied to traffic from a particular source address. For example, control traffic from one address does not have a higher priority than attended bulk transfer from a different address.

Flow labeling

Besides basic prioritization of traffic, IPv6 defines a mechanism for specifying a packet flow. A flow is defined as 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.

Flow identification may be used for priority control, and it can also be used for any number of other controls.

The randomly chosen flow label does not identify any characteristic of the traffic other than the flow to which it belongs. This means that a router cannot determine the purpose of a packet (for example, one used by FTP) by reading the flow label. The router will, however, be able to determine that the packet forms part of the same sequence of packets as the previous packet that had the same label.

NOTE: There are currently no standards for the use and control of traffic class priorities and flow labels. Their use is experimental and will remain so until IPv6 is widely deployed.

Jumbograms

An IPv4 packet size is limited to 64KB. Using the jumbo payload extension header, an IPv6 packet can be up to 2^32 octets (4GB) long.

Tunneling

The key to successful transition from IPv4 to IPv6 is to preserve compatibility with the existing installed base of IPv4 hosts and routers. Maintaining compatibility with IPv4 while deploying IPv6 will make the task of transitioning the Internet to IPv6 much easier.

In most cases, the IPv6 routing infrastructure will evolve over time. While the IPv6 infrastructure is being deployed, the existing IPv4 routing infrastructure can remain functional, and it can be used to carry IPv6 traffic. Tunneling allows the existing IPv4 routing infrastructure to carry IPv6 traffic.

Dual-stack hosts and routers (that support both IPv4 and IPv6) can tunnel IPv6 datagrams over regions of IPv4 routing topology by encapsulating the IPv6 datagrams within IPv4 packets. Tunneling can be used in a variety of ways:


host-to-host
Dual-stack hosts that are interconnected by an IPv4 infrastructure can tunnel IPv6 packets between themselves. In this case, the tunnel spans the entire end-to-end path that the packet takes.

In Release 7.2 the Simple Internet Transition (SIT) mechanism (see RFC 1933) is used to implement such host-to-host connections. The sit interface implements the SIT mechanism.


host-to-router
Dual-stack hosts can tunnel IPv6 packets to an intermediary dual-stack router that is reachable through an IPv4 infrastructure. This type of tunnel spans the first segment of the packet's end-to-end path.

router-to-router
Dual-stack routers interconnected by an IPv4 infrastructure can tunnel IPv6 packets between themselves. In this case, the tunnel spans one segment of the end-to-end path that the IPv6 packet takes.

router-to-host
Dual-stack routers can tunnel IPv6 packets to their final destination dual-stack host. This tunnel spans only the last segment of the end-to-end path.

Tunneling techniques are usually classified according to the mechanism by which the encapsulating node determines the address of the node at the end of the tunnel. In the router-to-router or host-to-router methods, the IPv6 packet is being tunneled to a router. In the host-to-host or router-to-host methods, the IPv6 packet is tunneled all the way to its final destination.

The entry point of the tunnel (the encapsulating node) adds the IPv4 header and transmits the encapsulated packet. The exit point of the tunnel (the decapsulating node) receives the encapsulated packet, removes the IPv4 header, updates the IPv6 header, and processes the IPv6 packet.

To process IPv6 packets forwarded into the tunnel, the encapsulating node maintains soft state information for each tunnel, such as its maximum transmission unit (MTU),

IPv6 multihomed link-local and site-local support

A host with two or more active interfaces is termed a ``multihomed host''. Each interface of a multihomed host has an associated link-local address. Link-local addresses are sufficient to allow communication among nodes attached to the same subnet.

In the IPv6 implementation in UnixWare 7 Release 7.2, link-local address resolution for multihomed hosts may be configured in one of four ways:


Option 0
No multihomed actions are taken. Packets are transmitted on the first link-local interface. When the Neighbor Discovery Protocol (NDP) needs to resolve an address (because the link-local information for the next-hop is not in the Neighbor Cache), it sends out a multicast Neighbor Solicitation message on each interface for which a link-local address is defined. NDP queues the data packet until a Neighbor Advertisement message is received on an interface. The data packet is sent out of this interface.

Option 1 (default configuration)
When NDP needs to resolve an address, it sends out a multicast Neighbor Solicitation message on each interface for which a link-local address is defined. NDP then queues the data packet until it receives a Neighbor Advertisement message for all the interfaces. This guarantees that the data packets are sent on the appropriate outgoing interfaces. If NDP did not wait, but responded to the first advertisement received, a packet might be sent out on an interface that is not associated with the packet's source address. The delay in sending the first packet will potentially be longer than for Option 0.

Option 2
Multihomed operation is allowed, but packets are only dispatched on the interface specified by the main_if6 parameter to the inconfig(1Mtcp) command. When NDP needs to resolve an address, it sends out a multicast Neighbor Solicitation message on each interface for which a link-local address is defined. NDP then queues the data packet until it receives a Neighbor Advertisement message from the main_if6 interface. On receiving this, the data packet is sent out of this interface.

Option 3
Multihomed operation is allowed, but packets are only dispatched on the interface specified by main_if6, and site-local addresses will only be routed for the interface specified by the main_site6 parameter. NDP operates as for Option 2. For applications on a multihomed host that route data packets using site-local addresses, only the site-local address specified by main_site6 will be used.
© 2002 Caldera International, Inc. All rights reserved.
UnixWare 7 Release 7.1.3 - 30 October 2002