Network Working Group P. Savola
Request for Comments: 3627 CSC/FUNET
Category: Informational September 2003
Use of /127 Prefix Length Between Routers Considered Harmful
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.
著作権（C）インターネット協会（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プレフィックス長を使用することができます。特定の状況下では、これは、実装されているサブネットルータエニーキャストに両方のアドレスを主張する1つのルータにつながる可能性があります。この文書では、この問題を議論し、問題の解決策のカップルを提供しています。それにもかかわらず、/ 127は、二つのルータ間で避けるべきです。
[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]サブネット・ルータのエニーキャストアドレスを定義：nビットのサブネットプレフィックスでは、最後の128のnビットが全てゼロです。サブネット内のいずれかのルータの使用であることを意味します。
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プレフィックス長を有する非000/3ユニキャストプレフィクスのための[ADDRARCH]セクション2.4で禁止されていても、/ 127プレフィックス長を使用して動作人気の多くを得ています。それは、これらのプレフィックス長は、ポイントツーポイントリンクで頻繁に使用されていることのように思えます。操作の練習は、多くの場合、特に、ポイントツーポイントリンクの多数の存在下で、アドレス空間の最小量を使用することでした。これらのリンクのすべてが/ 64年代の使用を開始するとは考えにくいかもしれません。 / 127を使用すると、他の運用上の利点を持っている：あなたは常にもう一方の端を使用して対処するのかを知る、そして何の「ピンポン」（[ICMPv3]になりまし固定）古いICMP実装と[PINGPONG]問題はありません。
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.
この問題はPREFIX :: 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を使用すると、ポイントツーポイントリンク上で特に有害である可能性があります。次の一連のイベントを考えてみます。
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に追加されます。今では[NDISC] 3FFEための重複アドレス検出（DAD）を行う：FFFF :: 1。 FFFF :: 0/127：ルータAはまた、サブネットルータエニーキャストアドレス3FFEを追加します。 （DADは、エニーキャストアドレスのために実行されません。）
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使用するように設定されています。そのユニキャストIPv6アドレスとしてFFFF :: 0/127を、それを追加して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つのルータ間サブネットルータエニーキャストアドレスの使い勝手が非常に疑問であるが、それはまだ[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.
サブネットルータエニーキャストアドレスが実装されたり、あまりにも広く使用されていないため、まだのように、予期しない動作のこの種は、おそらく大規模で見ていません。
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.一つは、唯一のリンクローカルアドレスを使用することができ、それは、少なくとも大きなネットワークでネットワークの保守およびデバッグ非現実的なをすることができます。例えば、「トレースルート」のみ、パスで使用されていたではないリンクをノードのリストを返すことができます。
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のアドレスを使用すると、多くの場合、面倒な、アプローチが、またひとつです。より短いプレフィックスが使用された場合、自然に、はるか例えば、/ 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はノード識別子の最後の16ビットを予約する、/ 112を使用することができない場合、おそらく欠点の最小量を有していることを感じている（また、セクション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.
リンクのプレフィックス長が/ 64（またはさらにより長い/ 120）でない場合に使用すべきではない4. [ADDRARCH]そのサブネット・ルータのエニーキャストアドレスを述べるように修正することができます。これは、将来の柔軟性を維持するために、我々は仕様のプレフィックス長についての仮定を避けるべきであるとして、良いアプローチのように見えるしていません。また、いくつかのケースでは、長いプレフィックス長といくつかのネットワークのサブネットルータエニーキャストアドレスを持つように使えるかもしれません。
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プレフィックス長を持つサブネットにサブネットのルータエニーキャストアドレスを使用していないであろう。これは、近隣広告の「ルータ」ビット[NDISC]と気づいたことができますメッセージ。しかし、これは「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.それは実装を改善することも可能です：/ 127はポイントツーポイントリンク上で使用されている場合、2つのアドレスを主張することはありません。これは、合成ユニキャストおよびエニーキャストアドレスを使用してルータがダウンした場合でも、他のアドレスを請求することができないように、サブネット・ルータのエニーキャストアドレスへのパケットが失われる。欠点を有していますこのアプローチは、問題をデバッグするときにトレースすることは難しいだろう予測不可能性につながる可能性があります。しかし、これは通常、サブネットルータエニーキャストアドレスは、リンクの外から使用されている唯一の問題は次のようになります。通常、これは、プレフィックス長として確実に行うことができない、またはEUI64 U / Gビットを確実に知ることができません。 [NDISC]でユニキャストまたはエニーキャストのセマンティクスを使用するかどうかを送信元アドレスとしてそれを使用すると、他の人：あまりにもエニーキャストとユニキャストされたアドレスを持つ他の問題があり、この動作だけに複雑の多くを追加すると思われることができ実装。
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ホームエージェント」エニーキャストアドレス。その結果、7つの最後のビットが[ANYCAST] [ADDRARCH]と同様すべての非000/3非マルチキャストアドレスの中で予約されています。このように、少なくとも/ 120は、意味をなすように思われます。送信者がリンクを知っていて、それが必要とするサービスがあることを期待していたときしかし、先のプレフィックス長を知っている必要があります送信者として、この「予約エニーキャストアドレス」メカニズムにのみ適用されます。ルータ間、例えば、/ 126の場合には、このリンク上で発見されたノードにのみ、他のルータになり、そう機構は有用でないようです。プレフィックス長よりも長い/ 120であれば、少なくとも、モバイルIPv6ホームエージェント発見を実行するべきではありません。
[ADDRARCH] Hinden, R. and S. Deering, "IP Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[ADDRARCH] HindenとR.とS.デアリング、 "IPバージョン6（IPv6）のアドレス指定アーキテクチャ"、RFC 3513、2003年4月。
[ANYCAST] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast Addresses", RFC 2526, March 1999.
[ANYCAST]ジョンソン、D.とS.デアリング、 "予約済みのIPv6サブネットエニーキャストアドレス"、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.およびW.シンプソン、 "IPバージョン6（IPv6）のための近隣探索"、RFC 2461、1998年12月。
[MIPV6] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in IPv6", Work in Progress.
[MIPV6]ジョンソン、D.、パーキンス、C.、Arkko、J.、 "IPv6におけるモビリティサポート"、進行中の作業。
[ICMPv3] Conta, A., Deering, S., "Internet Control Message Protocol (ICMPv6)", Work in Progress.
【ICMPv3]コンタ、A.、デアリング、S.、 "インターネット制御メッセージプロトコル（ICMPv6の）"、ProgressのWork。
[PINGPONG] Hagino, J., Jinmei, T., Zill, B., "Avoiding ping-pong packets on point-to-point links", Work in Progress.
【PINGPONG】萩野、J.、神明、T.、Zill、B.、「ポイントツーポイントリンク上でピンポンパケットを回避」、ProgressのWork。
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.
プレフィックス長に対する[ADDRARCH]要件を指摘して議論のためのIPv6ワーキンググループのロバート・エルツおよび他の多くのおかげで、アラン・デュラン。チャールズ・パーキンスは、MIPv6のHA要件を指摘しました。ランディブッシュとオレTroanは広範囲に文書でコメントし、そしてエリックNordmarkとは、Uビットの問題を指摘しました。
Pekka Savola CSC/FUNET Espoo, Finland
ペッカSavola CSC / FUNETエスポー、フィンランド
EMail: psavola@funet.fi
メールアドレス：psavola@funet.fi
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。