RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 9 records.

Status: Verified (3)

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

Source of RFC: ipv6 (int)

Errata ID: 3240

Status: Verified
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2007-10-12
Verifier Name: Brian Haberman
Date Verified: 2012-06-01

Section 3.3 says:

   4.  When creating a temporary address, the lifetime values MUST be
       derived from the corresponding prefix as follows:

       *  Its Valid Lifetime is the lower of the Valid Lifetime of the
          public address or TEMP_VALID_LIFETIME.

       *  Its Preferred Lifetime is the lower of the Preferred Lifetime
          of the public address or TEMP_PREFERRED_LIFETIME -
          DESYNC_FACTOR.

It should say:

   4.  When creating a temporary address, the lifetime values MUST be
       derived from the corresponding prefix as follows:

       *  Its Valid Lifetime is the lower of the Valid Lifetime of the
          prefix and TEMP_VALID_LIFETIME.

       *  Its Preferred Lifetime is the lower of the Preferred Lifetime
          of the prefix and TEMP_PREFERRED_LIFETIME - DESYNC_FACTOR.

Notes:

The language of RFC 4941 has been 'upgraded' from RFC 3041 by
replacing the confusing language related to "global addresses"
by correctly speaking about "prefixes" when referring to
information obtained in RA Prefix Options.
Unfortunately, in one place this 'upgrade' has been missed.

Errata ID: 998

Status: Verified
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2007-10-12
Verifier Name: Brian Haberman
Date Verified: 2012-06-01

Section 6 says:

The second paragraph of Section 6 refers to the Source Address
Selection API Extension without giving any reference.  The related
Internet-Draft in the meantime has been published as RFC 5014,
less than two weeks after RFC 4941.
It would have been useful to place a pointer to that work-in-progress
(or the RFC, if publication were coordinated).

Errata ID: 3241

Status: Verified
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2007-10-12
Verifier Name: Brian Haberman
Date Verified: 2012-06-01

Section 3.4 says:

   When a temporary address becomes deprecated, a new one MUST be
   generated.  This is done by repeating the actions described in
   Section 3.3, starting at step 3).  [...]

It should say:

   When a temporary address becomes deprecated, a new one MUST be
   generated.  This is done by repeating the actions described in
   Section 3.3, starting at step 4).  [...]

Notes:

The bullets in Section 3.3 have been renumbered from RFC 3041,
necessitated by the insertion of a new bullet as #2.
In an internal reference in Section 3.4, this change has not been
reflected accordingly.

Status: Reported (1)

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

Source of RFC: ipv6 (int)

Errata ID: 4763

Status: Reported
Type: Technical

Reported By: Jiri Bohac
Date Reported: 2016-08-04

Section 5 says:

DESYNC_FACTOR -- A random value within the range 0 -
   MAX_DESYNC_FACTOR.  It is computed once at system start (rather than
   each time it is used) and must never be greater than
   (TEMP_VALID_LIFETIME - REGEN_ADVANCE).

It should say:

DESYNC_FACTOR -- A random value within the range 0 -
   MAX_DESYNC_FACTOR.  It is computed once at system start (rather than
   each time it is used) and must never be greater than
   (TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE).

Notes:

At various places in the RFC, DESYNC_FACTOR is used in a calculation like (TEMP_PREFERRED_LIFETIME - DESYNC_FACTOR) or (TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE - DESYNC_FACTOR). It needs to be smaller than (TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE) for the result of these calculations to be larger than zero. It's never used in a calculation together with TEMP_VALID_LIFETIME.

Status: Held for Document Update (4)

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

Source of RFC: ipv6 (int)

Errata ID: 3239

Status: Held for Document Update
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2007-10-12
Held for Document Update by: Brian Haberman
Date Held: 2012-06-01

Section 3 says:

On page 9, the 2nd numbered bullet in Section 3 says:

   2.  [...]
       Deprecated address can continue to be used for already
       established connections, but are not used to initiate new
       connections.  [...]

It should say:

   2.  [...]
       Deprecated addresses can continue to be used for already
       established connections, but are not used to initiate new
       connections.  [...]

Errata ID: 4404

Status: Held for Document Update
Type: Technical

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!

Errata ID: 3242

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2007-10-12
Held for Document Update by: Brian Haberman
Date Held: 2012-06-01

Section 3.5 says:

   The frequency at which temporary addresses changes depends on [...]

It should say:

   The frequency at which temporary addresses change depends on [...]

Errata ID: 3243

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2007-10-12
Held for Document Update by: Brian Haberman
Date Held: 2012-06-01

Section 3.6 says:

                                       [...].  Note that the pre-prefix
   setting can be applied at any granularity, and not necessarily on a
   per-subnet basis.

It should say:

                                       [...].  Note that the per-prefix
   setting can be applied at any granularity, and not necessarily on a
   per-subnet basis.

Status: Rejected (1)

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

Source of RFC: ipv6 (int)

Errata ID: 4594

Status: Rejected
Type: Technical

Reported By: Johanna Ullrich
Date Reported: 2016-01-14
Rejected by: Brian Haberman
Date Rejected: 2016-01-15

Section 3.2 says:


Notes:

The algorithm for interface identifier generation is flawed: An adversary is able to infer a client's history value from a sequence of observed addresses and is able to infer all future interface identifiers of this certain client annihilating the extension's intended purpose of privacy protection.

For a detailed explanation on the algorithm's drawbacks, please see my paper:
https://www.sba-research.org/wp-content/uploads/publications/Ullrich2015Privacy.pdf
--VERIFIER NOTES--
The issue raised goes beyond a fix via the errata system. This should be raised in the appropriate working group within the IETF.

Report New Errata



Search RFCs
Advanced Search
×