[要約] RFC 4191は、IPv6ネットワークにおけるデフォルトルーターの優先度とより具体的なルートに関するガイドラインを提供するものです。このRFCの目的は、IPv6ネットワークの効率的なルーティングとネットワークパフォーマンスの向上を促進することです。
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).
Copyright（c）The Internet Society（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.
Neighbor Discovery [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.) 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.
デフォルトのルーターリストにホストが複数のルーターを持っている一部のネットワークトポロジでは、リンクオフリンクの宛先のルーターの選択が重要です。状況によっては、1つのルーターが目的地の場合よりもはるかに優れたパフォーマンスを提供する場合があります。他の状況では、間違ったルーターを選択すると、通信に失敗する可能性があります。（セクション5では、これらのシナリオの具体的な例を示します。）このドキュメントでは、デフォルトのルーターの設定とルーターからホストへのより特異的なルートを伝えるための近隣ディスカバリールーター広告メッセージへのオプションの拡張機能について説明します。これにより、ホストがオフリンクの宛先に適したルーターを選択する能力が向上します。
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.
Neighbor Discoveryは、ルーターがホストのルーターの選択を修正するために使用できるリダイレクトメッセージを提供します。ルーターは、リダイレクトメッセージをホストに送信し、特定の宛先に別のルーターを使用するように指示できます。ただし、リダイレクト機能は単一のリンクに制限されています。あるリンクのルーターは、別のリンクのルーターにホストをリダイレクトできません。したがって、リダイレクトメッセージは、マルチホーム（複数のインターフェイスを介して）ホストを選択するのに役立ちません。適切なルーターを選択します。
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などの1つ以上のワイヤレス接続があります。物理ネットワーク接続に加えて、ホストには仮想またはトンネルネットワーク接続がある場合があります。たとえば、パブリックインターネットへの直接接続に加えて、ホストはプライベート企業ネットワークへのトンネルを持つ場合があります。一部の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]のような他のプロトコルの代わりに、ルーター広告メッセージを使用します。ピギーバックルーターからホストへの既存のメッセージトラフィックに関するこの情報をバックすると、ネットワークオーバーヘッドが減少します。Neighbor Discoveryは、マルチキャストリスナーの発見と共有し、ホストとルーター間の相互作用に参加する必要がなく、ホストからルーターへの相互作用を定義するプロパティを発見します。さらに、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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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 High 00 Medium（デフォルト）11 Low 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.
3つの値だけがメトリックではないことを強化し、合理的なシナリオにはより多くの値が必要ではないようです。
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: 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.
メッセージヘッダーの優先値に加えて、ルーター広告には、::/0のルート情報オプションも含まれていることに注意してください。ルーター広告ヘッダーの優先値をエンコードすると、次の利点がいくつかあります。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. デフォルトルートに最適なルーターが共通トラフィックをリダイレクトする可能性が最も低いルーターである場合（これは一般的なケースになります）、メッセージヘッダーの優先値をエンコードすることは、個別のオプションを送信するよりも効率的です。
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オクテットのユニットのオプションの長さ（タイプフィールドと長さフィールドを含む）。長さのフィールドは、プレフィックスの長さに応じて1、2、または3です。プレフィックスの長さが64を超える場合、長さは3でなければなりません。プレフィックスの長さが0より大きい場合、長さは2または3でなければなりません。プレフィックスの長さがゼロの場合、長さは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.
プレフィックス長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ビット（0xffffffffff）の値は無限を表します。
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アドレスのプレフィックスを含むPREFIX変数長フィールド。プレフィックスの長さフィールドには、プレフィックス内の有効な先頭ビットの数が含まれています。プレフィックスの長さ（ある場合）の後のプレフィックスのビットは予約されており、送信者によってゼロに初期化され、受信機によって無視される必要があります。
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. プレフィックスは通常、両方ではなく1つのオプションにのみ表示されるため、新しいオプションでは重複を導入しません。
2. The Route Information Option is typically 16 octets while the Prefix Information Option is 32 octets.
2. ルート情報オプションは通常16オクテットですが、プレフィックス情報オプションは32オクテットです。
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].
タイプAホストは、デフォルトのルーターの好みとより固有のルートを無視します。近隣発見[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ホストは、ルーターの寿命とルーター広告メッセージヘッダーのデフォルトルーターの選好に基づいて、a ::/0ルートを最初に更新します。次に、ホストがルーター広告メッセージ本文のルート情報オプションを処理すると、そのようなオプションごとにルーティングテーブルを更新します。A ::/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.
たとえば、ホストがルーターXから100秒のルーター寿命と媒体のデフォルトのルーター選好を備えたルーター広告を受け取るとします。ルーター広告の本文には、ルート寿命が200秒、低いルートの好みを持つ::/0のルート情報オプションが含まれています。ルーター広告を処理すると、タイプAホストには、100秒の寿命のデフォルトルーターリストにルーターXのエントリがあります。タイプBホストが同じルーター広告を受信した場合、中程度の好みと100秒の寿命を備えたデフォルトルーターリストにルーターXのエントリがあります。タイプCホストには、::/0->ルーターxのルーティングテーブルにエントリがあり、好みが低く、200秒の寿命があります。ルーター広告の処理中、タイプCホストには一時的な状態があり、その中には、中程度の好みと寿命が100秒のルーターXのルーティングテーブルにエントリがあります。
Type A hosts use the conceptual sending algorithm described in Neighbor Discovery [RFC2461].
タイプAホストは、近隣発見[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ホストはパケットを破棄し、宛先の到達不可能/宛先エラーへのルートなしの宛先を報告する必要があります。
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 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.
ホストが到達不可能なルーターXを使用しないようにし、代わりに別のルーターYにデータパケットを送信し、ホストがルーターXが到達可能な場合はルーターXを使用していた場合、ホストはそのようなルーターXの各到達可能性を単一の到達可能性をプローブする必要があります。そのルーターのアドレスへの隣接勧誘。ホストは、ホストが到達可能であればルーターに送信した有用なトラフィックがない場合、ルーターの到達可能性をプローブしてはなりません。いずれにせよ、これらのプローブは、ルーターごとに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の到達可能性に気付かない場合があり、次のルーター広告がXによって送信されるまで、それほど決定できないルーターYを使用し続けます。真ん中が下がっている）ので、次のルーター広告が送信されるまでに最大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.
タイプAホスト（[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
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の到達可能性を調べながらYを使用する必要があります。プレフィックスが宛先と一致しないため、ルーターXは選択されません。
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回以上のルート情報オプションを送信してはなりません。このarbitrary意的な拘束力は、ホストに宣伝されるべきであり、慎重に選択されたルートを比較的少ない慎重に補強することを目的としています。
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 UNTALLITITED 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.
高い（非デフォルト）優先値は、ルーターとネットワークトポロジの両方の知識を持っている人が明示的に構成されている場合にのみ使用する必要があります。たとえば、それは一般的なネットワーク管理者であるか、ルーターを管理するさまざまな管理者への顧客リクエストである可能性があります。
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つの例外として、インターネットに接続していないルーターの管理者、または一般的なトラフィックをブロックするファイアウォールを介して接続されているため、ルーターを設定してデフォルトの低いルーターの好みを宣伝する必要があります。
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.
たとえば、ホームユーザーがファイアウォールされたコーポレートネットワークにトンネルを設定した場合、トンネルのコーポレートネットワーク端のアクセスルーターは、デフォルトのルーターとして自らを宣伝する必要がありますが、好みは低くなります。さらに、コーポレートルーターは、コーポレートサイトプレフィックスの特定のルートを宣伝する必要があります。最終的な結果は、コーポレートネットワークの目的地がトンネルを介して到達し、一般的なインターネットの目的地がHome 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のリンクがある状況を考えてみましょう。2002::/16に最適です。（6to4サイトゲートウェイです。）ルーターyは::/0に最適です。（ネイティブIPv6インターネットに接続します。）ルーターxは、ネイティブIPv6トラフィックをルーターyに転送します。ルーターYは6to4トラフィックをルーターXに転送します。このサイトからのほとんどのトラフィックが2002：/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がデフォルトのルーターの好みで自分自身を宣伝する必要があります。これにより、タイプBホストはルーターXを好み、リダイレクトの数を最小限に抑えます。
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のルートが低い::/0ルートと、中程度の好みのある2002 ::/16ルートを宣伝する必要があります。タイプCホストは、ルーティングテーブルに3つのルートになります：::/0->ルーターx（低）、::/0->ルーターy（中）、2002 ::/16->ルーターx（中程度）。Router Xに6to4トラフィックを送信し、その他のトラフィックはルーターYに送信します。タイプCホストはリダイレクトを引き起こしません。
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.
別のシナリオでは、マルチホームのホストが、1つのリンクでルーター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.
この状況では、タイプAマルチホームのホスト（デフォルトのルーターの設定やより特定のルートがない）は、デフォルトのルーターリストでルーター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]は、信頼モデルの詳細を提供し、これらの問題に対処するルーター発見メッセージのセキュリティに関する送信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は、IPv6 Neighbor Discoveryオプション形式の番号付けスペース内で値24を割り当てられたルート情報オプションであるルート情報オプションである新しいNeighbor Discovery [RFC2461]オプションを定義します。
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、Steve Deering、Robert Elz、Tony Hain、Bob Hinden、Christian Huitema、Jinmei Tatuya、Erik Nordmark、Pekka Savola、Kresimir Segaric、およびBrian Zillの貢献を認めたいと考えています。パケット図は、近隣発見[RFC2461]から派生しています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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. Simpson、「IPバージョン6（IPv6）の近隣発見」、RFC 2461、1998年12月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775] Johnson、D.、Perkins、C。、およびJ. Arkko、「IPv6のモビリティサポート」、RFC 3775、2004年6月。
[RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, January 1997.
[RFC2080] Malkin、G。およびR. Minnear、「RIPNG for IPv6」、RFC 2080、1997年1月。
[RFC2893] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 2893, August 2000.
[RFC2893] Gilligan、R。およびE. Nordmark、「IPv6ホストとルーターの遷移メカニズム」、RFC 2893、2000年8月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056] Carpenter、B。およびK. Moore、「IPv4 Cloudsを介したIPv6ドメインの接続」、RFC 3056、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.、Kempf、J。、およびE. Nordmark、「IPv6 Neighbor Discovery（ND）Trustモデルと脅威」、RFC 3756、2004年5月。
Authors' Addresses
著者のアドレス
Richard Draves Microsoft Research One Microsoft Way Redmond, WA 98052
リチャードドラヴズマイクロソフトリサーチワンマイクロソフトウェイレドモンド、ワシントン州98052
Phone: +1 425 706 2268
EMail: richdr@microsoft.com
Dave Thaler Microsoft One Microsoft Way Redmond, WA 98052
Dave Thaler Microsoft One Microsoft Way Redmond、WA 98052
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。