idnits 2.17.1 draft-fink-6bone-phaseout-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 33 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3513 (ref. 'ARCH') (Obsoleted by RFC 4291) ** Obsolete normative reference: RFC 2374 (ref. 'AGGR') (Obsoleted by RFC 3587) ** Obsolete normative reference: RFC 2471 (ref. 'TEST-NEW') (Obsoleted by RFC 3701) ** Obsolete normative reference: RFC 1897 (ref. 'TEST-OLD') (Obsoleted by RFC 2471) -- Obsolete informational reference (is this intentional?): RFC 2546 (ref. 'PRACTICE') (Obsoleted by RFC 2772) Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT R. Fink 2 June 12, 2003 R. Hinden 4 6bone (IPv6 Testing Address Allocation) Phaseout 6 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft 25 Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in [RFC2119]. 32 This Internet-Draft expires on December 12, 2003. 34 Abstract 36 The 6bone was established in 1996 by the IETF as an IPv6 Testbed 37 network to enable various IPv6 testing as well as to assist in the 38 transitioning of IPv6 into the Internet. It operates under the IPv6 39 address allocation 3FFE::/16 from RFC 2471. As IPv6 is beginning its 40 production deployment it is appropriate to plan for the phaseout of 41 the 6bone. This note establishes a plan for a multi-year phaseout of 42 the 6bone and its address allocation on the assumption that the IETF 43 is the appropriate place to determine this. 45 This document is intended to obsolete RFC 2471, "IPv6 Testing Address 46 Allocation", December, 1998. RFC 2471 will become historic. 48 1.0 Introduction 50 The 6bone IPv6 Testbed network was established in March 1996, 51 becoming operational during the summer of 1996 using an IPv6 testing 52 address allocation of 5F00::/8 [TEST-OLD] using the original (and now 53 obsolete) provider based unicast address format. In July 1998 a new 54 IPv6 Addressing Architecture [ARCH] replaced the original provider 55 based unicast address format with the now standardized Aggregatable 56 Global Unicast Address Format [AGGR]. 58 To allow the 6bone to operate under the revised IPv6 address 59 architecture with the new Aggregatable Global Unicast addressing 60 format, [TEST-OLD] was replaced with a new IPv6 testing address 61 allocation" of 3FFE::/16 in [TEST-NEW]. During the fall of 1998, in 62 anticipation of [AGGR], the 6bone was re-addressed under the 3FFE::/16 63 prefix with little problems. 65 From the fall of 1998, until the issuance of this note, the 6bone has 66 continued to successfully operate with Aggregatable Global Unicast 67 Address prefixes from the 3FFE::/16 allocation, using a set of 6bone 68 routing practice rules specified in [GUIDE], and later refined to 69 6Bone backbone routing guidelines in [PRACTICE]. 71 During its lifetime the 6bone has provided: 73 - a place for early standard developers and implementers to test 74 out the IPv6 protocols and their implementations; 76 - a place for early experimentation with routing and operational 77 procedures; 79 - a place to evolve practices useful for production IPv6 prefix 80 allocation; 82 - a place to provide bootstrap qualification for production IPv6 83 address prefix allocation; 85 - a place to develop IPv6 applications; 87 - a place for early users to try using IPv6 in their hosts and 88 networks. 90 As clearly stated in [TEST-NEW], the addresses for the 6bone are 91 temporary and will be reclaimed in the future. It further states that 92 all users of these addresses (within the 3FFE::/16 prefix) will be 93 required to renumber at some time in the future. 95 Since 1999 planning for, and allocation of, IPv6 production address 96 prefixes by the Regional Internet Registry (RIR) community has been 97 underway. During 2002 more production IPv6 address prefixes had been 98 allocated than are allocated by the 6bone at the top level. It is 99 generally assumed that this is one reasonable indicator that planning 100 for a 6bone phaseout should begin. 102 It is generally assumed that there is still some remaining need for 103 the 6bone, at least for current usage that will take time to evaluate 104 and possibly move to production IPv6 networks when possible. 106 It is generally viewed that the 6bone is an IETF activity as it was 107 established by IETF participants to assist the IETF in developing 108 IPv6 protocols, and also to assist in the IPv6 transition. To this 109 end, the [TEST-NEW] RFC specified that the 6bone testing was to be 110 under the auspices of the IETF IPng Transition (ngtrans) Working 111 Group 6bone testbed activity. However, during 2002 the ngtrans 112 working group was terminated and replaced to a certain degree by the 113 v6ops working group, which did not include oversight of the 6bone in 114 its charter. Therefore it is assumed that it is appropriate to use 115 the IETF Informational RFC process to determine a 6bone 116 phaseout plan, as well as an appropriate way to get community 117 feedback on the specifics of the 6bone phaseout. 119 This plan for a 6bone phaseout specifies a multi-year phaseout 120 timeline to allow sufficient time for continuing operation of the 121 6bone, followed by a sufficient time for 6bone participants to 122 convert to production IPv6 address prefixes allocated by the relevant 123 Regional Internet Registry (RIR), National Internet Registry, or 124 Local Internet Registries (ISPs). 126 It is anticipated that under this phaseout plan the 6bone will cease 127 to operate by June 6, 2006, with all 6bone prefixes fully reclaimed 128 by the IANA. 130 This document is intended to obsolete RFC 2471, "IPv6 Testing Address 131 Allocation", December, 1998. RFC 2471 will become historic. 133 2.0 6bone Phaseout Plan 135 To provide for the continuing useful operation of the 6bone, to the 136 extent that IETF consensus judges it to be useful, 6bone top level 137 address prefixes known as pseudo TLA's (pTLAs) MAY continue to be 138 allocated until January 1, 2004. 140 Thus after the pTLA allocation cutoff date January 1, 2004, it is 141 REQUIRED that no new 6bone 3FFE pTLAs be allocated. 143 To provide for sufficient planning time for 6bone participants to 144 convert to production IPv6 address prefixes, all 6bone prefixes 145 allocated by the cutoff time specified above, except for allocations 146 withdrawn as a matter of 6bone operating procedures, SHALL remain 147 valid until June 6, 2006. 149 Thus after the 6bone phaseout date June 6, 2006, it is the intent 150 that no 6bone 3FFE prefixes, of any size/length, be used on the 151 Internet in any form. Network operators may filter 3FFE prefixes on 152 their borders to ensure these prefixes are not misused. 154 It should be noted that this RFC does not intend to imply that a 155 6bone prefix holder, whether at the pTLA top level or lower, should 156 seek a production IPv6 address prefix at any specific level. It may 157 be entirely reasonable for a 6bone prefix holder to seek a higher 158 level, or a lower level, IPv6 prefix as their specific needs dictate. 160 3.0 Normative References 162 [ARCH] Hinden, R., S. Deering, "Internet Protocol Version 6 163 (IPv6) Addressing Architecture", RFC 3513, April 2003. 165 [AGGR] Hinden, R., S. Deering, M. O'Dell, "An Aggregatable Global 166 Unicast Address Format", RFC 2374, July 1998. 168 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 169 Requirement Levels", BCP 14, RFC 2119, March 1997. 171 [TEST-NEW] Hinden, R., R. Fink, J. Postel, "IPv6 Testing Address 172 Allocation", RFC 2471, December 1998. 174 [TEST-OLD] Hinden, R., J. Postel, "IPv6 Testing Address Allocation", 175 RFC 1897, January 1996 177 4.0 Informative References 179 [GUIDE] Rockell, R., R. Fink, "6Bone Backbone Routing Guidelines", 180 RFC 2772, February 2000. 182 [PRACTICE] Durand, A, B. Buclin, "6bone Routing Practice", RFC 2546, 183 March 1999. 185 5.0 Security Considerations 187 This document defines a phaseout plan for the usage of the IPv6 188 Testing Address Allocation [TEST-NEW], which uses addresses 189 consistent with [AGGR]. It does not have any direct impact on 190 Internet infrastructure security. 192 6.0 IANA Considerations 194 This document defines a phaseout plan for the usage of the IPv6 195 Testing Address Allocation [TEST-NEW]. The IANA MUST reclaim the 196 3FFE::/16 prefix upon the date specified in 2.0. 198 When the 6bone Testing Address Allocation is reclaimed by the IANA, 199 it is expected that many network operators will filter it on their 200 borders to ensure these prefixes are not misused. 202 There is experience from the IPv4 world that such filters may not be 203 removed promptly should this address space be reallocated, and it is 204 recommended that the IANA bears this in mind before reallocating it 205 in a manner that would require it to be routed globally within the 206 current Internet. 208 7.0 Authors' Addresses 210 Robert L. Fink 211 email: bob@thefinks.com 213 Robert M. Hinden 214 Nokia 215 313 Fairchild Drive 216 Mountain View, CA 94043 217 US 219 phone: +1 650 625-2004 220 email: bob.hinden@nokia.com 222 8.0 Full Copyright Statement 224 Copyright (C) The Internet Society (2003). All Rights Reserved. 226 This document and translations of it may be copied and furnished to 227 others, and derivative works that comment on or otherwise explain it 228 or assist in its implementation may be prepared, copied, published 229 and distributed, in whole or in part, without restriction of any 230 kind, provided that the above copyright notice and this paragraph are 231 included on all such copies and derivative works. However, this 232 document itself may not be modified in any way, such as by removing 233 the copyright notice or references to the Internet Society or other 234 Internet organizations, except as needed for the purpose of 235 developing Internet standards in which case the procedures for 236 copyrights defined in the Internet Standards process must be 237 followed, or as required to translate it into languages other than 238 English. 240 The limited permissions granted above are perpetual and will not be 241 revoked by the Internet Society or its successors or assigns. 243 This document and the information contained herein is provided on an 244 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 245 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 246 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 247 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 248 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.