Re: Notes about identifier - locator separator

[Erik Nordmark <Erik.Nordmark@sun.com>]

> The idea is that an external box could handle this so a non-multihoming
> aware host can enjoy being multihomed. And are you suggesting we should
> carry all addresses in all packets? That would be a huge waste of
> bandwidth. Not something IPv6 really needs as it is borderline in this
> area as it is.

I'm not suggesting anything - I'm merely trying to promote getting a shared
understanding that includes applications, DNS, transports, hosts, routers,
enterprises, ISPs, and the DFZ. 

I haven't seen much discussion (but I'm still horribly behind on mail)
about what the issues are around applications as it relates to multihomed
sites.

> (There are also solutions where both the host and the border
> routers/external boxes must be changed, though.)

And there are probably also solutions where every multi(>2)-party application
must be modified.

> It is also possible to use some new way to map identifiers to locators
> and not the DNS.

But that doesn't change the fundamental danger of having a single
packet (whether it is a TCP SYN or a packet that needs be get an ICMP
error sent back) resulting in significant work such as doing a lookup
in some mapping service.

> > One additional issue on my list is to what extent one can ease deployment
> of > a new scheme by being able to derive some benefits when e.g. the local
> host > and the local border routers implement the new stuff, but the peer
> host > and peer border routers do not.
> 
> That means the routers have to solve the problem, as is done today. This
> works very well but there are scalability issues. Have a look at:

That doesn't follow AFAIK.

Combinations of host and border router functionality might very well be
able to provide partial benefits without requiring changes at the other end.
At least I see no fundamental reason why such combinations can not add
something interesting to the solution space.

  Erik