RFC Errata
Found 4 records.
Status: Verified (2)
RFC 4291, "IP Version 6 Addressing Architecture", February 2006
Note: This RFC has been updated by RFC 5952, RFC 6052, RFC 7136, RFC 7346, RFC 7371, RFC 8064
Source of RFC: ipv6 (int)
Errata ID: 3480
Status: Verified
Type: Technical
Publication Format(s) : TEXT
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
Errata ID: 6848
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Fabrice Verrac
Date Reported: 2022-02-12
Verifier Name: Eric Vyncke
Date Verified: 2022-04-06
Section Appendix A says:
Note: [EUI-64] actually defines 0xFF and 0xFF as the bits to be
inserted to create an IEEE EUI-64 identifier from an IEEE MAC-
48 identifier.
It should say:
Note: [EUI-64] actually defines 0xFF and 0xFE as the bits to be
inserted to create an IEEE EUI-64 identifier from an IEEE MAC-
48 identifier.
Notes:
Just seems to be a typo
-- Verifier note --
This is indeed a minor typo as the rest of the RFC is clear that 0xFF and 0xFE are used.
Status: Reported (2)
RFC 4291, "IP Version 6 Addressing Architecture", February 2006
Note: This RFC has been updated by RFC 5952, RFC 6052, RFC 7136, RFC 7346, RFC 7371, RFC 8064
Source of RFC: ipv6 (int)
Errata ID: 5716
Status: Reported
Type: Technical
Publication Format(s) : TEXT
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.
Errata ID: 6596
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Martin D Kealey
Date Reported: 2021-06-03
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.
It should say:
EITHER
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 "0" pieces, or two or more when
leading or trailing. The "::" can only appear once in an address.
OR
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 pieces of 16 bits of zeros,
or two or more when leading or trailing. The "::" can only appear
once in an address.
Notes:
1. The existing wording would permit "::" to be used in leading or trailing position to compress a single 16-bit piece, leading to the conclusion that "::0:0:0:0:0:0:1" is a valid way to write the loopback address, with eight colons.
Many consumers of textual IPv6 addresses would reject this out of hand as "too many colons", and it seems questionable that such an interpretation was ever intended. Enforcing this on producers would improve interoperability.
2. The preceding paragraphs defines "piece", but the undefined term "group" is used in this paragraph, so by changing that term I hope to clarify that this is a textual substitution, necessarily aligned to a multiple of 16 bits.
I am uncomfortable with the phrasing "pieces of 16 bits of zeros", but I offer it as a single-word change to effect my point (2); I leave it to the discretion of the editor which of my alternatives to adopt.