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

From: "Christian Huitema" <[email-masked]>
Date: Thu, 22 May 2003 08:33:30 -0700

> > As for multi-addressing itself, naros addresses one of the issues,
i.e.
> > the choice of addresses by multi-addressing aware hosts.
> 
> Christian, could you (again) send some pointers to what it is you're
> talking about when you say "multi-adressing"? (It has been a long time
> since Atlanta.) Obviously all IPv6 hosts know about having more than
> one address. Which immediately poses the problem of both source and
> destination address selection. NAROS is a good approach to start
> solving this problem but there is more work to be done there, IMO.

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. 

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.

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

> 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.

-- Christian Huitema

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 25 May 2003 18:19:58 +0200

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

>> talking about when you say "multi-adressing"?

> 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).

> 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.

> of which being the interaction between multi-addressing and ingress

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.

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

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