[要約] RFC 3697は、IPv6フローラベルの仕様を定めたものであり、IPv6パケットのフローラベルの使用方法と目的を説明しています。この仕様は、ネットワークトラフィックの識別と優先順位付けを向上させるために設計されています。
Network Working Group J. Rajahalme
Request for Comments: 3697 Nokia
Category: Standards Track A. Conta
Transwitch
B. Carpenter
IBM
S. Deering
Cisco
March 2004
IPv6 Flow Label Specification
IPv6フローラベル仕様
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 (2004). All Rights Reserved.
著作権（c）The Internet Society（2004）。無断転載を禁じます。
Abstract
概要
This document specifies the IPv6 Flow Label field and the minimum requirements for IPv6 source nodes labeling flows, IPv6 nodes forwarding labeled packets, and flow state establishment methods. Even when mentioned as examples of possible uses of the flow labeling, more detailed requirements for specific use cases are out of scope for this document.
このドキュメントは、IPv6フローラベルフィールドと、IPv6ソースノードのラベル付けフロー、IPv6ノードのラベル付きパケット、フロー状態確立方法の最小要件を指定します。フローラベルの使用の可能性の例として言及された場合でも、特定のユースケースのより詳細な要件は、このドキュメントの範囲外です。
The usage of the Flow Label field enables efficient IPv6 flow classification based only on IPv6 main header fields in fixed positions.
フローラベルフィールドの使用は、固定位置のIPv6メインヘッダーフィールドのみに基づいて効率的なIPv6フロー分類を可能にします。
A flow is a sequence of packets sent from a particular source to a particular unicast, anycast, or multicast destination that the source desires to label as a flow. A flow could consist of all packets in a specific transport connection or a media stream. However, a flow is not necessarily 1:1 mapped to a transport connection.
フローは、特定のソースから特定のユニキャスト、Anycast、またはマルチキャストの宛先に送信されるパケットのシーケンスであり、ソースがフローとしてラベル付けしたいと考えています。フローは、特定のトランスポート接続またはメディアストリーム内のすべてのパケットで構成されます。ただし、フローは必ずしも輸送接続にマッピングされているわけではありません。
Traditionally, flow classifiers have been based on the 5-tuple of the source and destination addresses, ports, and the transport protocol type. However, some of these fields may be unavailable due to either fragmentation or encryption, or locating them past a chain of IPv6 option headers may be inefficient. Additionally, if classifiers depend only on IP layer headers, later introduction of alternative transport layer protocols will be easier.
伝統的に、フロー分類器は、ソースおよび宛先アドレス、ポート、および輸送プロトコルタイプの5タプルに基づいていました。ただし、これらのフィールドの一部は、断片化または暗号化のいずれかのために利用できない場合があります。または、IPv6オプションヘッダーのチェーンを通過することは非効率的な場合があります。さらに、分類器がIPレイヤーヘッダーのみに依存する場合、その後の代替輸送層プロトコルの導入が簡単になります。
The usage of the 3-tuple of the Flow Label and the Source and Destination Address fields enables efficient IPv6 flow classification, where only IPv6 main header fields in fixed positions are used.
フローラベルの3タプルとソースおよび宛先アドレスフィールドの使用は、固定位置のIPv6メインヘッダーフィールドのみが使用される効率的なIPv6フロー分類を可能にします。
The minimum level of IPv6 flow support consists of labeling the flows. IPv6 source nodes supporting the flow labeling MUST be able to label known flows (e.g., TCP connections, application streams), even if the node itself would not require any flow-specific treatment. Doing this enables load spreading and receiver oriented resource reservations, for example. Node requirements for flow labeling are given in section 3.
IPv6フローサポートの最小レベルは、フローのラベル付けで構成されています。フローラベルをサポートするIPv6ソースノードは、ノード自体がフロー固有の処理を必要としない場合でも、既知のフロー（TCP接続、アプリケーションストリームなど）にラベルを付けることができなければなりません。これを行うことで、荷重の拡大とレシーバー指向のリソースの予約などが可能になります。フローラベルのノード要件は、セクション3に記載されています。
Specific flow state establishment methods and the related service models are out of scope for this specification, but the generic requirements enabling co-existence of different methods in IPv6 nodes are set forth in section 4. The associated scaling characteristics (such as nodes involved in state establishment, amount of state maintained by them, and state growth function) will be specific to particular service models.
特定のフロー状態の確立方法と関連サービスモデルは、この仕様の範囲外ですが、IPv6ノードのさまざまな方法の共存を可能にする一般的な要件は、セクション4に記載されています。関連するスケーリング特性（状態に関与するノードなど確立、それらが維持する状態の量、および状態成長機能）は、特定のサービスモデルに固有のものになります。
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 BCP 14, RFC 2119 [KEYWORDS].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、BCP 14、RFC 2119 [キーワード]に記載されているとおりに解釈されます。
The 20-bit Flow Label field in the IPv6 header [IPv6] is used by a source to label packets of a flow. A Flow Label of zero is used to indicate packets not part of any flow. Packet classifiers use the triplet of Flow Label, Source Address, and Destination Address fields to identify which flow a particular packet belongs to. Packets are processed in a flow-specific manner by the nodes that have been set up with flow-specific state. The nature of the specific treatment and the methods for the flow state establishment are out of scope for this specification.
IPv6ヘッダー[IPv6]の20ビットフローラベルフィールドは、ソースによってフローのパケットをラベル付けするために使用されます。ゼロのフローラベルは、フローの一部ではないパケットを示すために使用されます。パケット分類器は、フローラベルのトリプレット、ソースアドレス、および宛先アドレスフィールドを使用して、特定のパケットが属するフローを特定します。パケットは、フロー固有の状態でセットアップされたノードによってフロー固有の方法で処理されます。特定の治療の性質とフロー状態の確立の方法は、この仕様の範囲外です。
The Flow Label value set by the source MUST be delivered unchanged to the destination node(s).
ソースによって設定されたフローラベル値は、宛先ノードに変更されずに配信する必要があります。
IPv6 nodes MUST NOT assume any mathematical or other properties of the Flow Label values assigned by source nodes. Router performance SHOULD NOT be dependent on the distribution of the Flow Label values. Especially, the Flow Label bits alone make poor material for a hash key.
IPv6ノードは、ソースノードによって割り当てられたフローラベル値の数学的またはその他のプロパティを想定してはなりません。ルーターのパフォーマンスは、フローラベル値の分布に依存してはなりません。特に、フローラベルビットだけで、ハッシュキーの材料が不十分になります。
Nodes keeping dynamic flow state MUST NOT assume packets arriving 120 seconds or more after the previous packet of a flow still belong to the same flow, unless a flow state establishment method in use defines a longer flow state lifetime or the flow state has been explicitly refreshed within the lifetime duration.
動的なフロー状態を維持するノード使用中のフロー状態確立方法が長いフロー状態の寿命を定義している場合、またはフロー状態が明示的に更新されていない限り、フローの前のパケットがまだ同じフローに属してから120秒以上到着するパケットを想定してはなりません生涯の期間内。
The use of the Flow Label field does not necessarily signal any requirement on packet reordering. Especially, the zero label does not imply that significant reordering is acceptable.
フローラベルフィールドの使用は、必ずしもパケットの並べ替えに要件を示すものではありません。特に、ゼロラベルは、重要な並べ替えが許容できることを意味しません。
If an IPv6 node is not providing flow-specific treatment, it MUST ignore the field when receiving or forwarding a packet.
IPv6ノードがフロー固有の処理を提供していない場合、パケットを受信または転送するときはフィールドを無視する必要があります。
To enable Flow Label based classification, source nodes SHOULD assign each unrelated transport connection and application data stream to a new flow. The source node MAY also take part in flow state establishment methods that result in assigning certain packets to specific flows. A source node which does not assign traffic to flows MUST set the Flow Label to zero.
フローラベルベースの分類を有効にするために、ソースノードは、それぞれの無関係なトランスポート接続とアプリケーションデータストリームを新しいフローに割り当てる必要があります。ソースノードは、特定のパケットを特定のフローに割り当てることになるフロー状態確立方法にも参加する場合があります。トラフィックをフローに割り当てないソースノードは、フローラベルをゼロに設定する必要があります。
To enable applications and transport protocols to define what packets constitute a flow, the source node MUST provide means for the applications and transport protocols to specify the Flow Label values to be used with their flows. The use of the means to specify Flow Label values is subject to appropriate privileges (see section 5.1). The source node SHOULD be able to select unused Flow Label values for flows not requesting a specific value to be used.
アプリケーションと輸送プロトコルがフローを構成するパケットを定義できるようにするために、ソースノードは、アプリケーションと輸送プロトコルがフローで使用するフローラベル値を指定する手段を提供する必要があります。フローラベル値を指定するための手段の使用は、適切な特権の対象となります（セクション5.1を参照）。ソースノードは、使用する特定の値を要求しないフローの未使用フローラベル値を選択できる必要があります。
A source node MUST ensure that it does not unintentionally reuse Flow Label values it is currently using or has recently used when creating new flows. Flow Label values previously used with a specific pair of source and destination addresses MUST NOT be assigned to new flows with the same address pair within 120 seconds of the termination of the previous flow. The source node SHOULD provide the means for the applications and transport protocols to specify quarantine periods longer than the default 120 seconds for individual flows.
ソースノードは、現在使用している、または最近使用されている新しいフローを作成するときに、意図せずにフローラベル値を再利用しないことを確認する必要があります。以前のソースおよび宛先アドレスのペアで以前に使用されていたフローラベル値は、前のフローの終了から120秒以内に同じアドレスペアで新しいフローに割り当てられてはなりません。ソースノードは、個々のフローのデフォルトの120秒よりも長い隔離期間を指定するためのアプリケーションおよび輸送プロトコルの手段を提供する必要があります。
To avoid accidental Flow Label value reuse, the source node SHOULD select new Flow Label values in a well-defined sequence (e.g., sequential or pseudo-random) and use an initial value that avoids reuse of recently used Flow Label values each time the system restarts. The initial value SHOULD be derived from a previous value stored in non-volatile memory, or in the absence of such history, a randomly generated initial value using techniques that produce good randomness properties [RND] SHOULD be used.
偶発的なフローラベル値の再利用を回避するために、ソースノードは、明確に定義されたシーケンス（たとえば、シーケンシャルまたは擬似ランダムなど）で新しいフローラベル値を選択し、システムのたびに最近使用されたフローラベル値の再利用を避ける初期値を使用する必要があります。再起動します。初期値は、不揮発性メモリに保存された以前の値から導き出される必要があります。または、そのような履歴がない場合、良好なランダム性プロパティ[RND]を生成する手法を使用してランダムに生成された初期値を使用する必要があります。
To enable flow-specific treatment, flow state needs to be established on all or a subset of the IPv6 nodes on the path from the source to the destination(s). The methods for the state establishment, as well as the models for flow-specific treatment will be defined in separate specifications.
フロー固有の処理を可能にするには、流れ状態を、ソースから宛先までのパス上のIPv6ノードのすべてまたはサブセットで確立する必要があります。国家施設の方法と、流れ固有の治療のモデルは、別々の仕様で定義されます。
To enable co-existence of different methods in IPv6 nodes, the methods MUST meet the following basic requirements:
IPv6ノードでさまざまな方法の共存を可能にするには、メソッドは次の基本要件を満たす必要があります。
(1) The method MUST provide the means for flow state clean-up from the IPv6 nodes providing the flow-specific treatment. Signaling based methods where the source node is involved are free to specify flow state lifetimes longer than the default 120 seconds.
(1) この方法は、フロー固有の処理を提供するIPv6ノードからフロー状態のクリーンアップの手段を提供する必要があります。ソースノードが関与しているシグナリングベースの方法は、デフォルトの120秒よりも長いフロー状態の寿命を自由に指定できます。
(2) Flow state establishment methods MUST be able to recover from the case where the requested flow state cannot be supported.
(2) フロー状態の確立方法は、要求されたフロー状態をサポートできない場合から回復できる必要があります。
This section considers security issues raised by the use of the Flow Label, primarily the potential for denial-of-service attacks, and the related potential for theft of service by unauthorized traffic (Section 5.1). Section 5.2 addresses the use of the Flow Label in the presence of IPsec including its interaction with IPsec tunnel mode and other tunneling protocols. We also note that inspection of unencrypted Flow Labels may allow some forms of traffic analysis by revealing some structure of the underlying communications. Even if the flow label were encrypted, its presence as a constant value in a fixed position might assist traffic analysis and cryptoanalysis.
このセクションでは、フローラベルの使用によって提起されたセキュリティの問題、主にサービス拒否攻撃の可能性、および不正なトラフィックによるサービスの盗難の可能性を考慮します（セクション5.1）。セクション5.2では、IPSECトンネルモードとその他のトンネルプロトコルとの相互作用を含む、IPSECの存在下でのフローラベルの使用について説明します。また、暗号化されていないフローラベルの検査により、基礎となる通信の構造を明らかにすることにより、何らかの形のトラフィック分析が可能になる可能性があることにも注意してください。フローラベルが暗号化されたとしても、固定位置に一定の値としての存在は、交通分析と暗号分析を支援する可能性があります。
Since the mapping of network traffic to flow-specific treatment is triggered by the IP addresses and Flow Label value of the IPv6 header, an adversary may be able to obtain better service by modifying the IPv6 header or by injecting packets with false addresses and/or labels. Taken to its limits, such theft-of-service becomes a denial-of-service attack when the modified or injected traffic depletes the resources available to forward it and other traffic streams. A curiosity is that if a DoS attack were undertaken against a given Flow Label (or set of Flow Labels), then traffic containing an affected Flow Label might well experience worse-than-best-effort network performance.
ネットワークトラフィックのフロー固有の処理へのマッピングは、IPv6ヘッダーのIPアドレスとフローラベル値によってトリガーされるため、敵はIPv6ヘッダーを変更するか、誤ったアドレスおよび/または/または注入することにより、より良いサービスを得ることができる場合があります。ラベル。そのような盗難の盗難は、変更されたまたは注入されたトラフィックがそれを転送するために利用可能なリソースやその他のトラフィックストリームを枯渇させると、そのような盗難盗難攻撃になります。好奇心は、DOS攻撃が特定のフローラベル（またはフローラベルのセット）に対して実施された場合、影響を受けるフローラベルを含むトラフィックが、ベストよりもエフォルトのネットワークパフォーマンスよりも悪い経験を経験する可能性があるということです。
Note that since the treatment of IP headers by nodes is typically unverified, there is no guarantee that flow labels sent by a node are set according to the recommendations in this document. Therefore, any assumptions made by the network about header fields such as flow labels should be limited to the extent that the upstream nodes are explicitly trusted.
ノードによるIPヘッダーの扱いは通常未確認であるため、ノードによって送信されるフローラベルがこのドキュメントの推奨事項に従って設定されているという保証はないことに注意してください。したがって、フローラベルなどのヘッダーフィールドに関するネットワークが行った仮定は、上流ノードが明示的に信頼される程度に制限する必要があります。
Since flows are identified by the 3-tuple of the Flow Label and the Source and Destination Address, the risk of theft or denial of service introduced by the Flow Label is closely related to the risk of theft or denial of service by address spoofing. An adversary who is in a position to forge an address is also likely to be able to forge a label, and vice versa.
フローラベルの3タプルとソースおよび宛先アドレスによってフローが識別されるため、フローラベルによって導入された盗難またはサービス拒否のリスクは、アドレススプーフィングによる盗難またはサービス拒否のリスクに密接に関連しています。住所を偽造する立場にある敵も、ラベルを築くことができる可能性があり、その逆も同様です。
There are two issues with different properties: Spoofing of the Flow Label only, and spoofing of the whole 3-tuple, including Source and Destination Address.
異なるプロパティには2つの問題があります。フローラベルのみのスプーフィングのみと、ソースおよび宛先アドレスを含む3タプル全体のスプーフィングです。
The former can be done inside a node which is using or transmitting the correct source address. The ability to spoof a Flow Label typically implies being in a position to also forge an address, but in many cases, spoofing an address may not be interesting to the spoofer, especially if the spoofer's goal is theft of service, rather than denial of service.
前者は、正しいソースアドレスを使用または送信しているノード内で実行できます。フローラベルをスプーフィングする能力は、通常、住所を偽造する立場にあることを意味しますが、多くの場合、住所をスプーフィングすることは、特にスポーファーの目標がサービスの拒否ではなくサービスの盗難である場合、スポーファーにとって興味深いものではないかもしれません。
The latter can be done by a host which is not subject to ingress filtering [INGR] or by an intermediate router. Due to its properties, such is typically useful only for denial of service. In the absence of ingress filtering, almost any third party could instigate such an attack.
後者は、イングレスフィルタリング[INGR]または中間ルーターの影響を受けないホストによって行うことができます。そのプロパティのため、そのようなものは通常、サービスの拒否にのみ役立ちます。イングレスフィルタリングがない場合、ほぼすべての第三者がそのような攻撃を扇動する可能性があります。
In the presence of ingress filtering, forging a non-zero Flow Label on packets that originated with a zero label, or modifying or clearing a label, could only occur if an intermediate system such as a router was compromised, or through some other form of man-in-the-middle attack. However, the risk is limited to traffic receiving better or worse quality of service than intended. For example, if Flow Labels are altered or cleared at random, flow classification will no longer happen as intended, and the altered packets will receive default treatment. If a complete 3-tuple is forged, the altered packets will be classified into the forged flow and will receive the corresponding quality of service; this will create a denial of service attack subtly different from one where only the addresses are forged. Because it is limited to a single flow definition, e.g., to a limited amount of bandwidth, such an attack will be more specific and at a finer granularity than a normal address-spoofing attack.
イングレスフィルタリングの存在下で、ゼロラベルで発信されたパケットにゼロ以外のフローラベルを偽造する、またはラベルの変更またはクリアの拡大は、ルーターなどの中間システムが侵害された場合、または他の形式を介して発生する可能性があります。中間攻撃。ただし、リスクは、意図したよりも優れたサービス品質を受け取るトラフィックに限定されています。たとえば、フローラベルがランダムに変更またはクリアされている場合、フロー分類は意図したとおりに発生しなくなり、変更されたパケットがデフォルトの処理を受けます。完全な3タプルが偽造されている場合、変更されたパケットは偽造フローに分類され、対応するサービス品質を受け取ります。これにより、アドレスのみが偽造されている場合とは、サービス拒否攻撃が微妙に異なります。単一のフロー定義、たとえば限られた量の帯域幅に限定されているため、このような攻撃は、通常のアドレススポーフィング攻撃よりも具体的で、より細かい粒度でより具体的になります。
Since flows are identified by the complete 3-tuple, ingress filtering [INGR] will, as noted above, mitigate part of the risk. If the source address of a packet is validated by ingress filtering, there can be a degree of trust that the packet has not transited a compromised router, to the extent that ISP infrastructure may be trusted. However, this gives no assurance that another form of man-in-the-middle attack has not occurred.
フローは完全な3タプルによって識別されるため、上記のように、イングレスフィルタリング[INGR]はリスクの一部を緩和します。パケットのソースアドレスがイングレスフィルタリングによって検証されている場合、ISPインフラストラクチャが信頼できる限り、パケットが侵害されたルーターを通過していないという程度の信頼があります。ただし、これは別の形態の中間攻撃が発生していないという保証を与えません。
Only applications with an appropriate privilege in a sending host will be entitled to set a non-zero Flow Label. Mechanisms for this are operating system dependent. Related policy and authorization mechanisms may also be required; for example, in a multi-user host, only some users may be entitled to set the Flow Label. Such authorization issues are outside the scope of this specification.
送信ホストに適切な特権を持つアプリケーションのみが、ゼロ以外のフローラベルを設定する権利があります。これのメカニズムは、オペレーティングシステムに依存しています。関連するポリシーと承認メカニズムも必要になる場合があります。たとえば、マルチユーザーホストでは、一部のユーザーのみがフローラベルを設定する権利があります。このような承認の問題は、この仕様の範囲外です。
The IPsec protocol, as defined in [IPSec, AH, ESP], does not include the IPv6 header's Flow Label in any of its cryptographic calculations (in the case of tunnel mode, it is the outer IPv6 header's Flow Label that is not included). Hence modification of the Flow Label by a network node has no effect on IPsec end-to-end security, because it cannot cause any IPsec integrity check to fail. As a consequence, IPsec does not provide any defense against an adversary's modification of the Flow Label (i.e., a man-in-the-middle attack).
[IPSEC、AH、ESP]で定義されているIPSECプロトコルには、暗号化計算のいずれにもIPv6ヘッダーのフローラベルが含まれていません（トンネルモードの場合、含まれていない外部IPv6ヘッダーフローラベルです）。したがって、ネットワークノードによるフローラベルの変更は、IPSECのエンドツーエンドセキュリティに影響を与えません。これは、IPSECの整合性チェックを失敗させることができないためです。結果として、IPSECは、敵のフローラベルの修正（つまり、中間攻撃）に対する敵の修正に対する防御を提供しません。
IPsec tunnel mode provides security for the encapsulated IP header's Flow Label. A tunnel mode IPsec packet contains two IP headers: an outer header supplied by the tunnel ingress node and an encapsulated inner header supplied by the original source of the packet. When an IPsec tunnel is passing through nodes performing flow classification, the intermediate network nodes operate on the Flow Label in the outer header. At the tunnel egress node, IPsec processing includes removing the outer header and forwarding the packet (if required) using the inner header. The IPsec protocol requires that the inner header's Flow Label not be changed by this decapsulation processing to ensure that modifications to label cannot be used to launch theft-or denial-of-service attacks across an IPsec tunnel endpoint. This document makes no change to that requirement; indeed it forbids changes to the Flow Label.
IPSECトンネルモードは、カプセル化されたIPヘッダーのフローラベルのセキュリティを提供します。トンネルモードIPSECパケットには、2つのIPヘッダーが含まれています。トンネルイングレスノードから供給される外側ヘッダーと、パケットの元のソースから提供されるカプセル化された内側ヘッダーです。Ipsecトンネルがフロー分類を実行するノードを通過すると、中間ネットワークノードは外側ヘッダーのフローラベルで動作します。トンネル出力ノードでは、IPSEC処理には、外側のヘッダーを取り外し、内側のヘッダーを使用してパケットを（必要に応じて）転送することが含まれます。IPSECプロトコルでは、この脱カプセル化処理によって内側のヘッダーフローラベルを変更しないようにする必要があります。これは、IPSECトンネルエンドポイント全体で盗難またはサービス拒否攻撃を起動するためにラベルの変更を使用できないことを確認します。このドキュメントは、その要件を変更しません。実際、それはフローラベルの変更を禁止しています。
When IPsec tunnel egress decapsulation processing includes a sufficiently strong cryptographic integrity check of the encapsulated packet (where sufficiency is determined by local security policy), the tunnel egress node can safely assume that the Flow Label in the inner header has the same value as it had at the tunnel ingress node.
IPSECトンネル出力脱カプセル化処理には、カプセル化されたパケットの十分に強力な暗号整合性チェックが含まれている場合（十分性がローカルセキュリティポリシーによって決定されます）、トンネルエグレスノードは、内側のヘッダーのフローラベルが持っていたのと同じ値を持っていると安全に想定できます。トンネルイングレスノードで。
This analysis and its implications apply to any tunneling protocol that performs integrity checks. Of course, any Flow Label set in an encapsulating IPv6 header is subject to the risks described in the previous section.
この分析とその意味は、整合性チェックを実行するトンネルプロトコルに適用されます。もちろん、カプセル化IPv6ヘッダーに設定されたフローラベルは、前のセクションで説明されているリスクの対象となります。
The Flow Label does nothing to eliminate the need for packet filtering based on headers past the IP header, if such filtering is deemed necessary for security reasons on nodes such as firewalls or filtering routers.
フローラベルは、ファイアウォールやルーターのフィルタリングなどのノードのセキュリティ上の理由でそのようなフィルタリングが必要とみなされる場合、IPヘッダーを通過するヘッダーに基づいてパケットフィルタリングの必要性を排除するために何もしません。
The discussion on the topic in the IPv6 WG mailing list has been instrumental for the definition of this specification. The authors want to thank Ran Atkinson, Steve Blake, Jim Bound, Francis Dupont, Robert Elz, Tony Hain, Robert Hancock, Bob Hinden, Christian Huitema, Frank Kastenholz, Thomas Narten, Charles Perkins, Pekka Savola, Hesham Soliman, Michael Thomas, Margaret Wasserman, and Alex Zinin for their contributions.
IPv6 WGメーリングリストのトピックに関する議論は、この仕様の定義のために貢献しています。著者は、ラン・アトキンソン、スティーブ・ブレイク、ジム・バウンド、フランシス・デュポン、ロバート・エルツ、トニー・ヘイン、ロバート・ハンコック、ボブ・ヒンデン、クリスチャン・フイテマ、フランク・カステンホルツ、トーマス・ナルテン、チャールズ・パーキンス、ペッカ・サヴォーラ、ヘシャム・ソリマン、マイケル・トーマス、マーガレット・ワッサーマンとアレックス・ジニンの貢献。
[IPv6] Deering, S. and R. Hinden, "Internet Protocol Version 6 Specification", RFC 2460, December 1998.
[IPv6] Deering、S。およびR. Hinden、「インターネットプロトコルバージョン6仕様」、RFC 2460、1998年12月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RND] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[RND] Eastlake、D.、Crocker、S。and J. Schiller、「セキュリティのためのランダム性推奨」、RFC 1750、1994年12月。
[AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[AH] Kent、S。およびR. Atkinson、「IP認証ヘッダー」、RFC 2402、1998年11月。
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[ESP] Kent、S。およびR. Atkinson、「IPカプセル化セキュリティペイロード（ESP）」、RFC 2406、1998年11月。
[INGR] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[Ingr] Ferguson、P。and D. Senie、「ネットワークイングレスフィルタリング：IPソースアドレススプーフィングを採用するサービス拒否攻撃の敗北」、BCP 38、RFC 2827、2000年5月。
[IPSec] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[IPSEC] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
Authors' Addresses
著者のアドレス
Jarno Rajahalme Nokia Research Center P.O. Box 407 FIN-00045 NOKIA GROUP, Finland
Jarno Rajahalme Nokia Research Center P.O.ボックス407フィン-00045ノキアグループ、フィンランド
EMail: jarno.rajahalme@nokia.com
Alex Conta Transwitch Corporation 3 Enterprise Drive Shelton, CT 06484 USA
Alex Conta Transwitch Corporation 3エンタープライズドライブシェルトン、CT 06484 USA
EMail: aconta@txc.com
Brian E. Carpenter IBM Zurich Research Laboratory Saeumerstrasse 4 / Postfach 8803 Rueschlikon Switzerland
ブライアンE.カーペンターIBMチューリッヒ研究研究所Saeumerstrasse 4 / Postfach 8803 Rueschlikon Switzerland
EMail: brc@zurich.ibm.com
Steve Deering Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA
Steve Deering Cisco Systems、Inc。170 West Tasman Drive San Jose、CA 95134-1706 USA
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004). 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.
著作権（c）The Internet Society（2004）。この文書は、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エディター機能の資金は現在、インターネット協会によって提供されています。