RFC Errata
Found 10 records.
Status: Verified (4)
RFC 4941, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", September 2007
Note: This RFC has been obsoleted by RFC 8981
Source of RFC: ipv6 (int)
Errata ID: 3240
Status: Verified
Type: Technical
Publication Format(s) : TEXT
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: 4763
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jiri Bohac
Date Reported: 2016-08-04
Verifier Name: Erik Kline
Date Verified: 2021-01-28
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.
Errata ID: 998
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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: Held for Document Update (4)
RFC 4941, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", September 2007
Note: This RFC has been obsoleted by RFC 8981
Source of RFC: ipv6 (int)
Errata ID: 3239
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
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
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!
Errata ID: 3242
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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 (2)
RFC 4941, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", September 2007
Note: This RFC has been obsoleted by RFC 8981
Source of RFC: ipv6 (int)
Errata ID: 4594
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
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.
Errata ID: 5182
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Erik Kline
Date Reported: 2017-11-13
Rejected by: Erik Kline
Date Rejected: 2021-01-28
Section 3.6 says:
Devices implementing this specification MUST provide a way for the end user to explicitly enable or disable the use of temporary addresses.
It should say:
Devices implementing this specification SHOULD provide a way for the end user to explicitly enable or disable the use of temporary addresses.
Notes:
Allowing users to disable privacy features is not something that should be mandatory.
--VERIFIER NOTES--
It would be bad form, I suspect, for me to verify my own erratum. =)
As 4941bis is in the works, I'll Reject this and consider whether to (re)submit an erratum for the new document once published.