idnits 2.17.1 draft-horley-v6ops-expand-doc-02.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 -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (26 January 2022) is 814 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 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: 30 July 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 26 January 2022 15 Reserving Additional IPv6 Address Prefixes for Use in Documentation 16 draft-horley-v6ops-expand-doc-02 18 Abstract 20 To reduce the likelihood of conflict and confusion when relating 21 documented examples to deployed systems, the IPv6 unicast address 22 prefix 2001:db8::/32 is reserved for use in examples in documentation 23 including RFCs, books, articles, vendor manuals, etc. This document 24 proposes the reservation of additional IPv6 prefixes for this 25 purpose; specifically, 3ffe::/16 (formerly 6bone) and fec0::/10 26 (formerly site-local). 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 30 July 2022. 45 Copyright Notice 47 Copyright (c) 2022 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 (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Revised BSD License text as 56 described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Revised BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 63 3. Documentation IPv6 Address Prefixes . . . . . . . . . . . . . 3 64 4. Operational Implications . . . . . . . . . . . . . . . . . . 3 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 4 70 8.2. Informative References . . . . . . . . . . . . . . . . . 5 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 73 1. Introduction 75 The address architecture for IPv6 [RFC4291] does not specifically 76 allocate any IPv6 address prefixes for documentation purposes. The 77 current IPv6 documentation prefix of 2001:db8::/32 defined in 78 [RFC6890] is not large enough for many design and documentation 79 requirements. No additional documentation prefix(es) were allocated 80 in the most recent IPv6 Specification [RFC8200]. 82 These are example use cases that require a documentation IPv6 prefix 83 larger than a /32: 85 * Ability to document network architectures (including addressing 86 plans) larger than a /32 (Service Providers, Enterprise, 87 Government, IoT, Energy), 89 * Ability to document mergers and acquisitions designs for large 90 networks (multiple /32 prefix space or larger, plus networks with 91 multiple ASNs), 93 * Reduction of operational impacts by having sufficiently large IPv6 94 prefixes dedicated for documenting and sharing designs and best 95 practices, 97 * Ability to depict unique IPv6 prefix identification (simple visual 98 representation to identify separate networks) 100 The following existing criteria are beneficially extended to the 101 additional documentation prefixes: 103 * Filters are already commonly in use to block the existing 104 documentation prefix from the Internet. 106 * There are no operational impacts to IANA or the RIRs with 107 documentation prefix space. 109 2. Requirements Language 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 113 "OPTIONAL" in this document are to are to be interpreted as described 114 in BCP 14 [RFC2119] when, and only when, they appear in all capitals, 115 as shown here. 117 3. Documentation IPv6 Address Prefixes 119 The additional IPv6 address prefixes allocated for documentation 120 purposes are 3ffe::/16 (formerly 6bone - [RFC3701]) and fec0::/10 121 (formerly site-local - [RFC3879]), resulting in the following 122 prefixes for use in documentation: 124 * fec0::/10 126 * 3ffe::/16 128 * 2001:db8::/32 - existing as defined in [RFC3879] 130 4. Operational Implications 132 The addition of IPv6 address prefixes for documentation implies that 133 IPv6 network operators should add these address prefixes to their 134 lists of non-routable/bogon IPv6 address space. If packet filters 135 are deployed in live networks, these address prefixes should be added 136 to those filters intended to prevent any public routing of such 137 address space. 139 Because the 3ffe::/16 address prefix was previously used for the 140 subsequently decommissioned 6bone network, this address prefix is 141 included in many existing non-routable prefix filters and lists. Its 142 precedence value per [RFC6724] is 1, which limits its usability in 143 production networks. In addition, the 3ffe::/16 address prefix was 144 returned to IANA and is available to be reserved for documentation 145 purposes. 147 Similarly the fec0::/10 address prefix was previously used for site- 148 local addressing, and thus is already included in many non-routable 149 prefix filters and lists. Its precedence value per [RFC6724] is 1, 150 which limits its usability in production networks. In addition, the 151 fec0::/10 address prefix was returned to IANA and is available to be 152 reserved for documentation purposes. 154 As a documentation prefix, the former site-local scope of fec0::/10 155 is considered deprecated and filters may be required and used with 156 any scope. 158 5. IANA Considerations 160 These documentation prefixes have limited impact on IANA and no 161 impact on any RIRs. 163 IANA is to record the allocation of the IPv6 global unicast address 164 prefix 3ffe::/16 and fec0::/10 as documentation-only prefixes in the 165 IPv6 address registry. No end-user or service provider/LIR is to be 166 assigned these addresses. 168 6. Security Considerations 170 IPv6 addressing documentation has no direct impact on Internet 171 security. 173 However, the assignment of a new address space for documentation 174 purposes does mean, as indicated above, that these addresses SHOULD 175 be added to any filters required by individual operators to prevent 176 their use for globally routed destinations. 178 7. Acknowledgements 180 The authors acknowledge the work of Geoff Huston, assisted by Anne 181 Lord, and Philip Smith, in authoring the previous proposal for the 182 IPv6 documentation prefix. 184 8. References 186 8.1. Normative References 188 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 189 Requirement Levels", BCP 14, RFC 2119, 190 DOI 10.17487/RFC2119, March 1997, 191 . 193 [RFC3701] Fink, R. and R. Hinden, "6bone (IPv6 Testing Address 194 Allocation) Phaseout", RFC 3701, DOI 10.17487/RFC3701, 195 March 2004, . 197 [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local 198 Addresses", RFC 3879, DOI 10.17487/RFC3879, September 199 2004, . 201 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 202 (IPv6) Specification", STD 86, RFC 8200, 203 DOI 10.17487/RFC8200, July 2017, 204 . 206 8.2. Informative References 208 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 209 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 210 2006, . 212 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 213 "Default Address Selection for Internet Protocol Version 6 214 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 215 . 217 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 218 "Special-Purpose IP Address Registries", BCP 153, 219 RFC 6890, DOI 10.17487/RFC6890, April 2013, 220 . 222 Authors' Addresses 224 Ed Horley 225 HexaBuild 227 Email: ed@hexabuild.io 229 Tom Coffeen 230 HexaBuild 232 Email: tom@hexabuild.io 233 Scott Hogg 234 HexaBuild 236 Email: scott@hexabuild.io 238 Nick Buraglio 239 Energy Sciences Network 241 Email: buraglio@es.net 243 Chris Cummings 244 Energy Sciences Network 246 Email: chriscummings@es.net 248 Kevin Myers 249 IP ArchiTechs 251 Email: kevin.myers@iparchitechs.com 253 Russ White 254 Juniper Networks 256 Email: russ@riw.us