Chapter 10: Transmitting IPv6 Packets

Transmitting IPv6 packets has many facets and challenges involving standards, medium, tools and implementations. Furthermore, considering the present IP standards and protocols, IPv6 must go through a transition process, addressing all the above issues on the way. The IPng Transition (ngtrans) working group of the IETF has as its overall goal assisting in and promoting the transition to IPv6.

Current ngtrans efforts are divided into two separate activities:

• Tools - In charge of defining and developing the tools for the transition process
• The 6bone – A worldwide IPv6 testbed for testing of IPv6 implementations and their interoperability, for gaining operational experience in running IPv6 networks, and for fully proving out the viability of IPv6 in real use. Figures 10.1 and 10.2 provides couple diagrams showing the 6bone Registry tunnels for the sites shown and the status of its connectivity

This is an automatically drawn from the 6bone Registry tunnels for the sites shown. Drawing courtesy of Lancaster University and Andrew Scott.

Backbone site connectivity for 6Bone, from UK IPv6 Resource Centre, of Lancaster University Computing Department.

The 6bone is an IPv6 testbed to assist in the evolution and deployment of IPv6 in the Internet. The 6bone activity is part of the ngtrans effort under the IETF, and became operational in June/July 1996, with tunnels between UL/PT, NRL/US and CISCO/US, and between UNIC/DK, G6/FR and WIDE/JP.

What is 6bone?

The 6bone is an independent outgrowth of the IETF IPng project that resulted in the creation of the IPv6 protocols intended eventually to replace the current Internet network layer protocols known as IPv4. The 6bone is currently an informal collaborative project covering North America, Europe, and Japan.

One essential part in the IPv4 to IPv6 transition is the development of an Internet-wide IPv6 backbone infrastructure that can transport IPv6 packets. As with the existing IPv4 Internet backbone, the IPv6 backbone infrastructure will be composed of many Internet Service Providers (ISPs) and user networks linked together to provide the world-wide Internet.

Until the IPv6 protocols are widely implemented and fully tested for interoperability, production ISP and user network routers will not readily place production Internet (IPv4) routers at risk. Thus a way is needed to provide Internet-wide IPv6 transport in an organized and orderly way for early testing and use.

The 6bone is a virtual network layered on top of portions of the physical IPv4-based Internet to support routing of IPv6 packets, as that function has not yet been integrated into many production routers. The network is composed of islands that can directly support IPv6 packets, linked by virtual point-to-point links called "tunnels". The tunnel endpoints are typically workstation-class machines having operating system support for IPv6.

Over time, as confidence builds to allow production routers to carry native IPv6 packets, it is expected that the 6bone would disappear by agreement of all parties. It would be replaced in a transparent way by production ISP and user network IPv6 Internet-wide transport.

The 6bone is thus focused on providing the early policy and procedures necessary to provide IPv6 transport in a reasonable fashion so testing and experience can be carried out. It would not attempt to provide new network interconnect architectures, procedures and policies that are clearly the purview of ISP and user network operators. In fact, it is the desire to include as many ISP and user network operators in the 6bone process as possible to guarantee a seamless transition to IPv6.

The 6bone Working Group is a forum for information concerning the deployment, engineering, and operation of IPv6 protocols and procedures in the global Internet. These activities include, but are not limited to:

• Deployment of IPv6 transport and routing in the global Internet via a "6bone" testbed to assist in the following.
• Creation of "practice and experience" informational RFC documents that capture the experiences of those who have deployed, and are deploying, various IPv6 technologies.
• Feedback to various IETF ipv6-related activities, based on testbed experience, where appropriate.
• Development of mechanisms and procedures to aid in the transition to native IPv6, where appropriate.
• Development of mechanisms and procedures for sharing operational information to aid in operation of global IPv6 routing.

The Transition to IPv6

