RFC5405 日本語訳
5405 Unicast UDP Usage Guidelines for Application Designers. L.Eggert, G. Fairhurst. November 2008. (Format: TXT=69607 bytes) (Also BCP0145) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
英語原文
Network Working Group L. Eggert
Request for Comments: 5405 Nokia
BCP: 145 G. Fairhurst
Category: Best Current Practice University of Aberdeen
November 2008
コメントを求めるワーキンググループL.エッゲルトの要求をネットワークでつないでください: 5405ノキアBCP: 145G.Fairhurstカテゴリ: アバディーン2008年11月の最も良い現在の習慣大学
Unicast UDP Usage Guidelines for Application Designers
アプリケーション設計者へのユニキャストUDP用法ガイドライン
Status of This Memo
このメモの状態
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (c) 2008 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright(c)2008IETF Trustと人々はドキュメントとして作者を特定しました。 All rights reserved。
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.
事実上、このドキュメントはこのドキュメントの公表の日付にIETF Documents( http://trustee.ietf.org/ ライセンスインフォメーション)へのBCP78とIETF TrustのLegal Provisions Relatingを受けることがあります。 このドキュメントに関して権利と制限について説明するとき、慎重にこれらのドキュメントを再検討してください。
Abstract
要約
The User Datagram Protocol (UDP) provides a minimal message-passing transport that has no inherent congestion control mechanisms. Because congestion control is critical to the stable operation of the Internet, applications and upper-layer 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. This document provides guidelines on the use of UDP for the designers of unicast applications and upper-layer protocols. Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, and middlebox traversal.
ユーザー・データグラム・プロトコル(UDP)はどんな固有の混雑制御機構も持っていない最小量のメッセージ・パッシング輸送を提供します。輻輳制御がインターネットの安定稼働に重要であるので、アプリケーションとインターネット輸送としてUDPを使用するのを選ぶ上側の層のプロトコルは混雑崩壊を防いで、同時発生のトラフィックでいくらかの公正を証明するのにメカニズムを使わなければなりません。 このドキュメントはUDPのユニキャストアプリケーションと上側の層のプロトコルのデザイナーの使用に関するガイドラインを提供します。 混雑管理指針は焦点ですが、また、ドキュメントは他の話題に関して指導を提供します、メッセージサイズ、信頼性、チェックサム、およびmiddlebox縦断を含んでいて。
Eggert & Fairhurst Best Current Practice [Page 1] RFC 5405 Unicast UDP Usage Guidelines November 2008
エッゲルトとFairhurstの最も良い海流はユニキャストUDP用法ガイドライン2008年11月にRFC5405を練習します[1ページ]。
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 . . . . . . . . . . . . . . . . . 11
3.3. Reliability Guidelines . . . . . . . . . . . . . . . . . . 12
3.4. Checksum Guidelines . . . . . . . . . . . . . . . . . . . 13
3.5. Middlebox Traversal Guidelines . . . . . . . . . . . . . . 15
3.6. Programming Guidelines . . . . . . . . . . . . . . . . . . 17
3.7. ICMP Guidelines . . . . . . . . . . . . . . . . . . . . . 18
4. Security Considerations . . . . . . . . . . . . . . . . . . . 19
5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.1. Normative References . . . . . . . . . . . . . . . . . . . 22
7.2. Informative References . . . . . . . . . . . . . . . . . . 23
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . . 5 3。 UDP用法ガイドライン. . . . . . . . . . . . . . . . . . . . . 5 3.1。 輻輳制御ガイドライン. . . . . . . . . . . . . . 6 3.2。 メッセージサイズガイドライン. . . . . . . . . . . . . . . . . 11 3.3。 信頼性のガイドライン. . . . . . . . . . . . . . . . . . 12 3.4。 チェックサムガイドライン. . . . . . . . . . . . . . . . . . . 13 3.5。 Middlebox縦断ガイドライン. . . . . . . . . . . . . . 15 3.6。 ガイドライン. . . . . . . . . . . . . . . . . . 17 3.7をプログラムします。 ICMPガイドライン. . . . . . . . . . . . . . . . . . . . . 18 4。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 19 5。 概要. . . . . . . . . . . . . . . . . . . . . . . . . . . 20 6。 承認. . . . . . . . . . . . . . . . . . . . . . . 22 7。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 22 7.1。 引用規格. . . . . . . . . . . . . . . . . . . 22 7.2。 有益な参照. . . . . . . . . . . . . . . . . . 23
Eggert & Fairhurst Best Current Practice [Page 2] RFC 5405 Unicast UDP Usage Guidelines November 2008
エッゲルトとFairhurstの最も良い海流はユニキャストUDP用法ガイドライン2008年11月にRFC5405を練習します[2ページ]。
1. Introduction
1. 序論
The User Datagram Protocol (UDP) [RFC0768] provides a minimal, unreliable, best-effort, message-passing transport to applications and upper-layer protocols (both simply called "applications" in the remainder of this document). 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)[RFC0768]はアプリケーションと上側の層のプロトコル(単にこのドキュメントの残りにおける「アプリケーション」と呼ばれる両方)に最小量の、そして、頼り無くて、ベストエフォート型のメッセージ・パッシング輸送を提供します。 他のトランスポート・プロトコルと比べて、終わりから終わりとのエンドシステムを伝えることの間の接続を確立しないので、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 link interface, which is often much greater than the available 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". 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ベースのストリーミング・アプリケーションが有効な輻輳回避メカニズムを組み込むべきです。」と述べます。 これはストリーミングにUDPを使用しないアプリケーションさえのための重要な要件です。 さらに、混雑で制御されたトランスミッションはアプリケーション自体に有益です、自己に誘発されたパケット損失を抑えて、「再-トランスミッション」を最小にして、したがって、遅れを縮めることができるので。 輻輳制御は比較的遅い通信速度でさえ不可欠です。 例えば、1秒後に5 1500バイトがUDPデータグラムであると生成するアプリケーションは既に56KB/sの経路の容量を超えることができます。 より高くて、潜在的に限りないデータ信号速度で作動できるアプリケーションのために、輻輳制御は混雑崩壊を防いで、いくらかの公正を証明するために重大になります。 セクション3はそのようなアプリケーションのデザイナーのために多くの簡単なガイドラインについて説明します。
Eggert & Fairhurst Best Current Practice [Page 3] RFC 5405 Unicast UDP Usage Guidelines November 2008
エッゲルトとFairhurstの最も良い海流はユニキャストUDP用法ガイドライン2008年11月にRFC5405を練習します[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, and middlebox traversal.
UDPデータグラムは、単一のIPパケットで運ばれて、したがって、IPv4のための6万5507バイトとIPv6のための6万5527バイトの最大積載量に制限されます。 通常、大きいIPパケットのトランスミッションはIP断片化を必要とします。 断片化は、コミュニケーションの信頼性と効率を減少させて、避けられるべきです。 IPv6は経路に沿ったすべてのリンクレイヤがこの[RFC2675]をサポートすると断片化なしで大きいパケット("jumbograms")を伝えるオプションを許容します。 セクション3のガイドラインのいくつかがアプリケーションがどう適切なメッセージサイズを決定するべきであるかを説明します。 このドキュメントの他のセクションは信頼性、チェックサム、およびmiddlebox縦断のときに指導を提供します。
This document provides guidelines and recommendations. Although most unicast 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 the application designers document the rationale for their design choice in the technical specification of their application or protocol.
このドキュメントはガイドラインと推薦を提供します。 ほとんどのユニキャストUDPアプリケーションがこれらのガイドラインに従うと予想されますが、特定のアプリケーションが与えられたガイドラインに従わないと決めるかもしれない正当な理由は存在しています。 そのような場合、アプリケーション設計者が彼らのアプリケーションかプロトコルに関する技術仕様書に基づく彼らのデザイン選択のために原理を記録するのは、RECOMMENDEDです。
This document provides guidelines to designers of applications that use UDP for unicast transmission, which is the most common case. Specialized classes of applications use UDP for IP multicast [RFC1112], broadcast [RFC0919], or anycast [RFC1546] transmissions. The design of such specialized applications requires expertise that goes beyond the simple, unicast-specific guidelines given in this document. Multicast and broadcast senders may transmit to multiple receivers across potentially very heterogeneous paths at the same time, which significantly complicates congestion control, flow control, and reliability mechanisms. 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]. Anycast senders 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. It is not intended that the guidelines in this document apply to multicast, broadcast, or anycast applications that use UDP.
このドキュメントは最も一般的なケースであるユニキャスト送信にUDPを使用するアプリケーションのデザイナーにガイドラインを提供します。 専門化しているクラスのアプリケーションはIPマルチキャスト[RFC1112]、放送[RFC0919]、またはanycast[RFC1546]トランスミッションにUDPを使用します。 そのような専門化しているアプリケーションの設計は本書では与えられた簡単なユニキャスト特別な基準を越える専門的技術を必要とします。 マルチキャストと放送送付者は輻輳制御、フロー制御、および信頼性のメカニズムをかなり複雑にするのと同時に潜在的に非常に異種の経路の向こう側に複数の受信機に伝わるかもしれません。IETFはマルチキャストアプリケーションのデザイナーを支援するために信頼できるマルチキャストフレームワーク[RFC3048]といくつかのブロックを定義しました、[RFC3738]や[RFC4654]のように。 Anycast送付者は同じanycast IPアドレスに送られた連続したメッセージが異なったanycastノードに提供されるかもしれないのを意識しているに違いありません、すなわち、トポロジーの別の場所に到着してください。 ガイドラインが本書ではUDPを使用するマルチキャスト、放送、またはanycastアプリケーションに適用されることを意図しません。
Finally, although this document specifically refers to unicast applications that use 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 or control applications that choose to run directly over IP by registering their own IP protocol number with IANA. This document may provide useful background reading to the designers of such applications and protocols.
最終的に、このドキュメントは明確にUDPを使用するユニキャストアプリケーションを示しますが、また、ガイドラインのいくつかの精神は他のメッセージ・パッシングアプリケーションとプロトコル(特に輻輳制御、メッセージサイズ、および信頼性の話題の)に適用します。 例が、合図するのを含んでいるか、またはそれら自身のIPを登録することによって直接IPをひくのを選ぶ制御アプリケーションがIANAと共に数について議定書の中で述べます。 このドキュメントはそのようなアプリケーションとプロトコルのデザイナーに読んで聞かせる役に立つバックグラウンドを提供するかもしれません。
Eggert & Fairhurst Best Current Practice [Page 4] RFC 5405 Unicast UDP Usage Guidelines November 2008
エッゲルトとFairhurstの最も良い海流はユニキャストUDP用法ガイドライン2008年11月にRFC5405を練習します[4ページ]。
2. Terminology
2. 用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14RFC2119[RFC2119]で説明されるように本書では解釈されることであるべきです。
3. UDP Usage Guidelines
3. UDP用法ガイドライン
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. 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 [RFC0793], 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][CCID4].
これらのメカニズムは正しく実装するのが難しいです。 ほとんどのアプリケーションのために、既存のIETFトランスポート・プロトコルの1つの使用は必要なメカニズムを入手する最も簡単なメソッドです; その結果、このセクションの残りで説明されたUDP用法へのRECOMMENDED代替手段はTCP RFC0793や、Stream Control Transmissionプロトコル(SCTP)RFC4960や、SCTP Partial Reliability Extension(SCTP-PR)RFC3758などのIETFトランスポート・プロトコルの使用であるか異なった輻輳制御があるデータグラムCongestion Controlプロトコル(DCCP)RFC4340はRFC4341RFC4342CCID4をタイプします。
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 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 [RFC0896] 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
正しく使用されるなら、これらの完全により特集されたトランスポート・プロトコルはしばしば要求されるように「ヘビー級ではありません」。 例えば、TCPアルゴリズムは、何10年間もにわたって絶え間なく改良されていて、カスタムアプリケーション層のメカニズムが容易にコピーするように戦う効率と正当性のレベルに達しました。 さらに、多くのTCP実装が、接続が目的へのアプリケーションで調整されるのを許容します。 例えば、TCPの「ネーグル」アルゴリズム[RFC0896]を無効にすることができます、より頻繁な、しかし、まだ混雑で制御されたパケット伝送を犠牲にしてコミュニケーション潜在を改良して。 別の例はTCP SYNクッキーメカニズム[RFC4987]です。(それは、多くのプラットホームで利用可能です)。SYNクッキーがあるTCPは、接続が確立されるまで1接続あたりの状態を維持するためにサーバを必要としません。 また、TCPはある接続インスタンスからの遅れたセグメントがaを妨げるのを防ぐタイム誌-WAIT州を維持するために接続を終える終わりを必要とします。
Eggert & Fairhurst Best Current Practice [Page 5] RFC 5405 Unicast UDP Usage Guidelines November 2008
エッゲルトとFairhurstの最も良い海流はユニキャストUDP用法ガイドライン2008年11月にRFC5405を練習します[5ページ]。
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接続[フェーバー]を終えるかを制御することによって資源を節約するためにタイム誌-WAIT状態のメインテナンスを移行させることができます。 最終的に、TCPの経路(PMTU)結果によって効率的なデータ伝送でそんなにすぐにサポートされたマキシマム・トランスミッション・ユニットの内蔵の容量調べと認識は初期の接続設定遅れを補います、かなり多くのセグメントを交換する転送の場合で。
3.1. Congestion Control Guidelines
3.1. 輻輳制御ガイドライン
If an application or upper-layer 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.
アプリケーションか上側の層であるなら、プロトコルは、混雑で制御されたトランスポート・プロトコルを使用しないのを選んで、それは要求にこたえるためにあて先ホストへのデータグラムをUDPに送る[RFC2914]のレートのSHOULDコントロールです。 圧力に、それがどうこのトラフィックを生成するかからアプリケーションSHOULDがそれが目的地に送るすべてのUDPトラフィックの輻輳制御を独自に実行するのは、重要です。 例えば、複数の労働者を分岐させるアプリケーションは、SHOULDが実行するUDPデータグラムに集合トラフィックの輻輳制御を生成するのに複数のソケットを処理するか、またはそうでなければ、使用します。
Several approaches to perform congestion control are discussed in the remainder of this section. Not all approaches discussed below are appropriate for all UDP-transmitting applications. Section 3.1.1 discusses congestion control options for applications that perform bulk transfers over UDP. Such applications can employ schemes that sample the path over several subsequent RTTs during which data is exchanged, in order 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.2 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.3 discusses congestion control considerations when UDP is used as a tunneling protocol.
このセクションの残りで輻輳制御を実行するいくつかのアプローチについて議論します。 すべてのUDP-伝えるアプリケーションに、以下で議論したというわけではないすべてのアプローチが適切です。 セクション3.1 .1 UDPの上のバルク転送を実行するアプリケーションのための輻輳制御オプションについて議論します。 そのようなアプリケーションはデータが交換される数個のその後のRTTsの上で経路を抽出する体系を使うことができます、現在の負荷における経路がサポートすることができる送付レートを測定するために。 他のアプリケーションはいくつかのUDPデータグラムを目的地と交換するだけです。 セクション3.1 .2 そのような「低データボリューム」アプリケーションのための輻輳制御オプションについて議論します。 彼らが繰り返しに安全な送付レートに、使うことを決定するそれらが、必要がある経路を抽出できるくらいのデータを通常送らないので、UDPがトンネリングプロトコルとして使用されるとき、混雑制御機構.3のセクション3.1異種が輻輳制御問題について議論します。
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],
また、過去に、IETFは2人のホストの間の集合のトラフィックに影響する統合混雑制御機構を調査しました、すなわち、Congestionマネージャ[RFC3124]などのフレームワーク
Eggert & Fairhurst Best Current Practice [Page 6] RFC 5405 Unicast UDP Usage Guidelines November 2008
エッゲルトとFairhurstの最も良い海流はユニキャストUDP用法ガイドライン2008年11月にRFC5405を練習します[6ページ]。
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].
アクティブであるところで、セッションはトランスポート・プロトコルから独立している方法で現在の混雑情報を共有するかもしれません。 そうでなければ、UDPセッションのために混雑制御機構のデザインを簡素化するだろう以外に、そのようなメカニズムが現在展開を見ていないので、それらは[RFC2914]で要求にこたえます。
3.1.1. Bulk Transfer Applications
3.1.1. バルク転送アプリケーション
Applications that perform bulk transmission of data to a peer over UDP, i.e., applications that exchange more than a small number of UDP datagrams per RTT, SHOULD implement TCP-Friendly Rate Control (TFRC) [RFC5348], window-based, TCP-like congestion control, or otherwise ensure that the application complies with the congestion control principles.
すなわち、UDPの上でデータの大量の伝達を同輩に実行するアプリケーション、1以上の少ない番号の1RTTあたりのUDPデータグラムを交換するアプリケーション、SHOULDはTCP好意的なRate Controlが(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.1, because TFRC already addresses them, but SHOULD still follow the remaining guidelines in the subsequent subsections of Section 3.
TFRCは、IETFの他のトランスポート・プロトコルと互換性がある方法で輻輳制御と公正の両方を提供するように設計されています。 アプリケーションがTFRCを実装するなら、TFRCが既にそれらを扱いますが、SHOULDがまだセクション3のその後の小区分における残っているガイドラインに従っているので、それはセクション3.1.1における残っているガイドラインに従う必要はありません。
Bulk transfer applications that choose not to implement TFRC or TCP- like windowing SHOULD implement a congestion control scheme that results in bandwidth use that competes fairly with TCP within an order of magnitude. 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.
SHOULDに窓を付けるようにTFRCかTCPを実装しないのを選ぶバルク転送アプリケーションが1桁以内でTCPと公正に競争する帯域幅使用をもたらす輻輳制御体系を実装します。 [RFC3551]のセクション2は、アプリケーションSHOULDが許容できるパラメタの中にそれがあるのを保証するためにパケット損失率をモニターするのを示します。 同じネットワーク状態の下の同じネットワーク経路中のTCP流動が妥当なスケールで測定された少なくともUDP流動のものである平均したスループットを実現するなら、パケット損失は許容できると考えられます。 TCPとの比較は、まさに指定できませんが、スケールとスループットにおける1「桁」比較として意図します。
Finally, some bulk transfer applications may choose not to implement any congestion control mechanism and instead rely on transmitting across reserved path capacity. This might be an acceptable choice for a subset of restricted networking environments, but is by no means a safe practice for operation in the Internet. When the UDP traffic of such applications leaks out on 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.
最終的に、いくつかのバルク転送アプリケーションが、どんな混雑も制御機構であると実装して、代わりに予約された経路容量の向こう側の伝えることを当てにしないのを選ぶかもしれません。 これは、制限されたネットワーク環境の部分集合のための許容できる選択であるかもしれませんが、決してインターネットでの操作のための安全な習慣ではありません。 そのようなアプリケーションのUDPトラフィックが非食糧を供給されたインターネット経路で漏れると、それは混雑崩壊で経路を共有する他のトラフィックと結果さえの性能をかなり下げることができます。 非制御であるかunadaptiveトランスミッションがSHOULD NOTがそれほどデフォルトでする振舞いであるとサポートするアプリケーションとSHOULDは、代わりにユーザが明らかにこの運転モードを可能にするのを必要とします。
Eggert & Fairhurst Best Current Practice [Page 7] RFC 5405 Unicast UDP Usage Guidelines November 2008
エッゲルトとFairhurstの最も良い海流はユニキャストUDP用法ガイドライン2008年11月にRFC5405を練習します[7ページ]。
3.1.2. Low Data-Volume Applications
3.1.2. 低いデータボリュームアプリケーション
When applications that at any time exchange only a small number of UDP datagrams with a destination implement TFRC or one of the other congestion control schemes in Section 3.1.1, the network sees little benefit, because those mechanisms perform congestion control in a way that is only effective for longer transmissions.
いつでも目的地がある少ない数のUDPデータグラムだけを交換するアプリケーションがTFRCを実装するか、またはもう片方の輻輳制御の1つがセクション3.1.1で計画されるとき、ネットワークはほとんど利益を見ません、それらのメカニズムが、より長いトランスミッションだけに、効果的な方法で輻輳制御を実行するので。
Applications that at any time exchange only a small number of UDP datagrams with a destination SHOULD still control their transmission behavior by not sending on average more than one UDP datagram per round-trip time (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. Applications SHOULD implement the algorithm specified in [RFC2988] to compute a smoothed RTT (SRTT) estimate. They SHOULD also detect packet loss and exponentially back-off their retransmission timer when a loss event occurs. When implementing this scheme, applications need to choose a sensible initial value for the RTT. This value SHOULD generally be as conservative as possible for the given application. TCP uses an initial value of 3 seconds [RFC2988], which is also RECOMMENDED as an initial value for UDP applications. SIP [RFC3261] and GIST [GIST] use an initial value of 500 ms, and initial timeouts that are shorter than this are likely problematic in many cases. It is also important to note that the initial timeout is not the maximum possible timeout -- the RECOMMENDED algorithm in [RFC2988] yields timeout values after a series of losses that are much longer than the initial value.
いつでもSHOULDがまだ彼らのトランスミッションの振舞いを制御している目的地で少ない数のUDPデータグラムだけを交換する転送されないアプリケーションが往復の時間(RTT)あたり1個以上のUDPデータグラムを目的地に平均します。 [RFC1536]、SHOULDがRTTの見積りにそれが交信するどんな目的地にも維持するアプリケーションにおける推薦と同様です。 アプリケーションSHOULDは平坦なRTT(SRTT)見積りに計算するために[RFC2988]で指定されたアルゴリズムを実装します。 それら、SHOULDはまた、パケット損失を検出して、損失イベントが起こると、それらの再送信タイマーを指数関数的に戻します。 この体系を実装するとき、アプリケーションは、RTTにおいて、分別がある初期の値を選ぶ必要があります。 これはSHOULDを評価します。一般に、できるだけ与えられたアプリケーションには保守的であってください。 TCPは3秒[RFC2988]の初期の値を使用します。(また、秒はUDPアプリケーションのための初期の値としてRECOMMENDEDです)。 SIP[RFC3261]とGIST[GIST]は500msの初期の値を使用します、そして、多くの場合、これより短い初期のタイムアウトはおそらく問題が多いです。 また、初期のタイムアウトが最大の可能なタイムアウトでないことに注意するのも重要です--[RFC2988]のRECOMMENDEDアルゴリズムは初期の値よりはるかに長い一連の損失の後にタイムアウト値をもたらします。
Some applications cannot maintain a reliable RTT estimate for a destination. The first case is that of applications that exchange too few UDP datagrams with a peer to establish a statistically accurate RTT estimate. Such applications MAY use a predetermined transmission interval that is exponentially backed-off when packets are lost. TCP uses an initial value of 3 seconds [RFC2988], which is also RECOMMENDED as an initial value for UDP applications. SIP [RFC3261] and GIST [GIST] 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.
いくつかのアプリケーションは目的地のための信頼できるRTT見積りを維持できません。 最初のケースは統計的に正確なRTT見積りを証明するためにあまりにわずかなUDPデータグラムを同輩と交換するアプリケーションのものです。 そのようなアプリケーションはパケットが無くなるとき指数関数的に戻される予定されたトランスミッション間隔を費やすかもしれません。 TCPは3秒[RFC2988]の初期の値を使用します。(また、秒はUDPアプリケーションのための初期の値としてRECOMMENDEDです)。 SIP[RFC3261]とGIST[GIST]は500msの間隔を費やします、そして、多くの場合、より短い値はおそらく問題が多いです。 先の事件のように、初期のタイムアウトが最大の可能なタイムアウトでないことに注意してください。
A second class 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. The 3-second interval was chosen based on TCP's retransmission timeout when the RTT is unknown [RFC2988], and shorter values are likely problematic in many cases. Note that the sending rate in this
アプリケーションの二等は目的地のためのRTT見積りを維持できません、目的地がリターントラフィックを送らないので。 そのようなアプリケーションSHOULD NOTは1個以上のUDPデータグラムに3秒毎を送ります、そして、可能であるときに、SHOULDはそれほど攻撃的でないレートさえ使用します。 RTTが未知であり[RFC2988]、より短い値が多くの場合おそらく問題が多いときに、3秒の間隔はTCPの再送タイムアウトに基づいて選ばれました。 発信がこれで評価することに注意してください。
Eggert & Fairhurst Best Current Practice [Page 8] RFC 5405 Unicast UDP Usage Guidelines November 2008
エッゲルトとFairhurstの最も良い海流はユニキャストUDP用法ガイドライン2008年11月にRFC5405を練習します[8ページ]。
case must be more conservative than in the two previous cases, because the lack of return traffic prevents the detection of packet loss, i.e., congestion events, and the application therefore cannot perform exponential back-off to reduce load.
ケースは2回の先の事件より保守的であるに違いありません、リターントラフィックの不足がすなわち、パケット損失、混雑イベントの検出を防ぎます、そして、したがって、アプリケーションは負荷を減少させるために下に指数の後部を実行できません。
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 direction 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.
bidirectionally SHOULDを伝えるアプリケーションがコミュニケーションの両方の方向のための輻輳制御を使います。 例えば、クライアント/サーバ、要求応答スタイルアプリケーションのために、クライアントSHOULDはサーバへの彼らの要求送信を混雑していて制御します、そして、サーバSHOULDはクライアントへの応答を混雑していて制御します。 前進の、そして、反対の方向への混雑は非相関であり、アプリケーションはどちらかが方向、または限界の両方に沿って新しくて再送された要求が全体の往復の経路の向こう側に承認された応答に拠点を置いた混雑に独自に検出して、反応させるSHOULDです。
3.1.3. UDP Tunnels
3.1.3. UDP Tunnels
One increasingly popular use of UDP is as a tunneling protocol, where a tunnel endpoint encapsulates the packets of another protocol inside UDP datagrams and transmits them to another tunnel endpoint, which decapsulates the UDP datagrams and forwards the original packets contained in the payload. 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つのますますポピュラーな使用があります。トンネル終点がUDPデータグラムの中に別のプロトコルのパケットをカプセルに入れって、別のトンネル終点にそれらを送って、そこでは、そのdecapsulatesはオリジナルのパケットがペイロードに含んだUDPデータグラムとフォワードです。 トンネルは、直接物理的なインターネットトポロジーで遠方である位置をつなげるように見える仮想のリンクを設立して、仮想(個人的な)のネットワークを創設するのに使用できます。 ペイロードプロトコルが経路に沿って存在するかもしれないmiddleboxesによってサポートされないとき、トンネリングプロトコルとしてUDPを使用するのは魅力的です、多くのmiddleboxesが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 -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流動です、そして、encapsulatorとdecapsulatorは定期的な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; second, whether the tunneling scheme generates UDP traffic at a volume that corresponds to the volume of payload traffic carried within the tunnel.
2つの要素が、ペイロードトラフィックが最初に、IPベースであるか否かに関係なく、UDPトンネルが、特定の混雑制御機構を使う必要であるかどうか決定します。 2番目に、トンネリング体系が、ペイロードトラフィックのボリュームに対応するボリュームでUDPがトラフィックであると生成するかどうかトンネルの中で運ばれました。
IP-based traffic is generally assumed to be congestion-controlled, i.e., it is assumed that the transport protocols generating IP-based traffic at the sender already employ mechanisms that are sufficient to address congestion on the path. Consequently, a tunnel carrying
一般に、混雑によってIPベースのトラフィックが制御されていると思われて、すなわち、送付者で既にIPベースのトラフィックを生成するトランスポート・プロトコルが経路で混雑を扱うために十分なメカニズムを使うと思われます。 その結果トンネル携帯
Eggert & Fairhurst Best Current Practice [Page 9] RFC 5405 Unicast UDP Usage Guidelines November 2008
エッゲルトとFairhurstの最も良い海流はユニキャストUDP用法ガイドライン2008年11月にRFC5405を練習します[9ページ]。
IP-based traffic should already interact appropriately with other traffic sharing the path, and specific congestion control mechanisms for the tunnel are not necessary.
IPベースのトラフィックは既に適切に経路を共有する他のトラフィックと対話するべきです、そして、トンネルへの特定の混雑制御機構は必要ではありません。
However, if the IP traffic in the tunnel is known to not be congestion-controlled, additional measures are RECOMMENDED in order to limit the impact of the tunneled traffic on other traffic sharing the path.
しかしながら、混雑によってトンネルのIPトラフィックが制御されていないのが知られているなら、追加措置は、経路を共有しながら他のトラフィックでトンネルを堀られたトラフィックの影響を制限するRECOMMENDEDです。
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.
これはインターネットトンネルへの論証上最も一般的なそうです。 この場合、UDPトンネルSHOULD NOTはそれ自身の混雑制御機構を使います、トンネルを堀られたトラフィックの混雑の損失がトンネルを堀られたトラフィックの元の送り主で既に適切な混雑応答の引き金となるので。
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のベースのコミュニケーションが混雑によって制御されているという前提で築き上げられることに注意してください。 UDPトンネルが制御されなかったどんな混雑であることも知られているIPベースのトラフィックに使用されるなら、ガイドラインの次のセットは適用されます。
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.
Because tunnels are usually bulk-transfer applications as far as
the intermediate routers are concerned, the guidelines in
Section 3.1.1 apply.
いくつかのリンク層プロトコルがUDPの中でカプセル化されるとき(すべてがプロトコルをリンクで層にするというわけではありません; 或るものは混雑によって制御されています)、例えば、これはそうであるかもしれません。 トンネルを堀られた非IPトラフィックの混雑の損失が送付者で適切な混雑応答の引き金となるのが知られていないので、UDPトンネルSHOULDは適切な混雑制御機構を使います。 中間的ルータに関する限り、トンネルが通常大量の転送アプリケーションであるので、セクション3.1.1におけるガイドラインは適用されます。
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. トンネルは、ペイロードトラフィックのボリュームと食い違っているボリュームでUDPがトラフィックであると生成します、ペイロードトラフィックがIPベースか混雑によって制御されていることの如何にかかわらず。
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
このクラスに関する例は増加する冗長のためForward Errorであるときに例えばそれらの通信速度を一定の割合で増加に損失で送るUDPトンネルを含んでいます。
Eggert & Fairhurst Best Current Practice [Page 10] RFC 5405 Unicast UDP Usage Guidelines November 2008
エッゲルトとFairhurstの最も良い海流はユニキャストUDP用法ガイドライン2008年11月にRFC5405を練習します[10ページ]。
Correction is used, or are otherwise constrained 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.
修正は、使用されているか、または別の方法で彼らのトランスミッションの振舞いで抑制されます。 トンネリングのためのUDPのこれらの専門化している用途は本書では与えられた一般的ガイドラインの範囲を越えます。 そのようなもののimplementerはそれらのトンネリングメカニズムのデザインでSHOULDが輻輳制御であると慎重に考えるトンネルを専門にしました。
Designing a tunneling mechanism requires significantly more expertise than needed for many other UDP applications, because tunnels virtualize lower-layer components of the Internet, and the virtualized components need to correctly interact with the infrastructure at that layer. 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アプリケーションに必要とされるよりかなり多くの専門的技術を必要とします、トンネルがインターネットの下層コンポーネントをvirtualizeして、virtualizedコンポーネントが、その層で正しくインフラストラクチャと対話する必要があるので。 このドキュメントは、UDPにトンネルを実装するために輻輳制御が問題であるのに触れるだけです。 範囲の外に他の必要なトンネリングの振舞いの議論があります。
3.2. Message Size Guidelines
3.2. メッセージサイズガイドライン
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. 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, and instead choose to drop all fragments. Finally, [RFC4963] documents other issues specific to IPv4 fragmentation.
IP断片化はインターネット通信の効率と信頼性を下げます。 ただ一つの断片の損失は全体の断片化しているパケットの損失をもたらします、正しく他のすべての断片を受け取っても、オリジナルのパケットを組み立て直して、提供できないので。 断片化のこの基本的な問題はIPv4とIPv6の両方のために存在しています。 さらに、いくつかのネットワークアドレス変換機構(NATs)とファイアウォールがIP断片を下げます。 NATによって実行されたネットワーク・アドレス翻訳は完全なIPパケットを作動させるだけです、そして、また、いくつかのファイアウォール方針が完全なIPパケットの点検を必要とします。 いくつかのNATsとファイアウォールは、ケースであるこれらがあっても、絶対に必要な再アセンブリの機能性を実装して、すべての断片を下げるのを代わりに選びません。 最終的に、[RFC4963]はIPv4断片化に特定の他の問題を記録します。
Due to these issues, an application SHOULD NOT send UDP datagrams that result in IP packets that exceed the MTU of 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 itself [RFC1191][RFC1981][RFC4821] to determine whether the path to a destination will support its desired message size without fragmentation.
これらの問題、SHOULD NOTが経路のMTUを目的地に超えているIPパケットをもたらすUDPデータグラムを送るアプリケーションのため。 その結果SHOULDが目的地への経路が断片化なしで必要なメッセージサイズをサポートするか否かに関係なく、決定するために、IP層で提供された経路MTU情報を使用するか、または経路MTU探索[RFC1191][RFC1981][RFC4821]自体を実装するアプリケーション。
Applications that do not follow this recommendation to do PMTU 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
SHOULDが、UDPデータグラムにそれを送るのをまだ避けているという発見をPMTUにするというこの推薦に続かないアプリケーションが経路MTUを超えているIPパケットをもたらすでしょう。 実際の経路MTUが未知であるので、そのようなアプリケーションSHOULDは送付のためのデフォルトの有効なMTU([RFC1122]のEMTU_S)より短い送付メッセージへ後ろへ下がります。 IPv4に関しては、576バイトと最初に、ホップMTU[RFC1122]ではEMTU_Sは、より小さいです。 IPv6に関しては、EMTU_Sは1280バイト[RFC2460]です。 直接接続された目的地(経路のルータのない)への有効なPMTUは構成されたインタフェースMTUであり、どれがあるかもしれませんか?
Eggert & Fairhurst Best Current Practice [Page 11] RFC 5405 Unicast UDP Usage Guidelines November 2008
エッゲルトとFairhurstの最も良い海流はユニキャストUDP用法ガイドライン2008年11月にRFC5405を練習します[11ページ]。
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.
最大のリンクペイロードサイズよりそれほど。 最小の大きさで分けられたUDPデータグラムのトランスミッションはPMTUが発見であると実装する2番目の理由であるより大きいPMTUをサポートする経路の上で効率が悪いです。
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 MMS_S, can be obtained from the TCP/IP stack [RFC1122].
適切なUDPペイロードサイズを決定するために、アプリケーションはPMTUサイズからUDPヘッダー(8バイト)の長さと同様にIPヘッダー(どんなIPv4の任意のヘッダーやIPv6拡張ヘッダーも含んでいる)のサイズを引き算しなければなりません。 TCP/IPスタック[RFC1122]からMMS_Sとして知られているこのサイズは得ることができます。
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, so implementing PMTU discovery may be beneficial.
IPv4かIPv6の有効なPMTUを超えているメッセージを送らないアプリケーションは上のメカニズムのどれかを実装する必要はありません。PMTUが発見であると実装するのが有益であることができなるようにトンネルの存在が有効な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データグラムSHOULDに応用層メッセージを断片化するアプリケーションは、各データグラムを独自に受け取って、アプリケーションがそれ自身の信頼性がメカニズムであると実装する場合で独自に再送できるようにこの断片化を実行します。
3.3. Reliability Guidelines
3.3. 信頼性のガイドライン
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. 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. Application designers SHOULD verify that their application handles datagram duplication gracefully, and may consequently need to implement mechanisms to detect duplicates. Even if UDP datagram reception triggers idempotent operations, applications may want to suppress duplicate datagrams to reduce load.
UDPもデータグラム複製から守りません、すなわち、アプリケーションは複本の同じUDPデータグラムを受けるかもしれません。 アプリケーション設計者SHOULDは、写しを検出するために彼らのアプリケーションが、優雅にデータグラム複製を処理して、その結果、メカニズムを実装する必要であるかもしれないことを確かめます。 UDPデータグラムレセプションがベキ等元操作の引き金となっても、アプリケーションは、負荷を減少させるために写しデータグラムを抑圧したがっているかもしれません。
In addition, 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. Applications that require ordered delivery MUST reestablish datagram ordering themselves.
さらに、インターネットは他のものに関していくつかのパケットをかなり遅らせることができます、例えば、ルーティング過渡現象、間欠接続性、または移動性のため。 UDPデータグラムがトランスミッション命令と異なったオーダーにおける受信機に届くところでこれは再命令を引き起こす場合があります。 命令された配送を必要とするアプリケーションはデータグラム注文を自分たちで復職させなければなりません。
Finally, it is important to note that delay spikes can be very large. This can cause reordered packets to arrive many seconds after they were sent. [RFC0793] defines the maximum delay a TCP segment should experience -- the Maximum Segment Lifetime (MSL) -- as 2 minutes. No
最終的に、遅れスパイクが非常に大きい場合があることに注意するのは重要です。 これで、それらを送った何秒も後に再命令されたパケットは到着できます。 [RFC0793]はTCPセグメントがなるべきである最大の遅れ(Maximum Segment Lifetime(MSL))を2分と定義します。 いいえ
Eggert & Fairhurst Best Current Practice [Page 12] RFC 5405 Unicast UDP Usage Guidelines November 2008
エッゲルトとFairhurstの最も良い海流はユニキャストUDP用法ガイドライン2008年11月にRFC5405を練習します[12ページ]。
other RFC defines an MSL for other transport protocols or IP itself. This document clarifies that the MSL value to be used for UDP SHOULD be the same 2 minutes as for TCP. Applications SHOULD be robust to the reception of delayed or duplicate packets that are received within this 2-minute interval.
他のRFCは他のトランスポート・プロトコルかIP自身のためにMSLを定義します。 このドキュメントははっきりさせられます。UDP SHOULDに使用されるべきMSL値はTCPのように同じ2分です。 この2分の間隔のSHOULDが遅らせられることのレセプションに強健であるか、または受け取られていているパケットをコピーするアプリケーション。
An application that requires reliable and ordered message delivery SHOULD choose an IETF standard transport protocol that provides these features. If this is not possible, it will need to implement a set of appropriate mechanisms itself.
SHOULDがそれについて議定書の中で述べるのをIETFの標準の輸送を選ぶ信頼できて注文されたメッセージ配送を必要とするアプリケーションはこれらの特徴を提供します。 これが可能でないなら、それは、適切な手段のセット自体を実装する必要があるでしょう。
3.4. Checksum Guidelines
3.4. チェックサムガイドライン
The UDP header includes an optional, 16-bit one's complement checksum that provides an integrity check. This results in a relatively weak protection in terms of coding theory [RFC3819], and application developers SHOULD implement additional checks where data integrity is important, e.g., through a Cyclic Redundancy Check (CRC) included with the data to verify the integrity of an entire object/file sent over the UDP service.
UDPヘッダーは保全チェックを提供する任意の、そして、16ビットの1の補数チェックサムを入れます。 これはコード化理論[RFC3819]で比較的弱い保護をもたらします、そして、アプリケーション開発者SHOULDは例えば、データ保全が重要であるところ、確かめるデータでCyclic Redundancy Check(CRC)を含んでいることを通した追加チェックがUDPサービスの上に送られた全体のオブジェクト/ファイルの保全であると実装します。
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. It therefore protects an application against receiving corrupted payload data in place of, or in addition to, the data that was sent. This check is not strong from a coding or cryptographic perspective, and is not designed to detect physical-layer errors or malicious modification of the datagram [RFC3819].
UDPチェックサムはペイロードがトランジットで崩壊しなかったという統計的な保証を提供します。 また、それで、受信機は、それがパケットの意図している目的地であったことを確かめることができます、IPアドレス、ポートナンバー、およびプロトコル番号を含んで、パケットが先端を切られもしませんし、水増しもされないことを確かめるので、サイズ分野をカバーしているので。 したがって、それは、データか送られたデータの崩壊したペイロードデータを受け取らないようにアプリケーションを保護します。 このチェックは、コード化か暗号の見解から強くなく、またデータグラム[RFC3819]の物理的な層の誤りか悪意がある変更を検出するように設計されていません。
Applications SHOULD enable UDP checksums, although [RFC0768] permits the option to disable their use. Applications that choose to disable UDP checksums when transmitting over IPv4 therefore 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. The use of the UDP checksum is REQUIRED when applications transmit UDP over IPv6 [RFC2460].
[RFC0768]は、オプションが彼らの使用を無効にすることを許可しますが、アプリケーションSHOULDはUDPチェックサムを可能にします。 IPv4の上を伝わるとき、UDPにチェックサムを無効にするのを選ぶアプリケーションは、したがって、受信データの正当性に関する仮定をしてはいけなくて、UDPデータグラムが受け取って、元々異なった目的地にそれを送ったということであるか別の方法で崩壊するとき、正しく振る舞わなければなりません。 アプリケーションがIPv6[RFC2460]の上にUDPを伝えるとき、UDPチェックサムの使用はREQUIREDです。
3.4.1. UDP-Lite
3.4.1. UDP-Lite
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
特別なクラスのアプリケーションが利益に誤り傾向があるリンクを含んでいる経路を使用するとき、捨てられるより部分的に破損しているペイロードをむしろ提供させるのに由来できます。 の代わりにするそのようなアプリケーションが、ペイロード不正を許容できて、UDPのライト級ユーザー・データグラム・プロトコル(UDP-Lite)[RFC3828]異形を使用するのを選ぶかもしれない。
Eggert & Fairhurst Best Current Practice [Page 13] RFC 5405 Unicast UDP Usage Guidelines November 2008
エッゲルトとFairhurstの最も良い海流はユニキャストUDP用法ガイドライン2008年11月にRFC5405を練習します[13ページ]。
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を使用するのを選ぶアプリケーションはまだ使用のためにUDPと共にセクション3で説明された輻輳制御と他のガイドラインに従っているべきです。
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 a checksum coverage length value: 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. Applications using UDP-Lite therefore 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は、いつもすなわち、パケットがいつも意図している送付先に提供されたことを確かめます。ヘッダーフィールドについて確かめます。 神経の鈍い部分の誤りで、目的地でUDPデータグラムを捨てないでしょう。 したがって、UDP-Liteを使用するアプリケーションはUDP-Liteペイロードの神経の鈍い一部分に受け取られたデータの正当性に関する仮定をしてはいけません。
The sending application SHOULD select the minimum checksum coverage to include all sensitive protocol headers. 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).
送付アプリケーションSHOULDは、すべての敏感なプロトコルヘッダーを含むように最小のチェックサム適用範囲を選択します。 例えば、レアル-時間プロトコル(RTP)[RFC3550]を使用するアプリケーションは不正に対しておそらくRTPヘッダーを保護したくなるでしょう。 また、アプリケーションはUDP-Liteペイロード(例えば、内部のCRCs)の神経の鈍い一部分で運ばれたプロトコル情報のために適切であるところでそれら自身の適切なバリディティチェックを導入しなければなりません。
The 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 may be negotiated by an application. UDP-Lite does not provide mechanisms to negotiate the checksum coverage between the sender and receiver.
受信機は入って来るパケットのための送付者[RFC3828]によって使用された中で最も小さい適用範囲ほど小さくない最小の適用範囲敷居を設定しなければなりません。 受信機SHOULDは不適当に短い適用範囲分野でパケットを妨げることができるくらい大きい敷居を選択します。 これは、一定の価値であるかもしれない、またはアプリケーションで交渉されるかもしれません。 UDP-Liteは、送付者と受信機の間のチェックサム適用範囲を交渉するためにメカニズムを提供しません。
Applications may still experience packet loss, rather than corruption, 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データグラム(すなわち、パケット損失における結果)として扱われるUDP-Liteデータグラムをもたらすことができます。 また、IP断片化の使用はUDP- Liteデータグラムに関する特別な処理を防ぐことができます、そして、これはアプリケーションSHOULDがIP断片化(セクション3.2)を避ける別の理由です。
Eggert & Fairhurst Best Current Practice [Page 14] RFC 5405 Unicast UDP Usage Guidelines November 2008
エッゲルトとFairhurstの最も良い海流はユニキャストUDP用法ガイドライン2008年11月にRFC5405を練習します[14ページ]。
3.5. Middlebox Traversal Guidelines
3.5. Middlebox縦断ガイドライン
Network address translators (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 traffic
and create and destroy per-flow state accordingly. For a
connectionless protocol such as UDP, this approach is not possible.
Consequently, middleboxes may create per-flow state when they see a
packet that indicates a new flow, and destroy the state after some
period of time during which no packets belonging to the same flow
have arrived.
ネットワークアドレス変換機構(NATs)とファイアウォールは終わりから端への経路に沿って存在できる媒介装置("middleboxes")に関する例です。 middleboxは1流れあたりの状態を維持するためにそれを必要とする機能を通常実行します。 TCPなどの接続指向のプロトコルのために、middleboxesはそれに従って、1流れあたりの状態を詮索して、接続管理トラフィックを分析して、創設して、破壊します。 UDPなどのコネクションレスプロトコルにおいて、このアプローチは可能ではありません。 その結果、middleboxesは彼らが新しい流れを示すパケットを見るとき、1流れあたりの状態を創設して、同じ流れに属すパケットが全く到着していないいつかの期間の後に状態を破壊するかもしれません。
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.
middleboxが実行する具体的な機能によって、この振舞いはmiddleboxの向こう側にうまくいっているUDPトラフィック交換の種類を制限する時間依存を導入できます。 例えば、NATsとファイアウォールはそれらが役立つドメインに内部であるためにそれらの半面の上の部分的な経路を通常定義しますが、それらの反対側の部分的な経路は、そのドメインに外であるために定義されます。 最初のパケットが内部から外部まで交差するとき、1流れあたりの状態は通常創設されます、そして、状態が存在している間、NATsとファイアウォールはリターントラフィックを進めるでしょう。 1流れあたりの状態は外で時間があった後に到着するリターントラフィックが下げられます、外部から到着する他のトラフィックのように。
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を使用する多くのアプリケーションがmiddleboxesの向こう側に作動します。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.
middleboxesがアプリケーションが少しのUDPトラフィックも交換しない期間、アプリケーションセッションに関連している1流れあたりの状態を破壊するとき、他のアプリケーションは通信障害になるかもしれません。 アプリケーション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. 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.
メディアトランスミッションなどのいくつかの応用には、この再同期は非常に望ましくありません、知覚できる再生人工物をユーザに引き起こす場合があるので。 そのような専門化しているアプリケーションはmiddlebox状態をリフレッシュするのを試みるメッセージを周期的な生きている生活費に送るかもしれません。 それがメッセージを生かすことに注意するために重要であるのは、一般的使用のためのNOT RECOMMENDEDです--多くのアプリケーションに不要であり、かなりの量のシステムとネットワーク資源を消費できるということです。
Eggert & Fairhurst Best Current Practice [Page 15] RFC 5405 Unicast UDP Usage Guidelines November 2008
エッゲルトとFairhurstの最も良い海流はユニキャストUDP用法ガイドライン2008年11月にRFC5405を練習します[15ページ]。
An application that needs to employ keep-alives 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 [ICE]. When applications are deployed in more
controlled network environments, the deployers 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 Middlebox
Communications (MIDCOM) [RFC3303], Next Steps in Signaling (NSIS)
[NSLP], 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.
可能であるときに、かつての15秒毎とSHOULDが、より長い間隔を費やすより頻繁にmiddleboxes SHOULDの面前でUDPが伝えない役に立つサービスオーバーを提供するためにアリフを保っているそれらを使う必要があるアプリケーション。 どんな一般的なタイムアウトも任意のmiddleboxesとして1流れあたりのUDP状態に指定されていません。 NATsは2分の州のタイムアウト[RFC4787]を必要とします。 しかしながら、実証的証拠は、残念ながら、現在配布しているmiddleboxesの重要な部分が、より短いタイムアウトを使用するのを示します。 15秒のタイムアウトはInteractive Connectivity特権階級(ICE)プロトコル[ICE]を発します。 アプリケーションが、より制御されたネットワーク環境で配布されるとき、例えば、アプリケーションが目標環境で、より長い間隔を費やすことができるか、または明らかにmiddleboxを制御するためにメカニズムを申し出ることにかかわらずSHOULDが調査するデプロイヤは、Middlebox Communications(MIDCOM)[RFC3303]、Signaling(NSIS)のNext Steps[NSLP]、またはUniversal Plug and Play(UPnP)[UPnP]を使用することでタイムアウト持続時間を述べます。 アプリケーションが異なったホストから生きている生活費送信の間の永続的な同期の可能性を減少させるために、わずかな不規則変動(「ジター」)を生きている生活費送信のタイミングに適用するのは、RECOMMENDEDです。
Sending keep-alives is not a substitute for implementing robust connection handling. Like all UDP datagrams, keep-alives 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-alives. Congestion control may thus lead to delays or temporary suspension of keep-alive transmission.
発信して、アリフを保つのは、体力を要している接続取り扱いを実装する代用品ではありません。 すべてのUDPデータグラムのように、middlebox状態をタイムアウトに引き起こす場合、生活費アリフを遅らせるか、または下げることができます。 さらに、セクション3.1の輻輳制御ガイドラインはアプリケーションですべてのUDPトランスミッションをカバーしています、middlebox生活費アリフの送信を含んでいて。 その結果コントロールが遅れか一時的なサスペンションに導くかもしれない混雑はトランスミッションを生かします。
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-alives 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-alives 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 [ICE], does succeed less often with TCP than with UDP. The tradeoffs between different transport protocols -- especially when it comes to middlebox traversal -- deserve careful analysis.
生きている生活費メッセージは一般的使用のためのNOT RECOMMENDEDです。 彼らは、多くのアプリケーションに不要であり、重要なリソースを消費するかもしれません。 例えば、アプリケーションが、長期の間、少ないトラフィックで接続性を維持する必要があるなら、バッテリーによる動力付きのデバイスで、生活費アリフが送られる頻度は電力消費量を決定する決定的要因になることができます、基本的なネットワーク技術によって。 多くのmiddleboxesがUDPに必要であるそれよりはるかに低い頻度でTCPのためにアリフを保っている接続を必要とするように設計されているので、この違いだけがこれらの展開のためにUDPよりTCPを好むためにしばしば十分である場合があります。 他方では、middleboxes、例えば、ICE[ICE]を使用するのによるダイレクトコミュニケーションがしばしばTCPよりUDPと共に成功するのを示す逸話の証拠があります。 異なったトランスポート・プロトコルの特にmiddlebox縦断のこととなると、間の見返りは慎重な分析に値します。
Eggert & Fairhurst Best Current Practice [Page 16] RFC 5405 Unicast UDP Usage Guidelines November 2008
エッゲルトとFairhurstの最も良い海流はユニキャストUDP用法ガイドライン2008年11月にRFC5405を練習します[16ページ]。
3.6. Programming Guidelines
3.6. プログラミングガイドライン
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パケットを組み立てて、送る能力をアプリケーションに提供します。 これは1秒、UDPを使用するより厄介なメソッドです。 ガイドラインは本書では、アプリケーションがUDPを使用するかもしれないそのようなすべてのメソッドをカバーしています。 ソケットAPIが断然最も多くの共通方法であるので、このセクションの残りはさらに詳細にそれについて議論します。
Although the sockets API was developed for UNIX in the early 1980s, a wide variety of non-UNIX operating systems also implement this. 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, the remainder of 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のためにいくつかのキー溝的にそれと異なっています。 アプリケーション・プログラマーがTCPソケットAPIに通常詳しいので、このセクションの残りはこれらの違いについて議論します。 [スティーブンス]は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ソケットに関する1つ以上のIPソースアドレスからパケットを受けることができます。 いくつかのサーバが、同時に単一のUDPソケットを通して1人以上のリモートホストとデータを交換するのにこれを使用します。 多くのアプリケーションが、彼らが特定のソースアドレスからパケットを受けるのを保証する必要があります。 これらのアプリケーションは、応用層で対応するチェックを実装しなければならないか、またはオペレーティングシステムが容認されたパケットをフィルターにかけるよう明らかに要求しなければなりません。
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.
[RFC1122]を見てください、セクション4.1。アプリケーションがクライアント/サーバであるならホストの上で1以上でIPインタフェース、SHOULDが要求を運んだUDPデータグラムの受信者IPアドレスに合っているIPソースアドレスによるどんなUDP応答も送るアプリケーションを作成する、(.3 .5)。 多くのmiddleboxesがこのトランスミッションの振舞いを予想して、異なったIPアドレスから送られる回答を下げます、セクション3.5で説明されるように。
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データグラムを受けることができます。 これが読書()ソケット呼び出しからのゼロのリターン値と異なっていることに注意してください。TCPのために、呼び出しは接続の終わりを示します。
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
また、すなわち、多くのオペレーティングシステムで、UDPソケットは、UDPソケットをアドレスとポートの特定の組まで縛るために接続します。 これは対応するTCPソケットAPIの機能性と同様です。 しかしながら、UDPに関して、これはそれが役立つ地方の操作にすぎません。
Eggert & Fairhurst Best Current Practice [Page 17] RFC 5405 Unicast UDP Usage Guidelines November 2008
エッゲルトとFairhurstの最も良い海流はユニキャストUDP用法ガイドライン2008年11月にRFC5405を練習します[17ページ]。
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は地方のUDPソケットが制限されているリモート終わりに通知しません。 また、ソケットを縛るのは例えば、層が使用するUDPチェックサムかIP TimestampオプションのUDPかIPに影響するオプションを構成させます。 また、いくつかのスタックの上では、トランスミッション[RFC1122]のためにICMPエラーメッセージを受け取るとき、制限されたソケットは、アプリケーションが通知されるのを許容します。
UDP provides no flow-control. 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 on 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.
UDPはフロー制御を全く提供しません。 これはUDPベースのアプリケーションがパケット損失の面前で強健である必要がある別の理由です。 また、この損失は送付ホストの中に発生できます、アプリケーションが外国行きのネットワーク・インターフェースのライン料率より速くデータを送るとき。 また、それは目的地に起こることができて、どこがアプリケーションがそれらをあまりまれに発行するとき(すなわち、受信バッファがあふれるように)、すべてのデータにそれを返すやり損ないを送ったという要求を受けるか。 強健なフロー制御メカニズムは実装するのが難しいです(この機能性SHOULDを必要とするアプリケーションが完全装備のトランスポート・プロトコルを使用すると考える理由です)。
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 in this case. 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ソケットを閉じると、受信ホストの上のトランスポート・プロトコルが、タイム誌-WAIT状態を維持するのに必要です。 これは、閉じている接続インスタンスからの遅れたパケットが同じIPアドレスを再利用して、たまたま組を移植する後の接続インスタンスに誤って関連しているのを防ぎます。 UDPプロトコルはそのようなメカニズムを実装しません。 したがって、UDPベースのアプリケーションは、この場合強健である必要があります。 同じポートの上で受信される別のアプリケーションが時間内にあとに続いて、1つのアプリケーションが、ソケットを閉じるか、または終わるかもしれません。 そして、この後のアプリケーションはネットワークで遅れた最初のアプリケーションのために意図するパケットを受けるかもしれません。
The Internet can provide service differentiation to applications based on IP-layer packet markings [RFC2475]. This facility can be used for UDP traffic. Different operating systems provide different interfaces for marking packets to applications. Differentiated services require support from the network, and application deployers need to discuss the provisioning of this functionality with their network operator.
インターネットはIP-層のパケット印[RFC2475]に基づくアプリケーションにサービス分化を提供できます。 UDPトラフィックにこの施設を使用できます。 異なったオペレーティングシステムはアプリケーションにパケットをマークするのに異なったインタフェースを提供します。 差別化されたサービスはネットワークから支持を要します、そして、アプリケーションデプロイヤは彼らのネットワーク・オペレータによるこの機能性の食糧を供給することについて議論する必要があります。
3.7. ICMP Guidelines
3.7. ICMPガイドライン
Applications can utilize information about ICMP error messages that the UDP layer passes up for a variety of purposes [RFC1122]. Applications SHOULD validate that the information in the ICMP message payload, e.g., a reported error condition, corresponds to a UDP datagram that the application actually sent. Note that not all APIs
アプリケーションはUDP層がさまざまな目的のために[RFC1122]を無視するというICMPエラーメッセージの情報を利用できます。 アプリケーションSHOULDはそれを有効にします。ICMPメッセージペイロードの情報(例えば、報告されたエラー条件)はアプリケーションが実際に送ったUDPデータグラムに対応しています。 すべてのAPIではなく、それに注意してください。
Eggert & Fairhurst Best Current Practice [Page 18] RFC 5405 Unicast UDP Usage Guidelines November 2008
エッゲルトとFairhurstの最も良い海流はユニキャストUDP用法ガイドライン2008年11月にRFC5405を練習します[18ページ]。
have the necessary functions to support this validation, and some APIs already perform this validation internally before passing ICMP information to the application.
この合法化をサポートする必要な機能を持ってください。そうすれば、情報をICMPに通過する前に、いくつかのAPIが既に内部的にこの合法化をアプリケーションに実行します。
Any application response to ICMP error messages SHOULD be robust to temporary routing failures, i.e., transient ICMP "unreachable" messages should not normally cause a communication abort. Applications SHOULD appropriately process ICMP messages generated in response to transmitted traffic. A correct response often 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.
どんなアプリケーション応答、もICMPエラーメッセージSHOULDに、ICMP一時的なルーティング失敗に強健で、すなわち、一時的な「手の届かないこと」は通常、メッセージがコミュニケーションアボートを引き起こすはずがないそうです。 アプリケーションSHOULDは適切に伝えられたトラフィックに対応して生成されたICMPメッセージを処理します。 正しい応答はしばしば接続指向のトランスポート・プロトコルで容易に利用可能ですが、UDPベースのアプリケーションでいつも維持されるというわけではない各目的地へのコミュニケーションインスタンスに関する地方の状態などの文脈を必要とします。
4. Security Considerations
4. セキュリティ問題
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. Applications that respond to short requests with potentially large responses are vulnerable to amplification attacks, and SHOULD authenticate the sender before responding. The source IP address of a request is not a useful authenticator, because it can be spoofed.
UDPは通信秘密保全を提供しません。 盗聴、改ざん、またはメッセージ偽造SHOULDに対してそれらのコミュニケーションを保護する必要があるアプリケーションが終わりから終わりへの他のIETFプロトコルによって提供されたセキュリティー・サービスを使います。 潜在的に大きい応答で短い要求に応じるアプリケーションは増幅攻撃に被害を受け易いです、そして、SHOULDは応じる前に、送付者を認証します。 それを偽造することができるので、要求のソースIPアドレスは役に立つ固有識別文字ではありません。
One option of 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) [RFC4306] 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.
UDPにコミュニケーションを保証する1つのオプションがIPsec[RFC4301]と共にあります。(IPsecはEncapsulating Security有効搭載量(超能力)[RFC4303]を通したAuthentication Header(AH)[RFC4302]と暗号化、そして/または、認証によるIPパケットの流れのための認証を提供できます)。 アプリケーションは、彼らのセッションのためにIPsecを構成するのに、インターネット・キー・エクスチェンジ(IKE)[RFC4306]を使用します。 IPsecが流れのためにどう構成されるかによって、それは、UDPペイロードと同様にUDPヘッダーを認証するか、または暗号化できます。 アプリケーションが認証を必要とするだけであるなら、しばしば暗号化、認証がある超能力はAHより良いオプションです、超能力がmiddleboxesの向こう側に作動できるので。 IPsecを使用するアプリケーションはIPsecがプロトコル群であると実装するオペレーティングシステムのサポートを必要とします。
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 of securing UDP communications is through Datagram Transport Layer Security (DTLS) [RFC4347]. 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.
UDPにコミュニケーションを保証するのにIPsecを使用するのが可能ですが、すべてのオペレーティングシステムが、IPsecをサポートするというわけではありませんし、またアプリケーションがそれらの流れのために容易にそれを構成するのを許容するというわけではありません。 データグラムTransport Layer Security(DTLS)[RFC4347]を通してUDPにコミュニケーションを保証する2番目のオプションがあります。 DTLSは、UDPペイロードを暗号化することによって、コミュニケーションプライバシーを提供します。 それはUDPヘッダーを保護しません。 オペレーティングシステムからサポートに依存しないで、アプリケーションはDTLSを実装することができます。
Eggert & Fairhurst Best Current Practice [Page 19] RFC 5405 Unicast UDP Usage Guidelines November 2008
エッゲルトとFairhurstの最も良い海流はユニキャストUDP用法ガイドライン2008年11月にRFC5405を練習します[19ページ]。
Many other options for authenticating or encrypting UDP payloads exist. For example, the GSS-API security framework [RFC2743] or Cryptographic Message Syntax (CMS) [RFC3852] could be used to protect UDP payloads. The IETF standard for securing RTP [RFC3550] communication sessions over UDP is the Secure Real-time Transport Protocol (SRTP) [RFC3711]. 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 [RFC3852], S/MIME [RFC3851] or OpenPGP [RFC4880] could be used. In addition, there are many non-IETF protocols in this area.
UDPペイロードを認証するか、または暗号化するための多くの別の選択肢が存在しています。 例えば、UDPペイロードを保護するのに、GSS-APIセキュリティフレームワーク[RFC2743]かCryptographic Message Syntax(CMS)[RFC3852]を使用できました。 RTP[RFC3550]にUDPの上のコミュニケーションセッションを保証するIETF規格はSecureレアル-時間Transportプロトコル(SRTP)[RFC3711]です。 使用目的によっては、より良いソリューションは、より大きいスタンドアロンのオブジェクトを保護することです、ファイルやメッセージのように、個々のUDPペイロードの代わりに。 これらの状況で、CMS[RFC3852]、S/MIME[RFC3851]または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などのよく知られる標準のセキュリティー対策を使うのは、RECOMMENDEDです。
The Generalized TTL Security Mechanism (GTSM) [RFC5082] may be used with UDP applications (especially when the intended endpoint is on the same link as the sender). This is a lightweight mechanism that 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. 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]はインターネットへの混雑無反応流れという危険について議論します。 このドキュメントは、彼らのトランスミッションを混雑していて制御するためにUDPベースのアプリケーションのデザイナーにガイドラインを提供して、少しの追加担保関心も高めません。
5. Summary
5. 概要
This section summarizes the guidelines made in Sections 3 and 4 in a tabular format (Table 1) for easy referencing.
このセクションは簡単な参照箇所のためにセクション3と4で表の様式(テーブル1)で作られたガイドラインをまとめます。
Eggert & Fairhurst Best Current Practice [Page 20] RFC 5405 Unicast UDP Usage Guidelines November 2008
エッゲルトとFairhurstの最も良い海流はユニキャストUDP用法ガイドライン2008年11月にRFC5405を練習します[20ページ]。
+---------------------------------------------------------+---------+ | Recommendation | Section | +---------------------------------------------------------+---------+ | MUST tolerate a wide range of Internet path conditions | 3 | | SHOULD use a full-featured transport (TCP, SCTP, DCCP) | | | | | | SHOULD control rate of transmission | 3.1 | | SHOULD perform congestion control over all traffic | | | | | | for bulk transfers, | 3.1.1 | | SHOULD consider implementing TFRC | | | else, SHOULD in other ways use bandwidth similar to TCP | | | | | | for non-bulk transfers, | 3.1.2 | | SHOULD measure RTT and transmit max. 1 datagram/RTT | | | else, SHOULD send at most 1 datagram every 3 seconds | | | SHOULD back-off retransmission timers following loss | | | | | | for tunnels carrying IP Traffic, | 3.1.3 | | SHOULD NOT perform congestion control | | | | | | for non-IP tunnels or rate not determined by traffic, | 3.1.3 | | SHOULD perform congestion control | | | | | | SHOULD NOT send datagrams that exceed the PMTU, i.e., | 3.2 | | SHOULD discover PMTU or send datagrams < minimum PMTU | | | | | | 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 | | MUST enable IPv6 UDP checksum | | | else, MAY use UDP-Lite with suitable checksum coverage | 3.4.1 | | | | | SHOULD NOT always send middlebox keep-alives | 3.5 | | MAY use keep-alives when needed (min. interval 15 sec) | | | | | | MUST check IP source address | 3.6 | | and, for client/server applications | | | SHOULD send responses from src address matching request | | | | | | SHOULD use standard IETF security protocols when needed | 4 | +---------------------------------------------------------+---------+
+---------------------------------------------------------+---------+ | 推薦| セクション| +---------------------------------------------------------+---------+ | さまざまなインターネット経路状態を許容しなければなりません。| 3 | | SHOULDは完全装備の輸送(TCP、SCTP、DCCP)を使用します。| | | | | | トランスミッションのSHOULDコントロール率| 3.1 | | SHOULDはすべてのトラフィックの輻輳制御を実行します。| | | | | | バルク転送のために| 3.1.1 | | SHOULDは、TFRCを実装すると考えます。| | | ほかに、他の方法でSHOULDはTCPと同様の帯域幅を使用します。| | | | | | 非バルク転送のために| 3.1.2 | | SHOULDはRTTを測定して、最大1データグラム/RTTを伝えます。| | | ほかに、SHOULDは3秒毎を1個のデータグラムに高々送ります。| | | 損失に続くSHOULD下に後部再送信タイマー| | | | | | IP Trafficを運ぶトンネルに| 3.1.3 | | SHOULD NOTは輻輳制御を実行します。| | | | | | 非IPトンネルかトラフィックによって測定されなかったレートのために| 3.1.3 | | SHOULDは輻輳制御を実行します。| | | | | | SHOULD NOTはすなわちPMTUを超えているデータグラムを送ります。| 3.2 | | SHOULDはPMTUを発見するか、またはデータグラム<最小限PMTUを送ります。| | | | | | SHOULDはデータグラムの損失、複製、再命令を扱います。| 3.3 | | SHOULD、最大2分間の配送遅れに強健にしてください。| | | | | | SHOULDはIPv4 UDPチェックサムを可能にします。| 3.4 | | IPv6 UDPチェックサムを可能にしなければなりません。| | | ほかに、適当なチェックサム適用範囲があるUDP-Liteを使用するかもしれません。| 3.4.1 | | | | | SHOULD NOTはいつもアリフを保ってmiddleboxを送ります。| 3.5 | | 必要であるとアリフを保っている5月の使用(15秒の間隔の間の分)| | | | | | チェックIPはアドレスの出典を明示しなければなりませんか?| 3.6 | | そして、クライアント/サーバ・アプリケーション| | | SHOULDはマッチングが要求するsrcアドレスから応答を送ります。| | | | | | 必要であると、SHOULDは標準のIETFセキュリティプロトコルを使用します。| 4 | +---------------------------------------------------------+---------+
Table 1: Summary of recommendations
テーブル1: 推薦の概要
Eggert & Fairhurst Best Current Practice [Page 21] RFC 5405 Unicast UDP Usage Guidelines November 2008
エッゲルトとFairhurstの最も良い海流はユニキャストUDP用法ガイドライン2008年11月にRFC5405を練習します[21ページ]。
6. Acknowledgments
6. 承認
Thanks to Paul Aitken, Mark Allman, Francois Audet, Iljitsch van Beijnum, Stewart Bryant, Remi Denis-Courmont, Lisa Dusseault, Wesley Eddy, Pasi Eronen, Sally Floyd, Robert Hancock, Jeffrey Hutzelman, Cullen Jennings, Tero Kivinen, Peter Koch, Jukka Manner, Philip Matthews, Joerg Ott, Colin Perkins, Tom Petch, Carlos Pignataro, Pasi Sarolahti, Pascal Thubert, Joe Touch, Dave Ward, and Magnus Westerlund for their comments on this document.
ポール・エイトケンへの感謝、マーク・オールマン、フランソアAudet、Iljitschはこのドキュメントの彼らのコメントのためにBeijnum、スチュワートブライアント、レミデニス-Courmont、リサDusseault、ウエスリーEddy、パシEronen、サリー・フロイド、ロバートハンコック、ジェフリーHutzelman、Cullenジョニングス、Tero Kivinen、ピーター・コッホ、ユッカManner、フィリップ・マシューズ、ヨルク・オット、コリン・パーキンス、トムPetch、カルロスPignataro、パシSarolahti、パスカルThubert、ジョーTouch、デーヴ・ウォード、およびマグヌスWesterlundをバンに積みます。
The middlebox traversal guidelines in Section 3.5 incorporate ideas from Section 5 of [BEHAVE-APP] by Bryan Ford, Pyda Srisuresh, and Dan Kegel.
セクション3.5のmiddlebox縦断ガイドラインはブライアン・フォード、Pyda Srisuresh、およびダン・ケーゲルで[BEHAVE-APP]のセクション5から考えを取り入れます。
Lars Eggert is partly funded by [TRILOGY], a research project supported by the European Commission under its Seventh Framework Program. Gorry Fairhurst was partly funded by the EC SatNEx project.
ラース・エッゲルトは[トリロジー]、Seventh Framework Programの下で欧州委員会によってサポートされた研究計画によって一部資金を供給されます。 ゴーリーFairhurstはEC SatNExプロジェクトによって一部資金を供給されました。
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC0768] ポステル、J.、「ユーザー・データグラム・プロトコル」、STD6、RFC768、1980年8月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC0793] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、R.、「インターネットのためのホスト--コミュニケーションが層にされるという要件」、STD3、RFC1122、10月1989日
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery",
RFC 1191, November 1990.
[RFC1191] ムガール人とJ.とS.デアリング、「経路MTU探索」、RFC1191、1990年11月。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU
Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981] マッキャン、J.、デアリング、S.、およびJ.ムガール人、「IPのための経路MTUディスカバリー、バージョン6インチ、RFC1981、1996インチ年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version
6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
RFC 2914, September 2000.
[RFC2914]フロイド、S.、「輻輳制御プリンシプルズ」、BCP41、RFC2914、2000年9月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's
Retransmission Timer", RFC 2988, November 2000.
[RFC2988] パクソンとV.とM.オールマン、「コンピューティングTCPの再送信タイマー」、RFC2988、2000年11月。
Eggert & Fairhurst Best Current Practice [Page 22] RFC 5405 Unicast UDP Usage Guidelines November 2008
エッゲルトとFairhurstの最も良い海流はユニキャストUDP用法ガイドライン2008年11月にRFC5405を練習します[22ページ]。
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E.,
and G. Fairhurst, "The Lightweight User Datagram
Protocol (UDP-Lite)", RFC 3828, July 2004.
[RFC3828]Larzon、L-A.、デーゲルマルク、M.、ピンク、S.、イェンソン、L-E.、およびG.Fairhurst、「軽量のユーザー・データグラム・プロトコル(UDP-Lite)」、RFC3828 2004年7月。
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP",
BCP 127, RFC 4787, January 2007.
[RFC4787]Audet(F.とC.ジョニングス)は「ユニキャストUDPのためのアドレス変換(NAT)の行動の要件をネットワークでつなぎます」、BCP127、RFC4787、2007年1月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path
MTU Discovery", RFC 4821, March 2007.
[RFC4821] マシスとM.とJ.ヘフナー、「Packetization層の経路MTU発見」、RFC4821、2007年3月。
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
Friendly Rate Control (TFRC): Protocol Specification",
RFC 5348, September 2008.
[RFC5348] フロイド、S.、ハンドレー、M.、Padhye、J.、およびJ.ウィトマー、「TCPの好意的なレートは(TFRC)を制御します」。 「プロトコル仕様」、RFC5348、2008年9月。
7.2. Informative References
7.2. 有益な参照
[BEHAVE-APP] Ford, B., "Application Design Guidelines for Traversal
through Network Address Translators", Work in Progress,
March 2007.
[装置を反応させている] フォード、B.、「ネットワークアドレス変換機構を通した縦断のためのアプリケーション設計ガイドライン」が進歩、2007年3月に働いています。
[CCID4] Floyd, S. and E. Kohler, "Profile for Datagram
Congestion Control Protocol (DCCP) Congestion ID 4:
TCP-Friendly Rate Control for Small Packets (TFRC-SP)",
Work in Progress, February 2008.
[CCID4] フロイド、S.、およびE.コーラーは「データグラム混雑制御プロトコル(DCCP)混雑ID4のために以下の輪郭を描きます」。 「小型小包(TFRC-SP)のためのTCPに優しい速度制御」、処理中の作業、2008年2月。
[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.
[フェーバー]フェーバー、T.、接触、J.、およびW.Yue、「忙しいサーバへのTCPとその効果における時間待ち状態」、Proc。 1999年3月のIEEE Infocom。
[GIST] Schulzrinne, H. and R. Hancock, "GIST: General Internet
Signalling Transport", Work in Progress, July 2008.
[要点] Schulzrinne、H.、およびR.ハンコック、「要点:」 「一般インターネットは輸送を示し」て、進歩、2008年7月に働いてください。
[ICE] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", Work
in Progress, October 2007.
ローゼンバーグ、[氷]J.、「対話的な接続性設立(氷):」 「申し出/答えプロトコルのためのネットワークアドレス変換機構(NAT)縦断のためのプロトコル」、処理中の作業、2007年10月。
[NSLP] Stiemerling, M., Tschofenig, H., Aoun, C., and E.
Davies, "NAT/Firewall NSIS Signaling Layer Protocol
(NSLP)", Work in Progress, September 2008.
M.、Tschofenig、H.、Aoun、C.、およびE.デイヴィース、「層のプロトコル(NSLP)に合図するNAT/ファイアウォールNSIS」という[NSLP]Stiemerlingは進行中(2008年9月)で働いています。
[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/IEC9945を発行します: 2002、12月2001日。
Eggert & Fairhurst Best Current Practice [Page 23] RFC 5405 Unicast UDP Usage Guidelines November 2008
エッゲルトとFairhurstの最も良い海流はユニキャストUDP用法ガイドライン2008年11月にRFC5405を練習します[23ページ]。
[RFC0896] Nagle, J., "Congestion control in IP/TCP
internetworks", RFC 896, January 1984.
[RFC0896] ネーグル、J.、「IP/TCPインターネットワークにおける輻輳制御」、RFC896、1984年1月。
[RFC0919] Mogul, J., "Broadcasting Internet Datagrams", STD 5,
RFC 919, October 1984.
[RFC0919] ムガール人、J.、「放送インターネットデータグラム」、STD5、RFC919、1984年10月。
[RFC1112] Deering, S., "Host extensions for IP multicasting",
STD 5, RFC 1112, August 1989.
[RFC1112] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、1989年8月。
[RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S.
Miller, "Common DNS Implementation Errors and Suggested
Fixes", RFC 1536, October 1993.
[RFC1536] クマー、A.、ポステル、J.、ヌーマン、C.、ダンツィグ、P.、およびS.ミラー、「一般的なDNS実装誤りの、そして、提案されたフィックス」、RFC1536(1993年10月)。
[RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host
Anycasting Service", RFC 1546, November 1993.
[RFC1546] ヤマウズラとC.とメンデス、T.とW.ミリケン、「ホストAnycastingサービス」、RFC1546、1993年11月。
[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,
April 1998.
[RFC2309] ブレーデン、B.、クラーク、D.、クロウクロフト、J.、デイビー、B.、デアリング、S.、Estrin、D.、フロイド、S.、ジェーコブソン、V.、Minshall、G.、ヤマウズラ、C.、ピーターソン、L.、Ramakrishnan、K.、Shenker、S.、Wroclawski、J.、およびL.チャン、「インターネットの待ち行列管理と輻輳回避の推薦」、RFC2309(1998年4月)。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang,
Z., and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[RFC2475] ブレーク、S.は黒くされます、D.、カールソン、M.、デイヴィース、E.、ワング、Z.とW.ウィス、「差別化されたサービスのためのアーキテクチャ」RFC2475、1998年12月。
[RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6
Jumbograms", RFC 2675, August 1999.
1999年8月の[RFC2675]ボーマンとD.とデアリング、S.とR.Hinden、「IPv6 Jumbograms」RFC2675。
[RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2743] リン、J.、「ジェネリックセキュリティー・サービス適用業務プログラム・インタフェースバージョン2、アップデート1インチ、RFC2743、2000年1月。」
[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, January 2001.
[RFC3048] Whetten、B.、Vicisano、L.、カーモード、R.、ハンドレー、M.、フロイド、S.、およびM.Luby、「多くへの1のための信頼できるマルチキャスト輸送ブロックバルク・データ転送」、RFC3048(2001年1月)。
[RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion
Manager", RFC 3124, June 2001.
[RFC3124]BalakrishnanとH.とS.Seshan、「混雑マネージャ」(RFC3124)2001年6月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G.,
Johnston, A., Peterson, J., Sparks, R., Handley, M.,
and E. Schooler, "SIP: Session Initiation Protocol",
RFC 3261, June 2002.
[RFC3261] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
Eggert & Fairhurst Best Current Practice [Page 24] RFC 5405 Unicast UDP Usage Guidelines November 2008
エッゲルトとFairhurstの最も良い海流はユニキャストUDP用法ガイドライン2008年11月にRFC5405を練習します[24ページ]。
[RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A.,
and A. Rayhan, "Middlebox communication architecture
and framework", RFC 3303, August 2002.
そして、[RFC3303]Srisuresh、P.、Kuthan、J.、ローゼンバーグ、J.、モリトル、A.、A.Rayhanと、「Middlebox通信アーキテクチャとフレームワーク」、RFC3303(2002年8月)
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and
W. Stevens, "Basic Socket Interface Extensions for
IPv6", RFC 3493, February 2003.
[RFC3493] ギリガンとR.とトムソンとS.とバウンドとJ.とマッキャン、J.とW.スティーブンス、「IPv6"、RFC3493、2003年2月のための基本的なソケットインタフェース拡大。」
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、2003年7月。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio
and Video Conferences with Minimal Control", STD 65,
RFC 3551, July 2003.
[RFC3551] Schulzrinne、H.、およびS.Casner、「オーディオのためのRTPプロフィールと最小量があるテレビ会議システムは制御します」、STD65、RFC3551、2003年7月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and
K. Norrman, "The Secure Real-time Transport Protocol
(SRTP)", RFC 3711, March 2004.
[RFC3711] 2004年のBaugher、M.、マグリュー、D.、ジーター、M.、カラーラ、E.、およびK.Norrman、「安全なリアルタイムのトランスポート・プロトコル(SRTP)」、RFC3711行進。
[RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate
Control (WEBRC) Building Block", RFC 3738, April 2004.
Goyal、[RFC3738]Luby、M.、およびRFC3738、2004年4月対「波と方程式のベースの速度制御(WEBRC)ブロック」
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
Conrad, "Stream Control Transmission Protocol (SCTP)
Partial Reliability Extension", RFC 3758, May 2004.
[RFC3758]スチュワート、R.、Ramalho(M.、シェ、Q.、Tuexen、M.、およびP.コンラッド)は「制御伝動のプロトコルの(SCTP)部分的な信頼性の拡大を流します」、RFC3758、2004年5月。
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and
L. Wood, "Advice for Internet Subnetwork Designers",
BCP 89, RFC 3819, July 2004.
[RFC3819]KarnとP.とボルマンとC.とFairhurstとG.とグロースマンとD.とラドウィグとR.とMahdaviとJ.とモンテネグロとG.と接触、J.とL.木、「インターネットサブネットワークデザイナーのためのアドバイス」BCP89、RFC3819(2004年7月)。
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004.
[RFC3851] Ramsdell、B.、「安全な/マルチパーパスインターネットメールエクステンション(S/MIME)バージョン3.1メッセージ仕様」、RFC3851、2004年7月。
[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)",
RFC 3852, July 2004.
[RFC3852] Housley、R.、「暗号のメッセージ構文(cm)」、RFC3852、2004年7月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4301] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、2005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005.
[RFC4302] ケント、S.、「IP認証ヘッダー」、RFC4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4303]ケント、S.、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC4303、2005年12月。
Eggert & Fairhurst Best Current Practice [Page 25] RFC 5405 Unicast UDP Usage Guidelines November 2008
エッゲルトとFairhurstの最も良い海流はユニキャストUDP用法ガイドライン2008年11月にRFC5405を練習します[25ページ]。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[RFC4306] コーフマン、C.、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、2005年12月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340,
March 2006.
[RFC4340] コーラー、E.、ハンドレー、M.、およびS.フロイド、「データグラム混雑制御プロトコル(DCCP)」、RFC4340、2006年3月。
[RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram
Congestion Control Protocol (DCCP) Congestion Control
ID 2: TCP-like Congestion Control", RFC 4341,
March 2006.
[RFC4341] フロイド、S.、およびE.コーラーは「データグラム混雑制御プロトコル(DCCP)輻輳制御ID2のために以下の輪郭を描きます」。 「TCPのような輻輳制御」、RFC4341、2006年3月。
[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, March 2006.
[RFC4342] フロイド、S.、コーラー、E.、およびJ.Padhyeは「データグラム混雑制御プロトコル(DCCP)輻輳制御ID3のために以下の輪郭を描きます」。 「TCPに優しい速度制御(TFRC)」、2006年3月のRFC4342。
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006.
[RFC4347] レスコラとE.とN.Modadugu、「データグラムトランスポート層セキュリティ」、RFC4347、2006年4月。
[RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast
Congestion Control (TFMCC): Protocol Specification",
RFC 4654, August 2006.
[RFC4654] ウィトマー、J.、およびM.ハンドレー、「TCPに優しいマルチキャスト混雑は(TFMCC)を制御します」。 「プロトコル仕様」、RFC4654、2006年8月。
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and
R. Thayer, "OpenPGP Message Format", RFC 4880,
November 2007.
[RFC4880] カラスとJ.とDonnerhackeとL.とフィニーとH.とショー、D.とR.セイヤー、「OpenPGPメッセージ・フォーマット」、RFC4880、2007年11月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007.
[RFC4960] スチュワート、R.、「ストリーム制御伝動プロトコル」、RFC4960、2007年9月。
[RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4
Reassembly Errors at High Data Rates", RFC 4963,
July 2007.
2007年7月の[RFC4963]ヘフナーとJ.とマシス、M.とB.ろうそく屋、「高いデータ信号速度におけるIPv4 Reassembly誤り」RFC4963。
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common
Mitigations", RFC 4987, August 2007.
[RFC4987] 渦巻、W.、「攻撃と一般的な緩和をあふれさせるTCP SYN」、RFC4987、2007年8月。
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C.
Pignataro, "The Generalized TTL Security Mechanism
(GTSM)", RFC 5082, October 2007.
[RFC5082]エラ、V.、Heasley、J.、マイヤー、D.、Savola、P.、およびC.Pignataro、「一般化されたTTLセキュリティー対策(GTSM)」、RFC5082 2007年10月。
[STEVENS] Stevens, W., Fenner, B., and A. Rudoff, "UNIX Network
Programming, The sockets Networking API", Addison-
Wesley, 2004.
[スティーブンス]スティーブンスとW.とフェナー、B.とA.Rudoff、「UNIX Network Programming、ソケットNetworking API」アディソンウエスリー、2004。
[TRILOGY] "Trilogy Project", <http://www.trilogy-project.org>.
「トリロジーは映し出す」[トリロジー]、<http://www.trilogy-project.org>。
Eggert & Fairhurst Best Current Practice [Page 26] RFC 5405 Unicast UDP Usage Guidelines November 2008
エッゲルトとFairhurstの最も良い海流はユニキャストUDP用法ガイドライン2008年11月にRFC5405を練習します[26ページ]。
[UPnP] UPnP Forum, "Internet Gateway Device (IGD) Standardized
Device Control Protocol V 1.0", November 2001.
[UPnP]UPnPフォーラム、「デバイス制御プロトコルV1インチと、2001年11月に標準化されたインターネットゲートウェイデバイス(IGD)。」
Authors' Addresses
作者のアドレス
Lars Eggert Nokia Research Center P.O. Box 407 Nokia Group 00045 Finland
ラースエッゲルトノキアリサーチセンター私書箱407Nokia Group00045フィンランド
Phone: +358 50 48 24461 EMail: lars.eggert@nokia.com URI: http://people.nokia.net/~lars/
以下に電話をしてください。 +358 50 48 24461はメールされます: lars.eggert@nokia.com ユリ: http://people.nokia.net/~lars/
Godred Fairhurst University of Aberdeen Department of Engineering Fraser Noble Building Aberdeen AB24 3UE Scotland
アバディーン工学部フレーザ・素晴らしい建築物アバディーンAB24 3UEスコットランドのGodred Fairhurst大学
EMail: gorry@erg.abdn.ac.uk URI: http://www.erg.abdn.ac.uk/
メール: gorry@erg.abdn.ac.uk ユリ: http://www.erg.abdn.ac.uk/
Eggert & Fairhurst Best Current Practice [Page 27]
エッゲルトとFairhurstの最も良い現在の習慣[27ページ]
一覧
スポンサーリンク
