Foreword note: This proposal stacks additional functionality on top of the RFC 3056 6to4 standard in a way which violates specific portions of that standard. The standard would need revisions before this policy could be implemented. Refer to the attached appendix for details.
Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0
ARIN shall encourage and support the use of the RFC [3056] 6to4 standard for rapid deployment of IPv6 by existing IPv4 registrants within the ARIN region prior to IPv4 exhaustion. This deployment shall consist of three phases:
Transition phase: 1/1/2008 through 1/1/2010
ARIN shall encourage all native IPv6 providers to implement 6to4 translating routers.
ARIN shall encourage IPv4 registrants seeking end-user IPv6 provider-independent space to use and announce 6to4 space instead.
ARIN shall encourage native IPv6 providers to constrain IPv6 table growth by filtering 2002:: routes as specified in the 6to4 RFC [changed as attached] and encapsulating affected IPv6 traffic into IPv4 packets.
ARIN shall establish a form for setting a permanent login to the NRO 6to4 reverse DNS (RDNS) delegation system for the delegations associated with a particular block of assigned or allocated IPv4 addresses. ARIN shall request that NRO implement such a permanent login so that once set by ARIN, no further weakly authenticated access will be permitted to the delegations associated with that block of IPv4 addresses.
Organizations holding IPv4 space under ARIN's Registration Services Agreement (RSA) may submit a form to set a RNDS permanent login associated with no more than one of the IPv4 assignments or allocations held by that organization. This RNDS permanent login is attached to and indivisible from the IPv4 assignment or allocation.
Organizations wishing to submit the RDNS form for legacy IPv4 space not managed under the RSA shall first accept the RSA as associated with that address block. 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.
Mixed phase: 1/1/2010 until IPv4 use declines
ARIN shall cease accepting permanent password forms for blocks to which a permanent password has not already been assigned. By 2/1/2010, ARIN shall publish a list of all 2002:: blocks covered by permanent passwords. These blocks shall be considered valid provider-independent blocks.
ARIN shall cease offering 6to4 as an alternative to end-user IPv6 provider-independent assignments.
ARIN shall request that native IPv6 providers accept route advertisements for the exact provided list of 2002:: prefixes.
ARIN shall advise that organizations which filter 6to4 advertisements per the RFC may continue to do so with the expectation of full reachability until the deployment of IPv4 declines.
Native phase: Following the decline of IPv4
ARIN shall request that native IPv6 providers accept and propagate advertisements for the exact provided list of 2002:: prefixes, treating such prefixes no differently than they would any other IPv6 assignment by ARIN.
ARIN shall request that any network which does not receive 2002:: routes discontinue offering a 2002::/16 route and cease encapsulating 2002:: destined packets into IPv4 packets.
ARIN shall advise that providers who improperly continue to filter 2002:: routes may be unable to reach valid hosts within ARIN's territory.
RFC 3056 allocated 2002::/16 for use in IPv6 islands existing within the IPv4 network. A translating router is assigned a specific IPv4 address. The IPv6 island is then connected to that router using subnets in 2002:ipv4:addr::/48. The translator encapsulates IPv6 traffic for other 2002:: addresses into IPv4 packets and sends them to the corresponding IPv4 address for decapsulation. It similarly encapsulates packets for native IPv6 destinations and sends them to the nearest public 6to4 translator. This policy extends the use of 2002::/16 for the IPv6 islands' eventual transition to a natively connected IPv6 network.
This policy addresses four 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 deploy 6to4 IPv6 addresses for production use 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 deploy 6to4 IPv6 addresses for production use and join the next generation of the Internet.
The need to constrain route announcement in the IPv6 Default-Free Zone
Routers on the portion of the Internet backbone which do not implement a default route (the default-free zone or DFZ) can support a fixed number of individual routes. This limit is set by the amount of memory in the routers, the amount of time it takes routers to load the BGP table and related dynamic stability issues. The system is severely stressed by the current presence of some 220,000 advertised IPv4 prefixes and might fail if the same 220,000 routes were rapidly imported into IPv6.
This policy reduces the number of routes added to the IPv6 DFZ in the near term by placing most provider-independent (PI) assignments under a 2002::/16 aggregated route. Providers may defer introducing the individual routes into the DFZ until such a time as their infrastructure can readily support it or until IPv4 deployment (and the IPv4 routes advertised) begins to wane. Further, because only one of the 6to4 blocks associated with an organization's IPv4 blocks can be imported to IPv6, the total number of routes eventually added to IPv6 will likely number less than 55,000.
More comments:
Reverse DNS
The Number Resource Organization (NRO) manages reverse DNS delegations for 2002::/16 on behalf of ARIN and the other Regional Internet Registries. Access to perform delegations is weakly authenticated: any machine within the affected /48 may set or change the delegation via https://6to4.nro.net/. For production use of 2002::/16, a more strongly authenticated access is required.
By accepting strong authentication for only one of an organization's 2002:: assignments, ARIN strongly discourages organizations from announcing multiple discontiguous blocks of IPv6 addresses into the global routing table.
Additional Notes
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.
Current IPv6 assignment policy disrespects the IPv4 early adopters (legacy registrants) by refusing provider-independent space to those who can not meet today's significantly more stringent requirements. While done with the best intent, the policy engenders hostility and procrastination among a group whose enthusiastic participation could offer significant impetus to the IPv6 deployment effort. This proposal reverses that trend, offering legacy registrants a time-limited opportunity to join the IPv6 deployment effort in a personally advantageous manner while side-stepping the routing problems such participation might otherwise cause.
Shim6 offers a potential way to implement multihoming for small operators using two or more subnets of provider aggregatable space instead of a provider independent assignment. If successful, Shim6 may be ubiquitously deployed as soon as 2015. If Shim6 works out, this current proposal provides a bridge so that IPv4 registrants can continue to employ the benefits of multihoming without harming the IPv6 DFZ even while Shim6 software is developed and deployed.
Waste
This proposal uses only address space already allocated for 6to4.
This proposal limits the injection of routes into the global IPv6 table both with an RDNS policy which strongly discourages the production deployment of more than one such route by any single organization and a filtering policy that allows organizations to aggregate the entire space into a single announced prefix.
END OF TEMPLATE
6to4 presently forbids announcing 2002:: space into the native IPv6 infrastructure based on the desire back in 2001 to avoid propagating the discontiguous mess of IPv4 routes forward in to IPv6. In 2007, this proposal envisions an alternate approach to discourage such pollution while facing the much closer reality of IPv4 address exhaustion. This would require adjustments to the RFC, detailed here:
RFC 3056 section 5.2 specifies:
This would change to:
RFC 3056 section 5.2.2 specifies:
This would change to:
Additionally, the following statement would be added to RFC 3056: