idnits 2.17.1 draft-moreiras-v6ops-rfc3849bis-00.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 (August 11, 2013) is 3882 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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 NIC.br 5 Expires: February 12, 2014 A. Servin 6 LACNIC 7 A. Acosta 8 Universidad Nueva Esparta 9 August 11, 2013 11 IPv6 Address Prefixes Reserved for Documentation 12 draft-moreiras-v6ops-rfc3849bis-00 14 Abstract 16 [RFC3849] specified an IPv6 prefix to be used in documentation, in 17 order to reduce the likelihood of conflict and confusion when 18 relating examples of deployed systems. This prefix was reserved to 19 be used in examples in RFCs, books, documentation, and the like. It 20 became widely accepted and used. 22 Although the IPv6 documentation prefix proved to be very useful, a / 23 32 prefix is not enough to be used to document some kinds of IPv6 24 deployments, such as large ISP deployments, transition techniques, 25 and other useful examples that require longer prefixes. This 26 document requests the allocation of a new global unicast /20 block, 27 as a documentation prefix, and expands the range of uses that can be 28 expected for these prefixes. It also updates [RFC3849]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on February 12, 2014. 47 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. IPv6 Documentation Prefixes . . . . . . . . . . . . . . . . . 3 66 4. Operational Implications . . . . . . . . . . . . . . . . . . 3 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 3 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 71 7.2. Informative References . . . . . . . . . . . . . . . . . 4 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 74 1. Introduction 76 This document describes the IPv6 address blocks provided to be used 77 in documentation. These blocks SHOULD be used to describe network 78 topologies, transition techniques or other systems, in RFCs, books, 79 videos, and documentation in general. They also MAY be used in 80 didactic laboratories, which aim to teach IPv6 or network principles. 82 The first block was reserved in [RFC3849], from the address space of 83 the Asia Pacific (APNIC) regional addressing community. Other 84 documentation ranges have been defined in the IETF, such as example 85 domain names described in [RFC2606], and IPv4 documentation-only 86 address blocks described in [RFC5737]. The IPv4 ranges reserved in 87 [RFC1918] for private use are also used in documentation, as well as 88 the Autonomous System numbers reserved in [RFC6996]. 90 Although the address block defined in [RFC3849] was within the range 91 of a conventional allocation size for an Internet Service Provider, 92 and it was expected that it could accurately match deployment 93 scenarios, there are some situations that can't be represented 94 accordingly with a prefix of 32 bits, such as: transition techniques, 95 peering between multiple ISPs, IPv6 address plan for multi-regional 96 ISPs, and others. 98 This situation leads to the same problem that [RFC3849] tried to 99 address. Some documentation material, particularly some didactic 100 material and laboratories, today is using IPv6 prefixes drawn from 101 address blocks already allocated or assigned. A similar situation 102 with IPv4 addresses caused problems in production environments, 103 because of address and routing conflicts with other services. 105 This document reserves an additional larger IPv6 block for 106 documentation, avoiding such problems. It does not obsolete the 107 current IPv6 documentation block 2001:0db8::/32, since it is widely 108 deployed. Nonetheless, it updates the current practice and specifies 109 one larger IPv6 block, for the same use. 111 2. Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [RFC2119]. 117 3. IPv6 Documentation Prefixes 119 The blocks provided for use in documentation are: 2001:0db8::/32 (v6 120 -TEST-NET-1), and DDDD:D000::/20 [Note to RFC Editor: this address 121 range is to be added before publication] (v6-TEST-NET-2). 123 4. Operational Implications 125 Addresses within the v6-TEST-NET-1, and v6-TEST-NET-2, SHOULD NOT 126 appear on the public Internet and are used without any coordination 127 with IANA or an Internet Regional Registry (RIR). Network operators 128 SHOULD add these address blocks to the list of non-routeable address 129 spaces, and if packet filters are deployed, then this address block 130 SHOULD be added to packet filters. 132 These blocks are not for local use, and the filters may be used in 133 both local and public contexts. 135 5. Security Considerations 137 There are no new security considerations pertaining to this document. 139 6. IANA Considerations 141 IANA recorded the allocation of the IPv6 global unicast address 142 prefix v6-TEST-NET-1 as a documentation-only prefix in the IPv6 143 address registry. 145 IANA is asked to record the allocation of v6-TEST-NET-2 prefix, 146 within the range reserved for Global IPv6 addresses, for use as an 147 additional documentation-only prefix, in the IPv6 address registry. 149 No end party is to be assigned any of these address blocks. 151 7. References 153 7.1. Normative References 155 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 156 Requirement Levels", BCP 14, RFC 2119, March 1997. 158 7.2. Informative References 160 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 161 E. Lear, "Address Allocation for Private Internets", BCP 162 5, RFC 1918, February 1996. 164 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 165 Names", BCP 32, RFC 2606, June 1999. 167 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 168 Reserved for Documentation", RFC 3849, July 2004. 170 [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks 171 Reserved for Documentation", RFC 5737, January 2010. 173 [RFC6996] Mitchell, J., "Autonomous System (AS) Reservation for 174 Private Use", BCP 6, RFC 6996, July 2013. 176 Authors' Addresses 178 Antonio Marcos Moreiras 179 NIC.br 180 Av das Nacoes Unidas 11541 7o andar 181 Sao Paulo, SP 04578-000 182 Brazil 184 Phone: +55 11 5509 3553 185 Email: moreiras@nic.br 186 Edwin Cordeiro 187 NIC.br 188 Av das Nacoes Unidas 11541 7o andar 189 Sao Paulo, SP 04578-000 190 Brazil 192 Phone: +55 11 5509 3537 193 Email: ecordeiro@nic.br 195 Arturo Servin 196 LACNIC 197 Rambla Republica de Mexico 6125 198 Montevideo 11300 199 Uruguay 201 Phone: +598 2604 2222 202 Email: aservin@lacnic.net 204 Alejandro Acosta 205 Universidad Nueva Esparta 206 Avenida Sur 7 207 Caracas, Los Naranjos del Cafetal CP 1081 208 Venezuela 210 Email: aacosta@rocketmail.com