[要約] 要約：RFC 3627は、ルーター間の/127プレフィックス長の使用に関する問題を指摘している。 目的：このRFCの目的は、/127プレフィックス長の使用がネットワークのパフォーマンスやセキュリティに悪影響を与える可能性があることを警告することです。
Network Working Group P. Savola
Request for Comments: 3627 CSC/FUNET
Category: Informational September 2003
Use of /127 Prefix Length Between Routers Considered Harmful
有害と見なされるルーター間の /127プレフィックスの長さの使用
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
Abstract
概要
In some cases, the operational decision may be to use IPv6 /127 prefix lengths, especially on point-to-point links between routers. Under certain situations, this may lead to one router claiming both addresses due to subnet-router anycast being implemented. This document discusses the issue and offers a couple of solutions to the problem; nevertheless, /127 should be avoided between two routers.
場合によっては、運用上の決定は、特にルーター間のポイントツーポイントリンクで、IPv6 /127プレフィックスの長さを使用することです。特定の状況では、これにより、サブネットルーターのAnycastが実装されているため、1つのルーターが両方のアドレスを主張することにつながる可能性があります。このドキュメントでは問題について説明し、問題に対するいくつかの解決策を提供します。それにもかかわらず、 /127は2つのルーター間で避ける必要があります。
[ADDRARCH] defines Subnet-router anycast address: in a subnet prefix of n bits, the last 128-n bits are all zero. It is meant to be in use of any one router in the subnet.
[addrarch]サブネットルーターのAnycastアドレスを定義します：nビットのサブネットプレフィックスでは、最後の128-Nビットはすべてゼロです。サブネットで1つのルーターを使用することを意図しています。
Even though having prefix length longer than /64 is forbidden by [ADDRARCH] section 2.4 for non-000/3 unicast prefixes, using /127 prefix length has gained a lot of operational popularity; it seems like that these prefix lengths are being used heavily in point-to-point links. The operational practise has often been to use the least amount of address space especially in the presence of a large number of point-to-point links; it may be unlikely that all of these links would start to use /64's. Using /127 has also other operational benefits: you always know which address the other end uses, and there is no "ping-pong" [PINGPONG] problem with older ICMP implementations (fixed now in [ICMPv3]).
/64より長いプレフィックスの長さを持つことは、[Addrarch]セクション2.4以外のUnicastプレフィックスのセクション2.4で禁止されていますが、 /127プレフィックスの長さを使用すると、多くの運用上の人気が獲得されています。これらのプレフィックスの長さは、ポイントツーポイントリンクで重く使用されているようです。運用慣行は、特に多数のポイントツーポイントリンクの存在下で、より少ない量のアドレススペースを使用することがよくありました。これらのリンクのすべてが /64の使用を開始する可能性は低い場合があります。/127を使用すると、他の運用上の利点もあります。もう一方の端が使用するアドレスを常に知っており、古いICMP実装に「ピンポン」[ピンポン]の問題はありません（[ICMPV3]に現在固定）。
This memo does not advocate the use of long prefixes, but brings up problems for those that do want to use them, for one reason or another.
このメモは、長いプレフィックスの使用を提唱するものではありませんが、何らかの理由でそれらを使用したい人に問題を引き起こします。
Detailed discussion on what is the "right" solution is out of the scope; it is not the goal of this memo to try to find the "best" addressing solution for everyone.
「正しい」ソリューションとは何かに関する詳細な議論は、範囲外です。このメモの目標は、すべての人に「最良の」アドレス指定ソリューションを見つけようとすることではありません。
Note that this problem does not exist between a router and a host, assuming the PREFIX::0/127 address is assigned to the router.
プレフィックス:: 0/127アドレスがルーターに割り当てられていると仮定して、ルーターとホストの間にこの問題は存在しないことに注意してください。
Using /127 can be especially harmful on a point-to-point link when Subnet-router anycast address is implemented. Consider the following sequence of events:
/127を使用すると、サブネットルーターのAnycastアドレスが実装されている場合、ポイントツーポイントリンクで特に有害になります。次の一連のイベントを検討してください。
1. Router A and Router B are connected by a point-to-point link.
1. ルーターAとルーターBは、ポイントツーポイントリンクで接続されています。
2. Neither has anything configured or set up on this link.
2. どちらもこのリンクで構成または設定されていません。
3. 3ffe:ffff::1/127 address is added to Router A; now it performs Duplicate Address Detection (DAD) [NDISC] for 3ffe:ffff::1. Router A also adds the Subnet-router anycast address 3ffe:ffff::0/127. (DAD is not performed for anycast addresses.)
3. 3ffe：ffff :: 1/127アドレスがルーターAに追加されます。これで、3ffe：ffff :: 1の重複アドレス検出（DAD）[NDISC]を実行します。ルーターAは、サブネットルーターのanycastアドレス3ffe：ffff :: 0/127も追加します。（お父さんはAnycastアドレスに対して実行されません。）
4. Now Router B has been planned and configured to use 3ffe:ffff::0/127 as its unicast IPv6 address, but adding it will fail DAD, and Router B does not have any address.
4. 現在、ルーターBは計画され、3FFE：FFFF :: 0/127をユニキャストIPv6アドレスとして使用するように構成されていますが、それを追加するとDADが失敗し、ルーターBにはアドレスがありません。
Similar scenarios also happen during router reboots, crashes and such.
同様のシナリオは、ルーターの再起動、クラッシュなどでも発生します。
The usability of subnet-router anycast address between two routers on a point-to-point link is very questionable, but it is still a mandated feature of [ADDRARCH]. Workarounds for this are presented in the next section.
ポイントツーポイントリンク上の2つのルーター間のサブネットルーターのANYCASTアドレスの使いやすさは非常に疑わしいものですが、それでも[AddRarch]の義務付けられた機能です。このための回避策は、次のセクションに示されています。
As of yet, this kind of unexpected behavior hasn't been seen at large perhaps because the Subnet-router anycast address hasn't been implemented or too widely used.
まだ、この種の予想外の動作は、サブネットルーターのAnyCastアドレスが実装されていないか、あまりにも広く使用されていないため、一般的には見られていません。
1. One could use /64 for subnets, including point-to-point links.
1. ポイントツーポイントリンクを含むサブネットに /64を使用できます。
2. One could use only link-local addresses, but that may make network maintenance and debugging impractical at least in bigger networks; for example, "traceroute" can only return a list of nodes on the path, not the links which would have been used.
2. Link-Localアドレスのみを使用できますが、少なくともより大きなネットワークでは、ネットワークメンテナンスとデバッグを非現実的にする可能性があります。たとえば、「Traceroute」は、使用されるリンクではなく、パス上のノードのリストのみを返すことができます。
3. Failing that, /126 does not have this problem, and it can be used safely on a point-to-point link (e.g., using the 2nd and the 3rd address for unicast). This is analogous to using /30 for IPv4. Using two /128 addresses is also one, though often cumbersome, approach. Naturally, not much would be lost if even a shorter prefix was used, e.g., /112 or /120.
3. それに失敗すると、 /126にはこの問題はありません。ポイントツーポイントリンクで安全に使用できます（たとえば、ユニキャストの2番目と3番目のアドレスを使用して）。これは、IPv4に /30を使用することに類似しています。2 /128のアドレスを使用することも1つですが、しばしば面倒なアプローチです。当然のことながら、短いプレフィックスでさえ使用された場合、 /112または /120を使用した場合、それほど失われません。
The author feels that if /64 cannot be used, /112, reserving the last 16 bits for node identifiers, has probably the least amount of drawbacks (also see section 3).
著者は、 /64を使用できない場合、 /112は、ノード識別子の最後の16ビットを予約することで、おそらく欠点が最も少ないと感じています（セクション3も参照）。
4. [ADDRARCH] could be revised to state that Subnet-router anycast address should not be used if the prefix length of the link is not /64 (or even longer than /120). This does not seem like a good approach, as we should avoid making assumptions about prefix lengths in the specifications, to maintain future flexibility. Also, in some cases, it might be usable to have a Subnet-router anycast address in some networks with a longer prefix length.
4. [addrarch]は、リンクのプレフィックス長が /64（またはさらに /120より長い）でない場合、サブネットルーターのAnycastアドレスを使用しないでください。これは、将来の柔軟性を維持するために、仕様のプレフィックスの長さについて仮定することを避ける必要があるため、これは良いアプローチのようには見えません。また、場合によっては、プレフィックスの長さが長いネットワークにサブネットルーターのAnycastアドレスを持つことが使用できる場合があります。
A more conservative (implementation) approach would be not using Subnet-router anycast addresses in subnets with a prefix length of /127 if there are only two routers on the link: this can be noticed with [NDISC] 'Router' bit in Neighbor Advertisement messages. However, this seems to overload the functionality of 'R' bit, so it does not look like a good approach in the long run.
より保守的な（実装）アプローチは、リンクに2つのルーターのみがある場合、 /127のプレフィックス長さのサブネットのサブネットルーターのANYCASTアドレスを使用しません。メッセージ。ただし、これは「R」ビットの機能を過負荷にしているようであるため、長期的には良いアプローチのようには見えません。
5. It's also possible to improve implementations: if /127 is used on a point-to-point link, never claim two addresses. This has the drawback that even if the router using the combined unicast and anycast address is down, the packets to subnet-router anycast address will be lost as the other cannot claim the address. This approach might lead to unpredictability which would be hard to trace when debugging problems. However, this would normally be an issue only when the Subnet-router anycast address is used from outside of the link; usually, this cannot be done reliably as the prefix length or EUI64 u/g bits cannot be known for certain. There are other problems with an address being anycast and unicast too: use of it as a source address, whether to use unicast or anycast semantics in [NDISC], and others: allowing this behavior would seem to only add a lot of complexity to the implementations.
5. 実装を改善することもできます。IF /127がポイントツーポイントリンクで使用され、2つのアドレスを請求することはありません。これには、合計ユニキャストとanycastアドレスを使用しているルーターがダウンしている場合でも、他の人がアドレスを請求できないため、サブネットルーターのアニキャストアドレスへのパケットが失われるという欠点があります。このアプローチは、問題をデバッグするときに追跡するのが難しい予測不可能性につながる可能性があります。ただし、これは通常、リンクの外側からサブネットルーターのAnycastアドレスが使用されている場合にのみ問題になります。通常、これは、プレフィックスの長さまたはEUI64 U/Gビットが確実に知られていないため、確実に実行できません。AnycastとUnicastのアドレスにも他の問題があります。[NDISC]でUnicastまたはAnycastセマンティクスを使用するかどうか、ソースアドレスとして使用すること、その他：この動作を許可することは、実装。
1) is definitely the best solution, wherever it is possible. 2) may be usable in some scenarios, but in larger networks (where the most often the desire would be to use longer prefix length) it may be deemed very impractical. There are some situations where one of these may not be an option; then an operational work-around for this operational problem, that is 3), appears to be the best course of action. This is because it may be very difficult to know whether all implementations implement some checks, like ones described in 4) or 5).
1) それが可能な限り、間違いなく最良の解決策です。2）いくつかのシナリオで使用できる場合がありますが、より大きなネットワーク（最も頻繁にはより長いプレフィックスの長さを使用することが望ましい場合）では、非常に非現実的であるとみなされる場合があります。これらのいずれかがオプションではない場合があります。次に、この運用上の問題、つまり3）の運用作業を行うことは、最良の行動方針のように見えます。これは、4）または5）に記載されているように、すべての実装がいくつかのチェックを実装するかどうかを知ることが非常に困難な可能性があるためです。
These issues are not specific to /127.
これらの問題は /127に固有のものではありません。
One should note that [ADDRARCH] specifies universal/local bits (u/g), which are the 70th and 71st bits in any address from non-000/3 range. When assigning prefixes longer than 64 bits, these should be taken into consideration; in almost every case, u should be 0, as the last 64 bits of a long prefix is very rarely unique. 'G' is still unspecified, but defaults to zero. Thus, all prefixes with u or g=1 should be avoided.
[Addrarch]は、非000/3の範囲の任意のアドレスの70番目と71番目のビットであるユニバーサル/ローカルビット（U/g）を指定することに注意する必要があります。64ビットより長い接頭辞を割り当てるときは、これらを考慮に入れる必要があります。ほとんどすべてのケースでは、長いプレフィックスの最後の64ビットが非常にユニークではないため、Uは0でなければなりません。「G」はまだ不特定ですが、デフォルトはゼロです。したがって、uまたはg = 1のすべての接頭辞を避ける必要があります。
[MIPV6] specifies "Mobile IPv6 Home-Agents" anycast address which is used for Home Agent Discovery. In consequence, 7 last bits of have been reserved in [ANYCAST] of every non-000/3 non-multicast address, similar to [ADDRARCH]. Thus, at least /120 would seem to make sense. However, as the sender must know the destination's prefix length, this "reserved anycast addresses" mechanism is only applicable when the sender knows about the link and expects that there is a service it needs there. In the case of e.g., /126 between routers, the only to node to be found on this link would be the other router, so the mechanism does not seem useful. At least, Mobile IPv6 Home Agent Discovery should not be performed if the prefix length is longer than /120.
[MIPV6]は、ホームエージェントの発見に使用される「モバイルIPv6ホームエージェント」ANYCASTアドレスを指定します。その結果、[addrarch]と同様に、すべての非000/3以外の非マルチカストアドレスの[Anycast]で7つの最後のビットが予約されています。したがって、少なくとも /120は理にかなっているようです。ただし、送信者は目的地のプレフィックスの長さを知っている必要があるため、この「予約されたAnycastアドレス」メカニズムは、送信者がリンクについて知っており、そこに必要なサービスがあることを期待している場合にのみ適用されます。たとえば、ルーター間の /126の場合、このリンクにあるノードのみが他のルーターであるため、メカニズムは有用ではないと思われます。少なくとも、プレフィックスの長さが /120より長い場合、モバイルIPv6ホームエージェントの発見は実行されないでください。
[ADDRARCH] Hinden, R. and S. Deering, "IP Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[Addrarch] Hinden、R。and S. Deering、「IPバージョン6（IPv6）アドレス指定アーキテクチャ」、RFC 3513、2003年4月。
[ANYCAST] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast Addresses", RFC 2526, March 1999.
[Anycast] Johnson、D。およびS. Deering、「予約済みのIPv6サブネットAnycastアドレス」、RFC 2526、1999年3月。
[NDISC] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[Ndisc] Narten、T.、Nordmark、E。and W. Simpson、「IPバージョン6（IPv6）の近隣発見」、RFC 2461、1998年12月。
[MIPV6] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in IPv6", Work in Progress.
[Mipv6] Johnson、D.、Perkins、C.、Arkko、J。、「IPv6のモビリティサポート」、進行中の作業。
[ICMPv3] Conta, A., Deering, S., "Internet Control Message Protocol (ICMPv6)", Work in Progress.
[ICMPV3] Conta、A.、Deering、S。、「インターネット制御メッセージプロトコル（ICMPV6）」、進行中の作業。
[PINGPONG] Hagino, J., Jinmei, T., Zill, B., "Avoiding ping-pong packets on point-to-point links", Work in Progress.
[Pingpong] Hagino、J.、Jinmei、T.、Zill、B。、「ポイントツーポイントリンクでピンポンパケットを避ける」、進行中の作業。
Beyond those already existing in other specifications, solution 4) might lead to denial of service in the case that one router is down: the packet to subnet-router anycast address would be lost.
他の仕様に既に存在するものを超えて、ソリューション4）は、1つのルーターがダウンしている場合に使用される可能性があります。
Thanks to Robert Elz and many others on the IPv6 Working Group for discussion, and Alain Durand for pointing out [ADDRARCH] requirements for prefix lengths. Charles Perkins pointed out MIPv6 HA requirements. Randy Bush and Ole Troan commented on the document extensively, and Erik Nordmark pointed out issues with u-bit.
IPV6ワーキンググループのロバートエルツと他の多くの人に議論のために、そしてプレフィックスの長さの[addrarch]要件を指摘してくれたAlain Durandに感謝します。チャールズ・パーキンスは、MIPV6 HAの要件を指摘しました。Randy BushとOle Troanはこの文書について広範囲にコメントし、Erik NordmarkはUビットの問題を指摘しました。
Pekka Savola CSC/FUNET Espoo, Finland
Pekka Savola CSC/Funet Espoo、フィンランド
EMail: psavola@funet.fi
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上記の限られた許可は永続的であり、インターネット社会やその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。