[ppml] Policy Proposal 2006-4: IPv6 Direct PI Assignments forEnd Sites - revised text
> Those architects are the ones that banned PI space in IPv6, forcing all
> sites" into a PA model where the definition is largely irrelevant. The
> existence of this proposal signifies we are rejecting the IETF's plan.
> most, their reasoning at the time is of historical interest.
Yes, those architects strayed from network architecture into
political and economic engineering when they assumed that the
provider-centric addressing scheme would be the only supported
way of building IPv6 networks. However, they did reserve 7/8ths
of the IPv6 address space for alternatives so it's not as
bad as it sounds.
There is a saying that those who do not learn from history
are doomed to repeat it. I think it is very important for all
of us to be aware of what went before, not just the final outcome
but some of the discussion surrounding it as well.
> > Unfortunately, ARIN does not monitor ISP assignment activity
> > and the only time they would audit or review assignments is
> > when an ISP asks for additional addresses. This means that
> > ARIN has no experience whatsoever with interpreting the meaning
> > of end-sites. That has been done by the ISPs themselves.
> Not true. End sites can get IPv4 assignments under existing policy,
Well, we are talking about IPv6 here...
> That wasn't clear from your earlier messages. At least we agree on
My position is that an organization must be free to
choose its own network architecture and that the PI
policy should not require an organization to change
the network architecture that they created with PA
addresses. Under the PA rules, an organization can
get a /48 per end-site, i.e. per location where they
subscribe to an ISP service. PI policy should be flexible
enough to allow this same scenario.
> In theory, if they have a separate connection at each location with no
> internal connectivity, each location would a be a separate end-site and
> would have to qualify for PI space independently. Folks using such an
> architecture overwhelmingly single-home all but the most important
> locations, however.
Organizations apply for ASes and address blocks.
End-sites and subnets do not fill in ARIN applications.
> If those 57 locations all have both direct public and private
> I don't see why it's essential to assign 57 separate PI blocks. If they
> justify it, maybe, but you're assuming need without even asking or
> minimum bar.
I'm saying that the architecture is justification in
and of itself. I'm saying that PI policy should not be
any more restrictive than PA policy.
> I'm not even proposing the standards for justification need to be all
> high -- only that we have some. One prefix per ASN seems to be a
It is entirely unreasonable to force a network architecture
on an organization with multiple locations when we are giving
individuals and small organizations much more flexibility.
> > To release organisations from the scarcity-based constraints
> > of IPv6.
> I don't consider that compelling unless there are tangible benefits to
Tangible benefits? Well, I suppose that means money. If PI space
is desirable then more people will apply for it an pay ARIN's fees.
Is that good for the community?
In any case, I think this talk of community is nonsense left over
from the Internet of the 1980's. Some people seem to feel that by
calling the network provider INDUSTRY a community, that it justifies
all manner of restrictive cartel-like behavior. If there is a community
that we should be concerned with, it is society in toto, and that
community wants to have a resilient and reliable Internet infrastructure
with full market freedoms to choose and re-choose where they buy service.
The PI policy needs to meet the needs of this community even if it
does have the potential to DISRUPT the way the industry currently
In other words, DISRUPTION is good because it is all about loosening
the cartel-like constraints that were imposed because of the scarcity
of IPv4 addresses and the lack of experience of policymakers 15 years
ago or so. We now have 15 years of more experience, we have a huge
supply of IPv6 addresses and we can correct the mistakes of the
past. This means that the provider community loses a little through
disruption but they stand to gain as well through continued growth
for their businesses. But not under the old lock-in model.
ARIN could easily issue IPv6 PI blocks from reserved blocks which
are designed to be aggregated by the geographical topology. Ideally
they would have separate aggregates for each city over 100,000
population but it could be done on a regional scale as well and
still provide benefits to scaling of the routing table. Of course
it does mean that providers who sell into that market of PI holders
need to do things a little differently with interconnects and
cold potato routing. But it requires no change to the technology
and protocols in use.
> If a location isn't an end-site in IPv4 land, why should it be in IPv6
Because IPv4 policy does not apply to IPv6 addressing. That is
why ARIN adopted an entirely separate IPv6 policy set. End-site
is an IPv6 concept with a sctrict definition. If you read the IPv4
policy you will see that it is used casually with two different
meanings. Let's not confuse the two policy sets.
> No, but the main point of giving out PI assignments is for use on the
> Internet, which today means a routing slot per assignment. If folks
> want global routing slots, they would use ULAs.
> The fewer blocks an RIR policy generates, the less likely the routes to
> those blocks are to be filtered, and consequently the more useful the
The fact is that we are not Soviet-style central planners.
We cannot mandate anything, merely create possibilities. No
matter what policy we adopt, there will always be elements
out of our control such as route filtering, customer adoption
and so on. That is not a reason to give up on making a good
policy that creates the possibility of a freer market for
network connectivity. Yes, the market could choose not to
accept this freedom or the industry could throw a spanner
into the works, but nevertheless, we have a duty to make the
best policy that we can.
> ARIN IPv6 policy (6.3.4) specifically states it is a goal "to limit the
> expansion of Internet routing tables."
Which is why many people have said that the PI policy needs
to allocate addresses out of an identifiable aggregate. This
gives providers an easy tool to limit expansion of their
routing table. Some of us have pointed out how using multiple
geographical aggregates could support both the limiting of
routing table growth as well as the need for companies to
multihome within a small geographic area, i.e. their city.
> That's an interesting model, but it's been discussed here and on NANOG
> several times with little forward motion. Policy needs to reflect the
> reality of what exists now. Ideally, it would not obstruct further
> development, but that is not the top priority.
The reality that exists right now is that ARIN's own
aggregation algorithm could be modified to enable this
type of geo-topological aggregation. Scott Leibrand's message
on PPML last month explains more about how it is workable
> Until such regions are designed, exchanges are set up, financial issues
> resolved, and a non-trivial number of ISPs participate, the best we can
> is to assign addresses such that regional aggregation is _possible_. We
> can't create policy today that _assumes_ such will come into existence.
We are not central planners who can mandate that everybody must spend
their money first and we will make our policy second. It is the other
way around. We make our policy and then the market reacts to them.
> IMHO, an explosion in PI routes would not cause regional aggregation to
> happen; it would result in wholesale filtering. You apparently
> Let's leave it at that.
Wholesale filtering is part and parcel of the regional aggregation
ISPs in California SHOULD filter all detail of PI routes in New York
they only need the single regional aggregate route to send traffic to any
PI end-site in New York. That is a fundamental component of this solution.