Re: Debian jessie > buster IPv6 link scope change of behaviour
On Thu 21 Jan 2021 at 08:16:23 (+0100), Marc SCHAEFER wrote:
> On Thu, Jan 21, 2021 at 08:04:05AM +0100, Marc SCHAEFER wrote:
> > fe80::1 is specifically a link-local scope, a bit like if you try to
> > access a class variable without telling in what class it is.
>
> Reading RFC-4291 [1], 2.5.6 (link-local addresses) and RFC-4007 [2] 6,
> Zones Indices:
>
> Because the same non-global address may be in use in more than one
> zone of the same scope (e.g., the use of link-local address fe80::1
> in two separate physical links) and a node may have interfaces
> attached to different zones of the same scope (e.g., a router
> normally has multiple interfaces attached to different links), a node
> *requires* an internal means to identify to which zone a non-global
> address belongs. This is accomplished by assigning, within the node,
> a distinct "zone index" to each zone of the same scope to which that
> node is attached, and by allowing all internal uses of an address to
> be qualified by a zone index.
Yes, that documents what we normally observe as a %eth0 or %1 suffix
for IPv6 addresses which selects the interface to use. "Requires"
(unemphasised in the original) mean that it is necessary to identify a
particular zone, but IMHO doesn't mean that a choice of zone is
necessary for the use of an address. I think the last clause means
that every address specification should allow for a zone ID to be
present as well. In the past, some software could handle a zone, but
some couldn't because it hadn't been taken into account.
> Also:
>
> An implementation should also support the concept of a "default" zone
> for each scope. And, when supported, the index value zero at each
> scope SHOULD be reserved to mean "use the default zone". Unlike
> other zone indices, the default index does not contain any scope, and
> the scope is determined by the address that the default index
> accompanies. An implementation may additionally define a separate
> default zone for each scope. Those default indices can also be used
> as the zone qualifier for an address for which the node is attached
> to only one zone; e.g., when using global addresses.
Yes, and I understand that to mean that the absence of the index in
your fe80::1 (as opposed to fe80::1%eth0) should allow fe80::1 to be a
valid address when there is only one zone or a default zone has been
chosen from amongst the many that are available.
> If I read well, recent Linux kernels might have decided that the first
> Ethernet interface is the default zone. Or at least this is how I
> understand the *requires* above.
I don't think it's quite that simple.
> [1] https://tools.ietf.org/html/rfc4291#section-2.5.6
> [2] https://tools.ietf.org/html/rfc4007
As [2] says: "For example, two different physical links may each
contain a node with the link-local address fe80::1.
"Zones of the different scopes are instantiated as follows:
[…]
" o Each link and the interfaces attached to that link comprise a
single zone of link-local scope (for both unicast and multicast)."
which covers, for example, two PCs connected by both a Cat5 cable and
an ad hoc wireless link.
Happening to have unpacked kernel sources for jessie and buster lying
around, I took a look at diffs between code in net/ipv6/, in
particular (icmp,ping,route,addrconf,anycast}.c. Without really
understanding most of the code, obviously, I can see things that
look like handling multiple devices, with reference counts, metrics,
expiration times and so on, resulting in a lot more code.
My hunch is that jessie threw an error merely because it couldn't
handle making a decision on which interface to use, whereas buster
is able to do so. What's going on might be explained by this page
I came across, from which I quote:
Neighbor Discovery
If you have not specified the sin6_scope_id member in the
sockaddr_in6 structure, have not bound a source address, and have
not specified a route for link-local addresses, then the IPv6
protocol will try Neighbor Discovery to resolve the destination
link-local address. For a given packet being sent, one interface is
tried. This first interface that is tried is considered the most
preferred interface. If Neighbor Discovery fails to resolve the
link-local address on an interface, the packet to be sent is dropped
and the system remembers that the destination link-local address is
not reachable over that interface. On the next packet to be sent
under all of the same conditions, a different interface is tried for
Neighbor Discovery. This process continues through each of the
interfaces on a local computer for each new packet until Neighbor
Discovery responds for the destination link-local address or all of
the possible interfaces have been tried and failed. Each time an
attempt to resolve the neighbor fails, one interface is eliminated
for that neighbor.
If the destination link-local address resolves, then that interface
is used to send the current packet. This interface is also used for
any subsequent ambiguously-scoped packets that are sent to the same
link-local destination address.
If Neighbor Discovery fails to resolve the destination link-local
address on all interfaces, the system then tries to send the packet
on the most preferred interface (the first interface tried). The
network stack keeps trying to resolve the destination link-local
address on the most preferred interface. After a period of time
after Neighbor Discovery has failed on all interfaces, the network
stack will restart the process again and try to resolve the
destination link-local address on all of the interfaces. Currently,
this time interval when Neighbor Discovery is again tried on all
interfaces is 60 seconds. However, this time interval may change on
versions of Windows and should not be assumed by an application.
https://docs.microsoft.com/en-us/windows/win32/winsock/link-local-and-site-local-addresses-2
Cheers,
David.
Reply to: