RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 10 records.

Status: Verified (1)

RFC 4291, "IP Version 6 Addressing Architecture", February 2006

Source of RFC: ipv6 (int)

Errata ID: 3480
Status: Verified
Type: Technical

Reported By: Erik Hugne
Date Reported: 2013-02-07
Verifier Name: Brian Haberman
Date Verified: 2013-03-16

Section 2.7 says:

Interface-Local scope spans only a single interface on a node
and is useful only for loopback transmission of multicast.

It should say:

Interface-Local scope spans only a single interface on a node 
and is useful only for loopback transmission of multicast.
Packets with interface-local scope received from another node 
must be discarded.

Notes:

It should be explicitly stated that interface-local scoped multicast packets
received from the link must be discarded.
The BSD implementation currently does this, but not Linux.
http://www.ietf.org/mail-archive/web/ipv6/current/msg17154.html

Status: Reported (1)

RFC 4291, "IP Version 6 Addressing Architecture", February 2006

Source of RFC: ipv6 (int)

Errata ID: 5716
Status: Reported
Type: Technical

Reported By: Dennis Ferguson
Date Reported: 2019-05-01

Section 2.5 says:

   A slightly sophisticated host (but still rather simple) may
   additionally be aware of subnet prefix(es) for the link(s) it is
   attached to, where different addresses may have different values for
   n:

It should say:

   For Link-Local unicast addresses, which comprise a flat address
   space that is reused on every link, the consideration above is all
   that is relevant. For Global Unicast addresses, however, a slightly
   sophisticated host (but still rather simple) may additionally be
   aware of subnet prefix(es) for the link(s) it is attached to, where
   different addresses may have different values for n:

Notes:

Text in several sections of 4291 seem to be logically inconsistent with respect to Link-Local unicast addresses. The inconsistency spans Sections 2.1, 2.5 and 2.5.6.

Section 2.5 says that unicast addresses, including Link-Local unicast addresses, on links a host is attached to have the following internal structure, providing a definition for "subnet prefix":

| n bits | 128-n bits |
+-------------------------------+---------------------------------+
| subnet prefix | interface ID |
+-------------------------------+---------------------------------+

Section 2.5.6 specifies that Link-Local unicast addresses have the following format:

| 10 |
| bits | 54 bits | 64 bits |
+----------+-------------------------+----------------------------+
|1111111010| 0 | interface ID |
+----------+-------------------------+----------------------------+

Applying the Section 2.5 definition, Link-Local unicast addresses hence have a subnet prefix of fe80::/64 on every link.

Section 2.1 says this about the addressing model:

Currently, IPv6 continues the IPv4 model in that a subnet prefix is
associated with one link.

Clearly the use of a same Link-Local unicast subnet prefix on every link is inconsistent with an addressing model that requires a subnet prefix to be unique to one link. The plain reading of this text is that it disagrees with itself, so either something needs to change to bring it into agreement or some explanation of how this is in fact consistent needs to be made. Since I don't know what the intent of this was I don't really know what needs fixing.

The proposed text hence reflects my personal biases; while I understand subnet prefix uniqueness to be foundational to the forwarding behaviour of Global Unicasts I have no idea what a "subnet prefix" even means in the context of Link-Local unicasts. The proposed text hence modifies Section 2.5 to exclude Link-Local addresses from the part of that section defining a "subnet prefix" and instead be defines them to provide a flat address space that is reused on every link. That is, Link-Local addresses are defined without a subnet prefix.

This leaves the Section 2.1 statement about subnet prefixes, and the forwarding behaviour implied by that, applicable to Global Unicast addresses but inapplicable to Link-Local addresses. Given this Section 2.5.6 can be read to be solely a constraint on Link-Local address construction, i.e. requiring SLAAC and other methods of Link-Local configuration to only produce addresses from that subset, without any implication for forwarding behaviour that "subnet prefix" might suggest.

That this general topic seems to produce periodic flurries of concern might be an indication that greater clarity in specification here might be useful.

Status: Held for Document Update (1)

