INTERNET-DRAFT Bob Fink, ESnet January 10, 2000 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 July 10, 2000. Acknowledgements Ideas in this draft are, in part, contributions of various IETF working groups, the Regional Internet Registries, participants of the 6bone testbed, and the worldwide IPv6 community. Contents Status of this Memo.......................................... Acknowledgements............................................. 1. Introduction............................................. 2. 6BONE Prequalification for sub-TLAs...................... 3. Security Considerations.................................. 4. Change Log............................................... REFERENCES................................................... AUTHOR'S ADDRESS............................................. 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 based on the following points. 1.1 The 6bone community represented 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 TLA allocation to the 6bone, documented in [6BONE-TLA]. 1.2 The 6bone uses a well defined top level address structure called a pseudo-TLA (pTLA), documented in [PSEUDO], that is delegated from its 3FFE::/16 allocation, that all top level 6BONE IPv6 transit providers use. 1.3 The 6bone process for allocation of pTLA-s is well defined in section 7 of [HARDEN] and is well accepted by the 6bone community. 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 2.1 A sub-TLA requestor (sTR) places a sub-TLA request with the appropriate RIR, per the RIR's own sub-TLA procedures, indicating that they intend to use 6bone prequalification. 2.2 The sTR follows the published process for becoming a pTLA as documented in Section 7 of [HARDEN]. (Note that [HARDEN] specifies the minimum time from first joining the 6bone as an end-site network to becoming a pTLA as 3 months.) Those pTLA allocations in effect prior to [HARDEN], or its predecessor RFC2546, are considered to have met all requirements for becoming a pTLA. However, 2.3 still applies. 2.3 An sTR must have operated as a pTLA for at least 3 months, with at least 3 active delegations under its pTLA (either lower level transits or end-sites, or a mix of both), for the sTR to meet the 6bone experience criterion (6EC). 2.4 A 6bone steering group (6SG), consisting of 3-5 persons established by 6bone participant consensus, uses factual operational information and other relevant experience of the sTR to determine if the 6EC has been met. It is expected that the 6SG will respond within 30 days. It is up to the RIR's own policies and procedures to determine what happens if this time is not met. 2.5 After allocation of a sub-TLA to the sTR (by an RIR), the sTR may optionally renumber from the 6bone pTLA prefix to the new sub-TLA prefix, or continue to use their pTLA for multihoming purposes. If the pTLA space becomes over subscribed, the most likely networks to be asked to surrender a pTLA would be those holding production TLA/sub-TLA prefix space. Given the large size of the pTLA space this is not considered likely to ever happen. 3. 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. 4. Change Log Changes since version -00 of the draft: Various rewordings for clarity. Replace [RFC 2546] references with new HARDEN specification now approved as Informational RFC. Notes that pTLAs prior to [HARDEN] and RFC 2546 are legitimate pTLAs, though still 3 months of oeprating experience with at leasts 3 delegations. Removal of the previous 2.2 requirement that the sTR notifies the 6bone list of intent to use the 6PP. In previous 2.4 (now 2.3) clarifies that it is 6bone experience criteria that is being met by the sTR for operating for 3 months. The new 2.4 specifies a 6SG maximum response interval of 30 days, with the RIR being responsible for deciding what to do when this time is exceeded. Removal of any mention or implication that the 6bone community us stating that an sTR is qualified for a sub-TLA allocation. Removal of previous 2.6 regarding time out issues. Removal of section 3. Only meaningful removal was regarding some pTLA-s not qualifying for this process due to the nature of there network. This had been regarded as unfair and unreasonable and there was general agreement to remove this. REFERENCES [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [6BONE-TLA] R. Hinden, R. Fink, J. Postel, "IPv6 Testing Address Allocation", RFC 2471, December 1998. [PSEUDO] R. Fink, "6bone pTLA & pNLA Formats", see , January, 2000. [HARDEN] R. Rockell, R. Fink, "6Bone Backbone Routing Guidelines", RFC xxxx, December 1999. Replaces RFC 2546. AUTHOR'S ADDRESS Bob Fink, ESnet Lawrence Berkeley National Lab 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