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

[William Herrin]

On Fri, Dec 11, 2009 at 9:23 PM, David Farmer <farmer at umn.edu> wrote:
> - Needs Basis
>
> First and probably most important from my personal point of view, I don't
> see a needs basis in this policy, even in the classful IPv4 days you had to
> demonstrate need to get a Class B, or Class A

Hi David,

If I recollect my history right (and I wasn't involved before '92 so
some of this is going to be fuzzy) nothing approaching a formal needs
based evaluation came in to play prior to the early '90's. Basically,
the guys who were involved when IPv4 was first deployed got class A's.
After that, the gentleman (just one) in charge of keeping the address
allocation list had something of a "convince me you need a class A and
by the way, you don't" policy but he gave out B's and C's for the
asking.

As the Internet got bigger and Network Solutions took over address
allocation under contract to the USG, allocation of class B's got
tightened up. There was an actual form (instead of an informal "I need
a class B" email) and if you were requesting more than a class C you
had to write a paragraph or two explaining why. I don't know if there
was a formal rule but the informal rule was that if you were a college
or government entity of any size, or a well known company, a B was
yours for the asking. "We are the United States Bureau of the Office"
justified as many class B's as you cared to ask for.

C's were still the reward for merely submitted a filled-out form, no
justification required. Indeed, the "official" policy was we wanted
anybody building a TCP/IP network to come and get as many addresses as
they thought they needed so that there wouldn't be any grief later
when they decided to connect their TCP/IP network with the Internet.

That's when I personally became involved, fetching a C at the start of
'94 and adding an adjacent C just before Network Solutions handed off
IP allocation to ARIN. And I can tell you for certain: the only
justification anybody ever asked for was "do you intend to use
TCP/IP?"

Class-C giveaways finally started to close down as the RIRs came into
existence in the mid-90's and ended with ARN's creation around about
'97.

The point of my ramble is this: needs-based justification wasn't
always around. It's something we invented ad-hoc halfway through the
game to address the disaggregation and over-consumption problems. As
entrenched as it now is in formal policy, "needs-based allocation" is
an underlying assumption we never really thought through all the way
from the beginning.


> - This could encourage the Big Guys to filter the little guys, by maybe
> making it to easy for them to do so.
>
> - As a result, this could encourage the smaller guys to try to get bigger
> blocks than they really need in order to justify having a routing slot and
> not being filtered.
>
> Think this threw a little, by making filtering this easy based on size, if
> there isn't some kind of needs based justification, and there is a pricing
> scheme like described then wouldn't we end up with something like you need
> to pay for a /32 for anyone to accept your route as a serious player.  If
> you can't afford $10,000 they go away you have to be my customer.

This is no accident. There are multihomed organizations now who can't
get usable (i.e. multihomed routable) IPv6 assignment. They have maybe
50 very valuable machines online and half a dozen Internet
connections.
They need multihoming reliability and $10k/year is nothing and
$100k/year is a stretch but doable if it gets them the reliability.

Currency is a universal metric. Acting independently, each one of us
can equate the worth of behaviors into dollars and back. ISP's can
convert the value of accepting routes into dollars. Users can convert
the value of multihoming into dollars. It's a mental meeting point
that intentionally lacks technical preconditions and as importantly:
avoids technical preconceptions.

A needs based metric like "200 end-user sites" is comparably
_arbitrary_. In strictly traditional scenarios (ISP serving dialups
and DSLs) it roughly equates with value but the moment you start
talking about server farms instead, the value equation is badly
skewed. And it leaves no practical way to value creative, innovative
systems which need to consume IP addresses or a routing slot.



> - Mergers and Acquisitions
>
> Getting people to properly report mergers and acquisitions seems hard enough
> now.  Requiring the single block per size per organization, and therefore
> renumbering, seems like an additional disincentive to proper reporting.
>  Leading to more bad registry data, less transparency to what is really
> going on, and possibly degrading operational response.

To my way of thinking, this is adequately handled by ARIN's fraud
reporting process. You find an AS announcing multiple same-size
registrations and they appear to all be a part of that org's unified
internal infrastructure, you report them and ARNI audits. Call it a
question of mind over matter: if nobody minds, it doesn't matter.

On the other hand, I've been thinking about this and maybe there's a
better way to handle it. Allow a registration to be declared "in
transition." Once it's in transition, there are no rules against
comingling the acquired registrations within your network. But,
declaring a registration "in transition" means you're going to
renumber out of it. The declaration starts a 24-month countdown clock
after which ARIN reclaims the registration no matter what and holds it
unregistered for a sufficient period of time to guarantee that it's
off the Internet.

Of course, you don't have to go that route. You can also keep the
acquired network at arms length, don't fold it in to the rest of your
network and keep the acquired legal entity for the purpose of holding
the registration and its network resources. The proposed policy does
not obstruct such behavior. This is one of the intentional release
valves that puts pressure on folks to aggregate but doesn't stand in
the way of business where the value involved is high enough.



> - 6.10.1 Micro-allocations for Critical Infrastructure are not moot and
> should be preserved, this allows network operators to create special
> filtering rule, if they wish, for these Critical Infrastructures.

In all honesty I disagree.

On the other hand, maintaining part or all of section 6.10 in parallel
with proposal 103 has no down sides that jump out at me. If there's a
desire to keep it around until the passage of time proves the issue
one way or another, I have no objections.



> - These changes are very radical.  It is at least very difficult, if not
> impossible, to predict what the real outcome of these policy changes will
> be.

I have requested and received access to the bulk whois data from ARIN.
Assuming 103 is accepted for formal discussion and debate, I intend to
build a simulation using this past data to try to give us a glimpse
into the future of both allocation under 103 and under current IPv6
policy as well as an estimate of the impact on the routing table. It
won't be perfect but it's at least a few shades better than
impossible.

Also, let's be honest with ourselves: we face a similar difficulty
predicting the outcome of IPv6 policy as it exists today. The devil's
in the details and current IPv6 policy is enough different from IPv4
policy that the results of the IPv4 allocation process do not offer a
reliable guide.


> Are there some incremental steps we can take toward this vision,
> without jumping off the cliff into a brave but unknown new world?

We could run it in parallel with the current process and let the ISPs
decide which one they like better via their filtering policies, but
that could create more chaos in a time when we want less.

We could restrict the top end of the range with a needs analysis but
unless there's at least one level of allocation that we're confident
the ISPs won't filter before that kicks in, it would trash the whole
function of proposal 103 -- ARIN would once again be the routing table
gatekeeper. Besides: if someone wants to pay $100k *per year* for a
/24, what's the problem exactly?

Other than that, the answer is likely "no."  If you accept 103's
rationale then the core premise behind today's IPv6 allocation policy
is dysfunctional: needs-based justification makes ARIN the gatekeeper
to Internet routing policy when it shouldn't be. Like in Millinocket,
"you can't get there from here." In order to move forward, we'll first
have to identify and back out the practices derived from error. That's
what I've attempted with proposal 103.



> In the Internet2 world we assigned GigaPOPs /40s out of the Internet2 /32,
> it worked well. Especially, in the early day of IPv6, when people still
> believed in tighter providers based aggregation for IPv6.  Think of GigaPOPs
> as regional cooperative providers aggregating end-sites into the national
> member owned Internet2 backbone.
>
> This isn't so radical, and if the rest of the world doesn't follow it still
> might be a good idea anyway.

Not only is that an exceptionally radical suggestion, it was solidly
opposed by the participants IRTF Routing Research Group when Heiner
Hummel suggested it. You can find a relatively informative iteration
of the discussion starting at
http://www.ops.ietf.org/lists/rrg/2008/msg01781.html .

The problem is the "international member-owned backbone." There can
only be one because as soon as you aggregate the traffic into gigapops
you lose control over how the packets transit the backbone.  During
the discussion it was demonstrated that such "geographic aggregation"
radically disrupts the economic underpinnings of today's Internet.
With geographic aggregation and more than one backbone, theft of
service anomalies are unavoidable.

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