[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
>fulfilled
>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.
Bob
--------------------------------------------------------------------
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
--------------------------------------------------------------------