[要約] RFC 6936は、IPv6 UDPデータグラムのゼロチェックサムの使用に関する適用性文書です。その目的は、ゼロチェックサムを使用することの利点と制約を説明し、IPv6ネットワークでの使用を促進することです。
Internet Engineering Task Force (IETF) G. Fairhurst
Request for Comments: 6936 University of Aberdeen
Category: Standards Track M. Westerlund
ISSN: 2070-1721 Ericsson
April 2013
Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums
チェックサムがゼロのIPv6 UDPデータグラムの使用に関する適用性声明
Abstract
概要
This document provides an applicability statement for the use of UDP transport checksums with IPv6. It defines recommendations and requirements for the use of IPv6 UDP datagrams with a zero UDP checksum. It describes the issues and design principles that need to be considered when UDP is used with IPv6 to support tunnel encapsulations, and it examines the role of the IPv6 UDP transport checksum. The document also identifies issues and constraints for deployment on network paths that include middleboxes. An appendix presents a summary of the trade-offs that were considered in evaluating the safety of the update to RFC 2460 that changes the use of the UDP checksum with IPv6.
このドキュメントは、IPv6でUDPトランスポートチェックサムを使用するための適用性ステートメントを提供します。これは、UDPチェックサムがゼロのIPv6 UDPデータグラムの使用に関する推奨事項と要件を定義しています。トンネルカプセル化をサポートするためにIPv6でUDPを使用するときに考慮する必要がある問題と設計原則について説明し、IPv6 UDPトランスポートチェックサムの役割を調べます。このドキュメントでは、ミドルボックスを含むネットワークパスでの展開に関する問題と制約についても説明しています。付録では、IPv6でのUDPチェックサムの使用を変更するRFC 2460への更新の安全性を評価する際に考慮されたトレードオフの概要を示します。
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/rfc6936.
このドキュメントの現在のステータス、エラッタ、フィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6936で入手できます。
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Document Structure . . . . . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Use of UDP Tunnels . . . . . . . . . . . . . . . . . . . . 6
1.3.1. Motivation for New Approaches . . . . . . . . . . . . 6
1.3.2. Reducing Forwarding Costs . . . . . . . . . . . . . . 6
1.3.3. Need to Inspect the Entire Packet . . . . . . . . . . 7
1.3.4. Interactions with Middleboxes . . . . . . . . . . . . 7
1.3.5. Support for Load Balancing . . . . . . . . . . . . . . 8
2. Standards-Track Transports . . . . . . . . . . . . . . . . . . 9
2.1. UDP with Standard Checksum . . . . . . . . . . . . . . . . 9
2.2. UDP-Lite . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1. Using UDP-Lite as a Tunnel Encapsulation . . . . . . . 10
2.3. General Tunnel Encapsulations . . . . . . . . . . . . . . 10
2.4. Relationship of Zero UDP Checksum to UDP-Lite and UDP
with Checksum . . . . . . . . . . . . . . . . . . . . . . 11
3. Issues Requiring Consideration . . . . . . . . . . . . . . . . 12
3.1. Effect of Packet Modification in the Network . . . . . . . 13
3.1.1. Corruption of the Destination IP Address Field . . . . 14
3.1.2. Corruption of the Source IP Address Field . . . . . . 15
3.1.3. Corruption of Port Information . . . . . . . . . . . . 16
3.1.4. Delivery to an Unexpected Port . . . . . . . . . . . . 16
3.1.5. Corruption of Fragmentation Information . . . . . . . 18
3.2. Where Packet Corruption Occurs . . . . . . . . . . . . . . 20
3.3. Validating the Network Path . . . . . . . . . . . . . . . 20
3.4. Applicability of the Zero UDP Checksum Method . . . . . . 21
3.5. Impact on Non-Supporting Devices or Applications . . . . . 22
4. Constraints on Implementation of IPv6 Nodes Supporting
Zero Checksum . . . . . . . . . . . . . . . . . . . . . . . . 23
5. Requirements on Usage of the Zero UDP Checksum . . . . . . . . 24
6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
9.1. Normative References . . . . . . . . . . . . . . . . . . . 30
9.2. Informative References . . . . . . . . . . . . . . . . . . 30
Appendix A. Evaluation of Proposal to Update RFC 2460 to
Support Zero Checksum . . . . . . . . . . . . . . . . 33
A.1. Alternatives to the Standard Checksum . . . . . . . . . . 33
A.2. Comparison of Alternative Methods . . . . . . . . . . . . 34
A.2.1. Middlebox Traversal . . . . . . . . . . . . . . . . . 34
A.2.2. Load Balancing . . . . . . . . . . . . . . . . . . . . 35
A.2.3. Ingress and Egress Performance Implications . . . . . 36
A.2.4. Deployability . . . . . . . . . . . . . . . . . . . . 36
A.2.5. Corruption Detection Strength . . . . . . . . . . . . 37
A.2.6. Comparison Summary . . . . . . . . . . . . . . . . . . 37
The User Datagram Protocol (UDP) [RFC0768] transport is defined for IPv4 [RFC0791], and it is defined in "Internet Protocol, Version 6 (IPv6)" [RFC2460] for IPv6 hosts and routers. The UDP transport protocol has a minimal set of features. This limited set has enabled a wide range of applications to use UDP, but these applications do need to provide many important transport functions on top of UDP. The UDP usage guidelines [RFC5405] provide overall guidance for application designers, including the use of UDP to support tunneling. The key difference between UDP usage with IPv4 and IPv6 is that RFC 2460 mandates use of a calculated UDP checksum, i.e., a non-zero value, due to the lack of an IPv6 header checksum. The inclusion of the pseudo-header in the checksum computation provides a statistical check that datagrams have been delivered to the intended IPv6 destination node. Algorithms for checksum computation are described in [RFC1071].
User Datagram Protocol（UDP）[RFC0768]トランスポートはIPv4 [RFC0791]で定義されており、IPv6ホストとルーターの「インターネットプロトコル、バージョン6（IPv6）」[RFC2460]で定義されています。 UDPトランスポートプロトコルには、最小限の機能セットがあります。この限られたセットにより、幅広いアプリケーションがUDPを使用できるようになりましたが、これらのアプリケーションはUDPに加えて多くの重要なトランスポート機能を提供する必要があります。 UDP使用ガイドライン[RFC5405]は、トンネリングをサポートするためのUDPの使用を含む、アプリケーション設計者向けの全体的なガイダンスを提供します。 IPv4とIPv6でのUDPの使用法の主な違いは、RFC 2460では、IPv6ヘッダーのチェックサムがないため、計算されたUDPチェックサム、つまりゼロ以外の値の使用が義務付けられていることです。チェックサム計算に疑似ヘッダーを含めることにより、データグラムが目的のIPv6宛先ノードに配信されたことを統計的に確認できます。チェックサム計算のアルゴリズムは、[RFC1071]で説明されています。
The inability to use an IPv6 datagram with a zero UDP checksum has been found to be a real problem for certain classes of application, primarily tunnel applications. This class of application has been deployed with a zero UDP checksum using IPv4. The design of IPv6 raises different issues when considering the safety of using a UDP checksum with IPv6. These issues can significantly affect applications, whether an endpoint is the intended user or an innocent bystander (i.e., when a packet is received by a different endpoint to that intended).
UDPチェックサムがゼロのIPv6データグラムを使用できないことは、主にトンネルアプリケーションなど、特定のクラスのアプリケーションにとって実際の問題であることが判明しています。このクラスのアプリケーションは、IPv4を使用したゼロUDPチェックサムで展開されています。 IPv6でUDPチェックサムを使用することの安全性を検討する場合、IPv6の設計にはさまざまな問題があります。これらの問題は、エンドポイントが意図されたユーザーであろうと無実の傍観者であろうと（つまり、意図されたものとは異なるエンドポイントによってパケットが受信された場合など）、アプリケーションに大きな影響を与える可能性があります。
This document identifies a set of issues that must be considered and mitigated to enable safe deployment of IPv6 applications that use a zero UDP checksum. The appendix compares the strengths and weaknesses of a number of proposed solutions. The comparison of methods provided in this document is also expected to be useful when considering applications that have different goals from the ones whose needs led to the writing of this document, especially applications that can use existing standardized transport protocols. The analysis concludes that using a zero UDP checksum is the best method of the proposed alternatives to meet the goals of certain tunnel applications.
このドキュメントでは、ゼロのUDPチェックサムを使用するIPv6アプリケーションの安全な展開を可能にするために考慮および軽減する必要がある一連の問題を特定します。付録では、いくつかの提案されたソリューションの長所と短所を比較しています。このドキュメントで提供されている方法の比較は、このドキュメントの作成につながったニーズとは異なる目的を持つアプリケーション、特に既存の標準化されたトランスポートプロトコルを使用できるアプリケーションを検討するときにも役立つと予想されます。分析では、UDPチェックサムをゼロにすることが、特定のトンネルアプリケーションの目標を達成するために提案された代替策の最良の方法であると結論付けています。
This document defines recommendations and requirements for use of IPv6 datagrams with a zero UDP checksum. This usage is expected to have initial deployment issues related to middleboxes, limiting the usability more than desired in the currently deployed Internet. However, this limitation will be largest initially and will decrease as updates are provided in middleboxes that support the zero UDP checksum for IPv6. Therefore, in this document, we derive a set of constraints required to ensure safe deployment of a zero UDP checksum.
このドキュメントでは、UDPチェックサムがゼロのIPv6データグラムの使用に関する推奨事項と要件を定義しています。この使用法では、ミドルボックスに関連する初期展開の問題が発生することが予想され、現在展開されているインターネットで望まれる以上に使いやすさが制限されます。ただし、この制限は最初は最大で、IPv6のゼロUDPチェックサムをサポートするミドルボックスで更新が提供されるため、減少します。したがって、このドキュメントでは、ゼロUDPチェックサムを安全に展開するために必要な一連の制約を導き出します。
Finally, the document identifies some issues that require future consideration and possibly additional research.
最後に、このドキュメントでは、将来の検討とおそらく追加の調査が必要ないくつかの問題を特定します。
Section 1 provides a background to key issues and introduces the use of UDP as a tunnel transport protocol.
セクション1では、主要な問題の背景を説明し、UDPをトンネル転送プロトコルとして使用する方法を紹介します。
Section 2 describes a set of standards-track datagram transport protocols that may be used to support tunnels.
セクション2では、トンネルのサポートに使用できる一連の標準化トラックデータグラムトランスポートプロトコルについて説明します。
Section 3 discusses issues with a zero UDP checksum for IPv6. It considers the impact of corruption, the need for validation of the path, and when it is suitable to use a zero UDP checksum.
セクション3では、IPv6のUDPチェックサムがゼロの問題について説明します。破損の影響、パスの検証の必要性、およびゼロUDPチェックサムを使用するのが適切な場合を考慮します。
Section 4 is an applicability statement that defines requirements and recommendations on the implementation of IPv6 nodes that support the use of a zero UDP checksum.
セクション4は、ゼロUDPチェックサムの使用をサポートするIPv6ノードの実装に関する要件と推奨事項を定義する適用性ステートメントです。
Section 5 provides an applicability statement that defines requirements and recommendations for protocols and tunnel encapsulations that are transported over an IPv6 transport that does not perform a UDP checksum calculation to verify the integrity at the transport endpoints.
セクション5は、トランスポートエンドポイントでの整合性を検証するためのUDPチェックサム計算を実行しないIPv6トランスポートを介してトランスポートされるプロトコルとトンネルカプセル化の要件と推奨事項を定義する適用性ステートメントを提供します。
Section 6 provides the recommendations for standardization of zero UDP checksum, with a summary of the findings, and notes the remaining issues that need future work.
セクション6では、UDPチェックサムをゼロに標準化するための推奨事項とその結果の概要を示し、今後の作業が必要な残りの問題について説明します。
Appendix A evaluates the set of proposals to update the UDP transport behavior and other alternatives intended to improve support for tunnel protocols. It concludes by assessing the trade-offs of the various methods and by identifying advantages and disadvantages for each method.
付録Aでは、UDPトランスポートの動作を更新するための一連の提案と、トンネルプロトコルのサポートを改善することを目的としたその他の代替案を評価しています。最後に、さまざまな方法のトレードオフを評価し、各方法の利点と欠点を特定します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
One increasingly popular use of UDP is as a tunneling protocol, where a tunnel endpoint encapsulates the packets of another protocol inside UDP datagrams and transmits them to another tunnel endpoint. Using UDP as a tunneling protocol is attractive when the payload protocol is not supported by the middleboxes that may exist along the path, because many middleboxes support transmission using UDP. In this use, the receiving endpoint decapsulates the UDP datagrams and forwards the original packets contained in the payload [RFC5405]. Tunnels establish virtual links that appear to directly connect locations that are distant in the physical Internet topology, and they can be used to create virtual (private) networks.
UDPの使用がますます一般的になっているのは、トンネリングプロトコルとしての使用です。トンネルエンドポイントは、UDPデータグラム内の別のプロトコルのパケットをカプセル化し、それらを別のトンネルエンドポイントに送信します。多くのミドルボックスはUDPを使用した送信をサポートしているため、ペイロードプロトコルがパスに沿って存在する可能性のあるミドルボックスでサポートされていない場合、トンネリングプロトコルとしてUDPを使用することは魅力的です。この用途では、受信エンドポイントがUDPデータグラムのカプセル化を解除し、ペイロードに含まれる元のパケットを転送します[RFC5405]。トンネルは、物理的なインターネットトポロジで離れた場所を直接接続しているように見える仮想リンクを確立し、仮想（プライベート）ネットワークを作成するために使用できます。
A number of tunnel encapsulations deployed over IPv4 have used the UDP transport with a zero checksum. Users of these protocols expect a similar solution for IPv6.
IPv4を介して展開されたいくつかのトンネルカプセル化では、チェックサムがゼロのUDPトランスポートが使用されています。これらのプロトコルのユーザーは、IPv6の同様のソリューションを期待しています。
A number of tunnel protocols are also currently being defined (e.g., Automated Multicast Tunnels [AMT] and Locator/Identifier Separation Protocol (LISP) [RFC6830]). These protocols provided several motivations to update IPv6 UDP checksum processing so that it would benefit from simpler checksum processing, including:
現在、多数のトンネルプロトコルも定義されています（たとえば、Automated Multicast Tunnels [AMT]およびLocator / Identifier Separation Protocol（LISP）[RFC6830]）。これらのプロトコルは、IPv6 UDPチェックサム処理を更新するいくつかの動機を提供しました。
o Reducing forwarding costs, motivated by redundancy present in the encapsulated packet header, because in tunnel encapsulations, payload integrity and length verification may be provided by higher-layer encapsulations (often using the IPv4, UDP, UDP-Lite [RFC3828], or TCP checksums [RFC0793]).
o トンネルのカプセル化では、ペイロードの整合性と長さの検証が上位層のカプセル化（多くの場合、IPv4、UDP、UDP-Lite [RFC3828]、またはTCPチェックサムを使用）によって提供されるため、転送コストを削減します。 [RFC0793]）。
o Eliminating the need to access the entire packet when a tunnel endpoint forwards the packet.
o トンネルエンドポイントがパケットを転送するときに、パケット全体にアクセスする必要がなくなります。
o Enhancing the ability to traverse and function with middleboxes.
o ミドルボックスを横断して機能する機能を強化します。
o A desire to use the port number space to enable load sharing.
o 負荷分散を可能にするためにポート番号スペースを使用したい。
It is a common requirement to terminate a large number of tunnels on a single router or host. The processing cost per tunnel includes both state (memory requirements) and per-packet processing at the tunnel ingress and egress.
単一のルーターまたはホストで多数のトンネルを終端することは一般的な要件です。トンネルごとの処理コストには、トンネルの入口と出口での状態（メモリ要件）とパケットごとの処理の両方が含まれます。
Automatic IP Multicast Tunneling, known as AMT [AMT], currently specifies UDP as the transport protocol for packets carrying tunneled IP multicast packets. The current specification for AMT states that the UDP checksum in the outer packet header should be zero (see Section 6.6 of [AMT]). That section argues that the computation of an additional checksum is an unwarranted burden on nodes implementing lightweight tunneling protocols when an inner packet is already adequately protected. The AMT protocol needs to replicate a multicast packet to each gateway tunnel. In this case, the outer IP addresses are different for each tunnel; therefore, a different pseudo-header must be built to form the header for each tunnel egress that receives replicated multicast packets.
AMT [AMT]と呼ばれる自動IPマルチキャストトンネリングは、現在、トンネルIPマルチキャストパケットを運ぶパケットのトランスポートプロトコルとしてUDPを指定しています。 AMTの現在の仕様では、外部パケットヘッダーのUDPチェックサムはゼロである必要があります（[AMT]のセクション6.6を参照）。そのセクションは、追加のチェックサムの計算は、内部パケットがすでに適切に保護されている場合に、軽量トンネリングプロトコルを実装するノードに不当な負担があると主張しています。 AMTプロトコルは、マルチキャストパケットを各ゲートウェイトンネルに複製する必要があります。この場合、外部IPアドレスはトンネルごとに異なります。したがって、複製されたマルチキャストパケットを受信する各トンネル出口のヘッダーを形成するには、異なる疑似ヘッダーを作成する必要があります。
The argument concerning redundant processing costs is valid regarding the integrity of a tunneled packet. In some architectures (e.g., PC-based routers), other mechanisms may also significantly reduce checksum processing costs. For example, there are implementations that have optimized checksum processing algorithms, including the use of checksum offloading. This processing is readily available for IPv4 packets at high line rates. Such processing may be anticipated for IPv6 endpoints, allowing receivers to reject corrupted packets without further processing. However, for certain classes of tunnel endpoints, this off-loading is not available and is unlikely to become available in the near future.
冗長な処理コストに関する議論は、トンネル化されたパケットの完全性に関して有効です。一部のアーキテクチャ（PCベースのルーターなど）では、他のメカニズムでもチェックサム処理コストを大幅に削減できます。たとえば、チェックサムオフロードの使用を含む、チェックサム処理アルゴリズムを最適化した実装があります。この処理は、高いラインレートのIPv4パケットですぐに利用できます。このような処理はIPv6エンドポイントで予期される可能性があり、レシーバーは破損したパケットをさらに処理せずに拒否できます。ただし、トンネルエンドポイントの特定のクラスでは、このオフロードは利用できず、近い将来利用可能になる可能性は低いです。
The currently deployed hardware in many routers uses a fast-path processing that provides only the first n bytes of a packet to the forwarding engine, where typically n <= 128.
現在多くのルーターに配備されているハードウェアは、パケットの最初のnバイトのみをフォワーディングエンジンに提供する高速パス処理を使用します。通常、n <= 128です。
When this design is used to support a tunnel ingress and egress, it prevents fast processing of a transport checksum over an entire (large) packet. Hence, the currently defined IPv6 UDP checksum is poorly suited for use within a router that is unable to access the entire packet and does not provide checksum off-loading. Thus, enabling checksum calculation over the complete packet can impact router design, performance, energy consumption, and cost.
この設計を使用してトンネルの入力と出力をサポートすると、（大きな）パケット全体でトランスポートチェックサムが高速に処理されなくなります。したがって、現在定義されているIPv6 UDPチェックサムは、パケット全体にアクセスできず、チェックサムのオフロードを提供しないルーター内での使用にはあまり適していません。したがって、パケット全体に対してチェックサム計算を有効にすると、ルーターの設計、パフォーマンス、エネルギー消費、およびコストに影響を与える可能性があります。
Many paths in the Internet include one or more middleboxes of various types. Large classes of middleboxes will handle zero UDP checksum packets, but do not support UDP-Lite or the other investigated proposals. These middleboxes include load balancers (see Section 1.3.5) including equal-cost multipath (ECMP) routing, traffic classifiers, and other functions that reads some fields in the UDP headers but does not validate the UDP checksum.
インターネットの多くのパスには、さまざまなタイプのミドルボックスが1つ以上含まれています。大きなクラスのミドルボックスは、UDPチェックサムパケットをゼロで処理しますが、UDP-Liteまたはその他の調査された提案をサポートしていません。これらのミドルボックスには、等コストマルチパス（ECMP）ルーティング、トラフィック分類子、およびUDPヘッダーの一部のフィールドを読み取るがUDPチェックサムを検証しないその他の機能を含むロードバランサー（セクション1.3.5を参照）が含まれます。
There are also middleboxes that either validate or modify the UDP checksum. The two most common classes are firewalls and NATs. In IPv4, UDP encapsulation may be desirable for NAT traversal, because UDP support is commonly provided. It is also necessary due to the almost ubiquitous deployment of IPv4 NATs. There has also been discussion of NAT for IPv6, although not for the same reason as in IPv4. If IPv6 NAT becomes a reality, it hopefully will not present the same protocol issues as for IPv4. If NAT is defined for IPv6, it should take into consideration the use of a zero UDP checksum.
UDPチェックサムを検証または変更するミドルボックスもあります。最も一般的な2つのクラスは、ファイアウォールとNATです。 IPv4では、UDPサポートが一般的に提供されているため、NATトラバーサルにはUDPカプセル化が望ましい場合があります。また、IPv4 NATのユビキタスな展開のためにも必要です。 IPv4と同じ理由ではありませんが、IPv6のNATについても議論されています。 IPv6 NATが現実のものになれば、IPv4の場合と同じプロトコルの問題が発生しないことが期待されます。 NATがIPv6用に定義されている場合は、ゼロUDPチェックサムの使用を考慮する必要があります。
The requirements for IPv6 firewall traversal are likely be to be similar to those for IPv4. In addition, it can be reasonably expected that a firewall conforming to RFC 2460 will not regard datagrams with a zero UDP checksum as valid. Use of a zero UDP checksum with IPv6 requires firewalls to be updated before the full utility of the change becomes available.
IPv6ファイアウォールトラバーサルの要件は、IPv4の要件と同様になる可能性があります。さらに、RFC 2460に準拠するファイアウォールは、UDPチェックサムがゼロのデータグラムを有効と見なさないことが合理的に期待できます。 IPv6でゼロUDPチェックサムを使用するには、変更の完全なユーティリティが利用可能になる前にファイアウォールを更新する必要があります。
It can be expected that datagrams with zero UDP checksum will initially not have the same middlebox traversal characteristics as regular UDP (RFC 2460). However, when implementations follow the requirements specified in this document, we expect the traversal capabilities to improve over time. We also note that deployment of IPv6-capable middleboxes is still in its initial phases. Thus, it might be that the number of non-updated boxes quickly becomes a very small percentage of the deployed middleboxes.
UDPチェックサムがゼロのデータグラムは、最初は通常のUDP（RFC 2460）と同じミドルボックストラバーサル特性を持たないことが予想されます。ただし、実装がこのドキュメントで指定された要件に従っている場合は、トラバーサル機能が時間とともに改善することが期待されます。また、IPv6対応のミドルボックスの導入はまだ初期段階にあることにも注意してください。したがって、更新されていないボックスの数が、デプロイされたミドルボックスの非常に小さい割合になる可能性があります。
The UDP port number fields have been used as a basis to design load-balancing solutions for IPv4. This approach has also been leveraged for IPv6. An alternate method would be to utilize the IPv6 flow label [RFC6437] as a basis for entropy for load balancing. This would have the desirable effect of freeing IPv6 load-balancing devices from the need to assume semantics for the use of the transport port field, and also, it works for all types of transport protocols.
UDPポート番号フィールドは、IPv4の負荷分散ソリューションを設計するための基礎として使用されています。このアプローチはIPv6でも活用されています。別の方法は、負荷分散のエントロピーの基礎としてIPv6フローラベル[RFC6437]を利用することです。これは、トランスポートポートフィールドの使用に関するセマンティクスを前提とする必要からIPv6ロードバランシングデバイスを解放するという望ましい効果があり、すべてのタイプのトランスポートプロトコルで機能します。
This use of the Flow Label for load balancing is consistent with the intended use, although further clarity was needed to ensure the field can be consistently used for this purpose. Therefore, an updated IPv6 flow label [RFC6437] and ECMP routing [RFC6438] usage were specified. Router vendors could be encouraged to start using the IPv6 Flow Label as a part of the flow hash, providing support for ECMP without requiring use of UDP.
負荷分散のためのフローラベルのこの使用は、意図された使用と一致していますが、この目的のためにフィールドを一貫して使用できるようにするために、さらに明確にする必要がありました。したがって、更新されたIPv6フローラベル[RFC6437]およびECMPルーティング[RFC6438]の使用法が指定されました。ルーターベンダーは、IPv6フローラベルをフローハッシュの一部として使用し始め、UDPを使用せずにECMPのサポートを提供することを推奨できます。
However, the method for populating the outer IPv6 header with a value for the flow label is not trivial. If the inner packet uses IPv6, the flow label value could be copied to the outer packet header.
ただし、外部IPv6ヘッダーにフローラベルの値を入力する方法は簡単ではありません。内部パケットがIPv6を使用する場合、フローラベル値は外部パケットヘッダーにコピーできます。
However, many current endpoints set the flow label to a zero value (thus, no entropy). The ingress of a tunnel seeking to provide good entropy in the flow label field would therefore need to create a random flow label value and keep corresponding state so that all packets that were associated with a flow would be consistently given the same flow label. Although possible, this complexity may not be desirable in a tunnel ingress.
ただし、現在のエンドポイントの多くは、フローラベルをゼロ値に設定しています（したがって、エントロピーはありません）。したがって、フローラベルフィールドに適切なエントロピーを提供しようとするトンネルの入口は、ランダムなフローラベル値を作成し、対応する状態を維持して、フローに関連付けられたすべてのパケットに一貫して同じフローラベルが与えられるようにする必要があります。この複雑さは可能ですが、トンネルの入口では望ましくない場合があります。
The end-to-end use of flow labels for load balancing is a long-term solution. Even if the usage of the flow label has been clarified, there will be a transition time before a significant proportion of endpoints start to assign a good quality flow label to the flows that they originate. The use of load balancing using the transport header fields would continue until any widespread deployment is finally achieved.
ロードバランシングにフローラベルをエンドツーエンドで使用することは、長期的なソリューションです。フローラベルの使用法が明確になっている場合でも、エンドポイントのかなりの割合が、元のフローに高品質のフローラベルを割り当て始めるまでの移行時間があります。トランスポートヘッダーフィールドを使用したロードバランシングの使用は、広範な展開が最終的に達成されるまで続きます。
The IETF has defined a set of transport protocols that may be applicable for tunnels with IPv6. There is also a set of network-layer encapsulation tunnels, such as IP-in-IP and Generic Routing Encapsulation (GRE). These solutions, which are already standardized, are discussed first, before discussing the issues, because they provide background for the description of the issues and allow some comparison with existing issues.
IETFは、IPv6のトンネルに適用できる一連のトランスポートプロトコルを定義しています。また、IP-in-IPやGeneric Routing Encapsulation（GRE）などの一連のネットワーク層カプセル化トンネルもあります。これらのソリューションは、すでに標準化されているため、問題を説明する前に最初に説明します。問題を説明するための背景を提供し、既存の問題との比較を可能にするためです。
UDP [RFC0768] with standard checksum behavior, as defined in RFC 2460, has already been discussed. UDP usage guidelines are provided in [RFC5405].
RFC 2460で定義されているように、標準のチェックサム動作を備えたUDP [RFC0768]についてはすでに説明しました。 UDPの使用ガイドラインは[RFC5405]で提供されています。
UDP-Lite [RFC3828] offers an alternate transport to UDP and is specified as a proposed standard, RFC 3828. A MIB is defined in [RFC5097], and unicast usage guidelines are defined in [RFC5405]. There has been at least one open-source implementation of UDP-Lite as a part of the Linux kernel since version 2.6.20.
UDP-Lite [RFC3828]はUDPへの代替トランスポートを提供し、提案された標準RFC 3828として指定されています。MIBは[RFC5097]で定義されており、ユニキャスト使用ガイドラインは[RFC5405]で定義されています。バージョン2.6.20以降、Linuxカーネルの一部としてUDP-Liteのオープンソース実装が少なくとも1つあります。
UDP-Lite provides a checksum with an option for partial coverage. When using this option, a datagram is divided into a sensitive part (covered by the checksum) and an insensitive part (not covered by the checksum). When the checksum covers the entire packet, UDP-Lite is fully equivalent with UDP, with the exception that it uses a different value in the Next Header field in the IPv6 header. Errors or corruption in the insensitive part will not cause the datagram to be discarded by the transport layer at the receiving endpoint. A minor side effect of using UDP-Lite is that it was specified for damage-tolerant payloads, and some link layers may employ different link encapsulations when forwarding UDP-Lite segments (e.g., radio access bearers). Most link layers will cover the insensitive part with the same strong Layer 2 frame Cyclic Redundancy Check (CRC) that covers the sensitive part.
UDP-Liteは、部分的なカバレッジのオプションを備えたチェックサムを提供します。このオプションを使用すると、データグラムは（チェックサムの対象となる）機密部分と（チェックサムの対象外となる）非機密部分に分けられます。チェックサムがパケット全体をカバーする場合、UDP-LiteはUDPと完全に同等ですが、IPv6ヘッダーの次のヘッダーフィールドで異なる値を使用する点が異なります。影響を受けない部分のエラーまたは破損によって、データグラムが受信エンドポイントのトランスポート層によって破棄されることはありません。 UDP-Liteを使用することのマイナーな副作用は、それが損傷耐性のあるペイロードに対して指定されたことであり、一部のリンク層はUDP-Liteセグメント（たとえば、無線アクセスベアラー）を転送するときに異なるリンクカプセル化を使用する場合があります。ほとんどのリンク層は、敏感な部分をカバーするのと同じ強力なレイヤー2フレームの巡回冗長検査（CRC）で、敏感でない部分をカバーします。
Tunnel encapsulations, such as Control And Provisioning of Wireless Access Points (CAPWAP) [RFC5415], can use UDP-Lite, because it provides a transport-layer checksum, including an IP pseudo-header checksum, in IPv6, without the need for a router/middlebox to traverse the entire packet payload. This provides most of the verification required for delivery and still keeps a low complexity for the checksumming operation. UDP-Lite may set the length of checksum coverage on a per-packet basis. This feature could be used if a tunnel protocol is designed to verify only delivery of the tunneled payload and uses a calculated checksum for control information.
ワイヤレスアクセスポイントの制御とプロビジョニング（CAPWAP）[RFC5415]などのトンネルカプセル化では、UDP-Liteを使用できます。これは、IPv6でトランスポート層のチェックサム（IP疑似ヘッダーチェックサムを含む）を提供するためです。ルーター/ミドルボックスを使用して、パケットペイロード全体をトラバースします。これにより、配信に必要な検証のほとんどが提供され、チェックサム演算の複雑さが低く抑えられます。 UDP-Liteは、チェックサムカバレッジの長さをパケットごとに設定できます。この機能は、トンネルプロトコルがトンネリングされたペイロードの配信のみを検証するように設計されており、計算されたチェックサムを制御情報に使用する場合に使用できます。
Currently, support for middlebox traversal using UDP-Lite is poor, because UDP-Lite uses a different IPv6 network-layer Next Header value than that used for UDP; therefore, few middleboxes are able to interpret UDP-Lite and take appropriate actions when forwarding the packet. This makes UDP-Lite less suited to protocols needing general Internet support, until such time as UDP-Lite has achieved better support in middleboxes and endpoints.
UDP-LiteはUDPに使用されるものとは異なるIPv6ネットワーク層の次のヘッダー値を使用するため、現在、UDP-Liteを使用したミドルボックストラバーサルのサポートは不十分です。したがって、UDP-Liteを解釈してパケットを転送するときに適切なアクションを実行できるミドルボックスはほとんどありません。これにより、UDP-Liteがミドルボックスとエンドポイントでより良いサポートを実現するまで、UDP-Liteは一般的なインターネットサポートを必要とするプロトコルにはあまり適していません。
The IETF has defined a set of tunneling protocols or network-layer encapsulations, e.g., IP-in-IP and GRE. These either do not include a checksum or use a checksum that is optional, because tunnel encapsulations are typically layered directly over the Internet layer (identified by the upper layer type in the IPv6 Next Header field) and because they are not used as endpoint transport protocols. There is little chance of confusing a tunnel-encapsulated packet with other application data. Such confusion could result in corruption of application state or data.
IETFは、IP-in-IPやGREなどの一連のトンネリングプロトコルまたはネットワーク層カプセル化を定義しています。これらはチェックサムを含まないか、オプションのチェックサムを使用します。これは、トンネルカプセル化は通常、インターネットレイヤー（IPv6次ヘッダーフィールドの上位レイヤータイプで識別される）の上に直接階層化され、エンドポイントトランスポートプロトコルとして使用されないためです。 。トンネルカプセル化パケットを他のアプリケーションデータと混同する可能性はほとんどありません。このような混乱により、アプリケーションの状態やデータが破損する可能性があります。
From an end-to-end perspective, the principal difference between an endpoint transport and a tunnel encapsulation is the value of the network-layer Next Header field. In the former, it identifies a transport protocol that supports endpoint applications. In the latter, it identifies a tunnel protocol egress. This separation of function reduces the probability that corruption of a tunneled packet could result in the packet being erroneously delivered to an application. Specifically, packets are delivered only to protocol modules that process a specific Next Header value. The Next Header field therefore provides a first-level check of correct demultiplexing. In contrast, the UDP port space is shared by many diverse applications, and therefore, UDP demultiplexing relies solely on the port numbers.
エンドツーエンドの観点から見ると、エンドポイントトランスポートとトンネルカプセル化の主な違いは、ネットワーク層の次のヘッダーフィールドの値です。前者では、エンドポイントアプリケーションをサポートするトランスポートプロトコルを識別します。後者では、トンネルプロトコル出力を識別します。この機能の分離により、トンネリングされたパケットの破損により、パケットが誤ってアプリケーションに配信される可能性が低くなります。具体的には、パケットは特定の次のヘッダー値を処理するプロトコルモジュールにのみ配信されます。したがって、次のヘッダーフィールドは、正しい逆多重化の第1レベルのチェックを提供します。対照的に、UDPポートスペースは多くの多様なアプリケーションによって共有されるため、UDP逆多重化はポート番号のみに依存します。
2.4. Relationship of Zero UDP Checksum to UDP-Lite and UDP with Checksum
2.4. ゼロUDPチェックサムとUDP-Liteおよびチェックサム付きUDPの関係
The operation of IPv6 with UDP with a zero checksum is not the same as IPv4 with UDP with a zero checksum. Protocol designers should not be fooled into thinking that the two are the same. The requirements below list a set of additional considerations for IPv6.
チェックサムがゼロのUDPを使用するIPv6の操作は、チェックサムがゼロのUDPを使用するIPv4と同じではありません。プロトコル設計者は、2つが同じであると誤解してはいけません。以下の要件は、IPv6に関する追加の考慮事項の一覧です。
Where possible, existing general tunnel encapsulations, such as GRE and IP-in-IP, should be used. This section assumes that such existing tunnel encapsulations do not offer the functionally required to satisfy the protocol designer's goals. This section considers the standardized alternative solutions rather than the full set of ideas evaluated in Appendix A. The alternatives to UDP with a zero checksum are UDP with a (calculated) checksum and UDP-Lite.
可能であれば、GREやIP-in-IPなどの既存の一般的なトンネルカプセル化を使用する必要があります。このセクションでは、このような既存のトンネルカプセル化は、プロトコル設計者の目標を満たすために機能的に必要な機能を提供しないことを前提としています。このセクションでは、付録Aで評価されたアイデアの完全なセットではなく、標準化された代替ソリューションを検討します。チェックサムがゼロのUDPの代替案は、（計算された）チェックサムのUDPとUDP-Liteです。
UDP with a checksum has the advantage of close to universal support in both endpoints and middleboxes. It also provides statistical verification of delivery to the intended destination (address and port). However, some classes of device have limited support for calculation of a checksum that covers a full datagram. For these devices, this limited support can incur significant processing costs (e.g., requiring processing in the router's slow path) and hence can reduce capacity or fail to function.
チェックサム付きのUDPには、エンドポイントとミドルボックスの両方でユニバーサルサポートに近いという利点があります。また、目的の宛先（アドレスとポート）への配信の統計的検証も提供します。ただし、デバイスのクラスによっては、完全なデータグラムを対象とするチェックサムの計算のサポートが制限されています。これらのデバイスの場合、この制限されたサポートにより、かなりの処理コスト（ルーターの低速パスでの処理が必要になるなど）が発生する可能性があるため、容量が減少したり、機能しなくなる可能性があります。
UDP-Lite has the advantage of using a checksum that can be calculated only over the pseudo-header and the UDP header. This provides a statistical verification of delivery to the intended destination (address and port). The checksum can be calculated without access to the datagram payload, requiring access only to the part that is to be protected. A drawback is that UDP-Lite currently has limited support in both endpoints (i.e., is not supported on all operating system platforms) and middleboxes (which must support the UDP-Lite header type). Therefore, using a path verification method is recommended.
UDP-Liteには、疑似ヘッダーとUDPヘッダーに対してのみ計算できるチェックサムを使用するという利点があります。これにより、目的の宛先（アドレスとポート）への配信を統計的に検証できます。チェックサムは、データグラムのペイロードにアクセスせずに計算できるため、保護する必要のある部分にのみアクセスする必要があります。欠点は、UDP-Liteは現在、エンドポイント（つまり、すべてのオペレーティングシステムプラットフォームでサポートされているわけではない）とミドルボックス（UDP-Liteヘッダータイプをサポートする必要がある）の両方でサポートが制限されていることです。したがって、パス検証方法を使用することをお勧めします。
IPv6 and UDP with a zero checksum can also be used by nodes that do not permit calculation of a payload checksum. Many existing classes of middleboxes do not verify or change the transport checksum. For these middleboxes, IPv6 with a zero UDP checksum is expected to function where UDP-Lite would not. However, support for the zero UDP checksum in middleboxes that do change or verify the checksum is currently limited, and this may result in datagrams with a zero UDP checksum being discarded. Therefore, using a path verification method is recommended.
チェックサムがゼロのIPv6およびUDPは、ペイロードチェックサムの計算を許可しないノードでも使用できます。ミドルボックスの既存のクラスの多くは、トランスポートチェックサムを検証または変更しません。これらのミドルボックスの場合、UDPチェックサムがゼロのIPv6は、UDP-Liteが機能しない場所で機能すると予想されます。ただし、チェックサムを変更または検証するミドルボックスでのゼロUDPチェックサムのサポートは現在制限されており、ゼロUDPチェックサムのデータグラムが破棄される可能性があります。したがって、パス検証方法を使用することをお勧めします。
For some sets of constraints, no solution exists. For example, a protocol designer who needs to originate or receive datagrams on a device that cannot efficiently calculate a checksum over a full datagram and also needs these packets to pass through a middlebox that verifies or changes a UDP checksum, but that does not support a zero UDP checksum, cannot use the zero UDP checksum method. Similarly, a protocol designer who needs to originate datagrams on a device with UDP-Lite support, but needs the packets to pass through a middlebox that does not support UDP-Lite, cannot use UDP-Lite. For such cases, there is no optimal solution. The current recommendation is to use or fall back to using UDP with full checksum coverage.
制約のセットによっては、解決策が存在しません。たとえば、完全なデータグラムに対してチェックサムを効率的に計算できないデバイスでデータグラムを発信または受信する必要があり、UDPチェックサムを検証または変更するミドルボックスを通過する必要があるが、サポートしていないプロトコルデザイナーゼロUDPチェックサム。ゼロUDPチェックサム方式は使用できません。同様に、UDP-Liteをサポートするデバイスでデータグラムを発信する必要があるが、UDP-Liteをサポートしないミドルボックスを通過するパケットを必要とするプロトコル設計者は、UDP-Liteを使用できません。このような場合、最適なソリューションはありません。現在の推奨事項は、UDPを使用するか、フルチェックサムカバレッジでUDPを使用することです。
This informative section evaluates issues about the proposal to update IPv6 [RFC2460] to enable the UDP transport checksum to be set to zero. Some of the identified issues are common to other protocols already in use. This section also provides background to help in understanding the requirements and recommendations that follow.
この有益なセクションでは、IPv6 [RFC2460]を更新してUDPトランスポートチェックサムをゼロに設定できるようにする提案に関する問題を評価します。特定された問題のいくつかは、すでに使用されている他のプロトコルに共通しています。このセクションでは、以下の要件と推奨事項を理解するのに役立つ背景情報も提供します。
The decision in RFC 2460 to omit an integrity check at the network level meant that the IPv6 transport checksum was overloaded with many functions, including validating:
ネットワークレベルでの整合性チェックを省略するというRFC 2460の決定は、IPv6トランスポートチェックサムが検証を含む多くの機能で過負荷になっていることを意味しました：
o That the endpoint address was not corrupted within a router, i.e., a packet was intended to be received by this destination, and that the packet does not consist of a wrong header spliced to a different payload.
o エンドポイントアドレスがルーター内で破損していないこと、つまり、パケットがこの宛先によって受信されることを意図していたこと、およびパケットが、異なるペイロードにスプライスされた誤ったヘッダーで構成されていないこと。
o That extension header processing is correctly delimited, i.e., the start of data has not been corrupted. In this case, reception of a valid Next Header value provides some protection.
o その拡張ヘッダー処理は正しく区切られています。つまり、データの先頭は破損していません。この場合、有効な次のヘッダー値を受信すると、ある程度の保護が提供されます。
o Reassembly processing, when used.
o 使用時の再組立加工。
o The length of the payload.
o ペイロードの長さ。
o The port values, i.e., the correct application receives the payload. (Applications should also check the expected use of source ports/addresses.)
o ポート値、つまり正しいアプリケーションがペイロードを受信します。 （アプリケーションは、送信元ポート/アドレスの予想される使用も確認する必要があります。）
o The payload integrity.
o ペイロードの整合性。
In IPv4, the first four of these checks are performed using the IPv4 header checksum.
IPv4では、これらのチェックの最初の4つは、IPv4ヘッダーチェックサムを使用して実行されます。
In IPv6, these checks occur within the endpoint stack using the UDP checksum information. An IPv6 node also relies on the header information to determine whether to send an ICMPv6 error message [RFC4443] and to determine the node to which this is sent. Corrupted information may lead to misdelivery to an unintended application socket on an unexpected host.
IPv6では、これらのチェックはUDPチェックサム情報を使用してエンドポイントスタック内で行われます。また、IPv6ノードはヘッダー情報に基づいて、ICMPv6エラーメッセージ[RFC4443]を送信するかどうかを決定し、これが送信されるノードを決定します。情報が破損すると、予期しないホストの意図しないアプリケーションソケットに誤って配信される可能性があります。
IP packets may be corrupted as they traverse an Internet path. Older evidence presented in "When the CRC and TCP Checksum Disagree" [Sigcomm2000] shows that this was an issue with IPv4 routers in the year 2000 and that occasional corruption could result from bad internal router processing in routers or hosts. These errors are not detected by the strong frame checksums employed at the link layer [RFC3819]. During the development of this document in 2009, a number of individuals provided reports of observed rates for received UDP datagrams using IPv4 where the UDP checksum had been detected as corrupt. These rates were as high as 1.39E-4 for some paths, but close to zero for other paths.
IPパケットは、インターネットパスを通過するときに破損する可能性があります。 「CRCとTCPチェックサムが一致しない場合」[Sigcomm2000]で提示された古い証拠は、これが2000年のIPv4ルーターの問題であり、ルーターまたはホストの内部ルーター処理が不適切なために破損が発生する可能性があることを示しています。これらのエラーは、リンク層[RFC3819]で採用されている強力なフレームチェックサムでは検出されません。 2009年のこのドキュメントの作成中に、UDPチェックサムが破損していると検出されたIPv4を使用して受信したUDPデータグラムの観測されたレートのレポートを多数の個人が提供しました。これらのレートは、一部のパスでは1.39E-4と高かったが、他のパスではゼロに近い。
There is extensive experience with deployments using tunnel protocols in well-managed networks (e.g., corporate networks and service provider core networks). This has shown the robustness of methods such as Pseudowire Emulation Edge-to-Edge (PWE3) and MPLS that do not employ a transport protocol checksum and that have not specified mechanisms to protect from corruption of the unprotected headers (such as the VPN Identifier in MPLS). Reasons for the robustness may include:
適切に管理されたネットワーク（企業ネットワークやサービスプロバイダーのコアネットワークなど）でトンネルプロトコルを使用した展開には、豊富な経験があります。これは、トランスポートプロトコルチェックサムを使用せず、保護されていないヘッダー（VPN IDなどの）の破損から保護するメカニズムを指定していない、疑似配線エミュレーションエッジツーエッジ（PWE3）やMPLSなどのメソッドの堅牢性を示しています。 MPLS）。堅牢性の理由には、以下が含まれます。
o A reduced probability of corruption on paths through well-managed networks.
o 適切に管理されたネットワークを経由するパスの破損の可能性が減少します。
o IP forms the majority of the inner traffic carried by these tunnels. Hence, from a transport perspective, endpoint verification is already being performed when a received IPv4 packet is processed or by the transport pseudo-header for an IPv6 packet. This update to UDP does not change this behavior.
o IPは、これらのトンネルによって伝送される内部トラフィックの大部分を形成します。したがって、トランスポートの観点からは、受信したIPv4パケットが処理されるとき、またはIPv6パケットのトランスポート疑似ヘッダーによって、エンドポイント検証がすでに実行されています。 UDPへのこの更新では、この動作は変更されません。
o In certain cases, a combination of additional filtering (e.g., filtering a MAC destination address in a Layer 2 tunnel) significantly reduces the probability of final misdelivery to the IP stack.
o 特定のケースでは、追加のフィルタリング（レイヤー2トンネルでのMAC宛先アドレスのフィルタリングなど）の組み合わせにより、IPスタックへの最終的な誤配信の確率が大幅に減少します。
o The tunnel protocols did not use a UDP transport header. Therefore, any corruption is unlikely to result in misdelivery to another UDP-based application. This concern is specific to UDP with IPv6.
o トンネルプロトコルは、UDPトランスポートヘッダーを使用しませんでした。したがって、破損が原因で別のUDPベースのアプリケーションへの配信が失敗することはほとんどありません。この問題は、IPv6を使用するUDPに固有です。
While this experience can guide the present recommendations, any update to UDP must preserve operation in the general Internet, which is heterogeneous and can include links and systems of widely varying characteristics. Transport protocols used by hosts need to be designed with this in mind, especially when there is need to traverse edge networks, where middlebox deployments are common.
この経験は現在の推奨事項を導くことができますが、UDPへの更新は一般的なインターネットでの動作を維持する必要があります。これは異種であり、さまざまな特性のリンクやシステムを含む可能性があります。ホストが使用するトランスポートプロトコルは、特にミドルボックスの展開が一般的なエッジネットワークを通過する必要がある場合、このことを考慮して設計する必要があります。
Currently, for the general Internet, there is no evidence that corruption is rare, nor is there evidence that corruption in IPv6 is rare. Therefore, it seems prudent not to relax checks on misdelivery. The emergence of low-end IPv6 routers and the proposed use of NAT with IPv6 provide further motivation to protect from misdelivery.
現在、一般的なインターネットでは、破損がまれであるという証拠はなく、IPv6の破損がまれであるという証拠もありません。したがって、誤配のチェックを緩和しないことが賢明なようです。ローエンドIPv6ルーターの出現とIPv6でのNATの提案された使用は、誤配信から保護するさらなる動機を提供します。
Corruption in the network may result in:
ネットワークの破損は、次の原因となる可能性があります。
o A datagram being misdelivered to the wrong host/router or the wrong transport entity within an endpoint. Such a datagram needs to be discarded.
o エンドポイント内の誤ったホスト/ルーターまたは誤ったトランスポートエンティティに誤って配信されているデータグラム。このようなデータグラムは破棄する必要があります。
o A datagram payload being corrupted, but still delivered to the intended host/router transport entity. Such a datagram needs to be either discarded or correctly processed by an application that provides its own integrity checks.
o データグラムペイロードが破損していますが、意図したホスト/ルータートランスポートエンティティに配信されています。このようなデータグラムは、破棄するか、独自の整合性チェックを提供するアプリケーションで正しく処理する必要があります。
o A datagram payload being truncated by corruption of the length field. Such a datagram needs to be discarded.
o 長さフィールドの破損によって切り捨てられるデータグラムペイロード。このようなデータグラムは破棄する必要があります。
Using a checksum significantly reduces the impact of errors, reducing the probability of undetected corruption of state (and data) on both the host stack and the applications using the transport service.
チェックサムを使用すると、エラーの影響が大幅に減少し、トランスポートサービスを使用するホストスタックとアプリケーションの両方で、検出されない状態（およびデータ）の破損の可能性が減少します。
The following sections examine the effect of modifications to the destination and source IP address fields, the port fields, and the fragmentation information.
次のセクションでは、宛先と送信元のIPアドレスフィールド、ポートフィールド、およびフラグメンテーション情報への変更の影響を調べます。
An IPv6 endpoint destination address could be modified in the network; for example, it could be corrupted by an error. This is not a concern for IPv4, because the IP header checksum will result in this packet being discarded by the receiving IP stack. When using IPv6, however, such modification in the network cannot be detected at the network layer. Detection of this corruption by a UDP receiver relies on the IPv6 pseudo-header that is incorporated in the transport checksum.
IPv6エンドポイントの宛先アドレスはネットワークで変更できます。たとえば、エラーによって破損している可能性があります。 IPヘッダーのチェックサムにより、このパケットは受信IPスタックによって破棄されるため、これはIPv4の問題ではありません。ただし、IPv6を使用する場合、ネットワークでのこのような変更は、ネットワーク層で検出できません。 UDPレシーバーによるこの破損の検出は、トランスポートチェックサムに組み込まれているIPv6疑似ヘッダーに依存しています。
There are two possible outcomes:
次の2つの結果が考えられます。
o Delivery to a destination address that is not in use. The packet will not be delivered, but an error report could be generated.
o 使用されていない宛先アドレスへの配信。パケットは配信されませんが、エラーレポートが生成される可能性があります。
o Delivery to a different destination address. This modification will normally be detected by the transport checksum, resulting in a silent discard. Without a computed checksum, the packet would be passed to the endpoint port demultiplexing function. If an application is bound to the associated ports, the packet payload will be passed to the application. (See Section 3.1.4 on port processing.)
o 別の宛先アドレスへの配信。この変更は通常、トランスポートチェックサムによって検出されるため、サイレント破棄が行われます。計算されたチェックサムがない場合、パケットはエンドポイントポートの逆多重化機能に渡されます。アプリケーションが関連するポートにバインドされている場合、パケットペイロードはアプリケーションに渡されます。 （ポート処理についてはセクション3.1.4を参照してください。）
This section examines what happens when the source IP address is corrupted in transit. This is not a concern in IPv4, because the IP header checksum will normally result in this packet being discarded by the receiving IP stack. Detection of this corruption by a UDP receiver relies on the IPv6 pseudo-header that is incorporated in the transport checksum.
このセクションでは、送信中に送信元IPアドレスが破損した場合に何が起こるかを調べます。これはIPv4では問題ではありません。これは、IPヘッダーのチェックサムにより、通常、このパケットが受信IPスタックによって破棄されるためです。 UDPレシーバーによるこの破損の検出は、トランスポートチェックサムに組み込まれているIPv6疑似ヘッダーに依存しています。
Corruption of an IPv6 source address does not result in the IP packet being delivered to a different endpoint protocol or destination address. If only the source address is corrupted, the datagram will likely be processed in the intended context, although with erroneous origin information. When using unicast reverse path forwarding [RFC2827], a change in address may result in the router discarding the packet when the route to the modified source address is different from that of the source address of the original packet.
IPv6送信元アドレスが破損しても、IPパケットが別のエンドポイントプロトコルまたは宛先アドレスに配信されることはありません。送信元アドレスだけが破損している場合、データグラムは意図したコンテキストで処理される可能性がありますが、発信元情報は誤っています。ユニキャストリバースパス転送[RFC2827]を使用している場合、変更された送信元アドレスへのルートが元のパケットの送信元アドレスと異なる場合、アドレスを変更すると、ルーターがパケットを破棄する可能性があります。
The result will depend on the application or protocol that processes the packet. Some examples are:
結果は、パケットを処理するアプリケーションまたはプロトコルによって異なります。次に例を示します。
o An application that requires a pre-established context may disregard the datagram as invalid or could map it to another context (if a context for the modified source address were already activated).
o 事前に確立されたコンテキストを必要とするアプリケーションは、データグラムを無効として無視したり、別のコンテキストにマップしたりする可能性があります（変更されたソースアドレスのコンテキストがすでにアクティブ化されている場合）。
o A stateless application will process the datagram outside of any context. A simple example is the ECHO server, which will respond with a datagram directed to the modified source address. This would create unwanted additional processing load and generate traffic to the modified endpoint address.
o ステートレスアプリケーションは、データグラムをコンテキスト外で処理します。簡単な例はECHOサーバーで、変更された送信元アドレスに送信されたデータグラムで応答します。これにより、不要な追加の処理負荷が発生し、変更されたエンドポイントアドレスへのトラフィックが生成されます。
o Some datagram applications build state using the information from packet headers. A previously unused source address would result in receiver processing and the creation of unnecessary transport-layer state at the receiver. For example, Real-time Protocol (RTP) [RFC3550] sessions commonly employ a source-independent receiver port. State is created for each received flow. Therefore, reception of a datagram with a corrupted source address will result in the accumulation of unnecessary state in the RTP state machine, including collision detection and response (since the same synchronization source (SSRC) value will appear to arrive from multiple source IP addresses).
o 一部のデータグラムアプリケーションは、パケットヘッダーからの情報を使用して状態を構築します。以前に未使用の送信元アドレスは、受信側での処理と、受信側での不必要なトランスポート層状態の作成をもたらします。たとえば、リアルタイムプロトコル（RTP）[RFC3550]セッションでは、通常、ソースに依存しないレシーバーポートが使用されます。受信したフローごとに状態が作成されます。したがって、破損したソースアドレスを持つデータグラムを受信すると、衝突検出と応答を含む、RTPステートマシンに不要な状態が蓄積されます（同じ同期ソース（SSRC）値が複数のソースIPアドレスから到着したように見えるため） 。
o ICMP messages relating to a corrupted packet can be misdirected to the wrong source node.
o 破損したパケットに関連するICMPメッセージは、間違った送信元ノードに誤って送信される可能性があります。
In general, the effect of corrupting the source address will depend upon the protocol that processes the packet and its robustness to this error. For the case where the packet is received by a tunnel endpoint, the tunnel application is expected to correctly handle a corrupted source address.
一般に、送信元アドレスの破損の影響は、パケットを処理するプロトコルと、このエラーに対する堅牢性に依存します。パケットがトンネルエンドポイントで受信される場合、トンネルアプリケーションは破損した送信元アドレスを正しく処理することが期待されています。
The impact of source address modification is more difficult to quantify when the receiving application is not the one originally intended and several fields have been modified in transit.
受信側アプリケーションが当初意図したものではなく、いくつかのフィールドが転送中に変更されている場合、ソースアドレス変更の影響を定量化することはより困難です。
This section describes what happens if one or both of the UDP port values are corrupted in transit. This can also happen when IPv4 is used with a zero UDP checksum, but not when UDP checksums are calculated or when UDP-Lite is used. If the ports carried in the transport header of an IPv6 packet are corrupted in transit, packets may be delivered to the wrong application process (on the intended machine), responses or errors may be sent to the wrong application process (on the intended machine), or both may occur.
このセクションでは、UDPポート値の一方または両方が転送中に破損した場合にどうなるかについて説明します。これは、UDPチェックサムがゼロのIPv4が使用されている場合にも発生する可能性がありますが、UDPチェックサムが計算されている場合やUDP-Liteが使用されている場合には発生しません。 IPv6パケットのトランスポートヘッダーに含まれるポートが転送中に破損した場合、パケットが間違ったアプリケーションプロセス（目的のマシン上）に配信されたり、応答またはエラーが間違ったアプリケーションプロセス（目的のマシン上）に送信されたりすることがあります。 、またはその両方が発生する可能性があります。
If one combines the corruption effects, such as a corrupted destination address and corrupted ports, there are a number of potential outcomes when traffic arrives at an unexpected port. The following are the possibilities and their outcomes for a packet that does not use UDP checksum validation:
宛先アドレスの破損やポートの破損などの破損の影響を組み合わせると、トラフィックが予期しないポートに到着したときに、いくつかの潜在的な結果が生じます。以下は、UDPチェックサム検証を使用しないパケットの可能性とその結果です。
o The packet could be delivered to a port that is not in use. The packet is discarded, but could generate an ICMPv6 message (e.g., port unreachable).
o パケットは、使用されていないポートに配信される可能性があります。パケットは破棄されますが、ICMPv6メッセージ（ポートに到達できないなど）が生成される可能性があります。
o The packet could be delivered to a different node that implements the same application, so the packet may be accepted, but side effects could occur or accumulated state could be generated.
o パケットは、同じアプリケーションを実装する別のノードに配信される可能性があるため、パケットは受け入れられますが、副作用が発生したり、累積状態が生成されたりする可能性があります。
o The packet could be delivered to an application that does not implement the tunnel protocol, so the packet may be incorrectly parsed and may be misinterpreted, causing side effects or generating accumulated state.
o パケットは、トンネルプロトコルを実装していないアプリケーションに配信される可能性があるため、パケットが正しく解析されず、誤って解釈され、副作用が発生したり、状態が蓄積されたりする可能性があります。
The probability of each outcome depends on the statistical probability that the address or the port information for the source or destination becomes corrupted in the datagram such that they match those of an existing flow or server port. Unfortunately, such a match may be more likely for UDP than for connection-oriented transports, because:
各結果の確率は、送信元または宛先のアドレスまたはポート情報が既存のフローまたはサーバーポートのそれらと一致するようにデータグラムで破損する統計的確率に依存します。残念ながら、そのような一致は、コネクション型のトランスポートよりもUDPの可能性が高くなります。
1. There is no handshake prior to communication and no sequence numbers (as in TCP, Datagram Congestion Control Protocol (DCCP), and Stream Control Transmission Protocol (SCTP)). This makes it hard to verify that an application process is given only the application data associated with a specific transport session.
1. 通信前のハンドシェイクやシーケンス番号はありません（TCP、データグラム輻輳制御プロトコル（DCCP）、ストリーム制御伝送プロトコル（SCTP）など）。これにより、アプリケーションプロセスに特定のトランスポートセッションに関連付けられたアプリケーションデータのみが与えられていることを確認することが困難になります。
2. Applications writers often bind to wildcard values in endpoint identifiers and do not always validate the correctness of datagrams they receive. (Guidance on this topic is provided in [RFC5405].)
2. 多くの場合、アプリケーションの作成者はエンドポイント識別子のワイルドカード値にバインドし、受け取ったデータグラムの正確さを常に検証するわけではありません。 （このトピックに関するガイダンスは[RFC5405]で提供されています。）
While these rules could, in principle, be revised to declare naive applications as "historic", this remedy is not realistic. The transport owes it to the stack to do its best to reject bogus datagrams.
これらのルールは、原則として、ナイーブアプリケーションを「歴史的」として宣言するように改訂できますが、この救済策は現実的ではありません。トランスポートは、不正なデータグラムを拒否するために最善を尽くすために、スタックを借りています。
If checksum coverage is suppressed, the application needs to provide a method to detect and discard the unwanted data. A tunnel protocol would need to perform its own integrity checks on any control information if it is transported in datagrams with a zero UDP checksum. If the tunnel payload is another IP packet, the packets requiring checksums can be assumed to have their own checksums, provided that the rate of corrupted packets is not significantly larger due to the tunnel encapsulation. If a tunnel transports other inner payloads that do not use IP, the assumptions of corruption detection for that particular protocol must be fulfilled. This may require an additional checksum/CRC and/or integrity protection of the payload and tunnel headers.
チェックサムカバレッジが抑制されている場合、アプリケーションは、不要なデータを検出して破棄する方法を提供する必要があります。トンネルプロトコルは、UDPチェックサムがゼロのデータグラムで転送される場合、制御情報に対して独自の整合性チェックを実行する必要があります。トンネルペイロードが別のIPパケットである場合、トンネルカプセル化により破損したパケットのレートがそれほど大きくない場合、チェックサムを必要とするパケットは独自のチェックサムを持っていると想定できます。トンネルがIPを使用しない他の内部ペイロードを転送する場合、その特定のプロトコルの破損検出の前提を満たす必要があります。これには、ペイロードおよびトンネルヘッダーの追加のチェックサム/ CRCおよび/または完全性保護が必要になる場合があります。
A protocol that uses a zero UDP checksum cannot assume that it is the only protocol using a zero UDP checksum. Therefore, it needs to handle misdelivery gracefully. It must be robust when malformed packets are received on a listening port, and it must expect that these packets may contain corrupted data or data associated with a completely different protocol.
ゼロUDPチェックサムを使用するプロトコルは、それがゼロUDPチェックサムを使用する唯一のプロトコルであるとは想定できません。したがって、配信ミスを適切に処理する必要があります。不正な形式のパケットがリスニングポートで受信された場合は堅牢である必要があり、これらのパケットに破損したデータや完全に異なるプロトコルに関連付けられたデータが含まれる可能性があることを期待する必要があります。
The fragmentation information in IPv6 employs a 32-bit identity field (compared to only a 16-bit field in IPv4), a 13-bit fragment offset, and a 1-bit flag indicating whether there are more fragments. Corruption of any of these fields may result in one of two outcomes:
IPv6の断片化情報は、32ビットのIDフィールド（IPv4の16ビットフィールドのみと比較）、13ビットのフラグメントオフセット、およびフラグメントがさらにあるかどうかを示す1ビットのフラグを採用しています。これらのフィールドのいずれかが破損すると、次の2つの結果のいずれかになる可能性があります。
o Reassembly failure: An error in the "More Fragments" field for the last fragment will, for example, result in the packet never being considered complete, so it will eventually be timed out and discarded. A corruption in the ID field will result in the fragment not being delivered to the intended context, thus leaving the rest of the packet incomplete, unless that packet has been duplicated before the corruption. The incomplete packet will eventually be timed out and discarded.
o 再構成の失敗：たとえば、最後のフラグメントの[More Fragments]フィールドにエラーがあると、パケットは完全とは見なされないため、最終的にはタイムアウトして破棄されます。 IDフィールドが破損すると、フラグメントが意図したコンテキストに配信されず、パケットが破損する前に複製されていなければ、残りのパケットは不完全なままになります。不完全なパケットは、最終的にタイムアウトして廃棄されます。
o Erroneous reassembly: The reassembled packet did not match the original packet. This can occur when the ID field of a fragment is corrupted, resulting in a fragment becoming associated with another packet and taking the place of another fragment. Corruption in the offset information can cause the fragment to be misaligned in the reassembly buffer, resulting in incorrect reassembly. Corruption can cause the packet to become shorter or longer; however, completing the reassembly is much less probable, because this would require consistent corruption of the IPv6 header's payload length and offset fields. To prevent erroneous assembly, the reassembling stack must provide strong checks that detect overlap and missing data. Note, however, that this is not guaranteed and has been clarified in "Handling of Overlapping IPv6 Fragments" [RFC5722].
o 誤った再構成：再構成されたパケットが元のパケットと一致しませんでした。これは、フラグメントのIDフィールドが破損している場合に発生し、その結果、フラグメントが別のパケットに関連付けられ、別のフラグメントの代わりをします。オフセット情報の破損により、フラグメントが再構成バッファーで誤って配置され、誤った再構成が発生する可能性があります。破損により、パケットが短くなったり長くなったりすることがあります。ただし、IPv6ヘッダーのペイロード長とオフセットフィールドの一貫した破損が必要になるため、再構成が完了する可能性ははるかに低くなります。誤った組み立てを防ぐために、再組み立てスタックは、重複や欠落データを検出する強力なチェックを提供する必要があります。ただし、これは保証されておらず、「重複するIPv6フラグメントの処理」[RFC5722]で明確になっていることに注意してください。
The erroneous reassembly of packets is a general concern, and such packets should be discarded instead of being passed to higher-layer processes. The primary detector of packet length changes is the IP payload length field, with a secondary check provided by the transport checksum. The Upper-Layer Packet length field included in the pseudo-header assists in verifying correct reassembly, because the Internet checksum has a low probability of detecting insertion of data or overlap errors (due to misplacement of data). The checksum is also incapable of detecting insertion or removal of data that is all-zero in a chunk that is a multiple of 16 bits.
パケットの誤った再構成は一般的な問題であり、そのようなパケットは上位層のプロセスに渡されるのではなく破棄されるべきです。パケット長の変化の主な検出項目はIPペイロード長フィールドであり、トランスポートチェックサムによって提供される2次チェックがあります。インターネットチェックサムはデータの挿入または重複エラー（データの配置ミスによる）を検出する可能性が低いため、疑似ヘッダーに含まれる上位層パケット長フィールドは、正しい再構成の検証に役立ちます。チェックサムは、16ビットの倍数であるチャンク内ですべてゼロのデータの挿入または削除を検出することもできません。
The most significant risk of corruption results following mis-association of a fragment with a different packet. This risk can be significant, because the size of fragments is often the same (e.g., fragments that form when the path MTU results in fragmentation of a larger packet, which is common when addition of a tunnel encapsulation header increases the size of a packet). Detection of this type of error requires a checksum or other integrity check of the headers and the payload. While such protection is desirable for tunnel encapsulations using IPv4, because the small fragmentation ID can easily result in wraparound [RFC4963], this is especially desirable for tunnels that perform flow aggregation [TUNNELS].
フラグメントと別のパケットの誤った関連付けにより、破損の最も重大なリスクが発生します。フラグメントのサイズが同じであることが多いため、このリスクは重大になる可能性があります（たとえば、パスMTUにより大きなパケットがフラグメント化されるときに形成されるフラグメント。これは、トンネルカプセル化ヘッダーの追加によりパケットのサイズが増加する場合に一般的です）。 。このタイプのエラーを検出するには、ヘッダーとペイロードのチェックサムまたはその他の整合性チェックが必要です。 IPv4を使用するトンネルカプセル化にはこのような保護が望ましいですが、小さな断片化IDは簡単にラップアラウンドを引き起こす可能性があるため[RFC4963]、これはフロー集約を実行するトンネル[TUNNELS]に特に望ましいです。
Tunnel fragmentation behavior matters. There can be outer or inner fragmentation tunnels in the Internet Architecture [TUNNELS]. If there is inner fragmentation by the tunnel, the outer headers will never be fragmented, and thus, a zero UDP checksum in the outer header will not affect the reassembly process. When a tunnel performs outer header fragmentation, the tunnel egress needs to perform reassembly of the outer fragments into an inner packet. The inner packet is either a complete packet or a fragment. If it is a fragment, the destination endpoint of the fragment will perform reassembly of the received fragments. The complete packet or the reassembled fragments will then be processed according to the packet Next Header field. The receiver may detect reassembly anomalies only when it uses a protocol with a checksum. The larger the number of reassembly processes to which a packet has been subjected, the greater the probability of an error. The following list describes some tunnel fragmentation behaviors:
トンネルのフラグメンテーション動作が重要です。インターネットアーキテクチャ[TUNNELS]には、外部または内部の断片化トンネルがあります。トンネルによる内部の断片化がある場合、外部ヘッダーは決して断片化されないため、外部ヘッダーのゼロUDPチェックサムは再構成プロセスに影響しません。トンネルが外部ヘッダーフラグメンテーションを実行するとき、トンネルの出口は外部フラグメントを内部パケットに再構成する必要があります。内部パケットは、完全なパケットまたはフラグメントです。フラグメントの場合、フラグメントの宛先エンドポイントは、受信したフラグメントの再構成を実行します。完全なパケットまたは再構成されたフラグメントは、パケットの次のヘッダーフィールドに従って処理されます。受信機は、チェックサム付きのプロトコルを使用する場合にのみ、再構成の異常を検出できます。パケットが受けた再構成プロセスの数が多いほど、エラーの可能性が高くなります。次のリストは、いくつかのトンネルフラグメンテーション動作について説明しています。
o An IP-in-IP tunnel that performs inner fragmentation has similar properties to a UDP tunnel with a zero UDP checksum that also performs inner fragmentation.
o 内部フラグメンテーションを実行するIP-in-IPトンネルは、UDPチェックサムがゼロであり、内部フラグメンテーションも実行するUDPトンネルと同様の特性を持っています。
o An IP-in-IP tunnel that performs outer fragmentation has similar properties to a UDP tunnel with a zero UDP checksum that performs outer fragmentation.
o 外部フラグメンテーションを実行するIP-in-IPトンネルには、外部フラグメンテーションを実行するUDPチェックサムがゼロのUDPトンネルと同様のプロパティがあります。
o A tunnel that performs outer fragmentation can result in a higher level of corruption due to both inner and outer fragmentation, enabling more chances for reassembly errors to occur.
o 外側の断片化を実行するトンネルは、内側と外側の両方の断片化が原因で、より高いレベルの破損を引き起こす可能性があり、再構成エラーが発生する可能性が高くなります。
o Recursive tunneling can result in fragmentation at more than one header level, even for fragmentation of the encapsulated packet, unless the fragmentation is performed on the innermost IP header.
o 再帰的トンネリングは、フラグメント化が最も内側のIPヘッダーで実行されない限り、カプセル化されたパケットのフラグメント化であっても、複数のヘッダーレベルでフラグメント化を引き起こす可能性があります。
o Unless there is verification at each reassembly, the probability of undetected errors will increase with the number of times fragmentation is recursively applied, making both IP-in-IP and UDP with zero UDP checksum vulnerable to undetected errors.
o 再構成のたびに検証が行われない限り、フラグメント化が再帰的に適用される回数に応じて、検出されないエラーの可能性が高くなり、IP-in-IPとUDPチェックサムがゼロのUDPの両方が検出されないエラーに対して脆弱になります。
In conclusion, fragmentation of datagrams with a zero UDP checksum does not worsen the performance compared to some other commonly used tunnel encapsulations. However, caution is needed for recursive tunneling that offers no additional verification at the different tunnel layers.
結論として、UDPチェックサムがゼロのデータグラムの断片化は、他のいくつかの一般的に使用されるトンネルカプセル化と比較してパフォーマンスを悪化させません。ただし、異なるトンネルレイヤで追加の検証を行わない再帰的なトンネリングには注意が必要です。
Corruption of IP packets can occur at any point along a network path: during packet generation, during transmission over the link, in the process of routing and switching, etc. Some transmission steps include a checksum or CRC that reduces the probability for corrupted packets being forwarded, but there still exists a probability that errors may propagate undetected.
IPパケットの破損は、ネットワークパス上の任意のポイントで発生する可能性があります。パケット生成中、リンクを介した送信中、ルーティングとスイッチングのプロセス中などです。一部の送信ステップには、破損したパケットの確率を減らすチェックサムまたはCRCが含まれます転送されますが、エラーが検出されずに伝播する可能性があります。
Unfortunately, the Internet community lacks reliable information to identify the most common functions or equipment that results in packet corruption. However, there are indications that the place where corruption occurs can vary significantly from one path to another. However, there is a risk in taking evidence from one usage domain and using it to infer characteristics for another. Methods intended for general Internet usage must therefore assume that corruption can occur, and mechanisms must be deployed to mitigate the effects of corruption and any resulting misdelivery.
残念ながら、インターネットコミュニティには、パケットの破損を引き起こす最も一般的な機能や機器を特定するための信頼できる情報が不足しています。ただし、破損が発生する場所は、パスごとに大きく異なる可能性があることを示しています。ただし、1つの使用法ドメインから証拠を取得し、それを使用して別の使用法の特性を推測することにはリスクがあります。したがって、一般的なインターネットの使用を目的とした方法では、破損が発生する可能性があると想定し、破損の影響とその結果生じる誤配信を軽減するメカニズムを導入する必要があります。
IP transports designed for use in the general Internet should not assume specific path characteristics. Network protocols may reroute packets, thus changing the set of routers and middleboxes along a path. Therefore, transports such as TCP, SCTP, and DCCP have been designed to negotiate protocol parameters, adapt to different network path characteristics, and receive feedback to verify that the current path is suited to the intended application. Applications using UDP and UDP-Lite need to provide their own mechanisms to confirm the validity of the current network path.
一般的なインターネットで使用するために設計されたIPトランスポートは、特定のパス特性を前提としてはなりません。ネットワークプロトコルはパケットを再ルーティングする場合があるため、パスに沿ってルーターとミドルボックスのセットを変更します。したがって、TCP、SCTP、DCCPなどのトランスポートは、プロトコルパラメータをネゴシエートし、さまざまなネットワークパス特性に適応し、フィードバックを受信して、現在のパスが目的のアプリケーションに適していることを確認するように設計されています。 UDPおよびUDP-Liteを使用するアプリケーションは、現在のネットワークパスの有効性を確認するための独自のメカニズムを提供する必要があります。
A zero value in the UDP checksum field is explicitly disallowed in RFC 2460. Thus, it may be expected that any device on the path that has a reason to look beyond the IP header, for example, to validate the UDP checksum, will consider such a packet as erroneous or illegal and may discard it, unless the device is updated to support the new behavior. Any middlebox that modifies the UDP checksum, for example, a NAT that changes the values of the IP and UDP header in such a way that the checksum over the pseudo-header changes value, will need to be updated to support this behavior. Until then, a zero UDP checksum packet is likely to be discarded, either directly in the middlebox or at the destination, when a zero UDP checksum has been modified to be non-zero by an incremental update.
UDPチェックサムフィールドのゼロ値は、RFC 2460では明示的に禁止されています。そのため、たとえばUDPチェックサムを検証するために、IPヘッダーを超えて調べる理由があるパス上のデバイスは、そのようなことを考慮することが予想されます。デバイスが新しい動作をサポートするように更新されていない限り、パケットはエラーまたは違法であり、パケットを破棄する可能性があります。 UDPチェックサムを変更するミドルボックス（たとえば、疑似ヘッダーのチェックサムが値を変更するようにIPおよびUDPヘッダーの値を変更するNAT）は、この動作をサポートするように更新する必要があります。それまで、ゼロUDPチェックサムパケットが増分更新によって非ゼロに変更された場合、ゼロUDPチェックサムパケットは、ミドルボックス内または宛先で直接破棄される可能性があります。
A pair of endpoints intending to use the new behavior will therefore need not only to ensure support at each endpoint, but also to ensure that the path between them will deliver packets with the new behavior. This may require using negotiation or an explicit mandate to use the new behavior by all nodes that support the new protocol.
したがって、新しい動作を使用する予定のエンドポイントのペアは、各エンドポイントでのサポートを保証するだけでなく、それらの間のパスが新しい動作でパケットを配信するようにする必要もあります。これには、新しいプロトコルをサポートするすべてのノードによる新しい動作を使用するために、ネゴシエーションまたは明示的な義務を使用する必要がある場合があります。
Enabling the use of a zero checksum places new requirements on equipment deployed within the network, such as middleboxes. A middlebox (e.g., a firewall or NAT) may enable zero checksum usage for a particular range of ports. Note that checksum off-loading and operating system design may result in all IPv6 UDP traffic being sent with a calculated checksum. This requires middleboxes that are configured to enable a zero UDP checksum to continue to work with bidirectional UDP flows that use a zero UDP checksum in only one direction, and therefore, they must not maintain separate state for a UDP flow based on its checksum usage.
ゼロチェックサムの使用を有効にすると、ミドルボックスなど、ネットワーク内に配置された機器に新しい要件が発生します。ミドルボックス（ファイアウォールやNATなど）を使用すると、特定の範囲のポートでゼロチェックサムを使用できるようになります。チェックサムのオフロードとオペレーティングシステムの設計により、すべてのIPv6 UDPトラフィックが計算されたチェックサムで送信される場合があることに注意してください。これには、ゼロUDPチェックサムを有効にするように構成されたミドルボックスが、一方向でのみゼロUDPチェックサムを使用する双方向UDPフローで引き続き機能するようにする必要があるため、チェックサムの使用に基づいてUDPフローの個別の状態を維持してはなりません。
Support along the path between endpoints can be guaranteed in limited deployments by appropriate configuration. In general, it can be expected to take time for deployment of any updated behavior to become ubiquitous.
エンドポイント間のパスに沿ったサポートは、適切な構成により、限られた展開で保証できます。一般に、更新された動作の展開がユビキタスになるまでには時間がかかることが予想されます。
A sender will need to probe the path to verify the expected behavior. Path characteristics may change, and usage therefore should be robust and able to detect a failure of the path under normal usage, and should be able to renegotiate. Note that a bidirectional path does not necessarily support the same checksum usage in both the forward and return directions. Receipt of a datagram with a zero UDP checksum does not imply that the remote endpoint can also receive a datagram with a zero UDP checksum. This behavior will require periodic validation of the path, adding complexity to any solution using the new behavior.
送信者は、予想される動作を確認するためにパスをプローブする必要があります。パスの特性は変化する可能性があるため、使用法は堅牢で、通常の使用法でパスの障害を検出でき、再ネゴシエートできる必要があります。双方向パスは、順方向と戻り方向の両方で同じチェックサムの使用を必ずしもサポートしないことに注意してください。 UDPチェックサムがゼロのデータグラムを受信しても、リモートエンドポイントがUDPチェックサムがゼロのデータグラムも受信できることを意味するものではありません。この動作にはパスの定期的な検証が必要であり、新しい動作を使用するソリューションに複雑さを追加します。
The update to the IPv6 specification defined in [RFC6935] modifies only IPv6 nodes that implement specific protocols designed to permit omission of a UDP checksum. This document provides an applicability statement for the updated method, indicating when the mechanism can (and cannot) be used. Enabling a zero UDP checksum, and ensuring correct interactions with the stack, implies much more than simply disabling the checksum algorithm for specific packets at the transport interface.
[RFC6935]で定義されているIPv6仕様の更新は、UDPチェックサムの省略を許可するように設計された特定のプロトコルを実装するIPv6ノードのみを変更します。このドキュメントは、更新されたメソッドの適用性ステートメントを提供し、メカニズムをいつ使用できるか（および使用できないか）を示します。ゼロUDPチェックサムを有効にし、スタックとの正しい相互作用を保証することは、トランスポートインターフェイスで特定のパケットのチェックサムアルゴリズムを無効にするだけではないことを意味します。
When the zero UDP checksum method is widely available, we expect that it will be used by applications that perceive to gain benefit from it. Any solution that uses an end-to-end transport protocol rather than an IP-in-IP encapsulation needs to minimize the possibility that application processes could confuse a corrupted or wrongly delivered UDP datagram with that of data addressed to the application running on their endpoint.
ゼロUDPチェックサム方式が広く利用可能である場合、そのメリットを享受していると思われるアプリケーションで使用されることが期待されます。 IP-in-IPカプセル化ではなくエンドツーエンドのトランスポートプロトコルを使用するソリューションでは、アプリケーションプロセスが、破損した、または誤って配信されたUDPデータグラムを、エンドポイントで実行されているアプリケーションにアドレス指定されたデータと混同する可能性を最小限に抑える必要があります。 。
A protocol or application that uses the zero UDP checksum method must ensure that the lack of checksum does not affect the protocol operation. This includes being robust to receiving an unintended packet from another protocol or context following corruption of a destination or source address and/or port value. It also includes considering the need for additional implicit protection mechanisms required when using the payload of a UDP packet received with a zero checksum.
ゼロUDPチェックサム方式を使用するプロトコルまたはアプリケーションは、チェックサムの欠如がプロトコルの動作に影響しないことを確認する必要があります。これには、宛先または送信元のアドレスやポートの値の破損に続く別のプロトコルまたはコンテキストからの意図しないパケットの受信に対する堅牢性が含まれます。また、ゼロのチェックサムで受信されたUDPパケットのペイロードを使用するときに必要な追加の暗黙的な保護メカニズムの必要性を検討することも含まれます。
It is important to consider the potential impact of using a zero UDP checksum on endpoint devices and applications that are not modified to support the new behavior or, by default or preference, do not use the regular behavior. These applications must not be significantly impacted by the update.
新しい動作をサポートするように変更されていないエンドポイントデバイスとアプリケーションでゼロUDPチェックサムを使用することの潜在的な影響を考慮することは重要です。または、デフォルトまたは設定により、通常の動作を使用しません。これらのアプリケーションは、更新による大きな影響を受けてはなりません。
To illustrate why this necessary, consider the implications of a node that enables use of a zero UDP checksum at the interface level. This would result in all applications that listen to a UDP socket receiving datagrams where the checksum was not verified. This could have a significant impact on an application that was not designed with the additional robustness needed to handle received packets with corruption, creating state or destroying existing state in the application.
これが必要な理由を説明するために、インターフェイスレベルでゼロのUDPチェックサムの使用を可能にするノードの影響を考慮してください。これにより、UDPソケットをリッスンするすべてのアプリケーションが、チェックサムが検証されていないデータグラムを受信することになります。これは、破損した受信パケットの処理、状態の作成、またはアプリケーションの既存の状態の破棄に必要な追加の堅牢性を備えて設計されていないアプリケーションに大きな影響を与える可能性があります。
Therefore, a zero UDP checksum needs to be enabled only for individual ports using an explicit request by the application. In this case, applications using other ports would maintain the current IPv6 behavior, discarding incoming datagrams with a zero UDP checksum. These other applications would not be affected by this changed behavior. An application that allows the changed behavior should be aware of the risk of corruption and the increased level of misdirected traffic, and can be designed robustly to handle this risk.
したがって、ゼロUDPチェックサムは、アプリケーションによる明示的な要求を使用する個々のポートに対してのみ有効にする必要があります。この場合、他のポートを使用するアプリケーションは現在のIPv6動作を維持し、UDPチェックサムがゼロの着信データグラムを破棄します。これらの他のアプリケーションは、この変更された動作の影響を受けません。動作の変更を許可するアプリケーションは、破損のリスクと誤った方向に向けられたトラフィックのレベルの増加を認識している必要があり、このリスクを処理するように堅牢に設計できます。
This section is an applicability statement that defines requirements and recommendations for the implementation of IPv6 nodes that support the use of a zero value in the checksum field of a UDP datagram.
このセクションは、UDPデータグラムのチェックサムフィールドでのゼロ値の使用をサポートするIPv6ノードの実装に関する要件と推奨事項を定義する適用性ステートメントです。
All implementations that support the zero UDP checksum method MUST conform to the requirements defined below:
ゼロUDPチェックサムメソッドをサポートするすべての実装は、以下に定義されている要件に準拠する必要があります。
1. An IPv6 sending node MAY use a calculated RFC 2460 checksum for all datagrams that it sends. This explicitly permits an interface that supports checksum off-loading to insert an updated UDP checksum value in all UDP datagrams that it forwards. Note, however, that sending a calculated checksum requires the receiver to also perform the checksum calculation. Checksum off-loading can normally be switched off for a particular interface to ensure that datagrams are sent with a zero UDP checksum.
1. IPv6送信ノードは、送信するすべてのデータグラムに対して計算されたRFC 2460チェックサムを使用できます（MAY）。これにより、チェックサムのオフロードをサポートするインターフェースが、転送するすべてのUDPデータグラムに更新されたUDPチェックサム値を挿入することが明示的に許可されます。ただし、計算されたチェックサムを送信するには、受信者がチェックサム計算も実行する必要があることに注意してください。チェックサムオフロードは、通常、特定のインターフェイスに対してオフにして、ゼロのUDPチェックサムでデータグラムが送信されるようにすることができます。
2. IPv6 nodes SHOULD, by default, NOT allow the zero UDP checksum method for transmission.
2. IPv6ノードは、デフォルトで、転送にゼロUDPチェックサム方式を許可しないでください。
3. IPv6 nodes MUST provide a way for the application/protocol to indicate the set of ports that will be enabled to send datagrams with a zero UDP checksum. This may be implemented by enabling a transport mode using a socket API call when the socket is established, or by a similar mechanism. It may also be implemented by enabling the method for a pre-assigned static port used by a specific tunnel protocol.
3. IPv6ノードは、アプリケーション/プロトコルが、UDPチェックサムがゼロのデータグラムを送信できるようにするポートのセットを示す方法を提供する必要があります。これは、ソケットが確立されたときにソケットAPI呼び出しを使用してトランスポートモードを有効にすることによって、または同様のメカニズムによって実装できます。また、特定のトンネルプロトコルによって使用される事前に割り当てられた静的ポートのメソッドを有効にすることによって実装することもできます。
4. IPv6 nodes MUST provide a method to allow an application/ protocol to indicate that a particular UDP datagram is required to be sent with a UDP checksum. This needs to be allowed by the operating system at any time (e.g., to send keepalive datagrams), not just when a socket is established in zero checksum mode.
4. IPv6ノードは、特定のUDPデータグラムがUDPチェックサムで送信される必要があることをアプリケーション/プロトコルが示すことを可能にするメソッドを提供しなければなりません（MUST）。これは、ソケットがゼロチェックサムモードで確立されたときだけでなく、いつでも（たとえば、キープアライブデータグラムを送信するために）オペレーティングシステムによって許可される必要があります。
5. The default IPv6 node receiver behavior MUST be to discard all IPv6 packets carrying datagrams with a zero UDP checksum.
5. デフォルトのIPv6ノードレシーバーの動作は、UDPチェックサムがゼロのデータグラムを運ぶすべてのIPv6パケットを破棄する必要があります。
6. IPv6 nodes MUST provide a way for the application/protocol to indicate the set of ports that will be enabled to receive datagrams with a zero UDP checksum. This may be implemented via a socket API call or by a similar mechanism. It may also be implemented by enabling the method for a pre-assigned static port used by a specific tunnel protocol.
6. IPv6ノードは、アプリケーション/プロトコルが、UDPチェックサムがゼロのデータグラムを受信できるようにするポートのセットを示す方法を提供する必要があります。これは、ソケットAPI呼び出しまたは同様のメカニズムによって実装できます。また、特定のトンネルプロトコルによって使用される事前に割り当てられた静的ポートのメソッドを有効にすることによって実装することもできます。
7. IPv6 nodes supporting usage of zero UDP checksums MUST also allow reception using a calculated UDP checksum on all ports configured to allow zero UDP checksum usage. (The sending endpoint, e.g., the encapsulating ingress, may choose to compute the UDP checksum or may calculate it by default.) The receiving endpoint MUST use the reception method specified in RFC2460 when the checksum field is not zero.
7. ゼロUDPチェックサムの使用をサポートするIPv6ノードは、ゼロUDPチェックサムの使用を許可するように構成されたすべてのポートで、計算されたUDPチェックサムを使用した受信も許可する必要があります。 （送信側エンドポイント、たとえばカプセル化イングレスは、UDPチェックサムを計算するか、デフォルトで計算するかを選択できます。）受信側エンドポイントは、チェックサムフィールドがゼロでない場合、RFC2460で指定された受信方法を使用する必要があります。
8. RFC 2460 specifies that IPv6 nodes SHOULD log received datagrams with a zero UDP checksum. This remains the case for any datagram received on a port that does not explicitly enable processing of a zero UDP checksum. A port for which the zero UDP checksum has been enabled MUST NOT log the datagram solely because the checksum value is zero.
8. RFC 2460は、IPv6ノードがゼロのUDPチェックサムで受信したデータグラムをログに記録する必要があることを指定しています。これは、ゼロUDPチェックサムの処理を明示的に有効にしないポートで受信されたデータグラムの場合にも当てはまります。ゼロUDPチェックサムが有効になっているポートは、チェックサム値がゼロであるという理由だけでデータグラムをログに記録してはなりません。
9. IPv6 nodes MAY separately identify received UDP datagrams that are discarded with a zero UDP checksum. They SHOULD NOT add these to the standard log, because the endpoint has not been verified. This may be used to support other functions (such as a security policy).
9. IPv6ノードは、UDPチェックサムがゼロで破棄される受信UDPデータグラムを個別に識別してもよい（MAY）。エンドポイントが確認されていないため、これらを標準ログに追加しないでください。これは、他の機能（セキュリティポリシーなど）をサポートするために使用できます。
10. IPv6 nodes that receive ICMPv6 messages that refer to packets with a zero UDP checksum MUST provide appropriate checks concerning the consistency of the reported packet to verify that the reported packet actually originated from the node, before acting upon the information (e.g., validating the address and port numbers in the ICMPv6 message body).
10. UDPチェックサムがゼロのパケットを参照するICMPv6メッセージを受信するIPv6ノードは、情報に基づいて処理する前に、報告されたパケットがノードから実際に発信されたことを確認するために、報告されたパケットの整合性に関する適切なチェックを提供する必要があります（たとえば、アドレスの検証やICMPv6メッセージ本文のポート番号）。
This section is an applicability statement that identifies requirements and recommendations for protocols and tunnel encapsulations that are transported over an IPv6 transport flow (e.g., a tunnel) that does not perform a UDP checksum calculation to verify the integrity at the transport endpoints. Before deciding to use the zero UDP checksum and lose the integrity verification provided by non-zero checksumming, a protocol developer should seriously consider if they can use checksummed UDP packets or UDP-Lite [RFC3828], because IPv6 with a zero UDP checksum is not equivalent in behavior to IPv4 with zero UDP checksum.
このセクションは、UDPチェックサム計算を実行してトランスポートエンドポイントでの整合性を検証しないIPv6トランスポートフロー（トンネルなど）を介してトランスポートされるプロトコルとトンネルカプセル化の要件と推奨事項を識別する適用性ステートメントです。ゼロのUDPチェックサムを使用することを決定し、ゼロ以外のチェックサムによって提供される整合性検証を失う前に、プロトコル開発者は、チェックサムされたUDPパケットまたはUDP-Lite [RFC3828]を使用できるかどうかを真剣に検討する必要があります。 UDPチェックサムがゼロのIPv4と同じ動作です。
The requirements and recommendations for protocols and tunnel encapsulations using an IPv6 transport flow that does not perform a UDP checksum calculation to verify the integrity at the transport endpoints are: 1. Transported protocols that enable the use of zero UDP checksum MUST enable this only for a specific port or port range. This needs to be enabled at the sending and receiving endpoints for a UDP flow.
トランスポートエンドポイントでの整合性を検証するためにUDPチェックサム計算を実行しないIPv6トランスポートフローを使用するプロトコルとトンネルカプセル化の要件と推奨事項は次のとおりです。1.ゼロUDPチェックサムの使用を有効にするトランスポートプロトコルは、特定のポートまたはポート範囲。これは、UDPフローの送信エンドポイントと受信エンドポイントで有効にする必要があります。
2. An integrity mechanism is always RECOMMENDED at the transported protocol layer to ensure that corruption rates of the delivered payload are not increased (e.g., at the innermost packet of a UDP tunnel). A mechanism that isolates the causes of corruption (e.g., identifying misdelivery, IPv6 header corruption, or tunnel header corruption) is also expected to provide additional information about the status of the tunnel (e.g., to suggest a security attack).
2. 完全性メカニズムは、転送されたペイロードの破損率が増加しないようにするために（たとえば、UDPトンネルの最も内側のパケットで）、トランスポートされたプロトコル層で常に推奨されます。破損の原因を特定するメカニズム（誤配信の特定、IPv6ヘッダーの破損、トンネルヘッダーの破損など）も、トンネルのステータスに関する追加情報を提供することが期待されています（たとえば、セキュリティ攻撃を示唆するため）。
3. A transported protocol that encapsulates Internet Protocol (IPv4 or IPv6) packets MAY rely on the inner packet integrity checks, provided that the tunnel protocol will not significantly increase the rate of corruption of the inner IP packet. If a significantly increased corruption rate can occur, the tunnel protocol MUST provide an additional integrity verification mechanism. Early detection is desirable to avoid wasting unnecessary computation, transmission capacity, or storage for packets that will subsequently be discarded.
3. インターネットプロトコル（IPv4またはIPv6）パケットをカプセル化する転送プロトコルは、トンネルプロトコルが内部IPパケットの破損率を大幅に増加させない限り、内部パケットの整合性チェックに依存する場合があります。破損率が大幅に増加する可能性がある場合、トンネルプロトコルは追加の整合性検証メカニズムを提供する必要があります。後で検出されるパケットの不要な計算、伝送容量、またはストレージを無駄にしないためには、早期検出が望ましいです。
4. A transported protocol that supports the use of a zero UDP checksum MUST be designed so that corruption of any header information does not result in accumulation of incorrect state for the protocol.
4. ゼロUDPチェックサムの使用をサポートするトランスポートされたプロトコルは、ヘッダー情報の破損によってプロトコルの誤った状態が蓄積されないように設計されている必要があります。
5. A transported protocol with a non-tunnel payload or one that encapsulates non-IP packets MUST have a CRC or other mechanism for checking packet integrity, unless the non-IP packet is specifically designed for transmission over a lower layer that does not provide a packet integrity guarantee.
5. 非IPパケットがパケットを提供しない下位層での送信用に特別に設計されている場合を除き、非トンネルペイロードまたは非IPパケットをカプセル化するトランスポートプロトコルには、パケットの整合性をチェックするためのCRCまたはその他のメカニズムが必要です完全性保証。
6. A transported protocol with control feedback SHOULD be robust to changes in the network path, because the set of middleboxes on a path may vary during the life of an association. The UDP endpoints need to discover paths with middleboxes that drop packets with a zero UDP checksum. Therefore, transported protocols SHOULD send keepalive messages with a zero UDP checksum. An endpoint that discovers an appreciable loss rate for keepalive packets MAY terminate the UDP flow (e.g., a tunnel). Section 3.1.3 of RFC 5405 describes requirements for congestion control when using a UDP-based transport.
6. パス上のミドルボックスのセットはアソシエーションの存続期間中に変化する可能性があるため、制御フィードバック付きのトランスポートされたプロトコルは、ネットワークパスの変更に対して堅牢である必要があります。 UDPエンドポイントは、UDPチェックサムがゼロのパケットをドロップするミドルボックスのあるパスを検出する必要があります。したがって、トランスポートされたプロトコルは、UDPチェックサムがゼロのキープアライブメッセージを送信する必要があります（SHOULD）。キープアライブパケットのかなりの損失率を発見したエンドポイントは、UDPフロー（トンネルなど）を終了する場合があります。 RFC 5405のセクション3.1.3は、UDPベースのトランスポートを使用するときの輻輳制御の要件について説明しています。
7. A protocol with control feedback that can fall back to using UDP with a calculated RFC 2460 checksum is expected to be more robust to changes in the network path. Therefore, keepalive messages SHOULD include both UDP datagrams with a checksum and datagrams with a zero UDP checksum. This will enable the remote endpoint to distinguish between a path failure and the dropping of datagrams with a zero UDP checksum.
7. 計算されたRFC 2460チェックサムでUDPを使用するようにフォールバックできる制御フィードバックを備えたプロトコルは、ネットワークパスの変更に対してより堅牢であることが期待されます。したがって、キープアライブメッセージには、チェックサムが付いたUDPデータグラムと、UDPチェックサムがゼロのデータグラムの両方を含める必要があります（SHOULD）。これにより、リモートエンドポイントは、パスの障害と、UDPチェックサムがゼロのデータグラムのドロップを区別できます。
8. A middlebox implementation MUST allow forwarding of an IPv6 UDP datagram with both a zero and a standard UDP checksum using the same UDP port.
8. ミドルボックスの実装では、同じUDPポートを使用して、ゼロと標準のUDPチェックサムの両方を持つIPv6 UDPデータグラムの転送を許可する必要があります。
9. A middlebox MAY configure a restricted set of specific port ranges that forward UDP datagrams with a zero UDP checksum. The middlebox MAY drop IPv6 datagrams with a zero UDP checksum that are outside a configured range.
9. ミドルボックスは、UDPチェックサムがゼロのUDPデータグラムを転送する特定のポート範囲の制限されたセットを構成する場合があります（MAY）。ミドルボックスは、構成された範囲外にある、UDPチェックサムがゼロのIPv6データグラムをドロップする場合があります。
10. When a middlebox forwards an IPv6 UDP flow containing datagrams with both a zero and a standard UDP checksum, the middlebox MUST NOT maintain separate state for flows, depending on the value of their UDP checksum field. (This requirement is necessary to enable a sender that always calculates a checksum to communicate via a middlebox with a remote endpoint that uses a zero UDP checksum.)
10. ミドルボックスがゼロと標準の両方のUDPチェックサムを持つデータグラムを含むIPv6 UDPフローを転送する場合、ミドルボックスは、UDPチェックサムフィールドの値に応じて、フローの個別の状態を維持してはなりません（MUST NOT）。 （この要件は、チェックサムを常に計算する送信者がミドルボックスを介して、ゼロのUDPチェックサムを使用するリモートエンドポイントと通信できるようにするために必要です。）
Special considerations are required when designing a UDP tunnel protocol where the tunnel ingress or egress may be a router that may not have access to the packet payload. When the node is acting as a host (i.e., sending or receiving a packet addressed to itself), the checksum processing is similar to other hosts. However, when the node (e.g., a router) is acting as a tunnel ingress or egress that forwards a packet to or from a UDP tunnel, there may be restricted access to the packet payload. This prevents calculating (or verifying) a UDP checksum. In this case, the tunnel protocol may use a zero UDP checksum and must:
トンネルの入口または出口がパケットペイロードにアクセスできないルーターである可能性があるUDPトンネルプロトコルを設計する場合は、特別な考慮事項が必要です。ノードがホストとして機能している（つまり、自分宛てのパケットを送信または受信している）場合、チェックサム処理は他のホストと同様です。ただし、ノード（ルーターなど）がUDPトンネルとの間でパケットを転送するトンネルの入口または出口として機能している場合、パケットペイロードへのアクセスが制限されることがあります。これにより、UDPチェックサムの計算（または検証）が防止されます。この場合、トンネルプロトコルはゼロのUDPチェックサムを使用する可能性があり、以下を行う必要があります。
o Ensure that tunnel ingress and tunnel egress router are both configured to use a zero UDP checksum. For example, this may include ensuring that hardware checksum off-loading is disabled.
o トンネル入口とトンネル出口ルーターの両方が、ゼロのUDPチェックサムを使用するように構成されていることを確認します。たとえば、ハードウェアチェックサムのオフロードが無効になっていることを確認することが含まれます。
o The tunnel operator must ensure that middleboxes on the network path are updated to support use of a zero UDP checksum.
o トンネルオペレーターは、ゼロUDPチェックサムの使用をサポートするために、ネットワークパス上のミドルボックスが更新されていることを確認する必要があります。
o A tunnel egress should implement appropriate security techniques to protect from overload, including source address filtering to prevent traffic injection by an attacker and rate-limiting of any packets that incur additional processing, such as UDP datagrams used for control functions that require verification of a calculated checksum to verify the network path. Usage of common control traffic for multiple tunnels between a pair of nodes can assist in reducing the number of packets to be processed.
oトンネル出口は、攻撃者によるトラフィックインジェクションを防止するための送信元アドレスフィルタリングや、検証を必要とする制御機能に使用されるUDPデータグラムなどの追加処理が発生するパケットのレート制限など、過負荷から保護する適切なセキュリティ技術を実装する必要があります。ネットワークパスを検証するために計算されたチェックサム。ノードのペア間の複数のトンネルに共通の制御トラフィックを使用すると、処理するパケットの数を減らすのに役立ちます。
This document provides an applicability statement for the use of UDP transport checksums with IPv6.
このドキュメントは、IPv6でUDPトランスポートチェックサムを使用するための適用性ステートメントを提供します。
It examines the role of the UDP transport checksum when used with IPv6 and presents a summary of the trade-offs in evaluating the safety of updating RFC 2460 to permit an IPv6 endpoint to use a zero UDP checksum field to indicate that no checksum is present.
IPv6で使用する場合のUDPトランスポートチェックサムの役割を調べ、RFC 2460を更新してIPv6エンドポイントがゼロのUDPチェックサムフィールドを使用してチェックサムが存在しないことを示すことを許可する安全性の評価におけるトレードオフの概要を示します。
Application designers should first examine whether their transport goals may be met using standard UDP (with a calculated checksum) or UDP-Lite. The use of UDP with a zero UDP checksum has merits for some applications, such as tunnel encapsulation, and is widely used in IPv4. However, there are different dangers for IPv6. There is an increased risk of corruption and misdelivery when using zero UDP checksum in IPv6 compared to using IPv4 due to the lack of an IPv6 header checksum. Thus, application designers need to evaluate the risks of enabling use of a zero UDP checksum and consider a solution that at least provides the same delivery protection as for IPv4, for example, by utilizing UDP-Lite or by enabling the UDP checksum. The use of checksum off-loading may help alleviate the cost of checksum processing and permit use of a checksum using method defined in RFC 2460.
アプリケーション設計者はまず、標準のUDP（計算されたチェックサムを使用）またはUDP-Liteを使用して、トランスポートの目標が満たされるかどうかを調べる必要があります。 UDPチェックサムがゼロのUDPを使用すると、トンネルカプセル化などの一部のアプリケーションにメリットがあり、IPv4で広く使用されています。ただし、IPv6にはさまざまな危険があります。 IPv6ヘッダーチェックサムがないため、IPv4を使用する場合と比較して、IPv6でゼロUDPチェックサムを使用すると、破損や誤配信のリスクが高まります。したがって、アプリケーション設計者は、ゼロUDPチェックサムの使用を有効にするリスクを評価し、たとえば、UDP-Liteを使用するか、UDPチェックサムを有効にすることによって、IPv4と同じ配信保護を提供するソリューションを検討する必要があります。チェックサムオフロードを使用すると、チェックサム処理のコストを軽減し、RFC 2460で定義されている方法を使用してチェックサムを使用できるようになります。
Tunnel applications using UDP for encapsulation can, in many cases, use a zero UDP checksum without significant impact on the corruption rate. A well-designed tunnel application should include consistency checks to validate the header information encapsulated with a received packet. In most cases, tunnels encapsulating IP packets can rely on the integrity protection provided by the transported protocol (or tunneled inner packet). When correctly implemented, such an endpoint will not be negatively impacted by the omission of the transport-layer checksum. Recursive tunneling and fragmentation are potential issues that can raise corruption rates significantly, and they require careful consideration.
カプセル化にUDPを使用するトンネルアプリケーションは、多くの場合、破損率に大きな影響を与えずにゼロUDPチェックサムを使用できます。適切に設計されたトンネルアプリケーションには、受信パケットでカプセル化されたヘッダー情報を検証するための整合性チェックが含まれている必要があります。ほとんどの場合、IPパケットをカプセル化するトンネルは、転送されたプロトコル（またはトンネル化された内部パケット）によって提供される整合性保護に依存できます。正しく実装されていれば、そのようなエンドポイントはトランスポート層のチェックサムの省略による悪影響を受けません。再帰的なトンネリングと断片化は、破損率を大幅に上げる可能性のある潜在的な問題であり、注意深く検討する必要があります。
Other UDP applications at the intended destination node or another node can be impacted if the nodes are allowed to receive datagrams that have a zero UDP checksum. It is important that already deployed applications are not impacted by a change at the transport layer. If these applications execute on nodes that implement RFC 2460, they will discard (and log) all datagrams with a zero UDP checksum. This is not an issue.
目的の宛先ノードまたは別のノードにある他のUDPアプリケーションは、ノードがUDPチェックサムがゼロのデータグラムを受信できる場合、影響を受ける可能性があります。すでにデプロイされているアプリケーションがトランスポート層での変更の影響を受けないことが重要です。これらのアプリケーションがRFC 2460を実装するノードで実行される場合、それらは、UDPチェックサムがゼロのすべてのデータグラムを破棄（およびログ）します。これは問題ではありません。
In general, UDP-based applications need to employ a mechanism that allows a large percentage of the corrupted packets to be removed before they reach an application, to protect both the data stream of the application and the control plane of higher layer protocols. These checks are currently performed by the UDP checksum for IPv6 or by the reduced checksum for UDP-Lite when used with IPv6.
一般に、UDPベースのアプリケーションは、アプリケーションのデータストリームと上位層プロトコルのコントロールプレーンの両方を保護するために、破損したパケットの大部分をアプリケーションに到達する前に削除できるメカニズムを採用する必要があります。これらのチェックは現在、IPv6のUDPチェックサムまたはIPv6で使用される場合はUDP-Liteの縮小チェックサムによって実行されます。
The transport of recursive tunneling and the use of fragmentation pose difficult issues that need to be considered in the design of tunnel protocols. There is an increased risk of an error in the innermost packet when fragmentation occurs across several layers of tunneling and several different reassembly processes are run without verification of correctness. This requires extra thought and careful consideration in the design of transported tunnels.
再帰的トンネリングの転送と断片化の使用は、トンネルプロトコルの設計で考慮する必要がある困難な問題を引き起こします。トンネリングのいくつかの層にわたってフラグメンテーションが発生し、正しいことを確認せずにいくつかの異なる再構成プロセスが実行されると、最も内側のパケットでエラーのリスクが高まります。これには、転送されるトンネルの設計において、特別な考慮と注意深い考慮が必要です。
Any use of the updated method must consider the implications for firewalls, NATs, and other middleboxes. It is not expected that IPv6 NATs will handle IPv6 UDP datagrams in the same way that they handle IPv4 UDP datagrams. In many deployed cases, an update to support an IPv6 zero UDP checksum will be required. Firewalls are intended to be configured, and therefore, they may need to be explicitly updated to allow new services or protocols. Deployment of IPv6 middleboxes is not yet as prolific as it is in IPv4, and therefore, new devices are expected to follow the methods specified in this document.
更新された方法を使用する場合は、ファイアウォール、NAT、およびその他のミドルボックスへの影響を考慮する必要があります。 IPv6 NATがIPv4 UDPデータグラムを処理するのと同じ方法でIPv6 UDPデータグラムを処理することは期待されていません。多くの導入事例では、IPv6ゼロUDPチェックサムをサポートするためのアップデートが必要になります。ファイアウォールは構成することを目的としているため、新しいサービスやプロトコルを許可するには、ファイアウォールを明示的に更新する必要がある場合があります。 IPv6ミドルボックスの配備は、IPv4の場合ほど多くはありません。そのため、新しいデバイスは、このドキュメントで指定されている方法に従うことが求められます。
Each application should consider the implications of choosing an IPv6 transport that uses a zero UDP checksum and should consider whether other standard methods may be more appropriate and may simplify application design.
各アプリケーションは、UDPチェックサムがゼロのIPv6トランスポートを選択することの影響を考慮し、他の標準的な方法がより適切であり、アプリケーション設計を簡略化できるかどうかを考慮する必要があります。
Transport checksums provide the first stage of protection for the stack, although they cannot be considered authentication mechanisms. These checks are also desirable to ensure that packet counters correctly log actual activity, and they can be used to detect unusual behaviors.
トランスポートチェックサムはスタックの保護の最初の段階を提供しますが、認証メカニズムとは見なされません。これらのチェックは、パケットカウンターが実際のアクティビティを正しくログに記録することを保証するためにも望ましく、異常な動作を検出するために使用できます。
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 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 that is forwarding zero checksum UDP packets and cause overload in the processing of the non-zero checksums, e.g., if it happens in a router's slow path. Protection mechanisms should therefore 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パケットを挿入しようとする可能性があり、非ゼロチェックサムの処理で過負荷を引き起こす可能性があります（ルーターの遅いパスで発生した場合など）。したがって、この脅威が存在する場合は、保護メカニズムを採用する必要があります。保護には、攻撃者がトラフィックを注入するのを防ぐための送信元アドレスフィルタリングや、ゼロ以外のチェックサムトラフィックの量を抑制することが含まれます。後者は、トンネルプロトコルの機能に影響を与える可能性があります。
Transmission of IPv6 packets with a zero UDP checksum could reveal additional information to help an on-path attacker identify the operating system or configuration of a sending node. There is a need to probe the network path to determine whether the current path supports the use of IPv6 packets with a zero UDP checksum. The details of the probing mechanism may differ for different tunnel encapsulations, and if they are visible in the network (e.g., if not using IPsec in encryption mode), they could reveal additional information to help an on-path attacker identify the type of tunnel being used.
UDPチェックサムがゼロのIPv6パケットを送信すると、経路上の攻撃者がオペレーティングシステムまたは送信ノードの構成を特定するのに役立つ追加情報が明らかになる可能性があります。現在のパスが、UDPチェックサムがゼロのIPv6パケットの使用をサポートしているかどうかを判断するために、ネットワークパスをプローブする必要があります。プローブメカニズムの詳細は、トンネルカプセル化によって異なり、ネットワークで可視である場合（暗号化モードでIPsecを使用していない場合など）は、パス上の攻撃者がトンネルのタイプを特定するのに役立つ追加情報を明らかにする可能性があります。使用されています。
IP-in-IP or GRE tunnels offer good traversal of middleboxes that have not been designed for security, e.g., firewalls. However, firewalls may be expected to be configured to block general tunnels, because they present a large attack surface. This applicability statement therefore permits this method to be enabled only for specific port ranges.
IP-in-IPまたはGREトンネルは、ファイアウォールなどのセキュリティ用に設計されていないミドルボックスを適切に通過できます。ただし、ファイアウォールは一般的なトンネルをブロックするように構成されている可能性があります。これは、ファイアウォールが大きな攻撃対象となるためです。したがって、この適用性ステートメントでは、このメソッドを特定のポート範囲に対してのみ有効にすることができます。
When the zero UDP checksum mode is enabled for a range of ports, nodes and middleboxes must forward received UDP datagrams that have either a calculated checksum or a zero checksum.
ポートの範囲でゼロUDPチェックサムモードが有効になっている場合、ノードとミドルボックスは、計算されたチェックサムまたはゼロチェックサムのいずれかを持つ受信したUDPデータグラムを転送する必要があります。
We would like to thank Brian Haberman, Brian Carpenter, Margaret Wasserman, Lars Eggert, and others in the TSV directorate. Barry Leiba, Ronald Bonica, Pete Resnick, and Stewart Bryant helped to make this document one with greater applicability. Thanks to P.F. Chimento for careful review and editorial corrections.
TSV総局のブライアンハーバーマン、ブライアンカーペンター、マーガレットワッサーマン、ラースエガートなどに感謝します。バリーレイバ、ロナルドボニカ、ピートレズニック、スチュワートブライアントは、このドキュメントをより適用性の高いものにするのに役立ちました。 P.F.に感謝慎重なレビューと編集上の修正のためのChimento。
Thanks also to Remi Denis-Courmont, Pekka Savola, Glen Turner, and many others who contributed comments and ideas via the 6man, behave, lisp, and mboned lists.
6man、behave、lisp、mbonedリストを介してコメントやアイデアを提供してくれたRemi Denis-Courmont、Pekka Savola、Glen Turner、その他多くの人にも感謝します。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768] Postel、J。、「User Datagram Protocol」、STD 6、RFC 768、1980年8月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[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月。
[RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and UDP Checksums for Tunneled Packets", RFC 6935, April 2013.
[RFC6935] Eubanks、M.、Chimento、P。、およびM. Westerlund、「IPv6およびUDPトンネルパケットのチェックサム」、RFC 6935、2013年4月。
[AMT] Bumgardner, G., "Automatic Multicast Tunneling", Work in Progress, June 2012.
[AMT] Bumgardner、G。、「Automatic Multicast Tunneling」、Work in Progress、2012年6月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、1981年9月。
[RFC1071] Braden, R., Borman, D., Partridge, C., and W. Plummer, "Computing the Internet checksum", RFC 1071, September 1988.
[RFC1071] Braden、R.、Borman、D.、Partridge、C。、およびW. Plummer、「Computing the Internet checksum」、RFC 1071、1988年9月。
[RFC1141] Mallory, T. and A. Kullberg, "Incremental updating of the Internet checksum", RFC 1141, January 1990.
[RFC1141]マロリー、T。およびA.カルバーグ、「インターネットチェックサムの増分更新」、RFC 1141、1990年1月。
[RFC1624] Rijsinghani, A., "Computation of the Internet Checksum via Incremental Update", RFC 1624, May 1994.
[RFC1624] Rijsinghani、A.、「インクリメンタルアップデートによるインターネットチェックサムの計算」、RFC 1624、1994年5月。
[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月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、2003年7月。
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, "Advice for Internet Subnetwork Designers", BCP 89, RFC 3819, July 2004.
[RFC3819]カーン、P。、ボルマン、C。、フェアハースト、G。、グロスマン、D。、ルートヴィヒ、R。、マハビ、J。、モンテネグロ、G。、タッチ、J.、L。ウッド、「助言インターネットサブネットワークデザイナー向け」、BCP 89、RFC 3819、2004年7月。
[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月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443]コンタ、A。、ディアリング、S。、およびM.グプタ、「インターネットプロトコルバージョン6（IPv6）仕様のインターネットコントロールメッセージプロトコル（ICMPv6）」、RFC 4443、2006年3月。
[RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly Errors at High Data Rates", RFC 4963, July 2007.
[RFC4963] Heffner、J.、Matis、M。、およびB. Chandler、「高データレートでのIPv4再構成エラー」、RFC 4963、2007年7月。
[RFC5097] Renker, G. and G. Fairhurst, "MIB for the UDP-Lite protocol", RFC 5097, January 2008.
[RFC5097]レンカー、G。およびG.フェアハースト、「UDP-Liteプロトコル用のMIB」、RFC 5097、2008年1月。
[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月。
[RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification", RFC 5415, March 2009.
[RFC5415] Calhoun、P.、Montemurro、M。、およびD. Stanley、「Control and Provisioning of Wireless Access Points（CAPWAP）Protocol Specification」、RFC 5415、2009年3月。
[RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", RFC 5722, December 2009.
[RFC5722] Krishnan、S。、「Handling of Overlapping IPv6 Fragments」、RFC 5722、2009年12月。
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, November 2011.
[RFC6437] Amante、S.、Carpenter、B.、Jiang、S.、J。Rajahalme、「IPv6 Flow Label Specification」、RFC 6437、2011年11月。
[RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels", RFC 6438, November 2011.
[RFC6438]カーペンター、B。およびS.アマンテ、「トンネルでの等コストマルチパスルーティングおよびリンク集約のためのIPv6フローラベルの使用」、RFC 6438、2011年11月。
[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月。
[Sigcomm2000] Stone, J. and C. Partridge, "When the CRC and TCP Checksum Disagree", 2000, <http://conferences.sigcomm.org/sigcomm/2000/conf/ abstract/9-1.htm>.
[Sigcomm2000] Stone、J。およびC. Partridge、「When the CRC and TCP Checksum Disagree」、2000、<http://conferences.sigcomm.org/sigcomm/2000/conf/ abstract / 9-1.htm>。
[TUNNELS] Touch, J. and M. Townsley, "Tunnels in the Internet Architecture", Work in Progress, March 2010.
[TUNNELS] Touch、J。およびM.タウンズリー、「インターネットアーキテクチャのトンネル」、2010年3月、作業中。
[UDPTT] Fairhurst, G., "The UDP Tunnel Transport mode", Work in Progress, February 2010.
[UDPTT] Fairhurst、G。、「UDPトンネルトランスポートモード」、Work in Progress、2010年2月。
Appendix A. Evaluation of Proposal to Update RFC 2460 to Support Zero Checksum
付録A.ゼロチェックサムをサポートするようにRFC 2460を更新する提案の評価
This informative appendix documents the evaluation of the proposal to update IPv6 [RFC2460] such that it provides the option that some nodes may suppress generation and checking of the UDP transport checksum. It also compares this proposal with other alternatives, and notes that for a particular application, some standard methods may be more appropriate than using IPv6 with a zero UDP checksum.
この有益な付録は、一部のノードがUDPトランスポートチェックサムの生成とチェックを抑制するオプションを提供するように、IPv6 [RFC2460]を更新する提案の評価を文書化しています。また、この提案を他の代替案と比較し、特定のアプリケーションでは、UDPチェックサムがゼロのIPv6を使用するよりも、いくつかの標準的な方法の方が適切である可能性があることに注意します。
There are several alternatives to the normal method for calculating the UDP checksum [RFC1071] that do not require a tunnel endpoint to inspect the entire packet when computing a checksum. These include:
チェックサムを計算するときにパケット全体を検査するためにトンネルエンドポイントを必要としない、UDPチェックサム[RFC1071]を計算する通常の方法に代わる方法がいくつかあります。これらは以下を含みます：
o IP-in-IP tunneling. Because this method completely dispenses with a transport protocol in the outer layer, it has reduced overhead and complexity, but also reduced functionality. There is no outer checksum over the packet, and also there are no ports to perform demultiplexing among different tunnel types. This reduces the available information upon which a load balancer may act.
o IP-in-IPトンネリング。この方法では、外層のトランスポートプロトコルが完全に不要になるため、オーバーヘッドと複雑さが軽減されますが、機能も低下します。パケットには外部チェックサムがなく、異なるトンネルタイプ間で逆多重化を実行するポートもありません。これにより、ロードバランサーが動作する可能性のある利用可能な情報が減少します。
o UDP-Lite with the checksum coverage set to only the header portion of a packet. This requires a pseudo-header checksum calculation only on the encapsulating packet header. The computed checksum value may be cached (before adding the Length field) for each flow/destination and subsequently combined with the Length of each packet to minimize per-packet processing. This value is combined with the UDP payload length for the pseudo-header. However, this length is expected to be known when performing packet forwarding.
o チェックサムカバレッジがパケットのヘッダー部分のみに設定されたUDP-Lite。これには、カプセル化パケットヘッダーでのみ疑似ヘッダーチェックサム計算が必要です。計算されたチェックサム値は、フロー/宛先ごとに（長さフィールドを追加する前に）キャッシュされ、その後、各パケットの長さと組み合わせられて、パケットごとの処理が最小化されます。この値は、疑似ヘッダーのUDPペイロード長と組み合わされます。ただし、この長さは、パケット転送を実行するときにわかっていると予想されます。
o Delta computation of the checksum from an encapsulated checksum field. Because the checksum is a cumulative sum [RFC1624], an encapsulating header checksum can be derived from the new pseudo-header, the inner checksum, and the sum of the other network-layer fields not included in the pseudo-header of the encapsulated packet, in a manner resembling incremental checksum update [RFC1141]. This would not require access to the whole packet, but does require fields to be collected across the header and arithmetic operations to be performed on each packet. The method would work only for packets that contain a 2's complement transport checksum (i.e., it would not be appropriate for SCTP or when IP fragmentation is used).
o カプセル化されたチェックサムフィールドからのチェックサムのデルタ計算。チェックサムは累積合計[RFC1624]であるため、カプセル化ヘッダーチェックサムは、新しい疑似ヘッダー、内部チェックサム、およびカプセル化されたパケットの疑似ヘッダーに含まれていない他のネットワーク層フィールドの合計から導出できます。 、増分チェックサム更新[RFC1141]に似た方法で。これにはパケット全体へのアクセスは必要ありませんが、ヘッダー全体でフィールドを収集し、各パケットで算術演算を実行する必要があります。この方法は、2の補数のトランスポートチェックサムを含むパケットに対してのみ機能します（つまり、SCTPやIPフラグメンテーションが使用されている場合は適切ではありません）。
o UDP has been modified to disable checksum processing (Zero UDP Checksum) [RFC6935]. This eliminates the need for a checksum calculation, but would require constraints on appropriate usage and updates to endpoints and middleboxes.
o UDPはチェックサム処理を無効にするように変更されました（ゼロUDPチェックサム）[RFC6935]。これにより、チェックサム計算の必要がなくなりますが、エンドポイントとミドルボックスへの適切な使用と更新に対する制約が必要になります。
o The proposed UDP Tunnel Transport [UDPTT] protocol suggested a method where UDP would be modified to derive the checksum only from the encapsulating packet protocol header. This value does not change between packets in a single flow. The value may be cached per flow/destination to minimize per-packet processing.
o 提案されたUDPトンネルトランスポート[UDPTT]プロトコルは、UDPがカプセル化パケットプロトコルヘッダーからのみチェックサムを取得するように変更される方法を提案しました。この値は、単一のフロー内のパケット間で変化しません。値は、パケットごとの処理を最小限に抑えるために、フロー/宛先ごとにキャッシュされます。
o A method has been proposed that uses a new (to-be-defined) IPv6 Destination Options Header to provide an end-to-end validation check at the network layer. This would allow an endpoint to verify delivery to an appropriate endpoint, but would also require IPv6 nodes to correctly handle the additional header and would require changes to middlebox behavior (e.g., when used with a NAT that always adjusts the checksum value).
o 新しい（未定義の）IPv6宛先オプションヘッダーを使用して、ネットワークレイヤーでエンドツーエンドの検証チェックを提供する方法が提案されています。これにより、エンドポイントは適切なエンドポイントへの配信を確認できますが、IPv6ノードが追加ヘッダーを正しく処理する必要があり、ミドルボックスの動作を変更する必要があります（たとえば、常にチェックサム値を調整するNATで使用する場合）。
o There has been a proposal to simply ignore the UDP checksum value on reception at the tunnel egress, allowing a tunnel ingress to insert any value, correct or false. For tunnel usage, a non-standard checksum value may be used, forcing an RFC 2460 receiver to drop the packet. The main downside is that it would be impossible to identify a UDP datagram (in the network or an endpoint) that is treated in this way compared to a packet that has actually been corrupted.
o トンネル出口での受信時にUDPチェックサム値を単に無視して、トンネル入口で任意の値（正しいまたはfalse）を挿入できるようにする提案がありました。トンネルを使用する場合は、非標準のチェックサム値を使用して、RFC 2460レシーバーにパケットをドロップさせることができます。主な欠点は、実際に破損したパケットと比較して、このように処理される（ネットワークまたはエンドポイント内の）UDPデータグラムを特定することが不可能になることです。
These options are compared and discussed further in the following sections.
これらのオプションは比較され、次のセクションでさらに説明されています。
This section compares the methods listed above to support datagram tunneling. It includes proposals for updating the behavior of UDP.
このセクションでは、データグラムトンネリングをサポートするために上記の方法を比較します。 UDPの動作を更新するための提案が含まれています。
While this comparison focuses on applications that are expected to execute on routers, the distinction between a router and a host is not always clear, especially at the transport level. Systems (such as UNIX-based operating systems) routinely provide both functions. From a received packet, there is no way to identify the role of the receiving node.
この比較は、ルーターで実行されることが予想されるアプリケーションに焦点を当てていますが、ルーターとホストの区別は、特にトランスポートレベルでは必ずしも明確ではありません。システム（UNIXベースのオペレーティングシステムなど）は、通常、両方の機能を提供します。受信したパケットから、受信ノードの役割を識別する方法はありません。
Regular UDP with a standard checksum or the delta-encoded optimization for creating correct checksums has the best possibility for successful traversal of a middlebox. No new support is required.
標準のチェックサムを備えた通常のUDP、または正しいチェックサムを作成するためのデルタエンコードされた最適化は、ミドルボックスのトラバーサルを成功させる可能性が最も高くなります。新しいサポートは必要ありません。
A method that ignores the UDP checksum on reception is expected to have a good probability of traversal, because most middleboxes perform an incremental checksum update. UDPTT would also be able to traverse a middlebox with this behavior. However, a middlebox on the path that attempts to verify a standard checksum will not forward packets using either of these methods, thus preventing traversal. A method that ignores the checksum has the additional downside that it prevents improvement of middlebox traversal, because there is no way to identify UDP datagrams that use the modified checksum behavior.
ほとんどのミドルボックスは増分チェックサム更新を実行するため、受信時にUDPチェックサムを無視する方法は、トラバーサルの可能性が高いと予想されます。 UDPTTは、この動作でミドルボックスをトラバースすることもできます。ただし、標準チェックサムを検証しようとするパス上のミドルボックスは、これらの方法のいずれかを使用してパケットを転送しないため、トラバーサルが防止されます。チェックサムを無視する方法には、変更されたチェックサム動作を使用するUDPデータグラムを識別する方法がないため、ミドルボックストラバーサルの改善を妨げるというマイナス面があります。
IP-in-IP or GRE tunnels offer good traversal of middleboxes that have not been designed for security, e.g., firewalls. However, firewalls may be expected to be configured to block general tunnels, because they present a large attack surface.
IP-in-IPまたはGREトンネルは、ファイアウォールなどのセキュリティ用に設計されていないミドルボックスを適切に通過できます。ただし、ファイアウォールは一般的なトンネルをブロックするように構成されている可能性があります。これは、ファイアウォールが大きな攻撃対象となるためです。
A new IPv6 Destination Options header will suffer traversal issues with middleboxes, especially firewalls and NATs, and will likely require them to be updated before the extension header is passed.
新しいIPv6宛先オプションヘッダーは、ミドルボックス、特にファイアウォールとNATのトラバーサルの問題に悩まされ、拡張ヘッダーが渡される前にそれらを更新する必要がある可能性があります。
Datagrams with a zero UDP checksum will not be passed by any middlebox that validates the checksum using RFC 2460 or updates the checksum field, such as NAT or firewalls. This would require an update to correctly handle a datagram with a zero UDP checksum.
UDPチェックサムがゼロのデータグラムは、RFC 2460を使用してチェックサムを検証したり、NATやファイアウォールなどのチェックサムフィールドを更新したりするミドルボックスには渡されません。これには、UDPチェックサムがゼロのデータグラムを正しく処理するための更新が必要です。
UDP-Lite will require an update of almost all types of middleboxes, because it requires support for a separate network-layer protocol number. Once enabled, the method to support incremental checksum updates would be identical to that for UDP, but different for checksum validation.
UDP-Liteは、別のネットワーク層プロトコル番号のサポートを必要とするため、ほとんどすべてのタイプのミドルボックスの更新が必要です。有効にすると、増分チェックサム更新をサポートする方法は、UDPの場合と同じですが、チェックサム検証では異なります。
The usefulness of solutions for load balancers depends on the difference in entropy in the headers for different flows that can be included in a hash function. All the proposals that use the UDP protocol number have equal behavior. UDP-Lite has the potential for behavior that is equally as good as UDP. However, UDP-Lite is currently unlikely to be supported by deployed hashing mechanisms, which could cause a load balancer not to use the transport header in the computed hash. A load balancer that uses only the IP header will have low entropy, but this could be improved by including the IPv6 the flow label, provided that the tunnel ingress ensures that different flow labels are assigned to different flows. However, a transition to the common use of good quality flow labels is likely to take time to deploy.
ロードバランサーのソリューションの有用性は、ハッシュ関数に含めることができるさまざまなフローのヘッダーのエントロピーの違いに依存します。 UDPプロトコル番号を使用するすべての提案は、同じ動作をします。 UDP-Liteには、UDPと同等の優れた動作の可能性があります。ただし、UDP-Liteは現在、デプロイされたハッシュメカニズムでサポートされている可能性が低く、ロードバランサーが計算されたハッシュでトランスポートヘッダーを使用しない可能性があります。 IPヘッダーのみを使用するロードバランサーはエントロピーが低くなりますが、トンネルの入口で異なるフローラベルが異なるフローに割り当てられることが保証されている場合、IPv6フローラベルを含めることでこれを改善できます。ただし、高品質のフローラベルの一般的な使用への移行は、展開に時間がかかる可能性があります。
IP-in-IP tunnels are often considered efficient, because they introduce very little processing and have low data overhead. The other proposals introduce a UDP-like header, which incurs an associated data overhead. Processing is minimized for the method that uses a zero UDP checksum and for the method that ignores the UDP checksum on reception, and processing is only slightly higher for UDPTT, the extension header, and UDP-Lite. The delta calculation scheme operates on a few more fields, but also introduces serious failure modes that can result in a need to calculate a checksum over the complete datagram. Regular UDP is clearly the most costly to process, always requiring checksum calculation over the entire datagram.
IP-in-IPトンネルは、処理がほとんどなく、データオーバーヘッドが低いため、効率的であると見なされることがよくあります。他の提案では、UDPのようなヘッダーが導入されており、これにより関連するデータオーバーヘッドが発生します。ゼロUDPチェックサムを使用するメソッドと受信時にUDPチェックサムを無視するメソッドの処理は最小限に抑えられ、UDPTT、拡張ヘッダー、およびUDP-Liteの処理はわずかに高くなります。デルタ計算スキームは、さらにいくつかのフィールドで動作しますが、データグラム全体でチェックサムを計算する必要が生じる可能性のある深刻な障害モードも導入します。通常のUDPは明らかに処理コストが最も高く、常にデータグラム全体のチェックサム計算が必要です。
It is important to note that the zero UDP checksum method, ignoring checksum on reception, the Option Header, UDPTT, and UDP-Lite will likely incur additional complexities in the application to incorporate a negotiation and validation mechanism.
受信時のチェックサムを無視するゼロUDPチェックサム方式、オプションヘッダー、UDPTT、およびUDP-Liteでは、ネゴシエーションおよび検証メカニズムを組み込むために、アプリケーションがさらに複雑になる可能性があることに注意することが重要です。
The major factors influencing deployability of these solutions are a need to update both endpoints, a need for negotiation, and the need to update middleboxes. These are summarized below:
これらのソリューションの展開可能性に影響を与える主な要因は、両方のエンドポイントを更新する必要性、交渉の必要性、およびミドルボックスを更新する必要性です。これらを以下にまとめます。
o The solution with the best deployability is regular UDP. This requires no changes and has good middlebox traversal characteristics.
o 展開性が最も高いソリューションは、通常のUDPです。これは変更を必要とせず、優れたミドルボックストラバーサル特性を備えています。
o The next easiest to deploy is the delta checksum solution. This does not modify the protocol on the wire and needs changes only in the tunnel ingress.
o 次に導入が最も簡単なのは、デルタチェックサムソリューションです。これは回線上のプロトコルを変更せず、トンネルの入口でのみ変更が必要です。
o IP-in-IP tunnels should not require changes to the endpoints, but they raise issues regarding the traversal of firewalls and other security devices, which are expected to require updates.
o IP-in-IPトンネルは、エンドポイントへの変更を必要としないはずですが、ファイアウォールやその他のセキュリティデバイスの通過に関する問題が発生します。これらは更新が必要になると予想されます。
o Ignoring the checksum on reception will require changes at both endpoints. The never-ceasing risk of path failure requires additional checks to ensure that this solution is robust, and it will require changes or additions to the tunnel control protocol to negotiate support and validate the path.
o 受信時にチェックサムを無視するには、両方のエンドポイントで変更が必要になります。パスの失敗という絶え間ないリスクでは、このソリューションが堅牢であることを確認するために追加のチェックが必要であり、サポートをネゴシエートしてパスを検証するには、トンネル制御プロトコルに変更または追加が必要になります。
o The remaining solutions (including the zero UDP checksum method) offer similar deployability. UDP-Lite requires support at both endpoints and in middleboxes. UDPTT and the zero UDP checksum method, with or without an extension header, require support at both endpoints and in middleboxes. UDP-Lite, UDPTT, and the zero UDP checksum method and the use of extension headers may also require changes or additions to the tunnel control protocol to negotiate support and path validation.
o残りのソリューション（ゼロUDPチェックサム方式を含む）は、同様の展開可能性を提供します。 UDP-Liteは、エンドポイントとミドルボックスの両方でのサポートを必要とします。 UDPTTとゼロUDPチェックサム方式は、拡張ヘッダーの有無にかかわらず、エンドポイントとミドルボックスの両方でサポートが必要です。 UDP-Lite、UDPTT、およびゼロUDPチェックサム方式と拡張ヘッダーの使用では、サポートとパスの検証をネゴシエートするために、トンネル制御プロトコルに変更または追加が必要になる場合もあります。
The standard UDP checksum and the delta checksum can both provide some verification at the tunnel egress. This can significantly reduce the probability that a corrupted inner packet is forwarded. UDP-Lite, UDPTT, and the extension header all provide some verification against corruption, but they do not verify the inner packet. They provide only a strong indication that the delivered packet was intended for the tunnel egress and was correctly delimited.
標準のUDPチェックサムとデルタチェックサムはどちらも、トンネルの出口である程度の検証を行うことができます。これにより、破損した内部パケットが転送される確率を大幅に削減できます。 UDP-Lite、UDPTT、および拡張ヘッダーはすべて、破損に対する何らかの検証を提供しますが、内部パケットは検証しません。これらは、配信されたパケットがトンネルの出口を対象としており、正しく区切られていたことを示す強力な指標のみを提供します。
The methods using a zero UDP checksum, ignoring the UDP checksum on reception, and IP-and-IP encapsulation all provide no verification that a received datagram was intended to be processed by a specific tunnel egress or that the inner encapsulated packet was correct. Section 3.1 discusses experience using specific protocols in well-managed networks.
ゼロUDPチェックサムを使用する方法、受信時にUDPチェックサムを無視する方法、およびIPおよびIPカプセル化はすべて、受信したデータグラムが特定のトンネル出口によって処理されることを意図していたこと、または内部のカプセル化されたパケットが正しいことの検証を提供しません。セクション3.1では、適切に管理されたネットワークで特定のプロトコルを使用した経験について説明します。
The comparisons above may be summarized as, "there is no silver bullet that will slay all the issues". One has to select which downsides can best be lived with. Focusing on the existing solutions, they can be summarized as:
上記の比較は、「すべての問題を解決する特効薬はありません」と要約できます。 1つは、どの欠点に耐えられるかを選択する必要があります。既存のソリューションに焦点を当てると、それらは次のように要約できます。
Regular UDP: The method defined in RFC 2460 has good middlebox traversal and load balancing and multiplexing, and requires a checksum in the outer headers to cover the whole packet.
通常のUDP：RFC 2460で定義されている方法は、ミドルボックストラバーサルとロードバランシングおよび多重化に優れており、パケット全体をカバーするために外部ヘッダーにチェックサムが必要です。
IP-in-IP: A low-complexity encapsulation that has limited middlebox traversal, no multiplexing support, and poor load-balancing support that could improve over time.
IP-in-IP：ミドルボックストラバーサルが制限され、多重化のサポートがなく、時間の経過とともに改善する可能性のあるロードバランシングサポートが不十分な、複雑度の低いカプセル化。
UDP-Lite: A medium-complexity encapsulation that has good multiplexing support, limited middlebox traversal that may possibly improve over time, and poor load-balancing support that could improve over time, and that, in most cases, requires application-level negotiation to select the protocol and validation to confirm that the path forwards UDP-Lite.
UDP-Lite：中程度の複雑さのカプセル化。良好な多重化サポート、時間の経過とともに改善される可能性のあるミドルボックストラバーサルの制限、および時間の経過とともに改善される可能性のある不十分なロードバランシングサポートがあり、ほとんどの場合、アプリケーションレベルのネゴシエーションが必要です。プロトコルと検証を選択して、パスがUDP-Liteを転送することを確認します。
Delta computation of a tunnel checksum: The delta checksum is an optimization in the processing of UDP, and, as such, it exhibits some of the drawbacks of using regular UDP.
トンネルチェックサムのデルタ計算：デルタチェックサムは、UDPの処理における最適化であるため、通常のUDPを使用する場合のいくつかの欠点を示します。
The remaining proposals may be described in similar terms:
残りの提案は、同様の用語で説明できます。
Zero Checksum: A low-complexity encapsulation that has good multiplexing support, limited middlebox traversal that could improve over time, and good load-balancing support, and that, in most cases, requires application-level negotiation and validation to confirm that the path forwards a zero UDP checksum.
ゼロチェックサム：多重化のサポート、時間の経過とともに改善できるミドルボックストラバーサルの制限、およびロードバランシングのサポートが良好で、ほとんどの場合、パスが転送されることを確認するためにアプリケーションレベルのネゴシエーションと検証が必要な、複雑性の低いカプセル化ゼロUDPチェックサム。
UDPTT: A medium-complexity encapsulation that has good multiplexing support, limited middlebox traversal that may possibly improve over time, and good load-balancing support, and that, in most cases, requires application-level negotiation to select the transport and validation to confirm the path forwards UDPTT datagrams.
UDPTT：中程度の複雑さのカプセル化。優れた多重化サポート、時間の経過とともに改善される可能性のあるミドルボックストラバーサルが制限されており、優れたロードバランシングサポートがあり、ほとんどの場合、確認のためにトランスポートと検証を選択するためにアプリケーションレベルのネゴシエーションが必要です。パスはUDPTTデータグラムを転送します。
IPv6 Destination Option IP-in-IP Tunneling: A medium-complexity encapsulation that has no multiplexing support, limited middlebox traversal, and poor load-balancing support that could improve over time, and that, in most cases, requires negotiation to confirm that the option is supported and validation to confirm the path forwards the option.
IPv6宛先オプションIP-in-IPトンネリング：中程度の複雑さのカプセル化。多重化サポートがなく、ミドルボックストラバーサルが制限されており、時間の経過とともに改善される可能性のある不十分なロードバランシングサポートがあり、ほとんどの場合、オプションがサポートされ、パスがオプションを転送することを確認するための検証。
IPv6 Destination Option Combined with Zero UDP Checksum: A medium-complexity encapsulation that has good multiplexing support, limited load-balancing support that could improve over time, and that, in most cases, requires negotiation to confirm the option is supported and validation to confirm the path forwards the option.
ゼロUDPチェックサムと組み合わせたIPv6宛先オプション：良好な多重化サポート、時間の経過とともに改善される可能性のある限定的なロードバランシングサポートがあり、ほとんどの場合、オプションがサポートされていることを確認するためのネゴシエーションと確認のための検証が必要な中複雑度のカプセル化パスはオプションを転送します。
Ignore the Checksum on Reception: A low-complexity encapsulation that has good multiplexing support, medium middlebox traversal that can never improve, and good load-balancing support, and that, in most cases, requires negotiation to confirm that the option is supported by the remote endpoint and validation to confirm the path forwards a zero UDP checksum.
受信時のチェックサムを無視：良好な多重化サポート、改善できない中程度のミドルボックストラバーサル、および優れたロードバランシングサポートを備えた複雑度の低いカプセル化。ほとんどの場合、オプションがサポートされていることを確認するために交渉が必要です。パスを確認するためのリモートエンドポイントと検証では、UDPチェックサムがゼロで転送されます。
There is no clear single optimum solution. If the most important need is to traverse middleboxes, the best choice is to stay with regular UDP and consider the optimizations that may be required to perform the checksumming. If one can live with limited middlebox traversal, if low complexity is necessary, and one does not require load balancing, IP-in-IP tunneling is the simplest. If one wants strengthened error detection, but with the currently limited middlebox traversal and load balancing, UDP-Lite is appropriate. Zero UDP checksum addresses another set of constraints: low complexity and a need for load balancing from the current Internet, provided that the usage can accept the currently limited support for middlebox traversal.
明確な単一の最適解はありません。ミドルボックスを全探索することが最も重要な必要である場合、最良の選択は、通常のUDPを維持し、チェックサムの実行に必要となる可能性のある最適化を検討することです。ミドルボックストラバーサルが制限された状態で生活でき、複雑さが低いことが必要で、負荷分散が不要な場合は、IP-in-IPトンネリングが最も簡単です。エラー検出を強化したいが、ミドルボックストラバーサルとロードバランシングが現在制限されている場合は、UDP-Liteが適しています。ゼロUDPチェックサムは、別の一連の制約に対処します。使用量がミドルボックストラバーサルの現在制限されているサポートを受け入れることができる場合、複雑さが低く、現在のインターネットからの負荷分散が必要です。
Techniques for load balancing and middlebox traversal do continue to evolve. Over a long time, developments in load balancing have good potential to improve. This time horizon is long, because it requires both load balancer and endpoint updates to get full benefit. The challenges of middlebox traversal are also expected to change with time as device capabilities evolve. Middleboxes are very prolific, with a larger proportion of end user ownership, and therefore may be expected to take a long time to evolve.
ロードバランシングとミドルボックストラバーサルの手法は進化し続けています。長い間、負荷分散の開発には改善の余地があります。ロードバランサーとエンドポイントの両方の更新を十分に活用する必要があるため、この期間は長いです。ミドルボックストラバーサルの課題は、デバイスの機能が進化するにつれて、時間とともに変化することが予想されます。ミドルボックスは非常に多用であり、エンドユーザーの所有権の割合が高いため、進化するまでに長い時間がかかることが予想されます。
However, we note that the deployment of IPv6-capable middleboxes is still in its initial phase, and if a new method becomes standardized quickly, fewer boxes will be non-compliant.
ただし、IPv6対応のミドルボックスの導入はまだ初期段階であり、新しい方法がすぐに標準化されるようになれば、非準拠のボックスは少なくなります。
Thus, the question of whether to permit use of datagrams with a zero UDP checksum for IPv6 under reasonable constraints is best viewed as a trade-off among a number of more subjective questions:
したがって、妥当な制約のもとでIPv6のUDPチェックサムがゼロのデータグラムの使用を許可するかどうかの質問は、より主観的な多くの質問の間のトレードオフと見なすのが最善です。
o Is there sufficient interest in using a zero UDP checksum with the given constraints (summarized below)?
o 与えられた制約（以下に要約）でゼロUDPチェックサムを使用することに十分な関心がありますか？
o Are there other avenues of change that will resolve the issue in a better way and sufficiently quickly ?
o より良い方法で十分に迅速に問題を解決する変更の他の手段はありますか？
o Do we accept the complexity cost of having one more solution in the future?
o 将来的にもう1つのソリューションを導入することによる複雑さのコストを受け入れますか？
The analysis concludes that the IETF should carefully consider constraints on sanctioning the use of any new transport mode. The 6man working group of the IETF has determined that the answers to the above questions are sufficient to update IPv6 to standardize use of a zero UDP checksum for use by tunnel encapsulations for specific applications.
分析は、IETFが新しいトランスポートモードの使用を認可する際の制約を慎重に検討する必要があると結論付けています。 IETFの6manワーキンググループは、特定のアプリケーションのトンネルカプセル化で使用するゼロUDPチェックサムの使用を標準化するためにIPv6を更新するには、上記の質問に対する回答で十分であると判断しました。
Each application should consider the implications of choosing an IPv6 transport that uses a zero UDP checksum. In many cases, standard methods may be more appropriate and may simplify application design. The use of checksum off-loading may help alleviate the checksum processing cost and permit use of a checksum using the method defined in RFC 2460.
各アプリケーションは、ゼロのUDPチェックサムを使用するIPv6トランスポートを選択することの影響を考慮する必要があります。多くの場合、標準的な方法の方が適切であり、アプリケーション設計を簡素化します。チェックサムオフロードを使用すると、チェックサムの処理コストを軽減し、RFC 2460で定義されている方法を使用してチェックサムを使用できるようになります。
Authors' Addresses
著者のアドレス
Godred Fairhurst University of Aberdeen School of Engineering Aberdeen, AB24 3UE Scotland, UK
Godred Fairhurst University of Aberdeen School of Engineeringアバディーン、AB24 3UEスコットランド、英国
EMail: gorry@erg.abdn.ac.uk
URI: http://www.erg.abdn.ac.uk/users/gorry
Magnus Westerlund Ericsson Farogatan 6 Stockholm, SE-164 80 Sweden
Magnus Westerlund Ericsson Farogatan 6ストックホルム、SE-164 80スウェーデン
Phone: +46 8 719 0000
EMail: magnus.westerlund@ericsson.com