Subject: [v6ops] Errata 2735 for RFC4291

From: Richard Hartmann <[email-masked]>
Date: Fri, 25 Feb 2011 16:07:06 +0100

Hi all,

I submitted an errata [1] for RFC 4291 and as far as I understand it,
an announcement of this should be sent to the relevant WG so people
are aware of this and can comment.

This hasn't happened yet and I suspect this might be because the WG
that released RFC 4291, ipv6, is a concluded WG.

Having had to decide between 6man and v6ops, I decided to go with
v6ops and hope it was the right choice.

So, long story short: I submitted an errata, I don't want it to lie
around without peer review and thus decided to poke this list.

As usual, thanks for all input and be it merely "don't bother this
list with this",
Richard

PS: I know that "2001:DB8:93::12:0:0:417A       an incorrect unicast
address" is not the correct wording. I am still trying to find out how
to change my errata

[1] http://www.rfc-editor.org/errata_search.php?rfc=4291&eid=2735

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 25 Feb 2011 09:35:36 -0600

Existing parsing code generally has allowed :: to mean one or more
groups of 16-bits. Think of this as :[0]: - it saves one character. And,
for that reason it should be valid for both input and output.

Thus, I don't support this Errata (whatever that might mean).

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Richard Hartmann
Sent: Friday, February 25, 2011 10:07 AM
To: IPv6 Operations
Subject: [v6ops] Errata 2735 for RFC4291

Hi all,

[1] http://www.rfc-editor.org/errata_search.php?rfc=4291&eid=2735
_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Russell Heilling <[email-masked]>
Date: Fri, 25 Feb 2011 15:45:08 +0000

> that released RFC 4291, ipv6, is a concluded WG.

I am not sure that any action is required on this errata.   RFC5952,
which is a standards track RFC and listed as updating RFC4291,
specifically addresses the usage of '::' for zero compression.

I also feel that the alignment of the 16-bit fields is clear from the
context in 2.2.1, and does not need to be made explicit in this way.

-- 
Russell Heilling                        http://perlmonkey.blogspot.com
"The amazing ability of the bee to adapt herself often helps the
 beekeeper to overcome the results of his ignorance." - Brother Adam

---

From: Richard Hartmann <[email-masked]>
Date: Fri, 25 Feb 2011 16:47:52 +0100

> for that reason it should be valid for both input and output.

I think you are misreading my errata.

The current RFCs allow me to compress

  2001:DB8:9300:0:12:0:0:417A

to

  2001:DB8:93::12:0:0:417A

which, uncompresses to

  2001:DB8:0093:0:12:0:0:417A

While I doubt any implementation allows this, it's still an error in
the RFCs. If any implementation followed the letter of the RFCs in
this matter, it could lead to rather grave consequences.

Richard

---

From: Richard Hartmann <[email-masked]>
Date: Fri, 25 Feb 2011 16:50:30 +0100

On Fri, Feb 25, 2011 at 16:45, Russell Heilling <[email-masked]> wrote:

> I am not sure that any action is required on this errata.

Me neither. But from how I understand the process, the appropriate WGs
need to be informed of errata, it hadn't happened and thus I did it
myself.

> RFC5952,

So you're saying I should have filed the errata against RFC 5952?

> context in 2.2.1, and does not need to be made explicit in this way.

While I am not that familiar with the RFC process, I doubt implicit
definitions are a good way to write them.

Richard

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 25 Feb 2011 09:56:05 -0600

But you changed:

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

To:

	The use of "::" indicates two or more groups of 16 bits of zeros.

I certainly missed that other part but I never thought that was unclear.

- Bernie

-----Original Message-----
From: Richard Hartmann [mailto:[email-masked]] 
Sent: Friday, February 25, 2011 10:48 AM
To: Bernie Volz (volz)
Cc: IPv6 Operations
Subject: Re: [v6ops] Errata 2735 for RFC4291

to

  2001:DB8:93::12:0:0:417A

which, uncompresses to

Richard

---

From: Richard Hartmann <[email-masked]>
Date: Fri, 25 Feb 2011 17:33:00 +0100

On Fri, Feb 25, 2011 at 16:56, Bernie Volz (volz) <[email-masked]> wrote:

> But you changed: [...]

Correct. As noted in the notes, errata 2466 changed this and I didn't
want to have our erratas overlapping.

Richard

---

From: Russell Heilling <[email-masked]>
Date: Fri, 25 Feb 2011 17:22:11 +0000

> I certainly missed that other part but I never thought that was unclear.

This part is also in RFC5952:

    The symbol "::" MUST NOT be used to shorten just one 16-bit 0 field

>  2001:DB8:9300:0:12:0:0:417A

That would actually be compressing 24-bits, which is not allowed by
the RFC, which refers to "one or more 16-bit fields"

I guess in theory the current wording would allow

2001:db8:9300:0093:12:0:0:417a to be compressed as
2001:db8:93::93:12:0:0:417a, which is obviously incorrect.

As you point out, I think the problem is with the implicit definition
of a 16-bit field in 2.2.1

i.e. change:

      The preferred form is x:x:x:x:x:x:x:x, where the 'x's are one to
      four hexadecimal digits of the eight 16-bit pieces of the address.

to

      The preferred form is x:x:x:x:x:x:x:x, where the 'x's are one to
      four hexadecimal digits of the eight 16-bit pieces of the address,
      subsequently referred to as "fields"

As you also pointed out, the work on
draft-denog-v6ops-addresspartnaming is currently leaning towards
"hextet" here instead of "field", but field is what is used currently
in both 4291 and 5952.

---

From: Richard Hartmann <[email-masked]>
Date: Fri, 25 Feb 2011 20:31:50 +0100

> the RFC, which refers to "one or more 16-bit fields"

No, as this are 32 bit:

  2001:0DB8:9300:0000:0012:0000:0000:417A
              ^^ ^^^^ ^^

I chose an example as broken as this on purpose. But apparently I
didn't do a very good job in writing the errata, nor in the notes that
accompany it.

If anyone has any alternate suggestions...?

>      subsequently referred to as "fields"

In that case, everything else would need to be changed to refer to
field as well. This works from the logical POV, but it's probably
easier for humans to have the rule stated explicitly rather than
changing from a weak to a binding implication.

Thanks for your feedback,
Richard

---

From: Fred Baker <[email-masked]>
Date: Fri, 25 Feb 2011 11:46:14 -0800

Speaking for myself, I actually don't see a problem with :: representing one :0000: block. Where there is a problem is when there are two :: strings in an address; it is in that event ambiguous.

in other words, if you want to represent 2001:db8:3:4:5:0:7:8 as 2001:db8:3:4:5::7:8, the intended interpretation is unambiguous. If you want to represent 2001:db8:0:0:5:0:0:8 as 2001:db8::5::8, we need to talk. So for my money, saying that :: represents "one or more" blocks is fine; the important thing is to have only one such in the string.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 26 Feb 2011 08:56:18 +1300

>   2001:0DB8:9300:0000:0012:0000:0000:417A

I don't believe there is an error in the RFC that is worth correcting.
It is completely clear what it means by a 16 bit field.

    Brian

---

From: Doug Barton <[email-masked]>
Date: Fri, 25 Feb 2011 12:05:46 -0800

On 02/25/2011 11:56, Brian E Carpenter wrote:
>> On Fri, Feb 25, 2011 at 18:22, Russell Heilling<[email-masked]>  wrote:
>>

Isn't 5952 clear enough on this issue?

Doug

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

---

From: Richard Hartmann <[email-masked]>
Date: Fri, 25 Feb 2011 23:06:36 +0100

> Speaking for myself, I actually don't see a problem with :: representing one :0000: block. Where there is a problem is when there are two :: strings in an address; it is in that event ambiguous.

I would tend to agree, but RFC 5952 does it differently.

> in other words, if you want to represent 2001:db8:3:4:5:0:7:8 as 2001:db8:3:4:5::7:8, the intended interpretation is unambiguous. If you want to represent 2001:db8:0:0:5:0:0:8 as 2001:db8::5::8, we…

True, but this is not what my errata is about.

Richard

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Fri, 25 Feb 2011 16:27:01 -0800

At Sat, 26 Feb 2011 08:56:18 +1300,

> It is completely clear what it means by a 16 bit field.

I agree.

I wonder what was the background motivation of the errata.  Was there
a bug report of an implementation that misunderstood :: due to the
"ambiguity", or is this just an attempt of a protocol spec lawyer
whose job is to find and remove all possible ambiguities from the
protocol description, including those that have never caused and will
be very unlikely to cause a trouble in practice?

If it's the former, I don't necessarily object to the clarification;
if it's the latter, I'd rather keep the description concise (by not
mentioning the obvious).

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.

---

From: Nathan Ward <[email-masked]>
Date: Sat, 26 Feb 2011 14:25:34 +1300

What ever happened to that draft attempting to name the 16 bit field from late last year? Perhaps instead of 16 bit field we could refer to whatever that doc recommends?

Apologies if this message is brief, it is sent from my cellphone.

On 26/02/2011, at 13:27, JINMEI Tatuya / 神明達哉 <[email-masked]> wrote:

> !DSPAM:22,4d684f48145875308115884!
> 
>

---

From: Bob Hinden <[email-masked]>
Date: Mon, 28 Feb 2011 00:10:54 -0800

