IP Version 6 over PPP
obsoleted by
- rfc-5072 — IP Version 6 over PPP
- rfc-5172 — Negotiation for IPv6 Datagram Compression Using IPv6 Control Protocol
obsoletes
- rfc-2023 — IP Version 6 over PPP
Extracted elements (25)
A consistently reproducible interface identifier is preferred over a completely random one to provide stability to global-scope addresses formed from the interface identifier; stability is valuable across reboots and IPV6CP state machine reinitializations.
Because the IPV6CP Interface-Identifier negotiation ensures each end has a unique identifier, duplicate address detection (DAD) as part of IPv6 Stateless Autoconfiguration is redundant and its transmit count should default to zero on PPP links.
This document obsoletes RFC 2023, with key changes including renaming 'Interface Token' to 'Interface Identifier', expanding it from 32 to 64 bits, and changing the response to a zero Interface-Identifier in a Configure-Request from Configure-Ack to Configure-Nak.
A Configure-Request MUST contain exactly one instance of the Interface-Identifier option, and the interface identifier MUST be unique within the PPP link so that different values are selected for each end upon completion of negotiation.
A new Configure-Request MUST NOT contain the Interface-Identifier option if a valid Interface-Identifier Configure-Reject has been received.
Before any IPv6 packets may be communicated, PPP MUST reach the Network-Layer Protocol phase, and the IPv6 Control Protocol 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 the IPV6CP Interface-Identifier option enabled, the default value of the DupAddrDetectTransmits autoconfiguration variable SHOULD be set to zero, since uniqueness is already guaranteed by IPV6CP negotiation.
If a Configure-Nak is received with a suggested Interface-Identifier different from the last Configure-Nak sent, a new Configure-Request MUST be sent with the identifier value suggested in the last Configure-Nak from the peer.
If a non-IEEE-derived identifier is used (from link-layer address, serial number, random number, etc.), the 'u' bit of the interface identifier MUST be set to zero (0).
If both Interface-Identifiers are equal to zero, negotiation MUST be terminated by transmitting a Configure-Reject with the Interface-Identifier value set to zero, as a unique identifier cannot be negotiated.
If the two Interface-Identifiers are equal and non-zero, a Configure-Nak MUST be sent specifying a different non-zero Interface-Identifier value for use by the remote peer.
IPV6CP packets may not be exchanged until PPP has reached the Network-Layer Protocol phase; packets received before this phase should be silently discarded.
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 of IPv6 unicast addresses on a PPP interface SHOULD be negotiated in the IPV6CP phase; if no valid identifier is successfully negotiated, recovery procedures are unspecified (one approach is manual configuration).
IPv6-Compression-Protocol negotiation is specific to IPv6 datagrams and is independent of compression negotiated via the Compression Control Protocol (CCP), which may affect all datagrams. Each end must separately request this option for bidirectional compression.
IPv6 packets are encapsulated in the Information field of PPP Data Link Layer frames where the Protocol field indicates type hex 0057 (Internet Protocol Version 6). Exactly one IPv6 packet is carried per frame.
IPV6CP uses only Codes 1 through 7 (Configure-Request, Configure-Ack, Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack, Code-Reject). Other codes should be treated as unrecognized and result in Code-Rejects.
The IPv6 Control Protocol (IPV6CP) is encapsulated in PPP frames with Protocol field hex 8057. It uses the same packet exchange mechanism as LCP but with a distinct set of Configuration Options.
To derive an interface identifier from an EUI-64, the only transformation is to invert the 'u' (universal/local) bit (bit 6 in canonical order). For EUI-48, it is first expanded to EUI-64 by inserting 0xFF and 0xFE between the company_id and extension-identifier.
The IPv6 Control Protocol extension to PPP can be used with all defined PPP authentication and encryption mechanisms, providing no additional security constraints beyond those of PPP itself.
Interface-Identifier negotiation has four outcomes based on comparing received vs. sent identifiers: (1) different and non-zero received → Configure-Ack; (2) received is zero → Configure-Nak with non-zero suggestion; (3) equal and non-zero → Configure-Nak with different value; (4) both zero → Configure-Reject terminating negotiation.
IPv6 link-local addresses on PPP interfaces are formed as: 10-bit prefix 1111111010 (FE80::), 54 zero padding bits, followed by the 64-bit Interface Identifier negotiated via IPV6CP.
The Interface-Identifier Configuration Option has Type=1, Length=10, and carries a 64-bit Interface-Identifier field (8 octets). The total option is 10 octets including Type and Length bytes.
The IPv6-Compression-Protocol Configuration Option has Type=2, Length>=4, a 2-octet IPv6-Compression-Protocol field (values match PPP Data Link Layer Protocol field values for that compression protocol), and a variable-length Data field.