Subject: What the f? (RFC5952 and RFCs)

From: Brian E Carpenter <[email-masked]>
Date: Thu, 10 Sep 2015 08:43:47 +1200

Hi,

With my Gen-ART reviewer's hat on, I recently reviewed a draft containing an IPv6
address (specifically FF02::FD, as it happens).

According to RFC5952, that should be ff02::fd.

Should we be insisting that all RFCs use the recommended format (lower case)?

If so, we need to get the IESG to change the relevant guidelines and request
an update to the ID-nits tool.

Any opinions?

    Brian

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 9 Sep 2015 20:56:37 +0000

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Brian E Carpenter

> an update to the ID-nits tool.

The letter of the law is clear NOW, although for a long time, 1 1/2 years it seems, there was an errata attached to RFC 5952 which stated the opposite. I was confused too, for a time. Finally, that errata was rejected, in 2012.

I can't feel too religious about this. What seems to be happening now is that other hex representations, e.g. MAC addresses, are almost always shown in upper case, and it's only the IPv6 addresses that show up in lower case. That too seems kind of odd. The use of lower case has always been a sort of an acceptable shorthand for operator input purposes, but the more formal depiction of hex is uppercase.

But yes, RFC 5952 with rejected errata does say MUST.

Bert

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 09 Sep 2015 22:57:10 +0200

Ouch.

Yes, we made RFC 5952 standards track, so we should be using their
canonical form.  Let's see...  (I have deleted the U+FF02 (FULLWIDTH
QUOTATION MARK) :-)

