[ppml] Policy Proposal 2006-4: IPv6 Direct PI Assignments forEnd Sites - revised text

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

> 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.

Now, in the RIPE region it may be different because RIPE
does directly involve themselves in ISP assignment activity
until they are assured that the ISP can do it in conformance
with RIPE policy. On the other hand, RIPE is free to tinker
with their IPv6 policy to make it different from ARINs. I don't 
know how much this has been done.

> 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.

> 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.
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.

The point is that an organization should have freedom to make
their network architecture decisions independent of ARIN policy
constraints. IPv6 is about releasing people from constraints.

> 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.

> 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. 

> 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.

> 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.

--Michael Dillon