RFC 4291, "IP Version 6 Addressing Architecture", February 2006

Source of RFC: ipv6 (int)

Errata ID: 1627
Status: Held for Document Update
Type: Editorial

Reported By: Yelland Mr Michael
Date Reported: 2007-03-02
Held for Document Update by: RFC Editor
Date Held: 2008-12-03

Section 2.7 says:

   Routers must not forward any multicast packets beyond of the scope
   indicated by the scop field in the destination multicast address.

It should say:

   Routers must not forward any multicast packets beyond the scope
   indicated by the scop field in the destination multicast address.

Notes:

extraneous "of"

Status: Rejected (7)

RFC 4291, "IP Version 6 Addressing Architecture", February 2006

Source of RFC: ipv6 (int)

Errata ID: 2702
Status: Rejected
Type: Technical

Reported By: Bassam Al-Khaffaf
Date Reported: 2011-02-01
Rejected by: Ralph Droms
Date Rejected: 2012-03-26

Section 2.3 says:

For example, the following are legal representations of the 60-bit
prefix 20010DB80000CD3 (hexadecimal):

   2001:0DB8:0000:CD30:0000:0000:0000:0000/60
   2001:0DB8::CD30:0:0:0:0/60
   2001:0DB8:0000:CD30::/60

It should say:

For example, the following are legal representations of the 60-bit
prefix 20010DB80000CD3 (hexadecimal):

   2001:0DB8:0000:CD30:0000:0000:0000:0000/60
   2001:0DB8:0000:CD30::/60

Notes:

According to the erratum reported on 2010-08-16 by Michael Rushton, the second text representation address of the example will be no more valid and should be taken away and keep the first and third ones.
This is because the use of "::" indicates two or more groups of 16 bits of zeros. Thank you
--VERIFIER NOTES--
Related to Bob Hinden's review of errata 2466:

I believe that this errata should be rejected. This was discussed on the v6ops mailing list around February 25, 2011. I responded:

http://www.ietf.org/mail-archive/web/v6ops/current/msg07741.html

The thread starts at:

http://www.ietf.org/mail-archive/web/v6ops/current/msg07722.html

Also, two errata were filed based on this one (Errata ID: 2735, Errata ID: 2702) that I think should also be rejected as they assume that this errata was correct.

Errata ID: 2735
Status: Rejected
Type: Technical

Reported By: Richard Hartmann
Date Reported: 2011-02-24
Rejected by: Ralph Droms
Date Rejected: 2012-03-26

Section 2.2 says:

2. Due to some methods of allocating certain styles of IPv6
      addresses, it will be common for addresses to contain long strings
      of zero bits.  In order to make writing addresses containing zero
      bits easier, a special syntax is available to compress the zeros.
      The use of "::" indicates one or more groups of 16 bits of zeros.
      The "::" can only appear once in an address.  The "::" can also be
      used to compress leading or trailing zeros in an address.


 For example, the following addresses

         2001:DB8:0:0:8:800:200C:417A   a unicast address
         FF01:0:0:0:0:0:0:101           a multicast address
         0:0:0:0:0:0:0:1                the loopback address
         0:0:0:0:0:0:0:0                the unspecified address

      may be represented as

         2001:DB8::8:800:200C:417A      a unicast address
         FF01::101                      a multicast address
         ::1                            the loopback address
         ::                             the unspecified address

It should say:

2. Due to some methods of allocating certain styles of IPv6
      addresses, it will be common for addresses to contain long strings
      of zero bits.  In order to make writing addresses containing zero
      bits easier, a special syntax is available to compress the zeros.
      The use of "::" indicates two or more groups of 16 bits of zeros.
      The "::" can only appear once in an address.  The "::" can also be
      used to compress leading or trailing zeros in an address.  All
      compressed groups of 16 bits of zeros MUST be aligned with their
      respective leading and trailing ":".

 For example, the following addresses

         2001:DB8:9300:0:12:0:0:417A    a unicast address
         FF01:0:0:0:0:0:0:101           a multicast address
         0:0:0:0:0:0:0:1                the loopback address
         0:0:0:0:0:0:0:0                the unspecified address

      may be represented as

         2001:DB8:9300:0:12::417A       a unicast address
         FF01::101                      a multicast address
         ::1                            the loopback address
         ::                             the unspecified address

      and MUST NOT be represented as

         2001:DB8:93::12:0:0:417A       an incorrect unicast address

