Earlier, David Conrad suggested: % We already have to change host stacks and applications to support % IPv6. Given the minimal deployment of IPv6 to date, particularly % within the application space, this doesn't seem like a non-starter % to me.
Agreed. Let me go farther, and in a bit of a different direction...hence the updated subject line. (I'd be greatly obliged if everyone would update subject lines when the topic/focus of a thread changes. :-) I don't think that it is too late to be enhancing IPv6. For example, one could easily imagine taking some of the ideas originating back with ddc and mo and applying them now to IPv6. The functional requirement would be that the enhanced IPv6 remain backwards compatible with existing IPv6 -- for the near term. Even today, most companies have actively disabled the IPv6 stacks inside their Windows systems (because of security concerns with TEREDO). A trivial way to deploy this would be to include a new IPv6 Destination Option ONLY for the first packets of those sessions originating in systems that have support for "enhanced IPv6". The option would not be needed once TCP hit "established" state or SCTP hit its equivalent or after the first few UDP packets in a flow. This option could be an indication, for example, that the transport-layer pseudo-header checksum only included the lower 64-bits (ID) and not the upper 64-bits (Locator -- or if one prefers 'Routing Prefix'). Old systems would drop the new packets because of either the unknown Destination Option OR because the transport-layer pseudo-header check failed at input time. The updated originating host would then fall back to "classic IPv6" using the existing all-128-bits pseudo-header calculation and omitting the new Destination Option. Then, to create pull for this new IPv6 enhancement, use that to enable host mobility, network mobility, node multi-homing, site multi-homing, and so forth. Mind, this would do zero for the RIB/FIB tables in the deployed IPv4 Internet -- but it could do a great deal to reduce/manage RIB/FIB table sizes in a future IPv6 Internet -- and could also do a great deal towards scalable, widely used, widely deployed mobility/multi-homing solutions. It might sound wacky to some, but this would be a very reasonable evolutionary path forwards -- and it would address a broader set of routing architectural issues than just the RIB/FIB size. (Kindly keep the IPv4 caveat above in mind. :-) Yours, Ran [EMAIL PROTECTED] -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
