RFC Errata
Found 13 records.
Status: Verified (4)
RFC 3971, "SEcure Neighbor Discovery (SEND)", March 2005
Note: This RFC has been updated by RFC 6494, RFC 6495, RFC 6980
Source of RFC: send (int)
Errata ID: 3538
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-14
Verifier Name: Ralph Droms
Date Verified: 2013-03-10
Section 6.4.3 says:
Length The length of the option (including the Type, Length, Name Type, | Pad Length, and Name fields), in units of 8 octets.
It should say:
Length The length of the option (including the Type, Length, Name Type, | Pad Length, Name, and Padding fields), in units of 8 octets.
Notes:
mis-specification ?
Rationale: See the explanation for the 'Padding' field, at the bottom of page 35.
Errata ID: 3539
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-14
Verifier Name: Ralph Droms
Date Verified: 2013-03-10
Section 6.4.4 says:
Length The length of the option (including the Type, Length, Cert Type, | Pad Length, and Certificate fields), in units of 8 octets.
It should say:
Length The length of the option (including the Type, Length, Cert Type, | Reserved, Certificate, and Padding fields), in units of 8 octets.
Notes:
mis-specification ?
Rationale:
Apparently, there's no 'Pad Length' field in the Certificate Option;
the artwork on top of page 36 shows a 'Reserved' field in the same
octet where the Trust Anchor Option carries a 'Pad Length' field,
and the text contains a description of that 'Reserved' field.
According to the explanation for the 'Padding' field at the bottom
of page 36, the length of the 'Padding' field must be derived
implicitely from the ASN.1 encoding of the 'Certificate' field,
and the 'Length' field comprises the length of the 'Padding' field.
Note:
Because the extensible format potentially allows for other Cert Type
values and other Certificate encodings, I am in doubt whether the
decision to include a Reserved octet in place of a Pad Length octet
was very wise.
The current description of the 'Reserved' field will admit a future
revision of that decision.
Errata ID: 3540
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-14
Verifier Name: Ralph Droms
Date Verified: 2013-03-10
Section 6.4.5 says:
Future, backward- | compatible changes to the protocol may specify the contents of the | Reserved field or add new options; backward-incompatible changes may use different Code values.
It should say:
Future, backward- | compatible changes to the protocol MAY specify the contents of the | Reserved field or add new options; backward-incompatible changes MUST use different Code values.
Notes:
Section 6.4.5 vs. Section 6.4.6 -- contradiction!
Contrary to 6.4.5, the first paragraph of Section 6.4.6 says:
Future, backward-
compatible changes to the protocol MAY specify the contents of the
Reserved field or add new options; backward-incompatible changes MUST
use different Code values.
I suspect that the first "may" above should be a "MAY" and the second
"may" should have been a "MUST" as well.
If that's correct, the first paragraph of Section 6.4.5 should be corrected as above.
Errata ID: 2290
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Tony Cheneau
Date Reported: 2010-05-25
Verifier Name: Brian Haberman
Date Verified: 2012-10-04
Section 5.1 says:
CGA Parameters A variable-length field containing the CGA Parameters data structure described in Section 4 of [11]. ^^^^^^^^^
It should say:
CGA Parameters A variable-length field containing the CGA Parameters data structure described in Section 3 of [11]. ^^^^^^^^^
Notes:
The current text points to Section 4 of RFC 3972, which is "CGA Generation". I believe it should point to Section 3 that is "CGA Parameters and Hash Values".
Status: Held for Document Update (8)
RFC 3971, "SEcure Neighbor Discovery (SEND)", March 2005
Note: This RFC has been updated by RFC 6494, RFC 6495, RFC 6980
Source of RFC: send (int)
Errata ID: 3536
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-14
Held for Document Update by: Ralph Droms
Date Held: 2013-03-10
Section 6.4.1 says:
| ICMP length (derived from the IP length) MUST be 8 or more octets.
It should say:
| The ICMP length (derived from the IP length) MUST be greater than 8 octets.
Notes:
The last paragraph of Section 6.4.1, at the bottom of page 31, has several issues.
First of all, this sentence apparently does *not* belong to the
discussion of `Valid Options` above it; hence, it should be indented
one step less.
Next, I propose to add an initial article, 'The'.
But most importantly, I suspect that the ICMP lenght specification,
>= 8 , in fact should be: > 8 .
Unfortunately I cannot find a precise statement specifying clearly
that the Trust Anchor option is mandatory in the Certification Path
Solicitation Message, but the explanation 9 lines before the end of
the section,
The first (or only) Trust Anchor option MUST contain a DER
Encoded X.501 Name; see Section 6.4.3.
IMHO in fact does imply this.
If that is correct, the final line should be updated as above.
Ralph Droms - verifier note:
As the current text is not incorrect and there is some question about the issue, I will mark the errata as "hold for document update"
Errata ID: 960
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-14
Held for Document Update by: Ralph Droms
Section 2 says:
Neighbor Discovery Protocol (NDP) | The IPv6 Neighbor Discovery Protocol [7, 8]. The Neighbor Discovery Protocol is a part of ICMPv6 [6].
It should say:
Neighbor Discovery Protocol (NDP) | The IPv6 Neighbor Discovery Protocol [4, 5]. The Neighbor Discovery Protocol is a part of ICMPv6 [6].
Notes:
wrong reference tags. See Section 12.1, on page 50; the proper references are RFC 2461 [4] and RFC 2462 [5].
Errata ID: 3533
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-14
Held for Document Update by: Ralph Droms
Section 2 says:
Non-SEND node An IPv6 node that does not implement this specification but uses only the Neighbor Discovery protocol defined in RFCs 2461 and | 2462, as updated, without security.
It should say:
Non-SEND node An IPv6 node that does not implement this specification but uses only the Neighbor Discovery protocol defined in RFCs 2461 and | 2462, without security.
Notes:
Perhaps, there once was a reference to some work in progress,
e.g., what has become RFC 4311, or the 2461bis and 2462bis I-Ds,
and this reference was been removed only partially. Cleanup!
For an alternative text change, see the next item.
Errata ID: 3534
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-14
Held for Document Update by: Ralph Droms
Section 3 says:
[...] This section is not normative, and if this section and the original Neighbor Discovery RFCs are in | conflict, the original RFCs, as updated, take precedence.
It should say:
[...] This section is not normative, and if this section and the original Neighbor Discovery RFCs are in | conflict, the original RFCs, or any updates to these, take precedence.
Notes:
It is unclear what has been intended here. The rationale for Errata ID 3533
might apply here as well.
Errata ID: 3537
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-14
Held for Document Update by: Ralph Droms
Date Held: 2013-03-10
Section 6.4.2 says:
The ICMP length (derived from the IP length) MUST be 8 or more octets.
It should say:
The ICMP length (derived from the IP length) MUST be greater than 8 octets.
Notes:
Similar to the rationale for Errata ID 3536, I suspect that
the Certification Path Advertisement Message will always include
at least one Option.
Errata ID: 3541
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-14
Held for Document Update by: Ralph Droms
Section 6.4.6 says:
If there are multiple missing certificates, additional CPS | messages can be sent after getting a response to first one. However, the complete retrieval process may last at most CPS_RETRY_MAX seconds.
It should say:
If there are multiple missing certificates, additional CPS | messages can be sent after getting a response to the first one. However, the complete retrieval process may last at most CPS_RETRY_MAX seconds.
Notes:
missing article
Errata ID: 3542
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-14
Held for Document Update by: Ralph Droms
Date Held: 2013-03-10
Section 7.4 says:
This specification also does not apply to addresses | generated by the IPv6 stateless address autoconfiguration from a fixed interface identifiers (such as EUI-64). ... | The Target Address in Neighbor Advertisement is required to be equal to the source address of the packet, except in proxy Neighbor Discovery, which is not supported by this specification.
It should say:
This specification also does not apply to addresses | generated by the IPv6 stateless address autoconfiguration from fixed interface identifiers (such as EUI-64). ... | The Target Address in a Neighbor Advertisement is required to be equal to the source address of the packet, except in proxy Neighbor Discovery, which is not supported by this specification.
Notes:
a spurious article and 2 missing articles
Verifier note (Ralph Droms): The first fix still isn't correct; should be:
This specification also does not apply to addresses
| generated by IPv6 stateless address autoconfiguration from fixed
interface identifiers (such as EUI-64).
Errata ID: 3543
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-14
Held for Document Update by: Ralph Droms
Section 9.1 says:
| There may not be cryptographic binding in SEND between the link layer frame address and the IPv6 address. An unsecured link layer could allow nodes to spoof the link layer address of other nodes.
It should say:
| There may not be a cryptographic binding in SEND between the link layer frame address and the IPv6 address. An unsecured link layer could allow nodes to spoof the link layer address of other nodes.
Notes:
missing article
Status: Rejected (1)
RFC 3971, "SEcure Neighbor Discovery (SEND)", March 2005
Note: This RFC has been updated by RFC 6494, RFC 6495, RFC 6980
Source of RFC: send (int)
Errata ID: 3535
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-14
Rejected by: Ralph Droms
Date Rejected: 2013-03-10
Section 6.4.1 says:
A link-local unicast address assigned to the sending interface, | or to the unspecified address if no address is assigned to the sending interface.
It should say:
A link-local unicast address assigned to the sending interface, | or the unspecified address if no address is assigned to the sending interface.
Notes:
spurious word / grammar, and a clarification
--VERIFIER NOTES--
The original text is fine.