[IPv6]Re: draft-carpenter-6man-zone-ui: Call for Adoption

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

On 29-May-24 16:44, David Farmer wrote:
> Even with all its problems, and there are many, RFC4007 is remarkably effective. The primary thing missing is a viable solution for IPv6 link-local literals in a URI, especially in a web browser. Earlier in this thread, you said, "This approach does not resolve the issue of how browsers should support link-local addresses." Where instead, I believe a properly clarified and required "default" zone will resolve many of the issues of how browsers should support link-local addresses.
> 
> So, I guess my question is: What use cases that don't currently work does this actually fix? Most applications seem to get what they need out of RFC4007, except for how browsers should support link-local addresses.

Well, I can give you one example today, in a quite well-known program. When I run Wireshark on Windows, here's the list of interfaces it offers me:

  Ethernet 4
  Adapter for loopback traffic capture
  Local Area Connection* 10
  Local Area Connection* 9
  Local Area Connection* 8
  Local Area Connection* 2
  Local Area Connection* 1
  Wi-Fi
  Ethernet 7
  Ethernet 6

When I ask Windows via ipconfig what interfaces are present, here are the names it gives me:

Wireless LAN adapter Wi-Fi:
Wireless LAN adapter Local Area Connection* 1:
Wireless LAN adapter Local Area Connection* 2:
Ethernet adapter Ethernet 7:
Ethernet adapter Ethernet 4:
Ethernet adapter Ethernet 6:

When I'm connected to both WiFi and Ethernet, they are known as "24" and "7" in RFC4007 terminology. "7", by the way, is not "Ethernet adapter Ethernet 7", it's actually "Ethernet adapter Ethernet 4". It's immensely confusing that Wireshark doesn't use the same interface identifiers as the IPv6 address format.

If I want to apply a Wireshark display filter for link-local traffic to/from a specific address, I obviously want to use RFC4007 format:

ipv6.addr == fe80::2e3a:fdff:fed6:dde7%7

but I can't, because Wireshark doesn't allow it.

In any case, I repeat that the zone-ui draft is orthogonal to updating RFC 4007, and addresses a whole different set of implementers. IMHO we should do both.

     Brian

> 
> Thanks
> 
> On Tue, May 28, 2024 at 10:08 PM Brian E Carpenter <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     Strangely enough, I agree with all David's suggestions for improving RFC 4007 (which has other deficiencies that he doesn't mention).
> 
>     But I disagree that fixing RFC 4007 would obviate the need for the zone-ui draft. The two things are orthogonal. This draft is the easy part, and IMHO should be done first.
> 
>     Regards
>          Brian Carpenter
> 
>     On 29-May-24 12:52, David Farmer wrote:
>      > I do not support the adoption of this draft. In my opinion, it doesn't fundamentally solve the problem. It provides only slightly more guidance than RFC4007 by adding the option of treating the Zone Identifier as a completely separate input field instead of connecting it with an IPv6 literal using the "%" or other delimiters. While I agree this technique is implementable by many applications, including modern web browsers. Nevertheless, I prefer a different solution to the problem, which I think is more consistent with an unmodified IPv6 literal URI specification in RFC3986.
>      >
>      > I believe a better solution to the problem involves the "default" zone. First, the current definition of the "default" zone is confusing. It needs significant clarification and more details about how the "default" zone functions. Second, all implementations should be required to implement the "default" zone for at least the link-local unicast and link-local multicast scopes.
>      >
>      > Further, I would like to see a recommendation that the default zone should be associated with the interface that came online most recently for at least the link-local scope. This would allow a user to easily change the interface associated with the link-local default zone by simply bouncing the desired interface.
>      >
>      > Finally, since multicast DNS relies on the link-local multicast scope, clarifying the "default" zone behavior for the link-local multicast scope will also provide more consistent multicast DNS behavior when multiple link-local multicast scopes are present.
>      >
>      > Thanks
>      >
>      >
>      >
>      >
>      >
>      > On Tue, May 28, 2024 at 3:33 AM Jen Linkova <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>      >
>      >     This email starts an adoption call for the following document:
>      >
>      >     Title : Entering IPv6 Zone Identifiers in User Interfaces
>      >     Authors : B. Carpenter, R. Hinden
>      >     Pages : 9
>      >     Date : 2024-03-31
>      >
>      > https://datatracker.ietf.org/doc/draft-carpenter-6man-zone-ui/ <https://datatracker.ietf.org/doc/draft-carpenter-6man-zone-ui/> <https://datatracker.ietf.org/doc/draft-carpenter-6man-zone-ui/ <https://datatracker.ietf.org/doc/draft-carpenter-6man-zone-ui/>>
>      >
>      >     Please note that the draft in question is a continuation of the work
>      >     done in draft-ietf-6man-rfc6874bis which was adopted by this WG
>      >     previously.
>      >
>      >     Substantive comments, statements of support for adopting this
>      >     document or objections to the adoption should be sent to the mailing
>      >     list.  Editorial suggestions can be sent to the authors.
>      >     .
>      >     This adoption call will end on June 12th 2024.
>      >
>      >     Regards,
>      >
>      >     Ole & Jen
>      >
>      >     --------------------------------------------------------------------
>      >     IETF IPv6 working group mailing list
>      > [e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
>      >     Administrative Requests:
>      >     --------------------------------------------------------------------
>      >
>      >
>      >
>      > --
>      > ===============================================
>      > David Farmer Email:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
>      > Networking & Telecommunication Services
>      > Office of Information Technology
>      > University of Minnesota
>      > 2218 University Ave SE        Phone: [phone]
>      > Minneapolis, MN 55414-3029   Cell: 612-812-9952
>      > ===============================================
>      >
>      > --------------------------------------------------------------------
>      > IETF IPv6 working group mailing list
>      > [e-mail] <mailto:[e-mail]>
>      > Administrative Requests:
>      > --------------------------------------------------------------------
> 
> 
> 
> -- 
> ===============================================
> David Farmer Email:[e-mail] <mailto:[e-mail]>
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE        Phone: [phone]
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================