Subject: Re: [Editorial Errata Reported] RFC5952 (4986)

From: Tim Chown <[email-masked]>
Date: Sat, 1 Apr 2017 23:26:14 +0000

Hi Jan,

> On 31 Mar 2017, at 17:07, Jan Zorz - Go6 <[email-masked]> wrote:
> 
> On 31/03/2017 17:52, RFC Errata System wrote:
>> Original Text
>> -------------
>> 'A special syntax is available to compress the zeros. The use of
>> "::" indicates one or more groups of 16 bits of zeros.'
>> 
>> 
>> Corrected Text
>> --------------
>> '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
> 
> Hi,
> 
> I don't agree with errata entirely.
> 
> 2001:db8:aaaa:bbbb:cccc:dddd::1 expands to 2001:db8:aaaa:bbbb:cccc:dddd:0:1
> 
> So it's one or more groups of 16 bits of zeros.

Note you cannot reduce just one group of zeroes with ::, so the above example of 2001:db8:aaaa:bbbb:cccc:dddd::1 must be written 2001:db8:aaaa:bbbb:cccc:dddd:0:1 (see 4.2.2 of RFC5952).

Tim

> Cheers, Jan Zorz
> 
>> 
>> Instructions:
>> -------------
>> This erratum is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party
>> can log in to change the status and edit the report, if necessary.
>> 
>> --------------------------------------
>> RFC5952 (draft-ietf-6man-text-addr-representation-07)
>> --------------------------------------
>> Title               : A Recommendation for IPv6 Address Text Representation
>> Publication Date    : August 2010
>> Author(s)           : S. Kawamura, M. Kawashima
>> Category            : PROPOSED STANDARD
>> Source              : IPv6 Maintenance
>> Area                : Internet
>> Stream              : IETF
>> Verifying Party     : IESG
>> 
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [email-masked]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Tim Chown <[email-masked]>
Date: Sat, 1 Apr 2017 23:30:00 +0000

Hi again (hit send too soon!),

> On 2 Apr 2017, at 00:26, Tim Chown <[email-masked]> wrote:
> 
> Hi Jan,
> 

So this might be the point the filer of the erratum is making, when referring to the recommendation of section 4 as a whole?

Tim

---

From: Doug Barton <[email-masked]>
Date: Sun, 2 Apr 2017 14:05:52 -0700

On 03/31/2017 09:21 AM, Bob Hinden wrote:
> Hi,
>
>> On Mar 31, 2017, at 10:52 AM, RFC Errata System <[email-masked]> wrote:
>>
>> The following errata report has been submitted for RFC5952,
>> "A Recommendation for IPv6 Address Text Representation".
>>
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata_search.php?rfc=5952&eid=4986
>>
>> Type: Editorial
>> Reported by: Julian de Prado <[email-masked]>
>>
>> Section: 2.2
>>
>> Original Text
>> -------------
> That is not correct.  RFC4291, where the “::” syntax is defined, says in Section 2.2:
>
>    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.
>
> Bob

+1

---

From: Tim Chown <[email-masked]>
Date: Sun, 2 Apr 2017 21:52:22 +0000

On 2 Apr 2017, at 22:05, Doug Barton <[email-masked]<mailto:[email-masked]>> wrote:

On Mar 31, 2017, at 10:52 AM, RFC Errata System <[email-masked]<mailto:[email-masked]>> wrote:

Section: 2.2

Original Text
-------------

Corrected Text
--------------

Bob

+1

So should Section 4.2.2 stand, on not shortening one 16-bit field of zeros?
https://tools.ietf.org/html/rfc5952#section-4.2.2

The rationale for that section given in earlier versions of the draft up until -04 says ""::" should not be used to shorten just one 16 bit 0 field for it would tend to mislead that there are more than one 16 bit field that is shortened”, which seems a bit weak, and at odds with RFC4291 as above?
https://tools.ietf.org/html/draft-ietf-6man-text-addr-representation-04#section-4.2.2

Tim

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Doug Barton <[email-masked]>
Date: Sun, 2 Apr 2017 15:09:07 -0700

On 04/02/2017 02:52 PM, Tim Chown wrote:
>>>> On Mar 31, 2017, at 10:52 AM, RFC Errata System
>>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>>

I wasn't involved in the 5952 discussion, so it would be hard for me to 
comment. On principle though I would say no, because ...

> The rationale for that section given in earlier versions of the draft up
> until -04 says ""::" should not be used to shorten just one 16 bit 0
> field for it would tend to mislead that there are more than one 16 bit
> field that is shortened”, which seems a bit weak, and at odds with
> RFC4291 as above?

