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

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

On 08-Apr-24 05:37, Jürgen Schönwälder wrote:
> Please see inline...
> 
> On 06.04.24 22:50, Brian E Carpenter wrote:
> 
>> 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.
> 
> I will do the following change:
> 
> OLD
> 
>         [...] All unnecessary
>         percent-encoding is removed, and all case-insensitive
>         characters are set to lowercase except for hexadecimal
>         digits, which are normalized to uppercase as described in
>         Section 6.2.2.1.
> 
> NEW
> 
>         [...] All unnecessary
>         percent-encoding is removed, and all case-insensitive
>         characters are set to lowercase except for hexadecimal
>         digits within a percent-encoded triplet, which are
>         normalized to uppercase as described in Section 6.2.2.1
>         of RFC 3986.

Yes, that's perfect.

> 
>> 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.
> 
> I am pretty optimistic that you can memset a sockaddr_in6 to zero and
> then fill out the sin6_addr field and things will work. 

I'm afraid not. If you call sendmsg() with a link-local destination and
a zero sin6_scope_id, you get "[Errno 22] Invalid argument". If you call
it with a non-existing positive value, you get "[Errno 101] Network is
unreachable".

Tested on my Linux machine with the attached Python script. And I knew
this anyway from testing with ping.

> Perhaps the zero
> is not what RFC 4007 calls the default zone, then we need to find
> better wording. But then RFC 4007 also says:
> 
>      An implementation should also support the concept of a "default" zone
>      for each scope.  And, when supported, the index value zero at each
>      scope SHOULD be reserved to mean "use the default zone".

However, that "should" and "SHOULD" have not been implemented for Linux.

> 
>> 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.
> 
> Yes, the zone ID is underspecified, and we can't really fix that. What
> we had did not allow forward slashes, although they are used by some
> vendors. So we are trying to improve but whatever we do is debatable
> since the zone ID is underspecified. (On Linux, I am pretty sure an
> interface name does not even have to be ASCII or UTF-8. Whatever we
> end up doing, we will likely assume UTF-8.)

OK, I understand that choice. Maybe you should say in the description
that the zone ID is underspecified in the RFC?

> 
> This is why I suggested to write an ID that explains what happens if
> people go creative with zone IDs so that people know that certain zone
> IDs will not play nice with YANG modules, certain zone IDs will not play
> nice with URLs and so on. People can than take an informed decision and
> deal with the consequences.

Well, I think 6man really ought to clean up RFC 4007 in this respect.
But that is a battle for another day.

     Brian