By now, you probably agree with the fact that IPv6 represents a major leap forward for the Internet and the enterprises that rely on internetworking technology. IPv6 improves on IPv4 in many areas that are of great near-term and long-term value to network-dependent businesses. But the industry has not agreed, however, on how the transition from IPv4 to IPv6 will be and how much time it will take. Some are lobbying for a wholesale, rapid adoption of IPv6 in the very near future. Others prefer to let the IPv6 project wait until address-space exhaustion and other issues force conversion. But given the magnitude of a migration that affects so many millions of network devices, it is clear that there will be an extended period when IPv4 and IPv6 will coexist at many levels of the Internet.

NOTE: There are three co-chairs of ngtrans: Bob Fink (rlfink@lbl.gov), Robert Gilligan (gilligan@freegate.net) and Tony Hain (tonyhain@microsoft.com). Feel free to contact them for additional information about 6bone and IPv6 transition (ngtrans).

NOTE: This section was based on a great white paper, available at Bay Network’s site (http://www.baynetworks.com/Products/Routers/Protocols/2789.html), which I recommend you to visit, for more details.

With the reality of extended IPv4/IPv6 coexistence looming, IETF protocol designers have expended a substantial amount of effort to ensure that hosts and routers can be upgraded to IPv6 in a graceful, incremental manner. Great pains have been taken to ensure that the transition will not entail large-scale obsolescence of IPv4 nodes or "fork-lift" upgrades for entire user populations in a short time frame. Transition mechanisms have been engineered to allow network administrators a large amount of flexibility in how and when they upgrade hosts and intermediate nodes. Consequently, IPv6 can be deployed in hosts first, in routers first, or, alternatively, in a limited number of adjacent or remote hosts and routers. The nodes that are upgraded initially do not have to be collocated in the same local area network or campus.

Another assumption made by IPv6 transition designers is the likelihood that many upgraded hosts and routers will need to retain downward compatibility with IPv4 devices for an extended time period (possibly years or even indefinitely). It was also assumed that upgraded devices should have the option of retaining their IPv4 addressing. To accomplish these goals, IPv6 transition relies on several special functions that have been built into the IPv6 standards work, including dual-stack hosts and routers and tunneling IPv6 via IPv4.

The Dual-Stack Hosts

Once a few nodes have been converted to IPv6, very likely these nodes will require continued interaction with existing IPv4 nodes. This is accomplished with the dual-stack IPv4/IPv6 approach. Many of the hosts and routers in today's multivendor, multiplatform-networking environment already support multiple network stack components. The majority of routers in enterprise networks are of the multiprotocol variety. By the same token, many workstations run some combination of IPv4, IPX, AppleTalk, NetBIOS, SNA, DECnet, or other protocols. The inclusion of one additional protocol (IPv6) on an endstation or router is a fairly trivial undertaking at the current time. When running a dual IPv4/IPv6 stack, a host has access to both IPv4 and IPv6 resources. Routers running both protocols can forward traffic for both IPv4 and IPv6 end nodes.

Dual-stack machines can use totally independent IPv4 and IPv6 addresses, or they can be configured with an IPv6 address that is IPv4-compatible. Dual-stack nodes can use conventional IPv4 autoconfiguration services (DHCP) to obtain their IPv4 addresses. IPv6 addresses can be manually configured in the 128-bit local host tables, or obtained via IPv6 stateless or stateful autoconfiguration mechanisms, when available. It is expected that major servers will run in dual-stack mode indefinitely, or until all active nodes are converted to IPv6.

IPv6 DNS

Domain Name Service is something that administrators must consider before deploying IPv6 or dual-stack hosts. The current 32-bit name servers cannot handle name-resolution requests for 128-bit addresses used by IPv6 devices. In response to this issue, IETF designers have defined an IPv6 DNS standard, which is discussed in more details on chapter 14, "IPv6 DNS Ids."

This specification creates a new 128-bit DNS record type named "AAAA" (quad A) that will map domain names to an IPv6 address. Domain name lookups (reverse lookups) based on 128-bit addresses also are defined. Once an IPv6-capable DNS is in place, dual-stack hosts can interact interchangeably with IPv6 nodes. If a dual-stack host queries a DNS and receives back a 32-bit address, IPv4 is used; if a 128-bit address is received, then IPv6 is used. On sites where the DNS has not been upgraded to IPv6, hosts may resolve name-to-address mappings through the use of manually configured local name tables.

But if an application does not directly access the network stack, then it will not need to be modified to run in the dual-stack environment. Network applications that directly interface with IP and related components will require updating if they are to use the IPv6 protocol.

Routing in IPv6/IPv4 Networks

Any router running both IPv6 and IPv4 can be administered just as it with IPv4-only networks. IPv6 versions of popular routing protocols, such as Open Shortest Path First (OSPF) and Routing Information Protocol (RIP), are already being developed, as discussed on chapter 9, "IPv6 Performance." In many cases, administrators will choose to keep the IPv6 topology logically separate from the IPv4 network, even though both run on the same physical infrastructure. This will allow the two to be administered separately.

A separate IPv6 architecture, however, can be advantageous in eliminating chaotic and inefficient IPv4 addressing systems. An independent IPv6 architecture presents the opportunity to build a fresh, hierarchical network address plan that will greatly facilitate connection to one or more ISPs.

IPv6 over IPv4: Tunneling encapsulates IPv6 packets in IPv4 packets

Tunneling allows early IPv6 implementations to take advantage of existing IPv4 infrastructure without any change to IPv4 components. A dual-stack router or host on the "edge" of the IPv6 topology simply appends an IPv4 header to each IPv6 packet and sends it as native IPv4 traffic through existing links. IPv4 routers forward this traffic without knowledge that IPv6 is involved. On the other side of the tunnel, another dual-stack router or host de-encapsulates the IPv6 packet and routes it to the ultimate destination using standard IPv6 protocols.

To accommodate different administrative needs, IPv6 transition mechanisms include two types of tunneling: automatic and configured. To build configured tunnels, administrators manually define IPv6-to-IPv4 address mappings at tunnel endpoints. On either side of the tunnel, traffic is forwarded with full 128-bit addresses. At the tunnel entry point, a router table entry is defined manually to dictate which IPv4 address is used to traverse the tunnel. This requires a certain amount of manual administration at the tunnel endpoints, but traffic is routed through the IPv4 topology dynamically, without the knowledge of IPv4 routers. The 128-bit addresses do not have to align with 32-bit addresses in any way.

Automatic Tunneling

Automatic tunnels use "IPv4-compatible" addresses, which are hybrid IPv4/IPv6 addresses. Adding leading zeros to the 32-bit IPv4 address to pad them out to 128 bits creates compatible addresses. When traffic is forwarded with compatible addresses, the device at the tunnel entry point can automatically address encapsulated traffic by simply converting the IPv4-compatible 128-bit address to a 32-bit IPv4 address. On the other side of the tunnel, the IPv4 header is removed to reveal the original IPv6 address. Automatic tunneling allows IPv6 hosts to dynamically exploit IPv4 networks, but it does require the use of IPv4-compatible addresses, which do not bring the benefits of the128-bit address space.

However, IPv6 nodes using IPv4-compatible addresses cannot take advantage of the extended address space, even though, they can exploit the other IPv6 enhancements, including flow labels, authentication, encryption, multicast, and anycast. Once a node is migrated to IPv6 with IPv4-compatible addressing, the door is open for a fairly painless move to the full IPv6 address space. Automatic tunnels are available when needed, but they may not be necessary in cases where major backbone routers are upgraded all at once to include the IPv6 stack. This is something that can be achieved quickly and efficiently when backbone routers support full remote configuration and upgrade capabilities (e.g., Bay Networks Backbone Node and Access Node routers).

TIP: For information on Bay Networks Backbone Node and Access Node routers check their Web site at URL http://www.baynetworks.com/Products/nav/t_routers.shtml.

Making the Transition

Earlier in this chapter we discussed some of the transition mechanisms of IPv6, which included dual-stack IPv4 /IPv6 hosts and routers, tunneling of IPv6 via IPv4. Below is a scenario that illustrates these proposed transitions.

Scenario 1:

In this scenario NAT is not used. Let’s assume you’re a big manufacturer, with several plants across United States and Europe, and are network-dependent of each other as you need to interface operations, real-time stoke control and so on. Let’s also assume that just like everyone else at this stage, your large network is IPv4-based.

Also, let’s assume that some of your sites in have a substantial number of private IPv4 addresses that are not necessarily unique within the current global IPv4 address space. One of the reasons you’re resisting your systems administrator’s effort to combine these two non-unique address spaces is because you know it will probably cost you a lot of money to renumber and restructure the routers, host addresses, domains, areas, exterior routing protocols, and so on. IPv6 can be the solution of your problems!

The task of logically merging two enterprise networks into a single autonomous domain is an expensive and potentially disruptive project. To avoid the cost and disruption of comprehensive renumbering, enterprises may be tempted to opt for the stopgap solution of a network address translator (NAT). But in our case here, a NAT could allow the two enterprises to maintain their private addresses, since a NAT must conduct address translation in real time for all packets that move between the two organizations. Besides, NATs tend to promote bottlenecks, lack of scalability, lack of standards, and lack of universal connectivity among all the nodes in the new enterprise and the Internet.

But unlike NATs, IPv6 can provide you with a robust "future-oriented" solution to the logical integration of two physical networks, as shown on figure 10.4. In the figure, assume that your factory in US is Enterprise A and your factory in Europe is Enterprise B. The first step is to determine which hosts need access to both sides of the new organization. These hosts are outfitted with dual IPv4/IPv6 stacks, which allow them to maintain connectivity to their original IPv4 network while also participating in a new IPv6 logical network that will be created "on top" of the existing IPv4 physical infrastructure.

IPv6 Unites Private Address Spaces

Evidently, your servers on both sides of the world will probably be integrated, running financial applications and other tools. Both servers and clients will be given IPv6, but they will also retain their IPv4 stack components. The IPv6 sessions of your accounting department, for example, could travel over the existing local and remote links as "just another protocol," requiring no changes to the physical network. The only requirement for IPv6 connectivity is that routers that are adjacent to accounting department users must be upgraded to IPv6 capabilities. Where end-to-end IPv6 connectivity can't be achieved, one of the IPv4/IPv6 tunneling techniques can be employed.

As integration continues, other departments in your newly merged factories will also be given IPv4/IPv6 hosts. As new departments and workgroups are added, they may be given dual-stack hosts, or in some cases, IPv6-only hosts. Hosts that require communications to the outside world via the Internet will likely receive dual stacks to maintain compatibility with IPv4 nodes exterior to the enterprise. But in some cases, hosts that only require access to internal servers and specific outside partners may be able to achieve connectivity with IPv6-only hosts. A migration to IPv6 presents the opportunity for a fresh start in terms of address allocation and routing protocol structure. IPv6 hosts and routers can immediately take advantage of IPv6 features such as stateless autoconfiguration, encryption, authentication, and so on.

Transmitting IPv6 Packets over Ethernet

RFC 1972, of August 1996, specifies the frame format for transmitting IPv6 packets and the method of forming IPv6 link-local addresses on Ethernet networks. It also specifies the content of the Source/Target Link-layer Address option used the Router Solicitation, Router Advertisement, Neighbor Solicitation, and Neighbor Advertisement messages described in RFC 1970, when those messages are transmitted on an Ethernet.

Maximum Transmission Unit

By default, the Maximum Transmission Unit (MTU) size for IPv6 packets on an Ethernet is 1500 octets. This size can be reduced by a Router Advertisement (RA), according to RFC 1970, containing an MTU option, which specifies a smaller MTU, or by manual configuration of each node. Thus, if a (RA) is received with an MTU option specifying an MTU larger than 1500, or larger than a manually configured value less than 1500, that MTU option must be ignored.

Frame Format

IPv6 packets are transmitted in standard Ethernet frames. The Ethernet header, as shown on figure 10.5, contains the Destination and Source Ethernet addresses and the Ethernet type code, which must contain the value 86DD hexadecimal. The data field contains the IPv6 header followed immediately by the payload, and possibly padding octets to meet the minimum frame size for Ethernet.

A description of a Ethernet header, containing the Destination, Source address and type of code

Stateless Autoconfiguration and Link-Local Addresses

The address token for an Ethernet interface, as specified on RFC 1971, is the interface's built-in 48-bit IEEE 802 address, in canonical bit order and with the octets in the same order in which they would appear in the header of an Ethernet frame. A different MAC address set manually or by software should not be used as the address token. Thus, an IPv6 address prefix used for stateless autoconfiguration of an Ethernet interface must be 80 bits in length.

As for the IPv6 Link-local address, for an Ethernet interface, as specified on RFC 1884, it is formed by appending the interface's IEEE 802 address to the 80-bit prefix FE80::.

IPv6 Link-local addresses on Ethernet interfaces are formed by appeding IEEE 802 address interface to the 80-bit prefix FE80::

Address Mapping – Unicast

The Source/Target Link-layer Address option has the form shown on figure 10.7 when the link layer is Ethernet. The following is the composition of the option fields:

• Type - 1 for Source Link-layer address, and 2 for Target Link-layer address.
• Length - 1 (in units of 8 octets).
• Ethernet Address - The 48 bit Ethernet IEEE 802 address, in canonical bit order. This is the address the interface currently responds to, and may be different from the built-in address used as the address token.

The Source/Target Link-layer Address option when using Ethernet as link layer

Address Mapping -- Multicast

An IPv6 packet with a multicast destination address DST is transmitted to the Ethernet multicast address whose first two octets are the value 3333 hexadecimal and whose last four octets are the last four octets of DST, ordered from more to least significant, as shown on figure 10.8.

IPv6 Multicast packet destination addresses DST are transmitted over the Ethernet using 3333 as the first two octets and the last four DST octets for the last four octets

Transmitting IPv6 Packets over FDDI Networks

RFC 2019, developed and proposed by Matt Crawford (see note below for contact information), specifies the MTU and frame format for transmission of IPv6 packets on FDDI networks. It also specifies the method of forming IPv6 link-local addresses on FDDI networks and the content of the Source/Target Link-layer Address option used the Router Solicitation, Router Advertisement, Neighbor Solicitation, and Neighbor Advertisement messages described in RFC 1970, when those messages are transmitted on an FDDI network.

NOTE: Matt Crawford, the author of RFC 2019, can be contacted by e-mail at crawdad@fnal.gov.

Maximum Transmission Unit

FDDI permits a frame length of 4500 octets (9000 symbols), including at least 22 octets (44 symbols) of Data Link encapsulation when long-format addresses are used. Subtracting 8 octets of LLC/SNAP header, this would, in principle, allow the IPv6 packet in the Information field to be up to 4470 octets. However, it is desirable to allow for the variable sizes and possible future extensions to the MAC header and frame status fields.

The default MTU size for IPv6 packets on an FDDI network is therefore 4352 octets. This size may be reduced by a Router Advertisement [DISC] containing an MTU option, which specifies a smaller MTU, or by manual configuration of a smaller value on each node. If a Router Advertisement is received with an MTU option specifying an MTU larger than the default or the manually configured value, that MTU option may be logged to system management but must be otherwise ignored.

Frame Format

FDDI provides both synchronous and asynchronous transmission, with the latter class further subdivided by the use of restricted and unrestricted tokens. Only asynchronous transmission with unrestricted tokens is required for FDDI interoperability. Thus, IPv6 packets shall be sent in asynchronous frames using unrestricted tokens.

The data field of an IPv6 FDDI frame contains the IPv6 header and payload and is followed by the FDDI Frame Check Sequence, Ending Delimiter, and Frame Status symbols.

FDDI Header Fields:

• FC - The Frame Code must be in the range 50 to 57 hexadecimal, inclusive, with the three low order bits indicating the frame priority. The Frame Code should be in the range 51 to 57 hexadecimal, inclusive, for reasons given in the next section.
• DSAP, SSAP - Both the DSAP and SSAP fields shall contain the value AA hexadecimal, indictating SNAP encapsulation.
• CTL - The Control field shall be set to 03 hexadecimal, indicating Unnumbered Information.
• OUI - The Organizationally Unique Identifier shall be set to 000000 hexadecimal.
• Ethertype - The Ethernet protocol type ("ethertype") shall be set to the value 86DD hexadecimal.

Interaction with Bridges

802.1d MAC bridges, connecting various media such as Ethernet and FDDI, have become very widespread. Some of them do IPv4 packet fragmentation and/or support IPv4 Path MTU discovery (PMTU), but many don’t have this capability or don’t function properly. Therefore, the use of IPv6 in a bridged mixed-media environment should not depend on support from MAC bridges.

In order to obtain a correct operation when mixed media are bridged together, the smallest MTU of all the media must be advertised by routers in an MTU option. If there are no routers present, this MTU must be manually configured in each node, which is connected to a medium with larger default MTU. Multicast packets on such a bridged network must not be larger than the smallest MTU of any of the bridged media. Often, the subnetwork topology will support larger unicast packets to be exchanged between certain pairs of nodes. To take advantage of high-MTU paths when possible, nodes transmitting IPv6 on FDDI should implement the following simple mechanism for "FDDI adjacency detection".

Note that an IPv6 frame which originated on an Ethernet, or traversed an Ethernet, before being translated by an 802.1d bridge and delivered to a node's FDDI interface will have zero in the priority field. As Crawford observes, there's a fine point here: a conforming bridge may provide a management-settable Outbound User Priority parameter for each port. However, the author is unaware of any product that provides this optional capability and, in any case, the default values for the parameter is zero.

If a node N1 receives, in an FDDI frame with a non-zero LLC priority, a valid Router Advertisement, Neighbor Advertisement, or Neighbor Solicitation from a node N2, then N1 may send unicast IPv6 packets to N2 with sizes up to the default IPv6 FDDI MTU (4352 octets), regardless of any smaller MTU configured manually or received in a Router Advertisement MTU option. N2 may be the IPv6 destination or the next hop router to the destination.

Also, nodes implementing FDDI adjacency detection must provide a configuration option to disable the mechanism. This option may be used when a smaller MTU is desired for reasons other than mixed-media bridging. By default, FDDI adjacency detection should be enabled.

NOTE: For information on Stateless Autoconfiguration and Link-Local Addresses, check RFC 2019.

IPv6 over PPP

The Point-to-Point Protocol (PPP) provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.

RFC 2023 (October 1996), the base for this section, was developed by Dimitry Haskin and Ed Allen, both from Bay Networks, and defines the method for transmission of IP Version 6 packets over PPP links as well as the Network Control Protocol (NCP) for establishing and configuring the IPv6 over PPP. It also specifies the method of forming IPv6 link-local addresses on PPP links.

NOTE: This section was based on RFC 2023, of Dimitry Haskin and Ed Allen, from Bay Networks, Inc. For additional information about that RFC or updated information on IPv6 over PPP, you can e-mail Dimitry at dhaskin@baynetworks.com and Ed at eallen@baynetworks.com.

Introduction

PPP has three main components:

1. A method for encapsulating datagrams over serial links.
2. A Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection.
3. A family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.

In order to establish communications over a point-to-point link, each end of the PPP link must first send LCP packets to configure and test the data link. After the link has been established and optional facilities have been negotiated as needed by the LCP, PPP must send NCP packets to choose and configure one or more network-layer protocols. Once each of the chosen network-layer protocols has been configured, datagrams from each network-layer protocol can be sent over the link.

In the RFC 2023, Haskin and Allen refer to the NCP for establishing and configuring the IPv6 over PPP as the IPv6 Control Protocol (IPV6CP).

Sending IPv6 Datagrams over PPP

For an IPv6 packet to be communicated, PPP must reach the Network-Layer Protocol phase, and the IPv6 Control Protocol must reach the Opened state. Exactly one IPv6 packet is encapsulated in the Information field of PPP Data Link Layer frames where the Protocol field indicates type hex 0057 (Internet Protocol Version 6).

An IPv6 packet transmitted over a PPP link has the same maximum length of the Information field of a PPP data link layer frame. PPP links supporting IPv6 must allow at least 576 octets in the information field of a data link layer frame.

PPP Network Control Protocol

The IPv6 Control Protocol (IPV6CP) is responsible for configuring, enabling, and disabling the IPv6 protocol modules on both ends of the point-to-point link. It uses the same packet exchange mechanism as the Link Control Protocol (LCP). However, these packets cannot be exchanged until PPP has reached the Network-Layer Protocol phase. Otherwise, if IPV6CP packets are received before this phase is reached, they should be silently discarded.

Both the IPv6 Control Protocol and the Link Control Protocol, are exactly the same, as per RFC 1661 (July 1994), developed by Simpson, W. except for the following:

• Data Link Layer Protocol Field - Exactly one IPV6CP packet is encapsulated in the Information field of PPP Data Link Layer frames where the Protocol field indicates type hex 8057 (IPv6 Control Protocol).
• Code field - Only Codes 1 through 7 (Configure-Request, Configure-Ack, Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack and Code-Reject) are used. Other Codes should be treated as unrecognized and should result in Code-Rejects.
• Timeouts – As discussed earlier IPV6CP packets may not be exchanged until PPP has reached the Network-Layer Protocol phase. Thus, an implementation should be prepared to wait for Authentication and Link Quality Determination to finish before timing out waiting for a Configure-Ack or other response. It is suggested that an implementation give up only after user intervention or a configurable amount of time.
• Configuration Option Types - IPV6CP has a distinct set of Configuration Options, which are defined below.

IPV6CP Configuration Options

IPV6CP Configuration Options allow negotiation of desirable IPv6 parameters. Both IPV6CP and Configuration Option (as defined for LCP on RFC 1661) uses the same format with a separate set of Options. If a Configuration Option is not included in a Configure-Request packet, the default value for that Configuration Option is then assumed.

Interface-Token

This Configuration Option provides a way to negotiate a unique 32-bit interface token to be used for the address autoconfiguration at the local end of the link. The interface token MUST be unique within the PPP link.

Before this Configuration Option is requested, an implementation must choose its tentative Interface-Token. It is recommended that a non-zero value be chosen in the most random manner possible in order to guarantee with very high probability that an implementation will arrive at a unique token value. A good way to choose a unique random number is to start with a unique seed. You could use the serial number of your computers and printers, or even other network hardware addresses, system clocks, etc.

IPv6-Compression-Protocol

The IPv6-Compression-Protocol Configuration Option is used to indicate the ability to receive compressed packets. Each end of the link must separately request this option if bi-directional compression is desired. By default, compression is not enabled.

Beware that the IPv6 compression negotiated with this option is specific to IPv6 datagrams only. Do not confuse it with compression resulting from negotiations via Compression Control Protocol (CCP), which potentially effect all datagrams.

From Here

Next chapter, ICMPv6 and IPv6 reviews RFC 1885, which specifies a set of Internet Control Message Protocol (ICMP) messages for use with IPv6.