... I find it sad that A) people could think that this is a problem, and 
B) that people who are confused about how many 16 bit fields make up an 
IPv6 address could possibly get more confused by how many fields are 
being replaced by all-zeros. (Is 1:2:3:4:5:6::8 really ambiguous? 
Seriously?)

So if updating 4.2.2 of 5952 will make things more clear for people, it 
should probably be done.

Doug

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Mon, 3 Apr 2017 01:03:37 +0200

> being replaced by all-zeros. (Is 1:2:3:4:5:6::8 really ambiguous?

In real world - compression and decompression of just 16 bits between 
the :: simply works.

Cheers, Jan

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 3 Apr 2017 08:00:16 +0200 (CEST)

On Mon, 3 Apr 2017, Jan Zorz - Go6 wrote:

> In real world - compression and decompression of just 16 bits between the :: 
> simply works.

Saying that 1:2:3:4:5:6::8 is invalid fails the "rule of least 
astonishment" test.

$ ping6 1:2:3:4:5:6::8
PING 1:2:3:4:5:6::8(1:2:3:4:5:6:0:8) 56 data bytes

Agreed that this just works, and I don't understand why we would have text 
that says it's not allowed?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Mon, 3 Apr 2017 08:36:36 +0200

On 03/04/2017 08:00, Mikael Abrahamsson wrote:
> Agreed that this just works, and I don't understand why we would have
> text that says it's not allowed?

In theory, there is no difference between theory and practice. But, in 
practice, there is.

;)

Cheers, Jan

---

From: Tim Chown <[email-masked]>
Date: Mon, 3 Apr 2017 11:27:37 +0000

On 3 Apr 2017, at 00:03, Jan Zorz - Go6 <[email-masked]<mailto:[email-masked]>> wrote:

In real world - compression and decompression of just 16 bits between the :: simply works.

Indeed.

I searched - it seems there’s already an erratum filed against section 4.2.2 to remove the MUST NOT on using :: for just one set of zeros.

https://www.rfc-editor.org/errata_search.php?eid=4900

Which I agree with, as 5952 is then compliant again with RFC4291, with “:: can replace one or more sets of zeros”.

Tim

Cheers, Jan

Doug

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 4 Apr 2017 00:47:00 +1200

> that says it's not allowed?

Sigh. RFC4291 defines the valid representations. RFC5952 defines the
canonical representation.

1:2:3:4:5:6::8 is valid
1:2:3:4:5:6:0:8 is valid and canonical.

This is not a problem.

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Tue, 4 Apr 2017 01:05:55 +0200

> So this might be the point the filer of the erratum is making, when referring to the recommendation of section 4 as a whole?

I'd assume so.

FWIW, while (recently) reading RFC5952, the section you referred to
somehow came as a "surprise" to me.

I guess that if rfc4291bis is still pursued, this should be incorporated
into it such the the bis RFC does not contradict with RFC5952?

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Fernando Gont <[email-masked]>
Date: Tue, 4 Apr 2017 01:12:04 +0200

On 04/03/2017 12:09 AM, Doug Barton wrote:
[....]
> being replaced by all-zeros. (Is 1:2:3:4:5:6::8 really ambiguous?

I agree with you on this one. That said, RFC5952 did update RFC4291.

> So if updating 4.2.2 of 5952 will make things more clear for people, it

RFC5952 updated RFC4291 in this respect. Having another document update
RFC5952 on this respect would be a kind of spaghetti kind of hard to parse.

At this point, and given the recent discussion regarding rfc4291bis, I'm
wondering if it might make sense to publish rfc4291bis such that lots of
things get cleared up, and move/postpone the "rfc4291bis to IS" to a
later stage? (me thinking out loud)

Thanks!

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 4 Apr 2017 01:13:12 +0200

+1

As noted, this was a surprise for me as well, when recently reading RFC5952.

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 5 Apr 2017 01:58:35 +1200

On 04/04/2017 11:05, Fernando Gont wrote:
...
> into it such the the bis RFC does not contradict with RFC5952?

No, I don't think so. 4291(bis) defines what is valid. 5952 defines
the canonical representation. Different animals.

1:2:3:4:5:6::B8 is valid.
1:2:3:4:5:6::b8 is valid.
1:2:3:4:5:6:0:B8 is valid
1:2:3:4:5:0006:0:B8 is valid
1:2:3:4:5:6:0:b8 is valid and canonical.

   Brian