この文書は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エディタ機能のための資金供給が現在インターネット学会によって
   供給されます。

Japanese translation by Ishida So