No. But I fail to see what we gain with creating a special block from
where we assign PI addresses. The RIRs can equally well assign PI space
from the current IPv6 unicast space. Sure, this will lead to growth in the
size of the DFZ, but that is a routing problem.
I think we're arguing the same side here...
I'd like to see addresses available to enterprises (and home users, for
that matter) with the following properties:
1) globally unique
2) provider independent (AKA "portable")
3) globally routable
4) indistinguishable from provider-allocated addresses by
routers, applications, etc.
However, the concern that has been voiced by many in the IPv6 WG is that
property (3) cannot be provided in a scalable manner. This has led to a
belief that we can't have property (4), because ISPs will need to know
which prefix advertisements to accept, and which to block...
So let's give them PI space!!! We don't really need more abbreviations, we
have the address space so far, we are still far from hitting the roof of
the routing table in IPv6....
I don't care what we call it...
I read your draft on multi6 regarding "longer prefix" multihoming, and was
surprised to see your assertion regarding how far we are from having a
route scaling problem in IPv6...
But, do you really think that we will continue to have fairly small routing
tables if we allow every enterprise (and home?) to get its own portable
address allocation? Or would we need to come up with some way to
assign these addresses in an aggregable manner.
Are you proposing a particular mechanism that would allow aggregation of
PI address allocations?
I know that there is a geography-based PI allocation proposal in mutli6, but I
don't understand how they produce aggregation. There are multiple providers
in every city, and those providers networks may not be topologically
"close" to each other, even though they are geographically close.
This would solve the uniqueness problem and take away the NAT worries.
True, but it would cause IPv6 routing table growth... Do you have an
answer for that?
Margaret
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
