Re: Backwards compatability with existing IPv6 [was: Re: Networklayer reqt? [was Re: Transport level multihoming]]

[itojun@iijlab.net]

	I finally catched up :-)

>Regardless - you are hearing the same thing from more than one vendor.
>Backwards compatibility with the code already implemented is a
>real world requirement here, to be added to the real world requirements
>we are getting from operators.
>As I have been trying to say, that doesn't prevent imaginative solutions
>but it does slightly constrain them: they mustn't break connectivity
>for RFC 2460 systems.

	I agree that the compatibility to RFC2460/TCP-as-of-today/without-SCTP
	nodes is the MUST.  It is okay even if they cannot enjoy the full
	benefits of some proposals, but they must be able to talk with others
	with multi6 proposals (= multi6 proposals with transport layer changes
	must be backward comptaible IMHO).

	If you need some numbers regarding to deployment and backward compat
	issues: Even at IETF50 venue (from what I have seen, IETF people are
	very conservative regarding to OS upgrades), there are at least 70
	nodes that are IPv6 aware.  It was reported at the plenary that there
	are 900+ laptops users on the wireless segment (I guess Fred counted
	the number of IPv4 DHCP leases).  70/900 = 7.7%.
	http://www.kame.net/ietf50/
	at Yokohama IETF (summer 2002) maybe we should provide term clusters 
	IPv6-only, as in Japan IPv4 address shortage situation is very severe
	and we have no choice:-):-):-)

	if I can put my $0.02, transport layer change should be optional
	transport layer changes will take a VERY long time to get deployed
	(please see the deployment/usage status of recent TCP options and
	tricks).  multi6 proposal has to include some other items that works
	without changes to the end nodes, and with minimal amount of impact to
	worldwide routing table (like routing coordination that do not impact
	worldwide routing table)

itojun