IP Version 6 over PPP
obsoletes
- rfc-2472 — IP Version 6 over PPP
updated by
- rfc-8064 — Recommendation on Stable IPv6 Interface Identifiers
Extracted elements (24)
A consistently reproducible unique interface identifier is preferred over a completely random one to provide stability to global scope addresses that may be derived from the interface identifier (see Appendix A). This avoids unnecessary renumbering across reboots.
The IPv6-Compression-Protocol option (Section 4.2 of RFC 2472) was removed from this document per IESG recommendation and moved to a separate standards-track document, keeping IPV6CP focused solely on interface identifier negotiation.
3GPP2 (cdma2000) and 3GPP networks are cited as examples of technologies that use PPP for IPv6 global unicast address assignment and satisfy the two conditions under which DAD suppression (DupAddrDetectTransmits=0) is appropriate.
A Configure-Request MUST contain exactly one instance of the Interface-Identifier option. The interface identifier MUST be unique within the PPP link, i.e., the two ends of the link MUST negotiate different values.
Before any IPv6 packets may be communicated, PPP MUST reach the network-layer protocol phase, and the IPv6 Control Protocol (IPV6CP) MUST reach the Opened state.
By default, an implementation SHOULD attempt to negotiate the interface identifier for its end of the PPP connection.
For PPP links with IPV6CP interface-identifier negotiation enabled, where prefixes are exclusive to the link and the access router does not autoconfigure addresses from those prefixes, it is RECOMMENDED that DupAddrDetectTransmits be set to zero, making DAD unnecessary.
If both interface identifiers are equal to zero, the negotiation MUST be terminated by sending Configure-Reject with interface-identifier value zero. A new Configure-Request MUST NOT include the Interface-Identifier option after receiving a valid Configure-Reject for it.
IPV6CP packets received before PPP reaches the network-layer protocol phase should be silently discarded. Implementations should be prepared to wait for Authentication and Link Quality Determination before timing out.
PPP links supporting IPv6 MUST allow the Information field to be at least as large as the minimum link MTU size required for IPv6.
The interface identifier for a PPP interface SHOULD be negotiated in the IPV6CP phase. It SHOULD NOT be assumed that the same negotiated identifier is used for global unicast addresses; a peer MAY generate additional identifiers (e.g., per RFC 4941) for global unicast autoconfiguration.
The tentative interface identifier SHOULD be chosen to be unique to the link and, preferably, consistently reproducible across IPV6CP finite state machine reinitializations (reboots, administrative close/reopen).
Upon receiving a Configure-Nak with a suggested identifier different from the last Configure-Nak sent, a new Configure-Request MUST be sent using the peer's suggested identifier. If the suggested value equals what was last sent in a Configure-Nak, a new identifier MUST be chosen.
When the interface identifier is not derived from a globally unique IEEE identifier (EUI-48 or EUI-64), the universal/local 'u' bit (bit 6) of the interface identifier MUST be set to zero.
The IPv6 Control Protocol (IPV6CP) is the NCP responsible for configuring, enabling, and disabling IPv6 on both ends of a PPP link. It reuses the LCP packet exchange mechanism and has its own distinct Configuration Options.
To derive an IPv6 interface identifier from an IEEE EUI-64, the only transformation is inverting the 'u' (universal/local) bit. For EUI-48, the identifier is first expanded to EUI-64 by inserting 0xFF and 0xFE between the company_id and extension identifier fields.
IANA assigned Type value 1 for the Interface-Identifier Configuration Option in IPV6CP. The current assignment is maintained in the IANA Assigned Numbers registry.
Absence of PPP link security (authentication, encryption) raises security concerns when stateless address autoconfiguration is used to generate global unicast addresses from negotiated or generated interface identifiers. Three mitigations are identified: Access Control Lists, an authentication protocol, and an encryption protocol.
Use of MD5 authentication on a PPP link exposes it to replay attacks, where an attacker intercepts and replays a station's identity and password hash to gain network access. Implementors are referred to RFC 3748 (EAP) for a generic threat model and authentication selection framework.
Interface identifier negotiation: (1) received != sent and received is nonzero → Configure-Ack; (2) received == sent and nonzero → Configure-Nak with different suggested value; (3) received is zero → Configure-Nak with nonzero suggestion; (4) both are zero → Configure-Reject, negotiation terminated.
IPv6 packets are encapsulated in the Information field of PPP Data Link Layer frames with Protocol field set to hex 0057 (Internet Protocol Version 6). Exactly one IPv6 packet is encapsulated per frame.
IPV6CP packets are encapsulated in PPP Data Link Layer frames with Protocol field set to hex 8057 (IPv6 Control Protocol). Only Codes 1 through 7 (Configure-Request through Code-Reject) are used.
PPP IPv6 link-local addresses have a 10-bit FE80:: prefix, 54 zero padding bits, and a 64-bit Interface-Identifier field, for a total of 128 bits.
The Interface-Identifier Configuration Option has Type=1, Length=10 octets, and carries a 64-bit interface identifier. The field is zero if no good source of uniqueness is available.