Re: [netmod] Changes to IPv6 zone definition in draft-ietf-netmod-rfc6991-bis-15

[Brian E Carpenter <[e-mail]>]

Hi Mahesh,

On 06-Apr-24 17:18, Mahesh Jethanandani wrote:
> I notice that draft-ietf-6man-rfc6874bis has expired. What is the plan with that document? Was there any consensus on the zone identifier?

There was consensus in the 6MAN WG, but no chance of consensus with the W3C and WHATWG community, so the draft is considered dead. Not everybody is happy with that, hence my Cc to Toerless.

There are two resulting active drafts:
https://datatracker.ietf.org/doc/draft-carpenter-6man-zone-ui/
https://datatracker.ietf.org/doc/draft-schinazi-httpbis-link-local-uri-bcp/

Note that RFC6874 itself is very likely to be obsoleted, since both of these drafts do so!

> I ask, because I am interested in moving rfc6991-bis forward. Can we close on this thread with lowercase and % encoding of special characters as the consensus?

I am discovering your draft as I type, but I assume you are referring to typedef uri {}. Assuming that RFC6874 is indeed obsoleted, you can just forget about this issue until something changes.

I do see a quite different glitch in your typedef uri {}. If the host part of a URI is a literal IPv6 address, normalizing to uppercase contradicts Section 4.3 of RFC5952 which says:

'4.3.  Lowercase

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

Therefore, normalizing to uppercase would be an error. However, I think your text is wrong anyway: section 6.2.2.1 of RFC3986 applies to hex digits *within a percent-encoded triplet* and in fact hex digits in the host part would be normalized to lowercase.

So where your draft reads "except for hexadecimal digits", it should read "except for hexadecimal digits within a percent-encoded triplet", for consistency with RFC3986 and RFC5952.

While I'm here, I looked at typedef ipv6-address {}. Two comments:

1. "If the zone index is not present, the default zone of the device will be used."
FYI, although RFC 4007 describes the default zone, it's optional. For example, there is no default zone on Linux; if you execute a socket call with a zero or null zone, it's a run-time error.

2. There seems to be a limited character set for the zone ID. RFC 4007 doesn't restrict the character set; it just says "non-null strings". IMHO that's a bug, but if I want to name an interface *%!@#$^&()_-+=:;'"?\|}{}{/.><, it's allowed by the RFC. (The text doesn't even specify ASCII, and the remark about "conflict with the delimiter" is meaningless, if you think about parsing.)

If you intend to limit the character set more than RFC 4007 does, that should be stated, and probably discussed on the 6man list.

Regards
     Brian

