RFC3627 日本語訳
3627 Use of /127 Prefix Length Between Routers Considered Harmful. P.Savola. September 2003. (Format: TXT=12436 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group P. Savola Request for Comments: 3627 CSC/FUNET Category: Informational September 2003
Savolaがコメントのために要求するワーキンググループP.をネットワークでつないでください: 3627年のCSC/FUNETカテゴリ: 情報の2003年9月
Use of /127 Prefix Length Between Routers Considered Harmful
有害であると考えられたルータの間の/127接頭語長さの使用
Status of this Memo
この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)インターネット協会(2003)。 All rights reserved。
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つのルータに通じるかもしれません。 このドキュメントは、問題に取り組んで、問題の2、3の解決を提供します。 それにもかかわらず、/127は2つのルータの間で避けられるべきです。
1. Introduction
1. 序論
[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]はSubnet-ルータanycastアドレスを定義します: 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には、他の操作上の利益があります: あなたは、いつもどれが他の最終用途を記述するかを知っています、そして、より古いICMP実現(現在、[ICMPv3]で修理されている)に関する「ピンポン」[PINGPONG]問題が全くありません。
Savola Informational [Page 1] RFC 3627 /127 Prefix Length Considered Harmful September 2003
2003年9月に有害であると考えられたSavolaの情報[1ページ]のRFC3627 /127接頭語の長さ
2. Scope of this Memo
2. このMemoの範囲
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.
範囲の外に「正しい」解決策であることの詳細な論議があります。 それは「最も良い」アドレシングが皆の解決策であることがわかろうとするこのメモの目標ではありません。
3. Problem with /127 and Two Routers
3. /127に関する問題と2つのルータ
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:
Subnet-ルータanycastアドレスが実行されるとき、使用/127はポイントツーポイント接続で特に有害である場合があります。 出来事の以下の系列を考えてください:
1. Router A and Router B are connected by a point-to-point link.
1. ルータAとRouter 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アドレスはRouter Aに加えられます。 今、3ffe: ffffのために、Duplicate Address Detection(おとうさん)[NDISC]を実行します:、:1. また、ルータAはSubnet-ルータanycastアドレス3ffe: ffffを加えます:、:0/127. (DADは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. 今、Router Bは3ffe: ffffを使用するために計画されて、構成されました:、:BがするユニキャストIPv6アドレス、しかし、DADに失敗すると言い足して、およびRouterとしての0/127には、少しのアドレスもありません。
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.
しかし、恐らく、Subnet-ルータanycastアドレスが実行もされませんし、あまり広く使用されてもいないので、この種類の予期していなかった振舞いは全体であることが見られていません。
Savola Informational [Page 2] RFC 3627 /127 Prefix Length Considered Harmful September 2003
2003年9月に有害であると考えられたSavolaの情報[2ページ]のRFC3627 /127接頭語の長さ
4. Solutions
4. ソリューション
1. One could use /64 for subnets, including point-to-point links.
1. 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. 1つはリンクローカルのアドレスだけを使用するかもしれませんが、それで、ネットワークメンテナンスとデバッグは少なくともより大きいネットワークで非実用的になるかもしれません。 例えば、「トレースルート」は使用されたリンクではなく、経路のノードのリストを返すことができるだけです。
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に類似しています。 しばしば厄介ですが、また、two /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).
作者は、ノード識別子のためにベスト16ビットを予約して、/64を使用できないなら、/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.
4. Subnet-ルータanycastアドレスがリンクの接頭語の長さが/64でない(/120よりさらに長い)なら使用されるべきでないと述べるために[ADDRARCH]を改訂できました。 これは良いアプローチのように見えません、私たちが、将来の柔軟性を維持するために仕様で接頭語の長さに関する仮定をするのを避けるべきであるとき。 また、いくつかの場合、より長い接頭語の長さと共にいくつかのネットワークでSubnet-ルータ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の接頭語の長さでサブネットにSubnet-ルータanycastアドレスを使用していないでしょう: Neighbor Advertisementメッセージで[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
5. また、実現を改良するのも可能です: /127がポイントツーポイント接続の上で使用されるなら、2つのアドレスを決して要求しないでください。 これには、結合したユニキャストとanycastアドレスを使用するルータがそうであってもダウンする欠点があって、もう片方がアドレスを要求できないようにサブネットルータanycastアドレスへのパケットは失われるでしょう。 このアプローチは問題をデバッグするときたどりにくい予測不可能性につながるかもしれません。しかしながら、Subnet-ルータanycastアドレスがリンクの外部から使用されるときだけ、通常、これは問題でしょう。 通常、確かに接頭語の長さかEUI64 u/gビットを知ることができないようにこれが確かにできません。 他の問題がアドレス存在anycastとユニキャストと共にあります。
Savola Informational [Page 3] RFC 3627 /127 Prefix Length Considered Harmful September 2003
2003年9月に有害であると考えられたSavolaの情報[3ページ]のRFC3627 /127接頭語の長さ
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.
また: ソースアドレスとしてのそれの使用かユニキャストを使用するか、そして、[NDISC]、および他のものの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)はいくつかのシナリオで使用可能であるかもしれませんが、より大きいネットワーク(より長い接頭語の長さを使用する最もしばしば、願望がことであるところ)では、それは非常に非実用的であると考えられるかもしれません。 いくつかの状況がこれらの1つがオプションでないかもしれないところにあります。 そして、すなわち、この運転上の問題、3のための)操作上の次善策は最も良い行動であるように見えます。 これはすべての実現がいくつかのチェックを実行するかどうかを知るのが非常に難しいかもしれないからです、4か)5で)説明されたもののように。
5. Other Problems with Long Prefixes
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]が70番目である普遍的であるか地方のビット(u/g)を指定することに注意するべきです、そして、非000/3からのどんなアドレスの71番目のビットも及びます。 64ビットより長い間接頭語を割り当てるとき、これらは考慮に入れられるべきです。 ほとんどすべての場合、uは0であるべきです、長い接頭語の最後の64ビットがめったにユニークでないときに。 '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アドレスを指定します。 その結果、7がビットを持続する、[ADDRARCH]と同様のあらゆる非000/3非マルチキャストアドレスの予約されたコネ[ANYCAST]はそうです。 したがって、少なくとも/120は理解できるように思えるでしょう。 送付者が、リンクに関して知って、それがそこで必要とするサービスがあると予想するときだけ、しかしながら、送付者が目的地の接頭語の長さを知らなければならないようにこれが「anycastアドレスを予約した」というメカニズムは適切です。 例えば、ルータの間の/126の場合では、このリンクの上に見つけられるノードへの唯一はもう片方のルータでしょう、したがって、メカニズムが役に立つように見えません。 接頭語の長さが/120より長いなら、少なくとも、モバイルIPv6ホームエージェントディスカバリーを実行するべきではありません。
6. References
6. 参照
6.1. Normative References
6.1. 引用規格
[ADDRARCH] Hinden, R. and S. Deering, "IP Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[ADDRARCH] HindenとR.とS.デアリング、「IPバージョン6(IPv6)アドレッシング体系」、RFC3513、2003年4月。
[ANYCAST] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast Addresses", RFC 2526, March 1999.
[ANYCAST] ジョンソンとD.とS.デアリング、「予約されたIPv6サブネットAnycastアドレス」、RFC2526、1999年3月。
Savola Informational [Page 4] RFC 3627 /127 Prefix Length Considered Harmful September 2003
2003年9月に有害であると考えられたSavolaの情報[4ページ]のRFC3627 /127接頭語の長さ
6.2. Informative References
6.2. 有益な参照
[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)のための隣人発見」、RFC2461、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)」が進行中で働いています。
[PINGPONG] Hagino, J., Jinmei, T., Zill, B., "Avoiding ping-pong packets on point-to-point links", Work in Progress.
[PINGPONG] B. Hagino、J.、Jinmei、T.、Zill、Progressの「ポイントツーポイント接続の上でピンポンパケットを避ける」Work。
7. Security Considerations
7. セキュリティ問題
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.
他の仕様に既に存在するものを超えて、1つのルータが下がっていて、解決策4)はサービスの否定につながるかもしれません: サブネットルータanycastアドレスへのパケットは失われるでしょう。
8. Acknowledgements
8. 承認
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]要件を指摘するためのアラン・ジュランドでロバートElzと多くの他のものをありがとうございます。 チャールズ・パーキンスはMIPv6 HA要件を指摘しました。 ランディ・ブッシュとOle Troanは手広くドキュメントを批評しました、そして、エリックNordmarkはu-ビットの問題を指摘しました。
9. Author's Address
9. 作者のアドレス
Pekka Savola CSC/FUNET Espoo, Finland
ペッカ・Savola CSC/FUNETエスポー(フィンランド)
EMail: psavola@funet.fi
メール: psavola@funet.fi
Savola Informational [Page 5] RFC 3627 /127 Prefix Length Considered Harmful September 2003
2003年9月に有害であると考えられたSavolaの情報[5ページ]のRFC3627 /127接頭語の長さ
10. Full Copyright Statement
10. 完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Savola Informational [Page 6]
Savola情報です。[6ページ]
一覧
スポンサーリンク