[要約] RFC 8086は、GREパケットをUDPでカプセル化する方法を定義しています。その目的は、ネットワーク上でのGREトラフィックの可用性と相互運用性を向上させることです。
Internet Engineering Task Force (IETF) L. Yong, Ed.
Request for Comments: 8086 Huawei Technologies
Category: Standards Track E. Crabbe
ISSN: 2070-1721 Oracle
X. Xu
Huawei Technologies
T. Herbert
Facebook
March 2017
GRE-in-UDP Encapsulation
GRE-in-UDPカプセル化
Abstract
概要
This document specifies a method of encapsulating network protocol packets within GRE and UDP headers. This GRE-in-UDP encapsulation allows the UDP source port field to be used as an entropy field. This may be used for load-balancing of GRE traffic in transit networks using existing Equal-Cost Multipath (ECMP) mechanisms. There are two applicability scenarios for GRE-in-UDP with different requirements: (1) general Internet and (2) a traffic-managed controlled environment. The controlled environment has less restrictive requirements than the general Internet.
このドキュメントでは、GREおよびUDPヘッダー内でネットワークプロトコルパケットをカプセル化する方法について説明します。このGRE-in-UDPカプセル化により、UDP送信元ポートフィールドをエントロピーフィールドとして使用できます。これは、既存の等価コストマルチパス（ECMP）メカニズムを使用するトランジットネットワークでのGREトラフィックのロードバランシングに使用できます。要件が異なるGRE-in-UDPには2つの適用シナリオがあります。（1）一般的なインターネットと（2）トラフィック管理された制御された環境です。制御された環境には、一般的なインターネットよりも制限の少ない要件があります。
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 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション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/rfc8086.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8086で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 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. Terminology ................................................5
1.2. Requirements Language ......................................5
2. Applicability Statement .........................................6
2.1. GRE-in-UDP Tunnel Requirements .............................6
2.1.1. Requirements for Default GRE-in-UDP Tunnel ..........7
2.1.2. Requirements for TMCE GRE-in-UDP Tunnel .............8
3. GRE-in-UDP Encapsulation ........................................9
3.1. IP Header .................................................11
3.2. UDP Header ................................................11
3.2.1. Source Port ........................................11
3.2.2. Destination Port ...................................11
3.2.3. Checksum ...........................................12
3.2.4. Length .............................................12
3.3. GRE Header ................................................12
4. Encapsulation Procedures .......................................13
4.1. MTU and Fragmentation .....................................13
4.2. Differentiated Services and ECN Marking ...................14
5. Use of DTLS ....................................................14
6. UDP Checksum Handling ..........................................15
6.1. UDP Checksum with IPv4 ....................................15
6.2. UDP Checksum with IPv6 ....................................15
7. Middlebox Considerations .......................................18
7.1. Middlebox Considerations for Zero Checksums ...............19
8. Congestion Considerations ......................................19
9. Backward Compatibility .........................................20
10. IANA Considerations ...........................................21
11. Security Considerations .......................................21
12. References ....................................................22
12.1. Normative References .....................................22
12.2. Informative References ...................................23
Acknowledgements ..................................................25
Contributors ......................................................25
Authors' Addresses ................................................27
This document specifies a generic GRE-in-UDP encapsulation for tunneling network protocol packets across an IP network based on Generic Routing Encapsulation (GRE) [RFC2784] [RFC7676] and User Datagram Protocol (UDP) [RFC768] headers. The GRE header indicates the payload protocol type via an EtherType [RFC7042] in the protocol type field, and the source port field in the UDP header may be used to provide additional entropy.
このドキュメントでは、Generic Routing Encapsulation（GRE）[RFC2784] [RFC7676]およびUser Datagram Protocol（UDP）[RFC768]ヘッダーに基づいて、IPネットワーク全体でネットワークプロトコルパケットをトンネリングするための一般的なGRE-in-UDPカプセル化について説明します。 GREヘッダーは、プロトコルタイプフィールドのEtherType [RFC7042]を介してペイロードプロトコルタイプを示し、UDPヘッダーの送信元ポートフィールドを使用して、追加のエントロピーを提供できます。
A GRE-in-UDP tunnel offers the possibility of better performance for load-balancing GRE traffic in transit networks using existing Equal-Cost Multipath (ECMP) mechanisms that use a hash of the five-tuple of source IP address, destination IP address, UDP/TCP source port, UDP/TCP destination port, and protocol number. While such hashing distributes UDP and TCP [RFC793] traffic between a common pair of IP addresses across paths, it uses a single path for corresponding GRE traffic because only the two IP addresses and the Protocol or Next Header field participate in the ECMP hash. Encapsulating GRE in UDP enables use of the UDP source port to provide entropy to ECMP hashing.
GRE-in-UDPトンネルは、送信元IPアドレス、宛先IPアドレスの5つのタプルのハッシュを使用する既存の等価コストマルチパス（ECMP）メカニズムを使用して、トランジットネットワークでGREトラフィックの負荷分散のパフォーマンスを向上させる可能性を提供します。 UDP / TCP送信元ポート、UDP / TCP宛先ポート、およびプロトコル番号。このようなハッシュでは、UDPおよびTCP [RFC793]トラフィックが共通のIPアドレスペア間でパス全体に分散されますが、ECMPハッシュには2つのIPアドレスとプロトコルまたは次のヘッダーフィールドのみが関与するため、対応するGREトラフィックには単一のパスが使用されます。 UDPでGREをカプセル化すると、UDP送信元ポートを使用して、ECMPハッシュにエントロピーを提供できます。
In addition, GRE-in-UDP enables extending use of GRE across networks that otherwise disallow it; for example, GRE-in-UDP may be used to bridge two islands where GRE is not supported natively across the middleboxes.
さらに、GRE-in-UDPを使用すると、GREの使用をネットワーク全体に拡張できます。たとえば、GRE-in-UDPは、GREがミドルボックス全体でネイティブにサポートされていない2つのアイランドをブリッジするために使用できます。
GRE-in-UDP encapsulation may be used to encapsulate already tunneled traffic, i.e., tunnel-in-tunnel traffic. In this case, GRE-in-UDP tunnels treat the endpoints of the outer tunnel as the end hosts; the presence of an inner tunnel does not change the outer tunnel's handling of network traffic.
GRE-in-UDPカプセル化は、すでにトンネル化されたトラフィック、つまりトンネルイントンネルトラフィックをカプセル化するために使用できます。この場合、GRE-in-UDPトンネルは、外部トンネルのエンドポイントをエンドホストとして扱います。内部トンネルが存在しても、外部トンネルのネットワークトラフィックの処理は変わりません。
A GRE-in-UDP tunnel is capable of carrying arbitrary traffic and behaves as a UDP application on an IP network. However, a GRE-in-UDP tunnel carrying certain types of traffic does not satisfy the requirements for UDP applications on the Internet [RFC8085]. GRE-in-UDP tunnels that do not satisfy these requirements MUST NOT be deployed to carry such traffic over the Internet. For this reason, this document specifies two deployment scenarios for GRE-in-UDP tunnels with GRE-in-UDP tunnel requirements for each of them: (1) general Internet and (2) a traffic-managed controlled environment (TMCE). Compared to the general Internet scenario, the TMCE scenario has less restrictive technical requirements for the protocol but more restrictive management and operation requirements for the network.
GRE-in-UDPトンネルは、任意のトラフィックを伝送でき、IPネットワーク上のUDPアプリケーションとして動作します。ただし、特定のタイプのトラフィックを伝送するGRE-in-UDPトンネルは、インターネット上のUDPアプリケーションの要件を満たしていません[RFC8085]。これらの要件を満たさないGRE-in-UDPトンネルは、インターネット上でそのようなトラフィックを伝送するために展開してはなりません。このため、このドキュメントでは、GRE-in-UDPトンネルの2つの展開シナリオを、それぞれにGRE-in-UDPトンネル要件を指定しています。（1）一般的なインターネットと（2）トラフィック管理の制御環境（TMCE）。一般的なインターネットシナリオと比較して、TMCEシナリオでは、プロトコルの技術要件はそれほど制限されていませんが、ネットワークの管理および運用要件はより制限されています。
To provide security for traffic carried by a GRE-in-UDP tunnel, this document also specifies Datagram Transport Layer Security (DTLS) for GRE-in-UDP tunnels, which SHOULD be used when security is a concern.
GRE-in-UDPトンネルによって伝送されるトラフィックにセキュリティを提供するために、このドキュメントでは、GRE-in-UDPトンネルのデータグラムトランスポート層セキュリティ（DTLS）も指定しています。これは、セキュリティが懸念される場合に使用する必要があります。
GRE-in-UDP encapsulation usage requires no changes to the transit IP network. ECMP hash functions in most existing IP routers may utilize and benefit from the additional entropy enabled by GRE-in-UDP tunnels without any change or upgrade to their ECMP implementation. The encapsulation mechanism is applicable to a variety of IP networks including Data Center Networks and Wide Area Networks, as well as both IPv4 and IPv6 networks.
GRE-in-UDPカプセル化の使用では、トランジットIPネットワークを変更する必要はありません。ほとんどの既存のIPルーターのECMPハッシュ機能は、GRE-in-UDPトンネルによって有効化される追加のエントロピーを利用し、ECMP実装を変更またはアップグレードせずに利用できます。カプセル化メカニズムは、データセンターネットワークや広域ネットワークなどのさまざまなIPネットワーク、およびIPv4ネットワークとIPv6ネットワークの両方に適用できます。
The terms defined in [RFC768] and [RFC2784] are used in this document. Below are additional terms used in this document.
このドキュメントでは、[RFC768]および[RFC2784]で定義されている用語が使用されています。以下は、このドキュメントで使用される追加の用語です。
Decapsulator: a component performing packet decapsulation at tunnel egress.
カプセル開放装置：トンネルの出口でパケットのカプセル開放を実行するコンポーネント。
ECMP: Equal-Cost Multipath.
ECMP：等コストマルチパス。
Encapsulator: a component performing packet encapsulation at tunnel egress.
カプセル化装置：トンネルの出口でパケットのカプセル化を実行するコンポーネント。
Flow Entropy: The information to be derived from traffic or applications and to be used by network devices in the ECMP process [RFC6438].
フローエントロピー：トラフィックまたはアプリケーションから取得され、ネットワークデバイスがECMPプロセスで使用する情報[RFC6438]。
Default GRE-in-UDP Tunnel: A GRE-in-UDP tunnel that can apply to the general Internet.
デフォルトのGRE-in-UDPトンネル：一般的なインターネットに適用できるGRE-in-UDPトンネル。
TMCE: A traffic-managed controlled environment, i.e., an IP network that is traffic-engineered and/or otherwise managed (e.g., via use of traffic rate limiters) to avoid congestion, as defined in Section 2.
TMCE：トラフィック管理された制御された環境、つまり、セクション2で定義されているように、輻輳を回避するために（たとえば、トラフィックレートリミッターを使用して）トラフィックエンジニアリングまたはその他の方法で管理されたIPネットワーク。
TMCE GRE-in-UDP Tunnel: A GRE-in-UDP tunnel that can only apply to a traffic-managed controlled environment that is defined in Section 2.
TMCE GRE-in-UDPトンネル：セクション2で定義されているトラフィック管理された制御された環境にのみ適用できるGRE-in-UDPトンネル。
Tunnel Egress: A tunnel endpoint that performs packet decapsulation.
トンネル出口：パケットのカプセル化解除を実行するトンネルエンドポイント。
Tunnel Ingress: A tunnel endpoint that performs packet encapsulation.
トンネル入力：パケットのカプセル化を実行するトンネルエンドポイント。
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]で説明されているように解釈されます。
GRE-in-UDP encapsulation applies to IPv4 and IPv6 networks; in both cases, encapsulated packets are treated as UDP datagrams. Therefore, a GRE-in-UDP tunnel needs to meet the UDP usage requirements specified in [RFC8085]. These requirements depend on both the delivery network and the nature of the encapsulated traffic. For example, the GRE-in-UDP tunnel protocol does not provide any congestion control functionality beyond that of the encapsulated traffic. Therefore, a GRE-in-UDP tunnel MUST be used only with congestion-controlled traffic (e.g., IP unicast traffic) and/or within a network that is traffic managed to avoid congestion.
GRE-in-UDPカプセル化は、IPv4およびIPv6ネットワークに適用されます。どちらの場合も、カプセル化されたパケットはUDPデータグラムとして扱われます。したがって、GRE-in-UDPトンネルは、[RFC8085]で指定されているUDP使用要件を満たす必要があります。これらの要件は、配信ネットワークとカプセル化されたトラフィックの性質の両方に依存します。たとえば、GRE-in-UDPトンネルプロトコルは、カプセル化されたトラフィックを超える輻輳制御機能を提供しません。したがって、GRE-in-UDPトンネルは、輻輳が制御されたトラフィック（IPユニキャストトラフィックなど）でのみ、および/または輻輳を回避するためにトラフィックが管理されているネットワーク内でのみ使用する必要があります。
[RFC8085] describes two applicability scenarios for UDP applications: (1) general internet and (2) a controlled environment. The controlled environment means a single administrative domain or bilaterally agreed connection between domains. A network forming a controlled environment can be managed/operated to meet certain conditions, while the general Internet cannot be; thus, the requirements for a tunnel protocol operating under a controlled environment can be less restrictive than the requirements in the general Internet.
[RFC8085]は、UDPアプリケーションの2つの適用シナリオを説明しています：（1）一般的なインターネットと（2）制御された環境。制御された環境とは、単一の管理ドメイン、またはドメイン間で相互に合意した接続を意味します。管理された環境を形成するネットワークは、特定の条件を満たすように管理/運用できますが、一般的なインターネットはできません。したがって、制御された環境で動作するトンネルプロトコルの要件は、一般的なインターネットの要件よりも制限が緩くなります。
For the purpose of this document, a traffic-managed controlled environment (TMCE) is defined as an IP network that is traffic-engineered and/or otherwise managed (e.g., via use of traffic rate limiters) to avoid congestion.
このドキュメントの目的上、トラフィック管理された制御環境（TMCE）は、輻輳を回避するために（たとえば、トラフィックレートリミッターを使用して）トラフィックエンジニアリングまたはその他の方法で管理されるIPネットワークとして定義されます。
This document specifies GRE-in-UDP tunnel usage in the general Internet and GRE-in-UDP tunnel usage in a traffic-managed controlled environment and uses "default GRE-in-UDP tunnel" and "TMCE GRE-in-UDP tunnel" terms to refer to each usage.
このドキュメントでは、一般的なインターネットでのGRE-in-UDPトンネルの使用法と、トラフィック管理された制御環境でのGRE-in-UDPトンネルの使用法を指定し、「デフォルトのGRE-in-UDPトンネル」と「TMCE GRE-in-UDPトンネル」を使用します。各使用法を指す用語。
NOTE: Although this document specifies two different sets of GRE-in-UDP tunnel requirements based on tunnel usage, the tunnel implementation itself has no ability to detect how and where it is deployed. Therefore, it is the responsibility of the user or operator who deploys a GRE-in-UDP tunnel to ensure that it meets the appropriate requirements.
注：このドキュメントでは、トンネルの使用に基づいて2つの異なるGRE-in-UDPトンネル要件のセットを指定していますが、トンネルの実装自体には、どのように、どこに配置されているかを検出する機能はありません。したがって、GRE-in-UDPトンネルを展開するユーザーまたはオペレーターは、適切な要件を確実に満たすようにする必要があります。
This section states the requirements for a GRE-in-UDP tunnel. Section 2.1.1 describes the requirements for a default GRE-in-UDP tunnel that is suitable for the general Internet; Section 2.1.2 describes a set of relaxed requirements for a TMCE GRE-in-UDP tunnel used in a traffic-managed controlled environment. Both Sections 2.1.1 and 2.1.2 are applicable to an IPv4 or IPv6 delivery network.
このセクションでは、GRE-in-UDPトンネルの要件について説明します。セクション2.1.1では、一般的なインターネットに適したデフォルトのGRE-in-UDPトンネルの要件について説明します。セクション2.1.2では、トラフィック管理された制御された環境で使用されるTMCE GRE-in-UDPトンネルの一連の緩和された要件について説明します。セクション2.1.1と2.1.2の両方がIPv4またはIPv6配信ネットワークに適用されます。
The following is a summary of the default GRE-in-UDP tunnel requirements:
次に、デフォルトのGRE-in-UDPトンネル要件の概要を示します。
1. A UDP checksum SHOULD be used when encapsulating in IPv4.
1. IPv4でカプセル化する場合は、UDPチェックサムを使用する必要があります（SHOULD）。
2. A UDP checksum MUST be used when encapsulating in IPv6.
2. IPv6でカプセル化する場合は、UDPチェックサムを使用する必要があります。
3. GRE-in-UDP tunnel MUST NOT be deployed or configured to carry traffic that is not congestion controlled. As stated in [RFC8085], IP-based unicast traffic is generally assumed to be congestion controlled, i.e., it is assumed that the transport protocols generating IP-based traffic at the sender already employ mechanisms that are sufficient to address congestion on the path. A default GRE-in-UDP tunnel is not appropriate for traffic that is not known to be congestion controlled (e.g., most IP multicast traffic).
3. GRE-in-UDPトンネルは、輻輳制御されていないトラフィックを伝送するように展開または構成してはなりません（MUST NOT）。 [RFC8085]で述べられているように、IPベースのユニキャストトラフィックは一般に輻輳制御されていると想定されます。つまり、送信元でIPベースのトラフィックを生成するトランスポートプロトコルは、パス上の輻輳に対処するのに十分なメカニズムをすでに採用していると想定されます。デフォルトのGRE-in-UDPトンネルは、輻輳制御されていることがわかっていないトラフィック（たとえば、ほとんどのIPマルチキャストトラフィック）には適していません。
4. UDP source port values that are used as a source of flow entropy SHOULD be chosen from the ephemeral port range (49152-65535) [RFC8085].
4. フローエントロピーのソースとして使用されるUDPソースポートの値は、エフェメラルポート範囲（49152-65535）[RFC8085]から選択する必要があります（SHOULD）。
5. The use of the UDP source port MUST be configurable so that a single value can be set for all traffic within the tunnel (this disables use of the UDP source port to provide flow entropy). When a single value is set, a random port taken from the ephemeral port range SHOULD be selected in order to minimize the vulnerability to off-path attacks [RFC6056].
5. トンネル内のすべてのトラフィックに単一の値を設定できるように、UDPソースポートの使用を構成可能にする必要があります（これにより、UDPソースポートを使用してフローエントロピーを提供できなくなります）。単一の値が設定されている場合、オフパス攻撃に対する脆弱性を最小限に抑えるために、エフェメラルポート範囲から取得されたランダムなポートを選択する必要があります[RFC6056]。
6. For IPv6 delivery networks, the flow entropy SHOULD also be placed in the flow label field for ECMP per [RFC6438].
6. IPv6配信ネットワークの場合、[RFC6438]に従ってECMPのフローラベルフィールドにもフローエントロピーを配置する必要があります（SHOULD）。
7. At the tunnel ingress, any fragmentation of the incoming packet (e.g., because the tunnel has a Maximum Transmission Unit (MTU) that is smaller than the packet) SHOULD be performed before encapsulation. In addition, the tunnel ingress MUST apply the UDP checksum to all encapsulated fragments so that the tunnel egress can validate reassembly of the fragments; it MUST set the same Differentiated Services Code Point (DSCP) value as in the Differentiated Services (DS) field of the payload packet in all fragments [RFC2474]. To avoid unwanted forwarding over multiple paths, the same source UDP port value SHOULD be set in all packet fragments.
7. トンネルの入口では、着信パケットの断片化（たとえば、トンネルのMTU（Maximum Transmission Unit）がパケットよりも小さいため）は、カプセル化の前に実行する必要があります（SHOULD）。さらに、トンネルの出口はフラグメントの再構成を検証できるように、トンネルの入口はすべてのカプセル化されたフラグメントにUDPチェックサムを適用する必要があります。すべてのフラグメント[RFC2474]のペイロードパケットのDifferentiated Services（DS）フィールドと同じDiffServコードポイント（DSCP）値を設定する必要があります。複数のパスを介した不要な転送を回避するために、同じ送信元UDPポート値をすべてのパケットフラグメントに設定する必要があります（SHOULD）。
The section contains the TMCE GRE-in-UDP tunnel requirements. It lists the changed requirements, compared with a Default GRE-in-UDP tunnel, for a TMCE GRE-in-UDP tunnel, which corresponds to requirements 1-3 listed in Section 2.1.1.
このセクションには、TMCE GRE-in-UDPトンネルの要件が含まれています。デフォルトのGRE-in-UDPトンネルと比較して、TMCE GRE-in-UDPトンネルのセクション2.1.1にリストされている要件1〜3に対応する、変更された要件を示しています。
1. A UDP checksum SHOULD be used when encapsulating in IPv4. A tunnel endpoint sending GRE-in-UDP MAY disable the UDP checksum, since GRE has been designed to work without a UDP checksum [RFC2784]. However, a checksum also offers protection from misdelivery to another port.
1. IPv4でカプセル化する場合は、UDPチェックサムを使用する必要があります（SHOULD）。 GREがUDPチェックサムなしで機能するように設計されているため[RFC2784]、GRE-in-UDPを送信するトンネルエンドポイントはUDPチェックサムを無効にする場合があります。ただし、チェックサムは、別のポートへの誤配信からの保護も提供します。
2. Use of the UDP checksum MUST be the default when encapsulating in IPv6. This default MAY be overridden via configuration of UDP zero-checksum mode. All usage of UDP zero-checksum mode with IPv6 is subject to the additional requirements specified in Section 6.2.
2. IPv6でカプセル化するときは、UDPチェックサムをデフォルトで使用する必要があります。このデフォルトは、UDPゼロチェックサムモードの構成を介してオーバーライドされる場合があります。 IPv6でのUDPゼロチェックサムモードのすべての使用には、セクション6.2で指定された追加要件が適用されます。
3. A GRE-in-UDP tunnel MAY encapsulate traffic that is not congestion controlled.
3. GRE-in-UDPトンネルは、輻輳制御されていないトラフィックをカプセル化してもよい（MAY）。
Requirements 4-7 listed in Section 2.1.1 also apply to a TMCE GRE-in-UDP tunnel.
セクション2.1.1にリストされている要件4〜7は、TMCE GRE-in-UDPトンネルにも適用されます。
The GRE-in-UDP encapsulation format contains a UDP header [RFC768] and a GRE header [RFC2890]. The format is shown as follows (presented in bit order):
GRE-in-UDPカプセル化形式には、UDPヘッダー[RFC768]とGREヘッダー[RFC2890]が含まれています。形式は次のとおりです（ビット順で表示）。
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
０ １ ２ ３ ０ １ ２ ３ ４ ５ ６ ７ ８ ９ ０ １ ２ ３ ４ ５ ６ ７ ８ ９ ０ １ ２ ３ ４ ５ ６ ７ ８ ９ ０ １
IPv4 Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Prot.=17(UDP) | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
UDP Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port = Entropy Value | Dest. Port = 4754/4755 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
GRE Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| |K|S| Reserved0 | Ver | Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum (optional) | Reserved1 (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: UDP + GRE Headers in IPv4
図1：IPv4のUDP + GREヘッダー
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
０ １ ２ ３ ０ １ ２ ３ ４ ５ ６ ７ ８ ９ ０ １ ２ ３ ４ ５ ６ ７ ８ ９ ０ １ ２ ３ ４ ５ ６ ７ ８ ９ ０ １
IPv6 Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | NxtHdr=17(UDP)| Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Outer Source IPv6 Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Outer Destination IPv6 Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
UDP Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port = entropy value | Dest. Port = 4754/4755 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
GRE Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| |K|S| Reserved0 | Ver | Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum (optional) | Reserved1 (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: UDP + GRE Headers in IPv6
図2：IPv6のUDP + GREヘッダー
The contents of the IP, UDP, and GRE headers that are relevant in this encapsulation are described below.
このカプセル化に関連するIP、UDP、およびGREヘッダーの内容を以下に示します。
An encapsulator MUST encode its own IP address as the source IP address and the decapsulator's IP address as the destination IP address. A sufficiently large value is needed in the IPv4 TTL field or IPv6 Hop Count field to allow delivery of the encapsulated packet to the peer of the encapsulation.
カプセル化装置は、自身のIPアドレスをソースIPアドレスとして、カプセル化解除装置のIPアドレスを宛先IPアドレスとしてエンコードする必要があります。カプセル化されたパケットをカプセル化のピアに配信できるようにするには、IPv4 TTLフィールドまたはIPv6ホップカウントフィールドに十分に大きな値が必要です。
GRE-in-UDP permits the UDP source port value to be used to encode an entropy value. The UDP source port contains a 16-bit entropy value that is generated by the encapsulator to identify a flow for the encapsulated packet. The port value SHOULD be within the ephemeral port range, i.e., 49152 to 65535, where the high-order two bits of the port are set to one. This provides fourteen bits of entropy for the inner flow identifier. In the case that an encapsulator is unable to derive flow entropy from the payload header or the entropy usage has to be disabled to meet operational requirements (see Section 7), to avoid reordering with a packet flow, the encapsulator SHOULD use the same UDP source port value for all packets assigned to a flow, e.g., the result of an algorithm that performs a hash of the tunnel ingress and egress IP address.
GRE-in-UDPでは、UDP送信元ポートの値を使用してエントロピー値をエンコードできます。 UDP送信元ポートには、カプセル化されたパケットのフローを識別するためにカプセル化プログラムによって生成される16ビットのエントロピー値が含まれています。ポート値は、エフェメラルポートの範囲内（49152〜65535）である必要があります（SHOULD）。ポートの上位2ビットは1に設定されています。これにより、内部フロー識別子に14ビットのエントロピーが提供されます。カプセル化装置がペイロードヘッダーからフローエントロピーを導出できない場合、または運用要件を満たすためにエントロピー使用を無効にする必要がある場合（セクション7を参照）、パケットフローでの再順序付けを回避するために、カプセル化装置は同じUDPソースを使用する必要があります（SHOULD）フローに割り当てられたすべてのパケットのポート値。たとえば、トンネルの入口と出口のIPアドレスのハッシュを実行するアルゴリズムの結果。
The source port value for a flow set by an encapsulator MAY change over the lifetime of the encapsulated flow. For instance, an encapsulator may change the assignment for Denial-of-Service (DoS) mitigation or as a means to effect routing through the ECMP network. An encapsulator SHOULD NOT change the source port selected for a flow more than once every thirty seconds.
カプセル化装置によって設定されたフローの送信元ポート値は、カプセル化されたフローの存続期間にわたって変化してもよい（MAY）。たとえば、カプセル化者は、サービス拒否（DoS）軽減の割り当てを変更したり、ECMPネットワークを介したルーティングを実行する手段として変更したりできます。カプセル化装置は、フローに選択された送信元ポートを30秒に1回以上変更してはなりません（SHOULD NOT）。
An IPv6 GRE-in-UDP tunnel endpoint SHOULD copy a flow entropy value in the IPv6 flow label field (requirement 6). This permits network equipment to inspect this value and utilize it during forwarding, e.g., to perform ECMP [RFC6438].
IPv6 GRE-in-UDPトンネルエンドポイントは、IPv6フローラベルフィールドにフローエントロピー値をコピーする必要があります（要件6）。これにより、ネットワーク機器はこの値を検査し、転送中にそれを利用して、たとえばECMP [RFC6438]を実行できます。
This document places requirements on the generation of the flow entropy value [RFC8085] but does not specify the algorithm that an implementation should use to derive this value.
このドキュメントでは、フローエントロピー値[RFC8085]の生成に関する要件を定めていますが、実装がこの値を導出するために使用する必要があるアルゴリズムを指定していません。
The destination port of the UDP header is set to either GRE-in-UDP (4754) or GRE-UDP-DTLS (4755); see Section 5.
UDPヘッダーの宛先ポートは、GRE-in-UDP（4754）またはGRE-UDP-DTLS（4755）に設定されます。セクション5を参照してください。
The UDP checksum is set and processed per [RFC768] and [RFC1122] for IPv4 and per [RFC2460] for IPv6. Requirements for checksum handling and use of zero UDP checksums are detailed in Section 6.
UDPチェックサムは、IPv4の場合は[RFC768]および[RFC1122]ごとに、IPv6の場合は[RFC2460]ごとに設定および処理されます。チェックサムの処理とゼロUDPチェックサムの使用の要件については、セクション6で詳しく説明します。
The usage of this field is in accordance with the current UDP specification in [RFC768]. This length will include the UDP header (eight bytes), GRE header, and the GRE payload (encapsulated packet).
このフィールドの使用法は、[RFC768]の現在のUDP仕様に準拠しています。この長さには、UDPヘッダー（8バイト）、GREヘッダー、およびGREペイロード（カプセル化されたパケット）が含まれます。
An encapsulator sets the protocol type (EtherType) of the packet being encapsulated in the GRE Protocol Type field.
カプセル化装置は、GREプロトコルタイプフィールドにカプセル化されるパケットのプロトコルタイプ（EtherType）を設定します。
An encapsulator MAY set the GRE Key Present, Sequence Number Present, and Checksum Present bits and associated fields in the GRE header as defined by [RFC2784] and [RFC2890]. Usage of the reserved bits, i.e., Reserved0, is specified in [RFC2784].
カプセル化者は、GREキーの存在、シーケンス番号の存在、チェックサムの存在のビットと、[RFC2784]と[RFC2890]で定義されているGREヘッダーの関連フィールドを設定してもよい（MAY）。予約ビットの使用、つまりReserved0は、[RFC2784]で指定されています。
The GRE checksum MAY be enabled to protect the GRE header and payload. When the UDP checksum is enabled, it protects the GRE payload, resulting in the GRE checksum being mostly redundant. Enabling both checksums may result in unnecessary processing. Since the UDP checksum covers the pseudo-header and the packet payload, including the GRE header and its payload, the UDP checksum SHOULD be used in preference to the GRE checksum.
GREチェックサムは、GREヘッダーとペイロードを保護するために有効化される場合があります。 UDPチェックサムを有効にすると、GREペイロードが保護され、GREチェックサムがほとんど冗長になります。両方のチェックサムを有効にすると、不要な処理が発生する可能性があります。 UDPチェックサムは、GREヘッダーとそのペイロードを含む疑似ヘッダーとパケットペイロードをカバーするため、GREチェックサムよりもUDPチェックサムを使用する必要があります（SHOULD）。
An implementation MAY use the GRE Key field to authenticate the encapsulator. (See the Security Considerations section.) In this model, a shared value is either configured or negotiated between an encapsulator and decapsulator. When a decapsulator determines that a presented key is not valid for the source, the packet MUST be dropped.
実装は、GREキーフィールドを使用して、カプセル化装置を認証できます。 （「セキュリティの考慮事項」セクションを参照してください。）このモデルでは、共有値は、カプセル化装置とカプセル開放装置の間で構成またはネゴシエートされます。カプセル化解除者が、提示されたキーがソースに対して有効ではないと判断した場合、パケットをドロップする必要があります。
Although the GRE-in-UDP encapsulation protocol uses both the UDP header and GRE header, it is one tunnel encapsulation protocol. The GRE and UDP headers MUST be applied and removed as a pair at the encapsulation and decapsulation points. This specification does not support UDP encapsulation of a GRE header where that GRE header is applied or removed at a network node other than the UDP tunnel ingress or egress.
GRE-in-UDPカプセル化プロトコルは、UDPヘッダーとGREヘッダーの両方を使用しますが、1つのトンネルカプセル化プロトコルです。 GREおよびUDPヘッダーは、カプセル化ポイントとカプセル開放ポイントでペアとして適用および削除する必要があります。この仕様は、GREヘッダーのUDPカプセル化をサポートしていません。GREヘッダーは、UDPトンネルの入力または出力以外のネットワークノードで適用または削除されます。
The procedures specified in this section apply to both a default GRE-in-UDP tunnel and a TMCE GRE-in-UDP tunnel.
このセクションで指定されている手順は、デフォルトのGRE-in-UDPトンネルとTMCE GRE-in-UDPトンネルの両方に適用されます。
The GRE-in-UDP encapsulation allows encapsulated packets to be forwarded through "GRE-in-UDP tunnels". The encapsulator MUST set the UDP and GRE headers according to Section 3.
GRE-in-UDPカプセル化により、カプセル化されたパケットを「GRE-in-UDPトンネル」を介して転送できます。カプセル化装置は、セクション3に従ってUDPおよびGREヘッダーを設定する必要があります。
Intermediate routers, upon receiving these UDP encapsulated packets, could load-balance these packets based on the hash of the five-tuple of UDP packets.
中間ルーターは、これらのUDPカプセル化パケットを受信すると、UDPパケットの5タプルのハッシュに基づいてこれらのパケットの負荷を分散できます。
Upon receiving these UDP encapsulated packets, the decapsulator decapsulates them by removing the UDP and GRE headers and then processes them accordingly.
これらのUDPカプセル化パケットを受信すると、カプセル開放装置は、UDPヘッダーとGREヘッダーを削除してカプセル化を解除し、それに応じて処理します。
GRE-in-UDP can encapsulate traffic with unicast, IPv4 broadcast, or multicast (see requirement 3 in Section 2.1.1). However, a default GRE-in-UDP tunnel MUST NOT be deployed or configured to carry traffic that is not congestion-controlled (see requirement 3 in Section 2.1.1). Entropy may be generated from the header of encapsulated packets at an encapsulator. The mapping mechanism between the encapsulated multicast traffic and the multicast capability in the IP network is transparent and independent of the encapsulation and is otherwise outside the scope of this document.
GRE-in-UDPは、ユニキャスト、IPv4ブロードキャスト、またはマルチキャストでトラフィックをカプセル化できます（セクション2.1.1の要件3を参照）。ただし、デフォルトのGRE-in-UDPトンネルは、輻輳制御されていないトラフィックを伝送するように展開または構成してはなりません（セクション2.1.1の要件3を参照）。エントロピーは、カプセル化装置でカプセル化されたパケットのヘッダーから生成されます。カプセル化されたマルチキャストトラフィックとIPネットワークのマルチキャスト機能との間のマッピングメカニズムは透過的であり、カプセル化とは無関係であり、それ以外ではこのドキュメントの範囲外です。
To provide entropy for ECMP, GRE-in-UDP does not rely on GRE keep-alive. It is RECOMMENDED not to use GRE keep-alive in the GRE-in-UDP tunnel. This aligns with middlebox traversal guidelines in Section 3.5 of [RFC8085].
ECMPにエントロピーを提供するために、GRE-in-UDPはGREキープアライブに依存しません。 GRE-in-UDPトンネルでGREキープアライブを使用しないことをお勧めします。これは、[RFC8085]のセクション3.5のミドルボックストラバーサルガイドラインと一致しています。
Regarding packet fragmentation, an encapsulator/decapsulator SHOULD perform fragmentation before the encapsulation. The size of fragments SHOULD be less than or equal to the Path MTU (PMTU) associated with the path between the GRE ingress and the GRE egress tunnel endpoints minus the GRE and UDP overhead, assuming the egress MTU for reassembled packets is larger than the PMTU. When applying payload fragmentation, the UDP checksum MUST be used so that the receiving endpoint can validate reassembly of the fragments; the same source UDP port SHOULD be used for all packet fragments to ensure the transit routers will forward the fragments on the same path.
パケットの断片化に関して、カプセル化装置/カプセル開放装置はカプセル化の前に断片化を実行する必要があります。フラグメントのサイズは、再構築されたパケットの出力MTUがPMTUよりも大きいと想定して、GRE入力とGRE出力トンネルエンドポイント間のパスに関連付けられたパスMTU（PMTU）以下である必要があります。 。ペイロードフラグメンテーションを適用するときは、受信エンドポイントがフラグメントの再構成を検証できるように、UDPチェックサムを使用する必要があります。すべてのパケットフラグメントに同じ送信元UDPポートを使用して（SHOULD）、中継ルーターがフラグメントを同じパスに転送するようにします。
If the operator of the transit network supporting the tunnel is able to control the payload MTU size, the MTU SHOULD be configured to avoid fragmentation, i.e., sufficient for the largest supported size of packet, including all additional bytes introduced by the tunnel overhead [RFC8085].
トンネルをサポートするトランジットネットワークのオペレーターがペイロードのMTUサイズを制御できる場合、MTUは断片化を回避するように構成する必要があります。つまり、サポートされるパケットの最大サイズに十分であり、トンネルオーバーヘッドによって追加されるすべての追加バイトを含みます[RFC8085 ]。
To ensure that tunneled traffic receives the same treatment over the IP network as traffic that is not tunneled, prior to the encapsulation process, an encapsulator processes the tunneled IP packet headers to retrieve appropriate parameters for the encapsulating IP packet header such as Diffserv [RFC2983]. Encapsulation endpoints that support Explicit Congestion Notification (ECN) must use the method described in [RFC6040] for ECN marking propagation. The congestion control process is outside of the scope of this document.
トンネル化されたトラフィックがトンネル化されていないトラフィックと同じ処理をIPネットワーク上で確実に受信するように、カプセル化プロセスの前に、カプセル化装置はトンネル化されたIPパケットヘッダーを処理して、Diffserv [RFC2983]などのカプセル化IPパケットヘッダーの適切なパラメーターを取得します。 。明示的輻輳通知（ECN）をサポートするカプセル化エンドポイントは、ECNマーキング伝播のために[RFC6040]で説明されている方法を使用する必要があります。輻輳制御プロセスはこのドキュメントの範囲外です。
Additional information on IP header processing is provided in Section 3.1.
IPヘッダー処理の詳細については、セクション3.1を参照してください。
Datagram Transport Layer Security (DTLS) [RFC6347] can be used for application security and can preserve network- and transport-layer protocol information. Specifically, if DTLS is used to secure the GRE-in-UDP tunnel, the destination port of the UDP header MUST be set to the IANA-assigned value (4755) indicating GRE-in-UDP with DTLS, and that UDP port MUST NOT be used for other traffic. The UDP source port field can still be used to add entropy, e.g., for load-sharing purposes. DTLS applies to a default GRE-in-UDP tunnel and a TMCE GRE-in-UDP tunnel.
データグラムトランスポート層セキュリティ（DTLS）[RFC6347]は、アプリケーションのセキュリティに使用でき、ネットワーク層とトランスポート層のプロトコル情報を保持できます。特に、GRE-in-UDPトンネルを保護するためにDTLSが使用される場合、UDPヘッダーの宛先ポートは、DTLSを使用するGRE-in-UDPを示すIANA割り当て値（4755）に設定する必要があり、そのUDPポートは他のトラフィックに使用されます。 UDPソースポートフィールドは、たとえば負荷分散の目的で、エントロピーを追加するために引き続き使用できます。 DTLSは、デフォルトのGRE-in-UDPトンネルとTMCE GRE-in-UDPトンネルに適用されます。
Use of DTLS is limited to a single DTLS session for any specific tunnel encapsulator/decapsulator pair (identified by source and destination IP addresses). Both IP addresses MUST be unicast addresses -- multicast traffic is not supported when DTLS is used. A GRE-in-UDP tunnel decapsulator that supports DTLS is expected to be able to establish DTLS sessions with multiple tunnel encapsulators, and likewise a GRE-in-UDP tunnel encapsulator is expected to be able to establish DTLS sessions with multiple decapsulators. Different source and/or destination IP addresses will be involved; see Section 6.2 for discussion of one situation where use of different source IP addresses is important.
DTLSの使用は、特定のトンネルカプセル化/カプセル化解除のペア（送信元と宛先のIPアドレスで識別される）の単一のDTLSセッションに制限されています。両方のIPアドレスはユニキャストアドレスである必要があります。DTLSが使用されている場合、マルチキャストトラフィックはサポートされません。 DTLSをサポートするGRE-in-UDPトンネルカプセル化解除機能は、複数のトンネルカプセル化装置とのDTLSセッションを確立できることが期待され、同様に、GRE-in-UDPトンネルカプセル化装置は、複数のカプセル化解除装置とのDTLSセッションを確立できることが期待されます。異なる送信元および/または宛先IPアドレスが関係します。異なるソースIPアドレスの使用が重要である1つの状況については、セクション6.2を参照してください。
When DTLS is used for a GRE-in-UDP tunnel, if a packet is received from the tunnel and that packet is not protected by the DTLS session or part of DTLS negotiation (e.g., a DTLS handshake message [RFC6347]), the tunnel receiver MUST discard that packet and SHOULD log that discard event and information about the discarded packet.
DTLSがGRE-in-UDPトンネルに使用されている場合、トンネルからパケットが受信され、そのパケットがDTLSセッションまたはDTLSネゴシエーションの一部（DTLSハンドシェイクメッセージ[RFC6347]など）によって保護されていない場合、トンネル受信者はそのパケットを破棄しなければならず、破棄イベントと破棄されたパケットに関する情報をログに記録する必要があります（SHOULD）。
DTLS SHOULD be used for a GRE-in-UDP tunnel to meet security requirements of the original traffic that is delivered by a GRE-in-UDP tunnel. There are cases where no additional security is required, e.g., the traffic to be encapsulated is already encrypted or the tunnel is deployed within an operationally secured network. Use of DTLS for a GRE-in-UDP tunnel requires both tunnel endpoints to configure use of DTLS.
DREは、GRE-in-UDPトンネルによって配信される元のトラフィックのセキュリティ要件を満たすために、GRE-in-UDPトンネルに使用する必要があります（SHOULD）。カプセル化されるトラフィックがすでに暗号化されている、またはトンネルが運用上安全なネットワーク内に配置されているなど、追加のセキュリティが必要ない場合があります。 GRE-in-UDPトンネルにDTLSを使用するには、DTLSの使用を構成するために両方のトンネルエンドポイントが必要です。
For UDP in IPv4, when a non-zero UDP checksum is used, the UDP checksum MUST be processed as specified in [RFC768] and [RFC1122] for both transmit and receive. The IPv4 header includes a checksum that protects against misdelivery of the packet due to corruption of IP addresses. The UDP checksum potentially provides protection against corruption of the UDP header, GRE header, and GRE payload. Disabling the use of checksums is a deployment consideration that should take into account the risk and effects of packet corruption.
IPv4のUDPでは、ゼロ以外のUDPチェックサムが使用される場合、UDPチェックサムは、送信と受信の両方について、[RFC768]と[RFC1122]で指定されているように処理される必要があります。 IPv4ヘッダーには、IPアドレスの破損によるパケットの誤配信から保護するチェックサムが含まれています。 UDPチェックサムは、UDPヘッダー、GREヘッダー、およびGREペイロードの破損に対する保護を提供する可能性があります。チェックサムの使用を無効にすることは、パケット破損のリスクと影響を考慮に入れるべき配備上の考慮事項です。
When a decapsulator receives a packet, the UDP checksum field MUST be processed. If the UDP checksum is non-zero, the decapsulator MUST verify the checksum before accepting the packet. By default, a decapsulator SHOULD accept UDP packets with a zero checksum. A node MAY be configured to disallow zero checksums per [RFC1122]; this may be done selectively, for instance, disallowing zero checksums from certain hosts that are known to be sending over paths subject to packet corruption. If verification of a non-zero checksum fails, a decapsulator lacks the capability to verify a non-zero checksum, or a packet with a zero checksum was received and the decapsulator is configured to disallow, the packet MUST be dropped and an event MAY be logged.
カプセル開放装置がパケットを受信すると、UDPチェックサムフィールドを処理する必要があります。 UDPチェックサムがゼロ以外の場合、カプセル化解除機能は、パケットを受け入れる前にチェックサムを検証する必要があります。デフォルトでは、カプセル開放装置は、チェックサムがゼロのUDPパケットを受け入れる必要があります（SHOULD）。ノードは、[RFC1122]によるゼロチェックサムを許可しないように構成できます。これは選択的に行うことができます。たとえば、パケット破損の影響を受けるパスを介して送信することがわかっている特定のホストからのゼロチェックサムを禁止します。ゼロ以外のチェックサムの検証に失敗した場合、カプセル化解除ツールにゼロ以外のチェックサムを検証する機能がないか、チェックサムがゼロのパケットが受信され、カプセル化解除者が許可しないように構成されている場合、パケットをドロップする必要があり、イベントはログに記録されました。
For UDP in IPv6, the UDP checksum MUST be processed as specified in [RFC768] and [RFC2460] for both transmit and receive.
IPv6のUDPの場合、UDPチェックサムは、[RFC768]と[RFC2460]で指定されているように、送信と受信の両方で処理される必要があります。
When UDP is used over IPv6, the UDP checksum is relied upon to protect both the IPv6 and UDP headers from corruption. As such, a default GRE-in-UDP tunnel MUST perform UDP checksum; a TMCE GRE-in- UDP tunnel MAY be configured with UDP zero-checksum mode if the traffic-managed controlled environment or a set of closely cooperating traffic-managed controlled environments (such as by network operators who have agreed to work together in order to jointly provide specific services) meet at least one of the following conditions:
UDPがIPv6を介して使用される場合、UDPチェックサムは、IPv6ヘッダーとUDPヘッダーの両方を破損から保護するために使用されます。そのため、デフォルトのGRE-in-UDPトンネルはUDPチェックサムを実行する必要があります。 TMCE GRE-in- UDPトンネルは、トラフィック管理された制御された環境または密接に協力しているトラフィック管理された制御された環境のセット（ネットワークオペレーターが共同で作業することに同意したなど）の場合、UDPゼロチェックサムモードで構成できます。特定のサービスを共同で提供する）次の条件の少なくとも1つを満たすこと：
a. It is known (perhaps through knowledge of equipment types and lower-layer checks) that packet corruption is exceptionally unlikely and where the operator is willing to take the risk of undetected packet corruption.
a. パケットの破損が例外的に発生する可能性は非常に低く、検出されないパケット破損のリスクをオペレーターが負う可能性がある場合は（おそらく機器の種類と下位層のチェックによって）わかっています。
b. It is judged through observational measurements (perhaps of historic or current traffic flows that use a non-zero checksum) that the level of packet corruption is tolerably low and where the operator is willing to take the risk of undetected packet corruption.
b. 観測による測定（おそらく、ゼロ以外のチェックサムを使用する過去または現在のトラフィックフロー）により、パケット破損のレベルは許容範囲内であり、オペレーターが検出されないパケット破損のリスクを負う可能性があると判断されます。
c. Carrying applications that are tolerant of misdelivered or corrupted packets (perhaps through higher-layer checksum, validation, and retransmission or transmission redundancy) where the operator is willing to rely on the applications using the tunnel to survive any corrupt packets.
c. オペレーターがトンネルを使用してアプリケーションを信頼し、破損したパケットを生き残ることができる場合に、誤った配信または破損したパケットを許容するアプリケーション（おそらく上位層のチェックサム、検証、再送信または送信の冗長性による）を運ぶ。
The following requirements apply to a TMCE GRE-in-UDP tunnel that uses UDP zero-checksum mode:
次の要件は、UDPゼロチェックサムモードを使用するTMCE GRE-in-UDPトンネルに適用されます。
a. Use of the UDP checksum with IPv6 MUST be the default configuration of all GRE-in-UDP tunnels.
a. IPv6でのUDPチェックサムの使用は、すべてのGRE-in-UDPトンネルのデフォルト構成である必要があります。
b. The GRE-in-UDP tunnel implementation MUST comply with all requirements specified in Section 4 of [RFC6936] and with requirement 1 specified in Section 5 of [RFC6936].
b. GRE-in-UDPトンネルの実装は、[RFC6936]のセクション4で指定されているすべての要件と、[RFC6936]のセクション5で指定されている要件1に準拠している必要があります。
c. The tunnel decapsulator SHOULD only allow the use of UDP zero-checksum mode for IPv6 on a single received UDP Destination Port, regardless of the encapsulator. The motivation for this requirement is possible corruption of the UDP Destination Port, which may cause packet delivery to the wrong UDP port. If that other UDP port requires the UDP checksum, the misdelivered packet will be discarded.
c. トンネルカプセル化解除機能は、カプセル化機能に関係なく、受信した単一のUDP宛先ポートでIPv6のUDPゼロチェックサムモードの使用のみを許可する必要があります（SHOULD）。この要件の動機は、UDP宛先ポートの破損の可能性であり、これにより、間違ったUDPポートにパケットが配信される可能性があります。他のUDPポートでUDPチェックサムが必要な場合、誤って配信されたパケットは破棄されます。
d. It is RECOMMENDED that the UDP zero-checksum mode for IPv6 is only enabled for certain selected source addresses. The tunnel decapsulator MUST check that the source and destination IPv6 addresses are valid for the GRE-in-UDP tunnel on which the packet was received if that tunnel uses UDP zero-checksum mode and discard any packet for which this check fails.
d. IPv6のUDPゼロチェックサムモードは、特定の選択された送信元アドレスに対してのみ有効にすることをお勧めします。トンネルカプセル化解除機能は、トンネルがUDPゼロチェックサムモードを使用している場合、パケットが受信されたGRE-in-UDPトンネルに対して送信元および宛先IPv6アドレスが有効であることを確認し、このチェックが失敗したパケットを破棄する必要があります。
e. The tunnel encapsulator SHOULD use different IPv6 addresses for each GRE-in-UDP tunnel that uses UDP zero-checksum mode, regardless of the decapsulator, in order to strengthen the decapsulator's check of the IPv6 source address (i.e., the same IPv6 source address SHOULD NOT be used with more than one IPv6 destination address, independent of whether that destination address is a unicast or multicast address). When this is not possible, it is RECOMMENDED to use each source IPv6 address for as few GRE-in-UDP tunnels that use UDP zero-checksum mode as is feasible.
e. トンネルカプセル化装置は、IPv6送信元アドレスのカプセル化解除プログラムのチェックを強化するために、カプセル化解除装置に関係なく、UDPゼロチェックサムモードを使用する各GRE-in-UDPトンネルに異なるIPv6アドレスを使用する必要があります（つまり、同じIPv6送信元アドレス宛先アドレスがユニキャストアドレスかマルチキャストアドレスかに関係なく、複数のIPv6宛先アドレスで使用しないでください。これが不可能な場合は、UDPゼロチェックサムモードを使用するGRE-in-UDPトンネルをできるだけ少なくするために、各ソースIPv6アドレスを使用することをお勧めします。
f. When any middlebox exists on the path of a GRE-in-UDP tunnel, it is RECOMMENDED to use the default mode, i.e., use UDP checksum, to reduce the chance that the encapsulated packets will be dropped.
f. ミドルボックスがGRE-in-UDPトンネルのパス上に存在する場合、デフォルトのモードを使用すること、つまり、UDPチェックサムを使用して、カプセル化されたパケットがドロップされる可能性を減らすことをお勧めします。
g. Any middlebox that allows the UDP zero-checksum mode for IPv6 MUST comply with requirements 1 and 8-10 in Section 5 of [RFC6936].
g. IPv6のUDPゼロチェックサムモードを許可するミドルボックスは、[RFC6936]のセクション5の要件1および8-10に準拠する必要があります。
h. Measures SHOULD be taken to prevent IPv6 traffic with zero UDP checksums from "escaping" to the general Internet; see Section 8 for examples of such measures.
h. UDPチェックサムがゼロのIPv6トラフィックが一般的なインターネットに「エスケープ」しないようにするための対策を講じる必要があります。このような対策の例については、セクション8を参照してください。
i. IPv6 traffic with zero UDP checksums MUST be actively monitored for errors by the network operator. For example, the operator may monitor Ethernet-layer packet error rates.
i. UDPチェックサムがゼロのIPv6トラフィックは、ネットワークオペレーターによるエラーを積極的に監視する必要があります。たとえば、オペレータはイーサネット層のパケットエラー率を監視できます。
j. If a packet with a non-zero checksum is received, the checksum MUST be verified before accepting the packet. This is regardless of whether the tunnel encapsulator and decapsulator have been configured with UDP zero-checksum mode.
j. チェックサムがゼロでないパケットを受信した場合、パケットを受け入れる前にチェックサムを検証する必要があります。これは、トンネルカプセル化装置とカプセル化解除装置がUDPゼロチェックサムモードで構成されているかどうかには関係ありません。
The above requirements do not change either the requirements specified in [RFC2460] as modified by [RFC6935] or the requirements specified in [RFC6936].
上記の要件は、[RFC6935]によって変更された[RFC2460]で指定された要件も、[RFC6936]で指定された要件も変更しません。
The requirement to check the source IPv6 address in addition to the destination IPv6 address and the strong recommendation against reuse of source IPv6 addresses among GRE-in-UDP tunnels collectively provide some mitigation for the absence of UDP checksum coverage of the IPv6 header. A traffic-managed controlled environment that satisfies at least one of three conditions listed at the beginning of this section provides additional assurance.
宛先IPv6アドレスに加えてソースIPv6アドレスをチェックする要件と、GRE-in-UDPトンネル間でソースIPv6アドレスを再利用しないことを強く推奨することにより、IPv6ヘッダーのUDPチェックサムカバレッジが存在しない場合の緩和策が提供されます。このセクションの冒頭に記載されている3つの条件のうち少なくとも1つを満たすトラフィック管理された制御環境は、追加の保証を提供します。
A GRE-in-UDP tunnel is suitable for transmission over lower layers in the traffic-managed controlled environments that are allowed by the exceptions stated above, and the rate of corruption of the inner IP packet on such networks is not expected to increase by comparison to GRE traffic that is not encapsulated in UDP. For these reasons, GRE-in-UDP does not provide an additional integrity check except when GRE checksum is used when UDP zero-checksum mode is used with IPv6, and this design is in accordance with requirements 2, 3, and 5 specified in Section 5 of [RFC6936].
GRE-in-UDPトンネルは、上記の例外で許可されているトラフィック管理された制御環境での下位層での送信に適しています。そのようなネットワーク上の内部IPパケットの破損率は、比較すると増加するとは予想されません。 UDPでカプセル化されていないGREトラフィックに。これらの理由により、IPv6でUDPゼロチェックサムモードが使用されているときにGREチェックサムが使用され、この設計がセクションで指定された要件2、3、および5に準拠している場合を除き、GRE-in-UDPは追加の整合性チェックを提供しません。 [RFC6936]の5。
Generic Router Encapsulation (GRE) does not accumulate incorrect transport-layer state as a consequence of GRE header corruption. A corrupt GRE packet may result in either packet discard or packet forwarding without accumulation of GRE state. Active monitoring of GRE-in-UDP traffic for errors is REQUIRED, as the occurrence of errors will result in some accumulation of error information outside the protocol for operational and management purposes. This design is in accordance with requirement 4 specified in Section 5 of [RFC6936].
Generic Router Encapsulation（GRE）は、GREヘッダーの破損の結果として、誤ったトランスポート層の状態を蓄積しません。破損したGREパケットは、GRE状態の蓄積なしに、パケット廃棄またはパケット転送のいずれかを引き起こす可能性があります。エラーが発生すると、運用および管理の目的でプロトコルの外部にエラー情報が蓄積されるため、GRE-in-UDPトラフィックのエラーをアクティブに監視する必要があります。この設計は、[RFC6936]のセクション5で指定されている要件4に準拠しています。
The remaining requirements specified in Section 5 of [RFC6936] are not applicable to GRE-in-UDP. Requirements 6 and 7 do not apply because GRE does not include a control feedback mechanism. Requirements 8-10 are middlebox requirements that do not apply to GRE-in-UDP tunnel endpoints. (See Section 7.1 for further middlebox discussion.)
[RFC6936]のセクション5で指定されている残りの要件は、GRE-in-UDPには適用されません。 GREには制御フィードバックメカニズムが含まれていないため、要件6および7は適用されません。要件8〜10は、GRE-in-UDPトンネルエンドポイントに適用されないミドルボックス要件です。 （ミドルボックスの詳細については、セクション7.1を参照してください。）
It is worth mentioning that the use of a zero UDP checksum should present the equivalent risk of undetected packet corruption when sending a similar packet using GRE-in-IPv6 without UDP [RFC7676] and without GRE checksums.
ゼロのUDPチェックサムを使用すると、UDPなしのGRE-in-IPv6 [RFC7676]とGREチェックサムなしで同様のパケットを送信するときに、検出されないパケット破損の同等のリスクが発生することに注意してください。
In summary, a TMCE GRE-in-UDP tunnel is allowed to use UDP zero-checksum mode for IPv6 when the conditions and requirements stated above are met. Otherwise, the UDP checksum needs to be used for IPv6 as specified in [RFC768] and [RFC2460]. Use of GRE checksum is RECOMMENDED when the UDP checksum is not used.
要約すると、TMCE GRE-in-UDPトンネルは、上記の条件と要件が満たされている場合、IPv6に対してUDPゼロチェックサムモードを使用できます。それ以外の場合は、[RFC768]および[RFC2460]で指定されているように、IPv6にUDPチェックサムを使用する必要があります。 UDPチェックサムを使用しない場合は、GREチェックサムの使用をお勧めします。
Many middleboxes read or update UDP port information of the packets that they forward. Network Address Port Translator (NAPT) is the most commonly deployed Network Address Translation (NAT) device [RFC4787]. A NAPT device establishes a NAT session to translate the {private IP address, private source port number} tuple to a {public IP address, public source port number} tuple, and vice versa, for the duration of the UDP session. This provides a UDP application with the "NAT pass-through" function. NAPT allows multiple internal hosts to share a single public IP address. The port number, i.e., the UDP Source Port number, is used as the demultiplexer of the multiple internal hosts. However, the above NAPT behaviors conflict with the behavior of a GRE-in-UDP tunnel that is configured to use the UDP source port value to provide entropy.
多くのミドルボックスは、転送するパケットのUDPポート情報を読み取りまたは更新します。ネットワークアドレスポートトランスレーター（NAPT）は、最も一般的に展開されているネットワークアドレス変換（NAT）デバイス[RFC4787]です。 NAPTデバイスは、NATセッションを確立して、UDPセッション中に{プライベートIPアドレス、プライベートソースポート番号}タプルを{パブリックIPアドレス、パブリックソースポート番号}タプルに、またはその逆に変換します。これにより、UDPアプリケーションに「NATパススルー」機能が提供されます。 NAPTを使用すると、複数の内部ホストが1つのパブリックIPアドレスを共有できます。ポート番号、つまりUDP送信元ポート番号は、複数の内部ホストのデマルチプレクサーとして使用されます。ただし、上記のNAPT動作は、UDP送信元ポート値を使用してエントロピーを提供するように構成されたGRE-in-UDPトンネルの動作と競合します。
A GRE-in-UDP tunnel is unidirectional; the tunnel traffic is not expected to be returned back to the UDP source port values used to generate entropy. However, some middleboxes (e.g., firewalls) assume that bidirectional traffic uses a common pair of UDP ports. This assumption also conflicts with the use of the UDP source port field as entropy.
GRE-in-UDPトンネルは単方向です。トンネルトラフィックは、エントロピーを生成するために使用されるUDP送信元ポートの値に戻されることは想定されていません。ただし、一部のミドルボックス（ファイアウォールなど）では、双方向トラフィックが共通のUDPポートのペアを使用すると想定しています。この仮定は、UDPソースポートフィールドをエントロピーとして使用することとも競合します。
Hence, use of the UDP source port for entropy may impact middleboxes' behavior. If a GRE-in-UDP tunnel is expected to be used on a path with a middlebox, the tunnel can be configured either to disable use of the UDP source port for entropy or to enable middleboxes to pass packets with UDP source port entropy.
したがって、エントロピーにUDPソースポートを使用すると、ミドルボックスの動作に影響を与える可能性があります。 GRE-in-UDPトンネルがミドルボックスのあるパスで使用されることが予想される場合、トンネルは、エントロピーに対するUDPソースポートの使用を無効にするか、ミドルボックスがUDPソースポートエントロピーでパケットを渡すことができるように構成できます。
IPv6 datagrams with a zero UDP checksum will not be passed by any middlebox that updates the UDP checksum field or simply validates the checksum based on [RFC2460], such as firewalls. Changing this behavior would require such middleboxes to be updated to correctly handle datagrams with zero UDP checksums. The GRE-in-UDP encapsulation does not provide a mechanism to safely fall back to using a checksum when a path change occurs that redirects a tunnel over a path that includes a middlebox that discards IPv6 datagrams with a zero UDP checksum. In this case, the GRE-in-UDP tunnel will be black-holed by that middlebox.
UDPチェックサムがゼロのIPv6データグラムは、UDPチェックサムフィールドを更新するか、ファイアウォールなどの[RFC2460]に基づいてチェックサムを検証するミドルボックスによって渡されません。この動作を変更するには、このようなミドルボックスを更新して、UDPチェックサムがゼロのデータグラムを正しく処理する必要があります。 UDPのチェックサムがゼロのIPv6データグラムを破棄するミドルボックスを含むパスを介してトンネルをリダイレクトするパス変更が発生した場合、GRE-in-UDPカプセル化はチェックサムの使用に安全にフォールバックするメカニズムを提供しません。この場合、GRE-in-UDPトンネルはそのミドルボックスによってブラックホール化されます。
As such, when any middlebox exists on the path of a GRE-in-UDP tunnel, use of the UDP checksum is RECOMMENDED to increase the probability of successful transmission of GRE-in-UDP packets. Recommended changes to allow firewalls and other middleboxes to support use of an IPv6 zero UDP checksum are described in Section 5 of [RFC6936].
そのため、GRE-in-UDPトンネルのパスにミドルボックスが存在する場合、GRE-in-UDPパケットの送信が成功する確率を高めるために、UDPチェックサムの使用が推奨されます。ファイアウォールやその他のミドルボックスがIPv6ゼロUDPチェックサムの使用をサポートできるようにするための推奨される変更は、[RFC6936]のセクション5で説明されています。
Section 3.1.9 of [RFC8085] discusses the congestion considerations for design and use of UDP tunnels; this is important because other flows could share the path with one or more UDP tunnels, necessitating congestion control [RFC2914] to avoid destructive interference.
[RFC8085]のセクション3.1.9は、UDPトンネルの設計と使用に関する輻輳の考慮事項について説明しています。他のフローが1つ以上のUDPトンネルとパスを共有し、破壊的な干渉を回避するために輻輳制御[RFC2914]を必要とする可能性があるため、これは重要です。
Congestion has potential impacts both on the rest of the network containing a UDP tunnel and on the traffic flows using the UDP tunnels. These impacts depend upon what sort of traffic is carried over the tunnel, as well as the path of the tunnel. The GRE-in-UDP tunnel protocol does not provide any congestion control and GRE-in-UDP packets are regular UDP packets. Therefore, a GRE-in-UDP tunnel MUST NOT be deployed to carry non-congestion-controlled traffic over the Internet [RFC8085].
輻輳は、UDPトンネルを含む残りのネットワークと、UDPトンネルを使用するトラフィックフローの両方に影響を与える可能性があります。これらの影響は、トンネルを通過するトラフィックの種類と、トンネルのパスによって異なります。 GRE-in-UDPトンネルプロトコルは輻輳制御を提供せず、GRE-in-UDPパケットは通常のUDPパケットです。したがって、GRE-in-UDPトンネルは、インターネットを介して非輻輳制御トラフィックを運ぶために展開してはなりません[RFC8085]。
Within a TMCE network, GRE-in-UDP tunnels are appropriate for carrying traffic that is not known to be congestion controlled. For example, a GRE-in-UDP tunnel may be used to carry Multiprotocol Label Switching (MPLS) traffic such as pseudowires or VPNs where specific bandwidth guarantees are provided to each pseudowire or VPN. In such cases, operators of TMCE networks avoid congestion by careful provisioning of their networks, rate-limiting of user data traffic, and traffic engineering according to path capacity.
TMCEネットワーク内では、GRE-in-UDPトンネルは、輻輳制御されていないことがわかっているトラフィックを運ぶのに適しています。たとえば、GRE-in-UDPトンネルは、特定の帯域幅保証が各疑似配線またはVPNに提供される疑似配線またはVPNなどのマルチプロトコルラベルスイッチング（MPLS）トラフィックを伝送するために使用できます。このような場合、TMCEネットワークのオペレーターは、ネットワークの慎重なプロビジョニング、ユーザーデータトラフィックのレート制限、およびパス容量に応じたトラフィックエンジニアリングにより、輻輳を回避します。
When a GRE-in-UDP tunnel carries traffic that is not known to be congestion controlled in a TMCE network, the tunnel MUST be deployed entirely within that network, and measures SHOULD be taken to prevent the GRE-in-UDP traffic from "escaping" the network to the general Internet. Examples of such measures are:
GRE-in-UDPトンネルがTMCEネットワークで輻輳制御されていないことがわかっているトラフィックを運ぶ場合、トンネルはそのネットワーク内に完全に展開する必要があり、GRE-in-UDPトラフィックが「エスケープするのを防ぐための対策を講じる必要があります（SHOULD）」 "一般的なインターネットへのネットワーク。このような対策の例は次のとおりです。
o physical or logical isolation of the links carrying GRE-in-UDP from the general Internet,
o 一般的なインターネットからGRE-in-UDPを伝送するリンクの物理的または論理的な分離
o deployment of packet filters that block the UDP ports assigned for GRE-in-UDP, and
o GRE-in-UDPに割り当てられたUDPポートをブロックするパケットフィルターの展開、および
o imposition of restrictions on GRE-in-UDP traffic by software tools used to set up GRE-in-UDP tunnels between specific end systems (as might be used within a single data center) or by tunnel ingress nodes for tunnels that don't terminate at end systems.
o 特定のエンドシステム間でGRE-in-UDPトンネルをセットアップするために使用されるソフトウェアツール（単一のデータセンター内で使用される可能性がある）または終了しないトンネルのトンネル入口ノードによるGRE-in-UDPトラフィックに対する制限の強制エンドシステムで。
In general, tunnel ingress routers have to be upgraded in order to support the encapsulations described in this document.
一般に、このドキュメントで説明されているカプセル化をサポートするには、トンネル入力ルーターをアップグレードする必要があります。
No change is required at transit routers to support forwarding of the encapsulation described in this document.
このドキュメントで説明されているカプセル化の転送をサポートするために、中継ルータで変更を加える必要はありません。
If a tunnel endpoint (a host or router) that is intended for use as a decapsulator does not support or enable the GRE-in-UDP encapsulation described in this document, that endpoint will not listen on the destination port assigned to the GRE-encapsulation (4754 and 4755). In these cases, the endpoint will perform normal UDP processing and respond to an encapsulator with an ICMP message indicating "port unreachable" according to [RFC792]. Upon receiving this ICMP message, the node MUST NOT continue to use GRE-in-UDP encapsulation toward this peer without management intervention.
カプセル化解除装置としての使用を目的としたトンネルエンドポイント（ホストまたはルーター）が、このドキュメントで説明されているGRE-in-UDPカプセル化をサポートまたは有効にしていない場合、そのエンドポイントはGREカプセル化に割り当てられた宛先ポートで待機しません（4754および4755）。これらの場合、エンドポイントは通常のUDP処理を実行し、[RFC792]に従って「ポート到達不能」を示すICMPメッセージでカプセル化装置に応答します。このICMPメッセージを受信すると、ノードは、管理の介入なしに、このピアに対してGRE-in-UDPカプセル化を引き続き使用してはなりません（MUST NOT）。
IANA has allocated the following UDP destination port number for the indication of GRE:
IANAは、GREを示すために次のUDP宛先ポート番号を割り当てました。
Service Name: GRE-in-UDP
Transport Protocol(s): UDP
Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>
Description: GRE-in-UDP Encapsulation
Reference: RFC 8086
Port Number: 4754
Service Code: N/A
Known Unauthorized Uses: N/A
Assignment Notes: N/A
IANA has allocated the following UDP destination port number for the indication of GRE with DTLS:
IANAは、DTLSを使用するGREを示すために、次のUDP宛先ポート番号を割り当てました。
Service Name: GRE-UDP-DTLS
Transport Protocol(s): UDP
Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>
Description: GRE-in-UDP Encapsulation with DTLS
Reference: RFC 8086
Port Number: 4755
Service Code: N/A
Known Unauthorized Uses: N/A
Assignment Notes: N/A
GRE-in-UDP encapsulation does not affect security for the payload protocol. The security considerations for GRE apply to GRE-in-UDP; see [RFC2784].
GRE-in-UDPカプセル化は、ペイロードプロトコルのセキュリティには影響しません。 GREのセキュリティに関する考慮事項は、GRE-in-UDPに適用されます。 [RFC2784]を参照してください。
To secure traffic carried by a GRE-in-UDP tunnel, DTLS SHOULD be used as specified in Section 5.
GRE-in-UDPトンネルによって伝送されるトラフィックを保護するには、セクション5で指定されているようにDTLSを使用する必要があります（SHOULD）。
In the case that UDP source port for entropy usage is disabled, a random port taken from the ephemeral port range SHOULD be selected in order to minimize the vulnerability to off-path attacks [RFC6056]. The random port may also be periodically changed to mitigate certain DoS attacks as mentioned in Section 3.2.1.
エントロピー使用のためのUDPソースポートが無効になっている場合、オフパス攻撃に対する脆弱性を最小化するために、エフェメラルポート範囲から取得したランダムなポートを選択する必要があります[RFC6056]。セクション3.2.1で述べたように、ランダムポートは定期的に変更され、特定のDoS攻撃を緩和することもできます。
Using one standardized value as the UDP destination port to indicate an encapsulation may increase the vulnerability to off-path attacks. To overcome this, an alternate port may be agreed upon to use between an encapsulator and decapsulator [RFC6056]. How the encapsulator endpoints communicate the value is outside the scope of this document.
カプセル化を示すために、1つの標準化された値をUDP宛先ポートとして使用すると、オフパス攻撃に対する脆弱性が高まる可能性があります。これを克服するために、代替ポートは、カプセル化装置とカプセル開放装置の間で使用することに同意されるかもしれません[RFC6056]。カプセル化エンドポイントが値を伝達する方法は、このドキュメントの範囲外です。
This document does not require that a decapsulator validate the IP source address of the tunneled packets (with the exception that the IPv6 source address MUST be validated when UDP zero-checksum mode is used with IPv6), but it should be understood that failure to do so presupposes that there is effective destination-based filtering (or a combination of source-based and destination-based filtering) at the boundaries.
このドキュメントでは、カプセル化解除ツールがトンネルパケットのIP送信元アドレスを検証する必要はありません（ただし、IPv6でUDPゼロチェックサムモードを使用する場合はIPv6送信元アドレスを検証する必要があります）。ただし、失敗すると、したがって、境界に効果的な宛先ベースのフィルタリング（または送信元ベースと宛先ベースのフィルタリングの組み合わせ）があると仮定します。
Corruption of GRE headers can cause security concerns for applications that rely on the GRE Key field for traffic separation or segregation. When the GRE Key field is used for this purpose, such as an application of a Network Virtualization Using Generic Routing Encapsulation (NVGRE) [RFC7637], GRE header corruption is a concern. In such situations, at least one of the UDP and GRE checksums MUST be used for both IPv4 and IPv6 GRE-in-UDP tunnels.
GREヘッダーの破損は、トラフィックの分離または分離をGREキーフィールドに依存するアプリケーションにセキュリティ上の問題を引き起こす可能性があります。 GREキーフィールドがこの目的で使用されている場合（Generic Routing Encapsulationを使用したネットワーク仮想化（NVGRE）[RFC7637]など）の場合、GREヘッダーの破損が懸念されます。このような状況では、UDPおよびGREチェックサムの少なくとも1つをIPv4とIPv6の両方のGRE-in-UDPトンネルに使用する必要があります。
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <http://www.rfc-editor.org/info/rfc768>.
[RFC768] Postel、J。、「User Datagram Protocol」、STD 6、RFC 768、DOI 10.17487 / RFC0768、1980年8月、<http://www.rfc-editor.org/info/rfc768>。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <http://www.rfc-editor.org/info/rfc1122>.
[RFC1122] Braden、R。、編、「インターネットホストの要件-通信層」、STD 3、RFC 1122、DOI 10.17487 / RFC1122、1989年10月、<http://www.rfc-editor.org/info/ rfc1122>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, <http://www.rfc-editor.org/info/rfc2474>.
[RFC2474] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「IPv4およびIPv6ヘッダーのDiffServフィールド（DSフィールド）の定義」、RFC 2474、DOI 10.17487 / RFC2474、 1998年12月、<http://www.rfc-editor.org/info/rfc2474>。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, DOI 10.17487/RFC2784, March 2000, <http://www.rfc-editor.org/info/rfc2784>.
[RFC2784] Farinacci、D.、Li、T.、Hanks、S.、Meyer、D。、およびP. Traina、「Generic Routing Encapsulation（GRE）」、RFC 2784、DOI 10.17487 / RFC2784、2000年3月、<http ：//www.rfc-editor.org/info/rfc2784>。
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, DOI 10.17487/RFC2890, September 2000, <http://www.rfc-editor.org/info/rfc2890>.
[RFC2890] Dommety、G。、「GREのキーとシーケンス番号の拡張」、RFC 2890、DOI 10.17487 / RFC2890、2000年9月、<http://www.rfc-editor.org/info/rfc2890>。
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010, <http://www.rfc-editor.org/info/rfc6040>.
[RFC6040] Briscoe、B。、「Tunnelling of Explicit Congestion Notification」、RFC 6040、DOI 10.17487 / RFC6040、2010年11月、<http://www.rfc-editor.org/info/rfc6040>。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC6347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security Version 1.2」、RFC 6347、DOI 10.17487 / RFC6347、2012年1月、<http://www.rfc-editor.org/info/rfc6347>。
[RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, <http://www.rfc-editor.org/info/rfc6438>.
[RFC6438]カーペンター、B。およびS.アマンテ、「トンネルでの等コストマルチパスルーティングおよびリンク集約のためのIPv6フローラベルの使用」、RFC 6438、DOI 10.17487 / RFC6438、2011年11月、<http：//www.rfc- editor.org/info/rfc6438>。
[RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and UDP Checksums for Tunneled Packets", RFC 6935, DOI 10.17487/RFC6935, April 2013, <http://www.rfc-editor.org/info/rfc6935>.
[RFC6935] Eubanks、M.、Chimento、P。、およびM. Westerlund、「トンネルパケットのIPv6およびUDPチェックサム」、RFC 6935、DOI 10.17487 / RFC6935、2013年4月、<http：//www.rfc-editor。 org / info / rfc6935>。
[RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 6936, DOI 10.17487/RFC6936, April 2013, <http://www.rfc-editor.org/info/rfc6936>.
[RFC6936] Fairhurst、G。およびM. Westerlund、「ゼロチェックサムを使用したIPv6 UDPデータグラムの使用に関する適用性声明」、RFC 6936、DOI 10.17487 / RFC6936、2013年4月、<http://www.rfc-editor.org / info / rfc6936>。
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <http://www.rfc-editor.org/info/rfc8085>.
[RFC8085] Eggert、L.、Fairhurst、G。、およびG. Shepherd、「UDP使用ガイドライン」、BCP 145、RFC 8085、DOI 10.17487 / RFC8085、2017年3月、<http://www.rfc-editor.org / info / rfc8085>。
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, <http://www.rfc-editor.org/info/rfc792>.
[RFC792] Postel、J。、「インターネット制御メッセージプロトコル」、STD 5、RFC 792、DOI 10.17487 / RFC0792、1981年9月、<http://www.rfc-editor.org/info/rfc792>。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <http://www.rfc-editor.org/info/rfc793>.
[RFC793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、DOI 10.17487 / RFC0793、1981年9月、<http://www.rfc-editor.org/info/rfc793>。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、DOI 10.17487 / RFC2460、1998年12月、<http://www.rfc-editor.org/info/ rfc2460>。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, DOI 10.17487/RFC2914, September 2000, <http://www.rfc-editor.org/info/rfc2914>.
[RFC2914] Floyd、S。、「Congestion Control Principles」、BCP 41、RFC 2914、DOI 10.17487 / RFC2914、2000年9月、<http://www.rfc-editor.org/info/rfc2914>。
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, DOI 10.17487/RFC2983, October 2000, <http://www.rfc-editor.org/info/rfc2983>.
[RFC2983] Black、D。、「Differentiated Services and Tunnels」、RFC 2983、DOI 10.17487 / RFC2983、2000年10月、<http://www.rfc-editor.org/info/rfc2983>。
[RFC4787] Audet, F., Ed., and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 2007, <http://www.rfc-editor.org/info/rfc4787>.
[RFC4787]オーデット、F。、エド、およびC.ジェニングス、「ユニキャストUDPのネットワークアドレス変換（NAT）動作要件」、BCP 127、RFC 4787、DOI 10.17487 / RFC4787、2007年1月、<http：// www .rfc-editor.org / info / rfc4787>。
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-Protocol Port Randomization", BCP 156, RFC 6056, DOI 10.17487/RFC6056, January 2011, <http://www.rfc-editor.org/info/rfc6056>.
[RFC6056] Larsen、M。およびF. Gont、「Recommendations for Transport-Protocol Port Randomization」、BCP 156、RFC 6056、DOI 10.17487 / RFC6056、2011年1月、<http://www.rfc-editor.org/info / rfc6056>。
[RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, October 2013, <http://www.rfc-editor.org/info/rfc7042>.
[RFC7042] Eastlake 3rd、D。およびJ. Abley、「IANAの考慮事項とIEEE 802パラメータのIETFプロトコルおよびドキュメントの使用法」、BCP 141、RFC 7042、DOI 10.17487 / RFC7042、2013年10月、<http：//www.rfc -editor.org/info/rfc7042>。
[RFC7637] Garg, P., Ed., and Y. Wang, Ed., "NVGRE: Network Virtualization Using Generic Routing Encapsulation", RFC 7637, DOI 10.17487/RFC7637, September 2015, <http://www.rfc-editor.org/info/rfc7637>.
[RFC7637] Garg、P。、編、およびY. Wang、編、「NVGRE：汎用ルーティングカプセル化を使用したネットワーク仮想化」、RFC 7637、DOI 10.17487 / RFC7637、2015年9月、<http：//www.rfc- editor.org/info/rfc7637>。
[RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support for Generic Routing Encapsulation (GRE)", RFC 7676, DOI 10.17487/RFC7676, October 2015, <http://www.rfc-editor.org/info/rfc7676>.
[RFC7676] Pignataro、C.、Bonica、R。、およびS. Krishnan、「IPv6 Support for Generic Routing Encapsulation（GRE）」、RFC 7676、DOI 10.17487 / RFC7676、2015年10月、<http：//www.rfc- editor.org/info/rfc7676>。
Acknowledgements
謝辞
The authors would like to thank Vivek Kumar, Ron Bonica, Joe Touch, Ruediger Geib, Lars Eggert, Lloyd Wood, Bob Briscoe, Rick Casarez, Jouni Korhonen, Kathleen Moriarty, Ben Campbell, and many others for their reviews and valuable input on this document.
著者は、Vivek Kumar、Ron Bonica、Joe Touch、Ruediger Geib、Lars Eggert、Lloyd Wood、Bob Briscoe、Rick Casarez、Jouni Korhonen、Kathleen Moriarty、Ben Campbell、その他多くのレビューとこれに関する貴重な情報に感謝します。資料。
Thanks to Donald Eastlake, Eliot Lear, Martin Stiemerling, and Spencer Dawkins for their detailed reviews and valuable suggestions during WG Last Call and the IESG process.
ドナルドイーストレイク、エリオットリア、マーティンスティーマーリング、およびスペンサードーキンスのWGラストコールおよびIESGプロセスにおける詳細なレビューと貴重な提案に感謝します。
Thanks to the design team led by David Black (members: Ross Callon, Gorry Fairhurst, Xiaohu Xu, and Lucy Yong) for efficiently working out the descriptions for the congestion considerations and IPv6 UDP zero checksum.
輻輳の考慮事項とIPv6 UDPゼロチェックサムの説明を効率的に作成してくれたDavid Black（メンバー：Ross Callon、Gorry Fairhurst、Xiaohu Xu、Lucy Yong）が率いる設計チームに感謝します。
Thanks to David Black and Gorry Fairhurst for their great help in document content and editing.
ドキュメントの内容と編集に多大な協力をいただいたDavid BlackとGorry Fairhurstに感謝します。
Contributors
貢献者
The following people all contributed significantly to this document and are listed in alphabetical order:
次の人々はすべてこのドキュメントに大きく貢献し、アルファベット順にリストされています：
David Black EMC Corporation 176 South Street Hopkinton, MA 01748 United States of America
デビッドブラックEMCコーポレーション176サウスストリートホプキントン、MA 01748アメリカ合衆国
Email: david.black@emc.com
Ross Callon Juniper Networks 10 Technology Park Drive Westford, MA 01886 United States of America
ロスキャロンジュニパーネットワークス10テクノロジーパークドライブウェストフォード、マサチューセッツ州01886アメリカ合衆国
Email: rcallon@juniper.net
John E. Drake Juniper Networks
ジョンE.ドレイクジュニパーネットワークス
Email: jdrake@juniper.net Gorry Fairhurst University of Aberdeen
メール：jdrake@juniper.net Gorry Fairhurst University of Aberdeen
Email: gorry@erg.abdn.ac.uk
Yongbing Fan China Telecom Guangzhou China
ヨーヨーパンプキンパイファンチャイナテレコム広州中国
Email: fanyb@gsta.com
Phone: +86 20 38639121
Adrian Farrel Juniper Networks
エイドリアンファレルジュニパーネットワークス
Email: adrian@olddog.co.uk
Vishwas Manral
信頼委員会
Email: vishwas@ionosnetworks.com
Carlos Pignataro Cisco Systems 7200-12 Kit Creek Road Research Triangle Park, NC 27709 United States of America
カルロスピグナタロシスコシステムズ7200-12キットクリークロードリサーチトライアングルパーク、ノースカロライナ州27709アメリカ合衆国
Email: cpignata@cisco.com
Authors' Addresses
著者のアドレス
Lucy Yong Huawei Technologies, USA
Lucy Yong hu Aはアメリカのテクノロジーです
Email: lucy.yong@huawei.com
Edward Crabbe Oracle
エドワードクラブオラクル
Email: edward.crabbe@gmail.com
Xiaohu Xu Huawei Technologies Beijing, China
ξOutbackX uh UAは中国、北京のテクノロジー
Email: xuxiaohu@huawei.com
Tom Herbert Facebook 1 Hacker Way Menlo Park, CA
トムハーバートFacebook 1ハッカーウェイメンローパーク、カリフォルニア州
Email: tom@herbertland.com