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

Re: Moving forward on Site-Local and Local Addressing

[no hats on]

>Then, we have a  'requirement' document that pretend to explain why we need
>'local' addresses. If you read it carefully, and as acknowledged by one of 
>its main
>author in Vienna, almost all of those requirements (if not all) would be 
>by provider independent addresses. Actually, there is nothing in it that
>explain why we need 'local range' addresses. The essence of those
>requirements is in the need for stable addresses that are
>independent from ISPs.

If this means non-globally routable provider independent addresses (e.g., 
<draft-hinden-ipv6-global-local-addr-02.txt> ), then I am in agreement that 
a solution doesn't have to be limited in scope (or range) like site-local 
addresses are.

If this means globally routable provider independent addresses.  Then it 
is, of course, correct that this would solve many of the problems 
too.  Unfortunately, there is a big problem why this isn't a practical 
choice we can make now.   We don't have, IMHO, any idea how to make 
globally routable provider independent addresses work at scale in the 
Internet.  There are a number of problem area.

We don't know how to route them at the scale of the current Internet.  The 
current routing technology we have now would have to treat each provider 
independent prefix as a separate route.  That would be one route per 
organization.  That is way too many routes to be handled by anything close 
to current technology and products.  It would be turning off aggregation.

If we had new routing technology that could handle globally routable 
provider independent addresses, then it would have to be deployed in most 
routers in the Internet before it would be useful.  Probably all routers 
from the site boundary to the core of the Internet.  Given that I suspect 
any solution in this area would not be an incremental changes to a routers 
implementation (i.e., not another BGP extension), perhaps even changes to 
the routers route lookup engines (in hardware in many cases) this would 
likely take a long time to accomplish.  Also, a bit of a chicken and egg 
deployment problem that everyone working on IPv6 understands too well.

We don't have any structure in place to allocate and register these types 
of addresses.  The registries might be able to do it, but as they are 
currently structured they are mostly focused on ISPs, not individual 
sites.  This would require some major changes in their structure and 
perhaps funding models. Right now every site would have to be an LIR.

Assuming routing technology was available and all of the routers were 
modified  to support the new routing technology, then there would have to 
be some incentive for the ISP to want to carry these type of routes.  They 
are great for the customers, but it makes it easy for their customers to 
switch ISPs.  We have seen how well the phone providers have embraced 
provider independent phone numbers.  They only "agreed" to support them 
after governmental action.  I suspect ISP might not be widely enthusiastic 
to deploy them.

So overall if we had all of these problems solved it would be 
great.  Beside just the local address problems, it would deal with site 
multihoming, site mobility, change of ISP, and more.  It's a great problem 
to work on as the benefits are many.  But I don't think we will see 
solutions to these problem in the near or medium terms.  I think the 
routing problem is a significant research topic that people have been 
working on for a long time.

Until solutions two these problems are available, I don't see this as a 
viable alternate to the current approaches.


IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com