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 revisons 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 all existing IPv4 registrants.
ARIN shall encourage all native IPv6 providers to accept 2002:: route announcements into their native IPv6 tables where such routes correspond to IPv4 blocks managed by ARIN for a period starting 1/1/2008 and ending 2/1/2010.
ARIN shall require any entity receiving native IPv6 space from ARIN to either implement a 2002::/16 route to a valid 6to4 translating router or decline to filter any 2002:: routes associated with IPv4 blocks managed by ARIN until 2/1/2010. ARIN shall encourage the organization to do both.
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 permanant login is attached to and indivisible from the IPv4 assignment or allocation.
Organizations wishing to submit said form for legacy 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.
On 1/1/2010, 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. ARIN shall request that following 2/1/2010, all native IPv6 providers minimally treat advertisements for the exact provided list of 2002:: prefixes no differently than they would any other IPv6 assignment by ARIN.
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 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 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.
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. 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.
Waste
This proposal uses only address space already allocated for 6to4.
This proposal limits the injection of routes into the global IPv6 table with an RDNS policy which strongly discourages the production deployment of more than one such route by any single organization.
Big Organization / Little Organization Dichotomy
On reason for the slow uptake of IPv6 is the operational differences between large and small organizations.
Network administrators in large organizations move carefully. Plans are proposed and approved for investigation. Testing is performed in the lab for months or years until a consensus is reached that its ready for deployment. Deployment approvals are received and schedules are set. Finally, the new technology is deployed to the production environment.
This fits reasonably well with ARIN's existing model for IPv6 assignment: with the fees waived and internal approvals already in place, soliciting IPv6 addresses from ARIN presents no particular obstacle during the testing phase.
Network administrators in small organizations follow a very different path. Acting on either a salesman's defined business need or on his own initiative, the network expert (there's only one) acquires and tests a new technology on his workstation. If more equipment is needed and the investigation is driven by a defined business need, additional equipment may be purchased. More commonly, ready spares are assigned to the testing task and returned to the closet once done. When the expert determines that testing is adequate, he proceeds to deploy the technology to a lightly used portion of the production system. This is scheduled for off-hours if disruption is possible. Once found satisfactory there, the technology is opportunistically deployed throughout the rest of the system.
ARIN's model for IPv6 assignment conflicts with operating process present in small organizations. Barring a defined business need from the sales staff, the network expert generally lacks the authority to sign agree to ARIN's contract. Faced with competing tasks for his time, he'll generally choose to abandon the investigation in favor of something else. A modified 6to4 would work well this individual, as he need only seek ARIN's involvement once his organization's IPv6 deployment is fait accompli. 6to4's current inability to announce the 2002:: addresses on the native IPv6 Internet presently serves as a barrier preventing the small organization network expert from giving it more than a casual glance.
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: