[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: requirements draft revision



On Wed, 27 Jun 2001, Brian E Carpenter wrote:

> > If the new way of multihoming requires action (upgrading software) by the
> > other end, obviously this will be less effective because the number of sites
> > that upgrade their software will always be less than 100%.

> And people still use Windows 3.1. We can't make this a killer argument
> for host updates - that's exactly why I drafted 3.2.3.

Of course at some point some software has to change. But just look at the
speed at which IPv6 is being deployed: people DON'T want to update their
software if it doesn't benefit THEM immediately.

This is exactly the reason why I don't think GxSE is the way to go: it
requires software updates in just about everything to work at all. We need
something that at least works as a single homed system in every instance and
works well within the limits of the software/protocol version environment it
lives in.

So a current IPv6 host should benefit from newer routers rewriting
addresses. And newer IPv6 hosts should be able to survive outages by using
multiple IP addresses even if the routers aren't capable of rewriting.

Obviously, the optimal situation is reached when all the hosts and routers on
both ends are completely up-to-date on all the new protocols. 

So what we need for a GxSE-like solution would be something where either the
end host or a router does all the processing or they share, with every case
being a likely possibility. In the first case, a host would have multiple GR
addresses and transparently accept a change of destination of incoming
packets (the sending side has better information about what works because it
(hopefully) gets ICMP messages when a packet can't be delivered). On the
other hand, if the host doesn't support the new scheme a router has to act as
a "multihoming proxy agent" and mimic regular IP connectivity towards the
internal host.

Note that the permutations between source and destination addresses when two
multihomed sites communicate can grow quickly in such a solution: when both
ends have two addresses there are four possible paths, with three addresses
each nine. Selecting the best path will be very hard in this situation and
even selecting just a reasonable one can be a non-trivial problem.

> > Basically, I'm saying the new way of multihoming should be at least as
> > attractive to most users as the current way.

> In the long term.

I'd say: intermediate term.

Iljitsch van Beijnum