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

[David Farmer <[e-mail]>]

On Tue, May 28, 2024 at 10:00 PM Mark Smith <[e-mail]> wrote:

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

If a device selects the default zone to use without any option for input
from the user, then I agree that the default zone is rarely going to be
useful. However, if the user is able to specify the default zone to use,
that is effectively the same thing as including the zone identifier with an
IPv6 literal. I believe the correct definition is that the default zone, as
specified by the user, is used as the zone identifier to use if a zone
identifier is not explicitly included.

Yes, bouncing an interface will be disruptive in many cases, especially for
servers and routers. It is not a universal answer. However, it will not be
disruptive in all cases; when it is not, it could be an easily understood
and verifiable option for unsophisticated users, especially when
bootstrapping a device or network. It will not eliminate the need for,
especially sophisticated, users to be able to specify the default zone or
include a zone identifier with an IPv6 literal; it is just an option to use
when appropriate.

Thanks.

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