Notes:

Errata ID: 2466 would change the text I am changing, as well.

My changed text includes the change from errata 2466 to avoid the likelyhood of human mistakes.

In case http://tools.ietf.org/html/draft-denog-v6ops-addresspartnaming becomes a RFC before this errata can be worked in, "group of 16 bits of zeros" should be replaced with "$new_term of zeros" or similar. As it looks today, $new_term will most likely end up being "hextet".



The current wording allows for 2001:DB8:9300:12:0:0:417A to be written as 2001:DB8:93::12:0:0:417A which is clearly wrong and against the intentions behind the relevant RFCs. While RFC 5952 puts additional constraints on compression, it still allows for the incorrect example given above.

Thus, alignment of 16 bit groups of zeros along ":" is enforced specifically.
--VERIFIER NOTES--
Related to Bob Hinden's report on errata 2466:

I believe that this errata should be rejected. This was discussed on the v6ops mailing list around February 25, 2011. I responded:

http://www.ietf.org/mail-archive/web/v6ops/current/msg07741.html

The thread starts at:

http://www.ietf.org/mail-archive/web/v6ops/current/msg07722.html

Also, two errata were filed based on this one (Errata ID: 2735, Errata ID: 2702) that I think should also be rejected as they assume that this errata was correct.

Errata ID: 4406
Status: Rejected
Type: Technical

Reported By: Peter Paluch
Date Reported: 2015-06-29
Rejected by: Brian Haberman
Date Rejected: 2015-06-30

Section 2.5.6 says:

   Link-Local addresses are for use on a single link.  Link-Local
   addresses have the following format:

   |   10     |
   |  bits    |         54 bits         |          64 bits           |
   +----------+-------------------------+----------------------------+
   |1111111010|           0             |       interface ID         |
   +----------+-------------------------+----------------------------+

It should say:

   Link-Local addresses are for use on a single link.  Link-Local
   addresses have the following format:

   |   10     |
   |  bits    |         54 bits         |          64 bits           |
   +----------+-------------------------+----------------------------+
   |1111111010|     arbitrary value     |       interface ID         |
   +----------+-------------------------+----------------------------+

Notes:

Section 2.4 of this RFC states that link-local addresses are identified by having the prefix FE80::/10. According to this prefix, the entire range of link-local addresses covers all addresses within the range of FE80:: through FEBF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF.

The format of link-local addresses as stated in Section 2.5.6 seems to partially contradict Section 2.4 in that it fixes the internal 54 bits between the 10-bit prefix and the IID to the value of 0. If that was the case then the prefix of link-local addresses would have been in fact FE80::/64 instead of FE80::/10, and the range of link-local addresses would have been limited to FE80:: through FE80::FFFF:FFFF:FFFF:FFFF. Thus, the definition of link-local addresses as follows from Section 2.4 does not align with the definition of link-local addresses as presented in Section 2.5.6.

I suggest resolving this internal contradiction by explicitly stating in Section 2.5.6 that the internal 54 bits of a link-local address that follow the FE80::/10 prefix can be of an arbitrary value.

Thank you!
--VERIFIER NOTES--
Section 2.4 reserves the FE80::/10 prefix for use on the local link. Section 2.5.6 specifies that the current definition of a link-local address falls in the FE80::/64 prefix. The suggested change would be a technical change to a consensus-based decision. The re-definition of the link-local address would need to be driven by a draft updating RFC 4291.

Errata ID: 2466
Status: Rejected
Type: Editorial

Reported By: Michael Rushton
Date Reported: 2010-08-16
Rejected by: Ralph Droms
Date Rejected: 2012-03-26

Section 2.2.2 says:

