Internet Engineering Task Force (IETF)                         G. Huston
Request for Comments: 9637                                         APNIC
Updates: 3849                                                N. Buraglio
Category: Informational                          Energy Sciences Network
ISSN: 2070-1721                                              August 2024
        
Expanding the IPv6 Documentation Space
IPv6ドキュメントスペースの拡張
Abstract
概要

The document describes the reservation of an additional IPv6 address prefix for use in documentation. This update to RFC 3849 expands on the existing 2001:db8::/32 address block with the reservation of an additional, larger prefix. The addition of a /20 prefix allows documented examples to more closely reflect a broader range of realistic, current deployment scenarios and more closely aligns with contemporary allocation models for large networks.

ドキュメントでは、ドキュメントで使用する追加のIPv6アドレスプレフィックスの予約について説明します。RFC 3849のこのアップデートは、既存の2001:DB8 ::/32アドレスブロックで拡張され、追加の大きなプレフィックスが予約されています。A /20プレフィックスを追加することで、文書化された例が、より広範な現実的で現在の展開シナリオをより密接に反映し、大規模なネットワークの現代的な割り当てモデルとより密接に整合します。

Status of This Memo
本文書の位置付け

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。

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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.

このドキュメントは、インターネットエンジニアリングタスクフォース(IETF)の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ(IESG)からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、インターネット標準のあらゆるレベルの候補者であるわけではありません。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/rfc9637.

このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9637で取得できます。

著作権表示

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

