On Mon, Jan 25, 2021 at 01:19:48PM +0100, Marc SCHAEFER 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.
It does not invalidate ping's usefulness for debugging. When you specify a scope explicitly, it is respected. This is exactly the behavior you need when debugging. > > 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. Right. A scope is required in order to fully specify the address. That's clear enough. However, there's nothing in there that forbids a client from choosing a scope based on routing rules or some other mechanism when a scope isn't explicitly provided by the user. noah
