errata logo graphic

Found 4 records.

Status: Verified (1)

RFC4294, "IPv6 Node Requirements", April 2006

Note: This RFC has been obsoleted by RFC6434

Source of RFC: ipv6 (int)

Errata ID: 139

Status: Verified
Type: Technical

Reported By: Mark Andrews
Date Reported: 2006-04-11

Section 5.1 says:

   Those nodes are NOT RECOMMENDED to support the experimental A6 and
   DNAME Resource Records [RFC-3363].

It should say:

   Those nodes are NOT RECOMMENDED to support the experimental A6
   Resource Records [RFC-3363].


Status: Held for Document Update (2)

RFC4294, "IPv6 Node Requirements", April 2006

Note: This RFC has been obsoleted by RFC6434

Source of RFC: ipv6 (int)

Errata ID: 1915

Status: Held for Document Update
Type: Editorial

Reported By: Thorsten Ulbricht
Date Reported: 2009-10-14
Held for Document Update by: Brian Haberman

Section 5.2 says:

5.3.3.  Use of Router Advertisements in Managed Environments

It should say:

5.2.3.  Use of Router Advertisements in Managed Environments


Errata ID: 1939

Status: Held for Document Update
Type: Editorial

Reported By: Thorsten Ulbricht
Date Reported: 2009-11-03
Held for Document Update by: Brian Haberman

Section 12.1 says:

   [RFC-3484]     Frye, R., Levi, D., Routhier, S., and B. Wijnen,
                  "Coexistence between Version 1, Version 2, and Version
                  3 of the Internet-standard Network Management
                  Framework", BCP 74, RFC 3584, August 2003.

It should say:

   [RFC-3484]     Draves, R., "Default Address Selection for Internet
                  Protocol version 6 (IPv6)", RFC 3484, February
                  2003.

Notes:

wrong reference


Status: Rejected (1)

RFC4294, "IPv6 Node Requirements", April 2006

Note: This RFC has been obsoleted by RFC6434

Source of RFC: ipv6 (int)

Errata ID: 138

Status: Rejected
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2006-04-18
Rejected by: Brian Haberman
Date Rejected: 2012-05-09

 

(1) Page 7, Section 4.4

The RFC 4294 text says:

  4.4.  ICMP for the Internet Protocol Version 6 (IPv6) - RFC 2463

     ICMPv6 [RFC-2463] MUST be supported.

It should say:

  4.4.  ICMP for the Internet Protocol Version 6 (IPv6) - RFC 4443

     ICMPv6 [RFC-4443] MUST be supported.

The title of Section 4.4 in the Table of Contents should be
adapted accordingly.

Rationale: RFC 4443 (replacing and obsoleting RFC 2463) has been
published exactly 3 weeks before RFC 4294, and hence should be
used as the currently valid reference.


(2) Page 7, Section 4.5.1

RFC 4294 says:

  4.5.1.  IP Version 6 Addressing Architecture - RFC 3513

     The IPv6 Addressing Architecture [RFC-3513] MUST be supported as
     updated by [RFC-3879].

It should say:

  4.5.1.  IP Version 6 Addressing Architecture - RFC 4291

     The IPv6 Addressing Architecture [RFC-4291] MUST be supported.

Rationale: RFC 4291 (replacing and obsoleting RFC 3513, and thereby
incorporating RFC 3879) has been published more than 8 weeks before
RFC 4294, and hence should be used as the currently valid reference.


(3) Page 8, Section 5.1

RFC 4294 says:

     DNS is described in [RFC-1034], [RFC-1035], [RFC-3152], [RFC-3363],
     and [RFC-3596].  [...]

It should say:

     DNS is described in [RFC-1034], [RFC-1035], [RFC-3363], and
     [RFC-3596].  [...]

And subsequently, where RFC 4294 says,

  -  reverse addressing in ip6.arpa using PTR records [RFC-3152];

it should say:

  -  reverse addressing in ip6.arpa using PTR records [RFC-3596];

Rationale: RFC 3152 has been obsoleted and incorporated into RFC 3596.


(4) Page 10, Section 6.1.1

RFC 4294 says:

  6.1.1.  Transition Mechanisms for IPv6 Hosts and Routers - RFC 2893

It should say:

  6.1.1.  Transition Mechanisms for IPv6 Hosts and Routers - RFC 4213

Rationale: RFC 4213 (replacing and obsoleting RFC 2893) has been
published more than 6 months before RFC 4294, and hence should be
used consistently as the currently valid reference.  (The text body
of the section has been updated accordingly, before publication.)


(5) Page 11, Section 8.2

RFC 4294 says:

  8.2.  Security Protocols

     ESP [RFC-4303] MUST be supported.  AH [RFC-4302] MUST be supported.

It should say:

  8.2.  Security Protocols

     ESP [RFC-4303] MUST be supported.  AH [RFC-4302] MAY be supported.

Rationale: The new IPsec RFCs purposely have changed the requirement
level for AH.  From RFC 4301, page 9, 1st paragraph of Section 3.2 :

               [...]  IPsec implementations MUST support ESP and MAY
   support AH. (Support for AH has been downgraded to MAY because
   experience has shown that there are very few contexts in which ESP
   cannot provide the requisite security services.  Note that ESP can be
   used to provide only integrity, without confidentiality, making it
   comparable to AH in most contexts.)

In Section 13, RFC 4301 lists the differences from RFC 2401,
and it states on page 74:

   o Support for AH in both IPv4 and IPv6 is no longer required.

RFC 4294 does not give any arguments to override these statements.

(The IPsec references in RFC 4294 apparently have been changed
 shortly before publication without due adaptation of the text.)


(6) Section 12.1, Normative References :

- The reference [RFC-2463] should be replaced by a reference to
  RFC 4443 according to item (1) above.

- The reference [RFC-3152] (last item on page 14) should be deleted.
  That RFC has been obsoleted long time ago, and the material has been
  incorporated into RFC 3596 (see the entry [RFC-3596] on page 15)
  according to item (3) above.

- The reference [RFC-3513] should be replaced by an entry [RFC-4291],
  containing the proper reference to RFC 4291, according to item (2)
  above.

- The reference [RFC-3879] is not needed any more according to
  item (2) above; the material from RFC 3879 has been incorporated
  into RFC 4291, the successor of RFC 3513 -- see item (2) above.

Notes:

from pending
--VERIFIER NOTES--
This RFC is obsolete and new implementations should be referring to RFC 6434.


Report New Errata