errata logo graphic

Found 13 records.

Status: Verified (4)

RFC3971, "SEcure Neighbor Discovery (SEND)", March 2005

Source of RFC: send (int)

Errata ID: 3538

Status: Verified
Type: Technical

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

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

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

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)

RFC3971, "SEcure Neighbor Discovery (SEND)", March 2005

Source of RFC: send (int)

Errata ID: 3536

Status: Held for Document Update
Type: Technical

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

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

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

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

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

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

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

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)

RFC3971, "SEcure Neighbor Discovery (SEND)", March 2005

Source of RFC: send (int)

Errata ID: 3535

Status: Rejected
Type: Editorial

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.


Report New Errata