INTERNET-DRAFT Bob Fink, ESnet August 23, 1999 6BONE Pre-Qualification for Address Prefix Allocation (6PAPA) Abstract This memo describes how the 6bone may be used as a prequalification step during the "bootstrap" phase of sub-TLA assignment by the Regional Internet Registries (RIRs). Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet Draft expires February 23, 2000. Acknowledgements Ideas in this draft are, in part, contributions of the Regional Internet Registries, participants of the 6bone testbed and members of the ngtrans working group. Contents Status of this Memo.......................................... 1 1. Introduction............................................. 3 2. 6BONE Prequalification for sub-TLAs...................... 3 3. Misc. Notes.............. .... .... .... ................ 4 4. Security Considerations.................................. 4 5. Change Log............................................... 5 REFERENCES................................................... 5 AUTHOR'S ADDRESS............................................. 5 1. Introduction This memo describes how the 6bone is used as a prequalification step during the "bootstrap" phase of sub-TLA assignment by the Regional Internet Registries (RIRs). It is predicated on the following points. 1.1 The 6bone community represents the world-wide IPv6 operational networking community as of early 1999, including all existing IPv6 providers and users in the world, operating under the only IPv6 address allocation and authority in place at that time, i.e., the 3FFE::/16 allocation to the 6bone under RFC 2471 ("IPv6 Testing Address Allocation") . 1.2 The 6bone has a well defined address structure underneath the RFC 2471 allocation for high-level (top tier) transit service providers, known as a Pseudo-TLA (pTLA), that all the known top level IPv6 transit providers are part of. See for documentation of the pTLA structure. 1.3 The 6bone process for becoming a Pseudo-TLA (pTLA) is well defined and accepted by the 6bone community. See Informational RFC 2546 Section 7 for current Guidelines for 6Bone pTLA sites. 1.4 The 6bone community as a whole is willing to provide their knowledge, experience and opinions as part of a process to help "bootstrap" the sub- TLA address allocation process for the RIRs. 2. 6BONE Prequalification for sub-TLAs The following steps define the prequalification process using the 6bone. 2.1 The sub-TLA requestor (sTR) places their sub-TLA request with the appropriate RIR and declares that they intend to use the 6bone prequalification process (6PP). (Optional, based on RIR policy.) 2.2 The sTR notifies the 6bone list of their intent to use the 6PP. (This assists the 6bone in establishing the time of first contact starting the process, but does not constitute the actual start of participation in the 6bone.) 2.3 The sTR follows the published process for becoming a pTLA. This process is documented by [RFC 2546] Section 7. The minimum time from first joining the 6bone as an end-site network to becoming a pTLA is set as 3 months. 2.4 After the sTR has been approved as a pTLA, and operating as a pTLA for at least 3 months with at least 3 customers (either lower level transits or end-sites), the pTR petitions the 6bone mailing list for support of its request for a sub-TLA based on its performance as a pTLA, providing relevant proof or statement of how and/or why they believe they have met current 6bone backbone practices (currently as in RFC 2546). 2.5 A 6bone steering group (consisting of 3-5 persons established by 6bone participant consensus) prepares a short 6bone fitness report (6FR) based on input received from 6bone participants, and factual information of compliance with established pTLA rules extant at the time (currently RFC 2546). It then submits the 6FR to the appropriate regsitry. Note that 6bone participant means members of pTLA, pNLA or end-site organizations, not mailing list subscribers. 2.6 If after two months of petitioning the 6bone mailing list (2.4 above) for support of its sub-TLA request with no response, the sTR may notify the appropriate RIR of 6bone non-responsiveness and ask for the RIR to proceed without a 6FR. (It is up to the RIR to decide what to do next, including the decision that the sTR's experience with the 6bone qualifies it for a sTLA allocation.) 2.7 After assignment of an sub-TLA to the sTR (by the RIR), the sTR may optionally renumber from the 6bone pTLA prefeix to the sub-TLA prefix, or continue use of their pTLA. If the pTLA space becomes over subscribed, the most likely networks to be asked to surrender their pTLA would be those holding production TLA/sub-TLA prefix space. 3. Misc. Notes 3.1 Currently the RFC 2546 doc is being reworked under the 6bone hardening process now underway, which will almost certainly yield a stronger set of rules on what it takes to operate as a pTLA. 3.2 The current RFC 2546 doc does not specify a prequalification time as a pNLA or end-site 6bone site prior to requesting a pTLA. Thus these prequalification rules have established the minimum time of 3 months from first joining the 6bone as an end-site network to becoming a pTLA. 3.3 In S6. above, the total time from start of the 6PP until a protest could be made to the RIR, would be in the 8 months minimum (3 mos.while becoming a pTLA, 3 mos. while a pTLA, plus 2 mos.). 3.4 Some existing pTLA sites should not be allocated a sub-TLA as they are not production networks, rather they were created to "bootstrap" the 6bone or help a specific testing user community. The decision on what pTLA may or may not qualify for a sub-TLA is left to the process outlined above, and the RIR processes for allocating sub-TLAs. 4. SECURITY CONSIDERATIONS There are no security considerations of this document as it only specifies a process of recommendations made to IPv6 Address Registries for prequalification for production IPv6 Address Prefix allocations. 5. CHANGE LOG Changes since version -00 of the draft: None yet. REFERENCES [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. AUTHOR'S ADDRESS Bob Fink Lawrence Berkeley National Lab ESnet - MS 50A-3111 1 Cyclotron Road Berkeley, CA 94720 USA phone: +1 510 486 5692 fax: +1 510 486 4790 email: fink@es.net -end