Remote TCP forwarding

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

I see a weakness in the remote port forwarding message in connect-18.
I'm wondering if this is for real or if I'm confused.  (Or perhaps even
it's been discussed before - ftp.ietf.org appears broken in a _very_
peculiar way[%], keeping me from checking the archives.)

It's specified as

     byte      SSH_MSG_GLOBAL_REQUEST
     string    "tcpip-forward"
     boolean   want reply
     string    address to bind (e.g. "0.0.0.0")
     uint32    port number to bind

   `Address to bind' and `port number to bind' specify the IP address
   and port to which the socket to be listened is bound.  The address
   should be "0.0.0.0" if connections are allowed from anywhere. (Note
   that the client can still filter connections based on information
   passed in the open request.)

I note that the "0.0.0.0" is IPv4-specific.  The "anywhere" seems to
imply that 0.0.0.0 should actually be taken as "this port for all
available IP versions" - but that interpretation leaves no way to
request forwarding for v4 only, but with a wildcard bind-to address.

Is there simply no way to request forwarding for both v4 and v6 with a
single request?  Might it be better to specify that a "" bind-to string
specifies "anywhere", with "0.0.0.0" and "::" available to wildcard
IPv4 and IPv6 specifically?

Certainly, the client could request 0.0.0.0 and :: both, but this
requires the client to know (a superset of) the IP versions the server
has available.  Since v4 and v6 are the only likely possibilities at
present, this is not much of a practical problem, but it certainly is
an aesthetic problem and could turn into a practical one if ssh
survives into the next IP version.

/~\ 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

[%] The brokenness I'm seeing is that the connection never comes up.
    tcpdumping shows me my SYN going out, a SYN-ACK coming back, my ACK
    going out, a pause, then the SYN-ACK being retransmitted and my ACK
    answering it.  The SYN-ACK/ACK exchange repeats until something
    (presumably the ftp client) gets fed up and closes the connection.