この文書はRFC3627の日本語訳(和訳)です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のRFC同様に無制限です。
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. 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つのルータが両方のアドレスを奪う事を起こすかもしれません。この文書 は問題を論じて、そして問題に対する2つの解決策を提供します;にもかか わらず/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]がサブネットルータエニキャストアドレスを定義します: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]). 非000/3のユニキャストプレフィックスで/64より長いプレフィック ス長さを持つことが[ADDRARCH]2.4章で禁じられるけれども、 /127プ レフィックス長を使う事が、多くの操作上の人気を増しました;これらのプ レフィックス長がポイントポイントリンクで最も使われていると思われます。 運用上の慣習はしばしば、特に多数のポイントポイントリンクがある時に、 最少量のアドレス空間を使用します。これらリンクが全て/64のを使うの はありそうもないです。/127を使うことは同じく他の運用上の利益を持 ちます:あなたは常に他の終端がどのアドレスを使うか知っています、そし て古いICMP実装における「ピンポン」[PINGPONG]問題はありません ([ICMPv3]で修正しました)。 2. Scope of this Memo 2. この文書の範囲 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: /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に追加されます;今これは 3ffe:ffff::1の重複アドレス発見(DAD)を行います。ルータAが同じ くサブネットルータエニキャストアドレス3ffe:ffff::0/127を追加します。 (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: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つのルータ間のサブネットルータエニキャス トアドレスの有用性は非常に疑わしいですが、これはまだ[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. サブネットルータエニキャストアドレスが広く実装や使用されなかったので 、時点でまだこの種類の意外な行動が多分一般的に見られています。 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つはリンクローカルアドレスだけを使うことです、しかしこれは少な くとも大きいネットワークでネットワークでの保守やデバッグを非実用 的にするかもしれません;例えば「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のアドレスを使うことは、しばしば扱いにくいけれ ども、同じです。当然、より短いプレフィックス、例えば/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より長いなら) 使われるべきではない、と述べるように修正することができます。我々 が仕様書でプレフィックス長の仮定をするのを避けるべきであるから、 これは良いアプローチには見えず将来の柔軟性を持続するように思われ ません。同じく、ある場合には、より長いプレフィックス長のあるネッ トワークで、サブネットルータエニキャストアドレスを持つ事が有用で あるかもしれません。 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つのアドレスを要求しないでください。 これは、もしルータが結合ユニキャストアドレスを使用し、エニキャスト アドレスがダウンしたなら、サブネットルータエニキャストアドレスへの パケットが、他がアドレスを要求できないから、失われるであろうという 欠点を持っています。この方法は問題をデバッグする際に追跡を困難にす る予測不能を導くかもしれません。しかしながらこれは、通常mサブネッ トルータエニキャストアドレスがリンク外から使われる時だけの問題であ るでしょう;通常、これは、プレフィックス長や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)は特定の場合に有用か もしれませんが、(最もしばしば長いプレフィックス長を使う要望がある) 大きなネットワークで非常に非実用的とみなされるかもしれません。これら の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. [ADDRARCH]が共通/ローカルビット(u/g)を指定することを気づくべき で、これは非000/3範囲の任意のアドレスの第70番目と第71番目の ビットです。 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. 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ホームエー ジェント」エニキャストアドレスを指定します。その結果、全ての 非000/3の非マルチキャストアドレスの最後の7ビットが[ADDRARCH]同 様に[ANYCAST]で予約されました。それで、少なくとも/120にするのが 意味があるでしょう。しかしながら、送信者が宛先プレフィックス長さを知 らなければならないから、この「予約エニキャストアドレス」機構は、送信 者がリンクについて知っていて、そしてそこに必要とするサービスがあると 思う時にだけ、適用可能です。ルータ間で、例えば、/126の場合に、リ ンク上で見いだされるノードはこのリンクの他のルータであり、それでこの メカニズムは有用に思われません。少なくとも、モバイルIPv6ホームエー ジェント探索は、もしプレフィックス長が/120より長いなら、行われる べきではありません。 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. [ANYCAST] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast Addresses", RFC 2526, March 1999. 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. [MIPV6] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in IPv6", Work in Progress. [ICMPv3] Conta, A., Deering, S., "Internet Control Message Protocol (ICMPv6)", Work in Progress. [PINGPONG] Hagino, J., Jinmei, T., Zill, B., "Avoiding ping-pong packets on point-to-point links", Work in Progress. 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. 他の既存の仕様書に既にあるもの以外に、解決策4)は1つのルータが停止し た際にサービス妨害を発生させるかもしれません:サブネットルータエニキャ ストアドレス宛のパケットが失われます。 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. Robert ElzとIPv6作業グループの多くの他の人たちと、Alain Durandの プレフィックス長の[ADDRARCH]要求条件に指摘に対して、感謝します。 Charles PerkinsはMIPv6のHA必要条件を指摘しました。Randy Bush とOle Troanは広範囲に文書についてコメントしました、そしてErik Nordmarkはuビットの問題を指摘しました。 9. Author's Address 9. 著者のアドレス Pekka Savola CSC/FUNET Espoo, Finland EMail: psavola@funet.fi 10. Full Copyright Statement 10. 著作権表示全文 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エディタ機能のための資金供給が現在インターネット学会によって 供給されます。