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

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

On 25-Mar-23 02:29, Jürgen Schönwälder wrote:
> Rob,
> 
> using '"(%.+)"' in the IP address types may be the most liberal answer
> and in line with the interface YANG module. Applications using
> draft-ietf-6man-rfc6874bis will have to resort to %-encodings to deal
> with forward slashes and the like, which likely is OK in the web
> context.

But they can't, under the ABNF proposed by rfc6874bis. It isn't obvious
to me that percent-encoding is "legal" anywhere in the host part of a URI
(although https://w%57w.ietf.org does appear to work, which demonstrates
both percent-encoding and case-folding). Current practice for "%" inside
an IPv6 literal varies between browsers.

> I do not think we can make the assumption that interface names are
> case insensitive. On Linux, it seems very well possible to have
> interfaces that only differ in case. But this would be more an issue
> for draft-ietf-6man-rfc6874bis and not for YANG data models.

Agreed. But the case-insensitivity of the host part of a URI is
100% clear. So even if Linux allows this, it's never going to work
in the URI context (and the draft already makes that clear).

> 
> I do not think that defining a new zone name type and then to have
> mappings to this new type makes sense. Existing implementations and
> APIs use interface names. Deploying a new indirection may take
> forever.

Agreed. That's why the draft says what it now says, as a practical
matter. Jürgen, have you checked this paragraph?
https://www.cs.auckland.ac.nz/~brian/draft-ietf-6man-rfc6874bis-06X.html#section-1-5
  
> Concerning your second question, I believe that changing the canonical
> format of typedef is a backwards incompatible change and hence I kept
> the numeric version. At the end, both, the zone name and the zone
> number have only local significance. The main difference may be that
> the name may be more stable than the number across device reboots.  If
> I would start from scratch, I would prefer to use the name for this
> reason.

I'm not sure why the name is intrinsically more stable than the number;
in Linux (today) the name will change if the MAC address changes when
a card is replaced, for example.

Regards
    Brian

> 
> /js
> 
> PS: The update of the zone pattern is enlarging the zone value space
>      and hence I consider this a backwards compatible change according
>      to the YANG update rules.
> 
> On Wed, Mar 22, 2023 at 01:32:44PM +0000, 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.  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.
>>
>> 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.
>>
>> 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.
>>
>> This general comment also applies for the same change for 'ipv4-address'.
>>
>>
>> (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)?
>>
>> This comment also applies for the same change for 'ipv4-address'.
>>
>>
>> Thoughts and comments on these two issues are welcome.
>>
>> Regards,
>> Rob
>