> 
> Thanks.
> 
>> On Mar 31, 2023, at 3:43 PM, Brian E Carpenter <[e-mail] <mailto:[e-mail]>> wrote:
>>
>> I just put two and two together and got five. There are so many threads that I can't remember who brought this point up, but the editor's copy of draft-ietf-6man-rfc6874bis now includes this:
>>
>> "The mapping
>> between the human-readable zone identifier string and the numeric value is a host-specific
>> function that varies between operating systems. The present document is concerned only
>> with the human-readable string. However, in some operating systems it is possible
>> to use the underlying interface number, represented as a decimal integer, as an alternative
>> to the human-readable string. For example, on Linux, a user can determine interface
>> numbers simply by issuing the command "ip link show" and then, for example,
>> use "fe80::1%5" instead of "fe80::1%Ethernet1/0/1", if the interface number
>> happens to be 5."
>>
>> I don't know whether this work-around will apply in every type of device, but I certainly can't see any other solution, since the URI syntax is very insistent on lowercase normalization and special characters.
>>
>> Comments?
>>
>> Regards
>>   Brian Carpenter
>>
>> On 23-Mar-23 14:48, Brian E Carpenter wrote:
>>> Hi Rob,
>>> On 23-Mar-23 02:32, Rob Wilton (rwilton) wrote:
>>>> Hi Jürgen, Netmod, & rfc6874bis interested parties,
>>>>
>>>> In my AD review of draft-ietf-netmod-rfc6991-bis-15, Jurgen has proposed a change to definition of the zone-id in the ip-address, ipv4-address, and ipv6-address types.  These changes move the definition somewhat closer to what is in rfc6874bis, but they are still different enough that we don't have wide compatibility.
>>>>
>>>> I think that it may be useful to have a discussion to see if we can find a technical solution that works both for YANG models and that is compatible with being used in URIs.  Hence, I've separated my AD review comments for these two specific issues into this separate thread to try and ensure that interested parties can be involved in the discussion:
>>>>
>>>> (2) In RFC 6991:
>>>>       typedef ipv6-address {
>>>>         type string {
>>>>           pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}'
>>>>                 + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|'
>>>>                 + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}'
>>>>                 + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))'
>>>>                 + '(%[\p{N}\p{L}]+)?';
>>>>
>>>> In draft-ietf-netmod-rfc6991-bis-15, p 27, sec 4.  Internet Protocol Suite Types
>>>>       typedef ipv6-address {
>>>>         type string {
>>>>           pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}'
>>>>                 + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|'
>>>>                 + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}'
>>>>                 + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))'
>>>>                 + '(%[A-Za-z0-9][A-Za-z0-9\-\._~/]*)?';
>>>>
>>>> I'm not saying that this change is wrong, but this technically looks to be a non-backwards-compatible change (depending on whether interface names could ever use non-ASCII characters).  Where is the set of allowed characters for zone-ids defined?  I couldn't find them in an RFC, RFC 4007 section 11.2 seems to indicate that there is no restriction.
>>> RFC 4007 is woefully vague, but it does limit the character set to ASCII. The failings I have noted so far include:
>>> 1) No length limit - i.e. exposed to buffer overrun bugs and exploits;
>>> 2) NULL is not disallowed - i.e. exposed to NULL-terminated string bugs and exploits;
>>> 3) In fact, no statement about non-alphanumeric characters at all;
>>> 4) No statement about case sensitivity or case folding;
>>> [It's clear to me that RFC 4007 needs to be revisited after we have settled the current issues.]
>>> All of these are problematic in the URI context, not to mention the poor choice of "%" as a delimiter.
>>> The above doesn't tell me what is intended about case sensitivity, and it does include "/" which is troublesome in URIs.
>>> Maybe you could consider an even more complex definition that distinguishes general zone identifiers from URI-friendly zone identifiers? The latter would be something like
>>> '(%[a-z0-9][a-z0-9\-\._~]*)?'
>>> Then there could be a general recommendation to use the restricted character set if, and only if, there is an operational requirement to generate URIs for a given interface.
>>>>  draft-ietf-6man-rfc6874bis, which I'm currently holding a 'discuss' ballot position on, effectively limits the usable character set of zone-ids to the unreserved set in URIs, which seems to match those above except for '/' that is allowed above (and used in many interface names), but not in the URI's unreserved character set.  A further difference is that upper case characters are allowed in this typedef but are not allowed when used in the host part of URIs.
>>> Well, more precisely they will almost certainly be normalized to lower case by the URI parser.
>>>
>>>> Update - I've now seen the thread 'ipv6-address in RFC 6991 (and bis)', and Jürgen has put together a useful blog post, thanks!
>>>>
>>>> Given that "interface-name" in RFC 8343, and the text in RFC 4007 section 11.2, then arguably the safest thing here would be to allow the zone-id to be unrestricted, i.e., "(%.*)?"  However, this would leave draft-ietf-6man-rfc6874bis as only being able to support a small fraction of interface names as zone-ids in URLs.  The authors of draft-ietf-6man-rfc6874bis seem to indicate that it works for all interface names that currently matter for their use case.
>>> That appears to be correct, as noted in the newly proposed text at
>>> https://www.cs.auckland.ac.nz/~brian/draft-ietf-6man-rfc6874bis-06X.html#section-1-5 <https://www.cs.auckland.ac.nz/~brian/draft-ietf-6man-rfc6874bis-06X.html#section-1-5>
>>>>
>>>> An alternative solution could be to somewhere define the zone-ids in YANG to match the restrictive set in draft-ietf-6man-rfc6874bis (i.e., lower case only, and disallow '/').  I think that this would then require that we recommend a conversion of interface names into draft-ietf-6man-rfc6874bis compatible zone-ids interface-names.  E.g., such a conversion could take the interface name, and change any uppercase characters to lower case, and replace any symbol that isn't in the allowed character set with '_'.  This conversion is effectively one way, and there is a theoretical risk that the converted interface names could collide, but this may be unlikely in practice.  Obviously, this conversation doesn't handle non-ASCII interface names, but I'm not sure how realistic it is that they would be used anyway.
>>> Remember there is a browser between the URI and the operating system, and the browser communicates with the operating system via a socket interface. So such a conversion is useless unless the socket interface in the device concerned is fully aware of the mapping. So even if there is a use case, there are a lot of moving parts here.
>>> Personally I think allowing non-ASCII would be disastrously complex and would have no real advantage for netops staff. Езернет1/0/1 instead of Ethernet1/0/1 doesn't seem worth all the resultant hassle.
>>>>
>>>> This general comment also applies for the same change for 'ipv4-address'.
>>> Fortunately this is 100% out of scope for the 6man draft.
>>>>
>>>> (3) draft-ietf-netmod-rfc6991-bis-15, p 28, sec 4.  Internet Protocol Suite Types
>>>>
>>>>           The canonical format of IPv6 addresses uses the textual
>>>>           representation defined in Section 4 of RFC 5952.  The
>>>>           canonical format for the zone index is the numerical
>>>>           format as described in Section 11.2 of RFC 4007.";
>>>>
>>>> Would it make sense to also change the canonical format for the zone index to be interface name (or converted interface name) rather than numeric id (when used in YANG models)?
>>> Please not. In a completely different context (RFC 8990) I've written code handling link local addresses and multiple interfaces, and driving it by interface index rather than by name is definitely the way to go. Humans may like the names, but the numbers are much better for programs.
>>> Regard
>>>     Brian
>>>>
>>>> This comment also applies for the same change for 'ipv4-address'.
>>>>
>>>>
>>>> Thoughts and comments on these two issues are welcome.
>>>>
>>>> Regards,
>>>> Rob
>> _______________________________________________
>> netmod mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/netmod
> 
> 
> Mahesh Jethanandani
> [e-mail] <mailto:[e-mail]>
> 
> 
> 
> 
> 
>