Subject: Re: Fix IPV6 literal notation?

From: Brian E Carpenter <[email-masked]>
Date: Sun, 27 Dec 2020 12:25:33 +1300

Tim,

On 27-Dec-20 11:16, Tim Bray wrote:
> See https://twitter.com/dave_universetf/status/1342685822286360576 to which I heartily concur. IPV6 addresses are neither easy for humans to read, nor easy for software to parse.
> 
> *If* someone has a better idea, there’s no good reason not to standardize it, the old approach would still work.   Does anyone have a better idea?

I have no idea if there's a proposal in that sequence of Twitter messages, but if there is, it should be written up as an I-D aimed at the 6man WG and discussed there. (Hence I have changed the IETF list to a Bcc: and added the 6man list in Cc:.)

I can say that this much is wrong:

> Oh, and the leading zero debate also infects IPv6, to some extent! The specs tried to specify the textual representation of IPv6, but it failed to be complete. So it's unclear if 000001::00001.00002.00003.00004 is a valid IPv6 address

It's quite clear that it is invalid. RFC4291 section 2.2 says:

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

As for writing a parser, I'd expect the starting point to be the ABNF in RFC3986 (where the limitation to 4 hex digits is also clear).

Regards
   Brian Carpenter

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 26 Dec 2020 19:42:28 -0500

I agree just on difficult to read and hard to parse.

For operators NOC and support the biggest complaint has been trying to
decipher the prefix,  subnet and host portion.  Over the last 20+ years I
have provided NOC and support training on IPv6 addressing and subnetting
basics.  Definitely a learning curve for any network support organization.

Main complaints from network engineers and grasping of basic concepts:

Understanding the hex format as it’s completely different from IPv4 decimal.

Understanding the bit pattern as it repeats in subnetting.

Understanding that Hex goes A-F in each 4 hex character field within each
16 bit field and that provides the combinations of addresses per bit
boundary.

The  :: Os compression helps, however does add confusion and needs
explanation and I usually tell folks to write out all the 0s then convert
to compressed format to help understanding of the compressed format.

Understanding that when an IPv6 prefix is written that the leading higher
order hex 0s are the not displayed within the hex field which leads to
confusion.

Happy Holidays!!

Gyan

On Sat, Dec 26, 2020 at 6:25 PM Brian E Carpenter <
[email-masked]> wrote:

> > See https://twitter.com/dave_universetf/status/1342685822286360576 to
> which I heartily concur. IPV6 addresses are neither easy for humans to
> read, nor easy for software to parse.
> >
> > *If* someone has a better idea, there’s no good reason not to
> standardize it, the old approach would still work.   Does anyone have a
> better idea?
>
> I have no idea if there's a proposal in that sequence of Twitter messages,
> but if there is, it should be written up as an I-D aimed at the 6man WG and
> discussed there. (Hence I have changed the IETF list to a Bcc: and added
> the 6man list in Cc:.)
>
> > Oh, and the leading zero debate also infects IPv6, to some extent! The
> specs tried to specify the textual representation of IPv6, but it failed to
> be complete. So it's unclear if 000001::00001.00002.00003.00004 is a valid
> IPv6 address
>
> As for writing a parser, I'd expect the starting point to be the ABNF in
> RFC3986 (where the limitation to 4 hex digits is also clear).
>
> Regards
>    Brian Carpenter
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: Karl Auer <[email-masked]>
Date: Sun, 27 Dec 2020 13:28:04 +1100

> I agree just on difficult to read and hard to parse.

Anything new is hard to start with and becomes easy with practice.

