[要約] RFC 8085は、UDPの使用ガイドラインを提供するものであり、UDPの効果的な使用方法とベストプラクティスを示しています。このRFCの目的は、ネットワークアプリケーションの開発者やネットワーク管理者に、UDPを効果的に利用するための指針を提供することです。
Internet Engineering Task Force (IETF) L. Eggert
Request for Comments: 8085 NetApp
BCP: 145 G. Fairhurst
Obsoletes: 5405 University of Aberdeen
Category: Best Current Practice G. Shepherd
ISSN: 2070-1721 Cisco Systems
March 2017
UDP Usage Guidelines
UDP使用ガイドライン
Abstract
概要
The User Datagram Protocol (UDP) provides a minimal message-passing transport that has no inherent congestion control mechanisms. This document provides guidelines on the use of UDP for the designers of applications, tunnels, and other protocols that use UDP. Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, middlebox traversal, the use of Explicit Congestion Notification (ECN), Differentiated Services Code Points (DSCPs), and ports.
ユーザーデータグラムプロトコル（UDP）は、固有の輻輳制御メカニズムを持たない最小限のメッセージパッシングトランスポートを提供します。このドキュメントは、UDPを使用するアプリケーション、トンネル、およびその他のプロトコルの設計者向けに、UDPの使用に関するガイドラインを提供します。輻輳制御ガイドラインが主な焦点ですが、このドキュメントには、メッセージサイズ、信頼性、チェックサム、ミドルボックストラバーサル、明示的輻輳通知（ECN）の使用、DiffServコードポイント（DSCP）、ポートなど、他のトピックに関するガイダンスも含まれています。
Because congestion control is critical to the stable operation of the Internet, applications and other protocols that choose to use UDP as an Internet transport must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic. They may also need to implement additional mechanisms, depending on how they use UDP.
輻輳制御はインターネットの安定した動作にとって重要であるため、UDPをインターネットトランスポートとして使用することを選択するアプリケーションやその他のプロトコルは、輻輳の崩壊を防ぎ、同時トラフィックとある程度の公平性を確立するメカニズムを採用する必要があります。また、UDPの使用方法によっては、追加のメカニズムを実装する必要がある場合もあります。
Some guidance is also applicable to the design of other protocols (e.g., protocols layered directly on IP or via IP-based tunnels), especially when these protocols do not themselves provide congestion control.
一部のガイダンスは、特にこれらのプロトコル自体が輻輳制御を提供しない場合に、他のプロトコル（IP上に直接またはIPベースのトンネルを介して直接階層化されたプロトコルなど）の設計にも適用できます。
This document obsoletes RFC 5405 and adds guidelines for multicast UDP usage.
このドキュメントはRFC 5405を廃止し、マルチキャストUDPの使用に関するガイドラインを追加します。
Status of This Memo
本文書の状態
This memo documents an Internet Best Current Practice.
このメモは、インターネットの現在のベストプラクティスを文書化したものです。
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 BCPs is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 BCPの詳細については、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/rfc8085.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8085で入手できます。
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 ....................................................3
2. Terminology .....................................................5
3. UDP Usage Guidelines ............................................5
3.1. Congestion Control Guidelines ..............................6
3.2. Message Size Guidelines ...................................19
3.3. Reliability Guidelines ....................................21
3.4. Checksum Guidelines .......................................22
3.5. Middlebox Traversal Guidelines ............................25
3.6. Limited Applicability and Controlled Environments .........27
4. Multicast UDP Usage Guidelines .................................28
4.1. Multicast Congestion Control Guidelines ...................30
4.2. Message Size Guidelines for Multicast .....................32
5. Programming Guidelines .........................................32
5.1. Using UDP Ports ...........................................34
5.2. ICMP Guidelines ...........................................37
6. Security Considerations ........................................38
7. Summary ........................................................40
8. References .....................................................42
8.1. Normative References ......................................42
8.2. Informative References ....................................43
Appendix A. .......................................................53
Acknowledgments ...................................................55
Authors' Addresses ................................................55
The User Datagram Protocol (UDP) [RFC768] provides a minimal, unreliable, best-effort, message-passing transport to applications and other protocols (such as tunnels) that wish to operate over IP. Both are simply called "applications" in the remainder of this document.
ユーザーデータグラムプロトコル（UDP）[RFC768]は、IPを介して動作するアプリケーションやその他のプロトコル（トンネルなど）に、最小限の、信頼できない、ベストエフォートのメッセージパッシングトランスポートを提供します。このドキュメントの残りの部分では、両方とも単に「アプリケーション」と呼ばれます。
Compared to other transport protocols, UDP and its UDP-Lite variant [RFC3828] are unique in that they do not establish end-to-end connections between communicating end systems. UDP communication consequently does not incur connection establishment and teardown overheads, and there is minimal associated end-system state. Because of these characteristics, UDP can offer a very efficient communication transport to some applications.
他のトランスポートプロトコルと比較して、UDPとそのUDP-Liteバリアント[RFC3828]は、通信するエンドシステム間のエンドツーエンド接続を確立しないという点で独特です。その結果、UDP通信では接続の確立と破棄のオーバーヘッドが発生せず、関連するエンドシステムの状態が最小限に抑えられます。これらの特性により、UDPは一部のアプリケーションに非常に効率的な通信トランスポートを提供できます。
A second unique characteristic of UDP is that it provides no inherent congestion control mechanisms. On many platforms, applications can send UDP datagrams at the line rate of the platform's link interface, which is often much greater than the available end-to-end path capacity, and doing so contributes to congestion along the path. [RFC2914] describes the best current practice for congestion control in the Internet. It identifies two major reasons why congestion control mechanisms are critical for the stable operation of the Internet:
UDPの2番目のユニークな特性は、固有の輻輳制御メカニズムを提供しないことです。多くのプラットフォームでは、アプリケーションは、プラットフォームのリンクインターフェイスのラインレートでUDPデータグラムを送信できます。これは、利用可能なエンドツーエンドパス容量よりもはるかに大きいことが多く、これによりパスに沿った輻輳が発生します。 [RFC2914]は、インターネットにおける輻輳制御の現在のベストプラクティスについて説明しています。これは、インターネットの安定した運用のために輻輳制御メカニズムが重要である2つの主な理由を特定します。
1. The prevention of congestion collapse, i.e., a state where an increase in network load results in a decrease in useful work done by the network.
1. 輻輳の崩壊の防止、つまりネットワーク負荷の増加がネットワークによって実行される有用な作業の減少をもたらす状態。
2. The establishment of a degree of fairness, i.e., allowing multiple flows to share the capacity of a path reasonably equitably.
2. ある程度の公平性の確立。つまり、複数のフローがパスの容量を合理的に公平に共有できるようにします。
Because UDP itself provides no congestion control mechanisms, it is up to the applications that use UDP for Internet communication to employ suitable mechanisms to prevent congestion collapse and establish a degree of fairness. [RFC2309] discusses the dangers of congestion-unresponsive flows and states that "all UDP-based streaming applications should incorporate effective congestion avoidance mechanisms." [RFC7567] reaffirms this statement. This is an important requirement, even for applications that do not use UDP for streaming. In addition, congestion-controlled transmission is of benefit to an application itself, because it can reduce self-induced packet loss, minimize retransmissions, and hence reduce delays. Congestion control is essential even at relatively slow transmission rates. For example, an application that generates five 1500-byte UDP datagrams in one second can already exceed the capacity of a 56 Kb/s path. For applications that can operate at higher, potentially unbounded data rates, congestion control becomes vital to prevent congestion collapse and establish some degree of fairness. Section 3 describes a number of simple guidelines for the designers of such applications.
UDP自体は輻輳制御メカニズムを提供しないため、インターネット通信にUDPを使用するアプリケーションは、輻輳の崩壊を防ぎ、ある程度の公平性を確立するための適切なメカニズムを採用する必要があります。 [RFC2309]は、輻輳に応答しないフローの危険性について説明し、「すべてのUDPベースのストリーミングアプリケーションには効果的な輻輳回避メカニズムを組み込む必要がある」と述べています。 [RFC7567]はこの声明を再確認します。これは、ストリーミングにUDPを使用しないアプリケーションでも重要な要件です。さらに、輻輳制御の送信は、アプリケーション自体にメリットがあります。これは、自己誘導によるパケット損失を減らし、再送信を最小限に抑え、遅延を減らすことができるためです。比較的遅い伝送速度でも輻輳制御は不可欠です。たとえば、1秒で5つの1500バイトのUDPデータグラムを生成するアプリケーションは、56 Kb / sパスの容量をすでに超えている可能性があります。より高い潜在的に無制限のデータレートで動作できるアプリケーションの場合、輻輳制御は、輻輳の崩壊を防ぎ、ある程度の公平性を確立するために不可欠になります。セクション3では、このようなアプリケーションの設計者向けのいくつかの簡単なガイドラインについて説明します。
A UDP datagram is carried in a single IP packet and is hence limited to a maximum payload of 65,507 bytes for IPv4 and 65,527 bytes for IPv6. The transmission of large IP packets usually requires IP fragmentation. Fragmentation decreases communication reliability and efficiency and should be avoided. IPv6 allows the option of transmitting large packets ("jumbograms") without fragmentation when all link layers along the path support this [RFC2675]. Some of the guidelines in Section 3 describe how applications should determine appropriate message sizes. Other sections of this document provide guidance on reliability, checksums, middlebox traversal and use of multicast.
UDPデータグラムは単一のIPパケットで伝送されるため、IPv4の場合は最大ペイロード65,507バイト、IPv6の場合は最大65,527バイトに制限されます。大きなIPパケットの送信には、通常、IPフラグメンテーションが必要です。断片化は通信の信頼性と効率を低下させるため、回避する必要があります。 IPv6では、パスに沿ったすべてのリンク層がこれをサポートしている場合、断片化せずに大きなパケット（「ジャンボグラム」）を送信するオプションを使用できます[RFC2675]。セクション3のガイドラインのいくつかは、アプリケーションが適切なメッセージサイズを決定する方法を説明しています。このドキュメントの他のセクションでは、信頼性、チェックサム、ミドルボックストラバーサル、およびマルチキャストの使用に関するガイダンスを提供します。
This document provides guidelines and recommendations. Although most UDP applications are expected to follow these guidelines, there do exist valid reasons why a specific application may decide not to follow a given guideline. In such cases, it is RECOMMENDED that application designers cite the respective section(s) of this document in the technical specification of their application or protocol and explain their rationale for their design choice.
このドキュメントはガイドラインと推奨事項を提供します。ほとんどのUDPアプリケーションはこれらのガイドラインに従うことが期待されていますが、特定のアプリケーションが所定のガイドラインに従わないと決定する正当な理由が存在します。そのような場合、アプリケーション設計者は、アプリケーションまたはプロトコルの技術仕様でこのドキュメントのそれぞれのセクションを引用し、設計の選択の根拠を説明することが推奨されます。
[RFC5405] was scoped to provide guidelines for unicast applications only, whereas this document also provides guidelines for UDP flows that use IP anycast, multicast, broadcast, and applications that use UDP tunnels to support IP flows.
[RFC5405]は、ユニキャストアプリケーションのみのガイドラインを提供するためにスコープされましたが、このドキュメントは、IPエニーキャスト、マルチキャスト、ブロードキャスト、およびUDPトンネルを使用してIPフローをサポートするアプリケーションを使用するUDPフローのガイドラインも提供します。
Finally, although this document specifically refers to usage of UDP, the spirit of some of its guidelines also applies to other message-passing applications and protocols (specifically on the topics of congestion control, message sizes, and reliability). Examples include signaling, tunnel or control applications that choose to run directly over IP by registering their own IP protocol number with IANA. This document is expected to provide useful background reading to the designers of such applications and protocols.
最後に、このドキュメントでは特にUDPの使用について言及していますが、そのガイドラインの一部の精神は、他のメッセージパッシングアプリケーションおよびプロトコル（特に、輻輳制御、メッセージサイズ、および信頼性のトピック）にも適用されます。例としては、IANAに独自のIPプロトコル番号を登録することにより、IP経由で直接実行することを選択するシグナリング、トンネル、または制御アプリケーションが含まれます。このドキュメントは、そのようなアプリケーションやプロトコルの設計者に役立つ背景情報を提供することが期待されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "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」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこの文書の "は、[RFC2119]で説明されているように解釈されます。
Internet paths can have widely varying characteristics, including transmission delays, available bandwidths, congestion levels, reordering probabilities, supported message sizes, or loss rates. Furthermore, the same Internet path can have very different conditions over time. Consequently, applications that may be used on the Internet MUST NOT make assumptions about specific path characteristics. They MUST instead use mechanisms that let them operate safely under very different path conditions. Typically, this requires conservatively probing the current conditions of the Internet path they communicate over to establish a transmission behavior that it can sustain and that is reasonably fair to other traffic sharing the path.
インターネットパスには、伝送遅延、使用可能な帯域幅、輻輳レベル、確率の並べ替え、サポートされるメッセージサイズ、損失率など、さまざまな特性があります。さらに、同じインターネットパスでも、時間の経過に伴って状況が大きく異なる可能性があります。したがって、インターネット上で使用される可能性のあるアプリケーションは、特定のパス特性について仮定をしてはなりません。代わりに、非常に異なるパス条件で安全に動作できるメカニズムを使用する必要があります。通常、これは、通信可能なインターネットパスの現在の状態を慎重に調査して、パスを共有する他のトラフィックに対して妥当である伝送動作を確立する必要があります。
These mechanisms are difficult to implement correctly. For most applications, the use of one of the existing IETF transport protocols is the simplest method of acquiring the required mechanisms. Doing so also avoids issues that protocols using a new IP protocol number face when being deployed over the Internet, where middleboxes that only support TCP and UDP are sometimes present. Consequently, the RECOMMENDED alternative to the UDP usage described in the remainder of this section is the use of an IETF transport protocol such as TCP
これらのメカニズムを正しく実装することは困難です。ほとんどのアプリケーションでは、既存のIETFトランスポートプロトコルのいずれかを使用することが、必要なメカニズムを取得する最も簡単な方法です。そうすることで、新しいIPプロトコル番号を使用するプロトコルが、TCPとUDPのみをサポートするミドルボックスが存在する場合があるインターネット経由で展開するときに直面する問題も回避できます。したがって、このセクションの残りの部分で説明するUDPの使用に推奨される代替策は、TCPなどのIETFトランスポートプロトコルを使用することです。
[RFC793], Stream Control Transmission Protocol (SCTP) [RFC4960], and SCTP Partial Reliability Extension (SCTP-PR) [RFC3758], or Datagram Congestion Control Protocol (DCCP) [RFC4340] with its different congestion control types [RFC4341][RFC4342][RFC5622], or transport protocols specified by the IETF in the future. (UDP-encapsulated SCTP [RFC6951] and DCCP [RFC6773] can offer support for traversing firewalls and other middleboxes where the native protocols are not supported.)
[RFC793]、ストリーム制御伝送プロトコル（SCTP）[RFC4960]、SCTP部分信頼性拡張（SCTP-PR）[RFC3758]、またはデータグラム輻輳制御プロトコル（DCCP）[RFC4340]と、さまざまな輻輳制御タイプ[RFC4341] [ RFC4342] [RFC5622]、または将来IETFによって指定されたトランスポートプロトコル。 （UDPカプセル化SCTP [RFC6951]およびDCCP [RFC6773]は、ネイティブプロトコルがサポートされていないファイアウォールやその他のミドルボックスを通過するためのサポートを提供できます。）
If used correctly, these more fully featured transport protocols are not as "heavyweight" as often claimed. For example, the TCP algorithms have been continuously improved over decades, and they have reached a level of efficiency and correctness that custom application-layer mechanisms will struggle to easily duplicate. In addition, many TCP implementations allow connections to be tuned by an application to its purposes. For example, TCP's "Nagle" algorithm [RFC1122] can be disabled, improving communication latency at the expense of more frequent -- but still congestion controlled -- packet transmissions. Another example is the TCP SYN cookie mechanism [RFC4987], which is available on many platforms. TCP with SYN cookies does not require a server to maintain per-connection state until the connection is established. TCP also requires the end that closes a connection to maintain the TIME-WAIT state that prevents delayed segments from one connection instance from interfering with a later one. Applications that are aware of and designed for this behavior can shift maintenance of the TIME-WAIT state to conserve resources by controlling which end closes a TCP connection [FABER]. Finally, TCP's built-in capacity-probing and awareness of the maximum transmission unit supported by the path (PMTU) results in efficient data transmission that quickly compensates for the initial connection setup delay, in the case of transfers that exchange more than a few segments.
正しく使用すれば、これらのより完全な機能を備えたトランスポートプロトコルは、頻繁に主張されるほど「重い」ものではありません。たとえば、TCPアルゴリズムは数十年にわたって継続的に改善されており、カスタムアプリケーション層メカニズムが簡単に複製するのに苦労する効率と正確さのレベルに達しています。さらに、多くのTCP実装では、アプリケーションが目的に合わせて接続を調整できます。たとえば、TCPの「Nagle」アルゴリズム[RFC1122]を無効にすると、パケットの送信が頻繁に発生しますが、輻輳が制御されますが、通信遅延が改善されます。別の例は、多くのプラットフォームで利用可能なTCP SYNクッキーメカニズム[RFC4987]です。 SYN Cookieを使用するTCPでは、接続が確立されるまで、サーバーが接続ごとの状態を維持する必要はありません。 TCPは、ある接続インスタンスからの遅延セグメントが後の接続インスタンスに干渉するのを防ぐTIME-WAIT状態を維持するために、接続を閉じる側も必要とします。この動作を認識して設計されたアプリケーションは、TCP接続[FABER]を閉じる側を制御することにより、TIME-WAIT状態のメンテナンスをシフトしてリソースを節約できます。最後に、TCPに組み込まれている容量プローブとパス（PMTU）でサポートされる最大伝送ユニットの認識により、効率的なデータ伝送が行われ、数個以上のセグメントを交換する転送の場合に、初期接続セットアップ遅延がすばやく補正されます。 。
If an application or protocol chooses not to use a congestion-controlled transport protocol, it SHOULD control the rate at which it sends UDP datagrams to a destination host, in order to fulfill the requirements of [RFC2914]. It is important to stress that an application SHOULD perform congestion control over all UDP traffic it sends to a destination, independently from how it generates this traffic. For example, an application that forks multiple worker processes or otherwise uses multiple sockets to generate UDP datagrams SHOULD perform congestion control over the aggregate traffic.
アプリケーションまたはプロトコルが輻輳制御のトランスポートプロトコルを使用しないことを選択した場合、[RFC2914]の要件を満たすために、宛先ホストにUDPデータグラムを送信するレートを制御する必要があります（SHOULD）。アプリケーションは、このトラフィックの生成方法とは無関係に、宛先に送信するすべてのUDPトラフィックに対して輻輳制御を実行する必要があることを強調することが重要です。たとえば、複数のワーカープロセスをフォークする、または複数のソケットを使用してUDPデータグラムを生成するアプリケーションは、集約トラフィックに対して輻輳制御を実行する必要があります（SHOULD）。
Several approaches to perform congestion control are discussed in the remainder of this section. This section describes generic topics with an intended emphasis on unicast and anycast [RFC1546] usage. Not all approaches discussed below are appropriate for all UDP-transmitting applications. Section 3.1.2 discusses congestion control options for applications that perform bulk transfers over UDP. Such applications can employ schemes that sample the path over several subsequent round-trips during which data is exchanged to determine a sending rate that the path at its current load can support. Other applications only exchange a few UDP datagrams with a destination. Section 3.1.3 discusses congestion control options for such "low data-volume" applications. Because they typically do not transmit enough data to iteratively sample the path to determine a safe sending rate, they need to employ different kinds of congestion control mechanisms. Section 3.1.11 discusses congestion control considerations when UDP is used as a tunneling protocol. Section 4 provides additional recommendations for broadcast and multicast usage.
このセクションの残りの部分では、輻輳制御を実行するためのいくつかのアプローチについて説明します。このセクションでは、ユニキャストおよびエニーキャスト[RFC1546]の使用に重点を置いて、一般的なトピックについて説明します。以下で説明するすべてのアプローチがすべてのUDP送信アプリケーションに適しているわけではありません。セクション3.1.2では、UDPを介してバルク転送を実行するアプリケーションの輻輳制御オプションについて説明します。そのようなアプリケーションは、現在の負荷でのパスがサポートできる送信レートを決定するためにデータが交換される複数の後続のラウンドトリップでパスをサンプリングするスキームを採用できます。他のアプリケーションは、宛先と少数のUDPデータグラムを交換するだけです。セクション3.1.3では、このような「データ量が少ない」アプリケーションの輻輳制御オプションについて説明します。通常は、パスを繰り返しサンプリングして安全な送信レートを決定するのに十分なデータを送信しないため、さまざまな種類の輻輳制御メカニズムを採用する必要があります。セクション3.1.11では、UDPがトンネリングプロトコルとして使用されている場合の輻輳制御の考慮事項について説明します。セクション4では、ブロードキャストおよびマルチキャストの使用に関する追加の推奨事項を示します。
It is important to note that congestion control should not be viewed as an add-on to a finished application. Many of the mechanisms discussed in the guidelines below require application support to operate correctly. Application designers need to consider congestion control throughout the design of their application, similar to how they consider security aspects throughout the design process.
輻輳制御は、完成したアプリケーションのアドオンと見なすべきではないことに注意することが重要です。以下のガイドラインで説明するメカニズムの多くは、正しく動作するためにアプリケーションのサポートを必要とします。アプリケーション設計者は、設計プロセス全体でセキュリティの側面を考慮する方法と同様に、アプリケーションの設計全体で輻輳制御を考慮する必要があります。
In the past, the IETF has also investigated integrated congestion control mechanisms that act on the traffic aggregate between two hosts, i.e., a framework such as the Congestion Manager [RFC3124], where active sessions may share current congestion information in a way that is independent of the transport protocol. Such mechanisms have currently failed to see deployment, but would otherwise simplify the design of congestion control mechanisms for UDP sessions, so that they fulfill the requirements in [RFC2914].
過去には、IETFは、2つのホスト間のトラフィック集約に作用する統合された輻輳制御メカニズム、つまり、アクティブなセッションが独立した方法で現在の輻輳情報を共有できるCongestion Manager [RFC3124]などのフレームワークも調査しましたトランスポートプロトコルの。このようなメカニズムは現在のところ展開を確認できていませんが、UDPセッションの輻輳制御メカニズムの設計を簡素化して、[RFC2914]の要件を満たすようにします。
Understanding the latency between communicating endpoints is usually a crucial part of effective congestion control implementations for protocols and applications. Latency estimation can be used in a number of protocol functions, such as calculating a congestion-controlled transmission rate, triggering retransmission, and detecting packet loss. Additional protocol functions, for example, determining an interval for probing a path, determining an interval between keep-alive messages, determining an interval for measuring the quality of experience, or determining if a remote endpoint has responded to a request to perform an action, typically operate over longer timescales than congestion control and therefore are not covered in this section.
通信するエンドポイント間の待ち時間を理解することは、通常、プロトコルとアプリケーションの効果的な輻輳制御実装の重要な部分です。レイテンシ推定は、輻輳で制御された送信レートの計算、再送信のトリガー、パケット損失の検出など、多くのプロトコル機能で使用できます。追加のプロトコル機能。たとえば、パスをプローブする間隔の決定、キープアライブメッセージの間隔の決定、エクスペリエンスの品質を測定する間隔の決定、またはリモートエンドポイントがアクションの実行要求に応答したかどうかの決定、通常、輻輳制御よりも長いタイムスケールで動作するため、このセクションでは説明しません。
The general recommendation in this document is that applications SHOULD leverage existing congestion control techniques and the latency estimators specified therein (see next subsection). The following guidelines are provided for applications that need to design their own latency estimation mechanisms.
このドキュメントの一般的な推奨事項は、アプリケーションは、既存の輻輳制御技術とそこに指定されているレイテンシエスティメータを利用する必要があることです（次のサブセクションを参照）。以下のガイドラインは、独自のレイテンシ推定メカニズムを設計する必要があるアプリケーション向けに提供されています。
The guidelines are framed in terms of "latency" and not "round-trip time" because some situations require characterizing only the network-based latency (e.g., TCP-Friendly Rate Control (TFRC) [RFC5348]), while other cases necessitate inclusion of the time required by the remote endpoint to provide feedback (e.g., developing an understanding of when to retransmit a message).
ガイドラインは「ラウンドトリップ時間」ではなく「レイテンシ」の観点からフレーム化されています。状況によっては、ネットワークベースのレイテンシ（例：TCP-Friendly Rate Control（TFRC）[RFC5348]）のみを特徴付ける必要があるため、他のケースでは含める必要があります。フィードバックを提供するためにリモートエンドポイントが必要とする時間（たとえば、メッセージを再送信するタイミングの理解を深める）。
The latency between endpoints is generally a dynamic property. Therefore, estimates SHOULD represent some sort of averaging of multiple recent measurement samples to account for variance. Leveraging an Exponentially Weighted Moving Average (EWMA) has proven useful for this purpose (e.g., in TCP [RFC6298] and TFRC [RFC5348]).
エンドポイント間のレイテンシは一般に動的なプロパティです。したがって、推定値は、分散を考慮するために、最近の複数の測定サンプルのある種の平均を表す必要があります（SHOULD）。指数加重移動平均（EWMA）の活用は、この目的に役立つことが証明されています（たとえば、TCP [RFC6298]およびTFRC [RFC5348]）。
Independent latency estimates SHOULD be maintained for each destination with which an endpoint communicates.
独立したレイテンシ推定値は、エンドポイントが通信する宛先ごとに維持する必要があります（SHOULD）。
Latency samples MUST NOT be derived from ambiguous transactions. The canonical example is in a protocol that retransmits data, but subsequently cannot determine which copy is being acknowledged. This ambiguity makes correct computation of the latency problematic. See the discussion of Karn's algorithm in [RFC6298]. This requirement ensures a sender establishes a sound estimate of the latency without relying on misleading measurements.
待ち時間サンプルは、あいまいなトランザクションから派生してはなりません。標準的な例は、データを再送信するプロトコルにありますが、その後、どのコピーが確認応答されているかを判別できません。このあいまいさにより、待ち時間の正確な計算が困難になります。 [RFC6298]のカーンのアルゴリズムの説明を参照してください。この要件により、送信者は、誤解を招く測定に依存することなく、遅延の適切な見積もりを確立できます。
When a latency estimate is used to arm a timer that provides loss detection -- with or without retransmission -- expiry of the timer MUST be interpreted as an indication of congestion in the network, causing the sending rate to be adapted to a safe conservative rate (e.g., TCP collapses the congestion window to one segment [RFC5681]).
遅延推定を使用して、再送の有無にかかわらず、損失検出を提供するタイマーを準備する場合、タイマーの有効期限は、ネットワークの輻輳を示すものとして解釈されなければならず、送信レートが安全な保守的なレートに適応されるようにする必要があります。 （例えば、TCPは輻輳ウィンドウを1つのセグメントに折りたたみます[RFC5681]）。
Some applications require an initial latency estimate before the latency between endpoints can be empirically sampled. For instance, when arming a retransmission timer, an initial value is needed to protect the messages sent before the endpoints sample the latency. This initial latency estimate SHOULD generally be as conservative (large) as possible for the given application. For instance, in the absence of any knowledge about the latency of a path, TCP requires the initial Retransmission Timeout (RTO) to be set to no less than 1 second [RFC6298]. UDP applications SHOULD similarly use an initial latency estimate of 1 second. Values shorter than 1 second can be problematic (see the data analysis in the appendix of [RFC6298]).
一部のアプリケーションでは、エンドポイント間のレイテンシを経験的にサンプリングする前に、初期レイテンシの見積もりが必要です。たとえば、再送信タイマーを設定する場合、エンドポイントがレイテンシをサンプリングする前に送信されるメッセージを保護するために初期値が必要です。この初期レイテンシの見積もりは、通常、特定のアプリケーションに対して可能な限り控えめ（大きい）である必要があります。たとえば、パスのレイテンシに関する知識がない場合、TCPでは初期の再送信タイムアウト（RTO）を1秒以上に設定する必要があります[RFC6298]。 UDPアプリケーションも同様に、1秒の初期レイテンシ推定値を使用する必要があります。 1秒より短い値は問題になる可能性があります（[RFC6298]の付録のデータ分析を参照してください）。
Applications that perform bulk transmission of data to a peer over UDP, i.e., applications that exchange more than a few UDP datagrams per RTT, SHOULD implement TFRC [RFC5348], window-based TCP-like congestion control, or otherwise ensure that the application complies with the congestion control principles.
UDPを介してピアへのデータのバルク送信を実行するアプリケーション、つまり、RTTごとに少数のUDPデータグラムを交換するアプリケーションは、TFRC [RFC5348]、ウィンドウベースのTCPのような輻輳制御を実装する必要があります。輻輳制御の原則。
TFRC has been designed to provide both congestion control and fairness in a way that is compatible with the IETF's other transport protocols. If an application implements TFRC, it need not follow the remaining guidelines in Section 3.1.2, because TFRC already addresses them, but it SHOULD still follow the remaining guidelines in the subsequent subsections of Section 3.
TFRCは、IETFの他のトランスポートプロトコルと互換性のある方法で、輻輳制御と公平性の両方を提供するように設計されています。アプリケーションがTFRCを実装する場合、TFRCはすでにそれらに対処しているため、セクション3.1.2の残りのガイドラインに従う必要はありませんが、セクション3の後続のサブセクションの残りのガイドラインに従う必要があります。
Bulk-transfer applications that choose not to implement TFRC or TCP-like windowing SHOULD implement a congestion control scheme that results in bandwidth (capacity) use that competes fairly with TCP within an order of magnitude.
TFRCまたはTCPのようなウィンドウ処理を実装しないことを選択するバルク転送アプリケーションは、1桁以内でTCPと公平に競合する帯域幅（容量）の使用をもたらす輻輳制御方式を実装する必要があります（SHOULD）。
Section 2 of [RFC3551] suggests that applications SHOULD monitor the packet-loss rate to ensure that it is within acceptable parameters. Packet loss is considered acceptable if a TCP flow across the same network path under the same network conditions would achieve an average throughput, measured on a reasonable timescale, that is not less than that of the UDP flow. The comparison to TCP cannot be specified exactly, but is intended as an "order-of-magnitude" comparison in timescale and throughput. The recommendations for managing timers specified in Section 3.1.1 also apply.
[RFC3551]のセクション2は、アプリケーションがパケット損失率を監視して、それが許容パラメータ内であることを確認する必要があることを示唆しています。パケット損失は、同じネットワーク条件下で同じネットワークパスを通過するTCPフローが、UDPフローのそれ以上の平均スループットを妥当なタイムスケールで測定する場合に許容できると見なされます。 TCPとの比較を正確に指定することはできませんが、タイムスケールとスループットの「桁違い」の比較を目的としています。セクション3.1.1で指定されたタイマーの管理に関する推奨事項も適用されます。
Finally, some bulk-transfer applications may choose not to implement any congestion control mechanism and instead rely on transmitting across reserved path capacity (see Section 3.1.9). This might be an acceptable choice for a subset of restricted networking environments, but is by no means a safe practice for operation over the wider Internet. When the UDP traffic of such applications leaks out into unprovisioned Internet paths, it can significantly degrade the performance of other traffic sharing the path and even result in congestion collapse. Applications that support an uncontrolled or unadaptive transmission behavior SHOULD NOT do so by default and SHOULD instead require users to explicitly enable this mode of operation, and they SHOULD verify that sufficient path capacity has been reserved for them.
最後に、一部のバルク転送アプリケーションは、輻輳制御メカニズムを実装せず、代わりに予約されたパス容量を介した送信に依存する場合があります（セクション3.1.9を参照）。これは、制限されたネットワーキング環境のサブセットでは許容できる選択かもしれませんが、より広いインターネット上での操作のための安全な方法ではありません。このようなアプリケーションのUDPトラフィックがプロビジョニングされていないインターネットパスに漏洩すると、パスを共有している他のトラフィックのパフォーマンスが大幅に低下し、輻輳が崩壊することさえあります。制御されていない、またはアダプティブではない送信動作をサポートするアプリケーションは、デフォルトではそうすべきではなく（SHOULD）、代わりにユーザーがこの操作モードを明示的に有効にする必要があり、十分なパス容量が確保されていることを確認する必要があります（SHOULD）。
When applications that at any time exchange only a few UDP datagrams with a destination implement TFRC or one of the other congestion control schemes in Section 3.1.2, the network sees little benefit, because those mechanisms perform congestion control in a way that is only effective for longer transmissions.
常に宛先と数個のUDPデータグラムのみを交換するアプリケーションがセクション3.1.2のTFRCまたは他の輻輳制御方式の1つを実装する場合、これらのメカニズムは効果的な方法でのみ輻輳制御を実行するため、ネットワークにはほとんどメリットがありません。より長い伝送のため。
Applications that at any time exchange only a few UDP datagrams with a destination SHOULD still control their transmission behavior by not sending on average more than one UDP datagram per RTT to a destination. Similar to the recommendation in [RFC1536], an application SHOULD maintain an estimate of the RTT for any destination with which it communicates using the methods specified in Section 3.1.1.
いつでも少数のUDPデータグラムのみを宛先と交換するアプリケーションは、RTTあたり平均で複数のUDPデータグラムを宛先に送信しないことにより、送信動作を制御する必要があります（SHOULD）。 [RFC1536]の推奨事項と同様に、アプリケーションは、セクション3.1.1で指定された方法を使用して通信する宛先のRTTの推定値を維持する必要があります（SHOULD）。
Some applications cannot maintain a reliable RTT estimate for a destination. These applications do not need to or are unable to use protocol timers to measure the RTT (Section 3.1.1). Two cases can be identified:
一部のアプリケーションは、宛先の信頼できるRTT見積もりを維持できません。これらのアプリケーションは、RTTを測定するためにプロトコルタイマーを使用する必要がないか、使用できません（セクション3.1.1）。 2つのケースが識別できます。
1. The first case is that of applications that exchange too few UDP datagrams with a peer to establish a statistically accurate RTT estimate but that can monitor the reliability of transmission (Section 3.3). Such applications MAY use a predetermined transmission interval that is exponentially backed off when packets are deemed lost. TCP specifies an initial value of 1 second [RFC6298], which is also RECOMMENDED as an initial value for UDP applications. Some low data-volume applications, e.g., SIP [RFC3261] and General Internet Signaling Transport (GIST) [RFC5971] use an interval of 500 ms, and shorter values are likely problematic in many cases. As in the previous case, note that the initial timeout is not the maximum possible timeout, see Section 3.1.1.
1. 最初のケースは、統計的に正確なRTT推定を確立するにはピアとのUDPデータグラムの交換が少なすぎるが、伝送の信頼性を監視できるアプリケーションの場合です（セクション3.3）。そのようなアプリケーションは、パケットが失われたと見なされたときに指数的にバックオフされる所定の送信間隔を使用してもよい（MAY）。 TCPは1秒の初期値[RFC6298]を指定します。これは、UDPアプリケーションの初期値としても推奨されています。データ量の少ないアプリケーション、たとえばSIP [RFC3261]やGeneral Internet Signaling Transport（GIST）[RFC5971]は500ミリ秒の間隔を使用するため、短い値では多くの場合問題が発生する可能性があります。前のケースと同様に、初期タイムアウトは可能な最大タイムアウトではないことに注意してください。セクション3.1.1を参照してください。
2. A second case of applications cannot maintain an RTT estimate for a destination, because the destination does not send return traffic. Such applications SHOULD NOT send more than one UDP datagram every 3 seconds and SHOULD use an even less aggressive rate when possible. Shorter values are likely problematic in many cases. Note that the sending rate in this case must be more conservative than in the previous cases, because the lack of return traffic prevents the detection of packet loss, i.e., congestion, and the application therefore cannot perform exponential back off to reduce load.
2. アプリケーションの2番目のケースでは、宛先が戻りトラフィックを送信しないため、宛先のRTT見積もりを維持できません。そのようなアプリケーションは、3秒ごとに複数のUDPデータグラムを送信してはならず（SHOULD）、可能な場合はさらに積極的なレートを使用する必要があります（SHOULD）。多くの場合、値が短いと問題が発生する可能性があります。この場合の送信レートは、前のケースよりも控えめにする必要があることに注意してください。リターントラフィックがないと、パケット損失、つまり輻輳の検出が妨げられ、アプリケーションは指数バックオフを実行して負荷を減らすことができないためです。
Applications that communicate bidirectionally SHOULD employ congestion control for both directions of the communication. For example, for a client-server, request-response-style application, clients SHOULD congestion-control their request transmission to a server, and the server SHOULD congestion-control its responses to the clients. Congestion in the forward and reverse directions is uncorrelated, and an application SHOULD either independently detect and respond to congestion along both directions or limit new and retransmitted requests based on acknowledged responses across the entire round-trip path.
双方向で通信するアプリケーションは、通信の両方向に輻輳制御を採用する必要があります（SHOULD）。たとえば、クライアントサーバー、要求応答スタイルのアプリケーションの場合、クライアントはサーバーへの要求の送信を輻輳制御する必要があり（SHOULD）、サーバーはクライアントへの応答を輻輳制御する必要があります（SHOULD）。順方向と逆方向の輻輳は無相関であり、アプリケーションは両方向の輻輳を個別に検出して応答するか、往復パス全体で確認済みの応答に基づいて新しい要求と再送信される要求を制限する必要があります。
Transports such as TCP, SCTP, and DCCP provide timely detection of congestion that results in an immediate reduction of their maximum sending rate when congestion is experienced. This reaction is typically completed 1-2 RTTs after loss/congestion is encountered. Applications using UDP SHOULD implement a congestion control scheme that provides a prompt reaction to signals indicating congestion (e.g., by reducing the rate within the next RTT following a congestion signal).
TCP、SCTP、DCCPなどのトランスポートは、輻輳がタイムリーに検出されるため、輻輳が発生したときに最大送信速度が即座に低下します。この反応は通常、損失/輻輳が発生した後に1〜2 RTTで完了します。 UDP SHOULDを使用するアプリケーションは、（たとえば、輻輳信号に続く次のRTT内のレートを下げることによって）輻輳を示す信号に迅速に対応する輻輳制御方式を実装する必要があります（SHOULD）。
The operation of a UDP congestion control algorithm can be very different from the way TCP operates. This includes congestion controls that respond on timescales that fit applications that cannot usefully work within the "change rate every RTT" model of TCP. Applications that experience a low or varying RTT are particularly vulnerable to sampling errors (e.g., due to measurement noise or timer accuracy). This suggests the need to average loss/congestion and RTT measurements over a longer interval; however, this also can contribute additional delay in detecting congestion. Some applications may not react by reducing their sending rate immediately for various reasons, including the following: RTT and loss measurements are only made periodically (e.g., using RTCP), additional time is required to filter information, or the application is only able to change its sending rate at predetermined interval (e.g., some video codecs).
UDP輻輳制御アルゴリズムの操作は、TCPの操作方法とは大きく異なる場合があります。これには、TCPの「RTTごとの変更率」モデル内で有効に機能できないアプリケーションに適合するタイムスケールで応答する輻輳制御が含まれます。 RTTが低い、または変動するアプリケーションは、（たとえば、測定ノイズやタイマーの精度が原因で）サンプリングエラーに対して特に脆弱です。これは、より長い間隔で損失/輻輳およびRTT測定を平均化する必要性を示唆しています。ただし、これにより、輻輳の検出がさらに遅れることもあります。一部のアプリケーションは、次のようなさまざまな理由により、送信速度をすぐに下げても反応しない場合があります。RTTと損失の測定は定期的にのみ行われる（RTCPを使用するなど）、情報のフィルタリングに追加の時間が必要、またはアプリケーションのみが変更できる所定の間隔での送信レート（例：一部のビデオコーデック）。
When designing a congestion control algorithm, the designer therefore needs to consider the total time taken to reduce the load following a lack of feedback or a congestion event. An application where the most recent RTT measurement is smaller than the actual RTT or the measured loss rate is smaller than the current rate, can result in over estimating the available capacity. Such over-estimation can result in a sending rate that creates congestion to the application or other flows sharing the path capacity, and can contribute to congestion collapse -- both of these need to be avoided.
したがって、輻輳制御アルゴリズムを設計するとき、設計者はフィードバックの欠如または輻輳イベントに続く負荷を削減するのにかかる合計時間を考慮する必要があります。最新のRTT測定値が実際のRTTよりも小さいアプリケーション、または測定された損失率が現在のレートよりも小さいアプリケーションでは、利用可能な容量が過大評価される可能性があります。このような過大評価は、アプリケーションまたは他のフローにパスキャパシティを共有する輻輳を作成する送信レートをもたらし、輻輳の崩壊に寄与する可能性があります-両方を回避する必要があります。
A congestion control designed for UDP SHOULD respond as quickly as possible when it experiences congestion, and it SHOULD take into account both the loss rate and the response time when choosing a new rate. The implemented congestion control scheme SHOULD result in bandwidth (capacity) use that is comparable to that of TCP within an order of magnitude, so that it does not starve other flows sharing a common bottleneck.
UDP用に設計された輻輳制御は、輻輳が発生したときにできるだけ早く応答する必要があり（SHOULD）、新しい速度を選択するときに損失率と応答時間の両方を考慮する必要があります（SHOULD）。実装された輻輳制御スキームは、一般的なボトルネックを共有する他のフローを枯渇させないように、桁違いにTCPのそれに匹敵する帯域幅（容量）の使用をもたらす必要があります（SHOULD）。
UDP applications SHOULD provide mechanisms to regulate the bursts of transmission that the application may send to the network. Many TCP and SCTP implementations provide mechanisms that prevent a sender from generating long bursts at line-rate, since these are known to induce early loss to applications sharing a common network bottleneck. The use of pacing with TCP [ALLMAN] has also been shown to improve the coexistence of TCP flows with other flows. The need to avoid excessive transmission bursts is also noted in specifications for applications (e.g., [RFC7143]).
UDPアプリケーションは、アプリケーションがネットワークに送信する可能性がある送信のバーストを規制するメカニズムを提供する必要があります（SHOULD）。多くのTCPおよびSCTP実装は、送信者がラインレートで長いバーストを生成しないようにするメカニズムを提供します。これらは、共通のネットワークボトルネックを共有するアプリケーションに早期の損失を引き起こすことが知られているためです。 TCP [ALLMAN]でのペーシングの使用は、他のフローとのTCPフローの共存を改善することも示されています。過度の送信バーストを回避する必要性は、アプリケーションの仕様にも記載されています（[RFC7143]など）。
Even low data-volume UDP flows may benefit from packet pacing, e.g., an application that sends three copies of a packet to improve robustness to loss is RECOMMENDED to pace out those three packets over several RTTs, to reduce the probability that all three packets will be lost due to the same congestion event (or other event, such as burst corruption).
データ量が少ないUDPフローでもパケットペーシングの恩恵を受ける可能性があります。たとえば、パケットの3つのコピーを送信して損失へのロバスト性を向上させるアプリケーションは、3つのパケットをいくつかのRTTにわたってペースアウトして、3つすべてのパケットが送信される確率を減らすことをお勧めします。同じ輻輳イベント（またはバースト破損などの他のイベント）により失われる。
Internet applications can use Explicit Congestion Notification (ECN) [RFC3168] to gain benefits for the services they support [RFC8087].
インターネットアプリケーションは、明示的輻輳通知（ECN）[RFC3168]を使用して、サポートするサービス[RFC8087]の利点を得ることができます。
Internet transports, such as TCP, provide a set of mechanisms that are needed to utilize ECN. ECN operates by setting an ECN-capable codepoint (ECT(0) or ECT(1)) in the IP header of packets that are sent. This indicates to ECN-capable network devices (routers and other devices) that they may mark (set the congestion experienced, Congestion Experience (CE) codepoint) rather than drop the IP packet as a signal of incipient congestion.
TCPなどのインターネットトランスポートは、ECNを利用するために必要な一連のメカニズムを提供します。 ECNは、送信されるパケットのIPヘッダーにECN対応のコードポイント（ECT（0）またはECT（1））を設定することによって動作します。これは、ECN対応のネットワークデバイス（ルーターおよびその他のデバイス）に対して、IPパケットを初期の輻輳の信号としてドロップするのではなく、マーク（輻輳経験、輻輳経験（CE）コードポイントを設定）する可能性があることを示します。
UDP applications can also benefit from enabling ECN, providing that the API supports ECN and that they implement the required protocol mechanisms to support ECN.
APIがECNをサポートし、ECNをサポートするために必要なプロトコルメカニズムを実装している場合、UDPアプリケーションもECNを有効にすることでメリットを得られます。
The set of mechanisms required for an application to use ECN over UDP are:
アプリケーションがUDP上でECNを使用するために必要なメカニズムのセットは次のとおりです。
o A sender MUST provide a method to determine (e.g., negotiate) that the corresponding application is able to provide ECN feedback using a compatible ECN method.
o 送信者は、対応するアプリケーションが互換性のあるECNメソッドを使用してECNフィードバックを提供できることを決定する（たとえば、交渉する）メソッドを提供する必要があります。
o A receiver that enables the use of ECN for a UDP port MUST check the ECN field at the receiver for each UDP datagram that it receives on this port.
o UDPポートでECNの使用を有効にする受信者は、このポートで受信する各UDPデータグラムの受信者のECNフィールドを確認する必要があります。
o The receiving application needs to provide feedback of congestion information to the sending application. This MUST report the presence of datagrams received with a CE-mark by providing a mechanism to feed this congestion information back to the sending application. The feedback MAY also report the presence of ECT(1) and ECT(0)/Not-ECT packets [RFC7560]. ([RFC3168] and [RFC7560] specify methods for TCP.)
o 受信アプリケーションは、輻輳情報のフィードバックを送信アプリケーションに提供する必要があります。これは、この輻輳情報を送信アプリケーションにフィードバックするメカニズムを提供することにより、CEマークで受信したデータグラムの存在を報告しなければなりません（MUST）。フィードバックは、ECT（1）およびECT（0）/ Not-ECTパケットの存在も報告する場合があります[RFC7560]。 （[RFC3168]および[RFC7560]は、TCPのメソッドを指定します。）
o An application sending ECN-capable datagrams MUST provide an appropriate congestion reaction when it receives feedback indicating that congestion has been experienced. This ought to result in reduction of the sending rate by the UDP congestion control method (see Section 3.1) that is not less than the reaction of TCP under equivalent conditions.
o ECN対応のデータグラムを送信するアプリケーションは、輻輳が発生したことを示すフィードバックを受信したときに、適切な輻輳反応を提供する必要があります。これは、UDP輻輳制御方式（セクション3.1を参照）による送信レートの低下をもたらすはずです。これは、同等の条件下でのTCPの反応以上です。
o A sender SHOULD detect network paths that do not support the ECN field correctly. When detected, they need to either conservatively react to congestion or even fall back to not using ECN [RFC8087]. This method needs to be robust to changes within the network path that may occur over the lifetime of a session.
o 送信者は、ECNフィールドを正しくサポートしないネットワークパスを検出する必要があります（SHOULD）。検出された場合、輻輳に保守的に対応するか、ECN [RFC8087]を使用しないようにフォールバックする必要があります。この方法は、セッションの存続期間中に発生する可能性があるネットワークパス内の変更に対して堅牢である必要があります。
o A sender is encouraged to provide a mechanism to detect and react appropriately to misbehaving receivers that fail to report CE-marked packets [RFC8087].
o 送信者は、CEマークの付いたパケットを報告できない誤動作している受信者を検出して適切に反応するメカニズムを提供することが推奨されます[RFC8087]。
[RFC6679] provides guidance and an example of this support, by describing a method to allow ECN to be used for UDP-based applications using the Real-Time Protocol (RTP). Applications that cannot provide this set of mechanisms, but wish to gain the benefits of using ECN, are encouraged to use a transport protocol that already supports ECN (such as TCP).
[RFC6679]は、ECNをReal-Time Protocol（RTP）を使用するUDPベースのアプリケーションに使用できるようにする方法を説明することにより、このサポートのガイダンスと例を提供します。この一連のメカニズムを提供できないが、ECNを使用する利点を獲得したいアプリケーションは、すでにECNをサポートしているトランスポートプロトコル（TCPなど）を使用することをお勧めします。
An application using UDP can use the differentiated services (DiffServ) Quality of Service (QoS) framework. To enable differentiated services processing, a UDP sender sets the Differentiated Services Code Point (DSCP) field [RFC2475] in packets sent to the network. Normally, a UDP source/destination port pair will set a single DSCP value for all packets belonging to a flow, but multiple DSCPs can be used as described later in this section. A DSCP may be chosen from a small set of fixed values (the class selector code points), or from a set of recommended values defined in the Per Hop Behavior (PHB) specifications, or from values that have purely local meanings to a specific network that supports DiffServ. In general, packets may be forwarded across multiple networks between source and destination.
UDPを使用するアプリケーションは、差別化サービス（DiffServ）サービス品質（QoS）フレームワークを使用できます。差別化されたサービスの処理を可能にするために、UDP送信者はネットワークに送信されるパケットにDiffServコードポイント（DSCP）フィールド[RFC2475]を設定します。通常、UDPの送信元/宛先ポートのペアは、フローに属するすべてのパケットに単一のDSCP値を設定しますが、このセクションで後述するように、複数のDSCPを使用できます。 DSCPは、固定値（クラスセレクターコードポイント）の小さなセットから、またはホップ単位の動作（PHB）仕様で定義された推奨値のセットから、または特定のネットワークに対して純粋にローカルな意味を持つ値から選択できます。 DiffServをサポートしています。一般に、パケットは送信元と宛先の間の複数のネットワークを介して転送されます。
In setting a non-default DSCP value, an application must be aware that DSCP markings may be changed or removed between the traffic source and destination. This has implications on the design of applications that use DSCPs. Specifically, applications SHOULD be designed not to rely on implementation of a specific network treatment; they need instead to implement congestion control methods to determine if their current sending rate is inducing congestion in the network.
デフォルト以外のDSCP値を設定する場合、アプリケーションは、トラフィックの送信元と宛先の間でDSCPマーキングが変更または削除される可能性があることを認識する必要があります。これは、DSCPを使用するアプリケーションの設計に影響を与えます。具体的には、アプリケーションは特定のネットワーク処理の実装に依存しないように設計する必要があります（SHOULD）。代わりに、現在の送信レートがネットワークで輻輳を引き起こしているかどうかを判断するために、輻輳制御メソッドを実装する必要があります。
[RFC7657] describes the implications of using DSCPs and provides recommendations on using multiple DSCPs within a single network five-tuple (source and destination addresses, source and destination ports, and the transport protocol used, in this case, UDP or UDP-Lite), and particularly the expected impact on transport protocol interactions, with congestion control or reliability functionality (e.g., retransmission, reordering). Use of multiple DSCPs can result in reordering by increasing the set of network forwarding resources used by a sender. It can also increase exposure to resource depletion or failure.
[RFC7657]は、DSCPを使用することの影響を説明し、単一のネットワーク5タプル（送信元と宛先のアドレス、送信元と宛先のポート、および使用されるトランスポートプロトコル（この場合はUDPまたはUDP-Lite））内での複数のDSCPの使用に関する推奨事項を提供します、特に、輻輳制御または信頼性機能（例：再送信、並べ替え）によるトランスポートプロトコルの相互作用への予想される影響。複数のDSCPを使用すると、送信者が使用するネットワーク転送リソースのセットが増えるため、並べ替えが発生する可能性があります。また、リソースの枯渇や障害にさらされる可能性も高くなります。
The IETF usually specifies protocols for use within the Best Effort General Internet. Sometimes it is relevant to specify protocols with a different applicability. An application using UDP can use the integrated services QoS framework. This framework is usually made available within controlled environments (e.g., within a single administrative domain or bilaterally agreed connection between domains). Applications intended for the Internet SHOULD NOT assume that QoS mechanisms are supported by the networks they use, and therefore need to provide congestion control, error recovery, etc., in case the actual network path does not provide provisioned service.
IETFは通常、ベストエフォートの一般的なインターネット内で使用するプロトコルを指定します。異なる適用性を持つプロトコルを指定することが適切な場合があります。 UDPを使用するアプリケーションは、統合サービスQoSフレームワークを使用できます。このフレームワークは通常、制御された環境内（たとえば、単一の管理ドメイン内またはドメイン間の相互に合意した接続内）で使用可能になります。インターネット向けのアプリケーションは、実際のネットワークパスがプロビジョニングされたサービスを提供しない場合に備えて、QoSメカニズムが使用するネットワークでQoSメカニズムがサポートされていることを想定してはならないため、輻輳制御、エラー回復などを提供する必要があります。
Some UDP applications are only expected to be deployed over network paths that use pre-provisioned capacity or capacity reserved using dynamic provisioning, e.g., through the Resource Reservation Protocol (RSVP). Multicast applications are also used with pre-provisioned capacity (e.g., IPTV deployments within access networks). These applications MAY choose not to implement any congestion control mechanism and instead rely on transmitting only on paths where the capacity is provisioned and reserved for this use. This might be an acceptable choice for a subset of restricted networking environments, but is by no means a safe practice for operation over the wider Internet. Applications that choose this option SHOULD carefully and in detail describe the provisioning and management procedures that result in the desired containment.
一部のUDPアプリケーションは、事前にプロビジョニングされた容量または動的プロビジョニングを使用して予約された容量を使用するネットワークパス（リソース予約プロトコル（RSVP）など）を介してのみ展開することが期待されています。マルチキャストアプリケーションは、事前にプロビジョニングされた容量（アクセスネットワーク内のIPTV展開など）でも使用されます。これらのアプリケーションは、輻輳制御メカニズムを実装しないことを選択できます。代わりに、この用途のために容量がプロビジョニングおよび予約されているパスのみでの送信に依存します。これは、制限されたネットワーキング環境のサブセットでは許容できる選択かもしれませんが、より広いインターネット上での操作のための安全な方法ではありません。このオプションを選択するアプリケーションは、望ましい封じ込めをもたらすプロビジョニングおよび管理手順を注意深く詳細に説明する必要があります。
Applications that support an uncontrolled or unadaptive transmission behavior SHOULD NOT do so by default and SHOULD instead require users to explicitly enable this mode of operation.
制御されていない、またはアダプティブでない伝送動作をサポートするアプリケーションは、デフォルトではそうすべきではなく（SHOULD）、代わりに、ユーザーがこの動作モードを明示的に有効にする必要があります。
Applications designed for use within a controlled environment (see Section 3.6) may be able to exploit network management functions to detect whether they are causing congestion, and react accordingly. If the traffic of such applications leaks out into unprovisioned Internet paths, it can significantly degrade the performance of other traffic sharing the path and even result in congestion collapse. Protocols designed for such networks SHOULD provide mechanisms at the network edge to prevent leakage of traffic into unprovisioned Internet paths (e.g., [RFC7510]). To protect other applications sharing the same path, applications SHOULD also deploy an appropriate circuit breaker, as described in Section 3.1.10.
制御された環境（セクション3.6を参照）内で使用するように設計されたアプリケーションは、ネットワーク管理機能を利用して、輻輳を引き起こしているかどうかを検出し、それに応じて対応できる場合があります。このようなアプリケーションのトラフィックがプロビジョニングされていないインターネットパスに漏れると、パスを共有している他のトラフィックのパフォーマンスが大幅に低下し、輻輳が崩壊することさえあります。このようなネットワーク用に設計されたプロトコルは、プロビジョニングされていないインターネットパスへのトラフィックの漏洩を防ぐためのメカニズムをネットワークエッジで提供する必要があります（例：[RFC7510]）。同じパスを共有する他のアプリケーションを保護するために、セクション3.1.10で説明されているように、アプリケーションは適切な回路ブレーカーも展開する必要があります（SHOULD）。
An IETF specification targeting a controlled environment is expected to provide an applicability statement that restricts the application to the controlled environment (see Section 3.6).
制御された環境を対象とするIETF仕様は、アプリケーションを制御された環境に制限する適用性ステートメントを提供することが期待されています（セクション3.6を参照）。
A transport circuit breaker is an automatic mechanism that is used to estimate the congestion caused by a flow, and to terminate (or significantly reduce the rate of) the flow when excessive congestion is detected [RFC8084]. This is a safety measure to prevent congestion collapse (starvation of resources available to other flows), essential for an Internet that is heterogeneous and for traffic that is hard to predict in advance.
トランスポート回路ブレーカーは、フローによって引き起こされる輻輳を推定し、過度の輻輳が検出されたときにフローを終了する（またはそのレートを大幅に下げる）ために使用される自動メカニズムです[RFC8084]。これは、混雑したインターネットや、事前に予測するのが難しいトラフィックにとって不可欠な、輻輳の崩壊（他のフローで利用可能なリソースの枯渇）を防ぐための安全対策です。
A circuit breaker is intended as a protection mechanism of last resort. Under normal circumstances, a circuit breaker should not be triggered; it is designed to protect things when there is severe overload. The goal is usually to limit the maximum transmission rate that reflects the available capacity of a network path. Circuit breakers can operate on individual UDP flows or traffic aggregates, e.g., traffic sent using a network tunnel.
回路ブレーカーは、最後の手段としての保護メカニズムとして使用されます。通常の状況では、回路ブレーカーをトリガーしないでください。これは、過負荷が発生したときに物事を保護するように設計されています。通常、目標は、ネットワークパスの利用可能な容量を反映する最大伝送速度を制限することです。サーキットブレーカーは、個々のUDPフローまたはトラフィック集約（ネットワークトンネルを使用して送信されたトラフィックなど）を操作できます。
[RFC8084] provides guidance and examples on the use of circuit breakers. The use of a circuit breaker in RTP is specified in [RFC8083].
[RFC8084]は、回路ブレーカーの使用に関するガイダンスと例を提供します。 RTPでのサーキットブレーカの使用は、[RFC8083]で指定されています。
Applications used in the general Internet SHOULD implement a transport circuit breaker if they do not implement congestion control or operate a low data-volume service (see Section 3.6). All applications MAY implement a transport circuit breaker [RFC8084] and are encouraged to consider implementing at least a slow-acting transport circuit breaker to provide a protection of last resort for their network traffic.
一般的なインターネットで使用されるアプリケーションは、輻輳制御を実装していないか、データ量の少ないサービスを運用していない場合は、トランスポート回路ブレーカーを実装する必要があります（セクション3.6を参照）。すべてのアプリケーションはトランスポート回路ブレーカー[RFC8084]を実装することができ（MAY）、ネットワークトラフィックの最後の手段の保護を提供するために、少なくとも低速のトランスポート回路ブレーカーの実装を検討することをお勧めします。
One increasingly popular use of UDP is as a tunneling protocol [INT-TUNNELS], where a tunnel endpoint encapsulates the packets of another protocol inside UDP datagrams and transmits them to another tunnel endpoint, which decapsulates the UDP datagrams and forwards the original packets contained in the payload. One example of such a protocol is Teredo [RFC4380]. Tunnels establish virtual links that appear to directly connect locations that are distant in the physical Internet topology and can be used to create virtual (private) networks. Using UDP as a tunneling protocol is attractive when the payload protocol is not supported by middleboxes that may exist along the path, because many middleboxes support transmission using UDP.
UDPの使用が増加している1つは、トンネリングプロトコル[INT-TUNNELS]です。この場合、トンネルエンドポイントは、UDPデータグラム内の別のプロトコルのパケットをカプセル化し、それらを別のトンネルエンドポイントに送信します。これにより、UDPデータグラムのカプセル化が解除され、元のパケットが転送されますペイロード。そのようなプロトコルの一例はTeredo [RFC4380]です。トンネルは、物理的なインターネットトポロジで離れた場所を直接接続しているように見える仮想リンクを確立し、仮想（プライベート）ネットワークの作成に使用できます。多くのミドルボックスがUDPを使用した送信をサポートしているため、パスに沿って存在する可能性があるミドルボックスでペイロードプロトコルがサポートされていない場合、トンネリングプロトコルとしてUDPを使用することは魅力的です。
Well-implemented tunnels are generally invisible to the endpoints that happen to transmit over a path that includes tunneled links. On the other hand, to the routers along the path of a UDP tunnel, i.e., the routers between the two tunnel endpoints, the traffic that a UDP tunnel generates is a regular UDP flow, and the encapsulator and decapsulator appear as regular UDP-sending and UDP-receiving applications. Because other flows can share the path with one or more UDP tunnels, congestion control needs to be considered.
適切に実装されたトンネルは、通常、トンネルリンクを含むパスを介して送信されるエンドポイントからは見えません。一方、UDPトンネルのパスに沿ったルーター、つまり2つのトンネルエンドポイント間のルーターに対しては、UDPトンネルが生成するトラフィックは通常のUDPフローであり、カプセル化装置とカプセル開放装置は通常のUDP送信として表示されます。およびUDP受信アプリケーション。他のフローは1つ以上のUDPトンネルとパスを共有できるため、輻輳制御を考慮する必要があります。
Two factors determine whether a UDP tunnel needs to employ specific congestion control mechanisms: first, whether the payload traffic is IP-based; and second, whether the tunneling scheme generates UDP traffic at a volume that corresponds to the volume of payload traffic carried within the tunnel.
UDPトンネルが特定の輻輳制御メカニズムを使用する必要があるかどうかを決定する2つの要因：最初に、ペイロードトラフィックがIPベースかどうか。次に、トンネリングスキームが、トンネル内で伝送されるペイロードトラフィックのボリュームに対応するボリュームでUDPトラフィックを生成するかどうか。
IP-based unicast traffic is generally assumed to be congestion controlled, i.e., it is assumed that the transport protocols generating IP-based unicast traffic at the sender already employ mechanisms that are sufficient to address congestion on the path. Consequently, a tunnel carrying IP-based unicast traffic should already interact appropriately with other traffic sharing the path, and specific congestion control mechanisms for the tunnel are not necessary.
IPベースのユニキャストトラフィックは、通常、輻輳制御されていると想定されます。つまり、送信元でIPベースのユニキャストトラフィックを生成するトランスポートプロトコルは、パス上の輻輳に対処するのに十分なメカニズムをすでに採用していると想定されます。したがって、IPベースのユニキャストトラフィックを伝送するトンネルは、パスを共有する他のトラフィックとすでに適切に相互作用しているはずであり、トンネルに特定の輻輳制御メカニズムは必要ありません。
However, if the IP traffic in the tunnel is known not to be congestion controlled, additional measures are RECOMMENDED to limit the impact of the tunneled traffic on other traffic sharing the path. For the specific case of a tunnel that carries IP multicast traffic, see Section 4.1.
ただし、トンネル内のIPトラフィックが輻輳制御されていないことがわかっている場合は、パスを共有している他のトラフィックへのトンネルトラフィックの影響を制限するための追加の対策が推奨されます。 IPマルチキャストトラフィックを伝送するトンネルの特定のケースについては、セクション4.1を参照してください。
The following guidelines define these possible cases in more detail:
次のガイドラインは、これらの可能なケースをより詳細に定義しています。
1. A tunnel generates UDP traffic at a volume that corresponds to the volume of payload traffic, and the payload traffic is IP based and congestion controlled.
1. トンネルは、ペイロードトラフィックのボリュームに対応するボリュームでUDPトラフィックを生成します。ペイロードトラフィックはIPベースであり、輻輳が制御されます。
This is arguably the most common case for Internet tunnels. In this case, the UDP tunnel SHOULD NOT employ its own congestion control mechanism, because congestion losses of tunneled traffic will already trigger an appropriate congestion response at the original senders of the tunneled traffic. A circuit breaker mechanism may provide benefit by controlling the envelope of the aggregated traffic.
これは間違いなくインターネットトンネルの最も一般的なケースです。この場合、UDPトンネルは独自の輻輳制御メカニズムを採用すべきではありません。トンネル化されたトラフィックの輻輳損失により、トンネル化されたトラフィックの元の送信者で適切な輻輳応答がすでにトリガーされているためです。サーキットブレーカメカニズムは、集約されたトラフィックのエンベロープを制御することにより、利点を提供します。
Note that this guideline is built on the assumption that most IP-based communication is congestion controlled. If a UDP tunnel is used for IP-based traffic that is known to not be congestion controlled, the next set of guidelines applies.
このガイドラインは、ほとんどのIPベースの通信が輻輳制御されているという前提に基づいて作成されていることに注意してください。輻輳制御されていないことがわかっているIPベースのトラフィックにUDPトンネルが使用される場合、次の一連のガイドラインが適用されます。
2. A tunnel generates UDP traffic at a volume that corresponds to the volume of payload traffic, and the payload traffic is not known to be IP based, or is known to be IP based but not congestion controlled.
2. トンネルは、ペイロードトラフィックのボリュームに対応するボリュームでUDPトラフィックを生成します。ペイロードトラフィックは、IPベースであるか、またはIPベースであるが、輻輳制御されていないことがわかっています。
This can be the case, for example, when some link-layer protocols are encapsulated within UDP (but not all link-layer protocols; some are congestion controlled). Because it is not known that congestion losses of tunneled non-IP traffic will trigger an appropriate congestion response at the senders, the UDP tunnel SHOULD employ an appropriate congestion control mechanism or circuit breaker mechanism designed for the traffic it carries. Because tunnels are usually bulk-transfer applications as far as the intermediate routers are concerned, the guidelines in Section 3.1.2 apply.
たとえば、一部のリンク層プロトコルがUDP内にカプセル化されている場合があります（ただし、すべてのリンク層プロトコルではなく、一部は輻輳制御されています）。トンネル化された非IPトラフィックの輻輳損失が送信側で適切な輻輳応答をトリガーするかどうかは不明であるため、UDPトンネルは、それが運ぶトラフィック用に設計された適切な輻輳制御メカニズムまたは回路ブレーカーメカニズムを採用する必要があります（SHOULD）。トンネルは通常、中間ルーターに関する限りバルク転送アプリケーションであるため、セクション3.1.2のガイドラインが適用されます。
3. A tunnel generates UDP traffic at a volume that does not correspond to the volume of payload traffic, independent of whether the payload traffic is IP based or congestion controlled.
3. トンネルは、ペイロードトラフィックがIPベースであるか輻輳制御されているかに関係なく、ペイロードトラフィックのボリュームに対応しないボリュームでUDPトラフィックを生成します。
Examples of this class include UDP tunnels that send at a constant rate, increase their transmission rates under loss, for example, due to increasing redundancy when Forward Error Correction is used, or are otherwise unconstrained in their transmission behavior. These specialized uses of UDP for tunneling go beyond the scope of the general guidelines given in this document. The implementer of such specialized tunnels SHOULD carefully consider congestion control in the design of their tunneling mechanism and SHOULD consider use of a circuit breaker mechanism.
このクラスの例には、一定の速度で送信するUDPトンネルが含まれます。たとえば、前方誤り訂正が使用される場合の冗長性の増加などにより、損失が発生した場合に伝送速度が増加します。トンネリングのためのUDPのこれらの特殊な使用法は、このドキュメントに記載されている一般的なガイドラインの範囲を超えています。このような特殊なトンネルの実装者は、トンネリングメカニズムの設計で輻輳制御を慎重に検討し、回路ブレーカーメカニズムの使用を検討する必要があります（SHOULD）。
The type of encapsulated payload might be identified by a UDP port; identified by an Ethernet Type or IP protocol number. A tunnel SHOULD provide mechanisms to restrict the types of flows that may be carried by the tunnel. For instance, a UDP tunnel designed to carry IP needs to filter out non-IP traffic at the ingress. This is particularly important when a generic tunnel encapsulation is used (e.g., one that encapsulates using an EtherType value). Such tunnels SHOULD provide a mechanism to restrict the types of traffic that are allowed to be encapsulated for a given deployment (see [INT-TUNNELS]).
カプセル化されたペイロードのタイプは、UDPポートによって識別される場合があります。イーサネットタイプまたはIPプロトコル番号で識別されます。トンネルは、トンネルによって伝送されるフローのタイプを制限するメカニズムを提供する必要があります（SHOULD）。たとえば、IPを伝送するように設計されたUDPトンネルは、入口で非IPトラフィックを除外する必要があります。これは、一般的なトンネルカプセル化（EtherType値を使用してカプセル化するトンネルなど）を使用する場合に特に重要です。このようなトンネルは、特定のデプロイメントでカプセル化できるトラフィックのタイプを制限するメカニズムを提供する必要があります（SHOULD）（[INT-TUNNELS]を参照）。
Designing a tunneling mechanism requires significantly more expertise than needed for many other UDP applications, because tunnels are usually intended to be transparent to the endpoints transmitting over them, so they need to correctly emulate the behavior of an IP link [INT-TUNNELS], for example:
トンネルは通常、それらを介して送信するエンドポイントに対して透過的であることを目的としているため、トンネリングメカニズムを設計するには、他の多くのUDPアプリケーションで必要とされるよりもはるかに多くの専門知識が必要です。そのため、トンネルはIPリンクの動作を正しくエミュレートする必要があります例：
o Requirements for tunnels that carry or encapsulate using ECN code points [RFC6040].
o ECNコードポイントを使用して伝送またはカプセル化するトンネルの要件[RFC6040]。
o Usage of the IP DSCP field by tunnel endpoints [RFC2983].
o トンネルエンドポイントによるIP DSCPフィールドの使用[RFC2983]。
o Encapsulation considerations in the design of tunnels [ENCAP].
o トンネルの設計におけるカプセル化の考慮事項[ENCAP]。
o Usage of ICMP messages [INT-TUNNELS].
o ICMPメッセージの使用[INT-TUNNELS]。
o Handling of fragmentation and packet size for tunnels [INT-TUNNELS].
o トンネルのフラグメンテーションとパケットサイズの処理[INT-TUNNELS]。
o Source port usage for tunnels designed to support equal cost multipath (ECMP) routing (see Section 5.1.1).
o 等コストマルチパス（ECMP）ルーティングをサポートするように設計されたトンネルの送信元ポートの使用（セクション5.1.1を参照）。
o Guidance on the need to protect headers [INT-TUNNELS] and the use of checksums for IPv6 tunnels (see Section 3.4.1).
o ヘッダーを保護する必要性に関するガイダンス[INT-TUNNELS]およびIPv6トンネルのチェックサムの使用（セクション3.4.1を参照）。
o Support for operations and maintenance [INT-TUNNELS].
o 運用と保守のサポート[INT-TUNNELS]。
At the same time, the tunneled traffic is application traffic like any other from the perspective of the networks the tunnel transmits over. This document only touches upon the congestion control considerations for implementing UDP tunnels; a discussion of other required tunneling behavior is out of scope.
同時に、トンネルトラフィックは、トンネルが送信するネットワークの観点からは、他のアプリケーショントラフィックと同じです。このドキュメントでは、UDPトンネルを実装するための輻輳制御の考慮事項についてのみ触れています。その他の必要なトンネリング動作の説明は範囲外です。
IP fragmentation lowers the efficiency and reliability of Internet communication. The loss of a single fragment results in the loss of an entire fragmented packet, because even if all other fragments are received correctly, the original packet cannot be reassembled and delivered. This fundamental issue with fragmentation exists for both IPv4 and IPv6.
IPの断片化は、インターネット通信の効率と信頼性を低下させます。単一のフラグメントが失われると、フラグメント化されたパケット全体が失われます。これは、他のすべてのフラグメントが正しく受信されたとしても、元のパケットを再構成して配信できないためです。このフラグメンテーションに関する基本的な問題は、IPv4とIPv6の両方に存在します。
In addition, some network address translators (NATs) and firewalls drop IP fragments. The network address translation performed by a NAT only operates on complete IP packets, and some firewall policies also require inspection of complete IP packets. Even with these being the case, some NATs and firewalls simply do not implement the necessary reassembly functionality; instead, they choose to drop all fragments. Finally, [RFC4963] documents other issues specific to IPv4 fragmentation.
さらに、一部のネットワークアドレストランスレータ（NAT）とファイアウォールはIPフラグメントをドロップします。 NATによって実行されるネットワークアドレス変換は完全なIPパケットでのみ動作し、一部のファイアウォールポリシーでは完全なIPパケットの検査も必要です。これらが当てはまる場合でも、一部のNATおよびファイアウォールは、必要な再構成機能を実装していません。代わりに、すべてのフラグメントをドロップすることを選択します。最後に、[RFC4963]はIPv4フラグメンテーションに固有の他の問題を文書化しています。
Due to these issues, an application SHOULD NOT send UDP datagrams that result in IP packets that exceed the Maximum Transmission Unit (MTU) along the path to the destination. Consequently, an application SHOULD either use the path MTU information provided by the IP layer or implement Path MTU Discovery (PMTUD) itself [RFC1191] [RFC1981] [RFC4821] to determine whether the path to a destination will support its desired message size without fragmentation.
これらの問題により、アプリケーションは、宛先へのパスに沿ってIPパケットが最大転送単位（MTU）を超えるようなUDPデータグラムを送信してはなりません（SHOULD NOT）。したがって、アプリケーションは、IP層によって提供されるパスMTU情報を使用するか、パスMTUディスカバリー（PMTUD）自体を実装する必要があります[RFC1191] [RFC1981] [RFC4821]。宛先へのパスが断片化なしで目的のメッセージサイズをサポートするかどうかを判断します。
However, the ICMP messages that enable path MTU discovery are being increasingly filtered by middleboxes (including Firewalls) [RFC4890]. When the path includes a tunnel, some devices acting as a tunnel ingress discard ICMP messages that originate from network devices over which the tunnel passes, preventing these from reaching the UDP endpoint.
ただし、パスMTU検出を有効にするICMPメッセージは、ミドルボックス（ファイアウォールを含む）によってますますフィルタリングされています[RFC4890]。パスにトンネルが含まれている場合、トンネルの入口として機能する一部のデバイスは、トンネルが通過するネットワークデバイスから送信されたICMPメッセージを破棄し、UDPエンドポイントに到達しないようにします。
Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821] does not rely upon network support for ICMP messages and is therefore considered more robust than standard PMTUD. It is not susceptible to "black holing" of ICMP messages. To operate, PLPMTUD requires changes to the way the transport is used: both to transmit probe packets and to account for the loss or success of these probes. This not only updates the PMTU algorithm, it also impacts loss recovery, congestion control, etc. These updated mechanisms can be implemented within a connection-oriented transport (e.g., TCP, SCTP, DCCP), but they are not a part of UDP; this type of feedback is not typically present for unidirectional applications.
パケット化レイヤーパスMTU検出（PLPMTUD）[RFC4821]は、ICMPメッセージのネットワークサポートに依存しないため、標準のPMTUDよりも堅牢であると見なされています。 ICMPメッセージの「ブラックホール」の影響を受けません。 PLPMTUDを操作するには、トランスポートの使用方法を変更する必要があります。プローブパケットを送信するためと、これらのプローブの損失または成功を説明するための両方です。これは、PMTUアルゴリズムを更新するだけでなく、損失回復、輻輳制御などにも影響を与えます。これらの更新されたメカニズムは、コネクション型トランスポート（TCP、SCTP、DCCPなど）内に実装できますが、UDPの一部ではありません。このタイプのフィードバックは、通常、単方向アプリケーションには存在しません。
Therefore, PLPMTUD places additional design requirements on a UDP application that wishes to use this method. This is especially true for UDP tunnels, because the overhead of sending probe packets needs to be accounted for and may require adding a congestion control mechanism to the tunnel (see Section 3.1.11) as well as complicating the data path at a tunnel decapsulator.
したがって、PLPMTUDは、この方法を使用したいUDPアプリケーションに追加の設計要件を課します。これは特にUDPトンネルに当てはまります。プローブパケットを送信する際のオーバーヘッドを考慮する必要があり、トンネルへの輻輳制御メカニズムの追加（セクション3.1.11を参照）や、トンネルのカプセル化解除装置でのデータパスが複雑になる場合があるためです。
Applications that do not follow the recommendation to do PMTU/PLPMTUD discovery SHOULD still avoid sending UDP datagrams that would result in IP packets that exceed the path MTU. Because the actual path MTU is unknown, such applications SHOULD fall back to sending messages that are shorter than the default effective MTU for sending (EMTU_S in [RFC1122]). For IPv4, EMTU_S is the smaller of 576 bytes and the first-hop MTU [RFC1122]. For IPv6, EMTU_S is 1280 bytes [RFC2460]. The effective PMTU for a directly connected destination (with no routers on the path) is the configured interface MTU, which could be less than the maximum link payload size. Transmission of minimum-sized UDP datagrams is inefficient over paths that support a larger PMTU, which is a second reason to implement PMTU discovery.
PMTU / PLPMTUDディスカバリーを実行するための推奨事項に従わないアプリケーションは、パスMTUを超えるIPパケットが発生する可能性があるUDPデータグラムを送信しないようにする必要があります（SHOULD）。実際のパスMTUは不明であるため、このようなアプリケーションは、デフォルトの送信用有効MTU（[RFC1122]のEMTU_S）よりも短いメッセージの送信にフォールバックする必要があります（SHOULD）。 IPv4の場合、EMTU_Sは576バイトと最初のホップのMTU [RFC1122]の小さい方です。 IPv6の場合、EMTU_Sは1280バイトです[RFC2460]。直接接続された宛先（パス上にルーターがない）の有効なPMTUは、構成されたインターフェイスMTUであり、最大リンクペイロードサイズよりも小さい場合があります。最小サイズのUDPデータグラムの送信は、より大きなPMTUをサポートするパスでは非効率的です。これが、PMTU検出を実装する2番目の理由です。
To determine an appropriate UDP payload size, applications MUST subtract the size of the IP header (which includes any IPv4 optional headers or IPv6 extension headers) as well as the length of the UDP header (8 bytes) from the PMTU size. This size, known as the Maximum Segment Size (MSS), can be obtained from the TCP/IP stack [RFC1122].
適切なUDPペイロードサイズを決定するには、アプリケーションはIPヘッダーのサイズ（IPv4オプションヘッダーまたはIPv6拡張ヘッダーを含む）と、UDTUヘッダーの長さ（8バイト）をPMTUサイズから差し引く必要があります。最大セグメントサイズ（MSS）と呼ばれるこのサイズは、TCP / IPスタック[RFC1122]から取得できます。
Applications that do not send messages that exceed the effective PMTU of IPv4 or IPv6 need not implement any of the above mechanisms. Note that the presence of tunnels can cause an additional reduction of the effective PMTU [INT-TUNNELS], so implementing PMTU discovery may be beneficial.
IPv4またはIPv6の有効なPMTUを超えるメッセージを送信しないアプリケーションは、上記のメカニズムを実装する必要はありません。トンネルが存在すると、有効なPMTU [INT-TUNNELS]がさらに減少する可能性があるため、PMTUディスカバリーを実装すると有益な場合があります。
Applications that fragment an application-layer message into multiple UDP datagrams SHOULD perform this fragmentation so that each datagram can be received independently, and be independently retransmitted in the case where an application implements its own reliability mechanisms.
アプリケーション層のメッセージを複数のUDPデータグラムにフラグメント化するアプリケーションは、このフラグメント化を実行して、各データグラムを独立して受信し、アプリケーションが独自の信頼性メカニズムを実装している場合は独立して再送信する必要があります。
Application designers are generally aware that UDP does not provide any reliability, e.g., it does not retransmit any lost packets. Often, this is a main reason to consider UDP as a transport protocol. Applications that do require reliable message delivery MUST implement an appropriate mechanism themselves.
アプリケーション設計者は一般に、UDPが信頼性を提供しないこと、たとえば、失われたパケットを再送信しないことを認識しています。多くの場合、これがトランスポートプロトコルとしてUDPを検討する主な理由です。信頼性の高いメッセージ配信を必要とするアプリケーションは、適切なメカニズムを自身で実装する必要があります。
UDP also does not protect against datagram duplication, i.e., an application may receive multiple copies of the same UDP datagram, with some duplicates arriving potentially much later than the first. Application designers SHOULD handle such datagram duplication gracefully, and they may consequently need to implement mechanisms to detect duplicates. Even if UDP datagram reception triggers only idempotent operations, applications may want to suppress duplicate datagrams to reduce load.
UDPはデータグラムの重複からも保護しません。つまり、アプリケーションは同じUDPデータグラムの複数のコピーを受信する可能性があり、一部の重複は最初のものよりもかなり遅れて到着する可能性があります。アプリケーション設計者は、そのようなデータグラムの複製を適切に処理する必要があり（SHOULD）、結果として、重複を検出するメカニズムを実装する必要がある場合があります。 UDPデータグラムの受信がべき等演算のみをトリガーする場合でも、アプリケーションは、重複するデータグラムを抑制して負荷を軽減したい場合があります。
Applications that require ordered delivery MUST reestablish datagram ordering themselves. The Internet can significantly delay some packets with respect to others, e.g., due to routing transients, intermittent connectivity, or mobility. This can cause reordering, where UDP datagrams arrive at the receiver in an order different from the transmission order.
順序付けされた配信を必要とするアプリケーションは、データグラムの順序付け自体を再確立する必要があります。インターネットは、たとえば、ルーティングのトランジェント、断続的な接続、またはモビリティのために、他のパケットに比べて一部のパケットを大幅に遅延させる可能性があります。これにより、UDPデータグラムが送信順序とは異なる順序で受信側に到着する、並べ替えが発生する可能性があります。
Applications that use multiple transport ports need to be robust to reordering between sessions. Load-balancing techniques within the network, such as Equal Cost Multipath (ECMP) forwarding can also result in a lack of ordering between different transport sessions, even between the same two network endpoints.
複数のトランスポートポートを使用するアプリケーションは、セッション間の並べ替えに対して堅牢である必要があります。等コストマルチパス（ECMP）転送などのネットワーク内の負荷分散手法では、同じ2つのネットワークエンドポイント間でも、異なるトランスポートセッション間の順序付けが欠落する可能性があります。
It is important to note that the time by which packets are reordered or after which duplicates can still arrive can be very large. Even more importantly, there is no well-defined upper boundary here. [RFC793] defines the maximum delay a TCP segment should experience -- the Maximum Segment Lifetime (MSL) -- as 2 minutes. No other RFC defines an MSL for other transport protocols or IP itself. The MSL value defined for TCP is conservative enough that it SHOULD be used by other protocols, including UDP. Therefore, applications SHOULD be robust to the reception of delayed or duplicate packets that are received within this 2-minute interval.
パケットが並べ替えられるまでの時間、または複製が到着するまでの時間が非常に長くなる可能性があることに注意することが重要です。さらに重要なことに、ここには明確な上限はありません。 [RFC793]は、TCPセグメントで発生する最大遅延、つまり最大セグメント寿命（MSL）を2分と定義しています。他のRFCでは、他のトランスポートプロトコルまたはIP自体のMSLを定義していません。 TCPに対して定義されたMSL値は、UDPを含む他のプロトコルによって使用される必要があるほど十分に保守的です。したがって、アプリケーションは、この2分の間隔内に受信される遅延パケットまたは重複パケットの受信に対して堅牢である必要があります。
Retransmission of lost packets or messages is a common reliability mechanism. Such retransmissions can increase network load in response to congestion, worsening that congestion. Any application that uses retransmission is responsible for congestion control of its retransmissions (as well as the application's original traffic); hence, it is subject to the Congestion Control guidelines in
失われたパケットまたはメッセージの再送信は、一般的な信頼性メカニズムです。このような再送信は、輻輳に応じてネットワークの負荷を増大させ、その輻輳を悪化させる可能性があります。再送信を使用するすべてのアプリケーションは、その再送信の輻輳制御（およびアプリケーションの元のトラフィック）に責任があります。したがって、それはの輻輳制御ガイドラインの対象となります
Section 3.1. Guidance on the appropriate measurement of RTT in Section 3.1.1 also applies for timers used for retransmission packet-loss detection.
セクション3.1。セクション3.1.1のRTTの適切な測定に関するガイダンスは、再送信パケット損失検出に使用されるタイマーにも適用されます。
Instead of implementing these relatively complex reliability mechanisms by itself, an application that requires reliable and ordered message delivery SHOULD whenever possible choose an IETF standard transport protocol that provides these features.
これらの比較的複雑な信頼性メカニズムを単独で実装する代わりに、信頼性のある順序付けられたメッセージ配信を必要とするアプリケーションは、これらの機能を提供するIETF標準のトランスポートプロトコルを可能な限り選択する必要があります。
The UDP header includes an optional, 16-bit one's complement checksum that provides an integrity check. These checks are not strong from a coding or cryptographic perspective and are not designed to detect physical-layer errors or malicious modification of the datagram [RFC3819]. Application developers SHOULD implement additional checks where data integrity is important, e.g., through a Cyclic Redundancy Check (CRC) or keyed or non-keyed cryptographic hash included with the data to verify the integrity of an entire object/file sent over the UDP service.
UDPヘッダーには、整合性チェックを提供するオプションの16ビットの1の補数チェックサムが含まれています。これらのチェックは、コーディングや暗号化の観点から強力ではなく、物理層エラーやデータグラムの悪意のある変更を検出するようには設計されていません[RFC3819]。アプリケーション開発者は、UDPサービスを介して送信されたオブジェクト/ファイル全体の整合性を検証するために、データに含まれる巡回冗長検査（CRC）またはキー付きまたはキーなしの暗号化ハッシュなど、データの整合性が重要な場合に追加のチェックを実装する必要があります（SHOULD）。
The UDP checksum provides a statistical guarantee that the payload was not corrupted in transit. It also allows the receiver to verify that it was the intended destination of the packet, because it covers the IP addresses, port numbers, and protocol number, and it verifies that the packet is not truncated or padded, because it covers the size field. Therefore, it protects an application against receiving corrupted payload data in place of, or in addition to, the data that was sent. More description of the set of checks performed using the checksum field is provided in Section 3.1 of [RFC6396].
UDPチェックサムは、ペイロードが転送中に破損していないことを統計的に保証します。また、IPアドレス、ポート番号、プロトコル番号を対象とするため、パケットの目的の宛先であることを受信者が確認でき、サイズフィールドを対象とするため、パケットが切り捨てられたり埋め込まれたりしていないことを確認できます。したがって、送信されたデータの代わりに、またはそれに加えて、破損したペイロードデータを受信しないようにアプリケーションを保護します。チェックサムフィールドを使用して実行される一連のチェックの詳細については、[RFC6396]のセクション3.1を参照してください。
Applications SHOULD enable UDP checksums [RFC1122]. For IPv4, [RFC768] permits an option to disable their use, by setting a zero checksum value. An application is permitted to optionally discard UDP datagrams with a zero checksum [RFC1122].
アプリケーションは、UDPチェックサムを有効にする必要があります[RFC1122]。 IPv4の場合、[RFC768]は、ゼロのチェックサム値を設定することにより、それらの使用を無効にするオプションを許可します。アプリケーションは、オプションで、チェックサムがゼロのUDPデータグラムを破棄できます[RFC1122]。
When UDP is used over IPv6, the UDP checksum is relied upon to protect both the IPv6 and UDP headers from corruption (because IPv6 lacks a checksum) and MUST be used as specified in [RFC2460]. Under specific conditions, a UDP application is allowed to use a zero UDP zero-checksum mode with a tunnel protocol (see Section 3.4.1).
UDPがIPv6で使用される場合、UDPチェックサムは、IPv6とUDPヘッダーの両方を破損から保護するために依存しており（IPv6にはチェックサムがないため）、[RFC2460]での指定に従って使用する必要があります。特定の条件下では、UDPアプリケーションはトンネルプロトコルでゼロUDPゼロチェックサムモードを使用できます（セクション3.4.1を参照）。
Applications that choose to disable UDP checksums MUST NOT make assumptions regarding the correctness of received data and MUST behave correctly when a UDP datagram is received that was originally sent to a different destination or is otherwise corrupted.
UDPチェックサムを無効にすることを選択するアプリケーションは、受信したデータの正確さに関する仮定を行ってはならず（MUST NOT）、元々別の宛先に送信された、または破損しているUDPデータグラムが受信されたときに正しく動作する必要があります。
[RFC6935] defines a method that enables use of a zero UDP zero-checksum mode with a tunnel protocol, providing that the method satisfies the requirements in [RFC6936]. The application MUST implement mechanisms and/or usage restrictions when enabling this mode. This includes defining the scope for usage and measures to prevent leakage of traffic to other UDP applications (see Appendix A and Section 3.6). These additional design requirements for using a zero IPv6 UDP checksum are not present for IPv4, since the IPv4 header validates information that is not protected in an IPv6 packet. Key requirements are:
[RFC6935]は、[RFC6936]の要件を満たしている場合に、トンネルプロトコルでゼロUDPゼロチェックサムモードを使用できるようにするメソッドを定義しています。このモードを有効にする場合、アプリケーションはメカニズムや使用制限を実装する必要があります。これには、他のUDPアプリケーションへのトラフィックの漏洩を防ぐための使用法と対策の範囲の定義が含まれます（付録Aとセクション3.6を参照）。 IPv4ヘッダーはIPv6パケットで保護されていない情報を検証するため、ゼロIPv6 UDPチェックサムを使用するためのこれらの追加の設計要件はIPv4には存在しません。主な要件は次のとおりです。
o Use of the UDP checksum with IPv6 MUST be the default configuration for all implementations [RFC6935]. The receiving endpoint MUST only allow the use of UDP zero-checksum mode for IPv6 on a UDP destination port that is specifically enabled.
o IPv6でのUDPチェックサムの使用は、すべての実装のデフォルト構成である必要があります[RFC6935]。受信エンドポイントは、特に有効になっているUDP宛先ポートでのIPv6のUDPゼロチェックサムモードの使用のみを許可する必要があります。
o An application that supports a checksum different than that in [RFC2460] MUST comply with all implementation requirements specified in Section 4 of [RFC6936] and with the usage requirements specified in Section 5 of [RFC6936].
o [RFC2460]とは異なるチェックサムをサポートするアプリケーションは、[RFC6936]のセクション4で指定されたすべての実装要件と[RFC6936]のセクション5で指定された使用要件に準拠する必要があります。
o A UDP application MUST check that the source and destination IPv6 addresses are valid for any packets with a UDP zero-checksum and MUST discard any packet for which this check fails. To protect from misdelivery, new encapsulation designs SHOULD include an integrity check at the transport layer that includes at least the IPv6 header, the UDP header and the shim header for the encapsulation, if any [RFC6936].
o UDPアプリケーションは、送信元と宛先のIPv6アドレスがUDPゼロチェックサムを持つすべてのパケットに対して有効であることを確認する必要があり、この確認が失敗したパケットを破棄する必要があります。誤配信から保護するために、新しいカプセル化設計は、少なくともIPv6ヘッダー、UDPヘッダー、およびカプセル化用のシムヘッダー（ある場合）を含むトランスポート層での整合性チェックを含める必要があります[RFC6936]。
o One way to help satisfy the requirements of [RFC6936] may be to limit the usage of such tunnels, e.g., to constrain traffic to an operator network, as discussed in Section 3.6. The encapsulation defined for MPLS in UDP [RFC7510] chooses this approach.
o [RFC6936]の要件を満たすのに役立つ1つの方法は、セクション3.6で説明するように、そのようなトンネルの使用を制限すること、たとえば、トラフィックをオペレーターネットワークに制限することです。 UDP [RFC7510]でMPLS用に定義されたカプセル化は、このアプローチを選択します。
As in IPv4, IPv6 applications that choose to disable UDP checksums MUST NOT make assumptions regarding the correctness of received data and MUST behave correctly when a UDP datagram is received that was originally sent to a different destination or is otherwise corrupted.
IPv4の場合と同様に、UDPチェックサムを無効にすることを選択したIPv6アプリケーションは、受信したデータの正確さについて仮定をしてはならず（MUST NOT）、元々別の宛先に送信された、または他の方法で破損したUDPデータグラムが受信されたときに正しく動作する必要があります。
IPv6 datagrams with a zero UDP checksum will not be passed by any middlebox that validates the checksum based on [RFC2460] or that updates the UDP checksum field, such as NATs or firewalls. Changing this behavior would require such middleboxes to be updated to correctly handle datagrams with zero UDP checksums. To ensure end-to-end robustness, applications that may be deployed in the general Internet MUST provide a mechanism to safely fall back to using a checksum when a path change occurs that redirects a zero UDP checksum flow over a path that includes a middlebox that discards IPv6 datagrams with a zero UDP checksum.
UDPチェックサムがゼロのIPv6データグラムは、[RFC2460]に基づいてチェックサムを検証するミドルボックス、またはNATやファイアウォールなどのUDPチェックサムフィールドを更新するミドルボックスによって渡されません。この動作を変更するには、このようなミドルボックスを更新して、UDPチェックサムがゼロのデータグラムを正しく処理する必要があります。エンドツーエンドの堅牢性を確保するために、一般的なインターネットにデプロイされる可能性のあるアプリケーションは、パス変更が発生したときにチェックサムの使用に安全にフォールバックするメカニズムを提供しなければなりません。 UDPチェックサムがゼロのIPv6データグラムを破棄します。
A special class of applications can derive benefit from having partially damaged payloads delivered, rather than discarded, when using paths that include error-prone links. Such applications can tolerate payload corruption and MAY choose to use the Lightweight User Datagram Protocol (UDP-Lite) [RFC3828] variant of UDP instead of basic UDP. Applications that choose to use UDP-Lite instead of UDP should still follow the congestion control and other guidelines described for use with UDP in Section 3.
エラーが発生しやすいリンクを含むパスを使用する場合、特別なクラスのアプリケーションは、破棄されるのではなく、部分的に損傷したペイロードを配信することでメリットを得ることができます。そのようなアプリケーションはペイロードの破損を許容でき、基本的なUDPではなくUDPのライトウェイトユーザーデータグラムプロトコル（UDP-Lite）[RFC3828]バリアントを使用することを選択できます（MAY）。 UDPの代わりにUDP-Liteを使用することを選択するアプリケーションは、セクション3でUDPでの使用について説明されている輻輳制御およびその他のガイドラインに従う必要があります。
UDP-Lite changes the semantics of the UDP "payload length" field to that of a "checksum coverage length" field. Otherwise, UDP-Lite is semantically identical to UDP. The interface of UDP-Lite differs from that of UDP by the addition of a single (socket) option that communicates the checksum coverage length: at the sender, this specifies the intended checksum coverage, with the remaining unprotected part of the payload called the "error-insensitive part". By default, the UDP-Lite checksum coverage extends across the entire datagram. If required, an application may dynamically modify this length value, e.g., to offer greater protection to some messages. UDP-Lite always verifies that a packet was delivered to the intended destination, i.e., always verifies the header fields. Errors in the insensitive part will not cause a UDP datagram to be discarded by the destination. Therefore, applications using UDP-Lite MUST NOT make assumptions regarding the correctness of the data received in the insensitive part of the UDP-Lite payload.
UDP-Liteは、UDPの「ペイロード長」フィールドの意味を「チェックサムカバレッジ長」フィールドの意味に変更します。それ以外の場合、UDP-Liteは意味的にUDPと同じです。 UDP-Liteのインターフェースは、チェックサムカバレッジ長を伝達する単一（ソケット）オプションが追加されている点でUDPのインターフェースとは異なります。送信側では、目的のチェックサムカバレッジを指定し、ペイロードの保護されていない残りの部分を「エラーに影響されない部分」。デフォルトでは、UDP-Liteチェックサムカバレッジはデータグラム全体に及びます。必要に応じて、アプリケーションはこの長さの値を動的に変更して、一部のメッセージをより強力に保護することができます。 UDP-Liteは常に、パケットが目的の宛先に配信されたことを確認します。つまり、常にヘッダーフィールドを確認します。 insensitive部分にエラーがあっても、宛先によってUDPデータグラムが破棄されることはありません。したがって、UDP-Liteを使用するアプリケーションは、UDP-Liteペイロードの非依存部分で受信されたデータの正確性に関する仮定をしてはなりません（MUST NOT）。
A UDP-Lite sender SHOULD select the minimum checksum coverage to include all sensitive payload information. For example, applications that use the Real-Time Protocol (RTP) [RFC3550] will likely want to protect the RTP header against corruption. Applications, where appropriate, MUST also introduce their own appropriate validity checks for protocol information carried in the insensitive part of the UDP-Lite payload (e.g., internal CRCs).
UDP-Lite送信者は、すべての機密ペイロード情報を含めるために最小チェックサムカバレッジを選択する必要があります（SHOULD）。たとえば、リアルタイムプロトコル（RTP）[RFC3550]を使用するアプリケーションは、RTPヘッダーを破損から保護する必要があります。アプリケーションは、必要に応じて、UDP-Liteペイロードの非機密部分で運ばれるプロトコル情報（たとえば、内部CRC）に対して適切な妥当性チェックも導入する必要があります。
A UDP-Lite receiver MUST set a minimum coverage threshold for incoming packets that is not smaller than the smallest coverage used by the sender [RFC3828]. The receiver SHOULD select a threshold that is sufficiently large to block packets with an inappropriately short coverage field. This may be a fixed value, or it may be negotiated by an application. UDP-Lite does not provide mechanisms to negotiate the checksum coverage between the sender and receiver. Therefore, this needs to be performed by the application.
UDP-Lite受信者は、送信者が使用する最小カバレッジよりも小さくない着信パケットの最小カバレッジしきい値を設定する必要があります[RFC3828]。受信者は、不適切に短いカバレッジフィールドを持つパケットをブロックするのに十分な大きさのしきい値を選択する必要があります（SHOULD）。これは固定値の場合もあれば、アプリケーションによってネゴシエートされる場合もあります。 UDP-Liteは、送信者と受信者の間でチェックサムカバレッジをネゴシエートするメカニズムを提供しません。したがって、これはアプリケーションで実行する必要があります。
Applications can still experience packet loss when using UDP-Lite. The enhancements offered by UDP-Lite rely upon a link being able to intercept the UDP-Lite header to correctly identify the partial coverage required. When tunnels and/or encryption are used, this can result in UDP-Lite datagrams being treated the same as UDP datagrams, i.e., result in packet loss. Use of IP fragmentation can also prevent special treatment for UDP-Lite datagrams, and this is another reason why applications SHOULD avoid IP fragmentation (Section 3.2).
UDP-Liteを使用すると、アプリケーションでパケット損失が発生する可能性があります。 UDP-Liteによって提供される拡張機能は、リンクがUDP-Liteヘッダーをインターセプトして、必要な部分的なカバレッジを正しく識別できることに依存しています。トンネルや暗号化が使用されている場合、これによりUDP-LiteデータグラムがUDPデータグラムと同じように扱われる可能性があります。つまり、パケット損失が発生します。 IPフラグメンテーションを使用すると、UDP-Liteデータグラムの特別な扱いを防ぐこともできます。これが、アプリケーションがIPフラグメンテーションを回避する必要があるもう1つの理由です（セクション3.2）。
UDP-Lite is supported in some endpoint protocol stacks. Current support for middlebox traversal using UDP-Lite is poor, because UDP-Lite uses a different IPv4 protocol number or IPv6 "next header" value than that used for UDP; therefore, few middleboxes are currently able to interpret UDP-Lite and take appropriate actions when forwarding the packet. This makes UDP-Lite less suited for applications needing general Internet support, until such time as UDP-Lite has achieved better support in middleboxes.
UDP-Liteは、一部のエンドポイントプロトコルスタックでサポートされています。 UDP-LiteはUDPに使用されるものとは異なるIPv4プロトコル番号またはIPv6 "次のヘッダー"値を使用するため、UDP-Liteを使用したミドルボックストラバーサルの現在のサポートは不十分です。したがって、UDP-Liteを解釈してパケットを転送するときに適切なアクションを実行できるミドルボックスはほとんどありません。これにより、UDP-Liteがミドルボックスでのサポートを改善するまで、UDP-Liteは一般的なインターネットサポートを必要とするアプリケーションにはあまり適していません。
NATs and firewalls are examples of intermediary devices ("middleboxes") that can exist along an end-to-end path. A middlebox typically performs a function that requires it to maintain per-flow state. For connection-oriented protocols, such as TCP, middleboxes snoop and parse the connection-management information, and create and destroy per-flow state accordingly. For a connectionless protocol such as UDP, this approach is not possible. Consequently, middleboxes can create per-flow state when they see a packet that -- according to some local criteria -- indicates a new flow, and destroy the state after some time during which no packets belonging to the same flow have arrived.
NATとファイアウォールは、エンドツーエンドパスに沿って存在できる中間デバイス（「ミドルボックス」）の例です。ミドルボックスは通常、フローごとの状態を維持するために必要な機能を実行します。 TCPなどの接続指向プロトコルの場合、ミドルボックスは接続管理情報をスヌーピングして解析し、それに応じてフローごとの状態を作成および破棄します。 UDPなどのコネクションレス型プロトコルの場合、このアプローチは不可能です。その結果、ミドルボックスは、ローカル基準に従って、新しいフローを示すパケットを検出したときにフローごとの状態を作成し、同じフローに属するパケットが到着していない時間が経過すると、状態を破棄できます。
Depending on the specific function that the middlebox performs, this behavior can introduce a time-dependency that restricts the kinds of UDP traffic exchanges that will be successful across the middlebox. For example, NATs and firewalls typically define the partial path on one side of them to be interior to the domain they serve, whereas the partial path on their other side is defined to be exterior to that domain. Per-flow state is typically created when the first packet crosses from the interior to the exterior, and while the state is present, NATs and firewalls will forward return traffic. Return traffic that arrives after the per-flow state has timed out is dropped, as is other traffic that arrives from the exterior.
ミドルボックスが実行する特定の機能に応じて、この動作は、ミドルボックス全体で成功するUDPトラフィック交換の種類を制限する時間依存性を導入する可能性があります。たとえば、NATとファイアウォールは通常、一方の側の部分パスをサービス対象のドメインの内部と定義し、もう一方の側の部分パスはそのドメインの外部と定義します。フローごとの状態は通常、最初のパケットが内部から外部に渡るときに作成されます。状態が存在している間、NATとファイアウォールはリターントラフィックを転送します。フローごとの状態がタイムアウトした後に到着するリターントラフィックは、外部から到着する他のトラフィックと同様にドロップされます。
Many applications that use UDP for communication operate across middleboxes without needing to employ additional mechanisms. One example is the Domain Name System (DNS), which has a strict request-response communication pattern that typically completes within seconds.
通信にUDPを使用する多くのアプリケーションは、追加のメカニズムを採用する必要なしにミドルボックス全体で動作します。 1つの例はドメインネームシステム（DNS）で、通常は数秒で完了する厳密な要求/応答通信パターンがあります。
Other applications may experience communication failures when middleboxes destroy the per-flow state associated with an application session during periods when the application does not exchange any UDP traffic. Applications SHOULD be able to gracefully handle such communication failures and implement mechanisms to re-establish application-layer sessions and state.
アプリケーションがUDPトラフィックを交換しない期間に、ミドルボックスがアプリケーションセッションに関連付けられたフローごとの状態を破棄すると、他のアプリケーションで通信障害が発生する可能性があります。アプリケーションは、そのような通信障害を適切に処理し、アプリケーション層のセッションと状態を再確立するメカニズムを実装できる必要があります（SHOULD）。
For some applications, such as media transmissions, this re-synchronization is highly undesirable, because it can cause user-perceivable playback artifacts. Such specialized applications MAY send periodic keep-alive messages to attempt to refresh middlebox state (e.g., [RFC7675]). It is important to note that keep-alive messages are not recommended for general use -- they are unnecessary for many applications and can consume significant amounts of system and network resources.
メディア送信などの一部のアプリケーションでは、ユーザーが認識できる再生アーティファクトを引き起こす可能性があるため、この再同期は非常に望ましくありません。このような特殊なアプリケーションは、ミドルボックスの状態を更新しようとするために、定期的にキープアライブメッセージを送信する場合があります（例：[RFC7675]）。キープアライブメッセージは一般的な使用には推奨されないことに注意することが重要です。これらのメッセージは多くのアプリケーションでは不要であり、システムおよびネットワークリソースを大量に消費する可能性があります。
An application that needs to employ keep-alive messages to deliver useful service over UDP in the presence of middleboxes SHOULD NOT transmit them more frequently than once every 15 seconds and SHOULD use longer intervals when possible. No common timeout has been specified for per-flow UDP state for arbitrary middleboxes. NATs require a state timeout of 2 minutes or longer [RFC4787]. However, empirical evidence suggests that a significant fraction of currently deployed middleboxes unfortunately use shorter timeouts. The timeout of 15 seconds originates with the Interactive Connectivity Establishment (ICE) protocol [RFC5245]. When an application is deployed in a controlled environment, the deployer SHOULD investigate whether the target environment allows applications to use longer intervals, or whether it offers mechanisms to explicitly control middlebox state timeout durations, for example, using the Port Control Protocol (PCP) [RFC6887], Middlebox Communications (MIDCOM) [RFC3303], Next Steps in Signaling (NSIS) [RFC5973], or Universal Plug and Play (UPnP) [UPnP]. It is RECOMMENDED that applications apply slight random variations ("jitter") to the timing of keep-alive transmissions, to reduce the potential for persistent synchronization between keep-alive transmissions from different hosts [RFC7675].
ミドルボックスの存在下でUDPを介して有用なサービスを提供するためにキープアライブメッセージを使用する必要があるアプリケーションは、15秒に1回より頻繁にメッセージを送信するべきではなく（可能な場合）、より長い間隔を使用する必要があります。任意のミドルボックスのフローごとのUDP状態に共通のタイムアウトが指定されていません。 NATには2分以上の状態タイムアウトが必要です[RFC4787]。ただし、経験的な証拠によると、現在デプロイされているミドルボックスのかなりの部分が、残念ながら短いタイムアウトを使用しています。 15秒のタイムアウトは、Interactive Connectivity Establishment（ICE）プロトコル[RFC5245]に起因しています。アプリケーションが制御された環境にデプロイされると、デプロイヤーは、ターゲット環境でアプリケーションがより長い間隔を使用できるかどうか、またはポート制御プロトコル（PCP）などを使用してミドルボックス状態のタイムアウト時間を明示的に制御するメカニズムを提供するかどうかを調査する必要があります（SHOULD）。 RFC6887]、ミドルボックス通信（MIDCOM）[RFC3303]、シグナリングの次のステップ（NSIS）[RFC5973]、またはユニバーサルプラグアンドプレイ（UPnP）[UPnP]。異なるホストからのキープアライブ送信間の永続的な同期の可能性を減らすために、アプリケーションはキープアライブ送信のタイミングにわずかなランダムな変動（「ジッター」）を適用することをお勧めします[RFC7675]。
Sending keep-alive messages is not a substitute for implementing a mechanism to recover from broken sessions. Like all UDP datagrams, keep-alive messages can be delayed or dropped, causing middlebox state to time out. In addition, the congestion control guidelines in Section 3.1 cover all UDP transmissions by an application, including the transmission of middlebox keep-alive messages. Congestion control may thus lead to delays or temporary suspension of keep-alive transmission.
キープアライブメッセージの送信は、壊れたセッションから回復するメカニズムを実装する代わりにはなりません。すべてのUDPデータグラムと同様に、キープアライブメッセージが遅延またはドロップされ、ミドルボックスの状態がタイムアウトする可能性があります。さらに、セクション3.1の輻輳制御ガイドラインは、ミドルボックスキープアライブメッセージの送信を含む、アプリケーションによるすべてのUDP送信をカバーしています。したがって、輻輳制御は、キープアライブ送信の遅延または一時的な停止につながる可能性があります。
Keep-alive messages are NOT RECOMMENDED for general use. They are unnecessary for many applications and may consume significant resources. For example, on battery-powered devices, if an application needs to maintain connectivity for long periods with little traffic, the frequency at which keep-alive messages are sent can become the determining factor that governs power consumption, depending on the underlying network technology.
キープアライブメッセージは、一般的な使用には推奨されません。多くのアプリケーションでは不要であり、大量のリソースを消費する可能性があります。たとえば、バッテリー駆動のデバイスで、アプリケーションが少ないトラフィックで長期間接続を維持する必要がある場合、キープアライブメッセージが送信される頻度は、基盤となるネットワークテクノロジーに応じて、電力消費を左右する決定要素になる可能性があります。
Because many middleboxes are designed to require keep-alive messages for TCP connections at a frequency that is much lower than that needed for UDP, this difference alone can often be sufficient to prefer TCP over UDP for these deployments. On the other hand, there is anecdotal evidence that suggests that direct communication through middleboxes, e.g., by using ICE [RFC5245], does succeed less often with TCP than with UDP. The trade-offs between different transport protocols -- especially when it comes to middlebox traversal -- deserve careful analysis.
多くのミドルボックスは、UDPに必要な頻度よりもはるかに低い頻度でTCP接続のキープアライブメッセージを要求するように設計されているため、この違いだけで、これらのデプロイメントにUDPよりもTCPを優先するのに十分な場合があります。一方、ミドルボックスを介した直接通信は、たとえば[ICE [RFC5245]を使用して）、UDPよりもTCPの方が成功する頻度が低いことを示唆する事例証拠があります。異なるトランスポートプロトコル間のトレードオフ、特にミドルボックストラバーサルに関しては、慎重に分析する必要があります。
UDP applications that could be deployed in the Internet need to be designed understanding that there are many variants of middlebox behavior, and although UDP is connectionless, middleboxes often maintain state for each UDP flow. Using multiple UDP flows can consume available state space and also can lead to changes in the way the middlebox handles subsequent packets (either to protect its internal resources, or to prevent perceived misuse). The probability of path failure can increase when applications use multiple UDP flows in parallel (see Section 5.1.2 for recommendations on usage of multiple ports).
インターネットに展開できるUDPアプリケーションは、ミドルボックスの動作にさまざまなバリエーションがあることを理解して設計する必要があります。UDPはコネクションレスですが、ミドルボックスは多くの場合、UDPフローごとに状態を維持します。複数のUDPフローを使用すると、使用可能な状態スペースが消費され、ミドルボックスが後続のパケットを処理する方法が変化する可能性があります（内部リソースを保護するため、または誤用の認識を防ぐため）。アプリケーションが複数のUDPフローを並行して使用すると、パス障害の可能性が高くなる可能性があります（複数のポートの使用に関する推奨事項については、セクション5.1.2を参照してください）。
Two different types of applicability have been identified for the specification of IETF applications that utilize UDP:
UDPを利用するIETFアプリケーションの仕様には、2つの異なるタイプの適用性が確認されています。
General Internet. By default, IETF specifications target deployment on the general Internet. Experience has shown that successful protocols developed in one specific context or for a particular application tend to become used in a wider range of contexts. For example, a protocol with an initial deployment within a local area network may subsequently be used over a virtual network that traverses the Internet, or in the Internet in general. Applications designed for general Internet use may experience a range of network device behaviors and, in particular, should consider whether applications need to operate over paths that may include middleboxes.
一般的なインターネット。デフォルトでは、IETF仕様は一般的なインターネットでの展開を対象としています。経験から、1つの特定のコンテキストまたは特定のアプリケーションで開発された成功したプロトコルは、より幅広いコンテキストで使用される傾向があることがわかっています。たとえば、ローカルエリアネットワーク内で初期展開を行うプロトコルは、インターネットを経由する仮想ネットワークを介して、またはインターネット全体で使用できます。一般的なインターネット使用向けに設計されたアプリケーションは、さまざまなネットワークデバイス動作を経験する可能性があり、特に、ミドルボックスを含む可能性のあるパス上でアプリケーションを動作させる必要があるかどうかを検討する必要があります。
Controlled Environment. A protocol/encapsulation/tunnel could be designed to be used only within a controlled environment. For example, an application designed for use by a network operator might only be deployed within the network of that single network operator or on networks of an adjacent set of cooperating network operators. The application traffic may then be managed to avoid congestion, rather than relying on built-in mechanisms, which are required when operating over the general Internet. Applications that target a limited applicability use case may be able to take advantage of specific hardware (e.g., carrier-grade equipment) or underlying protocol features of the subnetwork over which they are used.
制御された環境。プロトコル/カプセル化/トンネルは、制御された環境内でのみ使用されるように設計できます。たとえば、ネットワークオペレーターが使用するように設計されたアプリケーションは、その単一のネットワークオペレーターのネットワーク内、または隣接する一連の協力するネットワークオペレーターのネットワーク上にのみ展開できます。その後、アプリケーショントラフィックを管理して、一般的なインターネットで動作するときに必要な組み込みメカニズムに依存するのではなく、輻輳を回避できます。適用範囲が限定されたユースケースを対象とするアプリケーションは、特定のハードウェア（キャリアグレードの機器など）またはそれらが使用されるサブネットワークの基本的なプロトコル機能を利用できる場合があります。
Specifications addressing a limited applicability use case or a controlled environment SHOULD identify how, in their restricted deployment, a level of safety is provided that is equivalent to that of a protocol designed for operation over the general Internet (e.g., a design based on extensive experience with deployments of particular methods that provide features that cannot be expected in general Internet equipment and the robustness of the design of MPLS to corruption of headers both helped justify use of an alternate UDP integrity check [RFC7510]).
限定された適用性のユースケースまたは管理された環境に対応する仕様は、制限された展開において、一般的なインターネット上での運用向けに設計されたプロトコルと同等の安全性のレベルがどのように提供されるかを識別する必要があります（たとえば、広範な経験に基づく設計）一般的なインターネット機器では期待できない機能を提供する特定のメソッドの展開とヘッダーの破損に対するMPLSの設計の堅牢性は、どちらも代替UDP整合性チェックの使用を正当化するのに役立ちました[RFC7510]）。
An IETF specification targeting a controlled environment is expected to provide an applicability statement that restricts the application traffic to the controlled environment, and it would be expected to describe how methods can be provided to discourage or prevent escape of corrupted packets from the environment (for example, Section 5 of [RFC7510]).
制御された環境をターゲットとするIETF仕様は、アプリケーショントラフィックを制御された環境に制限する適用性ステートメントを提供することが期待されており、環境からの破損したパケットのエスケープを阻止または防止する方法を提供する方法を説明することが期待されます（たとえば、 、[RFC7510]のセクション5）。
This section complements Section 3 by providing additional guidelines that are applicable to multicast and broadcast usage of UDP.
このセクションは、UDPのマルチキャストおよびブロードキャストの使用に適用される追加のガイドラインを提供することにより、セクション3を補足します。
Multicast and broadcast transmission [RFC1112] usually employ the UDP transport protocol, although they may be used with other transport protocols (e.g., UDP-Lite).
マルチキャストおよびブロードキャスト送信[RFC1112]は通常、UDPトランスポートプロトコルを使用しますが、他のトランスポートプロトコル（UDP-Liteなど）でも使用できます。
There are currently two models of multicast delivery: the Any-Source Multicast (ASM) model as defined in [RFC1112] and the Source-Specific Multicast (SSM) model as defined in [RFC4607]. ASM group members will receive all data sent to the group by any source, while SSM constrains the distribution tree to only one single source.
現在、マルチキャスト配信には2つのモデルがあります。[RFC1112]で定義されているAny-Source Multicast（ASM）モデルと、[RFC4607]で定義されているSource-Specific Multicast（SSM）モデルです。 ASMグループメンバーは、任意のソースによってグループに送信されたすべてのデータを受信しますが、SSMは配布ツリーを1つのソースにのみ制限します。
Specialized classes of applications also use UDP for IP multicast or broadcast [RFC919]. The design of such specialized applications requires expertise that goes beyond simple, unicast-specific guidelines, since these senders may transmit to potentially very many receivers across potentially very heterogeneous paths at the same time, which significantly complicates congestion control, flow control, and reliability mechanisms.
特殊なクラスのアプリケーションも、IPマルチキャストまたはブロードキャストにUDPを使用します[RFC919]。このような特殊なアプリケーションの設計には、単純なユニキャスト固有のガイドラインを超える専門知識が必要です。これらの送信者は、潜在的に非常に異種のパスを介して非常に多くの受信者に同時に送信する可能性があり、輻輳制御、フロー制御、および信頼性メカニズムが大幅に複雑になるためです。 。
This section provides guidance on multicast and broadcast UDP usage. Use of broadcast by an application is normally constrained by routers to the local subnetwork. However, use of tunneling techniques and proxies can and does result in some broadcast traffic traversing Internet paths. These guidelines therefore also apply to broadcast traffic.
このセクションでは、マルチキャストおよびブロードキャストUDPの使用に関するガイダンスを提供します。アプリケーションによるブロードキャストの使用は、通常、ルーターによってローカルサブネットワークに制限されています。ただし、トンネリング技術とプロキシを使用すると、一部のブロードキャストトラフィックがインターネットパスを通過する可能性があります。したがって、これらのガイドラインはブロードキャストトラフィックにも適用されます。
The IETF has defined a reliable multicast framework [RFC3048] and several building blocks to aid the designers of multicast applications, such as [RFC3738] or [RFC4654].
IETFは、信頼できるマルチキャストフレームワーク[RFC3048]と、[RFC3738]や[RFC4654]などのマルチキャストアプリケーションの設計者を支援するいくつかのビルディングブロックを定義しています。
Senders to anycast destinations must be aware that successive messages sent to the same anycast IP address may be delivered to different anycast nodes, i.e., arrive at different locations in the topology.
エニーキャスト宛先への送信者は、同じエニーキャストIPアドレスに送信された連続するメッセージが異なるエニーキャストノードに配信される場合がある、つまりトポロジ内の異なる場所に到着する場合があることに注意する必要があります。
Most UDP tunnels that carry IP multicast traffic use a tunnel encapsulation with a unicast destination address, such as Automatic Multicast Tunneling [RFC7450]. These MUST follow the same requirements as a tunnel carrying unicast data (see Section 3.1.11). There are deployment cases and solutions where the outer header of a UDP tunnel contains a multicast destination address, such as [RFC6513]. These cases are primarily deployed in controlled environments over reserved capacity, often operating within a single administrative domain, or between two domains over a bilaterally agreed upon path with reserved capacity, and so congestion control is OPTIONAL, but circuit breaker techniques are still RECOMMENDED in order to restore some degree of service should the offered load exceed the reserved capacity (e.g., due to misconfiguration).
IPマルチキャストトラフィックを伝送するほとんどのUDPトンネルは、自動マルチキャストトンネリング[RFC7450]などのユニキャスト宛先アドレスを使用したトンネルカプセル化を使用します。これらは、ユニキャストデータを伝送するトンネルと同じ要件に従う必要があります（セクション3.1.11を参照）。 UDPトンネルの外部ヘッダーに[RFC6513]などのマルチキャスト宛先アドレスが含まれている導入事例とソリューションがあります。これらのケースは、主に予約された容量を介して制御された環境に展開され、多くの場合、単一の管理ドメイン内で、または予約された容量を使用して双方向で合意されたパスを介して2つのドメイン間で動作するため、輻輳制御はオプションですが、回路ブレーカーの技術は順番に推奨されます提供された負荷が予約済みの容量を超えた場合（構成の誤りなどにより）ある程度のサービスを復元するため。
Unicast congestion-controlled transport mechanisms are often not applicable to multicast distribution services, or simply do not scale to large multicast trees, since they require bidirectional communication and adapt the sending rate to accommodate the network conditions to a single receiver. In contrast, multicast distribution trees may fan out to massive numbers of receivers, which limits the scalability of an in-band return channel to control the sending rate, and the one-to-many nature of multicast distribution trees prevents adapting the rate to the requirements of an individual receiver. For this reason, generating TCP-compatible aggregate flow rates for Internet multicast data, either native or tunneled, is the responsibility of the application implementing the congestion control.
ユニキャストの輻輳制御トランスポートメカニズムは、双方向通信を必要とし、ネットワーク状態を単一のレシーバーに対応させるために送信速度を調整するため、マルチキャスト配信サービスに適用できないことが多く、または単に大きなマルチキャストツリーにスケーリングされません。対照的に、マルチキャスト配信ツリーは膨大な数のレシーバーにファンアウトする可能性があり、送信レートを制御するためのインバンドリターンチャネルのスケーラビリティを制限し、マルチキャスト配信ツリーの1対多の性質がレートを個々の受信機の要件。このため、ネイティブまたはトンネルのいずれかであるインターネットマルチキャストデータのTCP互換の集約フローレートの生成は、輻輳制御を実装するアプリケーションの責任です。
Applications using multicast SHOULD provide appropriate congestion control. Multicast congestion control needs to be designed using mechanisms that are robust to the potential heterogeneity of both the multicast distribution tree and the receivers belonging to a group. Heterogeneity may manifest itself in some receivers experiencing more loss that others, higher delay, and/or less ability to respond to network conditions. Congestion control is particularly important for any multicast session where all or part of the multicast distribution tree spans an access network (e.g., a home gateway). Two styles of congestion control have been defined in the RFC Series:
マルチキャストを使用するアプリケーションは、適切な輻輳制御を提供する必要があります（SHOULD）。マルチキャストの輻輳制御は、マルチキャスト配信ツリーとグループに属するレシーバーの両方の潜在的な不均一性に強いメカニズムを使用して設計する必要があります。不均一性は、一部のレシーバーで他のレシーバーよりも多くの損失が発生し、遅延が増加し、ネットワーク状態に応答する能力が低下する場合に現れます。輻輳制御は、マルチキャスト配信ツリーのすべてまたは一部がアクセスネットワーク（ホームゲートウェイなど）にまたがるマルチキャストセッションでは特に重要です。 RFCシリーズでは、2つのスタイルの輻輳制御が定義されています。
o Feedback-based congestion control, in which the sender receives multicast or unicast UDP messages from the receivers allowing it to assess the level of congestion and then adjust the sender rate(s) (e.g., [RFC5740],[RFC4654]). Multicast methods may operate on longer timescales than for unicast (e.g., due to the higher group RTT of a heterogeneous group). A control method could decide not to reduce the rate of the entire multicast group in response to a control message received from a single receiver (e.g., a sender could set a minimum rate and decide to request a congested receiver to leave the multicast group and could also decide to distribute content to these congested receivers at a lower rate using unicast congestion control).
o フィードバックベースの輻輳制御。送信側は受信側からマルチキャストまたはユニキャストのUDPメッセージを受信し、輻輳レベルを評価して送信側のレートを調整できます（例：[RFC5740]、[RFC4654]）。マルチキャストメソッドは、ユニキャストの場合よりも長いタイムスケールで動作する場合があります（たとえば、異種グループのグループRTTが高いため）。制御方法は、単一のレシーバーから受信した制御メッセージに応答して、マルチキャストグループ全体のレートを低下させないことを決定できます（たとえば、送信者は最小レートを設定し、輻輳したレシーバーにマルチキャストグループを離れるよう要求することを決定し、また、ユニキャスト輻輳制御を使用して、これらの輻輳したレシーバーに低いレートでコンテンツを配信することも決定します。
o Receiver-driven congestion control, which does not require a receiver to send explicit UDP control messages for congestion control (e.g., [RFC3738], [RFC5775]). Instead, the sender distributes the data across multiple IP multicast groups (e.g., using a set of {S,G} channels). Each receiver determines its own level of congestion and controls its reception rate using only multicast join/leave messages sent in the network control plane. This method scales to arbitrary large groups of receivers.
o 輻輳制御のために受信者が明示的なUDP制御メッセージを送信する必要がない、受信者主導の輻輳制御（[RFC3738]、[RFC5775]など）。代わりに、送信者は複数のIPマルチキャストグループにデータを分散します（たとえば、{S、G}チャネルのセットを使用して）。各受信機は、自身の輻輳レベルを決定し、ネットワークコントロールプレーンで送信されるマルチキャスト参加/脱退メッセージのみを使用して受信レートを制御します。この方法は、レシーバの任意の大きなグループにスケーリングします。
Any multicast-enabled receiver may attempt to join and receive traffic from any group. This may imply the need for rate limits on individual receivers or the aggregate multicast service. Note, at the transport layer, there is no way to prevent a join message propagating to the next-hop router.
マルチキャスト対応のレシーバーは、グループに参加して、トラフィックを受信しようとする可能性があります。これは、個々のレシーバーまたは集約マルチキャストサービスでのレート制限の必要性を示唆している可能性があります。トランスポート層では、参加メッセージがネクストホップルーターに伝播するのを防ぐ方法はありません。
Some classes of multicast applications support applications that can monitor the user-level quality of the transfer at the receiver. Applications that can detect a significant reduction in user quality SHOULD regard this as a congestion signal (e.g., to leave a group using layered multicast encoding); if not, they SHOULD use this signal to provide a circuit breaker to terminate the flow by leaving the multicast group.
マルチキャストアプリケーションの一部のクラスは、受信側でのユーザーレベルの転送品質を監視できるアプリケーションをサポートしています。ユーザー品質の大幅な低下を検出できるアプリケーションは、これを輻輳信号と見なすべきです（たとえば、レイヤードマルチキャストエンコーディングを使用してグループを離れる場合）。そうでない場合は、この信号を使用して、マルチキャストグループを離れることによってフローを終了する回路ブレーカーを提供する必要があります（SHOULD）。
Applications that perform bulk transmission of data over a multicast distribution tree, i.e., applications that exchange more than a few UDP datagrams per RTT, SHOULD implement a method for congestion control. The currently RECOMMENDED IETF methods are as follows: Asynchronous Layered Coding (ALC) [RFC5775], TCP-Friendly Multicast Congestion Control (TFMCC) [RFC4654], Wave and Equation Based Rate Control (WEBRC) [RFC3738], NACK-Oriented Reliable Multicast (NORM) transport protocol [RFC5740], File Delivery over Unidirectional Transport (FLUTE) [RFC6726], Real Time Protocol/Control Protocol (RTP/RTCP) [RFC3550].
マルチキャスト配信ツリーを介してデータのバルク送信を実行するアプリケーション、つまり、RTTごとに少数のUDPデータグラムを交換するアプリケーションは、輻輳制御の方法を実装する必要があります（SHOULD）。現在推奨されているIETFメソッドは次のとおりです：非同期レイヤードコーディング（ALC）[RFC5775]、TCPフレンドリーマルチキャスト輻輳制御（TFMCC）[RFC4654]、ウェーブおよび方程式ベースのレート制御（WEBRC）[RFC3738]、NACK指向の信頼できるマルチキャスト（NORM）トランスポートプロトコル[RFC5740]、一方向トランスポート経由のファイル配信（FLUTE）[RFC6726]、リアルタイムプロトコル/制御プロトコル（RTP / RTCP）[RFC3550]。
An application can alternatively implement another congestion control scheme following the guidelines of [RFC2887] and utilizing the framework of [RFC3048]. Bulk-transfer applications that choose not to implement [RFC4654], [RFC5775], [RFC3738], [RFC5740], [RFC6726], or [RFC3550] SHOULD implement a congestion control scheme that results in bandwidth use that competes fairly with TCP within an order of magnitude.
アプリケーションは、[RFC2887]のガイドラインに従い、[RFC3048]のフレームワークを利用して、別の輻輳制御方式を代わりに実装できます。 [RFC4654]、[RFC5775]、[RFC3738]、[RFC5740]、[RFC6726]、または[RFC3550]を実装しないことを選択するバルク転送アプリケーションは、内部のTCPと公平に競合する帯域幅の使用をもたらす輻輳制御スキームを実装する必要があります（SHOULD）。桁違い。
Section 2 of [RFC3551] states that multimedia applications SHOULD monitor the packet-loss rate to ensure that it is within acceptable parameters. Packet loss is considered acceptable if a TCP flow across the same network path under the same network conditions would achieve an average throughput, measured on a reasonable timescale, that is not less than that of the UDP flow. The comparison to TCP cannot be specified exactly, but is intended as an "order-of-magnitude" comparison in timescale and throughput.
[RFC3551]のセクション2には、マルチメディアアプリケーションがパケット損失率を監視して、それが許容可能なパラメータ内であることを確認する必要があると記載されています。パケット損失は、同じネットワーク条件下で同じネットワークパスを通過するTCPフローが、UDPフローのそれ以上の平均スループットを妥当なタイムスケールで測定する場合に許容できると見なされます。 TCPとの比較を正確に指定することはできませんが、タイムスケールとスループットの「桁違い」の比較を目的としています。
All the recommendations in Section 3.1.3 are also applicable to low data-volume multicast applications.
セクション3.1.3のすべての推奨事項は、データ量の少ないマルチキャストアプリケーションにも適用できます。
A multicast application SHOULD NOT send UDP datagrams that result in IP packets that exceed the effective MTU as described in Section 3 of [RFC6807]. Consequently, an application SHOULD either use the effective MTU information provided by the "Population Count Extensions to Protocol Independent Multicast (PIM)" [RFC6807] or implement path MTU discovery itself (see Section 3.2) to determine whether the path to each destination will support its desired message size without fragmentation.
[RFC6807]のセクション3で説明されているように、マルチキャストアプリケーションは、IPパケットが有効なMTUを超えるようなUDPデータグラムを送信してはなりません（SHOULD NOT）。その結果、アプリケーションは、「プロトコル独立マルチキャスト（PIM）への人口カウント拡張」[RFC6807]によって提供される有効なMTU情報を使用するか、パスMTUディスカバリー自体（セクション3.2を参照）を実装して、各宛先へのパスが断片化なしの目的のメッセージサイズ。
The de facto standard application programming interface (API) for TCP/IP applications is the "sockets" interface [POSIX]. Some platforms also offer applications the ability to directly assemble and transmit IP packets through "raw sockets" or similar facilities. This is a second, more cumbersome method of using UDP. The guidelines in this document cover all such methods through which an application may use UDP. Because the sockets API is by far the most common method, the remainder of this section discusses it in more detail.
TCP / IPアプリケーションの事実上の標準のアプリケーションプログラミングインターフェイス（API）は、「ソケット」インターフェイス[POSIX]です。一部のプラットフォームでは、「生のソケット」または同様の機能を介してIPパケットを直接組み立てて送信する機能もアプリケーションに提供します。これは、UDPを使用する2番目の、より面倒な方法です。このドキュメントのガイドラインは、アプリケーションがUDPを使用する可能性のあるすべての方法をカバーしています。ソケットAPIが最も一般的な方法であるため、このセクションの残りの部分では、このAPIについて詳しく説明します。
Although the sockets API was developed for UNIX in the early 1980s, a wide variety of non-UNIX operating systems also implement it. The sockets API supports both IPv4 and IPv6 [RFC3493]. The UDP sockets API differs from that for TCP in several key ways. Because application programmers are typically more familiar with the TCP sockets API, this section discusses these differences. [STEVENS] provides usage examples of the UDP sockets API.
ソケットAPIは1980年代初頭にUNIX用に開発されましたが、UNIX以外のさまざまなオペレーティングシステムでも実装されています。ソケットAPIはIPv4とIPv6の両方をサポートします[RFC3493]。 UDPソケットAPIは、いくつかの重要な点でTCPのAPIと異なります。アプリケーションプログラマは通常TCPソケットAPIに慣れているため、このセクションではこれらの違いについて説明します。 [STEVENS]は、UDPソケットAPIの使用例を提供します。
UDP datagrams may be directly sent and received, without any connection setup. Using the sockets API, applications can receive packets from more than one IP source address on a single UDP socket. Some servers use this to exchange data with more than one remote host through a single UDP socket at the same time. Many applications need to ensure that they receive packets from a particular source address; these applications MUST implement corresponding checks at the application layer or explicitly request that the operating system filter the received packets.
UDPデータグラムは、接続設定なしで直接送受信できます。ソケットAPIを使用すると、アプリケーションは単一のUDPソケットで複数のIP送信元アドレスからパケットを受信できます。一部のサーバーはこれを使用して、単一のUDPソケットを通じて同時に複数のリモートホストとデータを交換します。多くのアプリケーションは、特定の送信元アドレスからパケットを確実に受信する必要があります。これらのアプリケーションは、アプリケーション層で対応するチェックを実装するか、オペレーティングシステムが受信したパケットをフィルタリングすることを明示的に要求する必要があります。
Many operating systems also allow a UDP socket to be connected, i.e., to bind a UDP socket to a specific pair of addresses and ports. This is similar to the corresponding TCP sockets API functionality. However, for UDP, this is only a local operation that serves to simplify the local send/receive functions and to filter the traffic for the specified addresses and ports. Binding a UDP socket does not establish a connection -- UDP does not notify the remote end when a local UDP socket is bound. Binding a socket also allows configuring options that affect the UDP or IP layers, for example, use of the UDP checksum or the IP Timestamp option. On some stacks, a bound socket also allows an application to be notified when ICMP error messages are received for its transmissions [RFC1122].
多くのオペレーティングシステムでは、UDPソケットを接続することもできます。つまり、UDPソケットを特定のアドレスとポートのペアにバインドします。これは、対応するTCPソケットAPI機能に似ています。ただし、UDPの場合、これはローカルの送受信機能を簡素化し、指定されたアドレスとポートのトラフィックをフィルタリングするローカルの操作にすぎません。 UDPソケットをバインドしても接続は確立されません-UDPは、ローカルUDPソケットがバインドされたときにリモートエンドに通知しません。ソケットをバインドすると、UDPまたはIPレイヤーに影響を与えるオプション（UDPチェックサムやIPタイムスタンプオプションの使用など）も構成できます。一部のスタックでは、バインドされたソケットを使用して、ICMPエラーメッセージが送信されたときにアプリケーションに通知することもできます[RFC1122]。
If a client/server application executes on a host with more than one IP interface, the application SHOULD send any UDP responses with an IP source address that matches the IP destination address of the UDP datagram that carried the request (see [RFC1122], Section 4.1.3.5). Many middleboxes expect this transmission behavior and drop replies that are sent from a different IP address, as explained in Section 3.5.
クライアント/サーバーアプリケーションが複数のIPインターフェースを備えたホスト上で実行される場合、アプリケーションは、要求を伝送したUDPデータグラムのIP宛先アドレスと一致するIP送信元アドレスを持つUDP応答を送信する必要があります（[RFC1122]を参照）。 4.1.3.5）。セクション3.5で説明するように、多くのミドルボックスはこの送信動作を期待し、別のIPアドレスから送信された応答をドロップします。
A UDP receiver can receive a valid UDP datagram with a zero-length payload. Note that this is different from a return value of zero from a read() socket call, which for TCP indicates the end of the connection.
UDPレシーバーは、長さがゼロのペイロードを持つ有効なUDPデータグラムを受信できます。これは、read()ソケットコールからのゼロの戻り値とは異なります。TCPの場合、これは接続の終了を示します。
UDP provides no flow-control, i.e., the sender at any given time does not know whether the receiver is able to handle incoming transmissions. This is another reason why UDP-based applications need to be robust in the presence of packet loss. This loss can also occur within the sending host, when an application sends data faster than the line rate of the outbound network interface. It can also occur at the destination, where receive calls fail to return all the data that was sent when the application issues them too infrequently (i.e., such that the receive buffer overflows). Robust flow control mechanisms are difficult to implement, which is why applications that need this functionality SHOULD consider using a full-featured transport protocol such as TCP.
UDPはフロー制御を提供しません。つまり、送信側は、受信側が着信送信を処理できるかどうかを常に認識していません。これは、UDPベースのアプリケーションがパケット損失の存在下で堅牢である必要があるもう1つの理由です。この損失は、アプリケーションが送信ネットワークインターフェイスのラインレートよりも速くデータを送信するときに、送信ホスト内でも発生する可能性があります。また、宛先で発生することもあります。この場合、アプリケーションが発行する頻度が低すぎる（つまり、受信バッファーがオーバーフローする）と、受信呼び出しが送信されたすべてのデータを返すことができません。堅牢なフロー制御メカニズムの実装は難しいため、この機能を必要とするアプリケーションは、TCPなどのフル機能のトランスポートプロトコルの使用を検討する必要があります。
When an application closes a TCP, SCTP, or DCCP socket, the transport protocol on the receiving host is required to maintain TIME-WAIT state. This prevents delayed packets from the closed connection instance from being mistakenly associated with a later connection instance that happens to reuse the same IP address and port pairs. The UDP protocol does not implement such a mechanism. Therefore, UDP-based applications need to be robust to reordering and delay. One application may close a socket or terminate, followed in time by another application receiving on the same port. This later application may then receive packets intended for the first application that were delayed in the network.
アプリケーションがTCP、SCTP、またはDCCPソケットを閉じるとき、受信ホストのトランスポートプロトコルは、TIME-WAIT状態を維持するために必要です。これにより、閉じられた接続インスタンスからの遅延パケットが、偶然同じIPアドレスとポートのペアを再利用する後続の接続インスタンスに誤って関連付けられるのを防ぎます。 UDPプロトコルはそのようなメカニズムを実装していません。したがって、UDPベースのアプリケーションは、並べ替えや遅延に対して堅牢である必要があります。 1つのアプリケーションがソケットを閉じるか、終了した後、同じポートで別のアプリケーションが受信する場合があります。この後のアプリケーションは、ネットワークで遅延した最初のアプリケーションを対象としたパケットを受信します。
The rules and procedures for the management of the "Service Name and Transport Protocol Port Number Registry" are specified in [RFC6335]. Recommendations for use of UDP ports are provided in [RFC7605].
「サービス名とトランスポートプロトコルのポート番号レジストリ」の管理に関する規則と手順は、[RFC6335]で指定されています。 UDPポートの使用に関する推奨事項は、[RFC7605]で提供されています。
A UDP sender SHOULD NOT use a source port value of zero. A source port number that cannot be easily determined from the address or payload type provides protection at the receiver from data injection attacks by off-path devices. A UDP receiver SHOULD NOT bind to port zero.
UDP送信者は、0の送信元ポート値を使用してはなりません（SHOULD NOT）。アドレスまたはペイロードタイプから簡単に判別できない送信元ポート番号は、オフパスデバイスによるデータインジェクション攻撃からレシーバーを保護します。 UDPレシーバーはポート0にバインドすべきではありません（SHOULD NOT）。
Applications SHOULD implement receiver port and address checks at the application layer or explicitly request that the operating system filter the received packets to prevent receiving packets with an arbitrary port. This measure is designed to provide additional protection from data injection attacks from an off-path source (where the port values may not be known).
アプリケーションは、アプリケーション層でレシーバーのポートとアドレスのチェックを実装する必要があります。この対策は、オフポートソース（ポート値が不明な場合がある）からのデータインジェクション攻撃からの保護を強化するために設計されています。
Applications SHOULD provide a check that protects from off-path data injection, avoiding an application receiving packets that were created by an unauthorized third party. TCP stacks commonly use a randomized source port to provide this protection [RFC6056]; UDP applications should follow the same technique. Middleboxes and end systems often make assumptions about the system ports or user ports; hence, it is recommended to use randomized ports in the Dynamic and/ or Private Port range. Setting a "randomized" source port also provides greater assurance that reported ICMP errors originate from network systems on the path used by a particular flow. Some UDP applications choose to use a predetermined value for the source port (including some multicast applications), these applications need to therefore employ a different technique. Protection from off-path data attacks can also be provided by randomizing the initial value of another protocol field within the datagram payload, and checking the validity of this field at the receiver (e.g., RTP has random initial sequence number and random media timestamp offsets [RFC3550]).
アプリケーションは、パス外のデータインジェクションから保護するチェックを提供して、アプリケーションが不正なサードパーティによって作成されたパケットを受信することを回避する必要があります。 TCPスタックは通常、ランダム化された送信元ポートを使用してこの保護を提供します[RFC6056]。 UDPアプリケーションも同じ手法に従う必要があります。ミドルボックスとエンドシステムは、多くの場合、システムポートまたはユーザーポートについて想定しています。したがって、ダイナミックポートまたはプライベートポートの範囲でランダム化されたポートを使用することをお勧めします。 「ランダム化された」送信元ポートを設定すると、報告されたICMPエラーが、特定のフローで使用されるパス上のネットワークシステムから発生していることがより確実になります。一部のUDPアプリケーションは、送信元ポートに事前に決定された値を使用することを選択します（一部のマルチキャストアプリケーションを含む）。したがって、これらのアプリケーションは異なる手法を使用する必要があります。オフパスデータ攻撃からの保護は、データグラムペイロード内の別のプロトコルフィールドの初期値をランダム化し、受信側でこのフィールドの有効性をチェックすることでも提供できます（たとえば、RTPにはランダムな初期シーケンス番号とランダムなメディアタイムスタンプオフセットがあります[ RFC3550]）。
When using multicast, IP routers perform a reverse-path forwarding (RPF) check for each multicast packet. This provides protection from off-path data injection, restricting opportunities to forge a packet's source address. When a receiver joins a multicast group and filters based on the source address the filter verifies the sender's IP address. This is always the case when using an SSM {S,G} channel.
マルチキャストを使用する場合、IPルーターは各マルチキャストパケットに対してリバースパス転送（RPF）チェックを実行します。これにより、オフパスデータインジェクションから保護され、パケットの送信元アドレスを偽造する機会が制限されます。受信者がマルチキャストグループに参加し、送信元アドレスに基づいてフィルタリングすると、フィルターは送信者のIPアドレスを確認します。これは、SSM {S、G}チャネルを使用する場合は常に当てはまります。
Some applications use the UDP datagram header as a source of entropy for network devices that implement ECMP [RFC6438]. A UDP tunnel application targeting this usage encapsulates an inner packet using UDP, where the UDP source port value forms a part of the entropy that can be used to balance forwarding of network traffic by the devices that use ECMP. A sending tunnel endpoint selects a source port value in the UDP datagram header that is computed from the inner flow information (e.g., the encapsulated packet headers). To provide sufficient entropy, the sending tunnel endpoint maps the encapsulated traffic to one of a range of UDP source values. The 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. The available source port entropy of 14 bits (using the ephemeral port range) plus the outer IP addresses seems sufficient for entropy for most ECMP applications [ENCAP].
一部のアプリケーションは、ECMP [RFC6438]を実装するネットワークデバイスのエントロピーのソースとしてUDPデータグラムヘッダーを使用します。この使用法をターゲットとするUDPトンネルアプリケーションは、UDPを使用して内部パケットをカプセル化します。UDP送信元ポートの値は、ECMPを使用するデバイスによるネットワークトラフィックの転送のバランスをとるために使用できるエントロピーの一部を形成します。送信トンネルエンドポイントは、内部フロー情報（たとえば、カプセル化されたパケットヘッダー）から計算されるUDPデータグラムヘッダーのソースポート値を選択します。十分なエントロピーを提供するために、送信側トンネルエンドポイントは、カプセル化されたトラフィックをUDPソース値の範囲の1つにマッピングします。値は、エフェメラルポートの範囲内（49152〜65535）にある必要があります（SHOULD）。ポートの上位2ビットが1に設定されています。 14ビット（エフェメラルポート範囲を使用）の使用可能なソースポートエントロピーと外部IPアドレスは、ほとんどのECMPアプリケーション[ENCAP]のエントロピーに十分なようです。
To avoid reordering within an IP flow, the same UDP source port value SHOULD be used for all packets assigned to an encapsulated flow (e.g., using a hash of the relevant headers). The entropy mapping for a flow MAY change over the lifetime of the encapsulated flow [ENCAP]. For instance, this could be changed as a Denial of Service (DOS) mitigation, or as a means to effect routing through the ECMP network. However, the source port selected for a flow SHOULD NOT change more than once in every thirty seconds (e.g., as in [RFC8086]).
IPフロー内での並べ替えを回避するために、カプセル化されたフローに割り当てられたすべてのパケットに同じUDPソースポート値を使用する必要があります（たとえば、関連するヘッダーのハッシュを使用）。フローのエントロピーマッピングは、カプセル化されたフローの存続期間中に変更される場合があります[ENCAP]。たとえば、これはサービス拒否（DOS）の緩和策として、またはECMPネットワークを介したルーティングを実行する手段として変更できます。ただし、フローに選択された送信元ポートは、30秒ごとに2回以上変更してはなりません（たとえば、[RFC8086]のように）。
The use of the source port field for entropy has several side effects that need to be considered, including:
エントロピーに送信元ポートフィールドを使用すると、次のようないくつかの副作用を考慮する必要があります。
o It can increase the probability of misdelivery of corrupted packets, which increases the need for checksum computation or an equivalent mechanism to protect other UDP applications from misdelivery errors Section 3.4.
o 破損したパケットが誤って配信される可能性が高くなるため、チェックサム計算または同等のメカニズムを使用して、他のUDPアプリケーションを配信エラーから保護する必要があります。
o It is expected to reduce the probability of successful middlebox traversal Section 3.5. This use of the source port field will often not be suitable for applications targeting deployment in the general Internet.
o ミドルボックストラバーサルセクション3.5が成功する確率は低くなると予想されます。このソースポートフィールドの使用は、一般的なインターネットでの展開を対象とするアプリケーションには適さないことがよくあります。
o It can prevent the field being usable to protect from off-path attacks (described in Section 5.1). Designers therefore need to consider other mechanisms to provide equivalent protection (e.g., to restrict use to a controlled environment [RFC7510] Section 3.6).
o オフパス攻撃から保護するためにフィールドを使用できないようにすることができます（セクション5.1で説明）。したがって、設計者は同等の保護を提供するために他のメカニズムを検討する必要があります（たとえば、使用を制御された環境に制限するために[RFC7510]セクション3.6）。
The UDP source port number field has also been leveraged to produce entropy with IPv6. However, in the case of IPv6, the "flow label" [RFC6437] may also alternatively be used to provide entropy for load balancing [RFC6438]. This use of the flow label for load balancing is consistent with the definition of the field, 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 was specified.
UDP送信元ポート番号フィールドもIPv6でエントロピーを生成するために活用されています。ただし、IPv6の場合、「フローラベル」[RFC6437]を使用して、負荷分散のエントロピーを提供することもできます[RFC6438]。負荷分散のためのフローラベルのこの使用は、フィールドの定義と一致していますが、この目的でフィールドを一貫して使用できるようにするには、さらに明確にする必要がありました。したがって、更新されたIPv6フローラベル[RFC6437]およびECMPルーティング[RFC6438]の使用法が指定されました。
To ensure future opportunities to use the flow label, UDP applications SHOULD set the flow label field, even when an entropy value is also set in the source port field (e.g., An IPv6 tunnel endpoint could copy the source port flow entropy value to the IPv6 flow label field [RFC8086]). Router vendors are encouraged to start using the IPv6 flow label as a part of the flow hash, providing support for IP-level ECMP without requiring use of UDP. 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 will likely continue until widespread deployment is finally achieved.
フローラベルを使用する将来の機会を確保するために、エントロピー値がソースポートフィールドにも設定されている場合でも、UDPアプリケーションはフローラベルフィールドを設定する必要があります（たとえば、IPv6トンネルエンドポイントはソースポートフローエントロピー値をIPv6にコピーできます）フローラベルフィールド[RFC8086]）。ルーターベンダーは、IPv6フローラベルをフローハッシュの一部として使用し始め、UDPを使用せずにIPレベルのECMPをサポートすることをお勧めします。ロードバランシングにフローラベルをエンドツーエンドで使用することは、長期的なソリューションです。フローラベルの使用法が明確になっている場合でも、エンドポイントのかなりの割合が、元のフローに高品質のフローラベルを割り当て始めるまでの移行時間があります。トランスポートヘッダーフィールドを使用したロードバランシングの使用は、広範な展開が最終的に達成されるまで続く可能性があります。
A single application may exchange several types of data. In some cases, this may require multiple UDP flows (e.g., multiple sets of flows, identified by different five-tuples). [RFC6335] recommends application developers not to apply to IANA to be assigned multiple well-known ports (user or system). It does not discuss the implications of using multiple flows with the same well-known port or pairs of dynamic ports (e.g., identified by a service name or signaling protocol).
1つのアプリケーションが複数のタイプのデータを交換する場合があります。場合によっては、これには複数のUDPフローが必要になることがあります（たとえば、異なる5つのタプルで識別される複数のフローセット）。 [RFC6335]は、アプリケーション開発者に、複数の既知のポート（ユーザーまたはシステム）が割り当てられるIANAに適用しないことを推奨しています。同じ既知のポートまたは動的ポートのペア（たとえば、サービス名またはシグナリングプロトコルによって識別される）で複数のフローを使用することの影響については説明しません。
Use of multiple flows can affect the network in several ways:
複数のフローを使用すると、いくつかの方法でネットワークに影響を与える可能性があります。
o Starting a series of successive connections can increase the number of state bindings in middleboxes (e.g., NAPT or Firewall) along the network path. UDP-based middlebox traversal usually relies on timeouts to remove old state, since middleboxes are unaware when a particular flow ceases to be used by an application.
o 一連の連続した接続を開始すると、ネットワークパスに沿ったミドルボックス（NAPTやファイアウォールなど）の状態バインディングの数が増える可能性があります。 UDPベースのミドルボックストラバーサルは、通常、タイムアウトに依存して古い状態を削除します。これは、ミドルボックスは、特定のフローがアプリケーションで使用されなくなると認識されないためです。
o Using several flows at the same time may result in seeing different network characteristics for each flow. It cannot be assumed both follow the same path (e.g., when ECMP is used, traffic is intentionally hashed onto different parallel paths based on the port numbers).
o 複数のフローを同時に使用すると、フローごとに異なるネットワーク特性が表示される場合があります。両方が同じパスをたどっていると仮定することはできません（たとえば、ECMPを使用する場合、トラフィックはポート番号に基づいて異なる並列パスに意図的にハッシュされます）。
o Using several flows can also increase the occupancy of a binding or lookup table in a middlebox (e.g., NAPT or Firewall), which may cause the device to change the way it manages the flow state.
o 複数のフローを使用すると、ミドルボックス（NAPTやファイアウォールなど）内のバインディングテーブルまたはルックアップテーブルの占有率が増加する可能性があります。これにより、デバイスがフロー状態の管理方法を変更する可能性があります。
o Further, using excessive numbers of flows can degrade the ability of a unicast congestion control to react to congestion events, unless the congestion state is shared between all flows in a session. A receiver-driven multicast congestion control requires the sending application to distribute its data over a set of IP multicast groups, each receiver is therefore expected to receive data from a modest number of simultaneously active UDP ports.
o さらに、過剰な数のフローを使用すると、セッション内のすべてのフロー間で輻輳状態が共有されない限り、ユニキャスト輻輳制御が輻輳イベントに反応する能力が低下する可能性があります。レシーバー主導のマルチキャスト輻輳制御では、送信アプリケーションが一連のIPマルチキャストグループにデータを配信する必要があります。したがって、各レシーバーは、適度な数の同時にアクティブなUDPポートからデータを受信することが期待されます。
Therefore, applications MUST NOT assume consistent behavior of middleboxes when multiple UDP flows are used; many devices respond differently as the number of used ports increases. Using multiple flows with different QoS requirements requires applications to verify that the expected performance is achieved using each individual flow (five-tuple), see Section 3.1.9.
したがって、複数のUDPフローが使用されている場合、アプリケーションはミドルボックスの一貫した動作を想定してはなりません。使用されるポートの数が増えると、多くのデバイスの応答が異なります。 QoS要件が異なる複数のフローを使用するには、アプリケーションが、個々のフロー（5タプル）を使用して期待されるパフォーマンスが達成されていることを確認する必要があります。セクション3.1.9を参照してください。
Applications can utilize information about ICMP error messages that the UDP layer passes up for a variety of purposes [RFC1122]. Applications SHOULD appropriately validate the payload of ICMP messages to ensure these are received in response to transmitted traffic (i.e., a reported error condition that corresponds to a UDP datagram actually sent by the application). This requires context, such as local state about communication instances to each destination, that although readily available in connection-oriented transport protocols is not always maintained by UDP-based applications. Note that not all platforms have the necessary APIs to support this validation, and some platforms already perform this validation internally before passing ICMP information to the application.
アプリケーションは、UDP層がさまざまな目的で渡すICMPエラーメッセージに関する情報を利用できます[RFC1122]。アプリケーションは、ICMPメッセージのペイロードを適切に検証して、送信されたトラフィック（つまり、アプリケーションによって実際に送信されたUDPデータグラムに対応する報告されたエラー状態）に応答してこれらが受信されることを確認する必要があります。これには、各宛先への通信インスタンスに関するローカル状態などのコンテキストが必要ですが、接続指向のトランスポートプロトコルですぐに利用できるわけではありませんが、UDPベースのアプリケーションによって常に維持されるとは限りません。すべてのプラットフォームがこの検証をサポートするために必要なAPIを備えているわけではないことに注意してください。一部のプラットフォームは、ICMP情報をアプリケーションに渡す前にすでにこの検証を内部で実行しています。
Any application response to ICMP error messages SHOULD be robust to temporary routing failures (sometimes called "soft errors"), e.g., transient ICMP "unreachable" messages ought to not normally cause a communication abort.
ICMPエラーメッセージに対するアプリケーションの応答は、一時的なルーティングエラー（「ソフトエラー」と呼ばれることもあります）に対して堅牢である必要があります。たとえば、一時的なICMP「到達不能」メッセージは、通常、通信の中断を引き起こすべきではありません。
ICMP messages are being increasingly filtered by middleboxes. A UDP application therefore SHOULD NOT rely on their delivery for correct and safe operation.
ICMPメッセージはミドルボックスによってますますフィルタリングされています。したがって、UDPアプリケーションは、正確で安全な操作のためにそれらの配信に依存するべきではありません。
UDP does not provide communications security. Applications that need to protect their communications against eavesdropping, tampering, or message forgery SHOULD employ end-to-end security services provided by other IETF protocols.
UDPは通信セキュリティを提供しません。盗聴、改ざん、またはメッセージの偽造から通信を保護する必要があるアプリケーションは、他のIETFプロトコルによって提供されるエンドツーエンドのセキュリティサービスを採用する必要があります。
UDP applications SHOULD provide protection from off-path data injection attacks using a randomized source port or equivalent technique (see Section 5.1).
UDPアプリケーションは、ランダム化されたソースポートまたは同等の技術を使用して、オフパスデータインジェクション攻撃からの保護を提供する必要があります（セクション5.1を参照）。
Applications that respond to short requests with potentially large responses are a potential vector for amplification attacks, and SHOULD take steps to minimize their potential for being abused as part of a DoS attack. That could mean authenticating the sender before responding; noting that the source IP address of a request is not a useful authenticator, because it can easily be spoofed. Or it may mean otherwise limiting the cases where short unauthenticated requests produce large responses. Applications MAY also want to offer ways to limit the number of requests they respond to in a time interval, in order to cap the bandwidth they consume.
短いリクエストに応答する可能性のある大きな応答で応答するアプリケーションは、増幅攻撃の潜在的なベクトルであり、DoS攻撃の一部として悪用される可能性を最小限に抑えるための措置を講じるべきです（SHOULD）。これは、応答する前に送信者を認証することを意味します。要求のソースIPアドレスは、簡単に偽装される可能性があるため、有用なオーセンティケーターではないことに注意してください。または、認証されていない短いリクエストが大きな応答を生成するケースを制限することを意味する場合があります。また、アプリケーションは、消費する帯域幅を制限するために、時間間隔で応答する要求の数を制限する方法を提供する必要があります。
One option for securing UDP communications is with IPsec [RFC4301], which can provide authentication for flows of IP packets through the Authentication Header (AH) [RFC4302] and encryption and/or authentication through the Encapsulating Security Payload (ESP) [RFC4303]. Applications use the Internet Key Exchange (IKE) [RFC7296] to configure IPsec for their sessions. Depending on how IPsec is configured for a flow, it can authenticate or encrypt the UDP headers as well as UDP payloads. If an application only requires authentication, ESP with no encryption but with authentication is often a better option than AH, because ESP can operate across middleboxes. An application that uses IPsec requires the support of an operating system that implements the IPsec protocol suite, and the network path must permit IKE and IPsec traffic. This may become more common with IPv6 deployments [RFC6092].
UDP通信を保護するための1つのオプションは、IPsec [RFC4301]を使用することです。これにより、認証ヘッダー（AH）[RFC4302]を介したIPパケットのフローの認証、およびカプセル化セキュリティペイロード（ESP）[RFC4303]を介した暗号化または認証を提供できます。アプリケーションは、インターネットキーエクスチェンジ（IKE）[RFC7296]を使用して、セッションのIPsecを構成します。 IPsecがフローに対してどのように構成されているかによって、UDPヘッダーだけでなくUDPペイロードも認証または暗号化できます。アプリケーションが認証のみを必要とする場合、ESPはミドルボックス全体で動作できるため、暗号化なしで認証付きのESPがAHよりも優れたオプションであることがよくあります。 IPsecを使用するアプリケーションは、IPsecプロトコルスイートを実装するオペレーティングシステムのサポートを必要とし、ネットワークパスはIKEおよびIPsecトラフィックを許可する必要があります。これは、IPv6展開でより一般的になる可能性があります[RFC6092]。
Although it is possible to use IPsec to secure UDP communications, not all operating systems support IPsec or allow applications to easily configure it for their flows. A second option for securing UDP communications is through Datagram Transport Layer Security (DTLS) [RFC6347][RFC7525]. DTLS provides communication privacy by encrypting UDP payloads. It does not protect the UDP headers. Applications can implement DTLS without relying on support from the operating system.
IPsecを使用してUDP通信をセキュリティで保護することは可能ですが、すべてのオペレーティングシステムがIPsecをサポートしたり、アプリケーションがIPsecをフロー用に簡単に構成したりできるようにするわけではありません。 UDP通信を保護するための2番目のオプションは、Datagram Transport Layer Security（DTLS）[RFC6347] [RFC7525]を使用することです。 DTLSは、UDPペイロードを暗号化することで通信プライバシーを提供します。 UDPヘッダーは保護されません。アプリケーションは、オペレーティングシステムのサポートに依存せずにDTLSを実装できます。
Many other options for authenticating or encrypting UDP payloads exist. For example, the GSS-API security framework [RFC2743] or Cryptographic Message Syntax (CMS) [RFC5652] could be used to protect UDP payloads. There exist a number of security options for RTP [RFC3550] over UDP, especially to accomplish key-management, see [RFC7201]. These options covers many usages, including point-to-point, centralized group communication as well as multicast. In some applications, a better solution is to protect larger stand-alone objects, such as files or messages, instead of individual UDP payloads. In these situations, CMS [RFC5652], S/MIME [RFC5751] or OpenPGP [RFC4880] could be used. In addition, there are many non-IETF protocols in this area.
UDPペイロードを認証または暗号化するための他の多くのオプションが存在します。たとえば、GSS-APIセキュリティフレームワーク[RFC2743]または暗号化メッセージ構文（CMS）[RFC5652]を使用して、UDPペイロードを保護できます。特にキー管理を実現するために、UDPを介したRTP [RFC3550]にはいくつかのセキュリティオプションがあります。[RFC7201]を参照してください。これらのオプションは、ポイントツーポイントの集中型グループ通信やマルチキャストを含む、多くの使用法をカバーしています。一部のアプリケーションでは、個々のUDPペイロードの代わりに、ファイルやメッセージなどのより大きなスタンドアロンオブジェクトを保護する方がより良いソリューションです。これらの状況では、CMS [RFC5652]、S / MIME [RFC5751]、またはOpenPGP [RFC4880]を使用できます。さらに、この領域には多くの非IETFプロトコルがあります。
Like congestion control mechanisms, security mechanisms are difficult to design and implement correctly. It is hence RECOMMENDED that applications employ well-known standard security mechanisms such as DTLS or IPsec, rather than inventing their own.
輻輳制御メカニズムと同様に、セキュリティメカニズムも正しく設計および実装することが困難です。したがって、アプリケーションは独自に開発するのではなく、DTLSやIPsecなどのよく知られている標準のセキュリティメカニズムを使用することをお勧めします。
The Generalized TTL Security Mechanism (GTSM) [RFC5082] may be used with UDP applications when the intended endpoint is on the same link as the sender. This lightweight mechanism allows a receiver to filter unwanted packets.
Generalized TTL Security Mechanism（GTSM）[RFC5082]は、目的のエンドポイントが送信者と同じリンク上にある場合、UDPアプリケーションで使用できます。この軽量メカニズムにより、受信者は不要なパケットをフィルタリングできます。
In terms of congestion control, [RFC2309] and [RFC2914] discuss the dangers of congestion-unresponsive flows to the Internet. [RFC8084] describes methods that can be used to set a performance envelope that can assist in preventing congestion collapse in the absence of congestion control or when the congestion control fails to react to congestion events. This document provides guidelines to designers of UDP-based applications to congestion-control their transmissions, and does not raise any additional security concerns.
輻輳制御の観点から、[RFC2309]と[RFC2914]は、輻輳に反応しないインターネットへのフローの危険性について説明しています。 [RFC8084]は、輻輳制御がない場合、または輻輳制御が輻輳イベントに反応しない場合に、輻輳の崩壊を防止するのに役立つパフォーマンスエンベロープを設定するために使用できる方法について説明しています。このドキュメントは、UDPベースのアプリケーションの設計者が送信を輻輳制御するためのガイドラインを提供するものであり、セキュリティに関する追加の問題を提起するものではありません。
Some network operators have experienced surges of UDP attack traffic that are multiple orders of magnitude above the baseline traffic rate for UDP. This can motivate operators to limit the data rate or packet rate of UDP traffic. This may in turn limit the throughput that an application can achieve using UDP and could also result in higher packet loss for UDP traffic that would not be experienced if other transport protocols had been used.
一部のネットワークオペレーターは、UDPのベースライントラフィックレートを何桁も上回るUDP攻撃トラフィックの急増を経験しています。これにより、オペレーターはUDPトラフィックのデータレートまたはパケットレートを制限することができます。これにより、アプリケーションがUDPを使用して達成できるスループットが制限される可能性があり、他のトランスポートプロトコルが使用された場合に発生しないUDPトラフィックのパケット損失が増加する可能性もあります。
A UDP application with a long-lived association between the sender and receiver, ought to be designed so that the sender periodically checks that the receiver still wants ("consents") to receive traffic and need to be designed to stop if there is no explicit confirmation of this [RFC7675]. Applications that require communications in two directions to implement protocol functions (such as reliability or congestion control) will need to independently check both directions of communication, and may have to exchange keep-alive messages to traverse middleboxes (see Section 3.5).
送信者と受信者の間に長期間の関連付けがあるUDPアプリケーションは、送信者が受信者が引き続きトラフィックを受信することを望んでいること（「同意」）を定期的にチェックし、明示的なものがない場合は停止するように設計する必要があるように設計する必要があります。これの確認[RFC7675]。プロトコル機能（信頼性や輻輳制御など）を実装するために2方向の通信を必要とするアプリケーションでは、通信の両方向を個別にチェックする必要があり、ミドルボックスを通過するためにキープアライブメッセージを交換する必要がある場合があります（セクション3.5を参照）。
This section summarizes the key guidelines made in Sections 3 - 6 in a tabular format (Table 1) for easy referencing.
このセクションでは、簡単に参照できるように、セクション3〜6で作成した主要なガイドラインを表形式（表1）にまとめます。
+---------------------------------------------------------+---------+
| Recommendation | Section |
+---------------------------------------------------------+---------+
| MUST tolerate a wide range of Internet path conditions | 3 |
| SHOULD use a full-featured transport (e.g., TCP) | |
| | |
| SHOULD control rate of transmission | 3.1 |
| SHOULD perform congestion control over all traffic | |
| | |
| for bulk transfers, | 3.1.2 |
| SHOULD consider implementing TFRC | |
| else, SHOULD in other ways use bandwidth similar to TCP | |
| | |
| for non-bulk transfers, | 3.1.3 |
| SHOULD measure RTT and transmit max. 1 datagram/RTT | 3.1.1 |
| else, SHOULD send at most 1 datagram every 3 seconds | |
| SHOULD back-off retransmission timers following loss | |
| | |
| SHOULD provide mechanisms to regulate the bursts of | 3.1.6 |
| transmission | |
| | |
| MAY implement ECN; a specific set of application | 3.1.7 |
| mechanisms are REQUIRED if ECN is used. | |
| | |
| for DiffServ, SHOULD NOT rely on implementation of PHBs | 3.1.8 |
| | |
| for QoS-enabled paths, MAY choose not to use CC | 3.1.9 |
| | |
| SHOULD NOT rely solely on QoS for their capacity | 3.1.10 |
| non-CC controlled flows SHOULD implement a transport | |
| circuit breaker | |
| MAY implement a circuit breaker for other applications | |
| | |
| for tunnels carrying IP traffic, | 3.1.11 |
| SHOULD NOT perform congestion control | |
| MUST correctly process the IP ECN field | |
| | |
| for non-IP tunnels or rate not determined by traffic, | |
| SHOULD perform CC or use circuit breaker | 3.1.11 |
| SHOULD restrict types of traffic transported by the | |
| tunnel | |
| | |
| SHOULD NOT send datagrams that exceed the PMTU, i.e., | 3.2 |
| SHOULD discover PMTU or send datagrams < minimum PMTU; | |
| Specific application mechanisms are REQUIRED if PLPMTUD | |
| is used. | |
| | |
| SHOULD handle datagram loss, duplication, reordering | 3.3 |
| SHOULD be robust to delivery delays up to 2 minutes | |
| | |
| SHOULD enable IPv4 UDP checksum | 3.4 |
| SHOULD enable IPv6 UDP checksum; Specific application | 3.4.1 |
| mechanisms are REQUIRED if a zero IPv6 UDP checksum is | |
| used. | |
| | |
| SHOULD provide protection from off-path attacks | 5.1 |
| else, MAY use UDP-Lite with suitable checksum coverage | 3.4.2 |
| | |
| SHOULD NOT always send middlebox keep-alive messages | 3.5 |
| MAY use keep-alives when needed (min. interval 15 sec) | |
| | |
| Applications specified for use in limited use (or | 3.6 |
| controlled environments) SHOULD identify equivalent | |
| mechanisms and describe their use case. | |
| | |
| Bulk-multicast apps SHOULD implement congestion control | 4.1.1 |
| | |
| Low volume multicast apps SHOULD implement congestion | 4.1.2 |
| control | |
| | |
| Multicast apps SHOULD use a safe PMTU | 4.2 |
| | |
| SHOULD avoid using multiple ports | 5.1.2 |
| MUST check received IP source address | |
| | |
| SHOULD validate payload in ICMP messages | 5.2 |
| | |
| SHOULD use a randomized source port or equivalent | 6 |
| technique, and, for client/server applications, SHOULD | |
| send responses from source address matching request | |
| 5.1 | |
| SHOULD use standard IETF security protocols when needed | 6 |
+---------------------------------------------------------+---------+
Table 1: Summary of Recommendations
表1：推奨事項の要約
[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>。
[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>。
[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>。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990, <http://www.rfc-editor.org/info/rfc1191>.
[RFC1191] Mogul、J。およびS. Deering、「Path MTU discovery」、RFC 1191、DOI 10.17487 / RFC1191、1990年11月、<http://www.rfc-editor.org/info/rfc1191>。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 1996, <http://www.rfc-editor.org/info/rfc1981>.
[RFC1981] McCann、J.、Deering、S。、およびJ. Mogul、「Path MTU Discovery for IP version 6」、RFC 1981、DOI 10.17487 / RFC1981、1996年8月、<http：//www.rfc-editor。 org / info / rfc1981>。
[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>。
[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>。
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed., and G. Fairhurst, Ed., "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July 2004, <http://www.rfc-editor.org/info/rfc3828>.
[RFC3828] Larzon、LA。、Degermark、M.、Pink、S.、Jonsson、LE。、Ed。、and G. Fairhurst、Ed。、 "The Lightweight User Datagram Protocol（UDP-Lite）"、RFC 3828、 DOI 10.17487 / RFC3828、2004年7月、<http://www.rfc-editor.org/info/rfc3828>。
[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> 。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, <http://www.rfc-editor.org/info/rfc4821>.
[RFC4821] Mathis、M。およびJ. Heffner、「Packetization Layer Path MTU Discovery」、RFC 4821、DOI 10.17487 / RFC4821、2007年3月、<http://www.rfc-editor.org/info/rfc4821>。
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, DOI 10.17487/RFC5348, September 2008, <http://www.rfc-editor.org/info/rfc5348>.
[RFC5348] Floyd、S.、Handley、M.、Padhye、J。、およびJ. Widmer、「TCP Friendly Rate Control（TFRC）：Protocol Specification」、RFC 5348、DOI 10.17487 / RFC5348、2008年9月、<http： //www.rfc-editor.org/info/rfc5348>。
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, DOI 10.17487/RFC5405, November 2008, <http://www.rfc-editor.org/info/rfc5405>.
[RFC5405] Eggert、L。およびG. Fairhurst、「アプリケーション設計者のためのユニキャストUDP使用ガイドライン」、BCP 145、RFC 5405、DOI 10.17487 / RFC5405、2008年11月、<http://www.rfc-editor.org/info / rfc5405>。
[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>。
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, DOI 10.17487/RFC6298, June 2011, <http://www.rfc-editor.org/info/rfc6298>.
[RFC6298] Paxson、V.、Allman、M.、Chu、J。、およびM. Sargent、「Computing TCP's Retransmission Timer」、RFC 6298、DOI 10.17487 / RFC6298、2011年6月、<http：//www.rfc- editor.org/info/rfc6298>。
[RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, <http://www.rfc-editor.org/info/rfc8084>.
[RFC8084] Fairhurst、G。、「Network Transport Circuit Breakers」、BCP 208、RFC 8084、DOI 10.17487 / RFC8084、2017年3月、<http://www.rfc-editor.org/info/rfc8084>。
[ALLMAN] Allman, M. and E. Blanton, "Notes on burst mitigation for transport protocols", March 2005.
[ALLMAN] Allman、M。、およびE. Blanton、「トランスポートプロトコルのバースト緩和に関するノート」、2005年3月。
[BEHAVE-APP] Ford, B., "Application Design Guidelines for Traversal through Network Address Translators", Work in Progress, draft-ford-behave-app-05, March 2007.
[BEHAVE-APP]フォードB.、「ネットワークアドレストランスレータを通過するためのアプリケーション設計ガイドライン」、作業中、draft-ford-behave-app-05、2007年3月。
[ENCAP] Nordmark, E., Ed., Tian, A., Gross, J., Hudson, J., Kreeger, L., Garg, P., Thaler, P., and T. Herbert, "Encapsulation Considerations", Work in Progress, draft-ietf-rtgwg-dt-encap-02, October 2016.
[ENCAP] Nordmark、E.、Ed。、Tian、A.、Gross、J.、Hudson、J.、Kreeger、L.、Garg、P.、Thaler、P。、およびT. Herbert、「カプセル化に関する考慮事項」 、Work in Progress、draft-ietf-rtgwg-dt-encap-02、2016年10月。
[FABER] Faber, T., Touch, J., and W. Yue, "The TIME-WAIT State in TCP and Its Effect on Busy Servers", Proc. IEEE Infocom, March 1999.
[FABER] Faber、T.、Touch、J。、およびW. Yue、「TCPのTIME-WAIT状態とビジーサーバーへの影響」、Proc。 IEEE Infocom、1999年3月。
[INT-TUNNELS] Touch, J. and W. Townsley, "IP Tunnels in the Internet Architecture", Work in Progress, draft-ietf-intarea-tunnels-03, July 2016.
[INT-TUNNELS] Touch、J。およびW. Townsley、「インターネットアーキテクチャにおけるIPトンネル」、作業中、draft-ietf-intarea-tunnels-03、2016年7月。
[POSIX] IEEE Std. 1003.1-2001, , "Standard for Information Technology - Portable Operating System Interface (POSIX)", Open Group Technical Standard: Base Specifications Issue 6, ISO/IEC 9945:2002, December 2001.
[POSIX] IEEE Std。 1003.1-2001、「情報技術の標準-ポータブルオペレーティングシステムインターフェース（POSIX）」、オープングループ技術標準：基本仕様第6号、ISO / IEC 9945：2002、2001年12月。
[RFC919] Mogul, J., "Broadcasting Internet Datagrams", STD 5, RFC 919, DOI 10.17487/RFC0919, October 1984, <http://www.rfc-editor.org/info/rfc919>.
[RFC919] Mogul、J。、「Broadcasting Internet Datagrams」、STD 5、RFC 919、DOI 10.17487 / RFC0919、1984年10月、<http://www.rfc-editor.org/info/rfc919>。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, DOI 10.17487/RFC1112, August 1989, <http://www.rfc-editor.org/info/rfc1112>.
[RFC1112] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、DOI 10.17487 / RFC1112、1989年8月、<http://www.rfc-editor.org/info/rfc1112>。
[RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. Miller, "Common DNS Implementation Errors and Suggested Fixes", RFC 1536, DOI 10.17487/RFC1536, October 1993, <http://www.rfc-editor.org/info/rfc1536>.
[RFC1536] Kumar、A.、Postel、J.、Neuman、C.、Danzig、P。、およびS. Miller、「一般的なDNS実装エラーと推奨される修正」、RFC 1536、DOI 10.17487 / RFC1536、1993年10月、< http://www.rfc-editor.org/info/rfc1536>。
[RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, DOI 10.17487/RFC1546, November 1993, <http://www.rfc-editor.org/info/rfc1546>.
[RFC1546] Partridge、C.、Mendez、T。、およびW. Milliken、「Host Anycasting Service」、RFC 1546、DOI 10.17487 / RFC1546、1993年11月、<http://www.rfc-editor.org/info/ rfc1546>。
[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J., and L. Zhang, "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, DOI 10.17487/RFC2309, April 1998, <http://www.rfc-editor.org/info/rfc2309>.
[RFC2309]ブレーデン、B。、クラーク、D。、クロウクロフト、J。、デイビー、B。、ディアリング、S。、エストリン、D。、フロイド、S。、ジェイコブソン、V。、ミンシャル、G。、パートリッジ、 C.、Peterson、L.、Ramakrishnan、K.、Shenker、S.、Wroclawski、J。、およびL. Zhang、「インターネットでのキュー管理と輻輳回避に関する推奨事項」、RFC 2309、DOI 10.17487 / RFC2309、4月1998、<http://www.rfc-editor.org/info/rfc2309>。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, <http://www.rfc-editor.org/info/rfc2475>.
[RFC2475] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z.、and W. Weiss、 "An Architecture for Differentiated Services"、RFC 2475、DOI 10.17487 / RFC2475、December 1998、<http://www.rfc-editor.org/info/rfc2475>。
[RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", RFC 2675, DOI 10.17487/RFC2675, August 1999, <http://www.rfc-editor.org/info/rfc2675>.
[RFC2675] Borman、D.、Deering、S。、およびR. Hinden、「IPv6 Jumbograms」、RFC 2675、DOI 10.17487 / RFC2675、1999年8月、<http://www.rfc-editor.org/info/rfc2675 >。
[RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, DOI 10.17487/RFC2743, January 2000, <http://www.rfc-editor.org/info/rfc2743>.
[RFC2743] Linn、J。、「Generic Security Service Application Program Interface Version 2、Update 1」、RFC 2743、DOI 10.17487 / RFC2743、2000年1月、<http://www.rfc-editor.org/info/rfc2743> 。
[RFC2887] Handley, M., Floyd, S., Whetten, B., Kermode, R., Vicisano, L., and M. Luby, "The Reliable Multicast Design Space for Bulk Data Transfer", RFC 2887, DOI 10.17487/RFC2887, August 2000, <http://www.rfc-editor.org/info/rfc2887>.
[RFC2887] Handley、M.、Floyd、S.、Whetten、B.、Kermode、R.、Vicisano、L。、およびM. Luby、「バルクデータ転送のための信頼できるマルチキャストデザインスペース」、RFC 2887、DOI 10.17487 / RFC2887、2000年8月、<http://www.rfc-editor.org/info/rfc2887>。
[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>。
[RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S., and M. Luby, "Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer", RFC 3048, DOI 10.17487/RFC3048, January 2001, <http://www.rfc-editor.org/info/rfc3048>.
[RFC3048] Whetten、B.、Vicisano、L.、Kermode、R.、Handley、M.、Floyd、S。、およびM. Luby、「1対多のバルクデータ転送用の信頼性の高いマルチキャストトランスポートビルディングブロック」 、RFC 3048、DOI 10.17487 / RFC3048、2001年1月、<http://www.rfc-editor.org/info/rfc3048>。
[RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", RFC 3124, DOI 10.17487/RFC3124, June 2001, <http://www.rfc-editor.org/info/rfc3124>.
[RFC3124] Balakrishnan、H。およびS. Seshan、「The Congestion Manager」、RFC 3124、DOI 10.17487 / RFC3124、2001年6月、<http://www.rfc-editor.org/info/rfc3124>。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <http://www.rfc-editor.org/info/rfc3168>.
[RFC3168]ラマクリシュナン、K。、フロイド、S。、およびD.ブラック、「IPへの明示的輻輳通知（ECN）の追加」、RFC 3168、DOI 10.17487 / RFC3168、2001年9月、<http：// www。 rfc-editor.org/info/rfc3168>。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：セッション開始プロトコル」 、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<http://www.rfc-editor.org/info/rfc3261>。
[RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, DOI 10.17487/RFC3303, August 2002, <http://www.rfc-editor.org/info/rfc3303>.
[RFC3303] Srisuresh、P.、Kuthan、J.、Rosenberg、J.、Molitor、A。、およびA. Rayhan、「ミドルボックス通信アーキテクチャおよびフレームワーク」、RFC 3303、DOI 10.17487 / RFC3303、2002年8月、<http： //www.rfc-editor.org/info/rfc3303>。
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, DOI 10.17487/RFC3493, February 2003, <http://www.rfc-editor.org/info/rfc3493>.
[RFC3493] Gilligan、R.、Thomson、S.、Bound、J.、McCann、J.、and W. Stevens、 "Basic Socket Interface Extensions for IPv6"、RFC 3493、DOI 10.17487 / RFC3493、February 2003、<http ：//www.rfc-editor.org/info/rfc3493>。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、DOI 10.17487 / RFC3550、2003年7月、 <http://www.rfc-editor.org/info/rfc3550>。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, DOI 10.17487/RFC3551, July 2003, <http://www.rfc-editor.org/info/rfc3551>.
[RFC3551] Schulzrinne、H。およびS. Casner、「最小制御のオーディオおよびビデオ会議のRTPプロファイル」、STD 65、RFC 3551、DOI 10.17487 / RFC3551、2003年7月、<http：//www.rfc-editor。 org / info / rfc3551>。
[RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate Control (WEBRC) Building Block", RFC 3738, DOI 10.17487/RFC3738, April 2004, <http://www.rfc-editor.org/info/rfc3738>.
[RFC3738] Luby、M。およびV. Goyal、「Wave and Equation Based Rate Control（WEBRC）Building Block」、RFC 3738、DOI 10.17487 / RFC3738、2004年4月、<http://www.rfc-editor.org/ info / rfc3738>。
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, DOI 10.17487/RFC3758, May 2004, <http://www.rfc-editor.org/info/rfc3758>.
[RFC3758]スチュワート、R。、ラマーリョ、M.、Xie、Q.、Tuexen、M。、およびP.コンラッド、「ストリーム制御伝送プロトコル（SCTP）部分信頼性拡張」、RFC 3758、DOI 10.17487 / RFC3758、5月2004、<http://www.rfc-editor.org/info/rfc3758>。
[RFC3819] Karn, P., Ed., 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, DOI 10.17487/RFC3819, July 2004, <http://www.rfc-editor.org/info/rfc3819>.
[RFC3819]カーン、P。、編、ボーマン、C。、フェアハースト、G。、グロスマン、D。、ルートヴィヒ、R。、マハビ、J。、モンテネグロ、G。、タッチ、J.、L。ウッド、「インターネットサブネットワークデザイナーのためのアドバイス」、BCP 89、RFC 3819、DOI 10.17487 / RFC3819、2004年7月、<http://www.rfc-editor.org/info/rfc3819>。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[RFC4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、DOI 10.17487 / RFC4301、2005年12月、<http://www.rfc-editor.org/info/rfc4301>。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, December 2005, <http://www.rfc-editor.org/info/rfc4302>.
[RFC4302]ケント、S。、「IP認証ヘッダー」、RFC 4302、DOI 10.17487 / RFC4302、2005年12月、<http://www.rfc-editor.org/info/rfc4302>。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, <http://www.rfc-editor.org/info/rfc4303>.
[RFC4303]ケント、S。、「IPカプセル化セキュリティペイロード（ESP）」、RFC 4303、DOI 10.17487 / RFC4303、2005年12月、<http://www.rfc-editor.org/info/rfc4303>。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, DOI 10.17487/RFC4340, March 2006, <http://www.rfc-editor.org/info/rfc4340>.
[RFC4340] Kohler、E.、Handley、M。、およびS. Floyd、「Datagram Congestion Control Protocol（DCCP）」、RFC 4340、DOI 10.17487 / RFC4340、2006年3月、<http：//www.rfc-editor。 org / info / rfc4340>。
[RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control", RFC 4341, DOI 10.17487/RFC4341, March 2006, <http://www.rfc-editor.org/info/rfc4341>.
[RFC4341] Floyd、S。およびE. Kohler、「Profile for Datagram Congestion Control Protocol（DCCP）Congestion Control ID 2：TCP-like Congestion Control」、RFC 4341、DOI 10.17487 / RFC4341、2006年3月、<http：// www.rfc-editor.org/info/rfc4341>。
[RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, DOI 10.17487/RFC4342, March 2006, <http://www.rfc-editor.org/info/rfc4342>.
[RFC4342] Floyd、S.、Kohler、E。、およびJ. Padhye、「Datagram Congestion Control Protocol（DCCP）Congestion Control ID 3：TCP-Friendly Rate Control（TFRC）のプロファイル」、RFC 4342、DOI 10.17487 / RFC4342 、2006年3月、<http://www.rfc-editor.org/info/rfc4342>。
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, DOI 10.17487/RFC4380, February 2006, <http://www.rfc-editor.org/info/rfc4380>.
[RFC4380] Huitema、C。、「Teredo：Tunneling IPv6 over UDP through Network Address Translations（NATs）」、RFC 4380、DOI 10.17487 / RFC4380、2006年2月、<http://www.rfc-editor.org/info/ rfc4380>。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, <http://www.rfc-editor.org/info/rfc4607>.
[RFC4607] Holbrook、H.およびB. Cain、「Source-Specific Multicast for IP」、RFC 4607、DOI 10.17487 / RFC4607、2006年8月、<http://www.rfc-editor.org/info/rfc4607>。
[RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast Congestion Control (TFMCC): Protocol Specification", RFC 4654, DOI 10.17487/RFC4654, August 2006, <http://www.rfc-editor.org/info/rfc4654>.
[RFC4654] Widmer、J。およびM. Handley、「TCP-Friendly Multicast Congestion Control（TFMCC）：Protocol Specification」、RFC 4654、DOI 10.17487 / RFC4654、2006年8月、<http://www.rfc-editor.org / info / rfc4654>。
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, DOI 10.17487/RFC4880, November 2007, <http://www.rfc-editor.org/info/rfc4880>.
[RFC4880] Callas、J.、Donnerhacke、L.、Finney、H.、Shaw、D。、およびR. Thayer、「OpenPGP Message Format」、RFC 4880、DOI 10.17487 / RFC4880、2007年11月、<http：// www.rfc-editor.org/info/rfc4880>。
[RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering ICMPv6 Messages in Firewalls", RFC 4890, DOI 10.17487/RFC4890, May 2007, <http://www.rfc-editor.org/info/rfc4890>.
[RFC4890] Davies、E.、J。Mohacsi、「ファイアウォールでのICMPv6メッセージのフィルタリングに関する推奨事項」、RFC 4890、DOI 10.17487 / RFC4890、2007年5月、<http://www.rfc-editor.org/info/rfc4890> 。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, <http://www.rfc-editor.org/info/rfc4960>.
[RFC4960] Stewart、R.、Ed。、「Stream Control Transmission Protocol」、RFC 4960、DOI 10.17487 / RFC4960、2007年9月、<http://www.rfc-editor.org/info/rfc4960>。
[RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly Errors at High Data Rates", RFC 4963, DOI 10.17487/RFC4963, July 2007, <http://www.rfc-editor.org/info/rfc4963>.
[RFC4963] Heffner、J.、Mathis、M。、およびB. Chandler、「高データレートでのIPv4再構成エラー」、RFC 4963、DOI 10.17487 / RFC4963、2007年7月、<http：//www.rfc-editor。 org / info / rfc4963>。
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, <http://www.rfc-editor.org/info/rfc4987>.
[RFC4987] Eddy、W。、「TCP SYN Flooding Attacks and Common Mitigations」、RFC 4987、DOI 10.17487 / RFC4987、2007年8月、<http://www.rfc-editor.org/info/rfc4987>。
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, <http://www.rfc-editor.org/info/rfc5082>.
[RFC5082] Gill、V.、Heasley、J.、Meyer、D.、Savola、P.、Ed。、およびC. Pignataro、「一般化されたTTLセキュリティメカニズム（GTSM）」、RFC 5082、DOI 10.17487 / RFC5082、 2007年10月、<http://www.rfc-editor.org/info/rfc5082>。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, DOI 10.17487/RFC5245, April 2010, <http://www.rfc-editor.org/info/rfc5245>.
[RFC5245] Rosenberg、J。、「Interactive Connectivity Establishment（ICE）：A Protocol for Network Address Translator（NAT）Traversal for Offer / Answer Protocols」、RFC 5245、DOI 10.17487 / RFC5245、2010年4月、<http：// www .rfc-editor.org / info / rfc5245>。
[RFC5622] Floyd, S. and E. Kohler, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP)", RFC 5622, DOI 10.17487/RFC5622, August 2009, <http://www.rfc-editor.org/info/rfc5622>.
[RFC5622]フロイド、S。およびE.コーラー、「Profile for Datagram Congestion Control Protocol（DCCP）Congestion ID 4：TCP-Friendly Rate Control for Small Packets（TFRC-SP）」、RFC 5622、DOI 10.17487 / RFC5622、8月2009、<http://www.rfc-editor.org/info/rfc5622>。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <http://www.rfc-editor.org/info/rfc5652>.
[RFC5652] Housley、R。、「Cryptographic Message Syntax（CMS）」、STD 70、RFC 5652、DOI 10.17487 / RFC5652、2009年9月、<http://www.rfc-editor.org/info/rfc5652>。
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, <http://www.rfc-editor.org/info/rfc5681>.
[RFC5681] Allman、M.、Paxson、V。、およびE. Blanton、「TCP Congestion Control」、RFC 5681、DOI 10.17487 / RFC5681、2009年9月、<http://www.rfc-editor.org/info/ rfc5681>。
[RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, "NACK-Oriented Reliable Multicast (NORM) Transport Protocol", RFC 5740, DOI 10.17487/RFC5740, November 2009, <http://www.rfc-editor.org/info/rfc5740>.
[RFC5740] Adamson、B.、Bormann、C.、Handley、M。、およびJ. Macker、「NACK-Oriented Reliable Multicast（NORM）Transport Protocol」、RFC 5740、DOI 10.17487 / RFC5740、2009年11月、<http： //www.rfc-editor.org/info/rfc5740>。
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, DOI 10.17487/RFC5751, January 2010, <http://www.rfc-editor.org/info/rfc5751>.
[RFC5751] Ramsdell、B。およびS. Turner、「Secure / Multipurpose Internet Mail Extensions（S / MIME）Version 3.2 Message Specification」、RFC 5751、DOI 10.17487 / RFC5751、2010年1月、<http：//www.rfc- editor.org/info/rfc5751>。
[RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 5775, DOI 10.17487/RFC5775, April 2010, <http://www.rfc-editor.org/info/rfc5775>.
[RFC5775] Luby、M.、Watson、M。、およびL. Vicisano、「Asynchronous Layered Coding（ALC）Protocol Instantiation」、RFC 5775、DOI 10.17487 / RFC5775、2010年4月、<http：//www.rfc-editor .org / info / rfc5775>。
[RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signalling Transport", RFC 5971, DOI 10.17487/RFC5971, October 2010, <http://www.rfc-editor.org/info/rfc5971>.
[RFC5971] Schulzrinne、H。およびR. Hancock、「GIST：General Internet Signaling Transport」、RFC 5971、DOI 10.17487 / RFC5971、2010年10月、<http://www.rfc-editor.org/info/rfc5971>。
[RFC5973] Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", RFC 5973, DOI 10.17487/RFC5973, October 2010, <http://www.rfc-editor.org/info/rfc5973>.
[RFC5973] Stiemerling、M.、Tschofenig、H.、Aoun、C。、およびE. Davies、「NAT / Firewall NSIS Signaling Layer Protocol（NSLP）」、RFC 5973、DOI 10.17487 / RFC5973、2010年10月、<http： //www.rfc-editor.org/info/rfc5973>。
[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>。
[RFC6092] Woodyatt, J., Ed., "Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service", RFC 6092, DOI 10.17487/RFC6092, January 2011, <http://www.rfc-editor.org/info/rfc6092>.
[RFC6092] Woodyatt、J.、Ed。、 "Recommended Simple Security Capability in Customer Premises Equipment（CPE）for Providing Residential IPv6 Internet Service"、RFC 6092、DOI 10.17487 / RFC6092、January 2011、<http：//www.rfc -editor.org/info/rfc6092>。
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <http://www.rfc-editor.org/info/rfc6335>.
[RFC6335]綿、M。、エガート、L。、タッチ、J。、ウェスターランド、M。、およびS.チェシャー、「サービス名とトランスポートプロトコルのポート番号レジストリの管理のためのInternet Assigned Numbers Authority（IANA）手順"、BCP 165、RFC 6335、DOI 10.17487 / RFC6335、2011年8月、<http://www.rfc-editor.org/info/rfc6335>。
[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>。
[RFC6396] Blunk, L., Karir, M., and C. Labovitz, "Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format", RFC 6396, DOI 10.17487/RFC6396, October 2011, <http://www.rfc-editor.org/info/rfc6396>.
[RFC6396] Blunk、L.、Kairr、M。、およびC. Labovitz、「Multi-Threaded Routing Toolkit（MRT）Routing Information Export Format」、RFC 6396、DOI 10.17487 / RFC6396、2011年10月、<http：// www .rfc-editor.org / info / rfc6396>。
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/RFC6437, November 2011, <http://www.rfc-editor.org/info/rfc6437>.
[RFC6437] Amante、S.、Carpenter、B.、Jiang、S。、およびJ. Rajahalme、「IPv6 Flow Label Specification」、RFC 6437、DOI 10.17487 / RFC6437、2011年11月、<http：//www.rfc- editor.org/info/rfc6437>。
[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>。
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 2012, <http://www.rfc-editor.org/info/rfc6513>.
[RFC6513]ローゼン、E、エド。およびR. Aggarwal編、「MPLS / BGP IP VPNでのマルチキャスト」、RFC 6513、DOI 10.17487 / RFC6513、2012年2月、<http://www.rfc-editor.org/info/rfc6513>。
[RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., and K. Carlberg, "Explicit Congestion Notification (ECN) for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 2012, <http://www.rfc-editor.org/info/rfc6679>.
[RFC6679] Westerlund、M.、Johansson、I.、Perkins、C.、O'Hanlon、P。、およびK. Carlberg、「RTP over UDPの明示的輻輳通知（ECN）」、RFC 6679、DOI 10.17487 / RFC6679 、2012年8月、<http://www.rfc-editor.org/info/rfc6679>。
[RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, "FLUTE - File Delivery over Unidirectional Transport", RFC 6726, DOI 10.17487/RFC6726, November 2012, <http://www.rfc-editor.org/info/rfc6726>.
[RFC6726] Paila、T.、Walsh、R.、Luby、M.、Roca、V。、およびR. Lehtonen、「FLUTE-単一方向トランスポートを介したファイル配信」、RFC 6726、DOI 10.17487 / RFC6726、2012年11月、< http://www.rfc-editor.org/info/rfc6726>。
[RFC6773] Phelan, T., Fairhurst, G., and C. Perkins, "DCCP-UDP: A Datagram Congestion Control Protocol UDP Encapsulation for NAT Traversal", RFC 6773, DOI 10.17487/RFC6773, November 2012, <http://www.rfc-editor.org/info/rfc6773>.
[RFC6773] Phelan、T.、Fairhurst、G。、およびC. Perkins、「DCCP-UDP：A Datagram Congestion Control Protocol UDP Encapsulation for NAT Traversal」、RFC 6773、DOI 10.17487 / RFC6773、2012年11月、<http：/ /www.rfc-editor.org/info/rfc6773>。
[RFC6807] Farinacci, D., Shepherd, G., Venaas, S., and Y. Cai, "Population Count Extensions to Protocol Independent Multicast (PIM)", RFC 6807, DOI 10.17487/RFC6807, December 2012, <http://www.rfc-editor.org/info/rfc6807>.
[RFC6807] Farinacci、D.、Shepherd、G.、Venaas、S。、およびY. Cai、「Population Count Extensions to Protocol Independent Multicast（PIM）」、RFC 6807、DOI 10.17487 / RFC6807、2012年12月、<http： //www.rfc-editor.org/info/rfc6807>。
[RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, DOI 10.17487/RFC6887, April 2013, <http://www.rfc-editor.org/info/rfc6887>.
[RFC6887] Wing、D.、Ed。、Cheshire、S.、Boucadair、M.、Penno、R。、およびP. Selkirk、「Port Control Protocol（PCP）」、RFC 6887、DOI 10.17487 / RFC6887、2013年4月、<http://www.rfc-editor.org/info/rfc6887>。
[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>。
[RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication", RFC 6951, DOI 10.17487/RFC6951, May 2013, <http://www.rfc-editor.org/info/rfc6951>.
[RFC6951] Tuexen、M。、およびR. Stewart、「エンドホストからエンドホストへの通信用のストリーム制御伝送プロトコル（SCTP）パケットのUDPカプセル化」、RFC 6951、DOI 10.17487 / RFC6951、2013年5月、<http：/ /www.rfc-editor.org/info/rfc6951>。
[RFC7143] Chadalapaka, M., Satran, J., Meth, K., and D. Black, "Internet Small Computer System Interface (iSCSI) Protocol (Consolidated)", RFC 7143, DOI 10.17487/RFC7143, April 2014, <http://www.rfc-editor.org/info/rfc7143>.
[RFC7143] Chadalapaka、M.、Satran、J.、Meth、K。、およびD. Black、「インターネットスモールコンピュータシステムインターフェイス（iSCSI）プロトコル（統合）」、RFC 7143、DOI 10.17487 / RFC7143、2014年4月、< http://www.rfc-editor.org/info/rfc7143>。
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, <http://www.rfc-editor.org/info/rfc7201>.
[RFC7201] Westerlund、M。およびC. Perkins、「RTPセッションを保護するためのオプション」、RFC 7201、DOI 10.17487 / RFC7201、2014年4月、<http://www.rfc-editor.org/info/rfc7201>。
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, <http://www.rfc-editor.org/info/rfc7296>.
[RFC7296] Kaufman、C.、Hoffman、P.、Nir、Y.、Eronen、P。、およびT. Kivinen、「Internet Key Exchange Protocol Version 2（IKEv2）」、STD 79、RFC 7296、DOI 10.17487 / RFC7296 、2014年10月、<http://www.rfc-editor.org/info/rfc7296>。
[RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450, DOI 10.17487/RFC7450, February 2015, <http://www.rfc-editor.org/info/rfc7450>.
[RFC7450] Bumgardner、G。、「Automatic Multicast Tunneling」、RFC 7450、DOI 10.17487 / RFC7450、2015年2月、<http://www.rfc-editor.org/info/rfc7450>。
[RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, "Encapsulating MPLS in UDP", RFC 7510, DOI 10.17487/RFC7510, April 2015, <http://www.rfc-editor.org/info/rfc7510>.
[RFC7510] Xu、X.、Sheth、N.、Yong、L.、Callon、R。、およびD. Black、「UDPでのMPLSのカプセル化」、RFC 7510、DOI 10.17487 / RFC7510、2015年4月、<http：/ /www.rfc-editor.org/info/rfc7510>。
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>.
[RFC7525] Sheffer、Y.、Holz、R。、およびP. Saint-Andre、「Transport Layer Security（TLS）およびDatagram Transport Layer Security（DTLS）の安全な使用に関する推奨事項」、BCP 195、RFC 7525、DOI 10.17487 / RFC7525、2015年5月、<http://www.rfc-editor.org/info/rfc7525>。
[RFC7560] Kuehlewind, M., Ed., Scheffenegger, R., and B. Briscoe, "Problem Statement and Requirements for Increased Accuracy in Explicit Congestion Notification (ECN) Feedback", RFC 7560, DOI 10.17487/RFC7560, August 2015, <http://www.rfc-editor.org/info/rfc7560>.
[RFC7560] Kuehlewind、M。、編、Scheffenegger、R。、およびB. Briscoe、「Problem Statement and Requirements for Accuracy in Explicit Congestion Notification（ECN）Feedback」、RFC 7560、DOI 10.17487 / RFC7560、2015年8月、 <http://www.rfc-editor.org/info/rfc7560>。
[RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF Recommendations Regarding Active Queue Management", BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, <http://www.rfc-editor.org/info/rfc7567>.
[RFC7567]ベイカー、F。、エド。およびG.フェアハースト編、「アクティブキュー管理に関するIETFの推奨事項」、BCP 197、RFC 7567、DOI 10.17487 / RFC7567、2015年7月、<http://www.rfc-editor.org/info/rfc7567>。
[RFC7605] Touch, J., "Recommendations on Using Assigned Transport Port Numbers", BCP 165, RFC 7605, DOI 10.17487/RFC7605, August 2015, <http://www.rfc-editor.org/info/rfc7605>.
[RFC7605] Touch、J。、「割り当てられたトランスポートポート番号の使用に関する推奨事項」、BCP 165、RFC 7605、DOI 10.17487 / RFC7605、2015年8月、<http://www.rfc-editor.org/info/rfc7605>。
[RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services (Diffserv) and Real-Time Communication", RFC 7657, DOI 10.17487/RFC7657, November 2015, <http://www.rfc-editor.org/info/rfc7657>.
[RFC7657]ブラック、D。、エド。およびP.ジョーンズ、「Differentiated Services（Diffserv）and Real-Time Communication」、RFC 7657、DOI 10.17487 / RFC7657、2015年11月、<http://www.rfc-editor.org/info/rfc7657>。
[RFC7675] Perumal, M., Wing, D., Ravindranath, R., Reddy, T., and M. Thomson, "Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness", RFC 7675, DOI 10.17487/RFC7675, October 2015, <http://www.rfc-editor.org/info/rfc7675>.
[RFC7675] Perumal、M.、Wing、D.、Ravindranath、R.、Reddy、T。、およびM. Thomson、「同意の鮮度のためのNAT（STUN）使用のためのセッショントラバーサルユーティリティ」、RFC 7675、DOI 10.17487 / RFC7675 、2015年10月、<http://www.rfc-editor.org/info/rfc7675>。
[RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions", RFC 8083, DOI 10.17487/RFC8083, March 2017, <http://www.rfc-editor.org/info/rfc8083>.
[RFC8083] Perkins、C。およびV. Singh、「Multimedia Congestion Control：Circuit Breaks for Unicast RTP Sessions」、RFC 8083、DOI 10.17487 / RFC8083、2017年3月、<http://www.rfc-editor.org/info / rfc8083>。
[RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE-in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, March 2017, <http://www.rfc-editor.org/info/rfc8086>.
[RFC8086] Yong、L.、Ed。、Crabbe、E.、Xu、X。、およびT. Herbert、「GRE-in-UDP Encapsulation」、RFC 8086、DOI 10.17487 / RFC8086、2017年3月、<http：/ /www.rfc-editor.org/info/rfc8086>。
[RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using Explicit Congestion Notification (ECN)", RFC 8087, DOI 10.17487/RFC8087, March 2017, <http://www.rfc-editor.org/info/rfc8087>.
[RFC8087] Fairhurst、G。およびM. Welzl、「明示的な輻輳通知（ECN）を使用する利点」、RFC 8087、DOI 10.17487 / RFC8087、2017年3月、<http://www.rfc-editor.org/info / rfc8087>。
[STEVENS] Stevens, W., Fenner, B., and A. Rudoff, "UNIX Network Programming, The sockets Networking API", Addison-Wesley, 2004.
[STEVENS] Stevens、W.、Fenner、B。、およびA. Rudoff、「UNIXネットワークプログラミング、ソケットネットワークAPI」、Addison-Wesley、2004年。
[UPnP] UPnP Forum, , "Internet Gateway Device (IGD) Standardized Device Control Protocol V 1.0", November 2001.
[UPnP] UPnPフォーラム、「インターネットゲートウェイデバイス（IGD）標準化デバイスコントロールプロトコルV 1.0」、2001年11月。
This appendix provides a brief review of MPLS-in-UDP as an example of a UDP Tunnel Encapsulation that defines a UDP encapsulation. The purpose of the appendix is to provide a concrete example of which mechanisms were required in order to safely use UDP zero-checksum mode for MPLS-in-UDP tunnels over IPv6. By default, UDP requires a checksum for use with IPv6. An option has been specified that permits a zero IPv6 UDP checksum when used in specific environments, specified in [RFC7510], and defines a set of operational constraints for use of this mode. These are summarized below:
この付録では、UDPカプセル化を定義するUDPトンネルカプセル化の例として、MPLS-in-UDPについて簡単に説明します。付録の目的は、IPv6上のMPLS-in-UDPトンネルにUDPゼロチェックサムモードを安全に使用するために必要なメカニズムの具体例を提供することです。デフォルトでは、UDPはIPv6で使用するためにチェックサムを必要とします。 [RFC7510]で指定されている特定の環境で使用するときにゼロのIPv6 UDPチェックサムを許可するオプションが指定されており、このモードを使用するための一連の操作上の制約を定義します。これらを以下にまとめます。
A UDP tunnel or encapsulation using a zero-checksum mode with IPv6 must only be deployed within a single network (with a single network operator) or networks of an adjacent set of cooperating network operators where traffic is managed to avoid congestion, rather than over the Internet where congestion control is required. MPLS-in-UDP has been specified for networks under single administrative control (such as within a single operator's network) where 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.
IPv6でゼロチェックサムモードを使用するUDPトンネルまたはカプセル化は、単一のネットワーク内（単一のネットワークオペレーターを使用）または、トラフィックが管理されている隣接する一連の協力するネットワークオペレーターのネットワーク内にのみ配置する必要があります。輻輳制御が必要なインターネット。 MPLS-in-UDPは、単一の管理制御下（単一のオペレーターのネットワーク内など）のネットワークに対して指定されており、パケットの破損が例外的に発生する可能性が低く、オペレーターがどこにいるのか（おそらく、機器タイプと下位層のチェックによって）検出されないパケット破損のリスクを負うことをいとわない。
The tunnel encapsulator SHOULD use different IPv6 addresses for each UDP tunnel that uses the UDP zero-checksum mode, regardless of the decapsulator, 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). Use of MPLS-in-UDP may be extended to networks within a set of closely cooperating network administrations (such as network operators who have agreed to work together to jointly provide specific services) [RFC7510].
トンネルカプセル化装置は、カプセル化解除装置に関係なく、UDPゼロチェックサムモードを使用するUDPトンネルごとに異なるIPv6アドレスを使用して（SHOULD）、カプセル化解除装置によるIPv6送信元アドレスのチェックを強化する必要があります（つまり、同じIPv6送信元アドレスは、 1つのIPv6宛先アドレスよりも、その宛先アドレスがユニキャストアドレスであるかマルチキャストアドレスであるかに関係なく）。 MPLS-in-UDPの使用は、密接に協力している一連のネットワーク管理（共同で特定のサービスを共同で提供することに同意したネットワークオペレーターなど）内のネットワークに拡張できます[RFC7510]。
The requirement for MPLS-in-UDP endpoints to check the source IPv6 address in addition to the destination IPv6 address, plus the strong recommendation against reuse of source IPv6 addresses among MPLS-in-UDP tunnels collectively provide some mitigation for the absence of UDP checksum coverage of the IPv6 header. In addition, the MPLS data plane only forwards packets with valid labels (i.e., labels that have been distributed by the tunnel egress Label Switched Router, LSR), providing some additional opportunity to detect MPLS-in-UDP packet misdelivery when the misdelivered packet contains a label that is not valid for forwarding at the receiving LSR. The expected result for IPv6 UDP zero-checksum mode for MPLS-in-UDP is that corruption of the destination IPv6 address will usually cause packet discard, as offsetting corruptions to the source IPv6 and/or MPLS top label are unlikely.
MPLS-in-UDPエンドポイントが宛先IPv6アドレスに加えてソースIPv6アドレスをチェックするための要件に加えて、MPLS-in-UDPトンネル間でソースIPv6アドレスを再利用しないことを強く推奨することで、UDPチェックサムの不在を緩和しますIPv6ヘッダーのカバレッジ。さらに、MPLSデータプレーンは、有効なラベル（つまり、トンネル出力ラベルスイッチドルータ、LSRによって配布されたラベル）を持つパケットのみを転送し、誤って配信されたパケットに含まれる場合に、MPLS-in-UDPパケットの誤配信を検出する追加の機会を提供します。受信LSRでの転送に無効なラベル。 MPLS-in-UDPのIPv6 UDPゼロチェックサムモードで予期される結果は、ソースIPv6やMPLSトップラベルへの破損のオフセットが起こりそうにないため、宛先IPv6アドレスの破損は通常パケット破棄を引き起こすことです。
Additional assurance is provided by the restrictions in the above exceptions that limit usage of IPv6 UDP zero-checksum mode to well-managed networks for which MPLS packet corruption has not been a problem in practice. Hence, MPLS-in-UDP is suitable for transmission over lower layers in well-managed networks 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 MPLS traffic that is not encapsulated in UDP. For these reasons, MPLS-in-UDP does not provide an additional integrity check 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].
IPv6 UDPゼロチェックサムモードの使用を、MPLSパケットの破損が実際に問題になっていない適切に管理されたネットワークに制限する上記の例外の制限によって、追加の保証が提供されます。したがって、MPLS-in-UDPは、上記の例外で許可されている適切に管理されたネットワークの下位層での送信に適しています。このようなネットワーク上の内部IPパケットの破損率は、MPLSトラフィックと比較して増加するとは予想されません。これはUDPにカプセル化されていません。これらの理由により、IPv6でUDPゼロチェックサムモードが使用されている場合、MPLS-in-UDPは追加の整合性チェックを提供せず、この設計は[RFC6936]のセクション5で指定された要件2、3、および5に準拠しています。
The MPLS-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 MPLS-in-UDP tunnel will be black-holed by that middlebox. Recommended changes to allow firewalls, NATs and other middleboxes to support use of an IPv6 zero UDP checksum are described in Section 5 of [RFC6936]. MPLS does not accumulate incorrect state as a consequence of label-stack corruption. A corrupt MPLS label results in either packet discard or forwarding (and forgetting) of the packet without accumulation of MPLS protocol state. Active monitoring of MPLS-in-UDP traffic for errors is REQUIRED because the occurrence of errors will result in some accumulation of error information outside the MPLS protocol for operational and management purposes. This design is in accordance with requirement 4 specified in Section 5 of [RFC6936]. In addition, IPv6 traffic with a zero UDP checksum MUST be actively monitored for errors by the network operator.
UDPのチェックサムがゼロのIPv6データグラムを破棄するミドルボックスを含むパスを介してトンネルをリダイレクトするパス変更が発生した場合、MPLS-in-UDPカプセル化は、チェックサムの使用に安全にフォールバックするメカニズムを提供しません。この場合、MPLS-in-UDPトンネルはそのミドルボックスによってブラックホール化されます。ファイアウォール、NAT、その他のミドルボックスがIPv6ゼロUDPチェックサムの使用をサポートできるようにするための推奨される変更については、[RFC6936]のセクション5で説明されています。 MPLSは、ラベルスタックの破損の結果として誤った状態を蓄積しません。 MPLSラベルが破損していると、MPLSプロトコル状態が蓄積されずに、パケットが破棄されるか、パケットが転送（および忘却）されます。 MPLS-in-UDPトラフィックのエラーをアクティブに監視する必要があります。これは、エラーが発生すると、運用と管理の目的でMPLSプロトコルの外部にエラー情報が蓄積されるためです。この設計は、[RFC6936]のセクション5で指定されている要件4に準拠しています。さらに、UDPチェックサムがゼロのIPv6トラフィックは、ネットワークオペレーターによるエラーを積極的に監視する必要があります。
Operators SHOULD also deploy packet filters to prevent IPv6 packets with a zero UDP checksum from escaping from the network due to misconfiguration or packet errors. In addition, IPv6 traffic with a zero UDP checksum MUST be actively monitored for errors by the network operator.
オペレーターは、パケットフィルターを展開して、UDPチェックサムがゼロのIPv6パケットが、設定ミスやパケットエラーが原因でネットワークからエスケープしないようにする必要もあります。さらに、UDPチェックサムがゼロのIPv6トラフィックは、ネットワークオペレーターによるエラーを積極的に監視する必要があります。
Acknowledgments
謝辞
The middlebox traversal guidelines in Section 3.5 incorporate ideas from Section 5 of [BEHAVE-APP] by Bryan Ford, Pyda Srisuresh, and Dan Kegel. The protocol timer guidelines in Section 3.1.1 were largely contributed by Mark Allman.
セクション3.5のミドルボックストラバーサルガイドラインには、ブライアンフォード、ピダスリスレッシュ、ダンケーゲルによる[BEHAVE-APP]のセクション5のアイデアが組み込まれています。セクション3.1.1のプロトコルタイマーのガイドラインは、Mark Allmanによって大きく提供されました。
G. Fairhurst received funding from the European Union's Horizon 2020 research and innovation program 2014-2018 under grant agreement No. 644334 (NEAT). Lars Eggert has received funding from the European Union's Horizon 2020 research and innovation program 2014-2018 under grant agreement No. 644866 (SSICLOPS). This document reflects only the authors' views and the European Commission is not responsible for any use that may be made of the information it contains.
G.フェアハーストは、EUのHorizon 2020研究およびイノベーションプログラム2014-2018から、助成金契約番号644334（NEAT）の下で資金を受け取りました。 Lars Eggertは、EUのHorizon 2020研究およびイノベーションプログラム2014-2018から、助成金契約番号644866（SSICLOPS）に基づいて資金を受け取りました。この文書は著者の見解のみを反映しており、欧州委員会はそれが含む情報のいかなる利用についても責任を負いません。
Authors' Addresses
著者のアドレス
Lars Eggert NetApp Sonnenallee 1 Kirchheim 85551 Germany
Lars Eggert NetApp Sonnenallee 1キルヒハイム85551ドイツ
Phone: +49 151 120 55791
Email: lars@netapp.com
URI: https://eggert.org/
Godred Fairhurst University of Aberdeen Department of Engineering Fraser Noble Building Aberdeen AB24 3UE Scotland
Godred Fairhurst University of Aberdeen Engineering Department of Fraser Noble Building Aberdeen AB24 3UE Scotland
Email: gorry@erg.abdn.ac.uk
URI: http://www.erg.abdn.ac.uk/
Greg Shepherd Cisco Systems Tasman Drive San Jose United States of America
グレッグシェパードシスコシステムズタスマンドライブサンノゼアメリカ合衆国
Email: gjshep@gmail.com