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.
