idnits 2.17.1 draft-horley-v6ops-lab-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 27, 2021) is 997 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 185, but no explicit reference was found in the text == Unused Reference: 'RFC3515' is defined on line 197, but no explicit reference was found in the text == Unused Reference: 'RFC5180' is defined on line 218, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Horley 3 Internet-Draft T. Coffeen 4 Intended status: Informational S. Hogg 5 Expires: January 28, 2022 HexaBuild 6 N. Buraglio 7 C. Cummings 8 Energy Sciences Network 9 K. Myers 10 IP ArchiTechs 11 R. White 12 Juniper Networks 13 July 27, 2021 15 Expanding the IPv6 Lab Use Space 16 draft-horley-v6ops-lab-01 18 Abstract 20 To reduce the likelihood of addressing conflicts and confusion 21 between lab deployments and non-lab (i.e., production) deployments, 22 an IPv6 unicast address prefix is reserved for use in lab, proof-of- 23 concept, and validation networks as well as for for any similar use 24 case. This document describes the use of the IPv6 address prefix 25 0200::/7 as a prefix reserved for this purpose (repurposing the 26 deprecated OSI NSAP-mapped prefix). 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 28, 2022. 45 Copyright Notice 47 Copyright (c) 2021 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. New Lab IPv6 Address Prefix . . . . . . . . . . . . . . . . . 3 64 3. Operational Implications . . . . . . . . . . . . . . . . . . 3 65 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 67 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 70 7.2. Informative References . . . . . . . . . . . . . . . . . 5 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 73 1. Introduction 75 The address architecture for IPv6 ([RFC4291]) does not explicitly 76 define any prefixes allocated exclusively for lab use, nor is such 77 address space allocated in [RFC6890] or in [RFC8200]. While lab 78 deployments could potentially use IPv6 address prefixes typically 79 assigned and configured in non-lab network, the use of such 80 addressing in lab environments may create addressing conflicts and 81 operational confusion. For instance, designing labs utilizing ULA 82 fc00::/7 [RFC4193] is problematic due to the random global ID 83 requirement preventing hierarchical network prefix design 84 possibilities. Further, default address selection behavior [RFC6724] 85 by end nodes may result in a depreferencing of such addresses and 86 prevent lab deployments from accurately modeling their desired non- 87 lab equivalents. 89 To resolve these problems involved in building large scale lab 90 networks, and pre-staging, or automating large-scale networks for 91 deployment, this document allocates the IPv6 address prefix 0200::/7 92 for these purposes. 94 The goal is to allow organization to share working lab configuration 95 files (with little or no need of modification) to be deployed in a 96 third party lab environment like, 98 public and private clouds, 100 virtualization or hosting environments, 102 and in other networks like Service Providers, Enterprise, Government, 103 IoT, and Energy, 105 all with the knowledge that the lab GUA address space will perform 106 the same as any GUA but with the added knowledge that filtering will 107 be used to protect accidential leaks to the Internet. 109 The following criteria is for selecting the lab prefix: 111 The precendence for the lab prefix should no be lower than the GUA 112 prefix as defined in [RFC6724] (unlike ULA). Reduce the operational 113 impacts to IANA and the RIR's in selecting lab prefix space. 115 2. New Lab IPv6 Address Prefix 117 The prefix reserved for lab and testing purposes is 0200::/7. 119 3. Operational Implications 121 This space SHOULD NOT be employed for addressing use cases which are 122 already defined in other RFCs, such as addresses set apart for 123 documentation, testing, etc. 125 Enterprise and large scale networks have some specific criteria 126 around building and validating prior to deployment. The issues with 127 ULA for infrastructure modeling and labbing at the host level are 128 more impactful in large enterprises. This is due to the increased 129 focus on large scale hosts, servers and apps testing. Also, it is 130 likely that both GUA and ULA may co-exist (or are planned) and 131 reconfiguring lab hosts and networks isn't practical or desirable due 132 to inconsistent results for host preference due to [RFC6724] 133 behavior. 135 Most large enterprises strive to build lab, dev, and qa environments 136 that reflect production as accurately as possible. This is a fairly 137 straightforward way to avoid disparity between production and non- 138 production. Enterprise environments is an area that needs increased 139 IPv6 adoption. In an effort to make it easier to model a global 140 enterprise and to avoid the pitfalls of ULA de-preferenced host 141 behavior or squatting on other IPv6 space, a specific IPv6 lab prefix 142 is being assigned. 144 Because this address prefix has previously been used for the OSI 145 NSAP-mapped prefix set in [RFC4048] and [RFC4548], and deprecated, 146 this address prefix is already limited in its usability. In 147 addition, the address prefix was returned to IANA and is available to 148 be marked for lab or other purposes. 150 This assignment implies that IPv6 network operators SHOULD add this 151 address prefix to the list of non-routeable IPv6 address space, and 152 if packet filters are deployed, then this address prefix SHOULD be 153 added to packet filters. This is not a local-use address prefix so 154 these filters may be used in both local and public contexts. 156 4. IANA Considerations 158 IANA is to record the reservation of the IPv6 global unicast address 159 prefix 0200::/7 as a lab-only prefix in the IPv6 address registry. 160 No end party is to be assigned this address. 162 5. Security Considerations 164 The addresses assigned for lab and staging use SHOULD be filtered as 165 noted above. 167 Setting aside address space for lab and staging use, and adding this 168 address space to common filters to prevent destinations in this space 169 from being routed in production networks (including the global 170 Internet) improves security by preventing the leakage of prefixes 171 used for testing into production environments. As such, setting 172 aside this space improves the overall security posture of the 173 Internet. 175 6. Acknowledgements 177 The authors acknowledge the work of Bob Hinden and Stephen Deering, 178 in authoring the protocol standard and the addressing architecture 179 for IPv6. 181 7. References 183 7.1. Normative References 185 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 186 Requirement Levels", BCP 14, RFC 2119, 187 DOI 10.17487/RFC2119, March 1997, 188 . 190 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 191 (IPv6) Specification", STD 86, RFC 8200, 192 DOI 10.17487/RFC8200, July 2017, 193 . 195 7.2. Informative References 197 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 198 Method", RFC 3515, DOI 10.17487/RFC3515, April 2003, 199 . 201 [RFC4048] Carpenter, B., "RFC 1888 Is Obsolete", RFC 4048, 202 DOI 10.17487/RFC4048, April 2005, 203 . 205 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 206 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 207 . 209 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 210 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 211 2006, . 213 [RFC4548] Gray, E., Rutemiller, J., and G. Swallow, "Internet Code 214 Point (ICP) Assignments for NSAP Addresses", RFC 4548, 215 DOI 10.17487/RFC4548, May 2006, 216 . 218 [RFC5180] Popoviciu, C., Hamza, A., Van de Velde, G., and D. 219 Dugatkin, "IPv6 Benchmarking Methodology for Network 220 Interconnect Devices", RFC 5180, DOI 10.17487/RFC5180, May 221 2008, . 223 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 224 "Default Address Selection for Internet Protocol Version 6 225 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 226 . 228 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 229 "Special-Purpose IP Address Registries", BCP 153, 230 RFC 6890, DOI 10.17487/RFC6890, April 2013, 231 . 233 Authors' Addresses 234 Ed Horley 235 HexaBuild 237 Email: ed@hexabuild.io 239 Tom Coffeen 240 HexaBuild 242 Email: tom@hexabuild.io 244 Scott Hogg 245 HexaBuild 247 Email: scott@hexabuild.io 249 Nick Buraglio 250 Energy Sciences Network 252 Email: buraglio@es.net 254 Chris Cummings 255 Energy Sciences Network 257 Email: chriscummings@es.net 259 Kevin Myers 260 IP ArchiTechs 262 Email: kevin.myers@iparchitechs.com 264 Russ White 265 Juniper Networks 267 Email: russ@riw.us