[arin-ppml] Policy Proposal: A Modest Proposal for an Alternate IPv6 Allocation Process

[Ted Mittelstaedt]

I have a comment/question on this..

It appears the central rationale for this policy assumes that most 
people are going to want to filter incoming BGP announcements, 
presumably because the BGP table is going to grow rapidly and they will 
otherwise run out of ram in their routers.  Is this assumption realistic?

VISA and MasterCard corporation have devised systems that can handle
hundreds of millions of non-contiguous credit card numbers coming in for 
approvals, from every corner of the globe.  I therefore have an 
extremely difficult time believing that it is impossible to build a 
router that cannot handle, say, 10 or 20 million BGP routes.  I also 
have a difficult time believing that this cannot be done for the $50K to
$100K that Cisco and Juniper seem to think they can charge for a
fully-optioned BGP router.

Today I can walk into the discount store and by a brand new PC with 2GB 
of ram for under $350.  Yet, Cisco and Juniper are still including as
standard ram amounts, miserable, paltry amounts far smaller than that.

My gut feeling here is that the router vendors could EASILY and CHEAPLY
and QUICKLY greatly expand the capacity of their products IF demand 
called for it - thus removing the need for filtering.

Is this an accurate assessment?  Or is there really some reason that a
router cannot be built with more ram than a half gig?

Ted


