-----BEGIN PGP SIGNED MESSAGE-----
Seok J. Koh wrote:
Anyway, with IPv6 the address format is fundamentally incompatible with
that of IPv4 so there is no choice but running them concurrently during
the transition period. A new multihoming-capable transport protocol
doesn't have to be incompatible with existing TCP so this situation is
avoidable here.
It does not seem reasonable to compare the IPv6/IPv4 deployment and
SCTP/TCP deployment. SCTP and TCP are basically the
end-to-end protocols so that hosts/terminals have only to have them, whereas
IPv4
and IPv6 are subject to network support or change.
I see a possibility of speeding up SCTP deployment by using semi-NAT,
what about PT, Protocol-Translation, this could be accomplished using
a BIA (Bump In the API) approach.
Scenario: Clients connects to server.
Client's TCP/SCTP stack sees a connect() using TCP, it changes the
protocol field to SCTP and just tries to connect(), if it fails it
uses the normal TCP protocol.
Server starts to listen on TCP. It checks to see if the same port
for SCTP is already in use, if not, it also binds to SCTP.
Thus any client will also try to use sctp and any servercode will
automatically bind to SCTP, voila free multihoming code.
Putting this in the defacto Linux kernel will instantaniously have
a major deployment as generally people who keep up with new kernels
also enable the new toys in those kernels.
Or did someone already draft or even implement this? :)
Greets,
Jeroen
-----BEGIN PGP SIGNATURE-----
Version: Unfix PGP for Outlook Alpha 13 Int.
Comment: Jeroen Massar / http://unfix.org/~jeroen
iQA/AwUBQBr9GimqKFIzPnwjEQIhvgCfQn3SZ30zZRPz2C4DDmajFYpNjzoAnRVW
fTxLNkJcHK3nK+B1XNr3gPvB
=q2g+
-----END PGP SIGNATURE-----