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

[Tony Hain]

Being the person that did the needs based evaluations for the DoE related
allocations prior to the RIR formation, your fuzzy description is simply
wrong. Routers of the day had tiny memories compared to current devices, and
fitting the routing table was a strong consideration. The classful nature of
allocation units didn't leave much room for negotiation. When someone needed
more than a handful of /24's, it was better to give them a /16 than to blow
the routing system. 

Please don't propagate myths ...

Tony


> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of William Herrin
> Sent: Sunday, December 13, 2009 7:38 PM
> To: David Farmer
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation
> Process - revised
> 
> 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
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.