idnits 2.17.1 draft-iana-ipv4-examples-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? -- The draft header indicates that this document updates RFC1166, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC1166, updated by this document, for RFC5378 checks: 1990-07-01) -- 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.) -- The document date (September 21, 2009) is 5324 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2050 (Obsoleted by RFC 7020) -- Obsolete informational reference (is this intentional?): RFC 3330 (Obsoleted by RFC 5735) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Arkko 3 Internet-Draft Ericsson 4 Updates: 1166 (if approved) M. Cotton 5 Intended status: Informational L. Vegoda 6 Expires: March 25, 2010 ICANN 7 September 21, 2009 9 IPv4 Address Blocks Reserved for Documentation 10 draft-iana-ipv4-examples-02 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on March 25, 2010. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 Three IPv4 unicast address blocks are reserved for use in examples in 49 specifications and other documents. This document describes the use 50 of these blocks. 52 1. Introduction 54 This document describes three IPv4 address blocks that are provided 55 for use in documentation. The use of designated address ranges for 56 documentation and examples reduces the likelihood of conflicts and 57 confusion arising from the use of addresses assigned for some other 58 purpose. 60 [RFC1166] reserves the first of the three address blocks, 61 192.0.2.0/24. The other two address blocks have recently been 62 allocated for this purpose, primarily to ease the writing of examples 63 involving addresses from multiple networks. 65 Other documentation ranges have been defined in the IETF, including 66 the IPv6 documentation prefix [RFC3849] and example domain names 67 [RFC2606]. Documentation also makes use of the ranges reserved in 68 [RFC1918]. 70 2. Terminology 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in BCP 14, [RFC2119]. 76 3. Documentation Address Blocks 78 The blocks 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2), 79 and 203.0.113.0/24 (TEST-NET-3) are provided for use in 80 documentation. 82 4. Operational Implications 84 Addresses within the TEST-NET-1, TEST-NET-2, and TEST-NET-3 blocks 85 SHOULD NOT appear on the public Internet and are used without any 86 coordination with IANA or an Internet registry [RFC2050]. Network 87 operators SHOULD add these address blocks to the list of non- 88 routeable address space, and if packet filters are deployed, then 89 this address block SHOULD be added to packet filters. 91 These blocks are not for local use, and the filters may be used in 92 both local and public contexts. 94 5. The Status of 128.66.0.0/16 96 Note that 128.66.0.0/16 has been used for some examples in the past. 97 However, this block did not appear in the list of special prefixes in 98 [RFC3330] or its successors, and the block is therefore not reserved 99 for any special purpose. The block can be used for regular address 100 assignments with caution. 102 6. Security Considerations 104 This document has no security implications. 106 7. IANA Considerations 108 IANA should record the allocation of the three address blocks in the 109 IPv4 address registry. No end party is to be assigned these 110 addresses. 112 8. References 114 8.1. Normative References 116 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 117 Requirement Levels", BCP 14, RFC 2119, March 1997. 119 8.2. Informative References 121 [RFC1166] Kirkpatrick, S., Stahl, M., and M. Recker, "Internet 122 numbers", RFC 1166, July 1990. 124 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 125 E. Lear, "Address Allocation for Private Internets", 126 BCP 5, RFC 1918, February 1996. 128 [RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D., and 129 J. Postel, "INTERNET REGISTRY IP ALLOCATION GUIDELINES", 130 BCP 12, RFC 2050, November 1996. 132 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 133 Names", BCP 32, RFC 2606, June 1999. 135 [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, 136 September 2002. 138 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 139 Reserved for Documentation", RFC 3849, July 2004. 141 Appendix A. Acknowledgments 143 The authors would like to offer a special note of thanks to APNIC, 144 which nominated 198.51.100.0/24 and 203.0.113.0/24 for this purpose. 145 The authors would also like to acknowledge that this document 146 inherits material from [RFC3849]. 148 The authors would also like to thank Geoff Huston, Peter Koch, Ulf 149 Olsson, John Klensin and others for interesting discussions of this 150 topic. 152 Authors' Addresses 154 Jari Arkko 155 Ericsson 156 Jorvas 02420 157 Finland 159 Email: jari.arkko@piuha.net 161 Michelle Cotton 162 Internet Corporation for Assigned Names and Numbers 163 4676 Admiralty Way, Suite 330 164 Marina del Rey 90292 165 United States of America 167 Phone: +310-823-9358 168 Email: michelle.cotton@icann.org 169 URI: http://www.iana.org/ 171 Leo Vegoda 172 Internet Corporation for Assigned Names and Numbers 173 4676 Admiralty Way, Suite 330 174 Marina del Rey 90292 175 United States of America 177 Phone: +310-823-9358 178 Email: leo.vegoda@icann.org 179 URI: http://www.iana.org/