RFC 4941, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", September 2007

Note: This RFC has been obsoleted by RFC 8981

Errata ID: 4404
Status: Held for Document Update
Type: Technical
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.

Notes:

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!

Report New Errata