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
                                                               T. Narten
                                                         IBM Corporation
                                                              April 2011
           Using 127-Bit IPv6 Prefixes on Inter-Router Links



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.


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


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 ( 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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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
1. Introduction
1. はじめに

[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.


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プレフィックスがポイントツーポイントリンクとして使用するように構成されたルータ間のリンク上で使用することができる方法を指定した理由を再評価します。

2. Scope of This Memo

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.


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.


The recommendations in this document do not apply to the link-local address scope.


3. Conventions Used in This Document

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]に記載されているように解釈されます。

4. Problems Identified with 127-Bit Prefix Lengths in the Past

[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.


[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].


Though the analyses in the RFCs are correct, operational experience with IPv6 has shown that /127 prefixes can be used successfully.


5. Reasons for Using Longer Prefixes

There are reasons network operators use IPv6 prefix lengths greater than 64, particularly 127, for inter-router point-to-point links.


5.1. Ping-Pong Issue
5.1. ピンポン問題

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.


5.2. Neighbor Cache Exhaustion Issue
5.2. 近隣キャッシュの枯渇問題

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.


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.


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サブネットを割り当てると、それを完全に排除します。

5.3. Other Reasons
5.3. その他の理由

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 /少数の外の彼らのポイントツーポイントリンクのすべてに番号をすることができるかもしれません。

6. Recommendations

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].


7. Security Considerations

This document does not have inherent security considerations. It does discuss security-related issues and proposes a solution to them.


8. Contributors

Chris Morrow,


Pekka Savola,


Remi Despres,


Seiichi Kawamura,

せいいち かわむら、 かわむちょ@めsh。あd。jp

9. Acknowledgments

The authors would like to thank Ron Bonica, Pramod Srinivasan, Olivier Vautrin, Tomoya Yoshida, Warren Kumari, and Tatsuya Jinmei for their helpful inputs.


10. References
10.1. Normative References
10.1. 引用規格

[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月。

10.2. Informative References
10.2. 参考文献

[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

みや こhの じゅにぺr ねとぉrks、 けいお うにゔぇrしty しんじゅく ぱrk とうぇr、 3ー7ー1 にししんじゅく しんじゅくーく、 ときょ 163ー1035 じゃぱん



Becca Nitzan Juniper Networks 1194 North Mathilda Avenue Sunnyvale, CA 94089 USA

ベッカNitzanジュニパーネットワークスの1194北マチルダアベニューサニーベール、CA 94089 USA



Randy Bush Internet Initiative Japan 5147 Crystal Springs Bainbridge Island, WA 98110 USA

ランディブッシュインターネットイニシアティブ5147クリスタルスプリングスベインブリッジ島、ワシントン州98110 USA



Yoshinobu Matsuzaki Internet Initiative Japan Jinbocho Mitsui Building 1-105 Kanda Jinbo-cho, Tokyo 101-0051 Japan

よしのぶ まつざき いんてrねt いにちあちゔぇ じゃぱん じんぼちょ みつい ぶいlぢんg 1ー105 かんだ じんぼーちょ、 ときょ 101ー0051 じゃぱん



Lorenzo Colitti Google 1600 Amphitheatre Parkway Mountain View, CA 94043 USA

ロレンツォColitti Googleの1600アンフィシアターパークウェイマウンテンビュー、CA 94043 USA



Thomas Narten IBM Corporation 3039 Cornwallis Ave. PO Box 12195 Research Triangle Park, NC 27709-2195 USA

トーマスNarten氏IBMコーポレーション3039コーンウォリスアベニュー。私書箱12195リサーチトライアングルパーク、ノースカロライナ州27709から2195 USA