The Cable Guy - December 2006

Article
05/05/2010

IPv6 over Point-to-Point Protocol Links

TechNet's The Cable Guy

Microsoft® Windows Vista and Windows Server® 2008 support Internet Protocol version 6 (IPv6) over Point-to-Point Protocol (PPP) links in the built-in remote access client and Routing and Remote Access. This new capability allows remote access clients and demand-dial routers to send native IPv6 traffic over a PPP link such as a dial-up or virtual private network (VPN) connection. This capability also allows an Internet client to use PPP over Ethernet (PPPoE) for a broadband Internet connection to an IPv6-capable Internet service provider (ISP). This article describes how IPv6 packets are formatted over PPP links and the IPv6 Control Protocol (IPV6CP), a PPP Network Control Protocol (NCP) that negotiates IPv6 configuration options for the PPP connection.

Note

This article assumes knowledge of Internet Protocol version 4 (IPv4), IPv6, and PPP protocol operation.

Introduction

PPP is an industry standard method (RFC 1661) of utilizing point-to-point links to transport multi-protocol packets. PPP performs the following functions:

Provides multi-protocol data-link layer encapsulation PPP creates frames that contain separate Network layer packets.
Establishes, maintains, and ends the logical link The PPP protocol uses the Link Control Protocol (LCP) to establish and configure the parameters of the data-link connection. Part of the LCP negotiation is authenticating the security credentials of the PPP client.
Provides protocol configuration After the data-link connection has been negotiated, network layer protocols such as IPv4 or IPv6 are configured. For example, for IPv4, an IPv4 address is assigned to a remote access client by the remote access server. Compression and encryption can also be negotiated.

There are four phases of negotiation of a PPP connection. Each of these four phases must complete successfully before the PPP connection is ready to transfer network layer packets. The four phases of a PPP connection are the following:

PPP link configuration
Authentication
Callback (optional)
Protocol configuration

In Phase 4, a network control protocol (NCP) configures settings specific to each network layer protocol used over the PPP connection. For IP, the NCP is IP Control Protocol (IPCP). For IPCP, there are a variety of configuration options to assign an IP address or the addresses of name resolution servers. During IPCP negotiation, both PPP peers negotiate and agree on IPv4 configuration options. For IPv6, the NCP is IPV6CP (RFC 5072). Just as for IPCP, IPv6-based PPP peers use IPV6CP to negotiate and agree on IPv6 configuration options.

For more information about the phases of a PPP connection, see How Dial-up Remote Access Works in the Windows Server 2003 Technical Reference.

The following sections describe how IPv6 packets are encapsulated on a PPP link and the IPV6CP configuration options.

PPP Encapsulation of IPv6 Packets

PPP encapsulation uses a variant of the International Standards Organization (ISO) High Level Data Link Control (HDLC) protocol as defined in RFC 1662. Figure 1 shows PPP with HDLC framing for IPv6 packets.

Figure 1: PPP with HDLC framing for IPv6 packets

The fields in the PPP header and trailer are the following:

Flag Indicates the start and end of a PPP frame and is set to 0x7E. In consecutive PPP frames, only a single Flag character is used to mark both the end of a PPP frame and the beginning of the next PPP frame. The size of this field is 1 byte.
Address Used in HDLC environments to address the frame to a destination node. On a point-to-point link, the destination node does not need to be addressed. Therefore, for PPP, the Address field is set to 0xFF, which is the broadcast address. The size of this field is 1 byte. Typically, the use of this field is suppressed.
Control Used in HDLC environments for data-link layer sequencing and acknowledgments. For PPP, the Control field is set to 0x3 to indicate an unnumbered information (UI) frame. The size of this field is 1 byte. Typically, the use of this field is suppressed.
Protocol Identifies the protocol of the PPP payload. The Protocol field is set to 0x00-57 to indicate an IPv6 packet. In contrast, the Protocol field is set to 0x00-21 to indicate an IPv4 packet. The size of this field is 2 bytes. Although defined as a 2-byte field, typically the Protocol field size is compressed to 1 byte (the leading byte is suppressed).
Frame Check Sequence Stores a checksum value that is used to check for bit-level errors in the PPP frame. The size of this field is 2 bytes.

The MTU for a PPP connection, known as the Maximum Receive Unit, is negotiated by using LCP. The default MRU is 1,500 bytes. If negotiated lower, a PPP host must be able to send and receive frames large enough to meet the minimum link MTU size of 1280 bytes, as required by IPv6.

IPV6CP Configuration Options

IPV6CP configuration options are sent in IPV6CP messages, which use the same packet structure and negotiation method as LCP messages. For more information about LCP negotiation and messages, see How Dial-up Remote Access Works in the Windows Server 2003 Technical Reference.

Figure 2 shows the structure of IPV6CP messages.

Figure 2: The structure of IPV6CP messages

IPV6CP uses the PPP Protocol of 0x80-57. Each IPV6CP message consists of a Code field identifying the type of message, an Identifier field so that requests and replies can be matched, a Length field indicating the size of the message, and one or more IPV6CP options.

The following message types are defined for IPV6CP:

Configure-Request (Code=1) Sent to open the IPV6CP negotiation. Configure-Request contains a list of IPV6CP options with changes to default option values.
Configure-Ack (Code=2) Sent when all of the values of all of the IPV6CP options in the last Configure-Request received are recognized and acceptable. When both PPP peers send and receive Configure-Acks, the IPV6CP negotiation is complete.
Configure-Nack (Code=3) Sent when all the IPV6CP options are recognized, but the values of some options are not acceptable. Configure-Nack includes the offending options and their acceptable values.
Configure-Reject (Code=4) Sent when IPV6CP options are not recognized or not acceptable for negotiation. Configure-Reject includes the unrecognized or non-negotiable options.
Terminate-Request (Code=5) Optionally sent to close the IPV6CP negotiation.
Terminate-Ack (Code=6) Sent in response to the Terminate-Request.
Code-Reject (Code=7) Sent when the IPV6CP option code is unknown. The Code-Reject message includes the offending IPV6CP message.

RFC 5072 defines the Interface-Identifier IPv6 configuration option for IPV6CP.

Interface-Identifier Option

PPP peers use the Interface-Identifier option to negotiate the use of the 8-byte interface identifier (ID) portion of the link-local address assigned to the PPP interface. Figure 3 shows the structure of the Interface-Identifier option.

Figure 3: The Interface-Identifier option

PPP peers can derive an initial interface ID to assign to their PPP interface from an address assigned to a physical interface, such as an IEEE 802 address, or other types of serial numbers that are unique to the peer. If there is no source of information to derive an interface ID for the PPP interface, a PPP peer can set the interface ID to 0 and rely on the other PPP peer to determine an interface ID on its behalf. The two PPP peers must determine that each peer is using a unique interface ID. Examples of interface ID determination and negotiation are the following:

PPP Peer A determines an interface ID based on a local hardware address. PPP Peer B determines a different interface ID based on a local hardware address. Peer A sends an IPV6CP Configure-Request message containing its interface ID in the Interface-Identifier option. Peer B examines Peer A interface ID, determines that it is different than its own, and then sends a Configure-Ack message to Peer A. Peer B sends a Configure-Request message containing its interface ID. Peer A examines Peer B interface ID, determines that it is different than its own, and then sends a Configure-Ack message to Peer B. At this point, IPV6CP negotiation is complete.
Peer A determines an interface ID based on a local hardware address. Peer B cannot determine an interface ID and sets it to 0. Peer A sends a Configure-Request message containing its interface ID. Peer B examines Peer A interface ID, determines that it is different than its own, and then sends a Configure-Ack message to Peer A. Peer B sends a Configure-Request message containing its interface ID set to 0. Peer A examines Peer B interface ID, derives a interface ID for PPP Peer B to use (that is different from PPP Peer A interface ID), and then sends a Configure-Nack message to PPP Peer B containing the derived interface ID in the Interface-Identifier option. At this point, IPV6CP negotiation is complete.

For More Information

For more information, consult the following resources:

For a list of all The Cable Guy articles, click here.

Share via