On Thu, Apr 14, 2022 at 09:23:38AM -0700, Andy Bierman wrote:
> >
> So is this a correct summary:
>
> - zone index is not used in IPv4 at all
There are link-local IPv4 addresses, they are less wide-spread since
IPv4 stacks generally do not auto-configure IPv4 link-local addresses.
Nobody will be able to confirm "not used at all", this questions is
somewhat rhetoric since nobody can answer it.
> - zone index is not configured by a client in IPv6 at all
Configuring zone indexes is required in many cases to reach services
that are only reachable via link-local addresses. I mentioned the DNS
resolver example and this applies to pretty much any transport layer
endpoint. This is why by design (and not by accident) the with zone
version of ip-address is used in the inet:host typedef.
> - zone index is assigned by the system (as needed) to IPv6 link-local
> addresses
A link-local address exists on a link and as such does not need a zone
index as long it is used on the link. However, when you want to refer
to a link-local address on a system with more than one link, then the
link-local address is ambiguous and to disambiguate things you either
specify in adding the interface to be used or you embed the zone index
in the address. Since application code usually assumes that a
transport address is an (ip-address, port) tuple, people converged on
adding the zone to the ip address (instead of rewriting all APIs to
use (ip-address, port, interface) tuples. The zoned IP address
notation is meanwhile widely supported. This is why we have, for
example, RFC 6874 (but the IPv6 folks have a reoccuring debate about
the question whether the % needs to be percent encoded or not,
draft-carpenter-6man-rfc6874bis-03).
> I want to add a server option in our code to always reject (or alter)
> an edit that contains a zone index. I need to know the consensus on
> whether it is OK to ignore a zone index from a client.
It is your choice to design a product that will not work with
link-local addresses. For IETF data models, I expect that the bar is
higher and that people can expect that IETF data models are written to
also work with link-local addresses. If implementers than decide that
their users do not need to work with link-local addresses, so be it,
you can make your server reject the optional zone index. But others
can decide that they customers can also work with link-local
addresses. If we blindly remove the zone index from ip-address, then
the IETF would break data models for those who consider link-local
addresses a first class citizen.
> Nothing in RFC 6241 suggests that this is OK for <edit-config>.
I have no clue what you mean. If your server recceives a value that
your server does not support, you reject the value.
/js
PS: I recall the side meetings with IPv6 people to sort out how we add
proper IPv6 support to MIB modules, which led to RFC 4001, which
later influenced the YANG typedefs. Almost 20 years later (and
IPv6 deployed at a much larger scale) I find myself in a
discussion where people question that we need to support
link-local addresses. This is very irritating.
Apparently, getaddrinfo() implementations tend to handle zoned
link-local addresses just fine and any code that passes a zoned ip
address string to getaddrinfo() will likely return you a socket
address with the sin6_scope_id filled in properly. You actually
have to do extra work to prevent the right thing to happen if your
code passes strings on to getaddinfo(). I am puzzled why people
want to do this.
--
Jürgen Schönwälder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
