[要約] RFC 6164は、ルータ間リンクで127ビットのIPv6プレフィックスを使用するためのガイドラインです。その目的は、IPv6アドレスの効率的な利用と、ルータ間リンクのアドレス割り当ての一貫性を確保することです。
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
インタールーターリンクで127ビットIPv6プレフィックスを使用します
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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形式で構築される必要があることを指定します。さらに、ノードがリンク上のルーターのセットのいずれかと通信する必要があるアプリケーションに使用することを目的としたサブネットルーターAnycastアドレスを定義します。
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ビットの接頭辞を使用していますが、これはサブネットルーターのANYCAST [RFC3627]との競合のために落胆しています。ただし、64ビットのプレフィックスを使用すると、ルーター間リンクで特に問題があるセキュリティの問題が発生し、特に /127で64ビットより長い接頭辞を使用する他の正当な理由があります（セクション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.
このドキュメントは、オペレーターがルーター間のポイントツーポイントリンクに特定のアドレスを割り当て、リンクローカルアドレスに依存しない場合に適用できます。多くのオペレーターは、ネットワーク監視、Tracerouteおよびその他の管理ツールの逆DNS解像度、外部ボーダーゲートウェイプロトコル（EBGP）[RFC4271]ピアリングセッションなどの目的で特定のアドレスを割り当てます。
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]は、サブネットルーターのAnycastアドレスとの競合により、127ビットプレフィックスの長さの使用を妨げ、ポイントツーポイントリンクのサブネットルーターAnycastのユーティリティは疑わしいと述べています。
[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.
ネットワークオペレーターは、間隔間ポイントツーポイントリンクに64、特に127を超える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より短いプレフィックスの長さを備えたポイントツーポイントリンクで発生する場合があります。これは、隣接する光学ネットワークなどの媒体を使用する隣接発見を実行するインターフェイスに影響しませんが、ポイントツーポイントリンクに影響します。（ソネット）、隣人の発見を使用しないでください。結果として、これらのリンクで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.
Ping-Pongの問題は、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].
A /64サブネットが割り当てられている2つのルーターAとBの間のイーサネットリンクを考えてみましょう。/64のアドレスに送信されたパケット（AとBのアドレスを除く）により、ルーターはそれを転送しようとして、不完全な状態に新しいキャッシュエントリを作成し、リンクに近隣勧誘メッセージを送信し、再送信タイマーを開始します、など[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つ、サブネットルーターのAnycast用に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よりもIPv4よりも重要ではありませんが、一部の演算子は個々のポイントツーポイントリンクに /64を割り当てないことを好みます。代わりに、単一 /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のプレフィックスが使用されている場合、プレフィックスのサブネットルーターAnycastを無効にする必要があります。
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のプレフィックスを割り当てて使用する場合、次の考慮事項が適用されます。一部のアドレスには特別な意味があります。特に、予約されたAnyCastアドレスに対応するアドレスがあります。プレフィックス（およびアドレス）をリンクに割り当てる場合、そのような目的のために予約されたアドレスが不注意に割り当てられ、ユニキャストアドレスとして使用されないように注意する必要があります。それ以外の場合、ノードは、受信することを意図していないパケットを受信する場合があります。具体的には、サブネットとの衝突を避けるために、右端の64ビットのすべてのゼロを右端のすべてのゼロを使用して、単一のプレフィックスから多くのポイントツーポイントリンクが番号が付けられると仮定すると、（a）64ビットのすべてのゼロが割り当てられてはなりません。-Router Anycastアドレス[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：FF7FからFFFF：FFFF：FFFF：FFFF）をユニキャストアドレスとして使用してください。]。
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
Pekka Savola、pekkas@netcore.fi
Remi Despres, remi.despres@free.fr
Remi despres、remi.despres@free.fr
Seiichi Kawamura, kawamucho@mesh.ad.jp
川amura、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.
著者は、ロン・ボニャ、プラモド・スリニバサン、オリビエ・ヴォートリン、ヨシダとヨシダ、ウォーレン・クマリ、タツヤ・ジンメイの有益なインプットに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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. Deering、「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.、Simpson、W。、およびH. Soliman、「IPバージョン6（IPv6）の近隣発見」、RFC 4861、2007年9月。
[RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast Addresses", RFC 2526, March 1999.
[RFC2526] Johnson、D。およびS. Deering、「予約済みのIPv6サブネットAnycastアドレス」、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.、White、R.、Fuller、V。、およびD. McPherson、「IPv4ポイントツーポイントリンクで31ビットプレフィックスを使用」、RFC 3021、2000年12月。
[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.、Ed。、Kempf、J。、およびE. Nordmark、「IPv6 Neighbor Discovery（ND）Trust Models and Threats」、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.、Ed。、Li、T.、ed。、およびS. Hares、ed。、「A Border Gateway Protocol 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] Conta、A.、Deering、S。、およびM. Gupta、ed。、「インターネットプロトコルバージョン6（IPv6）仕様のインターネット制御メッセージプロトコル（ICMPV6）、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] van de Velde、G.、Popoviciu、C.、Chown、T.、Bonness、O.、およびC. Hahn、「IPv6 Unicastアドレスの割り当ての考慮事項」、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
ミヤ・コノ・ジュニパーネットワーク、キオ大学シンジュクパークタワー、3-7-1ニシシンジュク島ju-ku、東京163-1035日本
EMail: mkohno@juniper.net
Becca Nitzan Juniper Networks 1194 North Mathilda Avenue Sunnyvale, CA 94089 USA
Becca Nitzan Juniper Networks 1194 North Mathilda Avenue Sunnyvale、CA 94089 USA
EMail: nitzan@juniper.net
Randy Bush
Internet Initiative Japan
5147 Crystal Springs
Bainbridge Island, WA 98110
USA
EMail: randy@psg.com
Yoshinobu Matsuzaki Internet Initiative Japan Jinbocho Mitsui Building 1-105 Kanda Jinbo-cho, Tokyo 101-0051 Japan
吉野松崎インターネットイニシアチブジャパンジンボチョ・ミツイビル1-105カンダジンボチョ、東京101-0051日本
EMail: maz@iij.ad.jp
Lorenzo Colitti Google 1600 Amphitheatre Parkway Mountain View, CA 94043 USA
Lorenzo Colitti Google 1600 Amphitheater Parkway Mountain View、CA 94043 USA
EMail: lorenzo@google.com
Thomas Narten IBM Corporation 3039 Cornwallis Ave. PO Box 12195 Research Triangle Park, NC 27709-2195 USA
Thomas Narten IBM Corporation 3039 Cornwallis Ave. PO Box 12195 Research Triangle Park、NC 27709-2195 USA
EMail: narten@us.ibm.com