[arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process

[William Herrin]

On Wed, Nov 18, 2009 at 1:07 PM, George, Wes E [NTK]
<Wesley.E.George at sprint.com> wrote:
> [weg] yeah I think that gets to the right ballpark. You
> probably need to assume some percentages as to how
> much deaggregation will still be done as well as how
> much of it will be filtered by ISPs in the DFZ.
> I think you do need to try to capture some scenarios that
> assume some percentage of PI /48s displacing what
> would otherwise be aggregated PD /48s.

Hi Wes,

Let's see what can be done.

[QUESTION FOR THE AC]

I vaguely recall that ARIN offers its registration data set to
researchers trying to do academic analysis about change in the
Internet over time. Do I remember right? Can you point me in the right
direction for what it would take to get a hold of an archive of IPv4
registration data for the purpose of simulating the action of proposal
103 versus the existing IPv6 policy?


> [weg] it's sort of moot what is in my budget. I was
> simply saying that this seems to be quite a lot
> outside of the current fee structure, and fairly
> arbitrary - a simple order of magnitude increase
> as we go up the scale, and I can't exactly see why,

Well, to be frank it *is* fairly arbitrary. It's also just a suggestion.

ARIN has a body whose job is to take all the issues that impact fees
into consideration and then set the fee structure. It's name escapes
me right now, but the point is: those are the folks who will set the
actual fee structure.

My implementation notes are only intended to illustrate the general
kind of demand that the policy places on the fee structure in order
for the policy to work sensibly, since 103's needs are very different
from the needs created by the prior policy.


> [weg] Then what's the point in having /56 as
> an allocation at all, and especially at that
> price point?

There are two subtle yet very important things that the /56 allocation does:

1. It creates an allocation that's effectively PI for all. ISPs *will*
decide not to carry it.

As long as ISPs try to stretch to carry every prefix ARIN allocates,
they'll remain caught in the cost spiral from the constant tug-of-war
between folks who want ARIN to do cheap PI and vendors who expect them
to ante up for bigger TCAMs. I don't want that. I want to see them get
together at NANOG and impanel a committee to study the classifications
and issue a recommendation as to which classes should be carried in
members' DFZ routers. That committee isn't politically possible while
the ISPs are still trying to stretch to carry every ARIN allocation.

2. It creates a void where there's demand, no supply but plenty of
opportunity. We have technologies on the drawing board like LISP and
TRRP ( http://bill.herrin.us/network/trrp.html ) that could, in
theory, create a secondary routing level that acts scalabily without
consuming DFZ slots. But there's no demand to drive the development
and deployment of those technologies because they're only one piece of
the puzzle and the other pieces are also missing.


> [weg] I don't view expanding an existing
> network to match the standardized (and
> only available) netmasks as in any way
> unfair to new entrants.

Oh! You mean expand the legacy prefix lengths to the closest thing to
a uniform length possible rather than let them just sit there, but
restrain the fees until the registrant next asks for more addresses.
That way the two legacy pools may become filterable too and the
reserved address space isn't lost. That's a right good idea.

Would you object to seeing it as a follow-on or parallel proposal
rather than part of the initial proposal? There may be complications
lying in the details of how ARIN has allocated addresses in the legacy
pool. I'd rather those complications not bog down 103.

Regards,
Bill Herrin



-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004