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

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



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