RFC 9812

Clarification of IPv6 Address Allocation Policy

📅 published October 2025, from ietf

RFC 9812: Clarification of IPv6 Address Allocation Policy 💖

  • RFC number: 9812 🎀
  • BCP number: 242
  • Title: Clarification of IPv6 Address Allocation Policy
  • Authors: B. Carpenter (University of Auckland), S. Krishnan (Cisco), D. Farmer (University of Minnesota)
  • Category: Best Current Practice
  • Date: October 2025
  • ISSN: 2070-1721
  • Updates: RFC 7249
  • Obsoletes: none listed

Abstract ✨

okay so this doc is all about who gets to approve changes to the "IPv6 Address Space" registry 🧚 It also updates RFC 7249, so that's a whole vibe.

Status of This Memo 💅

This memo is a Best Current Practice (BCP) from the Internet Engineering Task Force (IETF). It's the community's consensus, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication. If you want more on BCPs, check Section 2 of RFC 7841.

For the latest status, errata, or a way to send feedback, go to https://www.rfc-editor.org/info/rfc9812.

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

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Read these carefully, because they spell out what you can and can't do with the document. Code Components pulled out of this document must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Revised BSD License describes.

Table of Contents 🌈

1.  Introduction
2.  Approval Level of IPv6 Address Allocations
3.  IANA Considerations
4.  Security Considerations
5.  References
  5.1.  Normative References
  5.2.  Informative References
Acknowledgements
Authors' Addresses

1. Introduction 🦋

okay so IPv6 and its address space are defined by [STD86] and [RFC4291]. IANA took on managing that address space because of [RFC1881], which happened years before the IETF and IANA formalized their relationship in [RFC2860]. Registry details were then clarified in [RFC7020] and [RFC7249].

Sometimes IPv6 address space gets allocated outside the normal routine allocations to Regional Internet Registries (RIRs). For example, a big allocation was requested by an IETF document approved by the IESG [RFC9602], which moved the range 5f00::/16 from the "IPv6 Address Space" registry [IANA1] to the "IPv6 Special-Purpose Address Space" registry [IANA3]. 😭

When this was written, the "IPv6 Address Space" registry [IANA1] listed its allocation policy as "IESG approval." That's way too lowkey for major allocations, which need a stricter policy. So this document raises the approval level for non-routine address allocations, and that means updating [RFC7249].

This doc also clarifies the status of [RFC1881]. It was a joint publication of the IAB and IESG that followed an IETF Last Call, but the RFC index at the time incorrectly listed it as "Legacy." It's actually part of the IETF Stream [RFC8729], so we're fixing that too. 🙈

2. Approval Level of IPv6 Address Allocations 💜

Some parts of the IPv6 address space show up in the registry as "Reserved by IETF" [IANA1]. This is the space kept in reserve for future use, in case the 125-bit unicast space (2000::/3) ever turns out to be inadequate or inappropriate.

[RFC1881] didn't specify an allocation policy for this space. At some point IANA listed "IESG approval" instead. [BCP26] describes that as a pretty weak requirement. It says that although the request doesn't have to be documented in an RFC, the IESG can choose to request documents, and it calls this a fall-back mechanism for when none of the other allowable approval mechanisms can be used.

Honestly, for something as important as most of the spare IPv6 address space, that process is clearly not enough. This document swaps "IESG approval" out for the "IETF Review" process defined in [BCP26]. The stricter "Standards Action" policy isn't considered necessary, because opening up a new range of address space doesn't always require a new protocol standard. 🧠

It's worth noting that the allocation for [RFC9602], which went through as a working group document, did follow the stricter "IETF Review" process this document proposes. The other two related registries [IANA2] and [IANA3] also cite the "IETF Review" policy, which matches [RFC7249].

So this document extends the first paragraph of Section 2.3 of [RFC7249] like this:

OLD:

|  The vast bulk of the IPv6 address space (approximately 7/8ths of
|  the whole address space) is reserved by the IETF [RFC4291], with
|  the expectation that further assignment of globally unique unicast
|  address space will be made from this reserved space in accordance
|  with future needs.

NEW:

