[要約] RFC 7608は、IPv6の転送におけるプレフィックス長の推奨事項を提供しています。その目的は、IPv6ネットワークの効率的な運用とスケーラビリティの向上を促進することです。
Internet Engineering Task Force (IETF) M. Boucadair
Request for Comments: 7608 France Telecom
BCP: 198 A. Petrescu
Category: Best Current Practice CEA, LIST
ISSN: 2070-1721 F. Baker
Cisco Systems
July 2015
IPv6 Prefix Length Recommendation for Forwarding
転送のためのIPv6プレフィックス長の推奨事項
Abstract
概要
IPv6 prefix length, as in IPv4, is a parameter conveyed and used in IPv6 routing and forwarding processes in accordance with the Classless Inter-domain Routing (CIDR) architecture. The length of an IPv6 prefix may be any number from zero to 128, although subnets using stateless address autoconfiguration (SLAAC) for address allocation conventionally use a /64 prefix. Hardware and software implementations of routing and forwarding should therefore impose no rules on prefix length, but implement longest-match-first on prefixes of any valid length.
IPv4の場合と同様に、IPv6プレフィックス長は、クラスレスドメイン間ルーティング（CIDR）アーキテクチャーに従ってIPv6ルーティングおよび転送プロセスで伝達および使用されるパラメーターです。 IPv6プレフィックスの長さは、0〜128の任意の数値にすることができますが、アドレス割り当てにステートレスアドレス自動構成（SLAAC）を使用するサブネットは、従来/ 64プレフィックスを使用します。したがって、ルーティングと転送のハードウェアとソフトウェアの実装は、プレフィックス長にルールを課さないでください。有効な長さのプレフィックスに最長一致を最初に実装してください。
Status of This Memo
本文書の状態
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 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 BCPの詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7608.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7608で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Recommendation . . . . . . . . . . . . . . . . . . . . . . . 3
3. Security Considerations . . . . . . . . . . . . . . . . . . . 4
4. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Normative References . . . . . . . . . . . . . . . . . . 4
4.2. Informative References . . . . . . . . . . . . . . . . . 4
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
Discussions on the 64-bit boundary in IPv6 addressing ([RFC7421]) revealed a need for a clear recommendation on which bits must be used by forwarding decision-making processes. However, such a recommendation was out of scope for that document.
IPv6アドレッシングの64ビット境界に関する議論（[RFC7421]）により、意思決定プロセスの転送にどのビットを使用する必要があるかについて明確な推奨が必要であることが明らかになりました。ただし、そのような推奨事項はそのドキュメントの範囲外でした。
Although Section 2.5 of [RFC4291] states "IPv6 unicast addresses are aggregatable with prefixes of arbitrary bit-length, similar to IPv4 addresses under Classless Inter-Domain Routing" (CIDR, [RFC4632]), there is still a misinterpretation that IPv6 prefixes can be either /127 ([RFC6164]) or any length up to /64. This misinterpretation is mainly induced by the 64-bit boundary in IPv6 addressing.
[RFC4291]のセクション2.5には、「IPv6ユニキャストアドレスは、クラスレスドメイン間ルーティングのIPv4アドレスと同様に、任意のビット長のプレフィックスを使用して集約できる」（CIDR、[RFC4632]）とありますが、IPv6プレフィックスが可能であるという誤解があります/ 127（[RFC6164]）または/ 64までの任意の長さ。この誤解釈は、主にIPv6アドレッシングの64ビット境界によって引き起こされます。
As discussed in [RFC7421], "the notion of a /64 boundary in the address was introduced after the initial design of IPv6, following a period when it was expected to be at /80". This evolution of the IPv6 addressing architecture, resulting in [RFC4291], and followed with the addition of /127 prefixes for point-to-point links, clearly demonstrates the intent for future IPv6 developments to have the flexibility to change this part of the architecture when justified.
[RFC7421]で説明されているように、「アドレスの/ 64境界の概念は、IPv6の初期設計の後に導入され、/ 80であると予想されていた期間に続きました」。 IPv6アドレッシングアーキテクチャのこの進化は、[RFC4291]をもたらし、ポイントツーポイントリンクに/ 127プレフィックスが追加され、アーキテクチャのこの部分を変更する柔軟性を持つ将来のIPv6開発の意図を明確に示しています。正当化されるとき。
It is fundamental not to link routing and forwarding to the IPv6 prefix/address semantics [RFC4291]. This document includes a recommendation in order to support that goal.
ルーティングと転送をIPv6プレフィックス/アドレスセマンティクスにリンクしないことが基本です[RFC4291]。このドキュメントには、その目標をサポートするための推奨事項が含まれています。
Forwarding decisions rely on the longest-match-first algorithm, which stipulates that, given a choice between two prefixes in the Forwarding Information Base (FIB) of different length that match the destination address in each bit up to their respective lengths, the longer prefix is used. This document's recommendation (Section 2) is that IPv6 forwarding must follow the longest-match-first rule, regardless of prefix length, unless some overriding policy is configured.
転送の決定は、最長一致優先アルゴリズムに依存します。このアルゴリズムでは、転送情報ベース（FIB）内の2つのプレフィックスの間で、それぞれの長さまでの各ビットの宛先アドレスと一致する異なる長さのプレフィックスから選択すると、長いプレフィックスが使用されます。使用されている。このドキュメントの推奨事項（セクション2）は、一部のオーバーライドポリシーが構成されていない限り、プレフィックスの長さに関係なく、IPv6転送は最長一致優先ルールに従う必要があることです。
This recommendation does not conflict with the 64-bit boundary for some schemes that based on IPv6 stateless address autoconfiguration (SLAAC) [RFC4862], such as [RFC2464]. Indeed, [RFC7421] clarifies this is only a parameter in the SLAAC process, and other longer prefix lengths are in operational use (e.g., either manually configured or based upon DHCPv6 [RFC3315]).
この推奨事項は、[RFC2464]など、IPv6ステートレスアドレス自動構成（SLAAC）[RFC4862]に基づく一部のスキームの64ビット境界と競合しません。実際、[RFC7421]は、これがSLAACプロセスのパラメータにすぎないこと、および他の長いプレフィックス長が運用に使用されていることを明確にします（たとえば、手動で構成するか、DHCPv6 [RFC3315]に基づいて）。
A historical background of CIDR is documented in [RFC1380] and Section 2 of [RFC4632].
CIDRの歴史的背景は、[RFC1380]と[RFC4632]のセクション2に記載されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
IPv6 implementations MUST conform to the rules specified in Section 5.1 of [RFC4632].
IPv6実装は、[RFC4632]のセクション5.1で指定されたルールに準拠する必要があります。
Decision-making processes for forwarding MUST NOT restrict the length of IPv6 prefixes by design. In particular, forwarding processes MUST be designed to process prefixes of any length up to /128, by increments of 1.
転送の意思決定プロセスは、意図的にIPv6プレフィックスの長さを制限してはなりません。特に、転送プロセスは、/ 128までの任意の長さのプレフィックスを1ずつ増加するように設計する必要があります。
Policies can be enforced to restrict the length of IP prefixes advertised within a given domain or in a given interconnection link. These policies are deployment specific and/or driven by administrative (interconnection) considerations.
ポリシーを適用して、特定のドメイン内または特定の相互接続リンクでアドバタイズされるIPプレフィックスの長さを制限できます。これらのポリシーは展開固有であり、管理（相互接続）の考慮事項によって推進されます。
This document does not introduce security issues in addition to what is discussed in [RFC4291].
このドキュメントでは、[RFC4291]で説明されていることに加えて、セキュリティの問題を紹介していません。
IPv6 security issues, including operational ones, are discussed in [RFC4942] and [OPSEC-v6].
運用上の問題を含むIPv6のセキュリティ問題は、[RFC4942]と[OPSEC-v6]で説明されています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレッシングアーキテクチャ」、RFC 4291、DOI 10.17487 / RFC4291、2006年2月、<http://www.rfc-editor.org/info/rfc4291>。
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 2006, <http://www.rfc-editor.org/info/rfc4632>.
[RFC4632] Fuller、V。およびT. Li、「Classless Inter-domain Routing（CIDR）：the Internet Address Assignment and Aggregation Plan」、BCP 122、RFC 4632、DOI 10.17487 / RFC4632、2006年8月、<http：// www.rfc-editor.org/info/rfc4632>。
[OPSEC-v6] Chittimaneni, K., Kaeo, M., and E. Vyncke, "Operational Security Considerations for IPv6 Networks", Work in Progress, draft-ietf-opsec-v6-06, March 2015.
[OPSEC-v6] Chittimaneni、K.、Kaeo、M。、およびE. Vyncke、「IPv6ネットワークの運用上のセキュリティの考慮事項」、作業中、draft-ietf-opsec-v6-06、2015年3月。
[RFC1380] Gross, P. and P. Almquist, "IESG Deliberations on Routing and Addressing", RFC 1380, DOI 10.17487/RFC1380, November 1992, <http://www.rfc-editor.org/info/rfc1380>.
[RFC1380] Gross、P。およびP. Almquist、「ルーティングとアドレッシングに関するIESG審議」、RFC 1380、DOI 10.17487 / RFC1380、1992年11月、<http://www.rfc-editor.org/info/rfc1380>。
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, <http://www.rfc-editor.org/info/rfc2464>.
[RFC2464] Crawford、M。、「Transmission of IPv6 Packets over Ethernet Networks」、RFC 2464、DOI 10.17487 / RFC2464、1998年12月、<http://www.rfc-editor.org/info/rfc2464>。
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3315] Droms、R.、Ed。、Bound、J.、Volz、B.、Lemon、T.、Perkins、C.、and M. Carney、 "Dynamic Host Configuration Protocol for IPv6（DHCPv6）"、RFC 3315 、DOI 10.17487 / RFC3315、2003年7月、<http://www.rfc-editor.org/info/rfc3315>。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, <http://www.rfc-editor.org/info/rfc4862>.
[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、DOI 10.17487 / RFC4862、2007年9月、<http://www.rfc-editor.org/info / rfc4862>。
[RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ Co-existence Security Considerations", RFC 4942, DOI 10.17487/RFC4942, September 2007, <http://www.rfc-editor.org/info/rfc4942>.
[RFC4942] Davies、E.、Krishnan、S。、およびP. Savola、「IPv6移行/共存セキュリティの考慮事項」、RFC 4942、DOI 10.17487 / RFC4942、2007年9月、<http：//www.rfc-editor .org / info / rfc4942>。
[RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter-Router Links", RFC 6164, DOI 10.17487/RFC6164, April 2011, <http://www.rfc-editor.org/info/rfc6164>.
[RFC6164]河野雅人、ニッサン、B。、ブッシュ、R。、松崎、Y。、コリティ、L。、およびT.ナルテン、「ルーター間リンクでの127ビットIPv6プレフィックスの使用」、RFC 6164 DOI 10.17487 / RFC6164、2011年4月、<http://www.rfc-editor.org/info/rfc6164>。
[RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S., Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit Boundary in IPv6 Addressing", RFC 7421, DOI 10.17487/RFC7421, January 2015, <http://www.rfc-editor.org/info/rfc7421>.
[RFC7421] Carpenter、B.、Ed。、Chown、T.、Gont、F.、Jiang、S.、Petrescu、A。、およびA. Yourtchenko、「IPv6アドレッシングにおける64ビット境界の分析」、RFC 7421、DOI 10.17487 / RFC7421、2015年1月、<http://www.rfc-editor.org/info/rfc7421>。
Acknowledgements
謝辞
Thanks to Eric Vyncke, Christian Jacquenet, Brian Carpenter, Fernando Gont, Tatuya Jinmei, Lorenzo Colitti, Ross Chandler, David Farmer, David Black, and Barry Leiba for their contributions and comments.
エリックヴィンケ、クリスチャンジャケネット、ブライアンカーペンター、フェルナンドゴン、タトゥヤジンメイ、ロレンゾコリッティ、ロスチャンドラー、デビッドファーマー、デビッドブラック、バリーレイバの貢献とコメントに感謝します。
Special thanks to Randy Bush for his support.
Randy Bushのサポートに特に感謝します。
Authors' Addresses
著者のアドレス
Mohamed Boucadair France Telecom Rennes 35000 France
Mohamed Boucadair France Telecom Rennes 35000 France
Email: mohamed.boucadair@orange.com
Alexandre Petrescu CEA, LIST CEA Saclay Gif-sur-Yvette, Ile-de-France 91190 France
アレクサンドルペトレスクCEA、リストCEAサクレジフシュルイヴェット、イルドフランス91190フランス
Phone: +33169089223
Email: alexandre.petrescu@cea.fr
Fred Baker Cisco Systems Santa Barbara, California 93117 United States
Fred Baker Cisco Systemsサンタバーバラ、カリフォルニア93117アメリカ合衆国
Email: fred@cisco.com