RFC 4941, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", September 2007Source of RFC: ipv6 (int)
Errata ID: 4404
Status: Held for Document Update
Publication Format(s) : TEXT
Reported By: Jewgenij Bytschkow
Date Reported: 2015-06-29
Held for Document Update by: Brian Haberman
Date Held: 2015-06-30
Section 2.3 says:
The way PPP is used today, however, PPP servers typically unilaterally inform the client what address they are to use (i.e., the client doesn't generate one on its own). This practice, if continued in IPv6, would avoid the concerns that are the focus of this document.
It should say:
In contrast to LAN clients, the way PPP is used today, however, does not allow the client to freely and unilaterally change its own interface identifier. PPP servers also do not unilaterally inform the client what 128-bit address to use. In the same manner as for LAN connected clients (without PPP), a PPP client generates its global-scope IPv6 address from the Interface-Identifier part and the Prefix part. The client obtains a prefix from the PPP server in the same way as LAN clients do, i.e. via Neighbor Discovery Protocol. However, an interface identifier of a PPP client MUST be negotiated with the PPP server via IPv6CP protocol (Interface-Identifier option). Only then, after IPv6CP was successfully negotiated between the PPP client and the PPP server, the PPP client can generate and assign its individual global IPv6 address compounded from the negotiated interface identifier and the obtained prefix. In order to change the old negotiated interface identifier later in the same PPP session, the client MUST initiate a new IPv6CP negotiation with the PPP server, proposing a new client's interface identifier.
Such an extensive additional explanation of PPP specifics regarding changing of interface identifier on PPP clients is very important for both PPP servers manufacturers and PPP slients manufacturers, in order to define a method for legal changing of interface IDs on PPP clients (according to the recommendations of this RFC 4941) and to correctly support of a changed client’s interface ID on the PPP Server (for correct IPv6 routes in the routing table et al.).
Failure to comply with these PPP specifics and requirements can lead to misinterpretation, fault implementations, and then to critical PPP sessions issues in real operation!