RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

RFC 5321, "Simple Mail Transfer Protocol", October 2008

Note: This RFC has been updated by RFC 7504

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: art

Errata ID: 4315
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Rodrigo Speller
Date Reported: 2015-03-27
Held for Document Update by: Barry Leiba
Date Held: 2015-03-28

Section 4.1.3 says:

   IPv6-full      = IPv6-hex 7(":" IPv6-hex)

   IPv6-comp      = [IPv6-hex *5(":" IPv6-hex)] "::"
                  [IPv6-hex *5(":" IPv6-hex)]
                  ; The "::" represents at least 2 16-bit groups of
                  ; zeros.  No more than 6 groups in addition to the
                  ; "::" may be present.

   IPv6v4-full    = IPv6-hex 5(":" IPv6-hex) ":" IPv4-address-literal

   IPv6v4-comp    = [IPv6-hex *3(":" IPv6-hex)] "::"
                  [IPv6-hex *3(":" IPv6-hex) ":"]
                  IPv4-address-literal
                  ; The "::" represents at least 2 16-bit groups of
                  ; zeros.  No more than 4 groups in addition to the
                  ; "::" and IPv4-address-literal may be present.

It should say:

   IPv6-full      = IPv6-hex 7(":" IPv6-hex)

   IPv6-comp      = "::" [IPv6-hex *6(":" IPv6-hex)]
                  | IPv6-hex "::" [IPv6-hex *5(":" IPv6-hex)]
                  | IPv6-hex 1(":" IPv6-hex) "::"
                  [IPv6-hex *4(":" IPv6-hex)]
                  | IPv6-hex 2(":" IPv6-hex) "::"
                  [IPv6-hex *3(":" IPv6-hex)]
                  | IPv6-hex 3(":" IPv6-hex) "::"
                  [IPv6-hex *2(":" IPv6-hex)]
                  | IPv6-hex 4(":" IPv6-hex) "::"
                  [IPv6-hex *1(":" IPv6-hex)]
                  | IPv6-hex 5(":" IPv6-hex) "::" [IPv6-hex]
                  | IPv6-hex 6(":" IPv6-hex) "::"
                  ; The "::" represents at least one 16-bit groups of
                  ; zeros.  No more than 7 groups in addition to the
                  ; "::" may be present.

   IPv6v4-full    = IPv6-hex 5(":" IPv6-hex) ":" IPv4-address-literal

   IPv6v4-comp    = ("::" [IPv6-hex *4(":" IPv6-hex) ":"] 
                  | IPv6-hex "::" [IPv6-hex *3(":" IPv6-hex) ":"]
                  | IPv6-hex 1(":" IPv6-hex) "::"
                  [IPv6-hex *2(":" IPv6-hex) ":"]
                  | IPv6-hex 2(":" IPv6-hex) "::"
                  [IPv6-hex *1(":" IPv6-hex) ":"]
                  | IPv6-hex 3(":" IPv6-hex) "::" [IPv6-hex ":"]
                  | IPv6-hex 4(":" IPv6-hex) "::")
                  IPv4-address-literal
                  ; The "::" represents at least one 16-bit groups of
                  ; zeros.  No more than 5 groups in addition to the
                  ; "::" and IPv4-address-literal may be present.

Notes:

I had the same impression that Michael Rushton (Errata 2467).

Searching about what says the others RFCs ([RFC 3986] , [RFC 4291] , [RFC 5952]), I believe that Michael Rushton's affirmative may be right.


Case 1 - Section 3.2.2 of [RFC 3986] says:

"(...) A sequence of one or more consecutive zero-valued 16-bit pieces within the address may be elided, omitting all their digits and leaving exactly two consecutive colons in their place to mark the elision." (sic).


Transcription of Section 3.2.2 of [RFC 3986]

"(...)

A 128-bit IPv6 address is divided into eight 16-bit pieces. Each piece is represented numerically in case-insensitive hexadecimal, using one to four hexadecimal digits (leading zeroes are permitted). The eight encoded pieces are given most-significant first, separated by colon characters. Optionally, the least-significant two pieces may instead be represented in IPv4 address textual format. A sequence of one or more consecutive zero-valued 16-bit pieces within the address may be elided, omitting all their digits and leaving exactly two consecutive colons in their place to mark the elision.

(...)"



Case 2 - Section 2.2 of [RFC 4291] says:

"(...) The use of "::" indicates one or more groups of 16 bits of zeros. (...)" (sic).


Transcription of Item 2, Section 2.2 of [RFC 4291]

"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.

(...)"



Case 3 - Recommendations of [RFC 5952]

In reply to the question of Errata 2467, was quoted the words of Section 4.2.2 of [RFC 5952], that recommends:

"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." (sic).


But the Section 4 of the same RFC, says:

"(...) The recommendation in this section SHOULD be followed by systems when generating an address to be represented as text, but all implementations MUST accept and be able to handle any legitimate [RFC4291] format."


Transcription of Section 4 and 4.2.2 of [RFC 5952]

"4. A Recommendation for IPv6 Text Representation

A recommendation for a canonical text representation format of IPv6 addresses is presented in this section. The recommendation in this document is one that complies fully with [RFC4291], is implemented by various operating systems, and is human friendly. The recommendation in this section SHOULD be followed by systems when generating an address to be represented as text, but all implementations MUST accept and be able to handle any legitimate [RFC4291] format. It is advised that humans also follow these recommendations when spelling an address.

(...)

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.

(...)"



Therefore, it is clear that the intent of what was said in Section 4.2.2 only serves to standardize the generation and not to interpretation of a IPv6 representation.



For more explanations see:

RFC 4291 - Errata 2702, 2735 and 2466
http://www.rfc-editor.org/errata_search.php?rfc=4291

RFC 4291 - Errata 2735 discussion
http://www.ietf.org/mail-archive/web/v6ops/current/msg07722.html



[RFC 3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.

[RFC 4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.

[RFC 5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010.

===== Verifier notes =====
The text in 5321 was correct at the time of publication, according to advice from the IPv6 folks. This was, of course, well before 5952 came out. This report has been noted in the notes for a future 5321bis document.

Report New Errata



Advanced Search