I think, but I'm not sure, that this assumes that we will have a scalable PI
scheme some time in the future (presumably by separating PI identifiers
from PA locators).
Actually, this is quite tricky...
If we _don't_ allocate PI addresses soon, enterprises will demand
IPv6 NAT to allow them to use provider-independent internal numbering.
This is the model that they use today, and they will probably continue
to use it unless a more compelling model (such as provider-independent
globally-routable addressing) is available.
But, if we do allocate PI addresses soon, we will need to do that without
any certainty that we can come up with a scalable PI routing scheme. So,
we may be creating a serious scaling problem further down the road. There
is no good way to predict when we would hit this scaling problem, as
that will depend on many factors including the rate of adoption of IPv6,
the number of PI addresses allocated/used, the rate of increase in the
speed/memory size of routers. But, I've been told by ISPs who lived
through the CIDR transition in IPv4 that this _really_ isn't something
that we want to repeat for IPv6.
If/when we do find a solution to the route scaling problem, there is no
real assurance that it will be backwards compatible with existing IPv6
address allocations. In fact, it may even require changes to the IPv6
protocol.
Some folks have argued that easy renumbering would eliminate the need
for enterprises to have provider-independent addressing, but I don't
agree. Addresses are stored in many places in the network besides
the interfaces of routers and hosts, such as access control lists,
configuration files, .hosts files, DNS configurations, ACL lists, etc.
In many cases, addresses are stored in nodes on other subnets. So,
being able to renumber the interfaces of hosts and routers on a
particular network or subnet doesn't even solve half of the problem.
So, what do we do?
Choices seem to be:
(A) Continue with PA addressing, and accept that enterprises will
use IPv6 NAT to get provider-independence.
(B) Allocate PI addresses, and trust that we can determine a
scalable PI routing scheme before we hit route scaling
issues in the IPv6 backbone.
NAT has huge costs, making the Internet more expensive and less efficient,
affecting the resiliency of networks, and limiting our ability to deploy
secure, innovative Internet applications and services. It does solve
the route scaling issues, but the cure may be worse than the disease.
We may be able to solve the route scaling issues in a less damaging way
later, but once folks start deploying IPv6 NAT on a large scale, we
will never be able to get rid of it.
So, I would make an informed decision to pursue choice (B), in full
knowledge that it might create a route scaling issue further down the road.
I'm not sure that we'll ever reach anything resembling "IETF consensus" on
that choice, though.
Margaret
At 06:08 AM 1/22/2003 +0100, Erik Nordmark wrote:
> I suspect we all agree that crushing the routing system would be bad .
> It seems like the question is what mechanism (other than ambiguity)
> would be sufficient to prevent that happening.
Assuming we have the "SHOULD NOT be routed globally" in the spec.
Then if the PI addresses come from a different space than the PA addresses
I think there is a way out.
When the routing gets strained ISPs can unilaterally decide to filter out
PI routes (or have a different prefix length filter for the PI space
than for the PA space).
ISPs are unlikely to do this for the PI routes their direct customers are
using, since it would upset their customers. But they should be able to do it
for the PI routes coming from elsewhere. And the ISPs could do this type of
filtering on the PI space from day one - "pay me money if you want me to
carry your PI route" - on an individual ISP basis.
Could this work?
I think, but I'm not sure, that this assumes that we will have a scalable PI
scheme some time in the future (presumably by separating PI identifiers
from PA locators).
Erik
--------------------------------------------------------------------
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 [EMAIL PROTECTED]
--------------------------------------------------------------------
--------------------------------------------------------------------
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 [EMAIL PROTECTED]
--------------------------------------------------------------------
