[RRG] Evolutionary Possibilities

[Randall Atkinson <rja@extremenetworks.com>]

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
rja@extremenetworks.com



--
to unsubscribe send a message to rrg-request@psg.com 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