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

Re: Options to consider [Re: tunneling [Was: Agenda for Vienna]]

On donderdag, mei 22, 2003, at 17:33 Europe/Amsterdam, Christian Huitema wrote:

Christian, could you (again) send some pointers to what it is you're
talking about when you say "multi-adressing"?



I intend to submit as a draft the doc that David Kessens and I sent to
the group at the time of the San Francisco IETF. The basic notion is
that a site is connected through several providers, and receives a
different addressing prefix from each provider. Hosts in the site
receive multiple prefixes announcement through the standard
auto-configuration mechanisms. They configure addresses using one or
several of these prefixes.




Ok. This is what I tried to do a couple of years ago with little 
success (I mean actually do, not write a draft or something).




The major rule of engagement in the multi-addressing scenario is

backward compatibility: hosts that would have functioned well using

standard implementations should continue functioning well even when

connected to a multi-addressed site. Hosts that have been augmented 
with

some multi-addressing support capability function better in a

multi-addressed site, for example ensuring that their sessions survive

or that their packets follow the most efficient path.



Ok, this is a big problem. Let's call existing hosts that have multiple 
addresses but don't know how to handle them "naive" multiaddressed 
hosts.




The doc pointed out the need to solve several issues, the most pressing
of which being the interaction between multi-addressing and ingress
filtering.




Exactly. Naive MA hosts don't get this, so they select the wrong 
source/dest combinations that can't work in the presence of ingress 
filtering. I see three solutions:



1. Source address based routing. Since this is helpful in other, 
related areas as well it would be good to implement this.

2. Giving hosts a routing table. This can work for some hosts under 
some circumstances, but it doesn't scale, certainly not in the long 
run, and there's still the problem of breaking sessions when there are 
routing changes.

3. Give naive hosts only a single address. This should work for those 
hosts, but then either autoconfiguration has to change or lots of 
manual configuration for smarter multiaddressed hosts.




It occurs to me that the address selection problem isn't so different
between loc/id and other multiaddress solutions. It's just that in
loc/id it isn't as vital to get it right as you can change your mind
later.





It could be argued that the loc/id split is a form of multi-homing,

where the "id" is in fact a "virtual provider" address. It is possible

to use the distributed hash table technology to enable overlay routing

of these addresses, in which case the "virtual provider" is just 
another

provider.



That is one way of looking at it. And some discovery or negotiation 
methods may in fact need those vitual providers.