RFC4191 日本語訳
4191 Default Router Preferences and More-Specific Routes. R. Draves,D. Thaler. November 2005. (Format: TXT=34672 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Draves
Request for Comments: 4191 D. Thaler
Category: Standards Track Microsoft
November 2005
Dravesがコメントのために要求するワーキンググループR.をネットワークでつないでください: 4191年のD.ターレルカテゴリ: 標準化過程マイクロソフト2005年11月
Default Router Preferences and More-Specific Routes
デフォルトルータ好みと、より特定のルート
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
This document describes an optional extension to Router Advertisement messages for communicating default router preferences and more- specific routes from routers to hosts. This improves the ability of hosts to pick an appropriate router, especially when the host is multi-homed and the routers are on different links. The preference values and specific routes advertised to hosts require administrative configuration; they are not automatically derived from routing tables.
このドキュメントはルータからホストまでデフォルトルータ好みを伝えることへのRouter Advertisementメッセージと、より多くの特定のルートに任意の拡大について説明します。 そして、これはホストが適切なルータを選ぶ能力を改良します、特にホストがそうときにマルチ、家へ帰り、異なったリンクの上にルータがあります。 ホストに広告に掲載された好みの値と特定のルートは管理構成を必要とします。 それらは経路指定テーブルから自動的に得られません。
1. Introduction
1. 序論
Neighbor Discovery [RFC2461] specifies a conceptual model for hosts that includes a Default Router List and a Prefix List. Hosts send Router Solicitation messages and receive Router Advertisement messages from routers. Hosts populate their Default Router List and Prefix List based on information in the Router Advertisement messages. A conceptual sending algorithm uses the Prefix List to determine if a destination address is on-link and uses the Default Router List to select a router for off-link destinations.
隣人ディスカバリー[RFC2461]はホストのためのDefault Router ListとPrefix Listを含んでいる概念モデルを指定します。 ホストは、メッセージをRouter Solicitationに送って、ルータからRouter Advertisementメッセージを受け取ります。 ホストはRouter Advertisementメッセージの情報に基づく彼らのDefault Router ListとPrefix Listに居住します。 概念的な送付アルゴリズムは、送付先アドレスがリンクであるかどうか決定するのにPrefix Listを使用して、オフリンクの目的地にルータを選択するのにDefault Router Listを使用します。
In some network topologies where the host has multiple routers on its Default Router List, the choice of router for an off-link destination is important. In some situations, one router may provide much better performance than another for a destination. In other situations, choosing the wrong router may result in a failure to communicate. (Section 5 gives specific examples of these scenarios.)
ホストがDefault Router Listに複数のルータを持っているいくらかのネットワークtopologiesでは、オフリンクの目的地へのルータの選択は重要です。 いくつかの状況で、1つのルータが別のものよりはるかに良い性能を目的地に提供するかもしれません。 他の状況で、間違ったルータを選ぶと、交信しないことはもたらされるかもしれません。 (セクション5はこれらのシナリオの特定の例を出します。)
Draves & Thaler Standards Track [Page 1] RFC 4191 Router Preferences and More-Specific Routes November 2005
Dravesとターレル規格は2005年11月にRFC4191ルータ好みと、より特定のルートを追跡します[1ページ]。
This document describes an optional extension to Neighbor Discovery Router Advertisement messages for communicating default router preferences and more-specific routes from routers to hosts. This improves the ability of hosts to pick an appropriate router for an off-link destination.
このドキュメントはルータからホストまでデフォルトルータ好みを伝えることへのNeighborディスカバリーRouter Advertisementメッセージと、より特定のルートに任意の拡大について説明します。 これはホストがオフリンクの目的地に適切なルータを選ぶ能力を改良します。
Note that since these procedures are applicable to hosts only, the forwarding algorithm used by the routers (including hosts with enabled IP forwarding) is not affected.
これらの手順がホストだけに適切であるのでルータ(可能にされたIP推進でホストを含んでいる)によって使用される推進アルゴリズムが影響を受けないことに注意してください。
Neighbor Discovery provides a Redirect message that routers can use to correct a host's choice of router. A router can send a Redirect message to a host, telling it to use a different router for a specific destination. However, the Redirect functionality is limited to a single link. A router on one link cannot redirect a host to a router on another link. Hence, Redirect messages do not help multi- homed (through multiple interfaces) hosts select an appropriate router.
隣人ディスカバリーはルータがホストのルータの選択を修正するのに使用できるRedirectメッセージを提供します。 ルータはRedirectメッセージをホストに送ることができます、特定の目的地に異なったルータを使用するようにそれに言って。 しかしながら、Redirectの機能性は単一のリンクに制限されます。 1個のリンクの上のルータは別のリンクの上にルータにホストを向け直すことができません。 したがって、Redirectメッセージが助けない、マルチ、家へ帰り、(複数のインタフェースを通した) ホストは適切なルータを選択します。
Multi-homed hosts are an increasingly important scenario, especially with IPv6. In addition to a wired network connection, like Ethernet, hosts may have one or more wireless connections, like 802.11 or Bluetooth. In addition to physical network connections, hosts may have virtual or tunnel network connections. For example, in addition to a direct connection to the public Internet, a host may have a tunnel into a private corporate network. Some IPv6 transition scenarios can add additional tunnels. For example, hosts may have 6to4 [RFC3056] or configured tunnel [RFC2893] network connections.
マルチ、家へ帰り、ホストは特にIPv6があるますます重要なシナリオです。 ホストには、有線ネットワーク接続に加えて、イーサネットのように、1人以上の無線接続がいるかもしれません、802.11やブルートゥースのように。 物理ネットワーク接続に加えて、ホストには、仮想かトンネルネットワーク接続がいるかもしれません。 例えば、公共のインターネットとのダイレクト接続に加えて、ホストは私設の企業ネットワークにトンネルを持っているかもしれません。 いくつかのIPv6変遷シナリオが追加トンネルを加えることができます。 例えば、ホストには、6to4[RFC3056]か構成されたトンネル[RFC2893]ネットワーク接続がいるかもしれません。
This document requires that the preference values and specific routes advertised to hosts require explicit administrative configuration. They are not automatically derived from routing tables. In particular, the preference values are not routing metrics and it is not recommended that routers "dump out" their entire routing tables to hosts.
このドキュメントは、ホストに広告に掲載された好みの値と特定のルートが明白な管理構成を必要とするのを必要とします。 それらは経路指定テーブルから自動的に得られません。 特に、好みの値は測定基準を発送していません、そして、それらの全体のルーティングがホストにテーブルの上に置くそのルータ「ダンプアウト」はそれに推薦されません。
We use Router Advertisement messages, instead of some other protocol like RIP [RFC2080], because Router Advertisements are an existing standard, stable protocol for router-to-host communication. Piggybacking this information on existing message traffic from routers to hosts reduces network overhead. Neighbor Discovery shares with Multicast Listener Discovery the property that they both define host-to-router interactions, while shielding the host from having to participate in more general router-to-router interactions. In addition, RIP is unsuitable because it does not carry route lifetimes so it requires frequent message traffic with greater processing overheads.
私たちはRouter Advertisementメッセージを使用します、RIP[RFC2080]のようなある他のプロトコルの代わりに、Router Advertisementsがルータからホストへのコミュニケーションのための既存の標準の、そして、安定したプロトコルであるので。 ルータからホストまで既存のメッセージトラフィックのこの情報を背負うと、ネットワークオーバーヘッドは下げられます。 隣人ディスカバリーはルータからルータへの、より一般的な相互作用に参加しなければならないそれらの両方がホストを保護している間のホストからルータへの相互作用を定義する特性をMulticast Listenerディスカバリーと共有します。 どんなキャリールートにも生涯をしないのでさらに、RIPが不適当であるので、それは、よりすばらしい処理オーバヘッドがある頻繁なメッセージトラフィックを必要とします。
Draves & Thaler Standards Track [Page 2] RFC 4191 Router Preferences and More-Specific Routes November 2005
Dravesとターレル規格は2005年11月にRFC4191ルータ好みと、より特定のルートを追跡します[2ページ]。
The mechanisms specified here are backwards-compatible, so that hosts that do not implement them continue to function as well as they did previously.
ここで指定されたメカニズムは後方に互換性があります、彼らを実装しないホストが、彼らが以前にしたのと同じくらいよく機能し続けるように。
1.1. Conventions Used in This Document
1.1. 本書では使用されるコンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. Message Formats
2. メッセージ・フォーマット
2.1. Preference Values
2.1. 好みの値
Default router preferences and preferences for more-specific routes are encoded the same way.
より特定のルートのためのデフォルトルータ好みと好みは同じようにコード化されます。
Preference values are encoded as a two-bit signed integer, as follows:
好みの値は以下の通り安っぽい署名している整数としてコード化されます:
01 High
00 Medium (default)
11 Low
10 Reserved - MUST NOT be sent
01 高い00Medium(デフォルト)11Low10Reserved--送ってはいけません。
Note that implementations can treat the value as a two-bit signed integer.
実装が安っぽい署名している整数として値を扱うことができることに注意してください。
Having just three values reinforces that they are not metrics and more values do not appear to be necessary for reasonable scenarios.
ちょうど3を持っていると、測定基準ではなく、補強が評価されます、そして、より多くの値は妥当なシナリオに必要であるように見えません。
Draves & Thaler Standards Track [Page 3] RFC 4191 Router Preferences and More-Specific Routes November 2005
Dravesとターレル規格は2005年11月にRFC4191ルータ好みと、より特定のルートを追跡します[3ページ]。
2.2. Changes to Router Advertisement Message Format
2.2. ルータ通知メッセージ・フォーマットへの変化
The changes from Neighbor Discovery [RFC2461] Section 4.2 and [RFC3775] Section 7.1 are as follows:
Neighborディスカバリー[RFC2461]部4.2と[RFC3775]セクション7.1からの変化は以下の通りです:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cur Hop Limit |M|O|H|Prf|Resvd| Router Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retrans Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| コード| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 野良犬ホップ限界|M|O|H|Prf|Resvd| ルータ生涯| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 届いている時間| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Retransタイマ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプション… +-+-+-+-+-+-+-+-+-+-+-+-
Fields:
分野:
Prf (Default Router Preference)
2-bit signed integer. Indicates whether to prefer this
router over other default routers. If the Router Lifetime
is zero, the preference value MUST be set to (00) by the
sender and MUST be ignored by the receiver. If the Reserved
(10) value is received, the receiver MUST treat the value as
if it were (00).
Prf(デフォルトRouter Preference)の2ビットは整数に署名しました。 他のデフォルトルータよりこのルータを好むかどうかを示します。 Router Lifetimeがゼロであるなら、好みの値を送付者は(00)に設定しなければならなくて、受信機で無視しなければなりません。Reserved(10)値が受け取られているなら、受信機は、まるでそれが(00)であるかのように値を扱わなければなりません。
Resvd (Reserved)
A 3-bit unused field. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
Resvd(予約される)のA3ビットの未使用の分野。 それを送付者がゼロに初期化しなければならなくて、受信機で無視しなければなりません。
Possible Options:
可能なオプション:
Route Information
These options specify prefixes that are reachable via the
router.
ルート情報Theseオプションはルータで届いている接頭語を指定します。
Discussion:
議論:
Note that in addition to the preference value in the message header, a Router Advertisement can also contain a Route Information Option for ::/0, with a preference value and lifetime. Encoding a preference value in the Router Advertisement header has some advantages:
また、メッセージヘッダーの好みの値に加えてRouter Advertisementが以下のためにRoute情報Optionを含むことができることに注意してください:好みの値と生涯がある/0。 Router Advertisementヘッダーで好みの値をコード化するのにおいて、いくつかの利点があります:
Draves & Thaler Standards Track [Page 4] RFC 4191 Router Preferences and More-Specific Routes November 2005
Dravesとターレル規格は2005年11月にRFC4191ルータ好みと、より特定のルートを追跡します[4ページ]。
1. It allows for a distinction between the "best router for the
default route" and the "router least likely to redirect common
traffic", as described below in Section 5.1.
1. それは「デフォルトルートへの最も良いルータ」と「一般的なトラフィックを最も向け直しそうにないルータ」の区別を考慮します、セクション5.1で以下で説明されるように。
2. When the best router for the default route is also the router
least likely to redirect common traffic (which will be a common
case), encoding the preference value in the message header is more
efficient than sending a separate option.
2. また、デフォルトルートへの最も良いルータが一般的なトラフィック(よくある例になる)を最も向け直しそうにないルータであるときに、メッセージヘッダーで好みの値をコード化するのは別々のオプションを送るより効率的です。
2.3. Route Information Option
2.3. 経由地案内オプション
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Prefix Length |Resvd|Prf|Resvd|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix (Variable Length) |
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 接頭語の長さ|Resvd|Prf|Resvd| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 生涯を発送してください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 接頭語(可変長)| . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
分野:
Type 24
24をタイプしてください。
Length 8-bit unsigned integer. The length of the option
(including the Type and Length fields) in units of 8
octets. The Length field is 1, 2, or 3 depending on the
Prefix Length. If Prefix Length is greater than 64, then
Length must be 3. If Prefix Length is greater than 0,
then Length must be 2 or 3. If Prefix Length is zero,
then Length must be 1, 2, or 3.
長さ、8ビットの符号のない整数。 8つの八重奏のユニットのオプション(TypeとLength分野を含んでいる)の長さ。 2、または3がPrefix Lengthによって、Length分野は1です。 Prefix Lengthが64歳以上であるなら、Lengthは3歳であるに違いありません。 Prefix Lengthが0歳以上であるなら、Lengthは2か3歳であるに違いありません。 Prefix Lengthがゼロであるなら、Lengthは1、2、または3歳であるに違いありません。
Prefix Length
8-bit unsigned integer. The number of leading bits in
the Prefix that are valid. The value ranges from 0 to
128. The Prefix field is 0, 8, or 16 octets depending on
Length.
Lengthを前に置いてください。8ビットの符号のない整数。 有効なPrefixの主なビットの数。 値は0〜128まで及びます。 8、または16の八重奏がLengthによって、Prefix分野は0です。
Prf (Route Preference)
2-bit signed integer. The Route Preference indicates
whether to prefer the router associated with this prefix
over others, when multiple identical prefixes (for
different routers) have been received. If the Reserved
(10) value is received, the Route Information Option MUST
be ignored.
Prf(ルートPreference)の2ビットは整数に署名しました。 Route Preferenceは、他のものの上でこの接頭語に関連しているルータを好むかどうかを示します、複数の同じ接頭語(異なったルータのための)を受け取ったとき。 Reserved(10)値が受け取られているなら、Route情報Optionを無視しなければなりません。
Draves & Thaler Standards Track [Page 5] RFC 4191 Router Preferences and More-Specific Routes November 2005
Dravesとターレル規格は2005年11月にRFC4191ルータ好みと、より特定のルートを追跡します[5ページ]。
Resvd (Reserved)
Two 3-bit unused fields. They MUST be initialized to
zero by the sender and MUST be ignored by the receiver.
2つのResvd(予約される)の3ビットの未使用の分野。 それらを送付者がゼロに初期化しなければならなくて、受信機で無視しなければなりません。
Route Lifetime
32-bit unsigned integer. The length of time in seconds
(relative to the time the packet is sent) that the prefix
is valid for route determination. A value of all one
bits (0xffffffff) represents infinity.
Lifetimeを発送してください。32ビットの符号のない整数。 ルート決断に、接頭語が有効であることの秒(時間に比例して、パケットを送る)の時間の長さ。 すべての1ビット(0xffffffff)の価値は無限を表します。
Prefix Variable-length field containing an IP address or a
prefix of an IP address. The Prefix Length field
contains the number of valid leading bits in the prefix.
The bits in the prefix after the prefix length (if any)
are reserved and MUST be initialized to zero by the
sender and ignored by the receiver.
IPアドレスかIPアドレスの接頭語を含むVariable-長さの分野を前に置いてください。 Prefix Length分野は接頭語の有効な主なビットの数を含んでいます。 接頭語の長さ(もしあれば)の後の接頭語のビットを予約されていて、送付者によってゼロに初期化されて、受信機で無視しなければなりません。
Routers MUST NOT include two Route Information Options with the same Prefix and Prefix Length in the same Router Advertisement.
ルータは同じRouter Advertisementに同じPrefixとPrefix Lengthと2Route情報Optionsを含んではいけません。
Discussion:
議論:
There are several reasons for using a new Route Information Option instead of using flag bits to overload the existing Prefix Information Option:
既存のPrefix情報Optionを積みすぎるフラグビットを使用することの代わりに新しいRoute情報Optionを使用するいくつかの理由があります:
1. Prefixes will typically only show up in one option, not both, so a
new option does not introduce duplication.
1. 接頭語が両方ではなく、1つのオプションで通常現れるだけであるので、新しいオプションは複製を導入しません。
2. The Route Information Option is typically 16 octets while the
Prefix Information Option is 32 octets.
2. Prefix情報Optionは32の八重奏ですが、通常、Route情報Optionは16の八重奏です。
3. Using a new option may improve backwards-compatibility with some
host implementations.
3. 新しいオプションを使用すると、いくつかのホスト導入との遅れている互換性は改良されるかもしれません。
3. Conceptual Model of a Host
3. ホストの概念モデル
There are three possible conceptual models for a host implementation of default router preferences and more-specific routes, corresponding to different levels of support. We refer to these as type A, type B, and type C.
デフォルトルータ好みと、より特定のルートのホスト導入のための3人の可能な概念モデルがいます、異なったレベルのサポートに対応しています。 私たちは、タイプAにこれらについて言及して、Bをタイプして、Cをタイプします。
3.1. Conceptual Data Structures for Hosts
3.1. ホストにとって、概念的なデータ構造
Type A hosts ignore default router preferences and more-specific routes. They use the conceptual data structures described in Neighbor Discovery [RFC2461].
タイプAホストはデフォルトルータ好みと、より特定のルートを無視します。 彼らはNeighborディスカバリー[RFC2461]で説明された概念的なデータ構造を使用します。
Draves & Thaler Standards Track [Page 6] RFC 4191 Router Preferences and More-Specific Routes November 2005
Dravesとターレル規格は2005年11月にRFC4191ルータ好みと、より特定のルートを追跡します[6ページ]。
Type B hosts use a Default Router List augmented with preference values, but ignore all Route Information Options. They use the Default Router Preference value in the Router Advertisement header. They ignore Route Information Options.
タイプBホストは、好みの値に従って増大するDefault Router Listを使用しますが、すべてのRoute情報Optionsを無視します。 彼らはRouter AdvertisementヘッダーでDefault Router Preference値を使用します。 彼らはRoute情報Optionsを無視します。
Type C hosts use a Routing Table instead of a Default Router List. (The Routing Table may also subsume the Prefix List, but that is beyond the scope of this document.) Entries in the Routing Table have a prefix, prefix length, preference value, lifetime, and next- hop router. Type C hosts use both the Default Router Preference value in the Router Advertisement header and Route Information Options.
タイプCホストはDefault Router Listの代わりにルート設定Tableを使用します。 (また、ルート設定TableはPrefix Listを包括するかもしれませんが、それはこのドキュメントの範囲を超えています。) ルート設定Tableにおけるエントリーには、接頭語、接頭語の長さ、好みの値、生涯、および次のホップルータがあります。 タイプCホストはRouter AdvertisementヘッダーのDefault Router Preference値とRoute情報Optionsの両方を使用します。
When a type C host receives a Router Advertisement, it modifies its Routing Table as follows. When processing a Router Advertisement, a type C host first updates a ::/0 route based on the Router Lifetime and Default Router Preference in the Router Advertisement message header. Then as the host processes Route Information Options in the Router Advertisement message body, it updates its routing table for each such option. The Router Preference and Lifetime values in a ::/0 Route Information Option override the preference and lifetime values in the Router Advertisement header. Updating each route is done as follows. A route is located in the Routing Table based on the prefix, prefix length, and next-hop router. If the received route's lifetime is zero, the route is removed from the Routing Table if present. If a route's lifetime is non-zero, the route is added to the Routing Table if not present and the route's lifetime and preference is updated if the route is already present.
タイプCホストがRouter Advertisementを受け取るとき、それは以下のルート設定Tableを変更します。 Router Advertisementを処理するとき、タイプCホストは最初に、aをアップデートします:、:Router Advertisementメッセージヘッダーの/Router Lifetimeに基づく0ルートとDefault Router Preference。 ホストがRouter Advertisementメッセージボディーでそして、Route情報Optionsを処理するとき、それはそのような各オプションのための経路指定テーブルをアップデートします。 Router PreferenceとLifetimeはaで以下を評価します:/0ルート情報OptionはRouter Advertisementヘッダーで好みと生涯値をくつがえします。 各ルートをアップデートするのは以下の通り完了しています。 ルートは接頭語、接頭語の長さ、および次のホップルータに基づくルート設定Tableで位置しています。 容認されたルートの寿命がゼロであるなら、存在しているなら、ルートはルート設定Tableから取り外されます。 ルートの寿命が非ゼロであるなら、ルート設定Tableか現在にルートを追加します、そして、ルートが既に存在しているなら、ルートの生涯と好みをアップデートします。
For example, suppose hosts receive a Router Advertisement from router X with a Router Lifetime of 100 seconds and a Default Router Preference of Medium. The body of the Router Advertisement contains a Route Information Option for ::/0 with a Route Lifetime of 200 seconds and a Route Preference of Low. After processing the Router Advertisement, a type A host will have an entry for router X in its Default Router List with a lifetime of 100 seconds. If a type B host receives the same Router Advertisement, it will have an entry for router X in its Default Router List with a Medium preference and a lifetime of 100 seconds. A type C host will have an entry in its Routing Table for ::/0 -> router X, with a Low preference and a lifetime of 200 seconds. During processing of the Router Advertisement, a type C host MAY have a transient state, in which it has an entry in its Routing Table for ::/0 -> router X with a Medium preference and a lifetime of 100 seconds.
例えば、ホストが100秒のRouter LifetimeとMediumのDefault Router Preferenceと共にルータXからRouter Advertisementを受け取ると仮定してください。 Router Advertisementのボディーは以下のためにRoute情報Optionを含みます:200秒のRoute LifetimeとLowのRoute Preferenceがある/0。 Router Advertisementを処理した後に、タイプAホストは100秒の生涯と共にDefault Router ListにルータXのためのエントリーを持つでしょう。 タイプBホストが同じRouter Advertisementを受け取ると、それはMedium優先と100秒の生涯と共にDefault Router ListにルータXのためのエントリーを持つでしょう。 タイプCホストは以下のためにルート設定Tableにエントリーを持つでしょう:Low優先と200秒の生涯がある/0->ルータX。 Router Advertisementの処理の間、タイプCホストには、一時的な状態があるかもしれません:(そこでは、それが以下のためにルート設定Tableにエントリーを持っています)。Medium優先と100秒の生涯がある/0->ルータX。
Draves & Thaler Standards Track [Page 7] RFC 4191 Router Preferences and More-Specific Routes November 2005
Dravesとターレル規格は2005年11月にRFC4191ルータ好みと、より特定のルートを追跡します[7ページ]。
3.2. Conceptual Sending Algorithm for Hosts
3.2. ホストにとって、概念的な送付アルゴリズム
Type A hosts use the conceptual sending algorithm described in Neighbor Discovery [RFC2461].
タイプAホストはNeighborディスカバリー[RFC2461]で説明された概念的な送付アルゴリズムを使用します。
When a type B host does next-hop determination and consults its Default Router List, it primarily prefers reachable routers over non-reachable routers and secondarily uses the router preference values. If the host has no information about the router's reachability, then the host assumes the router is reachable.
タイプBホストが次のホップ決断をして、Default Router Listに相談するとき、それは、非届いているルータより主として届いているルータを好んで、二次的に、ルータ好みの値を使用します。 ホストにルータの可到達性の情報が全くないなら、ホストは、ルータに届いていると仮定します。
When a type C host does next-hop determination and consults its Routing Table for an off-link destination, it searches its routing table to find the route with the longest prefix that matches the destination, using route preference values as a tie-breaker if multiple matching routes have the same prefix length. If the best route points to a non-reachable router, this router is remembered for the algorithm described in Section 3.5 below, and the next best route is consulted. This check is repeated until a matching route is found that points to a reachable router, or no matching routes remain. Again, if the host has no information about the router's reachability, then the host assumes the router is reachable.
タイプCホストが次のホップ決断をして、オフリンクの目的地にルート設定Tableに相談するとき、目的地に合っている最も長い接頭語でルートを見つけるために経路指定テーブルを捜します、複数の合っているルートに同じ接頭語の長さがあるならタイブレークとしてルート好みの値を使用して。 最も良いルートが非届いているルータを示すなら、このルータは以下のセクション3.5で説明されたアルゴリズムのために覚えていられます、そして、次の最も良いルートは相談されます。 届いているルータを示す合っているルートが見つけられるか、または合っているルートが全く残らないまで、このチェックは繰り返されます。 一方、ホストにルータの可到達性の情報が全くないなら、ホストは、ルータに届いていると仮定します。
If there are no routes matching the destination (i.e., no default routes and no more-specific routes), then a type C host SHOULD discard the packet and report a Destination Unreachable/No Route To Destination error to the upper layer.
目的地(すなわち、デフォルトルートがなくてまたより特定のルートがない)に合っているルートが全くなければ、タイプCホストSHOULDはパケットを捨てて、Destination Unreachable/いいえ、Route To Destination誤りを上側の層に報告します。
3.3. Destination Cache Management
3.3. 目的地キャッシュ管理
When a type C host processes a Router Advertisement and updates its conceptual Routing Table, it MUST invalidate or remove Destination Cache Entries and redo next-hop determination for destinations affected by the Routing Table changes.
タイプCホストがRouter Advertisementを処理して、概念的なルート設定Tableをアップデートすると、それは、ルート設定Table変化で影響を受ける目的地に、Destination Cache Entriesを無効にするか、または取り外して、次のホップ決断をやり直さなければなりません。
3.4. Client Configurability
3.4. クライアントConfigurability
Type B and C hosts MAY be configurable with preference values that override the values in Router Advertisements received. This is especially useful for dealing with routers that may not support preferences.
Bをタイプしてください。そうすれば、Cホストは受け取られたRouter Advertisementsで値をくつがえす好みの値で構成可能であってもよいです。 これは特に好みをサポートしないかもしれないルータに対処することの役に立ちます。
3.5. Router Reachability Probing
3.5. ルータ可到達性の調べ
When a host avoids using any non-reachable router X and instead sends a data packet to another router Y, and the host would have used router X if router X were reachable, then the host SHOULD probe each such router X's reachability by sending a single Neighbor
ホストがどんな非届いているルータXも使用するのを避けて、代わりに別のルータYにデータ・パケットを送って、ルータXが届くならホストがルータXを使用して、次に、ホストSHOULDが独身のNeighborを送ることによってそのような各ルータXの可到達性を調べるとき
Draves & Thaler Standards Track [Page 8] RFC 4191 Router Preferences and More-Specific Routes November 2005
Dravesとターレル規格は2005年11月にRFC4191ルータ好みと、より特定のルートを追跡します[8ページ]。
Solicitation to that router's address. A host MUST NOT probe a router's reachability in the absence of useful traffic that the host would have sent to the router if it were reachable. In any case, these probes MUST be rate-limited to no more than one per minute per router.
そのルータのアドレスへの懇願。 それが届くなら、ホストはホストがルータに送った役に立つトラフィックがないときルータの可到達性を調べてはいけないでしょうに。 どのような場合でも、これらの徹底的調査はレートで1分あたり1つ未満にルータ単位で限らなければなりません。
This requirement allows the host to discover when router X becomes reachable and to start using router X at that time. Otherwise, the host might not notice router X's reachability and continue to use the less-desirable router Y until the next Router Advertisement is sent by X. Note that the router may have been unreachable for reasons other than being down (e.g., a switch in the middle being down), so it may be up to 30 minutes (the maximum advertisement period) before the next Router Advertisement would be sent.
この要件で、ホストをルータXがいつ届くようになるかを発見して、その時、ルータXを使用し始めます。 ホストが、さもなければ、ルータXの可到達性に気付いて、ルータが下がっているのを除いた理由(例えば、下がっている中央のスイッチ)で手が届かなくあったかもしれなくそれほど望ましくない次のRouter AdvertisementまでのルータYがX.Noteによって送られる使用に続けないかもしれないので、(最大の広告の期間)最大30分次のRouter Advertisementを送るまでかかるかもしれません。
For a type A host (following the algorithm in [RFC2461]), no probing is needed since all routers are equally preferable. A type B or C host, on the other hand, explicitly probes unreachable, preferable routers to notice when they become reachable again.
タイプAホスト([RFC2461]のアルゴリズムに従う)にとって、すべてのルータが等しく望ましいので、調べは必要ではありません。 他方では、タイプBかCホストが、それらがいつ再び届くようになるかに気付くように明らかに手の届かなくて、望ましいルータを調べます。
3.6. Example
3.6. 例
Suppose a type C host has four entries in its Routing Table:
タイプCホストがルート設定Tableに4つのエントリーを持っていると仮定してください:
::/0 -> router W with a Medium preference
2002::/16 -> router X with a Medium preference
2001:db8::/32-> router Y with a High preference
2001:db8::/32-> router Z with a Low preference
::a Medium好み2002がある/0->ルータW:、:a Medium好み2001: db8がある/16->ルータX:、:a High好み2001: db8がある/の32>のルータY:、:Low優先がある/の32>のルータZ
and the host is sending to 2001:db8::1, an off-link destination. If all routers are reachable, then the host will choose router Y. If router Y is not reachable, then router Z will be chosen and the reachability of router Y will be probed. If routers Y and Z are not reachable, then router W will be chosen and the reachability of routers Y and Z will be probed. If routers W, Y, and Z are all not reachable, then the host should use Y while probing the reachability of W and Z. Router X will never be chosen because its prefix does not match the destination.
そして、ホストは: db8を2001に送ります:、:1 オフリンクの目的地。 すべてのルータが届くと、ホストはルータY.を選ぶでしょう。IfルータYは届いていません、そして、次に、ルータZは選ばれるでしょう、そして、ルータYの可到達性は調べられるでしょう。 ルータYとZが届かないと、ルータWは選ばれるでしょう、そして、ルータYとZの可到達性は調べられるでしょう。 ルータW、Y、およびZがすべて届かないなら、接頭語が目的地に合っていないのでWの可到達性を調べて、Z.Router Xが選ばれている間、ホストはYを決して使用するべきではありません。
4. Router Configuration
4. ルータ構成
Routers SHOULD NOT advertise preferences or routes by default. In particular, they SHOULD NOT "dump out" their entire routing table to hosts.
ルータSHOULD NOTはデフォルトで好みかルートの広告を出します。 特にそれら、SHOULD NOTはそれらの全体の経路指定テーブルをホストに「外では、どさっと落とします」。
Routers MAY have a configuration mode in which an announcement of a specific prefix is dependent on a specific condition, such as operational status of a link or presence of the same or another
ルータには、特定の接頭語の発表が特定の条件に依存している構成モードがあるかもしれません、リンクの操作上の状態や同じくらいか別のものの存在のように
Draves & Thaler Standards Track [Page 9] RFC 4191 Router Preferences and More-Specific Routes November 2005
Dravesとターレル規格は2005年11月にRFC4191ルータ好みと、より特定のルートを追跡します[9ページ]。
prefix in the routing table installed by another source, such as a dynamic routing protocol. If done, router implementations SHOULD make sure that announcement of prefixes to hosts is decoupled from the routing table dynamics to prevent an excessive load on hosts during periods of routing instability. In particular, unstable routes SHOULD NOT be announced to hosts until their stability has improved.
経路指定テーブルの接頭語はダイナミックルーティングプロトコルなどの別の源によってインストールされました。 するなら、SHOULDがホストへの接頭語のその発表がルーティングから衝撃を吸収されるのを確信するようにするルータ実装は、ルーティングの不安定性の期間、ホストの上で負担過重を防ぐために力学を見送ります。 彼らの安定性が向上するまで、特定の、そして、不安定なルートSHOULD NOTでホストに発表されてください。
Routers SHOULD NOT send more than 17 Route Information Options in Router Advertisements per link. This arbitrary bound is meant to reinforce that relatively few and carefully selected routes should be advertised to hosts.
ルータSHOULD NOTは1リンクあたりのRouter Advertisementsで17Route情報Optionsを送ります。 この任意のバウンドは比較的わずかな状態でそれを補強することになっています、そして、慎重に選択されたルートのホストに広告を出すべきです。
The preference values (both Default Router Preferences and Route Preferences) SHOULD NOT be routing metrics or automatically derived from metrics: the preference values SHOULD be configured.
測定基準を発送しているか、または測定基準から自動的に引き出されて、好みはSHOULD NOTを評価します(Default Router PreferencesとRoute Preferencesの両方): 構成されていて、好みはSHOULDを評価します。
The information contained in Router Advertisements may change through the actions of system management. For instance, the lifetime or preference of advertised routes may change, or new routes could be added. In such cases, the router MAY transmit up to MAX_INITIAL_RTR_ADVERTISEMENTS unsolicited advertisements, using the same rules as in [RFC2461]. When ceasing to be an advertising interface and sending Router Advertisements with a Router Lifetime of zero, the Router Advertisement SHOULD also set the Route Lifetime to zero in all Route Information Options.
Router Advertisementsに含まれた情報はシステム管理の動作で変化するかもしれません。 例えば、広告を出しているルートの生涯か好みが変化するかもしれませんか、または新しいルートは加えることができました。 ルータは、同じくらい使用するのが[RFC2461]のようにそのような場合統治されるとマックス_INITIAL_RTR_ADVERTISEMENTS未承諾広告まで伝えるかもしれません。 また、広告インタフェースであることをやめて、ゼロのRouter LifetimeとRouter Advertisementsを送るとき、Router Advertisement SHOULDは、Route LifetimeにすべてのRouteで情報Optionsのゼロを合わせるように設定します。
4.1. Guidance to Administrators
4.1. 管理者への指導
The High and Low (non-default) preference values should only be used when someone with knowledge of both routers and the network topology configures them explicitly. For example, it could be a common network administrator, or it could be a customer request to different administrators managing the routers.
ルータとネットワーク形態の両方に関する知識をもっているだれかが明らかにそれらを構成すると、HighとLow(非デフォルト)好みの値は使用されるだけであるべきです。 例えば、それは一般的なネットワーク管理者であるかもしれませんかそれがルータを管理する異なった管理者への顧客の要求であるかもしれません。
As one exception to this general rule, the administrator of a router that does not have a connection to the Internet, or is connected through a firewall that blocks general traffic, should configure the router to advertise a Low Default Router Preference.
この一般的な規則への1つの例外として、インターネットには接続がないか、または一般交通を妨げるファイアウォールを通して関連づけられるルータの管理者は、Low Default Router Preferenceの広告を出すためにルータを構成するべきです。
In addition, the administrator of a router should configure the router to advertise a specific route for the site prefix of the network(s) to which the router belongs. The administrator may also configure the router to advertise specific routes for directly connected subnets and any shorter prefixes for networks to which the router belongs.
さらに、ルータの管理者は、ルータが属するネットワークのサイト接頭語のために特定のルートの広告を出すためにルータを構成するべきです。 また、管理者は、直接接続されたサブネットのための特定のルートとどんなルータが属するネットワークには、より短い接頭語も広告を出すためにルータを構成するかもしれません。
Draves & Thaler Standards Track [Page 10] RFC 4191 Router Preferences and More-Specific Routes November 2005
Dravesとターレル規格は2005年11月にRFC4191ルータ好みと、より特定のルートを追跡します[10ページ]。
For example, if a home user sets up a tunnel into a firewalled corporate network, the access router on the corporate network end of the tunnel should advertise itself as a default router, but with a Low preference. Furthermore, the corporate router should advertise a specific route for the corporate site prefix. The net result is that destinations in the corporate network will be reached via the tunnel, and general Internet destinations will be reached via the home ISP. Without these mechanisms, the home machine might choose to send Internet traffic into the corporate network or corporate traffic into the Internet, leading to communication failure because of the firewall.
例えば、家庭でのユーザがfirewalled企業ネットワークにトンネルを設立するなら、トンネルの企業ネットワーク端のアクセスルータは、デフォルトルータとして自分を売り込みますが、Low優先で自分を売り込むべきです。 その上、法人のルータは法人のサイト接頭語のために特定のルートの広告を出すべきです。 最終結果は企業ネットワークにおける目的地にトンネルを通って達して、ホームISPで一般的なインターネットの目的地に達するということです。 これらのメカニズムがなければ、ホームマシンは、インターネットへの企業ネットワークか法人のトラフィックにインターネットトラフィックを送るのを選ぶかもしれません、ファイアウォールのために通信障害に通じて。
It is worth noting that the network administrator setting up preferences and/or more specific routes in Routing Advertisements typically does not know which kind of nodes (Type A, B, and/or C) will be connected to its links. This requires that the administrator configure the settings that will work in an optimal fashion regardless of which kinds of nodes will be attached. Two examples of how to do so follow.
ルート設定Advertisementsの好み、そして/または、、より特定のルートをセットアップしているネットワーク管理者が、どの種類のノード(A、B、そして/または、Cをタイプする)がリンクに接続されるかを通常知らないことに注意する価値があります。 これは、管理者がどの種類のノードが添付されるかにかかわらず最適のファッションで働いている設定を構成するのを必要とします。 どうそうするかに関する2つの例が従います。
5. Examples
5. 例
5.1. Best Router for ::/0 vs Router Least Likely to Redirect
5.1. 以下のための最も良いルータ:おそらく向け直すルータ最少に対する/0
The best router for the default route is the router with the best route toward the wider Internet. The router least likely to redirect traffic depends on the actual traffic usage. The two concepts can be different when the majority of communication actually needs to go through some other router.
デフォルトルートへの最も良いルータは、より広いインターネットに向かった最も良いルートがあるルータです。 トラフィックを最も向け直しそうにないルータは実際のトラフィック用法によります。 コミュニケーションの大部分が、実際にある他のルータに直面する必要があるとき、2つの概念が異なっている場合があります。
For example, consider a situation in which you have a link with two routers, X and Y. Router X is the best for 2002::/16. (It's your 6to4 site gateway.) Router Y is the best for ::/0. (It connects to the native IPv6 Internet.) Router X forwards native IPv6 traffic to router Y; router Y forwards 6to4 traffic to router X. If most traffic from this site is sent to 2002:/16 destinations, then router X is the one least likely to redirect.
例えば、2002に、あなたが2つのルータ、X、およびY.Router Xとのリンクを持っている状況が最も良いと考えてください:、:/16. (それはあなたの6to4サイトゲートウェイです。) 以下に、ルータYは最も良いです:/0. (それはネイティブのIPv6インターネットに接続します。) ルータXはネイティブのIPv6トラフィックをルータYに送ります。 ルータYはこのサイトからのほとんどのトラフィックが送られるルータX.Ifへの6to4トラフィックを2002に送ります: /16目的地、そして、ルータXはおそらく向け直す1つの最少です。
To make type A hosts work well, both routers should advertise themselves as default routers. In particular, if router Y goes down, type A hosts should send traffic to router X to maintain 6to4 connectivity, so router X and router Y need to be default routers.
タイプAホストをうまくいかせるように、両方のルータはデフォルトルータとして自分を売り込むべきです。 ルータYが落ちるなら、特に、タイプAホストが6to4の接続性を維持するためにルータXにトラフィックを送るべきであるので、ルータXとルータYは、デフォルトルータである必要があります。
To make type B hosts work well, router X should advertise itself with a High default router preference. This will cause type B hosts to prefer router X, minimizing the number of redirects.
タイプBホストをうまくいかせるように、ルータXはHighデフォルトルータ優先で自分を売り込むべきです。 これは数を最小にするルータXを好むホストをタイプBに引き起こすでしょう。向け直します。
Draves & Thaler Standards Track [Page 11] RFC 4191 Router Preferences and More-Specific Routes November 2005
Dravesとターレル規格は2005年11月にRFC4191ルータ好みと、より特定のルートを追跡します[11ページ]。
To make type C hosts work well, router X should in addition advertise the ::/0 route with a Low preference and the 2002::/16 route with a Medium preference. A type C host will end up with three routes in its routing table: ::/0 -> router X (Low), ::/0 -> router Y (Medium), 2002::/16 -> router X (Medium). It will send 6to4 traffic to router X and other traffic to router Y. Type C hosts will not cause any redirects.
タイプCホストをうまくいかせるように、ルータXがさらに、広告を出すべきである、:、:/0はLow優先と2002で以下を発送します:Medium優先がある/16ルート。 タイプCホストは経路指定テーブルの3つのルートで終わるでしょう: ::/0->ルータX(低い)、:、:/0->ルータY(媒体)、2002:、:/16->ルータX(媒体。) それはルータXへのトラフィックとルータY.Type Cホストへの他のトラフィックがそうしない6to4にいずれも向け直す原因を送るでしょう。
Note that when type C hosts process the Router Advertisement from router X, the Low preference for ::/0 overrides the High default router preference. If the ::/0 specific route were not present, then a type C host would apply the High default router preference to its ::/0 route to router X.
タイプCホストがルータX、以下のためのLow好みからRouter Advertisementを処理するときにはそれに注意してください:/0はHighデフォルトルータ好みをくつがえします。 :、:/0特定のルートは存在していません、タイプCホストがHighデフォルトルータ好みを適用するその時、それ、:、:/0はXをルータに発送します。
5.2. Multi-Homed Host and Isolated Network
5.2. マルチ、家へ帰り、ホストと孤立しているネットワーク
In another scenario, a multi-homed host is connected to the Internet via router X on one link and to an isolated network via router Y on another link. The multi-homed host might have a tunnel into a firewalled corporate network, or it might be directly connected to an isolated test network.
別のシナリオ、a、マルチ、家へ帰り、ホストは1個のリンクの上のルータXを通したインターネットと、そして、別のリンクの上のルータYを通した孤立しているネットワークに接続されます。 マルチ、家へ帰り、ホストがfirewalled企業ネットワークにトンネルを持っているか、またはそれは直接孤立しているテストネットワークに関連づけられるかもしれません。
In this situation, a type A multi-homed host (which has no default router preferences or more-specific routes) will have no way to intelligently choose between routers X and Y on its Default Router List. Users of the host will see unpredictable connectivity failures, depending on the destination address and the choice of router.
この状況、タイプA、マルチ、家へ帰り、ホスト(デフォルトルータ好みかどんなより特定のルートも持っていない)には、Default Router Listで知的にルータXとYを選ぶ方法が全くないでしょう。 送付先アドレスとルータの選択によって、ホストのユーザは予測できない接続性失敗を見るでしょう。
If the routers are configured appropriately, a multi-homed type B host in this same situation would have stable Internet connectivity, but would have no connectivity to the isolated test network.
ルータは適切に構成されます、a、マルチ、家へ帰り、この同じ状況におけるタイプBホストが、安定したインターネットの接続性を持っているでしょうが、孤立しているテストネットワークに接続性は全く持っていないでしょう。
If the routers are configured appropriately, a multi-homed type C host in this same situation can correctly choose between routers X and Y. For example, router Y on the isolated network should advertise a Route Information Option for the isolated network prefix. It might not advertise itself as a default router at all (zero Router Lifetime), or it might advertise itself as a default router with a Low preference. Router X should advertise itself as a default router with a Medium preference.
ルータは適切に構成されます、a、マルチ、家へ帰り、この同じ状況におけるタイプCホストが正しくルータXとY.Forの例を選ぶことができて、孤立しているネットワークのルータYは孤立しているネットワーク接頭語のためにRoute情報Optionの広告を出すべきです。 それがデフォルトルータとしてすべての(Router Lifetimeがありません)で自分を売り込まないかもしれませんか、またはそれはデフォルトルータとしてLow優先で自分を売り込むかもしれません。 ルータXはデフォルトルータとしてMedium優先で自分を売り込むべきです。
6. Security Considerations
6. セキュリティ問題
A malicious node could send Router Advertisement messages, specifying a High Default Router Preference or carrying specific routes, with the effect of pulling traffic away from legitimate routers. However, a malicious node could easily achieve this same effect in other ways.
悪意があるノードはメッセージをRouter Advertisementに送るかもしれません、High Default Router Preferenceを指定するか、または特定のルートを運んで、トラフィックより正統のルータから引きちぎるという効果で。 しかしながら、悪意があるノードは容易に他の方法でこの同じ効果を実現するかもしれません。
Draves & Thaler Standards Track [Page 12] RFC 4191 Router Preferences and More-Specific Routes November 2005
Dravesとターレル規格は2005年11月にRFC4191ルータ好みと、より特定のルートを追跡します[12ページ]。
For example, it could fabricate Router Advertisement messages with a zero Router Lifetime from the other routers, causing hosts to stop using the other routes. By advertising a specific prefix, this attack could be carried out in a less noticeable way. However, this attack has no significant incremental impact on Internet infrastructure security.
例えば、どんなRouter Lifetimeと共にも他のルータからRouter Advertisementメッセージを作ることができませんでした、ホストが、他のルートを使用するのを止めることを引き起こして。 特定の接頭語の広告を出すことによって、それほどめぼしくない方法でこの攻撃を行うことができるでしょう。 しかしながら、この攻撃はインターネット基盤セキュリティでどんな重要な増加の影響も与えません。
A malicious node could also include an infinite lifetime in a Route Information Option causing the route to linger indefinitely. A similar attack already exists with Prefix Information Options in RFC 2461, where a malicious node causes a prefix to appear as on-link indefinitely, resulting in a lack of connectivity if it is not. In contrast, an infinite lifetime in a Route Information Option will cause router reachability probing to continue indefinitely, but will not result in a lack of connectivity.
また、悪意があるノードはルートを無期限に長居させるRoute情報Optionに無限の生涯を含むかもしれません。 同様の攻撃はPrefix情報Optionsと共にRFC2461に既に存在しています、それがもたらさないなら接続性の不足をもたらして。(悪意があるノードで、そこでは、接頭語が同じくらいリンクに無期限に現れます)。 対照的に、Route情報Optionの無限の寿命は、ルータ可到達性の調べが無期限に続くことを引き起こしますが、接続性の不足をもたらさないでしょう。
Similarly, a malicious node could also try to overload hosts with a large number of routes in Route Information Options, or with very frequent Route Advertisements. Again, this same attack already exists with Prefix Information Options.
また、同様に、悪意があるノードはRoute情報Optionsの多くのルート、または非常に頻繁なRoute Advertisementsのホストを積みすぎようとするかもしれません。 一方、この同じ攻撃はPrefix情報Optionsと共に既に存在しています。
[RFC3756] provides more details on the trust models, and there is work in progress in the SEND WG on securing router discovery messages that will address these problems.
[RFC3756]は信頼モデルに関するその他の詳細を提供します、そして、処理中の作業がルータ発見がこれらのその問題を訴えるメッセージであると機密保護するときのSEND WGにあります。
7. IANA Considerations
7. IANA問題
Section 2.3 defines a new Neighbor Discovery [RFC2461] option, the Route Information Option, which has been assigned the value 24 within the numbering space for IPv6 Neighbor Discovery Option Formats.
セクション2.3は新しいNeighborディスカバリー[RFC2461]オプション、値24がIPv6 NeighborディスカバリーOption Formatsのために付番スペースの中で割り当てられたRoute情報Optionを定義します。
8. Acknowledgements
8. 承認
The authors would like to acknowledge the contributions of Balash Akbari, Steve Deering, Robert Elz, Tony Hain, Bob Hinden, Christian Huitema, JINMEI Tatuya, Erik Nordmark, Pekka Savola, Kresimir Segaric, and Brian Zill. The packet diagrams are derived from Neighbor Discovery [RFC2461].
作者はBalash Akbari、スティーブ・デアリング、ロバートElz、トニー・ハイン、ボブHinden、クリスチャンのHuitema、JINMEI Tatuya、エリックNordmark、ペッカSavola、Kresimir Segaric、およびブライアンZillの貢献を承諾したがっています。 Neighborディスカバリー[RFC2461]からパケットダイヤグラムを得ます。
9. Normative References
9. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998.
[RFC2461]Narten、T.、Nordmark、E.、およびW.シンプソン、「IPバージョン6(IPv6)のための隣人発見」、RFC2461、1998年12月。
Draves & Thaler Standards Track [Page 13] RFC 4191 Router Preferences and More-Specific Routes November 2005
Dravesとターレル規格は2005年11月にRFC4191ルータ好みと、より特定のルートを追跡します[13ページ]。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC3775] ジョンソンとD.とパーキンス、C.とJ.Arkko、「IPv6"、RFC3775、2004年6月の移動性サポート。」
10. Informative References
10. 有益な参照
[RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080,
January 1997.
[RFC2080] マルキンとG.とR.Minnear、「IPv6"、RFC2080、1997年1月のためのRIPng。」
[RFC2893] Gilligan, R. and E. Nordmark, "Transition Mechanisms for
IPv6 Hosts and Routers", RFC 2893, August 2000.
[RFC2893] ギリガンとR.とE.Nordmark、「IPv6ホストとルータのための変遷メカニズム」、RFC2893、2000年8月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via
IPv4 Clouds", RFC 3056, February 2001.
[RFC3056] 大工とB.とK.ムーア、「IPv4 Cloudsを通したIPv6 Domainsの接続」、RFC3056、2001年2月。
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756, May
2004.
[RFC3756] Nikander、P.、ケンフ、J.、およびE.Nordmark、「IPv6隣人発見(ノースダコタ)信頼モデルと脅威」(RFC3756)は2004がそうするかもしれません。
Authors' Addresses
作者のアドレス
Richard Draves Microsoft Research One Microsoft Way Redmond, WA 98052
リチャードDravesマイクロソフトは1つのマイクロソフト方法でレッドモンド、ワシントン 98052について研究します。
Phone: +1 425 706 2268 EMail: richdr@microsoft.com
以下に電話をしてください。 +1 2268年の425 706メール: richdr@microsoft.com
Dave Thaler Microsoft One Microsoft Way Redmond, WA 98052
デーヴターレルマイクロソフト1マイクロソフト道、レッドモンド、ワシントン 98052
Phone: +1 425 703 8835 EMail: dthaler@microsoft.com
以下に電話をしてください。 +1 8835年の425 703メール: dthaler@microsoft.com
Draves & Thaler Standards Track [Page 14] RFC 4191 Router Preferences and More-Specific Routes November 2005
Dravesとターレル規格は2005年11月にRFC4191ルータ好みと、より特定のルートを追跡します[14ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Draves & Thaler Standards Track [Page 15]
Dravesとターレル標準化過程[15ページ]
一覧
スポンサーリンク
