Re: [IPv6] [Last-Call] Artart last call review of draft-ietf-6man-rfc6874bis-02

On 27-Mar-23 13:18, Rob Sayre wrote:
> 
> 
> On Sun, Mar 26, 2023 at 4:58 PM David Farmer <[email protected] <mailto:[email protected]>> wrote:
> 
> 
> 
>     On Sun, Mar 26, 2023 at 17:51 Rob Sayre <[email protected] <mailto:[email protected]>> wrote:
> 
>         On Sun, Mar 26, 2023 at 3:44 PM Brian E Carpenter <[email protected] <mailto:[email protected]>> wrote:
> 
>             In what way does it "break" existing parsers? They simply return an error. Why is that a problem? As discussed at https://www.ietf.org/archive/id/draft-ietf-6man-rfc6874bis-05.html#section-4-1 <https://www.ietf.org/archive/id/draft-ietf-6man-rfc6874bis-05.html#section-4-1>, this is completely compatible with stepwise deployment as and when needed.
> 
>             Yes, it becomes a feature request for existing parsers. And it will only get implemented when the need is irresistible. No different from any other feature request.
> 
> 
>         I think the general issue is that some of them are looking for the "authority" component, and relying on the uniform syntax here. Maybe it's worth breaking that for this feature, but it's not a made-up issue. I still look at it and think "why?", though.
> 
> 
>     So, I’ll bite, why does this syntax interfere with?
> 
>     If anything, because IPv6 literals with Zone IDs are contained within square parentheses “[“,”]”, therefore determining the authority should be easy.
> 
>     Example:
>     http://[fe80::1234%en0]:8080/path-p1/p2
> 
>     Please explain how it interferes with determining a URI’s “authority” component.
> 
> 
> It's not allowed in the original grammar. This is why the draft rewrites the "IP-literal" rule to allow for a zone identifier. I think the catch here is that the chosen delimiter is "%", and that causes problems for URI parsers that are not updated for this issue. You could use a character that would not have this problem, as Appendix A describes.

But what is the operational or security problem? Again, the draft explains why a parsing error by a non-updated destination simply doesn't matter.

(Except that if I sell a CE router that cannot be configured on an IPv6-only network, I will lose customers, so it will be in my interest to fix it.)

Also, even if we changed from "%" to "-", the parsers still all need fixing, and many browsers will need additional code to pass the zone ID on to the socket interface.

> It's possible to change the parsers, but I think the nature of the objections are that you can't actually change all of them. Basically, "%" is probably the worst possible choice.

It is, and that's the problem with RFC4007, but the implications of changing it in every IPv6 stack and socket API implementation are horrendous.

If we had an incontrovertible explanation of why parsers *cannot* be adapted for this, we can go back and ask the user community if they can deal with manually patching % to - every time.

    Brian

_______________________________________________
art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/art