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

[Warren Johnson]

Instead of spending the next two decades trying to get people migrated over
maybe we should just scrap v6 and create "v7" and make it backwards
compatible with v4.  I guess we're not at that point yet because we just
don't know what's going to happen post-runout.



-----Original Message-----
From: Davis, Terry L [mailto:terry.l.davis at boeing.com] 
Sent: Monday, November 16, 2009 2:50 PM
To: 'Warren Johnson'; arin-ppml at arin.net
Subject: RE: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process

Warren

My answer would be "we didn't have enough software types in the room during
the discussions on creating v6" to point out the implications of that fact.

Although a long term v6 advocate, I did not fully realize what we had done
to ourselves till I did a Master's project paper on v6 migration a few years
ago.  After doing that, I realized that with current transition
technologies, we end up with an ugly v4-v6 transition layer consisting of
many different v4-v6 technologies (and some at the individual app level) in
our IT infrastructure architecture for probably decades.  And that layer
also has very severe implications for an IT security infrastructure.

If we had a simple straight forward transition mechanism, v6 would have
taken off years ago.  Hindsight is 20-20; foresight though isn't (maybe
20-2000).

Take care
Terry

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] 
> On Behalf Of Warren Johnson
> Sent: Monday, November 16, 2009 12:30 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation 
> Process
>
> Stupid question here: why wasn't v6 designed to be backwards 
> compatible with v4?  Just not possible?
>
>
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] 
> On Behalf Of Davis, Terry L
> Sent: Monday, November 16, 2009 2:03 PM
> To: 'Steve Bertrand'; arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation 
> Process
>
> Steve
>
> I like it also.  One of our biggest problems is that we simply do not 
> have enough really large scale IPv6 deployments around the globe to 
> begin to understand all the problems or to come up with better 
> migration/integration plans between v4 and v6.  This should spur more 
> use IPv6; as it is today, not even the green field startups are using 
> v6 and this should tell us something about our current assumptions and 
> policies.
>
> In retrospect, by not having a seamless, easy to use method, of 
> allowing
> v4
> to v6 communications, we have made deploying v6 very costly; migrating 
> our millions of v4 based apps to v6 comes with both a huge price tag 
> for opening and dual-stacking them and a corresponding "risk" factor 
> for business continuity associated with that work.
>
> Take care
> Terry
>
> > -----Original Message-----
> > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
> > On Behalf Of Steve Bertrand
> > Sent: Friday, November 13, 2009 8:20 PM
> > To: arin-ppml at arin.net
> > Subject: Re: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation 
> > Process
> >
> > Member Services wrote:
> >
> > > Policy Proposal 103: Change IPv6 Allocation Process
> >
> > I'm very, very interested in this proposal, and would like to give 
> > it a bump in hopes that it will spur more feedback and discussion 
> > than what it's received thus far.
> >
> > Truthfully, I would like to get a feel on the number of people who 
> > like it (I certainly do). If anyone has disregarded or overlooked 
> > the proposal because of the recommended financial figures, please 
> > let that be known as well.
> >
> > Complete original proposal message has been left intact below.
> >
> > Steve
> >
> >
> > > Proposal Originator: William Herrin
> > >
> > > Proposal Version: 1.0
> > >
> > > Date: 9 November 2009
> > >
> > > Proposal type: new
> > >
> > > Policy term: permanent.
> > >
> > > Policy statement:
> > >
> > > Strike NRPM sections: 6.2.3, 6.2.4, 6.2.6-6.2.9, 6.4.3, 6.4.4, 
> > > 6.5.1-6.5.5, 6.5.8, 6.7, 6.10
> > >
> > > Strike NRPM section 6.9 paragraph 2.
> > >
> > > Replace 6.2.5 as follows:
> > >
> > > 6.2.5 Allocate and Assign
> > >
> > > For the purposes of NRPM section 6, allocate and assign are 
> > > synonymous. Both terms describe any or all use identified in 
> > > section 2.5.
> > >
> > > Replace 6.5.7 with:
> > >
> > > 6.5.7. Existing IPv6 address space holders
> > >
> > > Organizations that received IPv6 allocations under the previous 
> > > IPv6 address policy are entitled to either retain those 
> > > allocations as is or trade them in for an allocation under 6.5.9.
> > >
> > > Add NRPM section 6.5.9 as follows:
> > >
> > > 6.5.9 IPv6 Allocations
> > >
> > > 6.5.9.1 ARIN shall allocate IPv6 address blocks in exactly and 
> > > only the following denominations: /56, /48, /40, /32, /24
> > >
> > > 6.5.9.2 No utilization-based eligibility requirements shall apply 
> > > to
> > > IPv6 allocations.
> > >
> > > 6.5.9.3 ARIN shall accept registration of no more than one address 
> > > block of each size for any single organization.
> > >
> > > 6.5.9.4 ARIN shall allocate IPv6 addresses from pools such that 
> > > the identity of the allocation pool serves to classify the 
> > > expected size of allocations within. ISPs may use that 
> > > classification to filter or otherwise manage their routing tables.
> > >
> > > 6.5.9.5 For each allocation size, ARIN shall further manage the 
> > > allocation pools such that the pool identity serves to classify 
> > > whether or not the registrant is Multihomed.
> > >
> > > 6.5.9.6 ARIN shall offer addresses from pools classified as 
> > > multihomed only to organizations which ARIN has verified are 
> > > multihomed on the public Internet per NRPM 2.7.
> > >
> > > 6.5.9.7 Where an organization ceases to be Multihomed it shall 
> > > surrender all address allocations from within pools classified as 
> > > multihomed within 3 months.
> > >
> > >
> > > Rationale:
> > >
> > > See the implementation notes section below for what should replace 
> > > utilization-based eligibility.
> > >
> > > The existing IPv6 allocation policy under section 6.5 makes a 
> > > number of unproven assumptions about how IPv6 allocations 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 
> > > space, its impractical to 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 multihomed 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 disaggregates 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 without a great deal of guesswork.
> > >
> > > B. Efficient utilization of BGP routing slots. No multihomed orgs 
> > > will announce more than five unfilterable routes, and that only if 
> > > they're so large that they can afford the price tag for the 
> > > biggest address blocks. That's a good thing since IPv6 routes that 
> > > propagate worldwide may impose an annual systemic overhead cost on 
> > > ISPs of as much as US $16,000 each.
> > >
> > > 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 allocation. You pay for what you 
> > > want and get what you pay for. You're either multihomed or you're not.
> > >
> > > F. Gets ARIN out of the business of being the gatekeeper for 
> > > Internet routing policy. By classifying allocations instead of 
> > > making eligibility decisions, ARIN empowers the ISPs to set 
> > > appropriate routing eligibility policies instead.
> > >
> > > FAQ
> > > Q. Isn't this classfull addressing all over again?
> > > A. Yes.
> > > 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. What if I don't want to accept /56 routes for single-homed users?
> > >
> > > A. This policy proposal intentionally and fully places backbone 
> > > routing policy in the hands of the ISPs who operate the Internet's 
> > > "Default-Free Zone (DFZ)," colloquially known as the Internet 
> > > backbone. The author expects that some of the allocations, 
> > > especially some of the single-homed allocations, *will not* be 
> > > routable on the public Internet. When we hold a general 
> > > expectation that all of ARIN's allocations will be routable, we 
> > > effectively mean that ARIN decides what the Internet routing 
> > > policy will be. That's precisely the role this proposal removes 
> > > from ARIN's hands and
> restores
> to the ISPs.
> > >
> > > Q. Spell it out for me. How exactly will pools and size 
> > > classifications enable route filtering?
> > >
> > > A. Suppose ARIN holds 4000::/12. ARIN might split it up as follows:
> > >
> > > 4000::/13 -- reserved
> > > 4008::/15 -- multihomed /24 allocations
> > > 400a::/15 -- non-multihomed /24 allocations
> > > 400c::/16 -- multihomed /32 allocations
> > > 400d::/16 -- non-multihomed /32 allocations
> > > 400e:0000::/18 -- multihomed /40 allocations
> > > 400e:4000::/18 -- non-multihomed /40 allocations
> > > 400e:8000::/24 -- multihomed /48 allocations
> > > 400e:8100::/24 -- non-multihomed /48 allocations
> > > 400e:8200::/24 -- multihomed /56 allocations
> > > 400e:8300::/24 -- non-multihomed /56 allocations
> > > 400e:8400::/22 -- reserved
> > > 400e:8800::/21 -- reserved
> > > 400e:9000::/20 -- reserved
> > > 400e:a000::/19 -- reserved
> > > 400e:c000::/18 -- reserved
> > > 400f::/16 -- reserved
> > >
> > > Now, you're an ISP. Here's a sample routing policy you might choose:
> > >
> > > Accept any routes to /32 because anyone paying $10k per year for 
> > > addresses is big enough to ride.
> > > For /24 allow 2 bits of traffic engineering too.
> > > Single-homers who won't spend $10k/year on their addresses 
> > > (smaller than /32) must use addresses from their ISP. Tough luck.
> > > Accept multihomers down to /48.
> > > The folks paying only $10/year for /56's aren't serious.
> > >
> > > Your route filter looks like this:
> > >
> > > accept 400e:8000::/24 equal 48
> > > accept 400e:0000::/18 equal 40
> > > accept 400c::/15 equal 32
> > > accept 4008::/14 le 26
> > > reject 4000::/12 le 128
> > >
> > > Note how 400e:8000::/24 contains only /48 allocations and you're 
> > > allowing only /48 announcements. Since there aren't any /47 or /46 
> > > allocations there, nobody in the pool can slip TE routes past you.
> > > On the other hand, you'll get some benefit of traffic engineering 
> > > from the super-massive /24 registrants up in 4008::/14 because 
> > > you're allowing them to disaggregate down to /26.
> > >
> > > Q. If its so expensive to announce routes into the DFZ, why not 
> > > use something better than BGP?
> > >
> > > A. In 2008 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. The long answer is more complicated.
> > >
> > > Folks have tried very hard to devise multi-vendor multihomed 
> > > systems which don't rely on BGP. The only approach that has ever 
> > > come near success is dynamically changing DNS records to favor the 
> > > currently working Internet connection. "Near" is a relative term 
> > > here. Such network architectures are enormously complex and they 
> > > don't work especially well. 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. So the Internet's resulting route policy will be to allow all 
> > > the sizes that no major ISP decides to filter and restrict the rest?
> > >
> > > A. That's one possible outcome. On the other hand, research in the 
> > > routing field suggests that with a sufficiently rich 
> > > classification scheme, it may be possible to implement lower 
> > > priority systems with provider-independent addresses yet without a 
> > > global route. Hints for how such a thing might work can be found 
> > > in http://www.cs.cornell.edu/people/francis/va-wp.pdf and 
> > > http://bill.herrin.us/network/trrp.html. Such schemes need a rich 
> > > classification process at the address allocation level that makes 
> > > it possible for ISPs to make reasonable and simple decisions about 
> > > which routes should be distributed to every DFZ router and which
> should
> not.
> > >
> > > Wouldn't that be something: IPv6 provider independent addresses 
> > > for everybody without materially increasing the cost of the 
> > > routing system.
> > >
> > > 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 then any route 
> > > in the /32 pool which is longer than /32 is a traffic engineering 
> > > (TE) route. As a router operator you can filter and discard TE 
> > > 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 TE routes... If they're 
> > > distinct 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 with certainty whether 
> > > the routes you're filtering are only for TE.
> > >
> > > Q. Why allow only one allocation of each particular size?
> > >
> > > A. Without the address scarcity issue which drives IPv4 policy, 
> > > the primary criteria for IPv6 addressing policy is suppressing the 
> > > disaggregation that drives route count in the IPv4 DFZ (NRPM 6.3.8).
> > > Such a criteria is not well served if an organization holds dozens 
> > > of discontiguous address spaces as a result of acquisitions, 
> > > mergers and and growing a little bit at a time. This proposal 
> > > says, in effect, once you've consumed your smaller allocation it's 
> > > time for you to get a *much* bigger allocation. The rest of us 
> > > don't want to pay the routing table price for you coming back 
> > > again and again and
> again.
> > >
> > > The proposal could require some renumbering as a result of mergers 
> > > and acquisitions. However, with only modest planning on the 
> > > registrant's part, the policy its 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 about the IETF recommendations?
> > >
> > > A. RFC 3177 recommends that ISPs receive a /32 while downstream 
> > > customers receive a /48 assignment by default with so-called 
> > > "sparse allocation" to allow those assignments to expand by 
> > > changing the netmask. While this proposal supports organizations 
> > > who wish to follow those recommendations, it is not this 
> > > proposal's intention that ARIN follow RFC 3177.
> > >
> > > RFC 3177 is not the gospel truth. It was written back in 2001 when 
> > > there was little IPv6 outside of academia and, indeed, little IPv6 
> > > at all. It's an engineers' SWAG about what operations folk should 
> > > do that's now 8-years-stale.
> > >
> > > This proposal attempts to slow-start IPv6 allocations instead, 
> > > while still maintaining the principle of suppressing the routing table
size.
> > > As an ISP, 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. A /60 is 16 
> > > /64 subnets. That's an internal LAN, a DMZ and 14 more subnets. 
> > > Just how many subnets do you think your normal downstream customer 
> > > will actually use?
> > >
> > > Q. What happens when organizations merge or split?
> > >
> > > A. Entities which merge may renumber out of and return  
> > > conflicting allocations, or they may maintain the existence of the 
> > > acquired organization in order to keep it's addresses. Either way 
> > > it should be a minor hardship.
> > >
> > > Entities which split have a bigger problem since the practical 
> > > effect of route filtering may be that 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 likely 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.  What about IPv6 addresses for uses which will not be connected 
> > > to the Internet at all?
> > >
> > > A. Folks are welcome to get non-multihomed addresses for any 
> > > purpose whatsoever. If they do eventually decide to connect to the 
> > > Internet, the routes will follow whatever rules the ISPs have 
> > > imposed for routes within the single-homed pools.
> > >
> > > Q. What about reporting requirements for downstream assignments?
> > >
> > > A. Reporting requirements were instituted for the purpose of 
> > > verifying eligibility for additional allocations. They have proven 
> > > useful for other purposes and the author encourages ARIN to 
> > > maintain the SWIP system. Nevertheless, this proposal renders the 
> > > use of SWIP for IPv6 optional since it is no longer needed to 
> > > verify eligibility for allocations.
> > >
> > > Q. What if I need more than a /24?
> > >
> > > A. This proposal's author asserts as obvious: anyone who defines a 
> > > need for more than a trillion subnets should make their case 
> > > publicly on PPML, seeking a follow-on proposal that establishes 
> > > address pools at the /16 level.
> > >
> > > Q. What are the struck sections of the current IPv6 policy and why 
> > > should they be struck?
> > >
> > > A. 6.2.3 - 6.2.9 define terms that have no meaning or use in the 
> > > policy as revised by this proposal.
> > >
> > > The 6.4.3 notion of a minimum allocation is obsoleted by the 
> > > allocation pools of specific size in this proposal.
> > >
> > > 6.4.4 is moot as this proposal does not expect registrants to 
> > > justify their IPv6 allocation size.
> > >
> > > 6.5.1 - 6.5.4 and 6.5.8 are replaced entirely by 6.5.9.
> > >
> > > 6.5.5 is largely moot since it's no longer necessary to confirm 
> > > downstream assignments in order to determine eligibility for 
> > > additional addresses.
> > >
> > > 6.7 is moot as it is unnecessary to compute utilization to justify 
> > > addresses under this proposal.
> > >
> > > 6.9 paragraph 2 is moot since utilization is not a factor in IPv6 
> > > policy under this proposal.
> > >
> > > 6.10 is redundant since micro-allocations are trivially 
> > > accomplished under 6.5.9.
> > >
> > >
> > > Implementation notes:
> > >
> > > To prevent wasteful consumption of IPv6 address space without a 
> > > complicated eligibility regime, the author recommends an initial 
> > > and annual fee regime for IPv6 address allocations similar to:
> > >
> > > /56 -- $10 USD
> > > /48 -- $100 USD
> > > /40 -- $1000 USD
> > > /32 -- $10,000 USD
> > > /24 -- $100,000 USD
> > > Legacy -- the lesser of the cost of the next larger size or the 
> > > cost of the next smaller size times the number encompassed by the 
> > > registration.
> > >
> > > The above notwithstanding, it may be advisable to discount /40s 
> > > and /32s to a much lower price during IPv6's general deployment 
> > > process in order to encourage adoption. Folks who already hold 
> > > /31's should probably also get a big break on the $20k fee for a 
> > > good long while, perhaps until the first time they request an 
> > > additional block without offering a plan to return the legacy
addresses.
> > >
> > > For verification of multihoming, the current way ARIN verifies 
> > > multihoming for other parts of it's policy appears satisfactory.
> > > Should that change, the author suggests requiring that the AS# 
> > > contacts for at least two AS#'s submit a template indicating that 
> > > they intend to originate or propagate IPv6 BGP routes from the 
> > > registrant's ORG.
> > >
> > > Timetable for implementation: immediate
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > 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.
> >
> > _______________________________________________
> > 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.
> _______________________________________________
> 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.
>
>
> _______________________________________________
> 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.