Am Montag 11 Dezember 2006 12:02 schrieb Rémi Denis-Courmont: > > And again: where is this documented? > > Partly in RFC 3542. Otherwise in glibc source code.
Ok, if this is a standard way, then that's valid behaviour. However, the words in the RFC are _not_ that specific: "When the address is a scoped one, there may be ambiguity about its scope zone. This is particularly the case for link-local addresses. In such a case, the kernel must first determine the appropriate scope zone based on the zone of the destination address or the outgoing interface (if known), then qualify the address. This also means that it is not feasible to specify the source address for a non-binding socket by the IPV6_PKTINFO sticky option, unless the outgoing interface is also specified. The application should simply use bind() for such purposes." There is no "must" anywhere in that. "may be" can be read as "unless there is", and "if known" is even more clear. I agree with the problem on bridges but not on a normal system (unless many interfaces share the same MAC address like on some Sparc systems). However, if the match can be unique (and that's the case in my system), it IS possible to do without specifying the interface. And it's even more non-sense when the system only has one interface. Wouldn't be the first case for lazy kernel functions, though. Neither is the dumb behaviour that follows this. Anyway, no standard user reads such RFCs. So if you want to close this bug, either document that in getaddrinfo(3) _and_ let the ssh manpage refer to that (a normal user does not know that ssh is using that function) or document that directly in the ssh manpage. I don't mind adding an "%eth0" to the address but without documentation, it is useless. Some remotely available RFC (that doesn't mention the '%') is not sufficient, neither is a reference to the some source code snippet. HS
