RFC Errata
Found 11 records.
Status: Verified (1)
RFC 5952, "A Recommendation for IPv6 Address Text Representation", August 2010
Source of RFC: 6man (int)
Errata ID: 2498
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mohamed Boucadair
Date Reported: 2010-08-23
Verifier Name: Brian Haberman
Date Verified: 2012-06-01
Section 6 says:
"This is due to the "::"usage in IPv6 addresses."
It should say:
"This is due to the ":" usage in IPv6 addresses."
Status: Reported (2)
RFC 5952, "A Recommendation for IPv6 Address Text Representation", August 2010
Source of RFC: 6man (int)
Errata ID: 4985
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Julian de Prado
Date Reported: 2017-03-31
Section 2.2 says:
In cases where there is more than one field of only zeros, there is a choice of how many fields can be shortened. 2001:db8:0:0:0::1 2001:db8:0:0::1 2001:db8:0::1 2001:db8::1
It should say:
In cases where there is more than one field of only zeros,there is a choice of how many fields can be shortened, but must be shortened to its maximum capability. 2001:db8:0:0:0::1 is NOT acceptable 2001:db8:0:0::1 is NOT acceptable 2001:db8:0::1 is NOT acceptable 2001:db8::1 is CORRECT
Notes:
Applying section 4.2.1
Errata ID: 6272
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Felipe Gasper
Date Reported: 2020-09-02
Section 4.2.1 says:
The line > The use of the symbol "::" MUST be used to its maximum capability. … contradicts the next section, which states that single-0 fields are not reduced. i.e., this: > 2001:db8:0:1:1:1:1:1 … is longer than: > 2001:db8::1:1:1:1:1 Thus, the standard does not, in all cases, require that "::" be used to its maximum capability.
It should say:
The first line of 4.2.1 should be amended to be consistent with section 4.2.2 > The use of the symbol "::" MUST be used to its maximum capability to reduce consecutive 16-bit 0 fields.
Status: Held for Document Update (2)
RFC 5952, "A Recommendation for IPv6 Address Text Representation", August 2010
Source of RFC: 6man (int)
Errata ID: 3218
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Rodrigo Curado
Date Reported: 2012-05-09
Held for Document Update by: Brian Haberman
Section 3.1.4 says:
Network diagrams and blueprints often show what IP addresses are assigned to a system devices.
It should say:
Network diagrams and blueprints often show which IP addresses are assigned to which systems devices.
Notes:
Improved grammar and correction to mismatch between singular and plural usage.
Errata ID: 3219
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Rodrigo Curado
Date Reported: 2012-05-09
Held for Document Update by: Brian Haberman
Section 3.1.4 says:
In times of trouble shooting there may be a need to search
It should say:
In times of troubleshooting there may be a need to search
Notes:
"troubleshooting" should be written as one word
Status: Rejected (6)
RFC 5952, "A Recommendation for IPv6 Address Text Representation", August 2010
Source of RFC: 6man (int)
Errata ID: 2656
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: D. Stussy
Date Reported: 2010-12-02
Rejected by: Brian Haberman
Date Rejected: 2012-05-30
Section 4.3 says:
4.3. Lowercase The characters "a", "b", "c", "d", "e", and "f" in an IPv6 address MUST be represented in lowercase.
It should say:
4.3. Case of Alphabetic Digits. The digits "A" through "F" in an IPv6 address MUST be represented in upper case. User and user derived input may be represented using lower case.
Notes:
Historically from the 1960's, hexidecimal digits other than decimal digits are represented by upper case letters. Lower case letters may have become acceptable as user input, but such resulted from lazy programmers who couldn't manage to hit the shift key on their keyboards. However, lower case is not acceptable for digit output. Many early assemblers would not even accept lower case as valid input digits except where the radix base exceeded 36 (thus exhausting all upper case values). This poor programming practice should not be allowed to be codified into any Internet standard.
References:
- Struble, George W., "Assembler Language Programming: The IBM System/360 and /370." Addison-Wesley Publishing Co., 1969 and 1975 (Second Edition), Page 6. ISBN 0-201-7322-6
- Barden, William Jr., "TRS-80 Assembly-Language Programming." Tandy Corporation, 1979, page 14. Library of Congress #79-63607
- Leventhal, Lance A., "6502 Assembly Language Programming." Osborne McGraw-Hill, 1979 and 1986 (Second Edition), Page 1-4. ISBN 0-07-881216-X
- Intel Corporation, "Intel486 Microprocessor Family Programmer's Reference Manual." 1995, Page 1-8 (Section 1.3.4). No ISBN or LoC #.
- Cress, Paul, Dirksen, Paul, and Grahm, J. Wesley, "Fortran IV with WatFor and WatFiv." Prentice-Hall, 1968 and 1970, Page 245. LoC 74-129241
- Mano, M. Morris, "Computer System Architecture." Prentice-Hall, 1982, Page 79. ISBN 0-13-166611-8
- Higgins, Richard J., "Electronics with Digital and Analog Integrated Circuits." Prentice-Hall, 1983, Page 60. ISBN 0-13-250704-8
However, I also note this ONE source permits mixed case:
- Kernighan, Brian W. & Ritchie, Dennis M., "The C Programming Language", Prentice Hall, 1978 (First Edition), Page 180. ISBN 0-13-110163-3
Many other pre-1990 computer science and engineering books show hexidecimal non-decimal digits as upper case only and NEVER as lower case. However, I could not find pages in them defining the lettered-digits as upper case only despite their consistent usage of upper case printing.
--VERIFIER NOTES--
This errata is attempting to overturn the clear consensus of the WG.
Errata ID: 2872
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Richard J. Smith
Date Reported: 2011-07-28
Rejected by: Brian Haberman
Date Rejected: 2012-06-01
Section 5 says:
For these addresses, mixed notation is RECOMMENDED if the following condition is met: the address can be distinguished as having IPv4 addresses embedded in the lower 32 bits solely from the address field through the use of a well-known prefix.
It should say:
For these addresses, mixed notation is RECOMMENDED if the following conditions are met: the address can be distinguished as having IPv4 addresses embedded in the lower 32 bits solely from the address field through the use of a well-known prefix, and the entire address is not either the unspecified IPv6 address "::" or the loopback IPv6 address "::1".
Notes:
RFC-4291 defines the 80-bit all-zeros prefix as indicating an "IPv4-compatible IPv6 address". Without further clarification in section 5 of RFC-5952, the recommended formatting of the IPv6 unspecified address would be "::0.0.0.0", and the recommended formatting of the IPv6 loopback address would be "::0.0.0.1". Neither of these recommended representations is desirable.
--VERIFIER NOTES--
::1 and :: are more specific and not part of the reserved block for IPv4 compatible addresses.
Errata ID: 3884
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Richard Hartmann
Date Reported: 2014-02-06
Rejected by: Brian Haberman
Date Rejected: 2014-02-12
Section 4.2.2. says:
4.2.2. Handling One 16-Bit 0 Field The symbol "::" MUST NOT be used to shorten just one 16-bit 0 field. For example, the representation 2001:db8:0:1:1:1:1:1 is correct, but 2001:db8::1:1:1:1:1 is not correct.
It should say:
4.2.2. Incorrect use of "::" The symbol "::" MUST NOT be used to shorten just one 16-bit 0 field. For example, the representation 2001:db8:0:1:1:1:1:1 is correct, but 2001:db8::1:1:1:1:1 is not correct. The symbol "::" MUST NOT be used just so. For example, the representation 2001:db8:1:1:1:1:1:1 is correct, but 2001:db8:1:1::1:1:1:1 is not correct.
Notes:
You would think this should be obvious, but I have seen actual discussions that 2001:db8:1:1::1:1:1:1 is correct syntax. Explicitly forbidding this form does no harm and stops all discussions in this direction.
Thanks for your work.
--VERIFIER NOTES--
As agreed to by the document authors and the submitter, there is a reference to RFC 4291 that addresses the concern.
Errata ID: 4483
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: André Melancia
Date Reported: 2015-09-26
Rejected by: Brian Haberman
Date Rejected: 2015-09-28
Section 4.3 says:
—
It should say:
—
Notes:
Errata ID 2656, reported by D. Stussy in 2010-12-02 is CORRECT and perfectly justified.
This was however rejected on 2012-05-30. Justification on "verified notes" states "This errata is attempting to overturn the clear consensus of the WG.", which is WRONG, since WG consensus applies to the whole document, not specifically to section 4.3 or its unjustified and arbitrary lowercase conventioning.
There is no technical reason why lowercase "must" or "should" be used, instead, HISTORICALLY (which for any IETF work has been the "de facto" rule) uppercase has been used (see full justification in Errata ID 2656 mentioned above).
Additionally, and considering that modern devices are able to properly handle case changes without performance losses, the WG should discuss removing this rule altogether.
--VERIFIER NOTES--
The consensus of the working group was to employ lowercase despite your arguments. This erratum is attempting to overturn the consensus of the WG during the publication of this RFC.
Errata ID: 4900
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Krzyzaniak
Date Reported: 2017-01-10
Rejected by: Erik Kline
Date Rejected: 2021-12-27
Section 4.2.2. says:
Handling One 16-Bit 0 Field The symbol "::" MUST NOT be used to shorten just one 16-bit 0 field. For example, the representation 2001:db8:0:1:1:1:1:1 is correct, but 2001:db8::1:1:1:1:1 is not correct.
It should say:
But Section 2.2. Zero Compression
says:
'A special syntax is available to compress the zeros. The use of
"::" indicates one or more groups of 16 bits of zeros.'
It is possible to select whether or not to omit just one 16-bit 0
field.
2001:db8:aaaa:bbbb:cccc:dddd::1
2001:db8:aaaa:bbbb:cccc:dddd:0:1
Notes:
In 2.2 :: for only one 16-bit 0 filed :: is used
4.2.2 says MUST NOT -RFC 2119 says
2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the
definition is an absolute prohibition of the specification.
--VERIFIER NOTES--
Valid versus canonical forms; see https://www.rfc-editor.org/errata/eid4986 for links to further discussion.
Errata ID: 4986
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julian de Prado
Date Reported: 2017-03-31
Rejected by: Erik Kline
Date Rejected: 2021-12-27
Section 2.2 says:
'A special syntax is available to compress the zeros. The use of "::" indicates one or more groups of 16 bits of zeros.'
It should say:
'A special syntax is available to compress the zeros. The use of "::" indicates two or more groups of 16 bits of zeros.'
Notes:
"indicates one" should be written as "indicates two"
for example:
'A special syntax is available to compress the zeros. The use of
"::" indicates two or more groups of 16 bits of zeros.'
2001:db8:aaaa:bbbb:cccc::1
2001:db8:aaaa:bbbb:cccc:0:0:1
--VERIFIER NOTES--
RFC 4291, section 2.2, #2 is clear that the current text is valid. Section 4.2.2 contains a specific recommendation for the defined canonical form in this situation. The canonical form is (must be) valid, but not all valid forms are canonical (of necessity :-).
To reach the working group discussion see this thread: https://mailarchive.ietf.org/arch/msg/ipv6/41x17WLwxBoS6AAtH6p0nuC84sk/