rfc6059.txt:715:   RS_Target_Address=FF02::2;
rfc6142.txt:573:                    link-local         -- FF02::204;
rfc6217.txt:263:   FF02:0:0:0:0:0:0:1 MUST be used, defined in RFC 4291 [8].
rfc6762.txt:312:   equivalent FF02::FB).  The design rationale for using
a fixed
rfc6762.txt:387:      or the mDNS IPv6 multicast address FF02::FB.
Since names under
rfc6762.txt:402:      be sent to the mDNS IPv6 link-local multicast
address FF02::FB or
rfc6762.txt:429:   [FF02::FB]:5353).  Typically, the timeout would also
be shortened to
rfc6762.txt:588:   equivalent FF02::FB).
rfc6762.txt:827:   multicast address 224.0.0.251 or its IPv6 equivalent
FF02::FB, except
rfc6762.txt:2119:   address (including the 224.0.0.251 and FF02::FB
link-local multicast
rfc6762.txt:2141:        FF02::FB are necessarily deemed to have
originated on the local
rfc6762.txt:2222:   is FF02::FB.  These are multicast addresses;
therefore, they identify
rfc6762.txt:2250:   the 224.0.0.251:5353 and [FF02::FB]:5353 multicast
groups, by virtue
rfc6762.txt:2960:   described in this document [MC6].  Only address
FF02::FB (link-local
rfc6788.txt:796:      FF02:0:0:0:0:0:0:10  All-BBF-Access-Nodes  [RFC6788]

(Yes, it ends with RFC 6788.)

vs.

rfc5963.txt:298:   the link-local all-nodes multicast address (ff02::1)
and/or
rfc5963.txt:299:   solicited-node multicast addresses
(ff02:0:0:0:0:1:ff00:0000 to ff02:
rfc5963.txt:304:   group address: ff02::2 (MLD) or ff02::16 (MLDv2).
Depending on the
rfc5963.txt:332:   to the link-local IPv6 'ALL-PIM-ROUTERS' multicast
group ff02::d in
rfc6037.txt:803:   IPv4 or ff02::d for IPv6) in the context of that VRF,
but when in
rfc6037.txt:982:      addressed to ALL-PIM-ROUTERS (ff02::d).
rfc6126.txt:2155:   IANA has registered the IPv6 multicast group
ff02:0:0:0:0:0:1:6 and
rfc6221.txt:359:      (ff02::1:2);
rfc6282.txt:527:         11:  8 bits.  The address takes the form
ff02::00XX.
rfc6282.txt:705:   supports compression of the Solicited-Node Multicast
Address (ff02::
rfc6282.txt:749:     Figure 9: DAM = 11. 8-bit Compressed Multicast
Address (ff02::GG)
rfc6516.txt:217:   PIM-ROUTERS, the IPv6 form of the address (ff02::d)
is used.  These
rfc6550.txt:1651:   new address with a value of ff02::1a.
rfc6550.txt:7710:   called all-RPL-nodes, with a value of ff02::1a.
rfc6636.txt:580:   address (ff02::1) is used as the IP destination
address of an IGMP/
rfc6788.txt:587:   All-BBF-Access-Nodes multicast address (ff02::10).
The link-layer
rfc6887.txt:3659:   announcements are sent to 224.0.0.1:5350 and/or
[ff02::1]:5350, as
rfc6887.txt:3679:   multicast address [ff02::1]:5350 (ff02::1 is for all
nodes on the
rfc6887.txt:3711:   [ff02::1]:5350.  A PCP client device that sends PCP
requests using
rfc7046.txt:2036:     m.join(URI("ham:ip:[ff02:0:0:0:0:0:0:3]:6000"));
rfc7252.txt:6119:   Client  ff02::1  A  B  C
rfc7390.txt:329:   ff02::fd and the site-local scoped address ff05::fd.
 IPv6 addresses
rfc7552.txt:460:      ff02:0:0:0:0:0:0:2   = Link-local scope
rfc7552.txt:468:   ff02:0:0:0:0:0:0:2) as the destination multicast IP
address in IPv6

Consistency is the hobgoblin of the little mind :-)

Grüße, Carsten

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

---

From: Mark Smith <[email-masked]>
Date: Thu, 10 Sep 2015 07:19:53 +1000

> Should we be insisting that all RFCs use the recommended format (lower
case)?

I think so. RFC5952 updates IPv6 Address Arch. RFC4291 and is standards
track, which I think makes it canonical, despite how optional its title
makes it seem.

Updating RFC5952 with a more prescriptive title would be good.

---

From: Bob Hinden <[email-masked]>
Date: Wed, 9 Sep 2015 20:53:30 -0700

Brian,

> On Sep 9, 2015, at 1:43 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> Hi,
> 

Yes, I think what you are suggesting is worthwhile.

Bob

---

From: Sander Steffann <[email-masked]>
Date: Thu, 10 Sep 2015 10:43:15 +0200

Hi,

> Yes, I think what you are suggesting is worthwhile.

+1

Sander

---

From: Ole Troan <[email-masked]>
Date: Thu, 10 Sep 2015 11:05:43 +0200

>> Yes, I think what you are suggesting is worthwhile.

at the same time I think we should remember that the intention of 5952 was to make it simpler and more deterministic for software to parse IPv6 addresses in text, like log files etc.

since no-one has developed the “parse RFC 2 implemented protocol” code yet I don’t think this is something we should spend too much time on.

cheers,
Ole

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 10 Sep 2015 12:14:24 +0200

I agree to use consistently lower case.  Typing lower case is 
intuitively safer to assume be the equivalent of the upper case variant, 
whereas typing upper case may suggest that lower case is a 
non-equivalent - case sensitiveness.

(web and email addresses, are so; SQL queries are an exception)

Alex

---

From: Kerry Lynn <[email-masked]>
Date: Thu, 10 Sep 2015 12:29:56 -0400

On Wed, Sep 9, 2015 at 5:19 PM, Mark Smith <[email-masked]> wrote:

> I generally support following our own conventions, especially as engage the
effort to move the core IPv6 specifications to Internet Standard.  For
example,
RFC 4291 uses upper case throughout.

How pedantic should we be on enforcing this elsewhere?  For example, the
IANA registries (e.g.
http://www.iana.org/assignments/ipv6-multicast-addresses)
seem to use an upper case letter convention

It seems that converting existing specifications and DBs would be less
error-
prone if it were automated.  If this can be done effectively, I'd be in
favor of
idnits throwing a warning but not an error.  I wouldn't want to see xml2rfc
try
to auto-correct.

> Updating RFC5952 with a more prescriptive title would be good.
Since you brought it up, RFC 5952 says "The [ ] style as expressed in
[RFC3986]
SHOULD be employed..." when combining IPv6 addresses with port numbers.
However, it is silent on the topic of ZoneIDs.  If and when we figure out
how to
fix RFC 6874, we should go back and update RFC 5952 to point to it, for
completeness.

Regards, Kerry

---

From: Bob Hinden <[email-masked]>
Date: Thu, 10 Sep 2015 11:19:51 -0700

Kerry,

> On Sep 10, 2015, at 9:29 AM, Kerry Lynn <[email-masked]> wrote:
> 
> On 10 Sep 2015 06:43, "Brian E Carpenter" <[email-masked]> wrote:
> >
> > Hi,
> >
> I think so. RFC5952 updates IPv6 Address Arch. RFC4291 and is standards track, which I think makes it canonical, despite how optional its title makes it seem.
> 
> 
> effort to move the core IPv6 specifications to Internet Standard.  For example,

As part of my work to produce an update of RFC4291 (see draft-hinden-6man-rfc4291bis), I have been thinking about what approach to take on the incorporating the RFC5952 update.  The choices are to change it to strictly follow RFC5952, or since RFC5952 is compliant with RFC4291 just add a pointer to RFC5952 that this is the recommended set of rules to follow when writing and displaying IPv6 address.

I note the abstract of RFC5952:

   As IPv6 deployment increases, there will be a dramatic increase in
   the need to use IPv6 addresses in text.  While the IPv6 address
   architecture in Section 2.2 of RFC 4291 describes a flexible model
   for text representation of an IPv6 address, this flexibility has been
   causing problems for operators, system engineers, and users.  This
   document defines a canonical textual representation format.  It does
   not define a format for internal storage, such as within an
   application or database.  It is expected that the canonical format
   will be followed by humans and systems when representing IPv6
   addresses as text, but all implementations must accept and be able to
   handle any legitimate RFC 4291 format.

An issue with rfc4291bis strictly follow RFC5952 is that would likely cause implementations to break.  If so, not a good idea.

I would appreciate feedback on this.

Thanks,
Bob

> IANA registries (e.g. http://www.iana.org/assignments/ipv6-multicast-addresses)
> It seems that converting existing specifications and DBs would be less error-
> prone if it were automated.  If this can be done effectively, I'd be in favor of
> idnits throwing a warning but not an error.  I wouldn't want to see xml2rfc try
> to auto-correct.
> Since you brought it up, RFC 5952 says "The [ ] style as expressed in [RFC3986]
> However, it is silent on the topic of ZoneIDs.  If and when we figure out how to

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Sep 2015 08:47:25 +1200

> since no-one has developed the “parse RFC 2 implemented protocol” code yet I don’t think this is something we should spend too much time on.

I agree with that. It can be done with a light touch (a note in http://www.ietf.org/id-info/checklist.html and a warning in
ID-nits).

    Brian

---

From: Richard Hartmann <[email-masked]>
Date: Thu, 10 Sep 2015 23:02:37 +0200

It's worth being consistent; +1.

Richard

Sent by mobile; excuse my brevity.

---

From: Mark Smith <[email-masked]>
Date: Fri, 11 Sep 2015 08:48:03 +1000

On 11 Sep 2015 04:19, "Bob Hinden" <[email-masked]> wrote:

<snip>

> It is expected that the canonical format
> An issue with rfc4291bis strictly follow RFC5952 is that would likely
cause implementations to break.  If so, not a good idea.
> I would appreciate feedback on this.

rfc4291bis is a piece of text, so it seems to me that generally, addresses
within it should be following RFC5952, and RFC5952 should also be described
as the canonical format. I think the former formats in RFC4291 could be
both  described and described as deprecated but still supported for
backwards compatibility reasons.

Regards,
Mark.

---

From: David Farmer <[email-masked]>
Date: Thu, 10 Sep 2015 18:53:25 -0500

> Should we be insisting that all RFCs use the recommended format (lower case)?

Yes, probably.

> an update to the ID-nits tool.

Yes, I think a nit warning would be appropriate.

> Any opinions?

For the specific address in question the author may have been led astray 
by the IANA IPv6 Multicast Address Space Registry, it doesn't seem to 
follow RFC5952.

http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml

So, if you were to just cut-n-past out of it, as I probably would have, 
you will have an issue.  Therefore, IANA should be asked to change that 
registry to use RFC5952 format.

Other registries use uppercase for Hex digits, but they are not IPv6 
addresses, they are other parameters so, RFC5952 doesn't necessarily 
apply.

The one exception might be the Internet Protocol Version 6 (IPv6) 
Anycast Addresses registry;

http://www.iana.org/assignments/ipv6-anycast-addresses/ipv6-anycast-addresses.xhtml

Since they are address components maybe it should follow RFC5952 as well.

Thanks

-- 
================================================
David Farmer               Email: [email-masked]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================

---

From: Bob Hinden <[email-masked]>
Date: Thu, 10 Sep 2015 17:43:25 -0700

Mark,

> On Sep 10, 2015, at 3:48 PM, Mark Smith <[email-masked]> wrote:
> 
> 
> rfc4291bis is a piece of text, so it seems to me that generally, addresses within it should be following RFC5952, and RFC5952 should also be described as the canonical format. I think the former formats in RFC4291 could be both  described and described as deprecated but still supported for backwards compatibility reasons.

Thanks, I think that will work.

Bob

---

From: David Farmer <[email-masked]>
Date: Thu, 10 Sep 2015 19:47:30 -0500

> On Sep 10, 2015, at 11:29, Kerry Lynn <[email-masked]> wrote:
> 

A number of the other IPv6 registries are already in RFC5952 format;

http://www.iana.org/assignments/ipv6-address-space
http://www.iana.org/assignments/ipv6-unicast-address-assignments
http://www.iana.org/assignments/iana-ipv6-special-registry

So, not pedantic at all, we are only asking for consistency.

-- 
===============================================
David Farmer                          Email: [email-masked]
Office of Information Technology
University of Minnesota    
2218 University Ave SE         Phone: +1-612-626-0815
Minneapolis, MN 55414-3029   Cell: +1-612-812-9952
===============================================

---

From: t.petch <[email-masked]>
Date: Fri, 11 Sep 2015 11:24:08 +0100

----- Original Message -----
From: "Alexandru Petrescu" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, September 10, 2015 11:14 AM

<tp>
lower case consistently

easier to type although slightly harder to read on the average pc screen
(but easier to read on motorway road signs)

and upper case used to be the only display/print option even when the
internal format was lower case so upper case has always had that slight
ambiguity

tom petch

Alex

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 14 Sep 2015 11:57:11 +0000

If we want to have products using RFC 5952 to ease operations, then the
bare minimum is to do what we write.

===> +1 of course

-éric

---

From: David Farmer <[email-masked]>
Date: Mon, 14 Sep 2015 20:14:33 -0500

On 9/10/15 19:47 , David Farmer wrote:
>
> On Sep 10, 2015, at 11:29, Kerry Lynn <[email-masked]
> <mailto:[email-masked]>> wrote:
>>

Thinking about this a little more; I'll concede IANA may have bigger 
fish to fry.

So, while I still prefer the idea of updating the format of the IPv6 
addresses in the IPv6 Multicast Registry.  On the other hand, if that 
option is not chosen, as an alternative I'd suggest a note be added 
stating that "the registry predates RFC5952 and for historic reasons 
does not conform to the canonical text representation for IPv6 addresses 
as described in RFC5952," or something to that effect.

Essentially, use of RFC5952 format is a SHOULD, not a MUST, and 
therefore if not followed, an explanation of why and a clear notion of 
the that fact would seem a reasonable alternative in this case.

Thanks.