Bug#295731: ssh fails to bind link-scope IPv6 addresses

[Hendrik Sattler <debian@hendrik-sattler.de>]

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