Subject: [Emailcore] Ticket #27: Erratum 4315: IPv6 ABNF needs updating to align with RFC 5952 and RFC 3986

From: Alexey Melnikov <[email-masked]>
Date: Mon, 16 Nov 2020 17:41:32 +0000

Dear collegues,

This ticket took me a bit of time to investigate, so it might be a bit 
tricky (not that anything in this WG is easy ;-)). Basically erratum 
4315 requested upgrade to IPv6 address ABNF in the document to match 
[RFC 3986]  (URI spec) and [RFC 5952] (A Recommendation for IPv6 Address 
Text Representation). There was a specific proposal in the erratum, but 
I think John's solution (which is currently in the draft) is better:

IPv6-addr = 6( h16 ":" ) ls32
     / "::" 5( h16 ":" ) ls32
     / [ h16 ] "::" 4( h16 ":" ) ls32
     / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32
     / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
     / [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32
     / [ *4( h16 ":" ) h16 ] "::" ls32
     / [ *5( h16 ":" ) h16 ] "::" h16
     / [ *6( h16 ":" ) h16 ] "::"
         ; This definition is consistent with the one for
         ; URIs [40].

ls32 = ( h16 ":" h16 ) / IPv4address
         ; least-significant 32 bits of address

h16 = 1*4HEXDIG
         ; 16 bits of address represented in hexadecimal

Basically IPv6-addr looks very similar to what is in RFC 3986, so it is 
easy to verify correctness.

However, RFC 3986 doesn't follow advice from RFC 5952, as it predates 
it. Some minor issues I've noticed with the above ABNF:

RFC 5952, 4.1. Handling Leading Zeros in a 16-Bit Field
     Leading zeros MUST be suppressed. For example, 2001:0db8::0001 is
     not acceptable and must be represented as 2001:db8::1. A single 16-
     bit 0000 field MUST be represented as 0.

4.3. Lowercase
     The characters "a", "b", "c", "d", "e", and "f" in an IPv6 address
     MUST be represented in lowercase.

Both of these would probably affect h16, which can be tweaked to make it 
clear that leading "0" are prohibited and only lowercase is to be used. 
(HEXDIG allows uppercase hex at the moment). This made me wonder though: 
are there any backward compatibility issues with changing this (e.g. to 
disallow uppercase hex)? Should we have 2 grammars, "strict" one for 
what should be generated and a more relaxed one for what should be accepted?

Best Regards,

Alexey

---

From: Michael Peddemors <[email-masked]>
Date: Mon, 16 Nov 2020 09:51:21 -0800

> what should be generated and a more relaxed one for what should be 

Not a bad approach, the 2 grammar idea..
Lends itself to a longer term enforcement of all lower case.

-- 
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.

---

From: Steffen Nurpmeso <[email-masked]>
Date: Mon, 16 Nov 2020 19:28:47 +0100

Alexey Melnikov wrote in
 <[email-masked]>:
 |This ticket took me a bit of time to investigate, so it might be a bit 
 |tricky (not that anything in this WG is easy ;-)). Basically erratum 
 |4315 requested upgrade to IPv6 address ABNF in the document to match 
 |[RFC 3986]  (URI spec) and [RFC 5952] (A Recommendation for IPv6 Address 
 |Text Representation). There was a specific proposal in the erratum, but 
 |I think John's solution (which is currently in the draft) is better:
 |
 |IPv6-addr
 ...
 |Basically IPv6-addr looks very similar to what is in RFC 3986, so it is 
 |easy to verify correctness.
 |
 |However, RFC 3986 doesn't follow advice from RFC 5952, as it predates 
 |it. Some minor issues I've noticed with the above ABNF:
 |
 |RFC 5952, 4.1. Handling Leading Zeros in a 16-Bit Field
 |     Leading zeros MUST be suppressed. For example, 2001:0db8::0001 is
 |     not acceptable and must be represented as 2001:db8::1. A single 16-
 |     bit 0000 field MUST be represented as 0.
 |
 |4.3. Lowercase
 |     The characters "a", "b", "c", "d", "e", and "f" in an IPv6 address
 |     MUST be represented in lowercase.
 |
 |Both of these would probably affect h16, which can be tweaked to make it 
 |clear that leading "0" are prohibited and only lowercase is to be used. 
 |(HEXDIG allows uppercase hex at the moment). This made me wonder though: 
 |are there any backward compatibility issues with changing this (e.g. to 
 |disallow uppercase hex)? Should we have 2 grammars, "strict" one for 
 |what should be generated and a more relaxed one for what should be \
 |accepted?