Richard,

> are aware of this and can comment.

The relevant w.g. would be 6man (not v6ops).  RFC4291 was developed in IPv6 w.g., and 6man is the continuation of that.

>  2001:DB8:0093:0:12:0:0:417A

That is not correct.  RFC4291 is clear about compressing 16-bit groups of zeros, not arbitrary number of continuous zero bits.  

In your Errata you change the text from:

to:

  The use of "::" indicates two or more groups of 16 bits of zeros

Since there compressing a single group of 16 bits of zeros is not an error, this is not an errata.  You are proposing a change and IMHO that is not appropriate for an errata.

So to quote Brian Carpenter:

  "I don't believe there is an error in the RFC that is worth correcting.  It is completely
   clear what it means by a 16 bit field."

Bob

p.s. Looking at the filed errata for this RFC, I note that Michael Rushton first filed an errata on the two or more field change on 2010-08-16, and that Bassam Al-Khaffaf on 2011-02-01 filed another errata based on yours to the prefix text.  I believe all of these errata should be rejected.

---

From: Richard Hartmann <[email-masked]>
Date: Mon, 28 Feb 2011 11:49:15 +0100

(Seems I sent this email to Brian directly and not to the list.
Re-sending as is)

> It is completely clear what it means by a 16 bit field.

Is it clear because it's obvious to you or is it clear because it's
defined explicitly? Should RFCs depend on "well, I am pretty sure
that's what they meant" or "I know what they meant"?

And to reduce email load in this thread, but break thread view:

> Isn't 5952 clear enough on this issue?

Unfortunately not. You are free to start and end the sequence of zeros
wherever you please.

Again, most people would probably not do this and for obvious reasons,
but the RFC is not explicit in this regard and that's A Bad Thing,
imo.

Richard

PS: Does this list prefer one reply per thread leaf I am replying to
or does it prefer condensed emails at the cost of breaking thread
view?

---

From: Richard Hartmann <[email-masked]>
Date: Mon, 28 Feb 2011 11:54:55 +0100

> What ever happened to that draft attempting to name the 16 bit field from late last year? Perhaps instead of 16 bit field we could refer to whatever that doc recommends?

It does not recommend anything yet, but the next version will suggest
hextet as that is what came out far ahead.

Richard

---

From: Richard Hartmann <[email-masked]>
Date: Mon, 28 Feb 2011 12:03:30 +0100

> The relevant w.g. would be 6man (not v6ops).  RFC4291 was developed in IPv6 w.g., and 6man is the continuation of that.

Noted, thanks a lot.

> That is not correct.  RFC4291 is clear about compressing 16-bit groups of zeros, not arbitrary number of continuous zero bits.

It does not define groups. In my example, I compressed a 32-bit group of zeros.

> Since there compressing a single group of 16 bits of zeros is not an error, this is not an errata.  You are proposing a change and IMHO that is not appropriate for an errata.

I don't agree with this change either, but please see RFC 5952,
Section 4.2.2 [1]:

   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.

Richard

[1] http://tools.ietf.org/html/rfc5952#section-4.2.2

---

From: Seiichi Kawamura <[email-masked]>
Date: Mon, 28 Feb 2011 20:40:37 +0900

I don't think this is any 'technical' problem with the current
RFC regarding this issue. 2.2.1 and 2.2.2 states the intention
and the specs clear enough.

I've operated IPv6 networks and
services for 7 years now and I've never
seen this mistake being made anyways.

Why don't you just include the clarification in the address part naming
draft if you are so unhappy about this?

Seiichi

---

From: Bob Hinden <[email-masked]>
Date: Mon, 28 Feb 2011 13:41:53 +0200

Richard,

>   2001:db8::1:1:1:1:1 is not correct.

RFC5952 says:

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

RFC4291 is still correct.  If RFC5952 did change RFC4291, which it does not, this is the correct way to change something in an RFC.    It is incorrect to use the errata process to do this.

Bob

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 01 Mar 2011 09:43:34 +1300

(Although the topic belongs to 6man I am replying
here one last time for consistency.)

> that's what they meant" or "I know what they meant"?

"   1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are one to
      four hexadecimal digits of the eight 16-bit pieces of the address. "

That is very clear to me about what it means by a 16-bit piece: there
are 8 of them.

>> Isn't 5952 clear enough on this issue?

(Not me in fact, but never mind...)
> Unfortunately not. You are free to start and end the sequence of zeros

The above sentence in 4291 makes it clear that the edge is a 16-bit
boundary in each case.

BTW, the ABNF discussed in RFC 5954 may interest you.

However, you're correct: 5952 and 5954 are only about syntax. It is
only 4291 that makes it clear that the : is always on a 16-bit
boundary.

   Brian