RFC 5737

RFC 5737 🦋 IPv4 Address Blocks Reserved for Documentation

okay bestie, the title block tea ☕💅 this is RFC 5737, called IPv4 Address Blocks Reserved for Documentation 💖

• Authors: J. Arkko (Ericsson), plus M. Cotton and L. Vegoda (both ICANN) 🧚
• Category: Informational (so it's a "for your info" doc, not a standards track thing) 🌸
• ISSN: 2070-1721
• Date: January 2010 ⭐
• Updates: RFC 1166 💜
• Obsoletes: nothing is listed 🎀

Abstract ✨

okay so the abstract is giving very simple energy 🫶 three IPv4 unicast address blocks get reserved for examples in specs and other docs. this doc explains how those blocks are meant to be used 💅

---

Status of This Memo 📜

this one's not on the Internet Standards Track, it's published just for info 🌈

it's an IETF product 💖 it represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the full tea 🍓

for the current status, errata, and where to send feedback, look at http://www.rfc-editor.org/info/rfc5737 🦋

Copyright Notice 💌

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. 🌸

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. read those carefully, they spell out your rights and restrictions for this doc 🧾 code components pulled out of this doc must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty as described in the Simplified BSD License 🫶

---

1. Introduction ✨

okay so this doc describes three IPv4 address blocks that are set aside for documentation 💖 using reserved ranges for docs and examples means less chance of conflicts and confusion with addresses that were assigned for some other purpose 🦋

[RFC1166] already reserved the first of the three blocks, 192.0.2.0/24. the other two were allocated more recently, mainly to make it easier to write examples that involve addresses from multiple networks 🌈

the IETF has defined other documentation ranges too, like the IPv6 documentation prefix [RFC3849] and the example domain names [RFC2606]. docs also use the ranges reserved in [RFC1918] 🎀

2. Terminology 📖

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be read as described in BCP 14, [RFC2119] 🧚

3. Documentation Address Blocks 🌸

the blocks 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2), and 203.0.113.0/24 (TEST-NET-3) are provided for use in documentation 💜

4. Operational Implications ⚠️

this section is important, bestie 😭 it's the one with the SHOULDs

addresses inside TEST-NET-1, TEST-NET-2, and TEST-NET-3 SHOULD NOT appear on the public Internet. they get used with no coordination with IANA or any Internet registry [RFC2050] 💀 network operators SHOULD add these blocks to their list of non-routeable address spaces, and if packet filters are deployed, this address block SHOULD be added to those packet filters 🔥

these blocks aren't for local use, and the filters may be used in both local and public contexts 🦋

5. The Status of 128.66.0.0/16 🍓

okay side quest: 128.66.0.0/16 got used for some examples in the past 🙈 BUT it wasn't on the list of special prefixes in [RFC3330] or its successors, so it isn't reserved for any special purpose. it can be used for regular address assignments, just with caution 💅

6. Security Considerations 🔒

this document has no security implications 💖

7. IANA Considerations 🧚

IANA has recorded the allocation of the three address blocks in the IPv4 address registry 🌈 no end party is to be assigned these addresses ⭐

8. References 📚

8.1. Normative References

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

8.2. Informative References

[RFC1166]  Kirkpatrick, S., Stahl, M., and M. Recker, "Internet
           numbers", RFC 1166, July 1990.

[RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
           E. Lear, "Address Allocation for Private Internets",
           BCP 5, RFC 1918, February 1996.

[RFC2050]  Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D., and
           J. Postel, "INTERNET REGISTRY IP ALLOCATION GUIDELINES",
           BCP 12, RFC 2050, November 1996.

[RFC2606]  Eastlake, D. and A. Panitz, "Reserved Top Level DNS
           Names", BCP 32, RFC 2606, June 1999.

[RFC3330]  IANA, "Special-Use IPv4 Addresses", RFC 3330,
           September 2002.

[RFC3849]  Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
           Reserved for Documentation", RFC 3849, July 2004.

---

Appendix A. Acknowledgments 🫶

the authors want to give a special thank-you to APNIC, which nominated 198.51.100.0/24 and 203.0.113.0/24 for this purpose 🌸 they also say this doc inherits material from [RFC3849] 💜

they'd also like to thank Geoff Huston, Peter Koch, Ulf Olsson, John Klensin, and others for the interesting discussions on this topic 🧚✨

Authors' Addresses 💌

Jari Arkko
Ericsson
Jorvas  02420
Finland

EMail: jari.arkko@piuha.net


Michelle Cotton
Internet Corporation for Assigned Names and Numbers
4676 Admiralty Way, Suite 330
Marina del Rey  90292
United States of America

Phone: +1-310-823-9358
EMail: michelle.cotton@icann.org
URI:   http://www.iana.org/


Leo Vegoda
Internet Corporation for Assigned Names and Numbers
4676 Admiralty Way, Suite 330
Marina del Rey  90292
United States of America

Phone: +1-310-823-9358
EMail: leo.vegoda@icann.org
URI:   http://www.iana.org/