I had written an IP address class which supported IPv4 and IPv6,
as of RFC 1884, which means, for the string representation,
compression was optional and upper- and lowercase were both
possible.  (Personally i liked that, as it is no problem on the
parser nor generator side (despite my code being ugly), and why
artificially encforcing people to do things for no technical
reason is beyond my worldview.)

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

---

From: Ned Freed <[email-masked]>
Date: Mon, 16 Nov 2020 22:51:05 -0800 (PST)

> what should be generated and a more relaxed one for what should be accepted?

Perhaps a better question is wheter or not you even have a way of measuring the
extent to which there are going to be backwards compatibility issues.

Implementations have been written, and to the extent that IPv6 literals are
even used, the supported forwats are what they are. It may well be there are
uses out there that would break. Or not. It's really impossible to tell.

Now, it would be one thing if this was a change to allow for more flexibility
in address formats. I could see a case for that. But it's the exact opposite.

And yes, we have a clever mechanism of imposing syntax restrictions on
addresses. But use of this mechanism is not with it's own costs.

So why make the change? The case for imposing these restriction is made in
section 3 of RFC 5952. I'm not going to bother to reproduce all of it here, but
it basically boils down to listing the advantages of having a canonical form
for IPv6 addresses and how it helps for searching, auditing, and so on.

Now let's please remember that we're talking about IPv6 literals in the context
of email addresses. In regards to caoonical forms in this context, let me
simply say

    [email-masked]
    ned.freed @ mrochek.com
    [email-masked]
    [email-masked]

All of these are legal addresses. Are they equivelant? The first two are,
but implementations are specifically allowed to treat local-parts
as case-senisitive, or not.

How about

    "ned.freed"@mrochek.com
    "ned . freed"@mrochek.com

Please note I haven't even gotten to obsolete forms, or EAI addresses. Or
subaddreses. Or multiple aliases.

When it comes to canonical forms for email addresses, the horse has left the
barn and the barn has been torn down and replaced with a parking lot.

Given this context, it would be a serious understatement To say I see no value
in worrying about canonical forms for IPv6 in domain literals.

tl;dr. The proposed change provides nothing of value and may have some
cost. It should be rejected.

				Ned

---

From: "Alexey Melnikov" <[email-masked]>
Date: Tue, 17 Nov 2020 09:31:02 +0000

On Tue, Nov 17, 2020, at 6:51 AM, Ned Freed wrote:
 [snip]

> cost. It should be rejected.

Ok, fair point. I suggest we keep John's change to match RFC 3986 (URI spec), but don't do anything else to comply with RFC 5952. We can also add some text to the A/S draft saying that IPv6 syntax is not necessarily canonical, so it doesn't follow recommendations from RFC 5952.

---

From: Ned Freed <[email-masked]>
Date: Tue, 17 Nov 2020 05:27:41 -0800 (PST)

> Ok, fair point. I suggest we keep John's change to match RFC 3986 (URI spec),
> but don't do anything else to comply with RFC 5952. We can also add some text
> to the A/S draft saying that IPv6 syntax is not necessarily canonical, so it
> doesn't follow recommendations from RFC 5952.

Works for me.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Tue, 17 Nov 2020 07:47:41 -0800

> cost. It should be rejected.

+1

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "John Levine" <[email-masked]>
Date: 17 Nov 2020 19:37:25 -0500

>> doesn't follow recommendations from RFC 5952.

OK with me too. I'm certainly not going to change the code that
produces and parses v6 literals in Received headers which is where
they mostly appear in the mail I see.

R's,
John

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 29 Nov 2020 17:33:53 +0000

>> doesn't follow recommendations from RFC 5952.

Based on the mailing list discussion I declare consensus on this ticket 
as per the proposal above (i.e. no further change is needed to rfc5321bis).

Best Regards,

Alexey, as a co-chair