著作権(c)2024 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ドキュメント(https://trustee.ietf.org/license-info)に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。

Table of Contents
目次
   1.  Introduction
   2.  Requirements Language
   3.  Current Assignment and Allocation Data
   4.  Filtering and Appropriate Use
   5.  Security Considerations
   6.  IANA Considerations
   7.  References
     7.1.  Normative References
     7.2.  Informative References
   Acknowledgments
   Authors' Addresses
        
1. Introduction
1. はじめに

[RFC3849] introduced the IPv6 address prefix 2001:db8::/32 as a reserved prefix for use in documentation. The rationale for this reservation was to reduce the likelihood of conflict and confusion when relating documented examples to deployed systems.

[RFC3849]は、ドキュメントで使用するための予約済みのプレフィックスとして、IPv6アドレスプレフィックス2001:DB8 ::/32を導入しました。この留保の理論的根拠は、文書化された例を展開システムに関連付ける際に、紛争と混乱の可能性を減らすことでした。

As the global deployment of IPv6 expands and evolves, individual IPv6 network deployment scenarios have also increased in size and diversity, and there is a requirement for documentation to reflect this increased diversity and scope. The original 2001:db8::/32 reservation is inadequate to describe many realistic, current deployment scenarios.

IPv6のグローバルな展開が拡大および進化するにつれて、個々のIPv6ネットワーク展開シナリオもサイズと多様性が増加しており、この多様性と範囲の増加を反映するためのドキュメントの要件があります。元の2001年:DB8 ::/32予約は、多くの現実的な現在の展開シナリオを説明するのに不十分です。

Without this additional address allocation, documentation prefixes are drawn from address blocks already allocated or assigned to existing organizations or well-known ISPs, or they are drawn from the currently unallocated address pool. Such use conflicts with existing or future allocations or assignments of IPv6 address space. The reservation of a /20 IPv6 address prefix from the Global Unicast Address pool [RFC4291] for documentation purposes allows such conflicts to be avoided.

この追加のアドレス割り当てがなければ、ドキュメントのプレフィックスは、既存の組織または有名なISPに既に割り当てられたり割り当てられているアドレスブロックから描画されます。または、現在未払いのアドレスプールから描画されます。このような使用は、IPv6アドレス空間の既存または将来の割り当てまたは割り当てとの競合を使用します。ドキュメントの目的で、グローバルユニキャストアドレスプール[RFC4291]からのA /20 IPv6アドレスのプレフィックスの予約により、このような競合を回避できます。

2. Requirements Language
2. 要件言語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。

3. Current Assignment and Allocation Data
3. 現在の割り当ておよび割り当てデータ

According to the allocation and assignment data published by the Regional Internet Registries (RIRs) (see [NROStatsReport]), in August 2023, 25.9% of the 62,770 recorded IPv6 unicast allocations and assignments were larger than a /32 in size. The most common allocation or assignment size was a /29, used in 24.8% of cases.

地域インターネットレジストリ(RIRS)が発行した割り当ておよび割り当てデータ([NROSTATSREPORT]を参照)によれば、2023年8月に、62,770のIPv6ユニキャストの割り当てと割り当ての25.9%は、サイズが /32よりも大きかった。最も一般的な割り当てまたは割り当てサイズはA /29で、24.8%のケースで使用されました。

The four largest assignments made to end users have been /19s, but these allocations were made before the RIRs moved away from the use of a fixed /48 site address prefix in IPv6 address assignment policies, and in the foreseeable future, it is unlikely that individual networks will require more than a /20. It is believed that reservation of a /20 will cover the documentation needs as they relate to the broad range of realistic network deployments.

エンドユーザーに対する4つの最大の割り当ては /19sでしたが、これらの割り当ては、RIRSがIPv6アドレスの割り当てポリシーで固定 /48サイトアドレスプレフィックスの使用から離れる前に行われました。個々のネットワークには、A /20以上が必要です。A /20の予約は、幅広い現実的なネットワーク展開に関連するドキュメントのニーズをカバーすると考えられています。

4. Filtering and Appropriate Use
4. フィルタリングと適切な使用

Documentation prefixes are for the use of relaying configuration and documentation examples, and as such, they MUST NOT be used for actual traffic, MUST NOT be globally advertised, and SHOULD NOT be used internally for routed production traffic or other connectivity. Documentation prefixes should be considered bogon [BOGON] and filtered in routing advertisements as appropriate.

ドキュメントのプレフィックスは、構成とドキュメントの例を中継するためのものであるため、実際のトラフィックに使用してはならず、グローバルに宣伝されてはならず、ルーティングされた生産トラフィックやその他の接続に内部的に使用しないでください。ドキュメントのプレフィックスは、Bogon [Bogon]と見なされ、必要に応じてルーティング広告でフィルタリングする必要があります。

5. Security Considerations
5. セキュリティに関する考慮事項

This special-use prefix should be marked as and considered bogon [BOGON]. As is appropriate with bogon prefixes, packets whose source or destination belongs to this prefix should be dropped and disallowed over the public Internet.

この特別な使用プレフィックスは、Bogon [Bogon]としてマークされ、考慮される必要があります。Bogonプレフィックスに適しているように、このプレフィックスに属しているソースまたは宛先がこのプレフィックスに属するパケットは、パブリックインターネット上でドロップして禁止する必要があります。

6. IANA Considerations
6. IANAの考慮事項

IANA has registered the following in the "IANA IPv6 Special-Purpose Address Registry" [IANA-IPv6-SPAR].

IANAは、「IANA IPv6特殊目的アドレスレジストリ」[IANA-IPV6-SPAR]で以下を登録しています。

Address Block:

アドレスブロック:

3fff::/20

3fff ::/20

Name:

名前:

Documentation

ドキュメント

RFC:

RFC:

RFC 9637

RFC 9637

Allocation Date

割り当て日

2024-07

2024-07

Termination Date:

終了日:

N/A

n/a

Source:

ソース:

False

間違い

Destination:

行き先:

False

間違い

Forwardable:

フォローダブル:

False

間違い

Globally Reachable :

グローバルに到達可能:

False

間違い

Reserved-by-Protocol:

プロトコルごとに予約済み:

False

間違い

7. References
7. 参考文献
7.1. Normative References
7.1. 引用文献
   [IANA-IPv6-SPAR]
              IANA, "IANA IPv6 Special-Purpose Address Registry",
              <https://www.iana.org/assignments/iana-ipv6-special-
              registry>.
        
   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.
        
   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
        
7.2. Informative References
7.2. 参考引用
   [BOGON]    Team Cymru, "Unravelling the Mystery of Bogons: A senior
              stakeholder and IT professional guide", July 2023,
              <https://www.team-cymru.com/post/unravelling-the-mystery-
              of-bogons-a-senior-stakeholder-and-it-professional-guide>.
        
   [NROStatsReport]
              "NRO Stats Reports",
              <https://ftp.ripe.net/pub/stats/ripencc/nro-stats>.
        
   [RFC3849]  Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
              Reserved for Documentation", RFC 3849,
              DOI 10.17487/RFC3849, July 2004,
              <https://www.rfc-editor.org/info/rfc3849>.
        
   [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>.
        
Acknowledgments
謝辞

The authors would like to acknowledge the valuable input from XiPeng Xiao, Chris Cummings, Russ White, Kevin Myers, Ed Horley, Tom Coffeen, and Scott Hogg.

著者は、Xipeng Xiao、Chris Cummings、Russ White、Kevin Myers、Ed Horley、Tom Coffeen、Scott Hoggからの貴重な意見を認めたいと考えています。

Authors' Addresses
著者のアドレス
   Geoff Huston
   APNIC
   Email: gih@apnic.net
        
   Nick Buraglio
   Energy Sciences Network
   Email: buraglio@forwardingplane.net