Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0
ARIN shall request a block of IPv6 space from IANA to be used as a "migration space" for organizations migrating from IPv4 to IPv6. During the period January 1, 2008 through December 31, 2009, all EXISTING, NEW, and LEGACY IPv4 networks managed by ARIN will be mapped to IPv6 networks within the Migration Space. Each /24 of IPv4 space will algorithmically map to a /56 of IPv6 space illustrated by the chart below:
IPv4 Space IPv6 Space
/24 --> /56
/23 --> /55
/22 --> /54
/21 --> /53
/20 --> /52
/19 --> /51
/18 --> /50
/17 --> /49
/16 --> /48
/15 --> /47
/14 --> /46
/13 --> /45
/12 --> /44
/11 --> /43
/10 --> /42
/9 --> /41
/8 --> /40
/0 --> /32
1. All EXISTING allocations and assignments of IPv4 space managed by ARIN under the regular RSA will receive an allocation or assignment from the Migration Space. Initial contact and organization records will be copied from the relevant IPv4 records. No initial reverse-DNS will be assigned.
Migration Space mapped from existing IPv4 space managed under ARIN's RSA may be claimed by the authorized contact for the IPv4 space by submitting a template requesting reverse DNS for the new space. No additional fees will be due beyond those already paid for registration of the IPv4 space.
2. All NEW allocations and assignments of IPv4 space will include the corresponding allocation or assignment from the Migration Space to the requesting organization. Those portions of the Migration Space which map from currently unallocated portions of the IPv4 space are reserved for this purpose. Migration Space for new allocations and assignments is considered automatically claimed.
3. All LEGACY assignments of IPv4 space managed by ARIN which do not fall under an RSA will receive a corresponding assignment from the Migration Space. Initial contact and organization records will be copied from the relevant IPv4 records. No initial reverse-DNS will be assigned.
Migration Space mapped from legacy IPv4 space not managed under ARIN's RSA may be claimed by the authorized contact for the IPv4 space by submitting a template requesting reverse DNS for the new space. The registrant must first accept ARIN's RSA for the IPv4 space and update all contact and organizational information in ARIN's database. These legacy registrations will be treated as end-user assignments unless otherwise requested by the registrant. As these networks are grandfathered, no initial assignment fees will be due and no use qualifications will be requested. As specified by ARIN's end-user assignment policy, only ARIN's then-current annual maintenance fee will be due.
4. Those portions of the Migration Space which map from IPv4 blocks managed by RIRs other than ARIN will be reserved and redelegated on request to the respective RIR for whatever purpose that RIR sees fit.
Any portion of the Migration Space not claimed by an IPv4 registrant and not redelegated to another RIR by January 1, 2010 shall expire and enter ARIN's general pool of available IPv6 space.
This policy addresses three of the difficulties ARIN faces:
The looming exhaustion of the IPv4 space.
IPv4 space is rapidly running out with potentially disastrous consequences. Various ideas have been floated to slow or mitigate this process, but thus far only one permanent solution is on the table: migrate to IPv6.
Unfortunately, IPv6 uptake has been slow. Usage projections suggest that the IPv4 space will be completely exhausted long before IPv6 has reached a level of ubiquity necessary to replace it.
The proposed policy encourages a the rapid deployment of IPv6 by making IPv6 allocations and assignments trivially available to all existing IPv4 registrants at no additional cost.
Obsolete and incorrect legacy IPv4 registration and contact information.
Many of the IPv4 registrations established before ARIN's stewardship of the Americas portion of the IPv4 space show obsolete and incorrect contact and organizational information. Some of the space is defunct.
This policy encourages those registrants to voluntarily come forward, update their contact information and voluntarily join ARIN's normal management process so that they may receive IPv6 addresses and join the next generation of the Internet.
Legacy IPv4 registrants don't pay their fair share.
Registrants holding pre-ARIN address space receive services from ARIN such as reverse-DNS but do not pay their fair share of ARIN's annual $10M operating expenses.
This policy encourages those registrants to voluntarily sign the Registration Services Agreement (RSA) and join ARIN's regular operating process as end-users so that they may receive IPv6 addresses and join the next generation of the Internet.
Additional Notes
Algorithmically mapping each /24 to a particular /56 within the migration space offers advantages that simply assigning /56's or /48's in a row as they're claimed would not.
Reverse DNS is not initially assigned for two reasons: 1) Lame delegations are undesirable. Servers should be prepared to provide reverse DNS for IPv6 addresses before the delegation is made.. 2) Registrants should be encouraged to claim the addresses sooner rather than later.
It would be reasonable to reward folks like the 6Bone users for their efforts as first adopters instead of disrespecting them in favor of the IPv4 holders. This proposal neither precludes nor addresses that.
A common criticism of this proposal is that no organization which has needed IPv6 space has failed to get it, making this proposal redundant. This proposal is not intended to address individual organizations' existing need for IPv6 addresses as clearly all such organizations already have them. Instead, it targets organizations' communal need to have completed deployment of IPv6 prior to IPv4's exhaustion. It does so by artificially creating a need for IPv6. Many if not most network administrators share a common trait: the desire to tinker. Given possession of a new gadget, many admins will choose to try it out. Having tried it, many will then find that they need it after all.
Waste
This proposal envisages consuming a block of IPv6 space that is larger than the entire IPv4 space and it propagates past inefficiencies in the IPv4 allocation process to this new space. What will happen to it? What will prevent problems like the defunct /8's and /16's in the IPv4 space?
First, it is unlikely that this proposal would induce defunct space. Most who would waste the space will simply not claim it in the first place or will fail to maintain the registration once claimed. The proposal returns such space to the pool in 2010 where it will be assigned to someone else under then current rules. As such, the only proper concern about waste relates to the folks who do claim the space but never need such a large assignment.
Its likely that the process of claiming the IPv6 space will help ARIN identify which of the legacy IPv4 space is truly defunct, a precursor to reclaiming that space and a laudable goal in and of itself.
Second, this proposal would consume a tiny amount of the IPv6 space relative to the
whole: one four billionth, a /32. If IPv6 lasts 100 years, this
proposal will shorten its lifespan by 45 seconds.
Third, as we've seen in the IPv4 tables, route deaggregation occurs regardless of whether contiguous space is assigned. Even if it did not, current advances in memory capacity make it unlikely that propagating the existing discontinuity of the IPv4 space forward to IPv6 will have a lasting negative impact.
Fourth, most IPv4 registrants only hold a single block. Between August 2002 and May 2007, 2,209 OrgIDs received an allocation from ARIN. Of those OrgIDs, 1,292 have only requested the one.
The bottom line is: no harm, no foul. At worst the IPv4 holders get more IPv6 space than is generally available later. There is no waste-related damage of substance.
END OF TEMPLATE
Issues to consider:
Is /56 a more appropriate starting point than /48? /24's would map to /56's, /16's would map to /48's and /8's would map to /40's. This seems reasonable but would the folks who maintain the backbone accept a prefix longer than /48? Current documentation frequently lists /48 as the minimum size.
Some folks (like Verizon) hold a large number of discontiguous IPv4 blocks. Would it be a good idea to allow those folks to ask that the corresponding Migration Space be abandoned in favor of a single large contiguous allocation?