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

Re: "architectural change" [RE: Draft: PI addressing derived from ASnumbers]



OK, maybe we need IPv6++ (although as Christian's message points 
out, the changes mainly wouldn't be in IPv6 itself).

But that is R&D, and it will be some years before it ships in product. 
Over here, can we get on with something shorter term? What is an I6SP 
supposed to say to a customer who asks for IPv6 multihoming next week?

    Brian

Pekka Savola wrote:
> 
> On Sat, 1 Feb 2003, Randy Bush wrote:
> > > In the long term, i'm rather convinced that an architectural change will
> > > be required.  I can't see other scalable alternatives.
> >
> > this is also what i see, though i am anxiously awaiting enlightenment.
> 
> Perhaps it was not clear what I meant with an "architectural change", and
> I should try to clarify.
> 
> I didn't mean we need IPv7; rather, that the model of solving a problem of
> locator/identifier problem and dumb end-hosts with a global routing
> solution.
> 
> For example, I consider models where multihomed hosts make a much more
> active role in the current "multihoming routing" problem an architectural
> change, as well as separating identifiers and locators as in LIN6 (or even
> more so, HIP), etc. as architectural changes.
> 
> Certainly, there are ways to do multihoming with IPv6 today.  And there
> will be ways.  But one point many, myself included, have tried to make is
> that doing it the way most have done it with IPv4 -- that is using BGP
> with "PI addresses" -- is not scalable.  That is likely the only solution
> for a long time to satisfy all those requirements.
> 
> For example, I personally have great faith in "multiple addresses from
> multiple providers" -approach (though there are some small ways it will
> have to be improved): it should give a sufficient amount of multihoming to
> most sites.  Also, multiple connections to a single ISP are also a way to
> get redundancy.
> 
> The major things I see missing are:
>  - ways to get upstream _independence_
>  - scalable ways to protect against your upstream ISP failures (if
> multiple addresses per node approach is not sufficient)
> 
> .. but I'm not sure whether solutions for these are really even required:
> people just want them because they've always had them.
> 
> --
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings