Internet Engineering Task Force (IETF) M. Kohno
Request for Comments: 6164 Juniper Networks, Keio University
Category: Standards Track B. Nitzan
ISSN: 2070-1721 Juniper Networks
R. Bush
Y. Matsuzaki
Internet Initiative Japan
L. Colitti
Google
T. Narten
IBM Corporation
April 2011
Using 127-Bit IPv6 Prefixes on Inter-Router Links
Abstract
抽象
On inter-router point-to-point links, it is useful, for security and other reasons, to use 127-bit IPv6 prefixes. Such a practice parallels the use of 31-bit prefixes in IPv4. This document specifies the motivation for, and usages of, 127-bit IPv6 prefix lengths on inter-router point-to-point links.
ルータ間のポイントツーポイントリンク上では、127ビットのIPv6プレフィックスを使用するために、セキュリティやその他の理由のため、便利です。そのような実施は、IPv4の31ビットプレフィックスの使用に匹敵します。このドキュメントは、のためにモチベーションを指定し、ルータ間のポイントツーポイントリンク上で、127ビットのIPv6プレフィックス長の用法。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
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 Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、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/rfc6164.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6164で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................2
2. Scope of This Memo ..............................................3
3. Conventions Used in This Document ...............................3
4. Problems Identified with 127-Bit Prefix Lengths in the Past .....3
5. Reasons for Using Longer Prefixes ...............................4
5.1. Ping-Pong Issue ............................................4
5.2. Neighbor Cache Exhaustion Issue ............................4
5.3. Other Reasons ..............................................5
6. Recommendations .................................................5
7. Security Considerations .........................................6
8. Contributors ....................................................6
9. Acknowledgments .................................................6
10. References .....................................................6
10.1. Normative References ......................................6
10.2. Informative References ....................................7
[RFC4291] specifies that interface IDs for all unicast addresses, except those that start with the binary value 000, are required to be 64 bits long and to be constructed in Modified EUI-64 format. In addition, it defines the Subnet-Router anycast address, which is intended to be used for applications where a node needs to communicate with any one of the set of routers on a link.
[RFC4291]はバイナリ値000で始まるものを除くすべてのユニキャストアドレスのインタフェースIDは、64ビット長であり、かつ変形EUI-64フォーマットに構築する必要があることを指定します。また、ノードは、リンク上のルータのセットのいずれかと通信する必要がある用途に使用されることを意図しているサブネットのルータエニーキャストアドレスを定義します。
Some operators have been using 127-bit prefixes, but this has been discouraged due to conflicts with Subnet-Router anycast [RFC3627]. However, using 64-bit prefixes creates security issues that are particularly problematic on inter-router links, and there are other valid reasons to use prefixes longer than 64 bits, in particular /127 (see Section 5).
いくつかの演算子は、127ビットのプレフィックスを使用しているが、これは、サブネットのルータエニーキャスト[RFC3627]との競合に推奨されています。しかし、64ビットのプレフィックスを使用してルータ間のリンク上で特に問題となるセキュリティ上の問題を作成し、具体的には、64ビットより長いプレフィックス/ 127（セクション5を参照）を使用する他の正当な理由があります。
This document provides a rationale for using 127-bit prefix lengths, reevaluates the reasons why doing so was considered harmful, and specifies how /127 prefixes can be used on inter-router links configured for use as point-to-point links.
この文書では、127ビットのプレフィックス長を使用するための理論的根拠を提供してやってはそれほど有害と考えられ、および/ 127プレフィックスがポイントツーポイントリンクとして使用するように構成されたルータ間のリンク上で使用することができる方法を指定した理由を再評価します。
This document is applicable to cases where operators assign specific addresses on inter-router point-to-point links and do not rely on link-local addresses. Many operators assign specific addresses for the purposes of network monitoring, reverse DNS resolution for traceroute and other management tools, External Border Gateway Protocol (EBGP) [RFC4271] peering sessions, and so on.
この文書では、事業者は、ルータ間のポイントツーポイントリンク上の特定のアドレスを割り当てると、リンクローカルアドレスに依存しない場合にも適用可能です。多くの事業者は、ネットワーク監視の目的のために特定のアドレスを割り当てトレースルートおよびその他の管理ツール、外部ボーダーゲートウェイプロトコル（EBGP）[RFC4271]ピアリングセッションなどのためのDNS解決を逆転します。
For the purposes of this document, an inter-router point-to-point link is a link to which only two routers and no hosts are attached. This may include Ethernet links that are configured to be point-to-point. Links between a router and a host, or links to which both routers and hosts are attached, are out of scope of this document.
本文書の目的のために、ルータ間のポイントツーポイントリンクは、2つだけのルータとないホストが結合しているリンクです。これは、ポイント・ツー・ポイントになるように構成されているイーサネットリンクを含んでもよいです。ルータとホストの両方が取り付けられたルータやホスト、またはリンク間のリンクは、この文書の範囲外です。
The recommendations in this document do not apply to the link-local address scope.
このドキュメントの推奨事項は、リンクローカルアドレスのスコープには適用されません。
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]に記載されているように解釈されます。
[RFC3627] discourages the use of 127-bit prefix lengths due to conflicts with the Subnet-Router anycast addresses, while stating that the utility of Subnet-Router anycast for point-to-point links is questionable.
ポイントツーポイントリンクのサブネットのルータエニーキャストの有用性は疑問であると述べている間[RFC3627]は、サブネットのルータエニーキャストアドレスとの衝突に起因する127ビットのプレフィックス長を使用することを阻止します。
[RFC5375] also says the usage of 127-bit prefix lengths is not valid and should be strongly discouraged, but the stated reason for doing this is to be in compliance with [RFC3627].
[RFC5375]も127ビットのプレフィックス長の使用が有効でないと、強くお勧めしなければならないと言いますが、これを行うために述べた理由は、[RFC3627]に準拠することです。
Though the analyses in the RFCs are correct, operational experience with IPv6 has shown that /127 prefixes can be used successfully.
RFCの中の分析が正しいものの、IPv6で運用経験は、127の接頭辞を正常に使用することができます/ことを示しています。
There are reasons network operators use IPv6 prefix lengths greater than 64, particularly 127, for inter-router point-to-point links.
ネットワークオペレータは、ルータ間のポイントツーポイントリンクのために、特に127、64を超えるIPv6プレフィックス長を使用する理由があります。
A forwarding loop may occur on a point-to-point link with a prefix length shorter than 127. This does not affect interfaces that perform Neighbor Discovery, but some point-to-point links, which use a medium such as the Synchronous Optical Network (SONET), do not use Neighbor Discovery. As a consequence, configuring any prefix length shorter than 127 bits on these links can create an attack vector in the network.
転送ループは近隣探索を実行するインターフェイスに影響を与えない127これより短いプレフィックス長とのポイントツーポイントリンク上で生じてもよいが、そのような同期光ネットワークなどの媒体を使用するいくつかのポイントツーポイントリンク、 （SONET）、近隣探索を使用しないでください。結果として、これらのリンク上の127ビットよりも短い任意のプレフィックス長を設定すると、ネットワーク内の攻撃ベクトルを作成することができます。
The ping-pong issue happens in the case of IPv4 as well. But due to the scarcity of IPv4 address space, the current practice is to assign long prefix lengths such as /30 or /31 [RFC3021] on point-to-point links; thus, the problem did not come to the fore.
ピンポンの問題は、同様のIPv4の場合に起こります。しかしによるIPv4アドレス空間の不足のために、現在の慣行は、ポイントツーポイントリンク上の長いプレフィックス長など/ 30または/ 31 [RFC3021]を割り当てることです。したがって、問題が前面に来ていません。
The latest ICMPv6 specification [RFC4443] mitigates this problem by specifying that a router receiving a packet on a point-to-point link, where the packet is destined to an address within a subnet assigned to that same link (other than one of the receiving router's own addresses), MUST NOT forward the packet back on that link. Instead, it SHOULD generate an ICMPv6 Destination Unreachable message (code 3) in response. This check is on the forwarding processing path, so it may have performance impact.
最新のICMPv6仕様[RFC4443]は、ルータがパケットを受信した以外の同じリンク（に割り当てられたサブネット内のアドレス宛てのポイントツーポイントリンク上でパケットを受信することを指定することによって、この問題を軽減しますルータ自身のアドレス）、バックそのリンク上のパケットを転送してはなりません。代わりに、応答のICMPv6宛先到達不能メッセージ（コード3）を生成する必要があります。このチェックは、転送処理経路上にあるので、パフォーマンスへの影響を有していてもよいです。
As described in Section 4.3.2 of [RFC3756], the use of a 64-bit prefix length on an inter-router link that uses Neighbor Discovery (e.g., Ethernet) potentially allows for denial-of-service attacks on the routers on the link.
[RFC3756]のセクション4.3.2に記載したように、近隣探索使用ルータ間のリンク上の64ビットのプレフィックス長を使用する（例えば、イーサネット（登録商標））は、潜在的にルータのサービス拒否攻撃を可能にしますリンク。
Consider an Ethernet link between two routers, A and B, to which a /64 subnet has been assigned. A packet sent to any address on the /64 (except the addresses of A and B) will cause the router attempting to forward it to create a new cache entry in INCOMPLETE state, send a Neighbor Solicitation message on the link, start a retransmit timer, and so on [RFC4861].
/ 64サブネットが割り当てられているには、2つのルータ、AとBとの間のイーサネットリンクを考えます。 （AとBのアドレスを除く）/ 64上の任意のアドレスに送信されたパケットは、不完全な状態で新しいキャッシュエントリを作成するために、順方向リンク上で近隣要請メッセージを送信し、再送タイマーを起動しようとするルータを引き起こします、およびので、[RFC4861]に。
By sending a continuous stream of packets to a large number of the 2^64 - 3 unassigned addresses on the link (one for each router and one for Subnet-Router anycast), an attacker can create a large number of neighbor cache entries and cause one of the routers to send a large number of Neighbor Solicitation packets that will never receive replies, thereby consuming large amounts of memory and processing resources. Sending the packets to one of the 2^24 addresses on the link that has the same Solicited-Node multicast address as one of the routers also causes the victim to spend large amounts of processing time discarding useless Neighbor Solicitation messages.
2 ^ 64の数が多いために、パケットの連続ストリームを送信することによって - リンク上の3未割り当てアドレス（各ルータ用とサブネットルータエニーキャスト用1）、攻撃者は、近隣キャッシュエントリと原因を大量に作成することができますこれにより、メモリと処理リソースを大量に消費し、応答を受信することはありません近隣要請大量のパケットを送信するためにルータの1つ。ルータの1つにも役に立たない近隣要請メッセージを破棄し、処理時間を大量に過ごすために、被害者が発生するのと同じ要請ノードマルチキャストアドレスを持つリンク上で2 ^ 24のアドレスのいずれかにパケットを送信します。
Careful implementation and rate-limiting can limit the impact of such an attack, but are unlikely to neutralize it completely. Rate-limiting Neighbor Solicitation messages will reduce CPU usage, and following the garbage-collection recommendations in [RFC4861] will maintain reachability, but if the link is down and neighbor cache entries have expired while the attack is ongoing, legitimate traffic (for example, BGP sessions) over the link might never be re-established, because the routers cannot resolve each others' IPv6 addresses to link-layer addresses.
注意深い実装と律速このような攻撃の影響を制限することができるが、それを完全に中和しにくいです。レート制限CPUの使用量を削減する近隣要請メッセージを、および到達可能性を維持します[RFC4861]でガベージコレクションの推奨事項に従うが、リンクがダウンしているとあれば、攻撃が進行中である間、近隣キャッシュエントリの期限が切れている、正当なトラフィック（例えば、ルータはリンク層アドレスにお互いのIPv6アドレスを解決できないため、リンク上でBGPセッション）は、再確立することはありませんかもしれません。
This attack is not specific to point-to-point links, but is particularly harmful in the case of point-to-point backbone links, which may carry large amounts of traffic to many destinations over long distances.
この攻撃は、ポイントツーポイントリンクに特有のものではなく、長距離で多くの宛先に大量のトラフィックを運ぶことができる、ポイントツーポイントバックボーンリンクの場合には特に有害です。
While there are a number of ways to mitigate this kind of issue, assigning /127 subnets eliminates it completely.
この種の問題を軽減するために、いくつかの方法がありますが、/ 127サブネットを割り当てると、それを完全に排除します。
Though address space conservation considerations are less important for IPv6 than they are in IPv4, some operators prefer not to assign /64s to individual point-to-point links. Instead, they may be able to number all of their point-to-point links out of a single /64 or a small number of /64s.
アドレス空間の保全の考慮事項は、彼らがIPv4であるよりも、IPv6にそれほど重要あるが、一部の事業者は、個々のポイントツーポイントリンクへ/ 64Sを割り当てることがないことを好みます。代わりに、彼らは、単一/ 64または64S /少数の外の彼らのポイントツーポイントリンクのすべてに番号をすることができるかもしれません。
Routers MUST support the assignment of /127 prefixes on point-to-point inter-router links. Routers MUST disable Subnet-Router anycast for the prefix when /127 prefixes are used.
ルータはの/ポイント・ツー・ポイントのルータ間のリンク上の127のプレフィックスの割り当てをサポートしなければなりません。 / 127接頭辞が使用される場合、ルータは、プレフィクスのサブネット・ルータのエニーキャストを無効にする必要があります。
When assigning and using any /127 prefixes, the following considerations apply. Some addresses have special meanings, in particular addresses corresponding to reserved anycast addresses. When assigning prefixes (and addresses) to links, care should be taken to ensure that addresses reserved for such purposes aren't inadvertently assigned and used as unicast addresses. Otherwise, nodes may receive packets that they are not intended to receive. Specifically, assuming that a number of point-to-point links will be numbered out of a single /64 prefix: (a) Addresses with all zeros in the rightmost 64 bits SHOULD NOT be assigned as unicast addresses, to avoid colliding with the Subnet-Router anycast address [RFC4291].
割り当て、任意/ 127接頭辞を使用する場合、以下の考慮事項が当てはまります。いくつかのアドレスは、予約エニーキャストアドレスに対応する特定のアドレスに、特別な意味を持っています。リンクのプレフィックス（及びアドレス）を割り当てる場合、注意は、このような目的のために予約アドレスが誤って割り当てられたユニキャストアドレスとして使用されないように注意すべきです。そうでない場合、ノードは、それらが受信することを意図していないパケットを受信することができます。 （a）は、右端の64ビットですべてゼロとアドレスは、サブネットとの衝突を回避するために、ユニキャストアドレスとして割り当てられるべきではない。具体的には、ポイントツーポイントリンクの数は、単一の/ 64プレフィックスのうちの番号付けされると仮定すると-routerエニーキャストアドレス[RFC4291]。
(b) Addresses in which the rightmost 64 bits are assigned the highest 128 values (i.e., ffff:ffff:ffff:ff7f to ffff:ffff:ffff: ffff) SHOULD NOT be used as unicast addresses, to avoid colliding with reserved subnet anycast addresses [RFC2526].
（b）の右端64ビットは、最高128個の値を割り当てられたアドレス（すなわち、FFFF：FFFF：FFFF：FFFFにff7f：FFFF：FFFF：FFFF）は、予約サブネットエニーキャストとの衝突を回避するために、ユニキャストアドレスとして使用しないでくださいアドレス[RFC2526]。
This document does not have inherent security considerations. It does discuss security-related issues and proposes a solution to them.
この文書では、固有のセキュリティ上の考慮事項はありません。これは、セキュリティ関連の問題を議論し、それらの解決策を提案しています。
Chris Morrow, morrowc@google.com
クリス・モロー、morrowc@google.com
Pekka Savola, pekkas@netcore.fi
ペッカSavola、pekkas@netcore.fi
Remi Despres, remi.despres@free.fr
レミ・デプレ、remi.despres@free.fr
Seiichi Kawamura, kawamucho@mesh.ad.jp
せいいち かわむら、 かわむちょ＠めｓｈ。あｄ。ｊｐ
The authors would like to thank Ron Bonica, Pramod Srinivasan, Olivier Vautrin, Tomoya Yoshida, Warren Kumari, and Tatsuya Jinmei for their helpful inputs.
作者は彼らの役に立つの入力のためにロンBonica、Pramodさんスリニバサン、オリヴィエVautrin、智也吉田、ウォーレン・クマリ、と達也神明に感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 4291、2006年2月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861] Narten氏、T.、Nordmarkと、E.、シンプソン、W.、およびH.ソリマン、 "IPバージョン6（IPv6）のための近隣探索"、RFC 4861、2007年9月。
[RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast Addresses", RFC 2526, March 1999.
[RFC2526]ジョンソン、D.とS.デアリング、 "予約済みのIPv6サブネットエニーキャストアドレス"、RFC 2526、1999年3月。
[RFC3021] Retana, A., White, R., Fuller, V., and D. McPherson, "Using 31-Bit Prefixes on IPv4 Point-to-Point Links", RFC 3021, December 2000.
[RFC3021] Retana、A.、ホワイト、R.、フラー、V.、および、RFC 3021、2000年12月、 "IPv4のポイントツーポイントリンク上で31ビットのプレフィックスを使用する" D.マクファーソン、。
[RFC3627] Savola, P., "Use of /127 Prefix Length Between Routers Considered Harmful", RFC 3627, September 2003.
[RFC3627] Savola、P.、 "有害と考えられルータ間の使用の/ 127プレフィックス長"、RFC 3627、2003年9月。
[RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[RFC3756] Nikander、P。、編、ケンプ、J.、およびE. Nordmarkと、 "IPv6近隣探索（ND）信頼モデルと脅威"、RFC 3756、2004年5月。
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271] Rekhter、Y.、エド。、李、T.、エド。、およびS.野兎、編、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 4271、2006年1月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443]コンタ、A.、デアリング、S.、およびM.グプタ、エド。、 "インターネット制御メッセージプロトコル（ICMPv6の）インターネットプロトコルバージョン6（IPv6）の仕様について"、RFC 4443、2006年3月。
[RFC5375] Van de Velde, G., Popoviciu, C., Chown, T., Bonness, O., and C. Hahn, "IPv6 Unicast Address Assignment Considerations", RFC 5375, December 2008.
[RFC5375]ヴァン・デ・ヴェルデ、G.、Popoviciu、C.、CHOWN、T.、Bonness、O.、及びC.ハーン、 "IPv6ユニキャストアドレスの割り当てに関する考慮事項"、RFC 5375、2008年12月。
Authors' Addresses
著者のアドレス
Miya Kohno Juniper Networks, Keio University Shinjuku Park Tower, 3-7-1 Nishishinjuku Shinjuku-ku, Tokyo 163-1035 Japan
みや こｈの じゅにぺｒ ねとぉｒｋｓ、 けいお うにゔぇｒしｔｙ しんじゅく ぱｒｋ とうぇｒ、 ３ー７ー１ にししんじゅく しんじゅくーく、 ときょ １６３ー１０３５ じゃぱん
EMail: mkohno@juniper.net
メールアドレス：mkohno@juniper.net
Becca Nitzan Juniper Networks 1194 North Mathilda Avenue Sunnyvale, CA 94089 USA
ベッカNitzanジュニパーネットワークスの1194北マチルダアベニューサニーベール、CA 94089 USA
EMail: nitzan@juniper.net
メールアドレス：nitzan@juniper.net
Randy Bush Internet Initiative Japan 5147 Crystal Springs Bainbridge Island, WA 98110 USA
ランディブッシュインターネットイニシアティブ5147クリスタルスプリングスベインブリッジ島、ワシントン州98110 USA
EMail: randy@psg.com
メールアドレス：randy@psg.com
Yoshinobu Matsuzaki Internet Initiative Japan Jinbocho Mitsui Building 1-105 Kanda Jinbo-cho, Tokyo 101-0051 Japan
よしのぶ まつざき いんてｒねｔ いにちあちゔぇ じゃぱん じんぼちょ みつい ぶいｌぢんｇ １ー１０５ かんだ じんぼーちょ、 ときょ １０１ー００５１ じゃぱん
EMail: maz@iij.ad.jp
メールアドレス：maz@iij.ad.jp
Lorenzo Colitti Google 1600 Amphitheatre Parkway Mountain View, CA 94043 USA
ロレンツォColitti Googleの1600アンフィシアターパークウェイマウンテンビュー、CA 94043 USA
EMail: lorenzo@google.com
メールアドレス：lorenzo@google.com
Thomas Narten IBM Corporation 3039 Cornwallis Ave. PO Box 12195 Research Triangle Park, NC 27709-2195 USA
トーマスNarten氏IBMコーポレーション3039コーンウォリスアベニュー。私書箱12195リサーチトライアングルパーク、ノースカロライナ州27709から2195 USA
EMail: narten@us.ibm.com
メールアドレス：narten@us.ibm.com