In order to make writing addresses containing zero
      bits easier, a special syntax is available to compress the zeros.
      The use of "::" indicates one or more groups of 16 bits of zeros.
      The "::" can only appear once in an address.

It should say:

In order to make writing addresses containing zero
      bits easier, a special syntax is available to compress the zeros.
      The use of "::" indicates two or more groups of 16 bits of zeros.
      The "::" can only appear once in an address.

Notes:

--VERIFIER NOTES--
Bob Hinden evaluated this errata:

I believe that this errata should be rejected. This was discussed on the v6ops mailing list around February 25, 2011. I responded:

http://www.ietf.org/mail-archive/web/v6ops/current/msg07741.html

The thread starts at:

http://www.ietf.org/mail-archive/web/v6ops/current/msg07722.html

Also, two errata were filed based on this one (Errata ID: 2735, Errata ID: 2702) that I think should also be rejected as they assume that this errata was correct.

Errata ID: 863
Status: Rejected
Type: Editorial

Reported By: Yelland Mr Michael
Date Reported: 2007-03-02
Rejected by: RFC Editor
Date Rejected: 2008-12-03

Section 2.7 says:

   Nodes must not originate a packet to a multicast address whose scop
   field contains the reserved value 0; if such a packet is received, it
   must be silently dropped.  Nodes should not originate a packet to a
   multicast address whose scop field contains the reserved value F; ...

It should say:

   Nodes must not originate a packet to a multicast address whose scope
   field contains the reserved value 0; if such a packet is received, it
   must be silently dropped.  Nodes should not originate a packet to a
   multicast address whose scope field contains the reserved value F; ...

Notes:

Typo: scop --> scope (2 times)

-- RATIONALE FOR REJECTION --

This isn't a typo. The field is named "scop". See Section 2.7:

scop is a 4-bit multicast scope value used to limit the scope of
the multicast group.

Thanks to Bob Hinden for pointing this out.

This report was incorrectly marked "Verified" from 2007-11-01 to 2008-12-03.

Errata ID: 864
Status: Rejected
Type: Editorial

Reported By: Yelland Mr Michael
Date Reported: 2007-03-02
Rejected by: RFC Editor
Date Rejected: 2008-12-03

Section 2.7 says:

   Routers must not forward any multicast packets beyond of the scope
   indicated by the scop field in the destination multicast address.

It should say:

   Routers must not forward any multicast packets beyond the scope
   indicated by the scope field in the destination multicast address.

Notes:

Typo: scop --> scope; extraneous "of"

-- RATIONALE FOR REJECTION --

This isn't a typo. The field is named "scop". See Section 2.7:

scop is a 4-bit multicast scope value used to limit the scope of
the multicast group.

Thanks to Bob Hinden for pointing this out.

This report was incorrectly marked "Verified" from 2007-11-01 to 2008-12-03.

[There is an extraneous "of", which has been listed in a separate report: Errata ID 1627.]

Errata ID: 865
Status: Rejected
Type: Editorial

Reported By: Yelland Mr Michael
Date Reported: 2007-03-02
Rejected by: RFC Editor
Date Rejected: 2007-12-03

Section 2.7 says:

   Nodes must not originate a packet to a multicast address whose scop
   field contains the reserved value 0; if such a packet is received, it
   must be silently dropped.  Nodes should not originate a packet to a
   multicast address whose scop field contains the reserved value F; ...

It should say:

   Nodes must not originate a packet to a multicast address whose scope
   field contains the reserved value 0; if such a packet is received, it
   must be silently dropped.  Nodes should not originate a packet to a
   multicast address whose scope field contains the reserved value F; ...

Notes:

Typo: scop --> scope (2 times)

-- RATIONALE FOR REJECTION --

This isn't a typo. The field is named "scop". See Section 2.7:

scop is a 4-bit multicast scope value used to limit the scope of
the multicast group.

Thanks to Bob Hinden for pointing this out.

This report was incorrectly marked "Verified" from 2007-11-01 to 2008-12-03.

Report New Errata