|  The vast bulk of the IPv6 address space (approximately 7/8ths of
|  the whole address space) is reserved by the IETF [RFC4291], with
|  the expectation that further assignment of globally unique unicast
|  address space will be made from this reserved space in accordance
|  with future needs, through "IETF Review" as defined in [BCP26].

3. IANA Considerations 🎀

IANA has updated the registration procedure of the "IPv6 Address Space" registry [IANA1] to "IETF Review." ✨

4. Security Considerations 🛡️

The security considerations of [RFC7249] apply here. This doc doesn't have a direct security impact by itself, but carefully reviewed address allocation mechanisms are needed to keep operational address accountability intact. 💀

5. References 🌸

5.1. Normative References

[BCP26]    Best Current Practice 26,
           <https://www.rfc-editor.org/info/bcp26>.
           At the time of writing, this BCP comprises the following:

           Cotton, M., Leiba, B., and T. Narten, "Guidelines for
           Writing an IANA Considerations Section in RFCs", BCP 26,
           RFC 8126, DOI 10.17487/RFC8126, June 2017,
           <https://www.rfc-editor.org/info/rfc8126>.

[RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
           Architecture", RFC 4291, DOI 10.17487/RFC4291, February
           2006, <https://www.rfc-editor.org/info/rfc4291>.

[STD86]    Internet Standard 86,
           <https://www.rfc-editor.org/info/std86>.
           At the time of writing, this STD comprises the following:

           Deering, S. and R. Hinden, "Internet Protocol, Version 6
           (IPv6) Specification", STD 86, RFC 8200,
           DOI 10.17487/RFC8200, July 2017,
           <https://www.rfc-editor.org/info/rfc8200>.

5.2. Informative References

[IANA1]    IANA, "IPv6 Address Space",
           <https://www.iana.org/assignments/ipv6-address-space>.

[IANA2]    IANA, "IPv6 Global Unicast Address Space",
           <https://www.iana.org/assignments/ipv6-unicast-address-
           assignments>.

[IANA3]    IANA, "IPv6 Special-Purpose Address Space",
           <https://www.iana.org/assignments/iana-ipv6-special-
           registry>.

[RFC1881]  IAB and IESG, "IPv6 Address Allocation Management",
           RFC 1881, DOI 10.17487/RFC1881, December 1995,
           <https://www.rfc-editor.org/info/rfc1881>.

[RFC2860]  Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
           Understanding Concerning the Technical Work of the
           Internet Assigned Numbers Authority", RFC 2860,
           DOI 10.17487/RFC2860, June 2000,
           <https://www.rfc-editor.org/info/rfc2860>.

[RFC7020]  Housley, R., Curran, J., Huston, G., and D. Conrad, "The
           Internet Numbers Registry System", RFC 7020,
           DOI 10.17487/RFC7020, August 2013,
           <https://www.rfc-editor.org/info/rfc7020>.

[RFC7249]  Housley, R., "Internet Numbers Registries", RFC 7249,
           DOI 10.17487/RFC7249, May 2014,
           <https://www.rfc-editor.org/info/rfc7249>.

[RFC8729]  Housley, R., Ed. and L. Daigle, Ed., "The RFC Series and
           RFC Editor", RFC 8729, DOI 10.17487/RFC8729, February
           2020, <https://www.rfc-editor.org/info/rfc8729>.

[RFC9602]  Krishnan, S., "Segment Routing over IPv6 (SRv6) Segment
           Identifiers in the IPv6 Addressing Architecture",
           RFC 9602, DOI 10.17487/RFC9602, October 2024,
           <https://www.rfc-editor.org/info/rfc9602>.

Acknowledgements 🫶

Useful comments came from Dale Carder, Bob Hinden, Scott Kelly, Philipp Tiesel, and others. Thank you all, you're the real MVPs 👑

Authors' Addresses 💌

Brian E. Carpenter
The University of Auckland
School of Computer Science
PB 92019
Auckland 1142
New Zealand
Email: brian.e.carpenter@gmail.com

Suresh Krishnan
Cisco Systems, Inc.
Email: suresh.krishnan@gmail.com

David E. Farmer III
University of Minnesota
Office of Information Technology
Minneapolis, MN 55455
United States of America
Email: farmer@umn.edu
📦 where this page comes from