[ppml] Policy Proposal 2006-4: IPv6 Direct PI Assignments forEnd Sites - revised text
Thus spake <Michael.Dillon at btradianz.com>
>> I don't think the IAB (or IETF) is the right group to ask; with all due
>> respect to the v6 architects, decade-old misguided intent is irrelevant.
> On the contrary. The original IPv6 architects must have considered
> many possibilities and discarded them for a reason, settling on
> the idea of a /48 per end-site for a reason. Since their wording
> is unclear, it would help to understand the surrounding discussion
> in order to make sense of it.
Those architects are the ones that banned PI space in IPv6, forcing all "end
sites" into a PA model where the definition is largely irrelevant. The very
existence of this proposal signifies we are rejecting the IETF's plan. At
most, their reasoning at the time is of historical interest.
>> I think it'd be more instructive to see how ARIN itself has been
>> interpreting the term to date, for both IPv4 and IPv6. If there's
>> consensus that they're wrong, we can clarify the policy.
> 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, and
have been doing so since before ARIN was even formed. ARIN is also charged
with reviewing every IPv6 end-site assignment by LIRs that exceeds /48.
>> I'd propose that a single network with private connectivity between
>> locations should count as a single "site".
> I would agree. This is a network architectural choice and
> if the organization chooses this architecture then they
> would get one /48. In that case, if they wish to receive
> a PI allocation then it should be a single /48 to be consistent
> with their architecture.
That wasn't clear from your earlier messages. At least we agree on
>> Consider that if such an org were to get PA space from one or
>> more LIRs, they would get _at most_ one prefix per connection.
>> They would not get a /48 per internal location. Why should PI
>> policy be different?
> If their architecture was to have several connections, whether it
> was one per physical location or one per regional headquarters,
> the fact remains, that they have the right to choose their
> network architecture. If that choice is to get 57 Internet
> connections with 57 PA /48s, then they should get a PI
> allocation with enough space to maintain that architecture.
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
If those 57 locations all have both direct public and private connectivity,
I don't see why it's essential to assign 57 separate PI blocks. If they can
justify it, maybe, but you're assuming need without even asking or setting a
> On the other hand, if their architecture is based around
> 3 connections to regional headquarters which then use private
> networks to the rest of the offices, then that would result
> in 3 /48's, whether PA or PI.
I disagree that they should get three PI /48s (or one PI /46) just because
they could have gotten three PA /48s. If they can justify the space, fine,
but it shouldn't be automatic.
I'm not even proposing the standards for justification need to be all that
high -- only that we have some. One prefix per ASN seems to be a reasonable
>> Also, is there a compelling reason for IPv6 policy to be different in
>> this respect from IPv4 policy?
> To release organisations from the scarcity-based constraints
> of IPv6.
I don't consider that compelling unless there are tangible benefits to the
If a location isn't an end-site in IPv4 land, why should it be in IPv6 land?
Consider that the IPv4 rules for PI assignment are pretty lax as it stands,
and this proposal (even as I interpret the term "end site") is comparable.
>> If the M&A targets are sufficiently independent to have their own
>> ASN and own private network, I'd agree with that statement -- but at
>> that point, they should qualify as a separate org for the purpose of
>> PI policy and could get their own /48 (or more). No renumbering
>> either way. Giving each location a /48 burns lots of routing slots
>> for little real benefit.
> A /48 does not equal a routing slot. ARIN policy does not mandate all
> ISPs everywhere to accept a route announcement.
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 didn't
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 policy
ARIN IPv6 policy (6.3.4) specifically states it is a goal "to limit the
expansion of Internet routing tables." Compare to IPv4 policy (4.1.7) which
states goals of "conserving scarce IPv4 address space and allowing continued
use of existing Internet routing technologies." These goals seem to have
very strong consensus around them, and any policy needs to be consistent
with those goals.
>> The fundamental problem with your model is it creates a situation
>> where, after a few years of M&A, large companies will be advertising
>> hundreds, if not thousands, of unaggregatable /48s per ASN. This
>> _will_ create routing table problems and lead to wholesale filtering
>> of PI space.
> That's why I think that PI space should be organized in such a way that
> it can be aggregated by geographical proximity. I define "geographical
> proximity" to mean "the nearest city over 100,000", however, it could
> also be done in a less finely-grained way similar to the way truck
> dispatchers have divided North America into about a dozen regions.
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 goal should be one PI prefix per ASN. Your model starts with
>> that on day one, but it will invariably get worse over time.
> You are getting your model and mine mixed together. I want to apply
> science to ARIN's PI allocation algorithm in order to avoid the
> worsening which you describe.
Until such regions are designed, exchanges are set up, financial issues are
resolved, and a non-trivial number of ISPs participate, the best we can do
is to assign addresses such that regional aggregation is _possible_. We
can't create policy today that _assumes_ such will come into existence.
IMHO, an explosion in PI routes would not cause regional aggregation to
happen; it would result in wholesale filtering. You apparently disagree.
Let's leave it at that.
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin