I notice that draft-ietf-6man-rfc6874bis has expired. What is the plan with
that document? Was there any consensus on the zone identifier?
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?
Thanks.
> On Mar 31, 2023, at 3:43 PM, Brian E Carpenter <brian.e.carpen...@gmail.com>
> 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
>>>
>>> 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
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
Mahesh Jethanandani
mjethanand...@gmail.com
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
