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

Errata ID: 2735
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
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.

Report New Errata