|
|
|
|
Found 1 record.
Source of RFC: ipv6 (int)
Errata ID: 998
Status: Reported
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2007-10-12
(1) Section 3 -- typo/grammar
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:
vv
2. [...]
| Deprecated addresses can continue to be used for already
established connections, but are not used to initiate new
connections. [...]
(2) Section 3.3 -- incomplete 'upgrade' of language
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.
On pp. 13/14, Section 3.3 of RFC 4941 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.
For consistency, and to avoid confusion, 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.
^^^^^^^^^^
(3) Section 3.4 -- out-of-sync internal reference
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.
On mid-page 14, at the beginning of Section 3.4, RFC 4941 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). [...]
^
(4) Section 3.5 -- typo/grammar (legacy)
The first line of Section 3.5 (on page 15) says:
| The frequency at which temporary addresses changes depends on [...]
^
It should say:
| The frequency at which temporary addresses change depends on [...]
(5) Section 3.6 -- typo
On page 16, the last sentence of the 2nd paragraph of Section 3.6 says:
vvv
| [...]. Note that the pre-prefix
setting can be applied at any granularity, and not necessarily on a
per-subnet basis.
It should presumably say:
vvv
| [...]. Note that the per-prefix
setting can be applied at any granularity, and not necessarily on a
per-subnet basis.
(6) Section 6 -- missing reference
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).