Re: tcpip-forward requests and bind addresses

[der Mouse <mouse%Rodents.Montreal.QC.CA@localhost>]

>> [connection forwarding stuff]
> I have some concern with the phrase "all supported protocol
> families".  I don't think it is wise to interpret that as "all
> protocol families that getaddrinfo return".  It should be IPv4, IPv6
> and, beyond that, only protocol families that *really* make sense to
> implementor and/or local sysadm.

Consider, for example, a dual-stack IP-and-DECnet machine.

> One simple argument against random protocol families is that we don't
> specify what the "originator IP address" and "originator port" in
> SSH_MSG_CHANNEL_OPEN "forwarded-tcpip".

This sentence is incomplete; there appears to be a verb missing.

This too has always struck me as a problem with ssh: it is rather
thoroughly IP-centric, whereas there is no inherent reason it couldn't
be designed so as to be usable over any reliable octet stream (DECnet
is my usual gedanken example).

For example, consider agent forwarding and port forwarding; both are
specified in a way which is impossible to extend to, say, DECnet, since
they do not have any kind of protocol identifier.  You'd have to design
a parallel set of requests to do the analogous things with some other
protocol.  (Putting "tcpip" in the names of the port-forwarding
messages helps make this obvious for that one, but the
forwarding-notice message really needs a redesign.)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse%rodents.montreal.qc.ca@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B