Subject: Fix IPV6 literal notation?

From: Tim Bray <[email-masked]>
Date: Sat, 26 Dec 2020 14:16:03 -0800

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?

[*shuffles off to try to think of a better idea*]

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 27 Dec 2020 03:55:44 -0500

> easy for software to parse.

The specification in https://tools.ietf.org/html/rfc4291#section-2.2 is
not nearly as diverse as the exotic variations in the tweet barrage.

There are just 3 or 4 valid input forms (depending on whether you count
the compressed and uncomressed variants of case 3 as two separate
forms).

> it, the old approach would still work.   Does anyone have a better idea?

It is far from clear that a change at this point would do more good than
harm.  In practice, the IPv4 forms are only occur as:

    ::1.2.3.4       -- https://tools.ietf.org/html/rfc4291#section-2.5.5.1
    ::ffff:1.2.3.4  -- https://tools.ietf.org/html/rfc4291#section-2.5.5.2

otherwise, one only sees compressed and uncomressed hex forms, with at
most 4 hex digits per group.

So if one were willing to parse just the expected forms, one could parse only:

    - 8 colon-separated groups
    - n1 colon-separated groups + "::" + n2 colon-separated groups,
      n1 >= 0, n2 >= 0, n1 + n2 <= 7
    - "::" + dotted quad IPv4 address
    - "::ffff:" + dotted quad IPv4 address

If you see anything else, someone is straying off the beaten path.  But
parsing a more general 96-bit hex prefix before the final IPv4 dotted
quads is both reasonable and not onerous.  Same parser as the first two
cases above, with 6 groups instead of 8.

-- 
    Viktor.

---

From: "John Levine" <[email-masked]>
Date: 27 Dec 2020 11:33:02 -0500

In article <[email-masked]> you write:
>-=-=-=-=-=-

I don't understand what the point of that tweet stream is. Yes, there
was a lot of funky code in 4BSD thirty-five years ago, including in
the IP address parsers. But so what?  As Victor said, these days every
actual IP address you will encounter is in a handful of familiar forms.

Parsing them is not hard or slow. I wrote a version of grepcidr that
matches all of the modern forms of v4 and v6 addresses with a state
machine that looks at each character once and doesn't back up. It's
plenty fast.

R's,
John

PS: https://www.taugh.com/grepcidr-2/

---

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