idnits 2.17.1 draft-moreiras-v6ops-rfc3849bis-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3849]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The abstract seems to indicate that this document updates RFC3849, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 21, 2013) is 3840 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-13) exists of draft-ietf-softwire-map-08 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force A. Moreiras 3 Internet-Draft E. Cordeiro 4 Intended status: Best Current Practice R. Santos 5 Expires: April 24, 2014 NIC.br 6 A. Servin 7 LACNIC 8 A. Acosta 9 Universidad Nueva Esparta 10 October 21, 2013 12 IPv6 Address Prefixes Reserved for Documentation 13 draft-moreiras-v6ops-rfc3849bis-01 15 Abstract 17 [RFC3849] specified an IPv6 prefix to be used in documentation, in 18 order to reduce the likelihood of conflict and confusion when 19 relating examples of deployed systems. This prefix was reserved to 20 be used in examples in RFCs, books, documentation, and the like. It 21 became widely accepted and used. 23 Although the IPv6 documentation prefix proved to be very useful, a / 24 32 prefix is not enough to be used to document some kinds of IPv6 25 deployments, such as large ISP deployments, transition techniques, 26 and other useful examples that require longer prefixes. This 27 document defines the allocation of a new global unicast (GUA) block 28 and a new unique local (ULA) block, to expand the range of 29 documentation blocks. It also updates [RFC3849]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on April 24, 2014. 48 Copyright Notice 50 Copyright (c) 2013 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 68 3.1. Didactic Usage . . . . . . . . . . . . . . . . . . . . . 3 69 3.2. Test Networks . . . . . . . . . . . . . . . . . . . . . . 4 70 3.3. Visual Identification and Address Filtering . . . . . . . 4 71 4. IPv6 Documentation Prefixes . . . . . . . . . . . . . . . . . 4 72 5. Operational Implications . . . . . . . . . . . . . . . . . . 4 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 77 8.2. Informative References . . . . . . . . . . . . . . . . . 5 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 80 1. Introduction 82 This document describes the IPv6 address blocks provided to be used 83 in documentation. These blocks SHOULD be used to describe network 84 topologies, transition techniques or other systems, in RFCs, books, 85 videos, and documentation in general. They also MAY be used in 86 didactic laboratories, which aim to teach IPv6 or network principles. 88 The first block was reserved in [RFC3849], from the address space of 89 the Asia Pacific (APNIC) regional addressing community. Other 90 documentation ranges have been defined in the IETF, such as example 91 domain names described in [RFC2606], and IPv4 documentation-only 92 address blocks described in [RFC5737]. The IPv4 ranges reserved in 93 [RFC1918] for private use are also used in documentation, as well as 94 the Autonomous System numbers reserved in [RFC6996]. 96 Although the address block defined in [RFC3849] was within the range 97 of a conventional allocation size for an Internet Service Provider, 98 and it was expected that it could accurately match deployment 99 scenarios, there are some situations that can't be represented 100 accordingly with a prefix of 32 bits, such as: transition techniques, 101 peering between multiple ISPs, IPv6 address plan for multi-regional 102 ISPs, and others. 104 This situation leads to the same problem that [RFC3849] tried to 105 address. Some documentation material, particularly some didactic 106 material and laboratories, today is using IPv6 prefixes drawn from 107 address blocks already allocated or assigned. A similar situation 108 with IPv4 addresses caused problems in production environments, 109 because of address and routing conflicts with other services. 111 This document reserves an additional larger IPv6 block for 112 documentation, avoiding such problems. It does not obsolete the 113 current IPv6 documentation block 2001:0db8::/32, since it is widely 114 deployed. Nonetheless, it updates the current practice and specifies 115 one larger IPv6 block, for the same use. 117 2. Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 3. Problem Statement 125 This document proposes a solution for the situations where the length 126 of the current documentation prefix for IPv6 (2001:db8::/32) is not 127 enough to represent some addressing scenarios and also proposes a 128 specific documentation block for ULA. 130 3.1. Didactic Usage 132 In some didactic laboratories and materials, people are using other 133 prefixes from Global Address space when they need networks bigger 134 than /32. For example, if you have a lab setup where each group 135 represents an Autonomous System (AS) the ideal situation is that each 136 group receives a block of the same size of the smallest allocation, 137 it means a /32 for each group. A typical scenery is to have 8 to 16 138 groups, each one with your own /32, that requires a /28. This 139 scenery is used by the authors of this document in IPv6 courses in 140 Latin America. 142 Some IPv6 instructors use of ULA addresses when they have to 143 represent networks bigger than /32, but it generates confusion on 144 students that are struggling to understand the differences between 145 IPv4 and IPv6. Some other instructors use non allocated or already 146 allocated prefixes and it may lead to operational problems in the 147 event of an example being inadvertently copied into a production 148 environment. 150 The same problems may occur to ULA being used for teaching purposes, 151 as the [RFC3849] does not define an ULA for documentation. 153 3.2. Test Networks 155 Some transition techniques from IPv4 to IPv6 uses the IPv4 addresses 156 embedded in the IPv6 addresses, for example, 6rd [RFC5969], 464XLAT 157 [RFC6877] and MAP-E [I-D.ietf-softwire-map]. Using only a /32 to 158 test those network may generate prefixes bigger than /64 that will 159 conflict with SLAAC mechanism, as described in [RFC6052]. 161 New protocols development may also need test networks larger than a 162 single /32, specially when making a large functional test to check 163 the new protocol behavior on a big network trying to emulate a 164 production environment. 166 3.3. Visual Identification and Address Filtering 168 It is important that the documentation blocks and addresses can be 169 easily identified, specially to avoid that those address to generate 170 problems in production networks. A simple visual identification also 171 avoid that people will use allocated or unallocated addresses to test 172 or teach IPv6, just because those addresses would be easier to 173 remember. 175 Books and documentation that includes IPv6 addresses would have a 176 standard to follow and that will serve their needs. 178 Having a large defined block for documentation will also help 179 filtering test and documentation addresses that may leak into 180 production networks. 182 4. IPv6 Documentation Prefixes 184 The blocks provided for use in documentation are: 2001:0db8::/32 (v6 185 -TEST-NET-1), UUUU:U000::/20 [Note to RFC Editor: this address range 186 is to be added before publication] (v6-TEST-NET-2) and 187 FCUU:UUUU:UUU0::/44 [Note to RFC Editor: this address range is to be 188 added before publication] (v6-TEST-NET-3). 190 5. Operational Implications 191 Addresses within the v6-TEST-NET-1, v6-TEST-NET-2 and v6-TEST-NET-3 192 SHOULD NOT appear on the public Internet and are used without any 193 coordination with IANA or an Internet Regional Registry (RIR). 194 Network operators SHOULD add these address blocks to the list of non- 195 routable address spaces, and if packet filters are deployed, then 196 this address block SHOULD be added to packet filters. 198 These blocks are not for local use, and the filters may be used in 199 both local and public contexts. 201 6. Security Considerations 203 There are no new security considerations pertaining to this document. 205 7. IANA Considerations 207 IANA recorded the allocation of the IPv6 global unicast address 208 prefix v6-TEST-NET-1 as a documentation-only prefix in the IPv6 209 address registry. 211 IANA is asked to record the allocation of v6-TEST-NET-2 prefix, 212 within the range reserved for Global IPv6 addresses, for use as an 213 additional documentation-only prefix, in the IPv6 address registry. 215 IANA is asked to record the reservation of v6-TEST-NET-3 prefix, 216 within the range reserved for Unique Local IPv6 addresses, for use as 217 an additional documentation-only prefix, in the IPv6 address 218 registry. 220 No end party is to be assigned any of these address blocks. 222 8. References 224 8.1. Normative References 226 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 227 Requirement Levels", BCP 14, RFC 2119, March 1997. 229 8.2. Informative References 231 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 232 E. Lear, "Address Allocation for Private Internets", BCP 233 5, RFC 1918, February 1996. 235 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 236 Names", BCP 32, RFC 2606, June 1999. 238 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 239 Reserved for Documentation", RFC 3849, July 2004. 241 [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks 242 Reserved for Documentation", RFC 5737, January 2010. 244 [RFC6996] Mitchell, J., "Autonomous System (AS) Reservation for 245 Private Use", BCP 6, RFC 6996, July 2013. 247 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 248 Infrastructures (6rd) -- Protocol Specification", RFC 249 5969, August 2010. 251 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 252 Combination of Stateful and Stateless Translation", RFC 253 6877, April 2013. 255 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 256 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 257 October 2010. 259 [I-D.ietf-softwire-map] 260 Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., 261 Murakami, T., and T. Taylor, "Mapping of Address and Port 262 with Encapsulation (MAP)", draft-ietf-softwire-map-08 263 (work in progress), August 2013. 265 Authors' Addresses 267 Antonio Marcos Moreiras 268 NIC.br 269 Av das Nacoes Unidas 11541 7o andar 270 Sao Paulo, SP 04578-000 271 Brazil 273 Phone: +55 11 5509 3553 274 Email: moreiras@nic.br 276 Edwin Cordeiro 277 NIC.br 278 Av das Nacoes Unidas 11541 7o andar 279 Sao Paulo, SP 04578-000 280 Brazil 282 Phone: +55 11 5509 3537 283 Email: ecordeiro@nic.br 284 Rodrigo Santos 285 NIC.br 286 Av das Nacoes Unidas 11541 7o andar 287 Sao Paulo, SP 04578-000 288 Brazil 290 Phone: +55 11 5509 3537 291 Email: rsantos@nic.br 293 Arturo Servin 294 LACNIC 295 Rambla Republica de Mexico 6125 296 Montevideo 11300 297 Uruguay 299 Phone: +598 2604 2222 300 Email: aservin@lacnic.net 302 Alejandro Acosta 303 Universidad Nueva Esparta 304 Avenida Sur 7 305 Caracas, Los Naranjos del Cafetal CP 1081 306 Venezuela 308 Email: aacosta@rocketmail.com