Internet Engineering Task Force (IETF) B. Carpenter
BCP: 242 Univ. of Auckland
Request for Comments: 9812 S. Krishnan
Updates: 7249 Cisco
Category: Best Current Practice D. Farmer
ISSN: 2070-1721 Univ. of Minnesota
October 2025
This document specifies the approval process for changes to the "IPv6 Address Space" registry. It also updates RFC 7249.
この文書は、「IPv6 アドレス空間」レジストリへの変更の承認プロセスを規定します。また、RFC 7249 も更新されます。
This memo documents an Internet Best Current Practice.
このメモは、インターネットの現在のベスト プラクティスを文書化したものです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 7841.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。BCP の詳細については、RFC 7841 のセクション 2 を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9812.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9812 で入手できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2025 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
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
Internet Protocol Version 6 (IPv6) and its address space are defined by [STD86] and [RFC4291]. The management of the IPv6 address space was delegated to IANA by [RFC1881], some years before the relationship between the IETF and IANA was formalized [RFC2860] and registry details were clarified [RFC7020] [RFC7249].
インターネット プロトコル バージョン 6 (IPv6) とそのアドレス空間は [STD86] と [RFC4291] によって定義されています。IPv6 アドレス空間の管理は、IETF と IANA の関係が正式に [RFC2860] され、レジストリの詳細が明確になる [RFC7020] [RFC7249] の数年前に、[RFC1881] によって IANA に委任されました。
Occasionally, IPv6 address space allocations are performed outside the scope of routine allocations to Regional Internet Registries (RIRs). For example, a substantial 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].
場合によっては、IPv6 アドレス空間の割り当てが、地域インターネット レジストリ (RIR) への日常的な割り当ての範囲外で実行されることがあります。たとえば、IESG [RFC9602] によって承認された IETF 文書によって大幅な割り当てが要求され、範囲 5f00::/16 が「IPv6 アドレス空間」レジストリ [IANA1] から「IPv6 特別目的アドレス空間」レジストリ [IANA3] に移動されました。
At the time of writing, the allocation policy in the "IPv6 Address Space" registry [IANA1] was shown as "IESG approval", whereas a more stringent policy is appropriate for major allocations. The present document therefore strengthens the approval level needed for non-routine address allocations, which requires an update to [RFC7249].
この記事の執筆時点では、「IPv6 アドレス空間」レジストリ [IANA1] の割り当てポリシーは「IESG 承認」として示されていますが、主要な割り当てにはより厳格なポリシーが適切です。したがって、この文書は、[RFC7249] への更新を必要とする非日常的なアドレス割り当てに必要な承認レベルを強化します。
This document also clarifies the status of [RFC1881]. This clarification is necessary because [RFC1881], a joint publication of the IAB and IESG following an IETF Last Call, was incorrectly listed in the RFC index at the time of writing as "Legacy", whereas it is part of the IETF Stream [RFC8729].
この文書は、[RFC1881] のステータスも明確にします。この明確化が必要なのは、IETF 最終呼び出し後の IAB と IESG の共同出版物である [RFC1881] が、IETF ストリーム [RFC8729] の一部であるにもかかわらず、執筆時点で RFC インデックスに誤って「レガシー」としてリストされていたためです。
Portions of the IPv6 address space are shown in the registry as "Reserved by IETF" [IANA1]. This is the address space held in reserve for future use if ever the 125-bit unicast space (2000::/3) is found inadequate or inappropriate.
IPv6 アドレス空間の一部は、レジストリに「IETF によって予約」[IANA1] として表示されます。これは、125 ビット ユニキャスト スペース (2000::/3) が不適切または不適切であることが判明した場合に備えて、将来の使用のために予約されているアドレス スペースです。
[RFC1881] did not specify an allocation policy for this space. At some point, IANA listed "IESG approval". As defined in [BCP26], this is a rather weak requirement ("Although there is no requirement that the request be documented in an RFC, the IESG has the discretion to request documents...") and is "a fall-back mechanism in the case where one of the other allowable approval mechanisms cannot be employed...".
[RFC1881] では、このスペースの割り当てポリシーが指定されていません。ある時点で、IANAは「IESG承認」をリストしました。[BCP26] で定義されているように、これはかなり弱い要件 (「要求を RFC に文書化するという要件はないが、IESG には文書を要求する裁量権がある...」) であり、「他の許容される承認メカニズムの 1 つが使用できない場合の代替メカニズム...」です。
For something as important as the majority of the spare IPv6 address space, this process is clearly insufficient. The present document replaces the "IESG approval" process by the "IETF Review" process as defined by [BCP26]. The stricter "Standards Action" policy is not considered necessary, because there may be cases where opening up a new range of address space does not in fact require a new protocol standard.
予備の IPv6 アドレス空間の大部分と同じくらい重要なものに対して、このプロセスでは明らかに不十分です。この文書は、[BCP26] で定義されているように、「IESG 承認」プロセスを「IETF レビュー」プロセスに置き換えます。新しいアドレス空間の範囲を開くのに実際には新しいプロトコル標準が必要ない場合があるため、より厳格な「標準化アクション」ポリシーは必要ないと考えられます。
It may be noted that the allocation for [RFC9602], which was processed as a working group document, did indeed follow the more stringent "IETF Review" process proposed by this document. Indeed, the other two related registries [IANA2] [IANA3] cite the "IETF Review" policy, consistent with [RFC7249].
ワーキンググループ文書として処理された[RFC9602]の割り当ては、実際にこの文書によって提案されたより厳格な「IETFレビュー」プロセスに従っていることに留意されたい。実際、他の 2 つの関連レジストリ [IANA2] [IANA3] は、[RFC7249] と一致する「IETF Review」ポリシーを引用しています。
This document therefore extends the first paragraph of Section 2.3 of [RFC7249] as follows:
したがって、この文書は、[RFC7249] のセクション 2.3 の最初の段落を次のように拡張します。
OLD:
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.
IPv6 アドレス空間の大部分 (アドレス空間全体の約 7/8) は IETF [RFC4291] によって予約されており、将来のニーズに応じてこの予約された空間から世界的に一意のユニキャスト アドレス空間がさらに割り当てられることが期待されています。
NEW:
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].
IPv6 アドレス空間の大部分 (アドレス空間全体の約 7/8) は IETF [RFC4291] によって予約されており、[BCP26] で定義されている「IETF Review」を通じて、将来のニーズに応じてこの予約された空間から世界的に一意のユニキャスト アドレス空間のさらなる割り当てが行われることが期待されています。
IANA has updated the registration procedure of the "IPv6 Address Space" registry [IANA1] to "IETF Review".
IANA は、「IPv6 アドレス空間」レジストリ [IANA1] の登録手順を「IETF Review」に更新しました。
The security considerations of [RFC7249] apply. While having no direct security impact, carefully reviewed address allocation mechanisms are necessary to ensure operational address accountability.
[RFC7249] のセキュリティに関する考慮事項が適用されます。セキュリティに直接的な影響はありませんが、運用上のアドレス責任を確保するには、慎重に検討されたアドレス割り当てメカニズムが必要です。
[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>.
[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>.
Useful comments were received from Dale Carder, Bob Hinden, Scott Kelly, Philipp Tiesel, and others.
Dale Carder、Bob Hinden、Scott Kelly、Philipp Tiesel などから有益なコメントをいただきました。
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