On Sat, Jan 23, 2021 at 10:04:00AM -0800, Noah Meyerhans wrote: > https://github.com/iputils/iputils/pull/100
Interesting. They interpret the fact that link-local works as expected as `broken', and fixed it. > I agree that this is the normal way of fully specifying a link-local > address. However, rfc 4291 does not prohibit inferring the scope based > on routing tables, as far as I can tell, so I'm not sure that ping's > behavior is outright wrong. It is incompatible with telnet and all other utilities I tried, which means that debugging with ping now is moot. > If you can find text in the standards that indicates that ping is > actually behaving incorrectly, then I'm very happy to raise this issue 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.
