IP Version 6 over PPP
obsoleted by
- rfc-2472 — IP Version 6 over PPP
Extracted elements (21)
A non-zero Interface-Token value should be chosen using the most random means possible, combining sources such as machine serial numbers, other network hardware addresses, and system clocks. A link-layer address alone is insufficient as a seed because it may not always be unique.
IPv6 compression negotiated via IPv6-Compression-Protocol is specific to IPv6 datagrams and is intentionally separate from Compression Control Protocol (CCP) negotiations, which potentially affect all datagrams.
If a Configure-Request is received with the Interface-Token option but the receiving peer does not implement this option, it sends a Configure-Reject, and the peer MUST NOT send further Configure-Nak messages including that option.
A new Configure-Request MUST NOT contain the Interface-Token option if a valid Interface-Token Configure-Reject has been received.
Before any IPv6 packets may be communicated, PPP must reach the Network-Layer Protocol phase and IPV6CP must reach the Opened state.
For PPP links with the IPV6CP Interface-Token option enabled, it is recommended that the DupAddrDetectTransmits autoconfiguration variable default to zero, because token uniqueness is guaranteed by the IPV6CP negotiation, making duplicate address detection redundant.
If a received Configure-Nak token equals the one sent in the last Configure-Nak, a new Interface-Token MUST be chosen and a new Configure-Request SHOULD be sent with the new tentative value.
If a received Interface-Token is non-zero and differs from the local token, a Configure-Ack MUST be sent acknowledging the requested token.
If both Interface-Tokens are equal and non-zero, a Configure-Nak MUST be sent specifying a different non-zero token value suggested for the remote peer.
If both Interface-Tokens are equal to zero, negotiation MUST be terminated by sending a Configure-Reject with the Interface-Token value set to zero, as a unique token cannot be negotiated.
IPV6CP packets received before PPP reaches the Network-Layer Protocol phase should be silently discarded.
PPP links supporting IPv6 MUST allow at least 576 octets in the information field of a data link layer frame, matching the maximum IPv6 packet size over such a link.
The interface token for a PPP interface SHOULD be negotiated during the IPV6CP phase of PPP connection setup; recovery procedures if no valid token is negotiated are unspecified.
The Interface-Token MUST be unique within the PPP link; upon completion of negotiation, different Interface-Token values must be selected for each end of the link.
IPV6CP defines two Configuration Options: Interface-Token (type 1) for negotiating a unique 32-bit interface token, and IPv6-Compression-Protocol (type 2) for negotiating IPv6 packet compression.
The IPv6 Control Protocol (IPV6CP) is the NCP responsible for configuring, enabling, and disabling IPv6 protocol modules on both ends of a PPP link. It uses the same packet exchange mechanism as LCP and is identified by PPP Protocol field value 0x8057.
Security issues are not discussed in this memo.
IPv6 link-local addresses for PPP interfaces are 128 bits: the 10-bit Link-Local prefix FE80::, 86 zero padding bits, and a 32-bit Interface Token. This differs from the 64-bit IID used on other link types.
IPv6 packets are encapsulated in the Information field of PPP Data Link Layer frames with the Protocol field set to hex 0057 (Internet Protocol Version 6). Exactly one IPv6 packet is carried per PPP frame.
The Interface-Token Configuration Option has Type=1, Length=6, and carries a 32-bit Interface-Token field. The token should be non-zero and as random as possible; zero indicates inability to generate a unique token.
The IPv6-Compression-Protocol Configuration Option has Type=2, Length>=4, a 2-octet IPv6-Compression-Protocol field (whose values match PPP Data Link Layer Protocol field values for the compression protocol), and a variable-length Data field. Value 0x004f identifies IPv6 Header Compression.