Network Working Group R. Draves
Request for Comments: 4191 D. Thaler
Category: Standards Track Microsoft
November 2005
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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（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.
この文書では、ホストにルーターからデフォルトルータ好みと、より特定のルートを通信するためのルータアドバタイズメントメッセージにオプションの拡張について説明します。これは、ホストがマルチホームであるとルータが異なるリンク上にある場合は特に、適切なルータを選択するホストの能力を向上させます。ホストに通知優先値と特定のルートは、管理設定を必要とします。それらは自動的にルーティングテーブルから導出されていません。
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]はデフォルトルータリストおよびプレフィクスリストを含むホストするための概念モデルを指定します。ホストはルータ要請メッセージを送信し、ルータからルータ通知メッセージを受信します。ホストはルータ通知メッセージ内の情報に基づいて、そのデフォルトルータリストおよびプレフィックスリストを読み込みます。概念的な送付アルゴリズムは、宛先アドレスがオンリンクであるとオフリンクの目的地のためのルータを選択するために、デフォルトルータリストを使用するかどうかを判断するためにプレフィックスリストを使用しています。
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.)
ホストがデフォルトルータリストに複数のルーターを持っているいくつかのネットワークトポロジでは、オフリンク先のルータの選択が重要です。いくつかの状況では、1つのルータは、宛先のための別のよりもはるかに優れた性能を提供することができます。他の状況では、間違ったルータを選択すると、通信に失敗する可能性があります。 （第5節では、これらのシナリオの具体例を与えます。）
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.
この文書では、ホストにルーターからデフォルトルータ好みと、より特定のルートを通信するための近隣探索ルータアドバタイズメントメッセージにオプションの拡張について説明します。これは、オフリンク先のために適切なルータを選択するホストの能力を向上させます。
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.
近隣探索は、ルータは、ルータのホストの選択を修正するために使用することができますリダイレクトメッセージを提供します。ルータが特定の宛先に別のルータを使用するように言って、ホストにリダイレクトメッセージを送信することができます。しかし、リダイレクト機能が単一のリンクに限定されています。一方のリンク上のルータが別のリンク上のルータにホストをリダイレクトすることはできません。したがって、リダイレクトメッセージは、ホストが適切なルータを選択し、マルチホーム（複数のインターフェイスを介して）役立ちません。
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で、ますます重要なシナリオです。イーサネットのような有線ネットワーク接続に加えて、ホストは、802.11またはBluetoothのような一つまたはそれ以上の無線接続を有していてもよいです。物理的ネットワーク接続に加えて、ホストは、仮想またはトンネルネットワーク接続を有していてもよいです。例えば、公共のインターネットへの直接接続に加えて、ホストは、企業のプライベートネットワークへのトンネルを有することができます。いくつかの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.
ルータ広告は既存の標準、ルータからホストへの通信のための安定したプロトコルであるため、我々は、ルータアドバタイズメントメッセージの代わりに、RIP [RFC2080]のようないくつかの他のプロトコルを使用しています。ホストへのルータからのメッセージトラフィックを既存の上でこの情報をピギーバックすると、ネットワークのオーバーヘッドを低減します。マルチキャストリスナ発見と近隣探索株式より一般的なルータ間の相互作用に関与することからホストを遮蔽しながら、彼らは、ホストとルータ間の相互作用を定義し、両方の性質。それはより大きな処理オーバーヘッドと頻繁にメッセージトラフィックを必要とするので、それがルート寿命を運ばないので、また、RIPは不向きです。
The mechanisms specified here are backwards-compatible, so that hosts that do not implement them continue to function as well as they did previously.
それらを実装していないホストは同様に、彼らは以前と同様に機能し続けるように、ここで指定されたメカニズムは、下位互換性があります。
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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
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:
次のように嗜好値は、2ビット符号付き整数として符号化されます。
01 High 00 Medium (default) 11 Low 10 Reserved - MUST NOT be sent
01ハイ00ミディアム（デフォルト）11低10は予約済み - 送ってはいけません
Note that implementations can treat the value as a two-bit signed integer.
実装は、2ビット符号付き整数として値を扱うことができることに留意されたいです。
Having just three values reinforces that they are not metrics and more values do not appear to be necessary for reasonable scenarios.
ただ三つの値を持つことは、彼らはメトリックではなく、より多くの値が妥当なシナリオに必要であることが表示されないことを強調しています。
The changes from Neighbor Discovery [RFC2461] Section 4.2 and [RFC3775] Section 7.1 are as follows:
次のように近隣探索[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 ...
+-+-+-+-+-+-+-+-+-+-+-+-
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（デフォルトルータ優先）2ビット符号付き整数。他のデフォルト・ルータ上でこのルータを好むかどうかを示します。ルータ寿命がゼロである場合、優先値は、送信者（00）に設定しなければならなくて、受信機で無視しなければなりません。予約（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（予約）3ビットの未使用フィールド。これは、送信者によってゼロに初期化しなければならなくて、受信機で無視しなければなりません。
Possible Options:
可能なオプション：
Route Information These options specify prefixes that are reachable via the router.
ルート情報は、これらのオプションは、ルータを経由して到達可能なプレフィックスを指定します。
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:
メッセージヘッダーの嗜好値に加えて、ルータ広告は、嗜好値と寿命と、:: / 0の経路情報オプションをも含むことができることに留意されたいです。ルータ広告ヘッダに優先値をコードするいくつかの利点を有します。
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.
セクション5.1で後述のように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.デフォルトルートのための最良のルータはまた、（一般的なケースであろう）、共通トラフィックをリダイレクトするために最も可能性がルータである場合、メッセージヘッダに優先値をコードする別のオプションを送信するよりも効率的です。
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) |
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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つのオクテットの単位で（タイプと長さフィールドを含む）オプションの長さ。 Lengthフィールドは、プレフィックスの長さに応じて1、2、または3です。プレフィックス長が64より大きい場合、長さは3でなければならないプレフィックス長が0より大きい場合、長さは、プレフィックス長がゼロである場合、長さは1、2、または3でなければならない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.
プレフィックス長8ビットの符号なし整数。有効な接頭辞の一流のビット数。値が0から128の範囲でプレフィックスフィールドは、長さに応じて0,8、または16オクテットです。
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（ルート好ましい）2ビット符号付き整数。ルート設定は（異なるルータの）複数の同一のプレフィックスが受信された他のものの上にこのプレフィックスに関連付けられているルータを好むかどうかを示します。予約（10）値を受信した場合、経路情報オプションを無視しなければなりません。
Resvd (Reserved) Two 3-bit unused fields. They MUST be initialized to zero by the sender and MUST be ignored by the receiver.
Resvd（予約）2つの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.
ルート寿命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アドレスのプレフィックスを含むプレフィックス可変長フィールド。プレフィックス長フィールドはプレフィックスに有効な先行ビットの数が含まれています。プレフィックス長（もしあれば）の後プレフィックスのビットは予約されており、送信者によってゼロに初期化し、受信機で無視しなければなりません。
Routers MUST NOT include two Route Information Options with the same Prefix and Prefix Length in the same Router Advertisement.
ルータは同じルータアドバタイズメントで同じプレフィックスとプレフィックス長を持つ2つのルート情報オプションを含んではいけません。
Discussion:
討論：
There are several reasons for using a new Route Information Option instead of using flag bits to overload the existing Prefix Information Option:
新しいルート情報オプションを使用する代わりに、既存のプレフィックス情報オプションをオーバーロードするフラグビットを使用するためのいくつかの理由があります。
1. Prefixes will typically only show up in one option, not both, so a new option does not introduce duplication.
1.プレフィックスは通常、唯一の選択肢ではなく、両方に表示されますので、新しいオプションが重複を導入しません。
2. The Route Information Option is typically 16 octets while the Prefix Information Option is 32 octets.
プレフィックス情報オプションは32オクテットである2経路情報オプションは、典型的には16オクテットです。
3. Using a new option may improve backwards-compatibility with some host implementations.
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としてこれらを参照してください。
Type A hosts ignore default router preferences and more-specific routes. They use the conceptual data structures described in Neighbor Discovery [RFC2461].
デフォルトルータ好みと、より特定のルートを無視するホストを入力します。彼らは、近隣探索[RFC2461]に記載の概念的なデータ構造を使用します。
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のホストは、プリファレンス値で拡張デフォルトルータリストを使用しますが、すべてのルート情報オプションを無視します。彼らは、ルータアドバタイズメントヘッダ内のデフォルトルータプリファレンス値を使用します。彼らは、ルート情報オプションを無視します。
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ホストは、ルーティングテーブルの代わりに、デフォルトルータリストを使用します。 （ルーティングテーブルはまた、プレフィックスリストを包摂することができるが、それはこの文書の範囲外である。）ルーティングテーブルのエントリは、プレフィックス、プレフィックス長、嗜好値、寿命、およびネクストホップルータを有します。タイプCホストがルータ広告ヘッダと経路情報オプションにおけるデフォルトルータ優先値の両方を使用します。
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ホストがルータ広告を受信した場合、以下のように、そのルーティングテーブルを変更します。ルータ通知を処理するときに、タイプCホストは、最初のルータ広告メッセージヘッダ内のルータ寿命とデフォルトルータの好みに基づいて:: / 0ルートを更新します。そして、ルータアドバタイズメントメッセージの本文内のホストプロセス経路情報オプションとして、それは、このような各オプションのためにそのルーティングテーブルを更新します。 :: / 0ルート情報オプションのルータ好みと寿命値は、ルータ広告ヘッダにおける優先と寿命値を上書き。次のように各ルートの更新が行われます。ルートは、プレフィックス、プレフィックス長、およびネクストホップルータに基づいて、ルーティングテーブル内に配置されています。受信したルートの寿命がゼロである場合に存在する場合、ルートは、ルーティングテーブルから削除されます。ルートの寿命が非ゼロである場合、経路が既に存在する場合に存在し、ルートのない寿命と嗜好が更新される場合、ルートは、ルーティングテーブルに追加されます。
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秒のルータ寿命とミディアムのデフォルトルータプリファレンスでルータXからルータ広告を受信します。ルータアドバタイズメントの本体は、200秒のルート寿命と低のルート好みに:: / 0のためのルート情報オプションが含まれています。ルータアドバタイズメントを処理した後、型のホストは、100秒の生涯とそのデフォルトルータリスト内のルータXのエントリを持つことになります。タイプBホストが同じルータ通知を受信した場合、それはミディアム好みと100秒の生涯とそのデフォルトルータリスト内のルータXのエントリを持つことになります。低有利に>ルータX、および200秒の生涯 - タイプCホストが:: / 0のためにそのルーティングテーブルのエントリを持つことになります。ミディアム有利に>ルータXと100秒の生涯 - ルーターアドバタイズの処理中に、タイプCのホストは、それが:: / 0のためにそのルーティングテーブルのエントリを持っている過渡状態を有していてもよいです。
Type A hosts use the conceptual sending algorithm described in Neighbor Discovery [RFC2461].
近隣探索[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ホストが次のホップ決意を行い、そのデフォルトルータリストを参照するとき、それは主に非到達可能なルータ上に到達可能なルータを優先し、二次ルータ優先値を使用します。ホストがルータの到達可能性に関する情報を持っていない場合、ホストは、ルータが到達可能であると仮定し。
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ホストが次のホップ決意を行い、オフリンク宛先にルーティングテーブルを参照するとき、それはタイブレーカかのようにルート優先値を使用して、先に一致する最も長い接頭辞を持つルートを見つけるために、そのルーティングテーブルを検索し複数のマッチングルートが同じプレフィックス長を有します。非到達可能なルータへの最適なルートポイントは、このルータは、以下のセクション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ホストがパケットを破棄し、上位層に送信先エラーに宛先到達不能/ Noルートを報告すべきです。
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ホストがルータ広告を処理し、その概念のルーティングテーブルを更新するとき、それは無効または削除宛先キャッシュエントリをルーティングテーブルの変更によって影響を受ける宛先のネクストホップ決意を再実行しなければなりません。
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のホストがルータ広告内の値は、受信上書き嗜好値で設定可能です。これは好みをサポートしていない可能性がルータを扱う場合に特に便利です。
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を使用していた場合は、ホストは単一を送信することにより、そのような各ルータXの到達可能性を探るべきです隣人
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.
そのルータのアドレスに懇願。ホストは、それが到達した場合、ホストがルータに送信されたであろう便利なトラフィックが存在しない場合に、ルータの到達可能性を探るてはなりません。いずれの場合においても、これらのプローブは、速度制限ルータ当たりない複数あたり分でなければなりません。
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は、ルータが、例えば（ダウンしている以外の理由でスイッチに到達不能であったかもしれないことをX.注によって送信されるまで、あまり望ましくルータYを使用し続けないかもしれません真ん中）がダウンしているので、送信される次のRouter Advertisement前30分（最大広告時間）までであり得ます。
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.
すべてのルータが等しく好適であるため、タイプ（[RFC2461]でのアルゴリズムに従って）ホストに対して、何らプロービングは必要とされません。タイプB又はCホストが、一方で、明示的にそれらが再び到達可能になったときに気づいて到達でき、好ましいルータをプローブ。
Suppose a type C host has four entries in its Routing Table:
タイプCホストがそのルーティングテーブルに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
:: / 0 - ミディアム好み2001と>ルータX - ミディアム好み2002 :: / 16とW>ルータ：DB8 :: / 32>ルータYの高優先度2001で：DB8 :: / 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.
そしてホストは、2001年に送信している：DB8 :: 1、オフリンク先を。すべてのルータが到達可能である場合、ルータYに到達できない場合、ホストはルータYを選択する、ルータZが選択されますと、ルータYの到達性がプローブされます。ルータYとZが到達可能でない場合は、ルータWが選択されますと、ルータYとZの到達可能性がプローブされます。ルータW、Y、およびZは、すべての到達可能でない場合はその接頭語が先と一致しないため、選択することはありませんWとZ.ルータXの到達可能性を探査ながら、ホストはYを使用する必要があります。
Routers SHOULD NOT advertise preferences or routes by default. In particular, they SHOULD NOT "dump out" their entire routing table to hosts.
ルータは、デフォルトでは好みやルートをアドバタイズすべきではありません。特に、彼らはホストにそのルーティングテーブル全体を「ダンプ」すべきではありません。
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 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.
ルータは、動的ルーティングのように、このような動作同一のリンクまたは存在の状態、または別のソースによってインストールルーティングテーブル内の別のプレフィックスとして、特定のプレフィックスのアナウンスメントが特定の条件に依存したコンフィギュレーションモードを有していてもよいですプロトコル。行われた場合は、ルータの実装は、ホストへのプレフィックスの発表が不安定にルーティングの期間中にホストに過度の負荷を防ぐために、ルーティングテーブルのダイナミクスから分離することを確認してください。その安定性が改善されるまでは特に、不安定なルートがホストに発表されるべきではありません。
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.
ルータは、リンクあたりのルータ広告に17の以上のルート情報オプションを送るべきではありません。拘束この任意のは、その比較的少ないと厳選されたルートがホストに通知しなければならない強化するためのものです。
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.
嗜好値（デフォルトルータの設定とルート設定の両方）のメトリックに由来自動的にルーティングメトリック、またはされるべきではない：優先値を設定する必要があります。
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.
ルータ広告に含まれている情報は、システム管理のアクションによって変更されることがあります。例えば、広告された経路の寿命や嗜好が変わることがあり、または新しいルートを追加することができます。このような場合、ルータは[RFC2461]と同じルールを使用して、迷惑広告をMAX_INITIAL_RTR_ADVERTISEMENTSまで送信することができます。広告インタフェースであることをやめると、ゼロのルータ寿命とルータ広告を送信する場合、ルータ通知はまた、すべてのルート情報オプションにゼロにルート寿命を設定する必要があります。
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.
この原則の例外として、インターネットへの接続を持っていない、またはそのブロックの一般的なトラフィックファイアウォールを介して接続されているルータの管理者は、低デフォルトルータプリファレンスを宣伝するようにルータを設定する必要があります。
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.
また、ルータの管理者は、ルータが属するネットワーク（複数可）のサイト接頭辞のための特定のルートをアドバタイズするようにルータを設定する必要があります。また、管理者は、直接接続されたサブネットとルータが属するネットワークのための任意の短いプレフィックスのための特定のルートをアドバタイズするようにルータを設定することができます。
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.
ホームユーザーは、ファイアウォール、企業ネットワークにトンネルを設定した場合、トンネルの企業ネットワーク側のアクセスルータは、デフォルトルータとしてではなく、低優先して自分自身を宣伝する必要があります。さらに、コーポレート・ルータは、企業サイトプレフィックスの特定のルートをアドバタイズする必要があります。最終結果は、企業ネットワーク内の宛先がトンネルを介して到達され、一般的なインターネットの宛先がホーム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.
ルーティング広告内のルートは、典型的には、そのリンクに接続されるノードの種類（タイプA、B、および/またはC）を知らないネットワーク管理者は、特定のプリファレンスを設定および/またはそれ以上のことは注目に値します。これにより、管理者は関係なく、ノードの種類が添付されるのに最適な形で動作する設定を構成する必要があります。そう従って行う方法の2つの例。
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.
たとえば、2つのルータ、XとYルータXが2002 :: / 16のために最善であるとのリンクを持っている状況を考えます。 （それはあなたの6to4サイトゲートウェイです。）ルーターYが:: / 0のための最善の方法です。 （これは、ネイティブのIPv6インターネットに接続されています。）ルータX Yをルータに転送し、ネイティブIPv6トラフィック;このサイトから、ほとんどのトラフィックが2002年に送られた場合、ルータXとYのルータ転送の6to4トラフィック：/ 16の宛先は、ルータXは、リダイレクト可能性が最も低いものです。
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は、ハイデフォルトルータの嗜好に自分自身を宣伝する必要があります。これは、リダイレクトの数を最小限に抑え、ルータXを好むタイプBのホストを引き起こします。
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ルートと2002 ::ミディアム好みに/ 16ルートをアドバタイズする必要があります。タイプCホストがそのルーティングテーブル内の3つのルートで終わるであろう：:: / 0 - >ルータX（低）、:: / 0 - >ルータY（中）、2002 :: / 16 - >ルータX（ミディアム）。これは、任意のリダイレクトが発生することはありませんY.タイプCホストをルータにルータXと他のトラフィックにの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からルータ通知を処理するとき、:: / 0のための低優先度が高いデフォルトルータ設定をオーバーライドすることに注意してください。 :: / 0特定のルートが存在しない場合は、タイプCホストがルータXにその:: / 0ルートに高いデフォルトルータ設定を適用します
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.
別のシナリオでは、マルチホームホストは、一つのリンク上のルータXを介して別のリンク上のルータYを介して分離されたネットワークに、インターネットに接続されています。マルチホームホストは、ファイアウォール、企業ネットワークにトンネルがあるかもしれない、またはそれが直接単離テストネットワークに接続されるかもしれません。
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.
このような状況では、タイプ（デフォルトルータの設定以上の特定のルートを持っていない）マルチホームホストは、インテリジェントにそのデフォルトルータリストにルータ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.
ルータが適切に設定されている場合、この同じ状況でマルチホーム型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.
ルータが適切に設定されている場合は、これと同じような状況では、マルチホームタイプCホストが正しくたとえばルータXとYの間で選択することができ、隔離されたネットワーク上のルータYは、分離されたネットワークプレフィックスのルート情報オプションを宣伝する必要があります。これは、すべてのデフォルトルータ（ゼロルータ寿命）として自身をアドバタイズしない可能性があります、またはそれは低好みにデフォルトルータとして自分自身を宣伝することがあります。ルータXはミディアム好みにデフォルトルータとしての地位を宣伝する必要があります。
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.
悪意のあるノードは離れて、正当なルータからのトラフィックを引く効果で、高いデフォルトルータプリファレンスを指定するか、特定のルートを運ぶ、ルータ通知メッセージを送信することができます。しかし、悪意のあるノードは、簡単に他の方法でこの同じ効果を得ることができました。
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.
例えば、ホストが他の経路を使用して停止させ、他のルータからゼロルータ寿命のルータ広告メッセージを作ることができました。特定のプレフィックスを広告することで、この攻撃は目立たな方法で行うことができました。しかし、この攻撃は、インターネットインフラストラクチャのセキュリティ上の有意なインクリメンタルな影響を与えません。
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.
悪意のあるノードは、無期限に残るへのルートを生じさせる経路情報オプションで無限の寿命を含むことができます。同様の攻撃はすでに悪意のあるノードは、それがない場合は、接続性の欠如、その結果、上のリンクを無期限として表示されるように接頭辞を起こしRFC 2461にプレフィックス情報オプションに存在します。これとは対照的に、ルート情報オプションで無限の寿命が無期限に継続するために、プロービングルータの到達可能性が発生しますが、接続性の欠如にはなりません。
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.
同様に、悪意のあるノードは、ルート情報オプション内のルートの数が多い、または非常に頻繁にルートの広告でホストをオーバーロードしようとすることができます。ここでも、この同じ攻撃はすでにプレフィックス情報オプションに存在します。
[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にあります。
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は、新しい近隣探索[RFC2461]のオプションを定義し、IPv6の近隣探索オプション形式の番号空間内の値24が割り当てられているルート情報オプション、。
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].
著者はバラッシュAkbari、スティーブデアリング、ロバート・エルツ、トニーハイン、ボブHindenとクリスチャンのHuitema、神明達也、エリックNordmarkと、ペッカSavola、Kresimir Segaric、およびブライアンZillの貢献を認めたいと思います。パケット図は、近隣探索[RFC2461]に由来します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、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）の"、RFC 2461、1998年12月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年6月。
[RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, January 1997.
[RFC2080]マルキン、G.およびR. Minnear、 "IPv6のためのRIPng"、RFC 2080、1997年1月。
[RFC2893] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 2893, August 2000.
"IPv6ホストとルータの移行メカニズム" [RFC2893]ギリガン、R.およびE. Nordmarkと、RFC 2893、2000年8月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056]カーペンター、B.およびK.ムーア、RFC 3056、2001年2月 "のIPv4クラウドを介したIPv6ドメインの接続"。
[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近隣探索（ND）信頼モデルと脅威"、RFC 3756、2004年5月。
Authors' Addresses
著者のアドレス
Richard Draves Microsoft Research One Microsoft Way Redmond, WA 98052
リチャードDravesマイクロソフトリサーチ1つのマイクロソフト道、レッドモンド、WA 98052
Phone: +1 425 706 2268 EMail: richdr@microsoft.com
電話：+1 425 706 2268 Eメール：richdr@microsoft.com
Dave Thaler Microsoft One Microsoft Way Redmond, WA 98052
デーブターラーマイクロソフト1マイクロソフト道、レッドモンド、ワシントン98052
Phone: +1 425 703 8835 EMail: dthaler@microsoft.com
電話：+1 425 703 8835 Eメール：dthaler@microsoft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
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リポジトリから。
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機能のための基金は現在、インターネット協会によって提供されます。