RFC 4773

RFC 4773 📜✨ Administration of the IANA Special Purpose IPv6 Address Block

Bestie, the header first! 🎀 This is RFC 4773, written by Geoff Huston of APNIC and dated December 2006. It's Informational 🦋, so it's guidance for the community and not an Internet standard. The header doesn't list any "Obsoletes" or "Updates" lines, so it doesn't replace or change any other RFC. 💅

Status of This Memo 🌸

This memo gives information 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 IETF Trust (2006).

Abstract ✨

This is a direction to IANA about how to manage the IANA Special Purpose IPv6 address assignment registry. 👑

1. Introduction 🧚

Okay so this section just repeats the Abstract, lol. It's a direction to IANA about how to manage the IANA Special Purpose IPv6 address assignment registry. 💖

2. IANA IPv6 Special Purpose Address Block 🍓

[RFC2928] is the one that handed the IPv6 address prefix over to IANA. The reasoning behind that was:

"The block of Sub-TLA IDs assigned to the IANA (i.e., 2001: 0000::/29 - 2001:01F8::/29) is for assignment for testing and experimental usage to support activities such as the 6bone, and for new approaches like exchanges." [RFC2928]

So this address allocation was meant for testing and experiments, obsessed 😭. For the bigger picture on what IANA does with address allocation, check [RFC2860]:

"4.3. [...] Note that [...] (b) assignments of specialised address blocks (such as multicast or anycast blocks), and (c) experimental assignments are not considered to be policy issues, and shall remain subject to the provisions of this Section 4. (For purposes of this MOU, the term "assignments" includes allocations.)" [RFC2860]

The "section 4" in that quote points to the general technical work IANA does:

"4.1. The IANA will assign and register Internet protocol parameters only as directed by the criteria and procedures specified in RFCs, including Proposed, Draft, and full Internet Standards and Best Current Practice documents, and any other RFC that calls for IANA assignment." [RFC2860]

This document tells IANA to designate special purpose address blocks, as long as that falls under the direct assignments IANA already makes. Those assignments follow the criteria in RFC 2928. 🦋

It also tells IANA to open a Special Purpose IPv6 address registry to manage those designated blocks. The special purpose registrations that go in there include addresses for experiments, as described in [RFC2928], and other special purpose cases documented in IESG-reviewed published RFCs, following the rules in section 4.1 of [RFC2860]. 🌈

3. IANA Considerations 🔥

IANA keeps an "IANA IPv6 Address Special Purpose Registry" 📋. It records the current address designations IANA has made from the IANA-managed Special Purpose IPv6 address pool.

This recommendation is about managing the address pool the IETF gave to IANA in July 1999 through [RFC2928], which is 2001:0000::/23. Following the policies in [RFC2434], any further assignments of address space to IANA, for designating more prefixes for the purposes listed here, shall only happen through an IETF Consensus action. Those directions for augmenting the IANA-managed special purpose address pool should, in the normal course of things, be consistent with the current IANA IPv6 address management policies [IPv6-Policies]. 🫶

IANA may designate IPv6 addresses for special purposes when an IESG-reviewed RFC asks for it in its "IANA Considerations" section. That covers an address block with a planned use for testing or experiments started by the IETF, or for specialised use in a context (like anycast) tied to an Internet Standards track protocol. 💅

For every current address designation IANA makes, the IANA IPv6 Special Purpose Address Registry records:

1. The designated address prefix. 🌸
2. The RFC that asked for the IANA address designation. 📜
3. The date the designation was made. 🗓️
4. The date the use designation is to be terminated, if it was specified as a limited-use designation. ⏳
5. The nature of the purpose of the designated address, for example unicast experiment or protocol service anycast. 🧪
6. For experimental unicast applications, and otherwise as appropriate, the registry will also identify the entity to whom the address designation was made, along with related contact details. 📇
7. The registry will also note, for each designation, the intended routing scope of the address. That says whether the address is meant to be routable only in scoped, local, or private contexts, or whether the address prefix is meant to be routed globally. 🌍
8. The date in the IANA registry is the date of the IANA action, meaning the day IANA records the allocation. 📅

The registry also has a general heads-up: address prefixes listed in the Special Purpose Address Registry are not guaranteed routability in any particular local or global context. So don't assume they'll route everywhere, bestie 🙈.

IANA will not maintain any further sub-registries for a special purpose address block designated under this direction. 💀

4. Security Considerations 🔐

This part is serious, so buckle up 😭. Security of the Internet's routing system depends on being able to authenticate a claim of unique control over an address block. The ways to authenticate those claims rely on checking that the address block is part of an existing allocated address block, and that there's a trustworthy and unique reference in the IANA address registries.

The proposed registry is meant to be an authoritative source for the current status and intended purpose of special use IPv6 address blocks designated from the IANA-administered Special Use registry. This is a small step toward building a comprehensive registry framework that can be used as a trust point for starting a chain of address validation. Consideration should be given to IANA registry publication formats that are machine parseable. Consideration should also be given to file signatures and associated certificate mechanisms, so applications can confirm that the registry contents are current and that IANA published them. 🛡️✨

5. Acknowledgements 🎀

This document was prepared with help from Leslie Daigle, Brian Haberman, Bob Hinden, David Kessens, Kurt Lindqvist, Thomas Narten, and Paul Wilson. Thank you, queens 👑💖.

6. Informative References 📚

• [IPv6-Policies] IANA, "IPv6 Allocation and Assignment Policy", June 2002.
• [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
• [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority", RFC 2860, June 2000.
• [RFC2928] Hinden, R., Deering, S., Fink, R., and T. Hain, "Initial IPv6 Sub-TLA ID Assignments", RFC 2928, September 2000.

Author's Address 🧚‍♀️

Geoff Huston Asia Pacific Network Information Centre

EMail: gih@apnic.net URI: http://www.apnic.net

Full Copyright Statement ©️

Copyright (C) The IETF Trust (2006).

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, THE IETF TRUST, 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 on whether any Intellectual Property Rights or other rights that someone might claim for the technology in this document are valid or in scope. It also doesn't say whether any license under those rights is or isn't available. It also doesn't claim to have made any independent effort to find such rights. Information on the procedures for 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 get a general license or permission for implementers or users to use those proprietary rights, can be found in 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 needed to implement this standard. Send that information to the IETF at ietf-ipr@ietf.org. 💌

Acknowledgement 💖

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