RFC 3849

RFC 3849: IPv6 Address Prefix Reserved for Documentation 🎀

Okay bestie, the header tea ☕: this is RFC 3849, written by Geoff Huston (Telstra), Anne Lord (APNIC), and Philip Smith (Cisco), dated July 2004. It's Informational, so it's just here to share info, not to lay down rules 💅. It doesn't list any RFCs it obsoletes or updates, so it's a standalone moment ✨.

Status of this Memo 📜

This memo is giving info to the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited 💖.

Copyright Notice

Copyright (C) The Internet Society (2004).

Abstract 🦋

Okay so, to cut down on conflicts and confusion when documented examples meet real systems, an IPv6 unicast address prefix has been reserved for examples in RFCs, books, documentation, and stuff like that 📚. Site-local and link-local unicast addresses already have special meaning in IPv6, so they can't be used in lots of example situations, which is a whole mood 😭. This document says the IPv6 address prefix 2001:DB8::/32 is reserved for documentation.

1. Introduction ✨

Bestie, the IPv6 address architecture [1] doesn't specifically set aside a prefix for documentation 🙈. So documentation has been borrowing prefixes from blocks already allocated or assigned to existing organizations or well-known ISPs, or grabbing stuff from the still-unallocated pool. That causes clashes with existing or future allocations and assignments of IPv6 address space, and it's giving chaos.

We've already seen this with IPv4. When documented examples got used literally in production environments, they caused address and routing conflicts with services that were already running 💀. By making an explicit allocation for documentation, the idea is that these operational problems can be avoided for IPv6 🌸.

Similar discussions have happened for top level domain names, and some of them have been reserved for similar purposes [2].

2. Documentation IPv6 Address Prefix 🌈

So documentation can describe deployment examples accurately, using site-local or link-local addresses isn't appropriate, and a unicast address block is needed 🙌. All IPv6 unicast address space is currently marked as reserved, unassigned, or has been assigned to the Internet Assigned Numbers Authority (IANA) for further redistribution to the Regional Internet Registries (RIRs) [1]. But no unicast address space has been specifically nominated for use in documented examples yet.

Then the Asia Pacific regional addressing community accepted a proposal for a block of IPv6 address space to be reserved for documentation purposes 🎉. After that, the Asia Pacific Network Information Centre (APNIC) allocated a unicast address prefix for documentation. The block is within the range of a conventional allocation size, so documentation can accurately match real deployment scenarios 🫶.

The documentation prefix in this memo can also be used to generate multicast addresses for documentation, using the Unicast prefix-based proposal [3]. Representing other kinds of multicast addresses in documentation is outside the scope of this memo 🦋.

The prefix allocated for documentation purposes is 2001:DB8::/32. Periodt.

3. Operational Implications 🔥

This assignment means IPv6 network operators should add this address prefix to the list of non-routeable IPv6 address space. If packet filters are deployed, this address prefix should be added to the packet filters too 🧱.

This is not a local-use address prefix, so the filters may be used in both local and public contexts. Don't skip this one, it matters 👑.

4. IANA Considerations 📋

IANA is to record the allocation of the IPv6 global unicast address prefix 2001:DB8::/32 as a documentation-only prefix in the IPv6 address registry. No end party is to be assigned this address 🚫.

5. Security Considerations 🔐

Real talk, this one's serious. IPv6 addressing documents do not have any direct impact on Internet infrastructure security 💅.

6. Acknowledgements 🫶

The authors acknowledge the work of Marc Blanchet, who authored an earlier proposal for a V6 documentation prefix, assisted by Alain Durand, Robert Elz, Bob Fink, and Dave Thaler 🌟.

7. References 📚

7.1. Normative References

• [1] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.

7.2. Informative References

• [2] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999.
• [3] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, August 2002.

Authors' Addresses 💌

Geoff Huston Telstra EMail: gih@apnic.net

Anne Lord Asia Pacific Network Information Centre EMail: anne@apnic.net

Philip Smith Cisco Systems EMail: pfs@cisco.com

Full Copyright Statement ⚖️

Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🔏

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. It also doesn't represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Acknowledgement 💖

Funding for the RFC Editor function is currently provided by the Internet Society 🌸.