この文書はRFC3627の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
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.
ある場合には、運用上の決定で、特にポイントポイントリンク上のルータ間
で、ＩＰｖ６／１２７プレフィックス長を使うことであるかもしれません。
ある特定の状態の下で、サブネットルーターエニキャストのために、これは
１つのルータが両方のアドレスを奪う事を起こすかもしれません。この文書
は問題を論じて、そして問題に対する２つの解決策を提供します；にもかか
わらず／１２７が２つのルータ間で避けられるべきです。
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]がサブネットルータエニキャストアドレスを定義します：ｎビッ
トのサブネットプレフィックスで、最後の１２８−ｎのビットはすべてゼロ
です。これはサブネットのどのルータも使用することを意味します。
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]).
非０００/３のユニキャストプレフィックスで／６４より長いプレフィック
ス長さを持つことが[ADDRARCH]２.４章で禁じられるけれども、 ／１２７プ
レフィックス長を使う事が、多くの操作上の人気を増しました；これらのプ
レフィックス長がポイントポイントリンクで最も使われていると思われます。
運用上の慣習はしばしば、特に多数のポイントポイントリンクがある時に、
最少量のアドレス空間を使用します。これらリンクが全て／６４のを使うの
はありそうもないです。／１２７を使うことは同じく他の運用上の利益を持
ちます：あなたは常に他の終端がどのアドレスを使うか知っています、そし
て古いＩＣＭＰ実装における「ピンポン」[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. ／１２７と２つのルータにおける問題
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:
／１２７を使うことは、サブネットルータエニキャストアドレスが実装され
る時、ポイントポイントリンク上に特に有害であり得ます。次のイベント列
を考えてください：
1. Router A and Router B are connected by a point-to-point link.
1. ルータＡとルータＢがポイントポイントリンクによって接続されます。
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アドレスがルータＡに追加されます；今これは
3ffe:ffff::1の重複アドレス発見（ＤＡＤ）を行います。ルータＡが同じ
くサブネットルータエニキャストアドレス3ffe:ffff::0/127を追加します。
（ＤＡＤはエニキャストアドレスのために行はわれません。）
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. 今ルータＢが3ffe:ffff::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.
ポイントポイントリンク上の２つのルータ間のサブネットルータエニキャス
トアドレスの有用性は非常に疑わしいですが、これはまだ[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. １つは、ポイントポイントリンクでも、サブネットに／６４を使うこと
です。
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. １つはリンクローカルアドレスだけを使うことです、しかしこれは少な
くとも大きいネットワークでネットワークでの保守やデバッグを非実用
的にするかもしれません；例えば「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. ／１２６はこの問題がありません、これはポイントポイントリンク上で安
全に使うことができます（例えば、ユニキャストの第２番目と第３番目の
アドレスを使います）。これはＩＰｖ４で／３０を使うことに類似してい
ます。２つの／１２８のアドレスを使うことは、しばしば扱いにくいけれ
ども、同じです。当然、より短いプレフィックス、例えば／１１２や
／１２０を使えば、失う物はないでしょう。
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).
著者はもし／６４を使うことができないなら、／１１２はノード識別子の
ために最後の１６ビットを確保しているので、恐らく欠点が最小であると
思います（３章参照）。
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]はサブネットルータエニキャストアドレスが、もしリンクのプ
レフィックス長が／６４ではないなら（あるいは／１２０より長いなら）
使われるべきではない、と述べるように修正することができます。我々
が仕様書でプレフィックス長の仮定をするのを避けるべきであるから、
これは良いアプローチには見えず将来の柔軟性を持続するように思われ
ません。同じく、ある場合には、より長いプレフィックス長のあるネッ
トワークで、サブネットルータエニキャストアドレスを持つ事が有用で
あるかもしれません。
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.
いっそう保守的な（実装）方法は、もしリンクに２つのルータだけがある
なら、／１２７プレフィックス長のサブネットでサブネットルータエニ
キャストアドレスを使わない事でしょう：これは近隣広告メッセージの
[NDISC]「ルータ」ビットで気付くことができます。しかしながら、これ
は「Ｒ」ビットの機能に負担をかけ過ぎるように思われ、長い目で見れ
ば良い方法に見えません。
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. 実装を改善することも同じく可能です：もし／１２７がポイントポイント
リンク上で使われるなら、決して２つのアドレスを要求しないでください。
これは、もしルータが結合ユニキャストアドレスを使用し、エニキャスト
アドレスがダウンしたなら、サブネットルータエニキャストアドレスへの
パケットが、他がアドレスを要求できないから、失われるであろうという
欠点を持っています。この方法は問題をデバッグする際に追跡を困難にす
る予測不能を導くかもしれません。しかしながらこれは、通常ｍサブネッ
トルータエニキャストアドレスがリンク外から使われる時だけの問題であ
るでしょう；通常、これは、プレフィックス長や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)で記
述したようなある検査をしていると知ることは難しいのからです。
5. Other Problems with Long Prefixes
5. 長いプレフィックスにおける他の問題
These issues are not specific to /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]が共通／ローカルビット（ｕ／ｇ）を指定することを気づくべき
で、これは非０００/３範囲の任意のアドレスの第７０番目と第７１番目の
ビットです。
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.
６４ビットより長いプレフィックスを割り当てる時、これらを考慮に入れる
べきです；ほとんどすべての場合に、ｕは０であるべきです、長いプレフィッ
クスの最後の６４ビットがめったにユニークではありません。「Ｇ」はまだ
特定されていませんが、ゼロをデフォルトとします。それで、すべてのプレ
フィックスでｕかｇ＝１が避けられるべきです。
[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]がホームエージェント探索に使われる「モバイルＩＰｖ６ホームエー
ジェント」エニキャストアドレスを指定します。その結果、全ての
非０００/３の非マルチキャストアドレスの最後の７ビットが[ADDRARCH]同
様に[ANYCAST]で予約されました。それで、少なくとも／１２０にするのが
意味があるでしょう。しかしながら、送信者が宛先プレフィックス長さを知
らなければならないから、この「予約エニキャストアドレス」機構は、送信
者がリンクについて知っていて、そしてそこに必要とするサービスがあると
思う時にだけ、適用可能です。ルータ間で、例えば、／１２６の場合に、リ
ンク上で見いだされるノードはこのリンクの他のルータであり、それでこの
メカニズムは有用に思われません。少なくとも、モバイルＩＰｖ６ホームエー
ジェント探索は、もしプレフィックス長が／１２０より長いなら、行われる
べきではありません。
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)は１つのルータが停止し
た際にサービス妨害を発生させるかもしれません：サブネットルータエニキャ
ストアドレス宛のパケットが失われます。
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とＩＰｖ６作業グループの多くの他の人たちと、Alain Durandの
プレフィックス長の[ADDRARCH]要求条件に指摘に対して、感謝します。
Charles PerkinsはＭＩＰｖ６のＨＡ必要条件を指摘しました。Randy Bush
とOle Troanは広範囲に文書についてコメントしました、そしてErik
Nordmarkはｕビットの問題を指摘しました。
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.
著作権（Ｃ）インターネット学会（２００３）。すべての権利は保留される。
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.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。