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

[Mark Smith <[e-mail]>]

Hi,

On Wed, 29 May 2024 at 10:53, David Farmer
<farmer=[e-mail]> 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.
>

As a general observation, I think the mechanism of a default zone has
become less useful as hosts have become commonly multi-interface and
therefore can more likely be multi-homed since RFC 4007. A default
zone is much easier to implement and obvious to operate on a single
interface host.

If I think about all of the "end-user" hosts I've acquired over the
past 10+ years, e.g., "small" (Rasberry Pi) and large desktop PCs,
laptops, smartphones, all of them have 2 or more interfaces that can
run IPv6, such as wired, Wifi and Bluetooth interfaces.

The host being IPv4 or IPv6 multi-homed is also becoming generally
more common e.g., a smartphone with tethering enabled.

Default zone has a place, however I think the need to be able to
specify an outgoing interface has increased.

> 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.
>

I think this is assuming that bouncing an interface is not disruptive
to anybody other than the person using this interface/zone specifying
capability.

This would preclude what this RFC is proposing being used on servers,
routers and switches for troubleshooting.

While I've specified outgoing interfaces on hosts on a number of
occasions* for both IPv4 and IPv6, it has been far more common for me
to do that on routers during  IPv4 and IPv6 troubleshooting such as to
override a route table entry. Bouncing an interface on a router to
change the default zone would typically be more disruptive than the
fault I'm trying to fix.


Regards,
Mark.



> 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]> 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/
>>
>> 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]
>> Administrative Requests:
>> --------------------------------------------------------------------
>
>
>
> --
> ===============================================
> David Farmer               Email:[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]
> Administrative Requests:
> --------------------------------------------------------------------