RFC3627 日本語訳

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ページ]