Ambiguity when forwarding port "0"

[Jacob Nevins <jacobn+secsh%chiark.greenend.org.uk@localhost>]

RFC 4254 (ssh-connect) section 7.1 allows a party (client) to specify a
port of 0 in a remote-to-local "tcpip-forward" request. This causes the
other party (server) to unilaterally allocate a port, and optionally
notify the client of that port.

However, a port number is required to identify the tunnel in
subsequent messages sent by the client -- "cancel-tcpip-forward" (7.1)
and "forwarded-tcpip" (7.2).

I can't find it explicitly stated anywhere whether the port number in
these latter messages should be 0, or the port allocated by the server.

Reading through the list archives, some of the original proposals for
this feature (circa 2001) made it clear that port 0 was not to be used
subsequently (and hence implied that the actually bound port should be
used).

This does seem to be the only interpretation that makes sense when you
consider two such requests in a single session.

Going with this interpretation, 7.1 implies that it is optional for a
client to request notification of the bound port; however, if it does
not do so, it can't meet the requirement of 7.2 that "Implementations
MUST reject ["forwarded-tcpip"] messages unless they have previously
requested a remote TCP/IP port forwarding with the given port number."
(Although I don't see what unforeseeable trouble a client could get
into by accepting all such requests, if it had originally sent a port
of 0.)

Does anyone's implementation disagree?