Re: [IPv6] I-D Action: draft-ietf-6man-rfc6874bis-06.txt

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

Jürgen & Shang,

I realised a serious problem with this:

>>> otherwise try to parse them using if_nametoindex()

That is only valid if the URI is parsed in the host where it originated. On any other host, the result will be rubbish.

Parsing for valid characters is OK. Interpreting the actual value is not OK.

Regards
    Brian Carpenter

On 08-Apr-23 10:08, Brian E Carpenter wrote:
> On 08-Apr-23 03:38, Shang Ye wrote:
>> Jürgen & Brian,
>>
>> On 2023/4/7 15:26, Jürgen Schönwälder wrote:
>>
>>> In other words, why not simply use the
>>> following approach:
>>>
>>>      extract ZoneID characters
>>>      try to parse them as a numeric zone identifier
>>>      if succcess, done
>>>      otherwise try to parse them using if_nametoindex()
>>>      if success, use the index
>>>      otherwise report failure (or try any future zone name to index mapping function)
>>
>>    From my experience of writing a URI parser, I can tell that this is
>> indeed the right way of parsing a zone identifier. Should we probably
>> mention this process in the document?
> 
> I'm not convinced. Eventually of course the socket API will parse
> and verify the zone ID, but I don't believe we should attempt to
> to specify exactly when that happens.
> 
>>
>>> What is the rationale for limiting the focus on human readable
>>> strings?  Why not generally support numeric zone indexes as they
>>> should always work and accepting zone names (oops interface names used
>>> as zone names) where this is feasible (i.e., the names use lowercase
>>> unreserved characters)? If we generally support numeric zone indexes,
>>> we would not have to exclude so called "infrastructure devices" since
>>> they should be able to deal with numeric zone indexes as well.
>>
>> Aren't numeric zone indices already supported in the current format
>> because they are exactly human readable strings? Section 11.2 of RFC
>> 4007 also says:
>>
>>       An implementation SHOULD support at least numerical indices that are
>>       non-negative decimal integers as <zone_id>.
>>
>> So I don't understand why this sentence is necessary:
>>
>>       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.
> 
> Because it's only a SHOULD, so we cannot rely on it.
> 
>>
>> On the other hand, the following sentence is mostly true:
>>
>>       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.
>>
>> Except that we can't really make a network interface name on Linux
>> contain slashes, can we?
> 
> Why not? Have you tried?
> 
>>
>> Now that users can work around their inability to use an unsupported
>> interface names in a URI by first converting them into numerical
>> indices, is it possible that we replace the ZoneID ABNF rule with
>>
>>       ZoneID = 1*( %x61-7A / DIGIT / "-" / "." / "_" / "~" )
>>
>> and thus avoid the case-sensitivity issue of zone identifiers altogether?
> 
> The whole point is (for the normal caases) to allow straigthforward cut and
> paste.
> 
> Regards
>      Brian
> 
>>
>>
>> Regards,
>> Shang
>>