Please, use global-v6@lists.apnic.net for inputs to this draft policy proposal, in order to avoid threads being split across multiple mail exploders in different regions. 1. Number: (The RIPE NCC will assign this) 2. Policy Proposal Name: Provider-Independent (PI) IPv6 Assignments for End-User-Organizations Note: We can use ³Portable IPv6 Assignments for End-User-Organizations² if that helps some folks to buy-in the proposal. 3. Author: a. name: Jordi Palet Martinez b. e-mail: jordi.palet@consulintel.es c. organisation: Consulintel 4. Proposal Version: 1.1 5. Submission Date: 17/4/2006 6. Suggested RIPE Working Group for discussion and publication: Address Policy 7. Proposal type: a. new, modify, or delete. NEW 8. Policy term: a. temporary, permanent, or renewable. TEMPORARY 9. Summary of proposal: This policy is intended to provide a solution for organizations that have a need for provider independent assignments in IPv6. Typically those organizations will require the provider independent assignment in order to be able to become multihomed in a similar fashion as today is done for IPv4, but other reasons are also foreseen. For example some organizations aren¹t multihomed, but still require being globally routable with stable addressing (avoiding renumbering if they change the upstream provider) and in those cases (reasons behind may be administrative, policy, security, etc.) it seems that no other solution than provider independence is feasible, at least by now. Considering the foreseen consequences in the medium/long-term of this policy in the routing tables, this policy proposes an expiry date of 3 years once a technically correct alternative valid and deployable solution becomes accepted by the community. After that sunset period, the assignments done for multihoming purposes should be reclaimed and this policy should be modified to still allow assignments that could be required for purposes different than multhoming. At the sunset, the organizations that want to avoid renumbering and qualify to become an LIR, will be able to opt for that solution and they will get allocated the same prefix. 10. Policy text: a. Current (if modify): b. New: Provider-Independent IPv6 assignment to End-User-Organizations Qualification for an IPv6 Provider-Independent assignment: To qualify for a direct assignment, the organization must not be an IPv6 LIR and must qualify for an IPv4 assignment or allocation from RIPE NCC under the actual IPv4 policy. This is valid regardless of actually having being assigned or allocated such an IPv4 block. Provider-Independent IPv6 assignment size to End-User-Organizations: The minimum size of the assignment is /32. However a larger assignment can be provided if duly documented and justified. Subsequent assignment size to End-User-Organizations: Whenever possible, further assignments will be made from adjacent address blocks, but only if duly documented and justified. Assignment super-block: Those assignments shall be allocated from a separate super-block to allow for LIRs to filter them if required. Expiry for those assignments: In the case of assignments done under this proposal in order to address the multihoming issue, they will need to return the block in a maximum period of 3 years after a technically correct alternative valid and deployable solution becomes accepted by the community. Alternatively, to avoid renumbering, some of the organizations affected by this, could become an LIR, if they qualify for it. 11. Rationale: a. Arguments supporting the proposal In IPv4 there are organizations that qualify for an allocation for being PI, or could opt to be an LIR, either because they need to be multihomed or have other administrative or technical reasons to require a portable addressing block. This is not the case today for IPv6 and it is perceived as a clear barrier for deployment of IPv6 in some organizations, and is being addressed by this proposal by means of providing a direct assignment from RIPE NCC. These organizations are not allowed to make further assignments to other external organizations, but instead only to assign subnets internally within their own facilities. Assigning /32 will make those blocks to behave as other regular LIR-allocated ones and follow the generally accepted routing filtering practices, but at the same time being identifiable belonging to a special super-block. Also, it allows becoming an LIR, if that¹s the case, without requiring a renumbering. By setting up this policy, we avoid creating an unfairness situation among different regions and allow any organization that requires PI to access to it. All the organizations that opt for this PI, will be in the same fair situation once the technical solution is agreed and will have to either move to the new solution or become an LIR if they qualify. Newcomers will be in the same situation. Organizations that don¹t opt to PI with this policy is because they don¹t need it, so they aren¹t put in an unfair situation. Those that don¹t believe in possible alternative solutions and agree in going for a permanent PI policy instead, don¹t have valid reasons to oppose to this proposal, as the sunset will only enter into effect once that solution is agreed, so this proposal is not against their view. Some organizations my qualify to become an LIR now and avoid using this temporary assignment, but if their only reason to become an LIR is to get the PI block, then it seems better, looking in the long-term routing table size conservation, to go for this choice, which is more fair for the overall community. The ³temporarily² of this assignment must be understood as a long-term one, as we may expect those alternative solutions to be available possible in 3-4 years, which means that with the ³transition² period of 3 years, asking for a change in 6-7 years must not be considered as a pain. b. Arguments opposing the proposal The possible effect of this proposal is the grow of the routing tables to figures which, together with the existing (and forecasted) IPv4 routing entries, could create an important trouble to operators before vendors provide products with implement technical solutions, or even if those technical solutions exists, have an important impact in the cost or/and depreciation period for the infrastructure investments. This is the reason why the proposal provides already a fix sunset, but relative to the date where an alternative and technically correct solution is available and accepted as deployable by the community. Regarding the size of the assignment (/32), being a temporal one, should not be considered as a space waste, and instead be seen as an advantage in the sense of not requiring new special filters. Acknowledgments: I will like to acknowledge the inputs received for the first version of this proposal from Marcelo Bagnulo and Lea Roberts. ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.