[要約] RFC 6935は、トンネル化されたパケットのIPv6とUDPのチェックサムに関する情報を提供する。その目的は、トンネル化されたパケットの正確性と信頼性を確保するために、IPv6とUDPのチェックサムの使用方法を定義することである。
Internet Engineering Task Force (IETF) M. Eubanks
Request for Comments: 6935 AmericaFree.TV LLC
Updates: 2460 P. Chimento
Category: Standards Track Johns Hopkins University Applied
ISSN: 2070-1721 Physics Laboratory
M. Westerlund
Ericsson
April 2013
IPv6 and UDP Checksums for Tunneled Packets
トンネルパケットのIPv6およびUDPチェックサム
Abstract
概要
This document updates the IPv6 specification (RFC 2460) to improve performance when a tunnel protocol uses UDP with IPv6 to tunnel packets. The performance improvement is obtained by relaxing the IPv6 UDP checksum requirement for tunnel protocols whose header information is protected on the "inner" packet being carried. Relaxing this requirement removes the overhead associated with the computation of UDP checksums on IPv6 packets that carry the tunnel protocol packets. This specification describes how the IPv6 UDP checksum requirement can be relaxed when the encapsulated packet itself contains a checksum. It also describes the limitations and risks of this approach and discusses the restrictions on the use of this method.
このドキュメントはIPv6仕様（RFC 2460）を更新して、トンネルプロトコルがIPv6でUDPを使用してパケットをトンネリングするときのパフォーマンスを向上させます。パフォーマンスの向上は、伝送される「内部」パケットでヘッダー情報が保護されているトンネルプロトコルのIPv6 UDPチェックサム要件を緩和することで得られます。この要件を緩和すると、トンネルプロトコルパケットを伝送するIPv6パケットのUDPチェックサムの計算に関連するオーバーヘッドが取り除かれます。この仕様では、カプセル化されたパケット自体にチェックサムが含まれている場合に、IPv6 UDPチェックサム要件を緩和する方法について説明しています。また、このアプローチの制限とリスク、およびこの方法の使用に関する制限についても説明します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6935.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6935で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Analysis of Corruption in Tunnel Context . . . . . . . . . 5
4.2. Limitation to Tunnel Protocols . . . . . . . . . . . . . . 7
4.3. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 8
5. The Zero UDP Checksum Update . . . . . . . . . . . . . . . . . 9
6. Additional Observations . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 11
This document constitutes an update of the IPv6 specification [RFC2460] for cases where a tunnel protocol uses UDP with IPv6 to tunnel packets. With the rapid growth of the Internet, tunnel protocols have become increasingly important to enable the deployment of new protocols. Tunnel protocols can be deployed rapidly, while the time to upgrade and deploy a new protocol on a critical mass of routers, middleboxes, and hosts on the global Internet is now measured in decades. At the same time, the increasing use of firewalls and other security-related middleboxes means that truly new tunnel protocols, with new protocol numbers, are also unlikely to be deployable in a reasonable time frame. The result is an increasing interest in and use of UDP-based tunnel protocols. In such protocols, there is an encapsulated "inner" packet, and the "outer" packet carrying the tunneled inner packet is a UDP packet, which can pass through firewalls and other middleboxes that perform the filtering that is a fact of life on the current Internet.
このドキュメントは、トンネルプロトコルがIPv6でUDPを使用してパケットをトンネリングする場合のIPv6仕様[RFC2460]の更新を構成します。インターネットの急速な成長に伴い、トンネルプロトコルは新しいプロトコルの展開を可能にするためにますます重要になっています。トンネルプロトコルは迅速に展開できますが、ルーター、ミドルボックス、およびグローバルインターネット上のホストの重要な質量で新しいプロトコルをアップグレードおよび展開する時間は、数十年で測定されるようになりました。同時に、ファイアウォールやその他のセキュリティ関連のミドルボックスの使用が増加しているため、新しいプロトコル番号を備えた真に新しいトンネルプロトコルも、妥当な時間枠で展開できる可能性は低いと言えます。その結果、UDPベースのトンネルプロトコルへの関心と使用が増加しています。このようなプロトコルでは、カプセル化された「内部」パケットがあり、トンネル化された内部パケットを運ぶ「外部」パケットはUDPパケットです。これは、ファイアウォールやその他のミドルボックスを通過でき、現在の現実のフィルタリングです。インターネット。
Tunnel endpoints may be routers or middleboxes aggregating traffic from a number of tunnel users. Therefore, the computation of an additional checksum on the outer UDP packet may be seen as an unwarranted burden on nodes that implement a tunnel protocol, especially if the inner packets are already protected by a checksum. IPv4 has a checksum over the IP packet header, and the checksum on the outer UDP packet may be set to zero. However, IPv6 has no checksum in the IP header, and RFC 2460 [RFC2460] explicitly states that IPv6 receivers MUST discard UDP packets with a zero checksum. So, while sending a UDP datagram with a zero checksum is permitted in IPv4 packets, it is explicitly forbidden in IPv6 packets. To improve support for IPv6 UDP tunnels, this document updates RFC 2460 to allow endpoints to use a zero UDP checksum under constrained situations (primarily for IPv6 tunnel transports that carry checksum-protected packets), following the applicability statements and constraints in [RFC6936].
トンネルエンドポイントは、ルーターまたはミドルボックスであり、多数のトンネルユーザーからのトラフィックを集約します。したがって、特に内部パケットがすでにチェックサムによって保護されている場合は、外部UDPパケットの追加のチェックサムの計算は、トンネルプロトコルを実装するノードに対する不当な負担と見なされる場合があります。 IPv4にはIPパケットヘッダーのチェックサムがあり、外側のUDPパケットのチェックサムはゼロに設定される場合があります。ただし、IPv6のIPヘッダーにはチェックサムがありません。RFC2460 [RFC2460]では、IPv6受信者はチェックサムがゼロのUDPパケットを破棄する必要があると明示されています。したがって、チェックサムがゼロのUDPデータグラムの送信はIPv4パケットで許可されていますが、IPv6パケットでは明示的に禁止されています。 IPv6 UDPトンネルのサポートを改善するために、このドキュメントはRFC 2460を更新し、[RFC6936]の適用性ステートメントと制約に従って、エンドポイントが制約された状況（主にチェックサムで保護されたパケットを運ぶIPv6トンネルトランスポート）でゼロUDPチェックサムを使用できるようにします。
When reading this document, the advice in "Unicast UDP Usage Guidelines for Application Designers" [RFC5405] is applicable. It discusses both UDP tunnels (Section 3.1.3) and the usage of checksums (Section 3.4).
このドキュメントを読むとき、「アプリケーション設計者のためのユニキャストUDP使用ガイドライン」[RFC5405]のアドバイスが適用されます。 UDPトンネル（セクション3.1.3）とチェックサムの使用法（セクション3.4）の両方について説明します。
While the origin of this specification is the problem raised by the draft titled "Automatic Multicast Tunnels", also known as "AMT" [AMT], we expect it to have wide applicability. Since the first draft of this RFC was written, the need for an efficient UDP tunneling mechanism has increased. Other IETF Working Groups, notably LISP [RFC6830] and Softwires [RFC5619], have expressed a need to update the UDP checksum processing in RFC 2460. We therefore expect this update to be applicable in the future to other tunnel protocols specified by these and other IETF Working Groups.
この仕様の起源は、「自動マルチキャストトンネル」というタイトルのドラフト（「AMT」としても知られている[AMT]）で提起された問題ですが、幅広い適用性があると期待しています。このRFCの最初のドラフトが作成されて以来、効率的なUDPトンネリングメカニズムの必要性が高まっています。他のIETFワーキンググループ、特にLISP [RFC6830]とSoftwires [RFC5619]は、RFC 2460でUDPチェックサム処理を更新する必要性を表明しています。したがって、これらのおよび他のプロトコルで指定されている他のトンネルプロトコルにこの更新が将来的に適用されると予想していますIETFワーキンググループ。
This document discusses only IPv6, because the problem being addressed does not exist for IPv4. Therefore, all references to "IP" should be understood as references to IPv6.
このドキュメントではIPv6についてのみ説明します。これは、IPv4では対処されている問題が存在しないためです。したがって、「IP」へのすべての言及は、IPv6への言及として理解されるべきです。
The document uses the terms "tunneling" and "tunneled" as adjectives when describing packets. When we refer to "tunneling packets", we refer to the outer packet header that provides the tunneling function. When we refer to "tunneled packets", we refer to the inner packet, i.e., the packet being carried in the tunnel.
このドキュメントでは、パケットを説明するときに、「トンネリング」および「トンネリング」という用語を形容詞として使用します。 「トンネリングパケット」とは、トンネリング機能を提供する外部パケットヘッダーを指します。 「トンネリングされたパケット」とは、内部パケット、つまりトンネルで運ばれているパケットを指します。
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 RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
When using tunnel protocols based on UDP, there can be both a benefit and a cost to computing and checking the UDP checksum of the outer (encapsulating) UDP transport header. In certain cases, where reducing the forwarding cost is important, the cost of the computation may outweigh the benefit of the checksum. This document provides an update for usage of the UDP checksum with IPv6. The update is specified for use by a tunnel protocol that transports packets that are themselves protected by a checksum.
UDPに基づくトンネルプロトコルを使用する場合、外側の（カプセル化された）UDPトランスポートヘッダーのUDPチェックサムを計算およびチェックすることには、利点とコストの両方があります。転送コストの削減が重要な特定のケースでは、計算のコストがチェックサムのメリットを上回る場合があります。このドキュメントでは、IPv6でのUDPチェックサムの使用に関する更新を提供します。更新は、チェックサムによって保護されているパケットを転送するトンネルプロトコルで使用するために指定されています。
"Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums" [RFC6936] describes issues related to allowing UDP over IPv6 to have a valid zero UDP checksum and is the starting point for this discussion. Sections 4 and 5 of [RFC6936], respectively, identify node implementation and usage requirements for datagrams sent and received with a zero UDP checksum. These sections introduce constraints on the usage of a zero checksum for UDP over IPv6. The remainder of this section analyzes the use of general tunnels and explains the motivations for why tunnel protocols are being permitted to use the method described in this update. It also discusses issues with middleboxes.
「ゼロチェックサムを使用したIPv6 UDPデータグラムの使用に関する適用性声明」[RFC6936]では、IPv6上のUDPに有効なゼロUDPチェックサムを許可することに関連する問題が説明されており、この議論の出発点となります。 [RFC6936]のセクション4と5はそれぞれ、UDPチェックサムがゼロで送受信されるデータグラムのノード実装と使用法の要件を識別します。これらのセクションでは、IPv6上のUDPのゼロチェックサムの使用に関する制約を紹介します。このセクションの残りの部分では、一般的なトンネルの使用を分析し、この更新で説明されている方法の使用がトンネルプロトコルに許可されている理由について説明します。ミドルボックスの問題についても説明します。
This section analyzes the impact of the different corruption modes in the context of a tunnel protocol. It specifies what needs to be considered by the designer and user of a tunnel protocol for the protocol to be robust. It also summarizes why use of a zero UDP checksum is thought to be safe for deployment.
このセクションでは、トンネルプロトコルのコンテキストにおけるさまざまな破損モードの影響を分析します。プロトコルを堅牢にするために、トンネルプロトコルの設計者とユーザーが考慮する必要があることを指定します。また、ゼロUDPチェックサムの使用が展開にとって安全であると考えられる理由も要約します。
o Context (i.e., tunneling state) should be established by exchanging application Protocol Data Units (PDUs) carried in checksummed UDP datagrams or by using other protocols that provide integrity protection against corruption. These control packets should also carry any negotiation required to enable the tunnel endpoint to accept UDP datagrams with a zero checksum and identify the set of ports that are used. It is important that the control traffic is robust against corruption, because undetected errors can lead to long-lived and significant failures that may affect much more than the single packet that was corrupted.
o コンテキスト（つまり、トンネリング状態）は、チェックサムされたUDPデータグラムで運ばれるアプリケーションプロトコルデータユニット（PDU）を交換するか、破損に対する整合性保護を提供する他のプロトコルを使用して確立する必要があります。これらの制御パケットは、トンネルエンドポイントがチェックサム0のUDPデータグラムを受け入れ、使用されるポートのセットを識別するために必要なネゴシエーションも運ぶ必要があります。検出されないエラーは、長期間にわたって重大な障害を引き起こし、破損した単一のパケット以外にも影響を与える可能性があるため、制御トラフィックは破損に対して堅牢であることが重要です。
o Keepalive datagrams with a zero UDP checksum should be sent to validate the network path, because the path between tunnel endpoints can change, and therefore, the set of middleboxes along the path may change during the life of an association. Paths with middleboxes that drop datagrams with a zero UDP checksum will drop these keepalives. To enable the tunnel endpoints to discover and react to this behavior in a timely way, the keepalive traffic should include datagrams with a non-zero checksum and datagrams with a zero checksum.
o UDPチェックサムがゼロのキープアライブデータグラムを送信してネットワークパスを検証する必要があります。これは、トンネルエンドポイント間のパスが変更される可能性があるため、アソシエーションの存続中にパスに沿ったミドルボックスのセットが変更される可能性があるためです。 UDPチェックサムがゼロのデータグラムをドロップするミドルボックスのあるパスは、これらのキープアライブをドロップします。トンネルエンドポイントがこの動作をタイムリーに検出して対応できるようにするには、キープアライブトラフィックにゼロ以外のチェックサムのデータグラムとゼロのチェックサムのデータグラムを含める必要があります。
o Receivers should attempt to detect corruption of the address information in an encapsulating packet. A robust tunnel protocol should track tunnel context based on the 5-tuple (tunneled protocol number, IPv6 source address, IPv6 destination address, UDP source port, UDP destination port). A corrupted datagram that arrives at a destination may be filtered based on this check.
o 受信側は、カプセル化パケット内のアドレス情報の破損を検出しようとする必要があります。堅牢なトンネルプロトコルは、5タプル（トンネルプロトコル番号、IPv6送信元アドレス、IPv6宛先アドレス、UDP送信元ポート、UDP宛先ポート）に基づいてトンネルコンテキストを追跡する必要があります。宛先に到着した破損したデータグラムは、このチェックに基づいてフィルタリングできます。
* If the datagram header matches the 5-tuple and the node has enabled the zero checksum for this port, the payload is matched to the wrong context. The tunneled packet will then be decapsulated and forwarded by the tunnel egress.
* データグラムヘッダーが5タプルと一致し、ノードがこのポートのゼロチェックサムを有効にしている場合、ペイロードは誤ったコンテキストと一致します。トンネル化されたパケットは、カプセル化が解除され、トンネル出力によって転送されます。
* If a corrupted datagram matches a different 5-tuple and the node has enabled zero checksum for the port, the datagram payload is matched to the wrong context and may be processed by the wrong tunnel protocol, provided that it also passes the verification of that protocol.
* 破損したデータグラムが別の5タプルと一致し、ノードでポートのゼロチェックサムが有効になっている場合、データグラムペイロードは誤ったコンテキストと一致し、そのプロトコルの検証にも合格すると、誤ったトンネルプロトコルによって処理される可能性があります。
* If a corrupted datagram matches a 5-tuple and node has not enabled the zero checksum for this port, the datagram will be discarded.
* 破損したデータグラムが5タプルに一致し、ノードがこのポートのゼロチェックサムを有効にしていない場合、データグラムは破棄されます。
When only the source information is corrupted, the datagram could arrive at the intended applications or protocol, which will process the datagram and try to match it against an existing tunnel context. The likelihood that a corrupted packet enters a valid context is reduced when the protocol restricts processing to only the source addresses with established contexts. When both source and destination fields are corrupted, this also decreases the likelihood of matching a context. However, the exception is when errors replace one packet header with another, so both packets could be tunneled, and therefore the corrupted packet could match a previously defined context.
ソース情報のみが破損している場合、データグラムは目的のアプリケーションまたはプロトコルに到達し、データグラムを処理して既存のトンネルコンテキストと照合しようとします。破損したパケットが有効なコンテキストに入る可能性は、プロトコルが処理を確立されたコンテキストを持つ送信元アドレスのみに制限する場合に減少します。ソースと宛先の両方のフィールドが破損している場合、これにより、コンテキストが一致する可能性も低くなります。ただし、例外は、エラーが1つのパケットヘッダーを別のパケットヘッダーに置き換える場合です。そのため、両方のパケットがトンネリングされ、破損したパケットが以前に定義されたコンテキストと一致する可能性があります。
o Receivers should attempt to detect corruption of source-fragmented encapsulating packets. A tunnel protocol may reassemble fragments associated with the wrong context at the right tunnel endpoint, it may reassemble fragments associated with a context at the wrong tunnel endpoint, or corrupted fragments may be reassembled at the right context at the right tunnel endpoint. In each of these cases, the IPv6 length of the encapsulating header may be checked (although [RFC6936] points out the weakness in this check). In addition, if the encapsulated packet is protected by a transport (or other) checksum, these errors can be detected (with some probability).
o 受信者は、ソースフラグメント化されたカプセル化パケットの破損を検出しようとする必要があります。トンネルプロトコルは、正しいトンネルエンドポイントで間違ったコンテキストに関連付けられたフラグメントを再構成する可能性があります。間違ったトンネルエンドポイントでコンテキストに関連付けられたフラグメントを再構成する可能性があります。または、破損したフラグメントは、正しいトンネルエンドポイントの正しいコンテキストで再構成される可能性があります。これらの各ケースでは、カプセル化ヘッダーのIPv6の長さがチェックされます（ただし、[RFC6936]はこのチェックの弱点を指摘しています）。さらに、カプセル化されたパケットがトランスポート（または他の）チェックサムによって保護されている場合、これらのエラーは（ある程度の確率で）検出できます。
o Compared to other applications, tunnel protocols using UDP have some advantages that reduce the risk for a corrupted tunnel packet reaching a destination that will receive it. These advantages result from processing by the network of the inner (tunneled) packet after it is forwarded from the tunnel egress using a wrong context:
o 他のアプリケーションと比較して、UDPを使用するトンネルプロトコルには、破損したトンネルパケットが宛先に到達するリスクを軽減するいくつかの利点があります。これらの利点は、間違ったコンテキストを使用してトンネルの出口から転送された後の内部（トンネル）パケットのネットワークによる処理に起因します。
* A tunneled packet may be forwarded to the wrong address domain, for example, to a private address domain where the inner packet's address is not routable, or it may fail a source address check, such as Unicast Reverse Path Forwarding [RFC2827], resulting in the packet being dropped.
* トンネル化されたパケットは、間違ったアドレスドメインに転送される可能性があります。たとえば、内部パケットのアドレスがルーティングできないプライベートアドレスドメインに転送される場合や、ユニキャストリバースパス転送[RFC2827]などの送信元アドレスチェックに失敗する場合があります。ドロップされるパケット
* The destination address of a tunneled packet may not be reachable at all from the delivered domain. An example is an Ethernet frame where the destination MAC address is not present on the LAN segment that was reached.
* トンネリングされたパケットの宛先アドレスは、配信されたドメインからまったく到達できない場合があります。例としては、到達したLANセグメントに宛先MACアドレスが存在しないイーサネットフレームがあります。
* The type of the tunneled packet may prevent delivery. For example, an attempt to interpret an IP packet payload as an Ethernet frame would likely to result in the packet being dropped as invalid.
* トンネリングされたパケットのタイプが配信を妨げる可能性があります。たとえば、IPパケットのペイロードをイーサネットフレームとして解釈しようとすると、パケットが無効として破棄される可能性があります。
* The tunneled packet checksum or integrity mechanism may detect corruption of the inner packet caused at the same time as corruption to the outer packet header. The resulting packet would likely be dropped as invalid.
* トンネルパケットチェックサムまたは整合性メカニズムは、外部パケットヘッダーの破損と同時に発生した内部パケットの破損を検出する場合があります。結果のパケットは無効として破棄される可能性があります。
Each of these checks significantly reduces the likelihood that a corrupted inner tunneled packet is finally delivered to a protocol listener that can be affected by the packet. While the methods do not guarantee correctness, they can reduce the risks of relaxing the UDP checksum requirement for a tunnel application using IPv6.
これらの各チェックにより、破損した内部トンネルパケットが最終的にパケットの影響を受ける可能性のあるプロトコルリスナーに配信される可能性が大幅に減少します。これらの方法は正確性を保証しませんが、IPv6を使用するトンネルアプリケーションのUDPチェックサム要件を緩和するリスクを減らすことができます。
This document describes the applicability of using a zero UDP checksum to support tunnel protocols. There are good motivations behind this, and the arguments are provided here.
このドキュメントでは、ゼロUDPチェックサムを使用してトンネルプロトコルをサポートすることの適用性について説明します。これには良い動機があり、議論はここで提供されます。
o Tunnels carry inner packets that have their own semantics, which may make any corruption less likely to reach the indicated destination and be accepted as a valid packet. This is true for IP packets with the addition of verification that can be made by the tunnel protocol, the network processing of the inner packet headers as discussed above, and verification of the inner packet checksums. Non-IP inner packets are likely to be subject to similar effects that may reduce the likelihood of a misdelivered packet being delivered to a protocol listener that can be affected by the packet.
o トンネルは、独自のセマンティクスを持つ内部パケットを伝送します。これにより、破損が指示された宛先に到達し、有効なパケットとして受け入れられる可能性が低くなります。これは、トンネルプロトコル、前述の内部パケットヘッダーのネットワーク処理、および内部パケットチェックサムの検証によって実行できる検証が追加されたIPパケットに当てはまります。非IP内部パケットは同様の影響を受ける可能性が高く、パケットの影響を受ける可能性のある、誤って配信されたパケットがプロトコルリスナーに配信される可能性を減らすことができます。
o Protocols that directly consume the payload must have sufficient robustness against misdelivered packets (from any context), including ones that are corrupted in tunnels or corrupted by other usage of the zero checksum. This will require an integrity mechanism. Using a standard UDP checksum reduces the computational load in the receiver that is necessary to verify this mechanism.
o ペイロードを直接消費するプロトコルは、トンネルで破損したり、ゼロチェックサムの他の使用法によって破損したりしたものも含め、（あらゆるコンテキストからの）誤って配信されたパケットに対して十分な堅牢性を備えている必要があります。これには整合性メカニズムが必要です。標準のUDPチェックサムを使用すると、このメカニズムを検証するために必要なレシーバーの計算負荷が軽減されます。
o The design for stateful protocols or protocols where corruption causes cascade effects requires extra care. In tunnel usage, each encapsulating packet provides no functions other than a transport from tunnel ingress to tunnel egress. A corruption will commonly affect only the single tunneled packet, not the established protocol state. One common effect is that the inner packet flow will see only a corruption and a misdelivery of the outer packet as a lost packet.
oステートフルプロトコルまたは破損がカスケード効果を引き起こすプロトコルの設計には、特別な注意が必要です。トンネルの使用では、各カプセル化パケットは、トンネル入口からトンネル出口へのトランスポート以外の機能を提供しません。破損は通常、確立されたプロトコル状態ではなく、単一のトンネルパケットにのみ影響します。一般的な影響の1つは、内部パケットフローでは、外部パケットの破損と誤配信のみが失われたパケットとして認識されることです。
o Some non-tunnel protocols operate with general servers that do not know the source from which they will receive a packet. In such applications, a zero UDP checksum is unsuitable, because it is necessary to provide the first level of verification that the packet was intended for the receiving server. A verification prevents the server from processing the datagram payload; without this, the server may spend significant resources processing the packet, including sending replies or error messages.
o 一部の非トンネルプロトコルは、パケットの受信元を知らない一般的なサーバーで動作します。このようなアプリケーションでは、UDPチェックサムがゼロの場合は適切ではありません。これは、パケットが受信サーバーを対象としたものであることを最初のレベルで確認する必要があるためです。検証により、サーバーはデータグラムのペイロードを処理できなくなります。これがないと、サーバーは、応答やエラーメッセージの送信など、パケットの処理にかなりのリソースを費やす可能性があります。
Tunnel protocols that encapsulate IP will generally be safe for deployment, because all IPv4 and IPv6 packets include at least one checksum at either the network or transport layer. The network delivery of the inner packet will then further reduce the effects of corruption. Tunnel protocols carrying non-IP packets may offer equivalent protection when the non-IP networks reduce the risk of misdelivery to applications. However, further analysis is necessary to understand the implications of misdelivery of corrupted packets for each non-IP protocol. The analysis above suggests that non-tunnel protocols can be expected to have significantly more cases where a zero checksum would result in misdelivery or negative side effects.
IPをカプセル化するトンネルプロトコルは、すべてのIPv4およびIPv6パケットにネットワーク層またはトランスポート層のいずれかに少なくとも1つのチェックサムが含まれているため、一般に展開しても安全です。内部パケットのネットワーク配信により、破損の影響がさらに軽減されます。非IPパケットを伝送するトンネルプロトコルは、非IPネットワークがアプリケーションへの誤配信のリスクを低減する場合、同等の保護を提供します。ただし、各非IPプロトコルの破損したパケットの誤配信の影響を理解するには、さらに分析が必要です。上記の分析は、非トンネルプロトコルでは、チェックサムがゼロの場合に配信ミスや悪影響が生じるケースが大幅に増えることが予想されることを示唆しています。
One unfortunate side effect of increased use of a zero checksum is that it also increases the likelihood of acceptance when a datagram with a zero UDP checksum is misdelivered. This requires all tunnel protocols using this method to be designed to be robust in the face of misdelivery.
ゼロチェックサムの使用が増えることの1つの不幸な副作用は、ゼロUDPチェックサムを持つデータグラムが誤って配信されたときにも受け入れられる可能性が高くなることです。これには、この方法を使用するすべてのトンネルプロトコルが、誤配信に直面しても堅牢になるように設計されている必要があります。
"Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums" [RFC6936] specifies requirements for middleboxes and tunnels that need to traverse middleboxes. Tunnel protocols intending to use a zero UDP checksum need to ensure that they have defined a method for handling cases when a middlebox prevents the path between the tunnel ingress and egress from supporting transmission of datagrams with a zero UDP checksum. This is especially important as middleboxes that conform to RFC 2460 are likely to discard datagrams with a zero UDP checksum.
「チェックサムがゼロのIPv6 UDPデータグラムの使用に関する適用性ステートメント」[RFC6936]は、ミドルボックスを通過する必要があるミドルボックスとトンネルの要件を指定しています。ゼロUDPチェックサムを使用するトンネルプロトコルは、ミドルボックスがトンネルの入口と出口の間のパスでゼロUDPチェックサムを使用したデータグラムの送信をサポートできない場合の処理方法を定義していることを確認する必要があります。 RFC 2460に準拠するミドルボックスは、UDPチェックサムがゼロのデータグラムを破棄する可能性が高いため、これは特に重要です。
This specification updates IPv6 to allow a zero UDP checksum in the outer encapsulating datagram of a tunnel protocol. UDP endpoints that implement this update MUST follow the node requirements in "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums" [RFC6936].
この仕様はIPv6を更新して、トンネルプロトコルの外側のカプセル化データグラムでゼロUDPチェックサムを許可します。この更新を実装するUDPエンドポイントは、「チェックサムがゼロのIPv6 UDPデータグラムの使用に関する適用性ステートメント」[RFC6936]のノード要件に従う必要があります。
The following text in [RFC2460], Section 8.1, fourth bullet should be deleted:
[RFC2460]、セクション8.1、4番目の箇条書きの次のテキストを削除する必要があります。
Unlike IPv4, when UDP packets are originated by an IPv6 node, the UDP checksum is not optional. That is, whenever originating a UDP packet, an IPv6 node must compute a UDP checksum over the packet and the pseudo-header, and, if that computation yields a result of zero, it must be changed to hex FFFF for placement in the UDP header. IPv6 receivers must discard UDP packets containing a zero checksum, and should log the error.
IPv4とは異なり、UDPパケットがIPv6ノードによって発信された場合、UDPチェックサムはオプションではありません。つまり、UDPパケットを発信するときは常に、IPv6ノードはパケットと疑似ヘッダーに対してUDPチェックサムを計算する必要があり、その計算結果がゼロの場合、UDPヘッダーに配置するために16進FFFFに変更する必要があります。 。 IPv6レシーバーは、ゼロのチェックサムを含むUDPパケットを破棄し、エラーをログに記録する必要があります。
This text should be replaced by:
このテキストは次のように置き換える必要があります。
An IPv6 node associates a mode with each used UDP port (for sending and/or receiving packets).
IPv6ノードは、（パケットの送受信のために）使用される各UDPポートにモードを関連付けます。
Whenever originating a UDP packet for a port in the default mode, an IPv6 node MUST compute a UDP checksum over the packet and the pseudo-header, and, if that computation yields a result of zero, the checksum MUST be changed to hex FFFF for placement in the UDP header, as specified in [RFC2460]. IPv6 receivers MUST by default discard UDP packets containing a zero checksum and SHOULD log the error.
デフォルトモードのポートのUDPパケットを発信するときは常に、IPv6ノードはパケットと疑似ヘッダーに対してUDPチェックサムを計算する必要があり、その計算結果がゼロの場合、チェックサムは16進FFFFに変更する必要があります。 [RFC2460]で指定されているUDPヘッダー内の配置。 IPv6レシーバーは、デフォルトで、ゼロのチェックサムを含むUDPパケットを破棄し、エラーをログに記録する必要があります（SHOULD）。
As an alternative, certain protocols that use UDP as a tunnel encapsulation MAY enable zero-checksum mode for a specific port (or set of ports) for sending and/or receiving. Any node implementing zero-checksum mode MUST follow the node requirements specified in Section 4 of "Applicability Statement for the use of IPv6 UDP Datagrams with Zero Checksums" [RFC6936].
代わりに、UDPをトンネルカプセル化として使用する特定のプロトコルは、送信および/または受信のために特定のポート（またはポートのセット）のゼロチェックサムモードを有効にする場合があります。ゼロチェックサムモードを実装するノードは、「ゼロチェックサムを使用したIPv6 UDPデータグラムの使用に関する適用性ステートメント」[RFC6936]のセクション4で指定されたノード要件に従う必要があります。
Any protocol that enables zero-checksum mode for a specific port or ports MUST follow the usage requirements specified in Section 5 of "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums" [RFC6936].
特定のポートでゼロチェックサムモードを有効にするプロトコルは、「ゼロチェックサムでのIPv6 UDPデータグラムの使用に関する適用性ステートメント」[RFC6936]のセクション5で指定された使用要件に従う必要があります。
Middleboxes supporting IPv6 MUST follow requirements 9, 10, and 11 of the usage requirements specified in Section 5 of "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums" [RFC6936].
IPv6をサポートするミドルボックスは、「チェックサムがゼロのIPv6 UDPデータグラムの使用に関する適用性ステートメント」[RFC6936]のセクション5で指定された使用要件の要件9、10、および11に従う必要があります。
This update was motivated by the existence of a number of protocols being developed in the IETF that are expected to benefit from the change. The following observations are made:
この更新は、IETFで開発されており、変更の恩恵を受けると予想される多数のプロトコルが存在することを動機としています。以下の観察が行われます：
o An empirically based analysis of the probabilities of packet corruption (with or without checksums) has not, to our knowledge, been conducted since about 2000. At the time of publication, it is now 2013. We strongly suggest that a new empirical study be performed, along with extensive analysis of the corruption probabilities of the IPv6 header. This could potentially allow revising the recommendations in this document.
o パケット破損（チェックサムの有無にかかわらず）の確率の経験に基づいた分析は、2000年頃から私たちの知る限りでは行われていません。発行時点では現在2013年です。新しい実証的研究を実施することを強くお勧めします、およびIPv6ヘッダーの破損確率の広範な分析とともに。これにより、このドキュメントの推奨事項を改訂できる可能性があります。
o A key motivation for the increase in use of UDP in tunneling is a lack of protocol support in middleboxes. Specifically, new protocols, such as LISP [RFC6830], may prefer to use UDP tunnels to traverse an end-to-end path successfully and avoid having their packets dropped by middleboxes. If middleboxes were updated to support UDP-Lite [RFC3828], UDP-Lite would provide better protection than offered by this update. UDP-Lite may be suited to a variety of applications and would be expected to be preferred over this method for many tunnel protocols.
o トンネリングでのUDPの使用が増加する主な動機は、ミドルボックスでのプロトコルサポートの欠如です。特に、LISP [RFC6830]などの新しいプロトコルは、UDPトンネルを使用してエンドツーエンドパスを正常に通過し、ミドルボックスによってパケットがドロップされるのを回避することを好む場合があります。 UDP-Lite [RFC3828]をサポートするようにミドルボックスが更新された場合、UDP-Liteはこの更新で提供されるよりも優れた保護を提供します。 UDP-Liteはさまざまなアプリケーションに適している可能性があり、この方法よりも多くのトンネルプロトコルに適していると予想されます。
o Another issue is that the UDP checksum is overloaded with the task of protecting the IPv6 header for UDP flows (as is the TCP checksum for TCP flows). Protocols that do not use a pseudo-header approach to computing a checksum or CRC have essentially no protection from misdelivered packets.
o 別の問題は、UDPチェックサムがUDPフローのIPv6ヘッダーを保護するタスクで過負荷になることです（TCPフローのTCPチェックサムと同様）。チェックサムまたはCRCの計算に疑似ヘッダーアプローチを使用しないプロトコルは、パケットの誤配信から本質的に保護されません。
Less work is required to generate an attack using a zero UDP checksum than one using a standard full UDP checksum. However, this does not lead to significant new vulnerabilities, because checksums are not a security measure and can be easily generated by any attacker.
ゼロのUDPチェックサムを使用して攻撃を生成するために必要な作業は、標準の完全なUDPチェックサムを使用するものよりも少なくて済みます。ただし、チェックサムはセキュリティ対策ではなく、攻撃者が簡単に生成できるため、これは重大な新しい脆弱性にはつながりません。
In general, any user of zero UDP checksums should apply the checks and context verification that are possible to minimize the risk of unintended traffic to reach a particular context. This will, however, not protect against an intentional attack that creates packets with the correct information. Source address validation can help prevent injection of traffic into contexts by an attacker.
一般に、UDPチェックサムがゼロのユーザーは、意図しないトラフィックが特定のコンテキストに到達するリスクを最小限に抑えるために可能なチェックとコンテキスト検証を適用する必要があります。ただし、これは、正しい情報を含むパケットを作成する意図的な攻撃を防ぐことはできません。送信元アドレスの検証は、攻撃者によるコンテキストへのトラフィックの注入を防ぐのに役立ちます。
Depending on the hardware design, the processing requirements may differ for tunnels that have a zero UDP checksum and those that calculate a checksum. This processing overhead may need to be considered when deciding whether to enable a tunnel and to determine an acceptable rate for transmission. This processing overhead can become a security risk for designs that can handle a significantly larger number of packets with zero UDP checksums compared to datagrams with a non-zero checksum, such as a tunnel egress. An attacker could attempt to inject non-zero checksummed UDP packets into a tunnel forwarding zero checksum UDP packets and cause overload in the processing of the non-zero checksums, e.g., if this happens in a router's slow path. Therefore, protection mechanisms should be employed when this threat exists. Protection may include source-address filtering to prevent an attacker from injecting traffic, as well as throttling the amount of non-zero checksum traffic. The latter may impact the functioning of the tunnel protocol.
ハードウェア設計によっては、UDPチェックサムがゼロのトンネルと、チェックサムを計算するトンネルの処理要件が異なる場合があります。この処理オーバーヘッドは、トンネルを有効にするかどうか、および伝送の許容速度を決定するかどうかを決定するときに考慮する必要がある場合があります。この処理オーバーヘッドは、UDPチェックサムがゼロの非常に多くのパケットを処理できる設計では、トンネル出力などのゼロ以外のチェックサムのデータグラムと比較して、セキュリティリスクになる可能性があります。攻撃者は、ゼロ以外のチェックサムUDPパケットをトンネル転送ゼロゼロチェックサムUDPパケットに挿入しようと試み、非ゼロチェックサムの処理で過負荷を引き起こす可能性があります（これがルーターの低速パスで発生した場合など）。したがって、この脅威が存在する場合は、保護メカニズムを採用する必要があります。保護には、攻撃者がトラフィックを注入するのを防ぐための送信元アドレスフィルタリングや、ゼロ以外のチェックサムトラフィックの量を抑制することが含まれます。後者は、トンネルプロトコルの機能に影響を与える可能性があります。
We would like to thank Brian Haberman, Dan Wing, Joel Halpern, David Waltermire, J.W. Atwood, Peter Yee, Joe Touch, and the IESG of 2012 for discussions and reviews. Gorry Fairhurst has been very diligent in reviewing and helping to ensure alignment between this document and [RFC6936].
Brian Haberman、Dan Wing、Joel Halpern、David Waltermire、J.Wに感謝します。 Atwood、Peter Yee、Joe Touch、およびディスカッションとレビューのための2012年のIESG。 Gorry Fairhurstは、このドキュメントと[RFC6936]の整合性を確認し、それを確実にするために非常に勤勉でした。
[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月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 6936, April 2013.
[RFC6936] Fairhurst、G。およびM. Westerlund、「ゼロチェックサムを使用したIPv6 UDPデータグラムの使用に関する適用性声明」、RFC 6936、2013年4月。
[AMT] Bumgardner, G., "Automatic Multicast Tunneling", Work in Progress, June 2012.
[AMT] Bumgardner、G。、「Automatic Multicast Tunneling」、Work in Progress、2012年6月。
[RFC2827] 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.
[RFC2827]ファーガソン、P。およびD.セニー、「ネットワーク入力フィルタリング：IP送信元アドレスのスプーフィングを利用するサービス拒否攻撃の阻止」、BCP 38、RFC 2827、2000年5月。
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G. Fairhurst, "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, July 2004.
[RFC3828] Larzon、L-A。、Degermark、M.、Pink、S.、Jonsson、L-E。、およびG. Fairhurst、「The Lightweight User Datagram Protocol（UDP-Lite）」、RFC 3828、2004年7月。
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008.
[RFC5405] Eggert、L。およびG. Fairhurst、「アプリケーション設計者のためのユニキャストUDP使用ガイドライン」、BCP 145、RFC 5405、2008年11月。
[RFC5619] Yamamoto, S., Williams, C., Yokota, H., and F. Parent, "Softwire Security Analysis and Requirements", RFC 5619, August 2009.
[RFC5619] Yamamoto、S.、Williams、C.、Yokota、H.、and F. Parent、 "Softwire Security Analysis and Requirements"、RFC 5619、August 2009。
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, January 2013.
[RFC6830] Farinacci、D.、Fuller、V.、Meyer、D。、およびD. Lewis、「Locator / ID Separation Protocol（LISP）」、RFC 6830、2013年1月。
Authors' Addresses
著者のアドレス
Marshall Eubanks AmericaFree.TV LLC P.O. Box 141 Clifton, Virginia 20124 USA
マーシャルユーバンクスAmericaFree.TV LLC P.O. Box 141 Clifton、Virginia 20124 USA
Phone: +1-703-501-4376
EMail: marshall.eubanks@gmail.com
P.F. Chimento Johns Hopkins University Applied Physics Laboratory 11100 Johns Hopkins Road Laurel, Maryland 20723 USA
P.F. Chimento Johns Hopkins University Applied Physics Laboratory 11100 Johns Hopkins Road Laurel、Maryland 20723 USA
Phone: +1-443-778-1743
EMail: Philip.Chimento@jhuapl.edu
Magnus Westerlund Ericsson Farogatan 6 SE-164 80 Kista Sweden
Magnus Westerlund Ericsson Farogatan 6 SE-164 80 Kistaスウェーデン
Phone: +46 10 719 00 00
EMail: magnus.westerlund@ericsson.com