For a way to make it even easier, see RFC1924 (
ftp://ftp.rfc-editor.org/in-notes/rfc1924.txt)

> The  :: Os compression helps, however does add confusion

I generally make the same recommendations as RFC5952.

The other thing people get hung up on is that the term "leading zeroes"
does not mean ALL the zeroes. In most classes there is at least one
person who tries to turn ":3000:" into ":3:" (and in one memorable case
":3001:" into ":31:").

> Understanding that when an IPv6 prefix is written that the leading
> higher order hex 0s are the not displayed within the hex field which
> leads to confusion.

Can we blame IPv4 octal representation? There are no higher-order
zeroes shown in IPv4 octets either, and nobody gets confused.

A lot of people treat IP addresses as symbols without understanding
their underlying meaning. Making the link between the written addresses
and the underlying bits helps a lot.

128 bits are just plain harder to get your head around than 32. IPv6
addresses are not easily parsed by the unaided human; they are too big
to be encompassed at a glance, regardless of the notation.

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer ([email-masked])
http://www.biplane.com.au/kauer

GPG fingerprint: 2561 E9EC D868 E73C 8AF1 49CF EE50 4B1D CCA1 5170
Old fingerprint: 8D08 9CAA 649A AFEF E862 062A 2E97 42D4 A2A0 616D

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 27 Dec 2020 13:57:07 -0500

Agreed on all comments.  As you stated anything difficult or not as
pleasing visually gets easier over time and with practice.  When you look
at an IPv6 address you hex and 48 bit ugly mac or maybe even Token Ring RIF
field for source routing packets.

I think the most difficult is the visualization and being used to decimal
and now looking at Hex is a huge change for operations to get their arms
around.

Practice makes Perfect!!

Cheers

Gyan

-- 

*Gyan Mishra*

---

From: Ofer Inbar <[email-masked]>
Date: Mon, 28 Dec 2020 13:57:54 -0500

On Sun, Dec 27, 2020 at 12:25:33PM +1300,
Brian E Carpenter <[email-masked]> wrote:
> > *If* someone has a better idea, there???s no good reason not to standardize it, the old approach would still work.   Does anyone have a better idea?
> 

It's clearly not a proposal for changing anything, because the
majority of the weirdness that thread describes is address forms that
are no longer actively in use, but still appear in various places -
old threads, documents, databases, config files, archives, etc.  Any
change made to specifications now will only affect what forms people
produce addresses in in the future, so it would have no effect on
this.  IPv6 address formats are reasonably specified for the present
and future, and changing specs won't affect artifacts of the past.

>       four hexadecimal digits of the eight 16-bit pieces of the address."

That's not clear at all, since it doesn't address validity, only what
is "preferred".  So if there is one thing in that thread that might
call for a change, it's to clarify that IPv6 addresses are expected
not to pad with leading zeros beyond 4 hex characters, and that it is
invalid to write them with more digits.

I'd support that change, unless someone can show it's already very
clearly spelled out somewhere.
  -- Cos

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 29 Dec 2020 09:44:44 +1300

On 29-Dec-20 07:57, Ofer Inbar wrote:
> is "preferred". 

RFC4291 doesn't use RFC2119 language, but to me that sentence is a clear
specification. 02001:0:0:0:0:0:0:1 doesn't conform.

I also cited the ABNF, which is prescriptive for address literals in URIs,
but we all know that it applies generally.

> So if there is one thing in that thread that might

I think that's really not needed. As a matter of curiosity, I think
the IPv4 format is pretty much undocumented. A few minutes of research
found this:

   One commonly used notation for internet host addresses divides the
   32-bit address into four 8-bit fields and specifies the value of each
   field as a decimal number with the fields separated by periods.  This
   is called the "dotted decimal" notation.  For example, the internet
   address of ISIF in dotted decimal is 010.002.000.052, or 10.2.0.52.

which first appeared in RFC820 (January 1983) and last appeared in
RFC990 (November 1986). Note that leading zeroes are allowed and do not
signal octal. 

    Brian

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 28 Dec 2020 22:05:26 +0000

> RFC990 (November 1986). Note that leading zeroes are allowed and do not

it's not unprecedented that programs emit or expect leading zeros when 
dealing with dotted decimal ipv4 notation. You tend to get this quite a 
bit with embedded ip stacks, e.g. rom monitors, bootloaders, PXE 
front-ends, etc.

Obviously this conflicts with the behaviour that you'll see in 
bsd-derived parsers, so in general it's a bad idea to use leading zeros. 
  The same thing applies to using dotted hex, mixing octal/decimal/hex 
format, and partial/complete non-dotted format. Sometimes addresses 
written in these formats will do what you intend, but depending on 
consistent interpretation would be brave, to say the least.

Nick

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 29 Dec 2020 12:27:11 +0100

Le 27/12/2020 à 00:25, Brian E Carpenter a écrit :
>> See https://twitter.com/dave_universetf/status/1342685822286360576 
>> to which I heartily concur. IPV6 addresses are neither easy for 
>> humans to read, nor easy for software to parse.
>> 
>> standardize it, the old approach would still work.   Does anyone 
>> have a better idea?
> 
> I have no idea if there's a proposal in that sequence of Twitter 
> messages, but if there is, it should be written up as an I-D aimed
> at the 6man WG and discussed there. (Hence I have changed the IETF
> list to a Bcc: and added the 6man list in Cc:.)
> 
>> Oh, and the leading zero debate also infects IPv6, to some extent! 
>> The specs tried to specify the textual representation of IPv6, but 
>> it failed to be complete. So it's unclear if 
>> 000001::00001.00002.00003.00004 is a valid IPv6 address
> 

But there is also that notation in a certain RFC which says that
1::1.1.1.1 is a valid notation too.

So combining the two might indeed lead to 1::01.1.1.1 being a
potentially valid notation as well.

> As for writing a parser, I'd expect the starting point to be the
> ABNF in RFC3986 (where the limitation to 4 hex digits is also
> clear).

One might wonder why ABNF (A Backus Naur Form) and not other notations
for grammar descriptions, such as ASN.1 (Abstract Syntax Notation number 1)?

But the idea of a reference parser would be great.  One might start with
the parsers that are open source in BSD and in linux.

A reference parser implementation might help avoid incompatible IP
literal address notations.

Alex

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 29 Dec 2020 12:35:59 +0100

Le 27/12/2020 à 03:28, Karl Auer a écrit :
> The other thing people get hung up on is that the term "leading
> zeroes" does not mean ALL the zeroes. In most classes there is at
> least one person who tries to turn ":3000:" into ":3:" (and in one
> memorable case ":3001:" into ":31:").

YEs, that led to some confusion here too.

Another thing that leads to confusion is this fc00- and fd00- both being
a prefix for ULAs, being distinguished by just a prefix length.  One
cant say that all ULAs are fc00- prefixed addresses (like one says that
all LLs are fe80- prefixed addresses), because there are also the fd00-
prefixed addresses that are also ULAs.

Another problem with the IPv6 notation is the difficulty in memorizing
long strings such as 2001:2425:bcd:23:2DF:1DF:... When building an
addressing architecture one would rather choose hextets that are easy to
memorize.

It is true that there is a tendency to make work with addresses
dynamically changing all the time, but I have not yet seen an addressing
architecture plan that does not follow a certain logic understood by the
designer and that is not designed by hand.  I think it is rather
impossible to design an addressing architecture using random number
generators.  This is an additional reason why notation is useful.

Alex

>> higher order hex 0s are the not displayed within the hex field
>> which leads to confusion.
> 
> their underlying meaning. Making the link between the written
> addresses and the underlying bits helps a lot.
> 
> addresses are not easily parsed by the unaided human; they are too
> big to be encompassed at a glance, regardless of the notation.
> 
> Regards, K.
> 
>

---

From: tom petch <[email-masked]>
Date: Tue, 29 Dec 2020 11:36:45 +0000

From: ipv6 <[email-masked]> on behalf of Alexandre Petrescu <[email-masked]>
Sent: 29 December 2020 11:27

<tp>
Augmented Backus Naur 
RFC5234 (which seems like a good enough reason to me)
Tom Petch

Alex

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 31 Dec 2020 16:47:32 +1300

> potentially valid notation as well.

The parsers that I have convenient access to all treat that leading 0
as invalid, which is no surprise if you study the URI ABNF.

   Brian