Member Services wrote:
> ARIN received the following policy proposal and is posting it to the
> Public Policy Mailing List (PPML) in accordance with Policy Development
> Process.
> 
> This proposal is in the first stage of the Policy Development Process.
> ARIN staff will perform the Clarity and Understanding step. Staff does
> not evaluate the proposal at this time, their goal is to make sure that
> they understand the proposal and believe the community will as well.
> Staff will report their results to the ARIN Advisory Council (AC) within
> 10 days.
> 
> The AC will review the proposal at their next regularly scheduled
> meeting (if the period before the next regularly scheduled meeting is
> less than 10 days, then the period may be extended to the subsequent
> regularly scheduled meeting). The AC will decide how to utilize the
> proposal and announce the decision to the PPML.
> 
> In the meantime, the AC invites everyone to comment on the proposal on
> the PPML, particularly their support or non-support and the reasoning
> behind their opinion. Such participation contributes to a thorough
> vetting and provides important guidance to the AC in their deliberations.
> 
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
> 
> Mailing list subscription information can be found
> at:https://www.arin.net/mailing_lists/
> 
> Regards,
> 
> Member Services
> American Registry for Internet Numbers (ARIN)
> 
> 
> ## * ##
> 
> 
> 1. Policy Proposal Name: A Modest Proposal for an Alternate IPv6
> Allocation Process
> 
> 2. Proposal Originator: William Herrin
> 
> 3. Proposal Version: 1.0
> 
> 4. Date: 5 June 2009
> 
> 5. Proposal type: new
> 
> 6. Policy term: See 6.11.7 below.
> 
> 7. Policy statement:
> 
> Add section 6.11 as follows:
> 
> 6.11 Alternate IPv6 allocation process
> 
> Section 6.11 offers an alternative to the address assignment process
> laid out in sections 6.5 and 6.10. Except where explicitly mentioned,
> no elements of the process here are binding on the process in those
> sections and vice versa.
> 
> 6.11.1 ARIN pools used for allocation.
> 
> ARIN shall reserve 3 pools of IPv6 addresses for the purpose of
> address allocation under section 6.11.
> 
> The first pool shall be used solely for making /48 allocations. ARIN
> will make no larger or smaller allocations from this pool.
> 
> The second pool shall be used solely for making /32 allocations. ARIN
> will make no larger or smaller allocations from this pool.
> 
> The third pool shall be used solely for making /24 allocations. ARIN
> will make no larger or smaller allocations from this pool.
> 
> ARIN shall publish the locations of these pool such that folks
> operating routers in the Internet Default-Free Zone can filter route
> announcements based on these published sizes if they so choose.
> 
> 
> 6.11.2 Initial allocation
> 
> 6.11.2.1 Initial allocation criteria
> 
> To qualify for an initial allocation of IPv6 address space, an
> organization must:
> 
> a. Be multihomed in the ARIN region with at least two different
> Internet Service Providers, both of whom agree to propagate the
> organization's IPv6 prefix into the Internet Default-Free Zone.
> 
> b. Have already obtained an Autonomous System Number.
> 
> c. Do not already hold a /48 or shorter IPv6 allocation from ARIN
> under any current or prior policy.
> 
> d. If requesting a /32, hold at least a /18 of IPv4 addresses
> 
> e. If requesting a /32, have implemented either SWIP or RWHOIS for all
> IPv4 allocations /28 or shorter.
> 
> 6.11.2.2 Initial allocation size
> 
> If requested, a /32 from the pool reserved for assigning /32's.
> Otherwise a /48 from the pool reserved for assigning /48's.
> 
> 
> 6.11.3 Extra /32 allocation
> 
> Organizations which hold a /48 from ARIN are eligible for an
> additional /32 allocation from the pool reserved for /32 allocations
> if they:
> 
> a. Demonstrate that they continue to meet the qualifications for the
> /48 assignment.
> 
> b. Do not already hold a /32 or shorter allocation from ARIN under any
> current or prior policy.
> 
> c. Plan to provide IPv6 service such that they will run out of space
> in the /48 within one year of making the second application.
> 
> d. Have implemented either SWIP or RWHOIS for all downstream
> allocations shorter than /64.
> 
> e. Agree to return all ARIN allocations longer than /33 except for one
> /48 allocation to ARIN within one year of receiving the /32
> allocation. Although 6.11.2 permits only one /48 allocation to an
> organization (hence no need to return anything), they may hold more
> than one due to mergers, acquisitions, policy changes, etc. These
> extras must be removed from the DFZ BGP table and returned to ARIN
> once a /32 is assigned.
> 
> 
> 6.11.4 Extra /24 allocation
> 
> Organizations which hold a /32 from ARIN are eligible for an
> additional /24 allocation from the pool reserved for /24 allocations
> if they:
> 
> a. Demonstrate that they continue to meet the qualifications for the
> /32 assignment.
> 
> b. Do not already hold a /24 or shorter allocation from ARIN under any
> current or prior policy.
> 
> c. Plan to provide downstream IPv6 service with address space such
> that they will run out of space within the /32 within two years of
> making the third application.
> 
> d. Return all /33 or longer allocations to ARIN prior to making the
> /24 application.
> 
> e. Agree to return all allocations longer than /25 except for one /32
> allocation to ARIN within one year of receiving the /24 allocation.
> 
> 
> 6.11.5 Additional allocations
> 
> No additional allocation beyond the single /24 is contemplated for a
> single organization at this time. No known usage pattern could require
> more than a /24 of IPv6 address space without egregious waste.
> 
> 
> 6.11.6 Advice to multihomed users
> 
> ARIN advises multihomed end-users that section 6.11 has been
> intentionally crafted to enable folks operating routers in the
> Internet Default-Free Zone to filter out route announcements longer
> than /48 within the /48 pool, longer than /32 within the /32 pool and
> longer than /24 within the /24 pool. Accordingly, it is probable that
> addresses assigned by an ISP instead of by ARIN will only be usable
> with that one ISP.
> 
> 
> 6.11.7 Policy term and re-evaluation
> 
> Three years from policy implementation, ARIN staff and the ARIN
> advisory council shall separately review the efficacy of address
> allocations made under both section 6.11 and sections 6.5 plus 6.10.
> Each shall recommend to the ARIN Board of Trustees that either 6.11 or
> both 6.5 and 6.10 be struck from the NRPM. The board shall review the
> recommendations and either strike section 6.11, strike both sections
> 6.5 and 6.10, or take no action, retaining both policies.
> 
> 
> 
> 8. Rationale:
> 
> The IPv6 allocation policy under section 6.5 makes a number of
> unproven assumptions about how IPv6 will work.
> 
> Unproven: we can make a reasonable guess about how many IPv6 subnets
> an organization will need at the outset when they first request IP
> addresses. When in all of human history has this ever proven true of
> any resource?
> 
> Unproven: with sparse allocation, we can allow organizations to expand
> by just changing their subnet mask so that they don't have to announce
> additional routes into the DFZ. This claim is questionable. With
> sparse allocation, we either consume much larger blocks that what we
> assign (so why not just assign the larger block?) or else we don't
> consume them in which case the org either has to renumber to expand or
> he has to announce a second route. Worse, because routes of various
> sizes are all scattered inside the same address pool, its impractical
> to detect or filter out the traffic engineering routes.
> 
> Unproven: we can force organizations not to disaggregate for traffic
> engineering purposes. Neither any of our experience with IPv4 nor any
> of the research in the IRTF Routing Research Group suggests that this
> is even remotely practical so long as BGP or any similar system rules
> the roost.
> 
> Unproven: all non-ISPs can be reasonably expected to get their address
> space from ISPs instead of from ARIN. We can certainly operate that
> way, but it could prove deadly to the routing table. Any organization
> mutlihomed between two ISPs will need to announce that route via BGP,
> regardless of where they get the address space from. We have knobs and
> dials in the routers that let us easily filter disagregates from
> distant announcements, but we don't dare do so if there is a
> possibility that one of those disaggregates is a multihomed customer
> rather than traffic engineering.
> 
> Benefits of this proposal:
> 
> A. Efficient allocation of IP addresses. Orgs get what they need when
> they need it and not before without a great deal of guesswork trying
> to define that need.
> 
> B. Efficient utilization of BGP routing slots. Few multihomed orgs
> will ever announce more than two unfilterable routes.
> 
> C. Traffic engineering routes are trivially filterable. Any route
> longer than the published allocation size can be presumed to be
> traffic engineering, not a downstream multihomed customer, thus you
> can filter distant small routes with confidence and ease.
> 
> D. Fair. No need to define the difference between ISP and not ISP.
> Everybody plays by the same rules.
> 
> E. No complicated analysis for the first allocation. You're either
> multihomed or you're not. If you're multihomed, you qualify.
> 
> F. For those who can live within the /48 there are distinct
> advantages: no swip or rwhois reporting and the generic end-user
> annual fee instead of the ISP annual fee. Once you're up to a /32, you
> pay the ISP annual fee. As a result, ARIN doesn't have to scrutinize
> the /32 requests too closely either.
> 
> G. No disruption to the prior IPv6 allocation policy until this new
> one proves itself.
> 
> 
> FAQ
> 
> Q. Isn't this classful addressing all over again?
> 
> A. Yes, with a twist. Now you have to fully use a class C before you
> can get a class B and fully use a class B before you can get a class
> A. And by the way, there are potentially 16 million class A's, not a
> mere 200.
> 
> Classful addressing had a lot of virtues with respect to route
> filtering and management. We had to abandon it because there weren't
> enough B's for everyone who needed more than one C and there weren't
> enough A's period. With IPv6, we don't have that problem. Not yet and
> maybe not ever. Perhaps we can have our cake and eat it too.
> 
> 
> Q. Why prevent single-homed users from getting ARIN addresses?
> 
> A. Any IPv6 allocation from ARIN must be announced into the Internet
> DFZ via BGP in order to use it on the Internet. That costs a lot of
> money, more than $10k per year according to
> http://bill.herrin.us/network/bgpcost.html   Worse, it spends other
> people's money: no practical system exists for recovering the cost of
> a consumed routing slot from the folks who announced the route.
> 
> If you don't get an allocation from ARIN then you have to renumber in
> order to change ISPs. That can cost a lot of money too. Sometimes far
> more than $10k. But it spends only your money, not somebody else's.
> 
> Finally there's the technical consideration: regardless of who assigns
> the addresses, a multihomed system must announce a route into the DFZ.
> That's the way BGP works and we're stuck with it for at least another
> decade. So why not let the multihomed org get his IP addresses from
> ARIN? By contrast, a single-homed system works just fine with its
> addresses aggregated inside the shorter route announced by its ISP.
> 
> 
> Q. If it's so expensive to announce routes into the DFZ, why not use
> something better than BGP?
> 
> A. Last year the IRTF Routing Research Group compiled an exhaustive
> study attempting to identify the possible ways to improve the routing
> system. A draft of the results is at
> http://tools.ietf.org/html/draft-irtf-rrg-recommendation-02 . While
> there are many promising ideas for how to replace BGP with something
> that scales better, we're at least a decade away and probably more
> from any significant deployment of a BGP replacement.
> 
> 
> Q. Is it really true that multihoming requires announcing a route via BGP?
> 
> A. The short answer is yes, its true. The long answer is more complicated.
> 
> Folks have tried very hard to devise multi-vendor multihomed systems
> which don't rely on BGP. Some even work OK for networks containing no
> Internet servers.
> 
> The only non-BGP approach that has ever come close to success for a
> system that hosts Internet servers is dynamically changing DNS records
> to favor the currently working Internet connection. "Close" is a
> relative term here. Such network architectures are enormously complex
> and they don't work for a useful definition of "work." The DNS
> protocol itself supports quick changes but the applications which use
> it often don't. It takes hours to achieve two-nines recovery from an
> address change in the DNS and it takes months to achieve five-nines
> recovery. Web browsers, for example, don't immediately recover. Search
> google for "DNS Pinning."
> 
> 
> Q. Why allocate the /48's from a pool only for /48's, /32's from a /32
> pool, etc.? Why not allocate from just one pool?
> 
> A. If all assignments in a particular pool are /32 and all multihomed
> entities get their IP addresses directly from ARIN then any route in
> the /32 pool which is longer than /32 is a traffic engineering route.
> As a router operator you can filter and discard a traffic engineering
> routes if you find they give you insufficient benefit. The routes you
> filter don't cost you any money; only the routes you keep carry a
> price tag.
> 
> You can only filter if you're sure they're traffic engineering
> routes... If they're downstream customer routes and you filter them,
> there goes the Internet. Or at least there goes your part of it. See
> customers. See customers run... straight to your competitor. Setting
> up the distinct pools makes it practical to know for certain that the
> routes you're filtering are only for TE.
> 
> 
> Q. Why make folks return all but one /48 to get a /32 and all but one
> /32 to get a /24?
> 
> A. Without the address scarcity issue which drives IPv4 policy, the
> primary criteria for IPv6 addressing policy is suppressing the route
> count in the IPv6 DFZ. Such a criteria is not well served if an
> organization holds dozens of discontiguous address spaces as a result
> of acquisitions, mergers and the like. With the return policy in
> place, organizations will generally only announce one or two primary
> routes, routes necessary for the correct operation of the Internet.
> Any other announced routes will be for traffic engineering. Because of
> the segregated pools from which the allocations come, those traffic
> engineering routes can be filtered by anyone who gains insufficient
> advantage from them without harming the Internet as a whole.
> 
> The return policy does require some renumbering activity. However,
> with only modest planning on the registrant's part, the policy is
> flexible enough to allow that renumbering to occur over a long period
> of time so that both cost and disruption are minimized. In many cases,
> customer churn can be expected to take care of much of the renumbering
> activity all by itself.
> 
> 
> Q. What if the first allocation from the /48 is a /48?
> 
> A. RFC 3177 recommends that downstream customers receive a /48
> assignment by default. Obviously there's a mismatch here if the ARIN
> allocation is also a /48.
> 
> The short version is that RFC 3177 is not the gospel truth. It's based
> on the IPv6 allocation model embodied in ARIN policy section 6.5 where
> we try very hard to assign all the addresses you'll ever need up front
> so that you only ever use one routing slot. This proposal attempts to
> slow-start IPv6 allocations instead, while still maintaining the
> principle of suppressing the routing table size. With a /48 allocation
> under this proposal, consider implementing a slow start for your
> downstream customers as well: Give them a /60 initially, add a /56
> when they need it and add a /52 when they run out of the /56. There
> are 16 /52's in your /48, or 4000 /60's. Plenty to get started. And a
> /60 is 16 /64 subnets. That's an internal LAN, a DMZ and 14 more
> subnets.
> 
> 
> Q. What happens when organizations merge or split?
> 
> A. Entities which merge will want to renumber out of and return one of
> the allocations so that they don't run into grief when they go to get
> the next larger allocation from ARIN. If done gradually, this should
> be a minor hardship.
> 
> Entities which split have a bigger problem since only one of them can
> keep the addresses. To a large extent, that problem already exists and
> is a pain in the rump for IPv4 operations today. This policy doesn't
> solve it but it doesn't make it a whole lot worse either. Because
> disaggregates are expected to be filtered, this IPv6 policy does gives
> us a slightly better guarantee that the rest of us won't get stuck
> with the check (in the form of routing slot consumption) when an ISP
> goes bankrupt and gets split up.
> 
> 
> Q. Why allow folks announcing IPv4 /18's to jump straight to a /32?
> 
> A. We're not really starting from scratch here and there are plenty of
> IPv6 addresses. Why make extra useless work for large ISPs who -are-
> going to use more than a /48? There are far fewer than 30k orgs
> holding /18s. How much grief should we cause them in order to save at
> most one whole /25?
> 
> 
> Q. Why not just replace section 6.5 instead of running this allocation
> system in parallel?
> 
> A. The most experienced user of IPv6 still has only a fraction of the
> experience that we have with IPv4. Yet the network operating model
> proposed by the IETF is radically different than the IPv4 model. The
> author believes that the IETF recommendation is based on an errant
> operating model, but he respects those who believe otherwise. The
> author also believes that competition is a good thing and history
> backs up this claim. Since little long term harm can come from briefly
> running both systems in parallel, allowing them to compete directly
> will result in the selection of the superior system.
> 
> 
> Q. You've covered multihomed and single-homed. What about IPv6
> addresses for uses which will not be connected to the Internet at all?
> 
> A. "ULA Central" or an idea like it is not addressed in this policy
> proposal. If desired, it should probably be implemented in a separate,
> parallel policy. The author observes that all of 2002:0a00::/24 is
> available for your offline use and there are plenty of others if you
> don't like that one.
> 
> 
> Implementation notes:
> 
> Initially, ARIN may want to use sparse allocation inside each of the
> three reserved pools until the policies are re-evaluated in three
> years. That way if section 6.11 is retired in favor of section 6.5,
> the 6.11 assignments may be able to grow by changing the netmask as
> intended in section 6.5. If 6.11 is retained, sparse allocation should
> cease.
> 
> Because IPv6 addresses are plentiful and the largest possible
> allocation under this policy is /24, the author recommends against
> explicit criteria for efficiency at this time. Instead, ARIN should
> consider selecting a fee schedule for /48, /32 and /24 allocations
> which discourages asking for more addresses than are really needed.
> Something along the lines of $100, $10k and $100k per year
> respectively might do nicely.
> 
> Under this proposal there is no difference whatsoever between an
> allocation and an assignment. The two words should be treated as
> synonyms.
> 
> 
> 9. Timetable for implementation: immediate; re-evaluate in 3 years
> 
> 
> _______________________________________________
> 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.