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

[Owen DeLong]

On Dec 13, 2009, at 7:38 PM, William Herrin wrote:

> 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.
>
No... That was not the case.

Even back that far (I've been involved since ~1986), A's were given to
large(ish) organizations, not just anyone.  There was a time when a C
was the minimum allocation unit, and, you could get a C essentially
for the asking, but, you always had to have at least some level of
justification if you wanted a B or an A. Yes, the bar was raised over
time on what that justification was, but, there has always been some
level of needs-based.

> 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.
>
That does not match my recollection, but, I think it has become a
popular mythology.  Prior to NSI taking over from SRI, SRI pretty
much issued on the basis of trusting what was submitted without
much verification. NSI tightened that up a bit, and later as they
were preparing to split the address management out of domain
management, policy started to get even tighter and more formalized.
The formation of ARIN marked a major step forward in policy
formulation, and, that process has continued to evolve into what
we have today.

> 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 remained mostly true up to the point where CIDR started becoming
a concern, at which point, policy was tightened up not because of  
address
shortage (which started being an issue just a little later), but,  
because of
AGS/AGS+ memory limitations.

> 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?"
>
Sure... That was the policy for getting a minimum allocation back then,
but, you always needed more than that to get something more than
a minimum sized allocation. (True, there was little verification of
multiple applications for minimum sized allocations, but, that was
largely an oversight due to the fact that at the time, most people
couldn' t really see value in asking for more than you needed).

> 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.
>
Not entirely accurate.  The class-C giveaway was actually terminated on
the altar of CIDR which was purely coincidental in time with the  
formation
of the first RIRs and the transition away from SRI/NSI/SAIC.

> 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.
>
Yes it was.  To get a minimum allocation, you had to show that you  
needed
some IP addresses.  To get more, you needed to show that you needed
more, or, you had to submit multiple applications showing that you  
needed
some. Whether or not there was effective enforcement of needs-based,
the social contract was always needs-based. Prior to 1990, the internet
was a much friendlier more trusting environment.
>
> 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.
>
Um, why can't they get a routable assignment?  All such an organization
would need in order to get a PI /48 from ARIN is apply and pay the one- 
time
fee and $100/year thereafter.  You can convince me that my ARIN-assigned
IPv6 /48 isn't routable when I start having trouble reaching IPv6  
content I
care about.  So far, that hasn't been an issue.

> 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.
>
It also ignores the fact that merely thinking something is worth X  
does not
necessarily mean that you can afford to pay X for it because someone  
else
arbitrarily decided that you should.

> 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.
>
Agreed.  We need a better needs-based metric.  Money is not a good
needs-based metric, it is a good greeds-based metric.

> 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.
>
Or, more likely, this simply creates an impetus not to actually merge
the entities and continue to operate them as separate business
units under common ownership.  Thus, no fraud.  I don't understand
how the community benefits from address policy being used to dictate
business models in this manner, however.  This policy approach will
not reduce the size of the routing table, it will merely create
administrative hoops to jump through in structuring the merger to
keep the resources separate in the eyes of the policy.
>
> 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.
>
I don't see how it puts pressure to do anything other than work around
the system.

>> 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.
>
This approach to testing radical reform was tested in California in the
form of electrical deregulation.  Suffice it to say that consumers  
preferred
regulated prices based on the savings promised by the energy producers,
and, the energy producers, led by Enron preferred the spot market.
The result was that the delivery utilities were caught in a squeeze
between regulated (low) sell prices to consumers and unregulated
(high) purchase prices from energy producers who have been shown
to be more than willing to commit whatever felony was necessary
to maximize arbitrage opportunities.

I strongly suggest that we not do this to IP addressing, as I live in
California and can assure you that electric rates and the economy
of the state in general are still hurting from that "test".

> 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?
>
But someone who gets that /24 as an assignment doesn't pay $100k/year.
They pay $100/year, just like someone who gets a /32 or a /48 assigment.

> 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.
>
Respectfully, I disagree.  I think that needs-based is functional  
without
regard to internet routing table gatekeeping being a function of ARIN.
Verizon is, at this very moment, proving that needs-based /48s being
issued to people does not prevent a provider from filtering them.

>
>
>> 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 IETF also solidly opposed the idea of PI IPv6 at all.  The IETF is  
not
the canonical source for good operational practice and addressing  
policy.

Further, I don't think David was suggesting that GigaPOPs be the model
for traffic distribution, so much as suggesting an alternative address
allocation strategy which was, in part, predicated on an understanding
of the term "GigaPOP".

Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20091214/e76bcd06/attachment.htm>