-----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-----