Network Working Group L. Eggert
Request for Comments: 5482 Nokia
Category: Standards Track F. Gont
UTN/FRH
March 2009
TCP User Timeout Option
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Abstract
抽象
The TCP user timeout controls how long transmitted data may remain unacknowledged before a connection is forcefully closed. It is a local, per-connection parameter. This document specifies a new TCP option -- the TCP User Timeout Option -- that allows one end of a TCP connection to advertise its current user timeout value. This information provides advice to the other end of the TCP connection to adapt its user timeout accordingly. Increasing the user timeouts on both ends of a TCP connection allows it to survive extended periods without end-to-end connectivity. Decreasing the user timeouts allows busy servers to explicitly notify their clients that they will maintain the connection state only for a short time without connectivity.
TCPユーザのタイムアウトを制御し、接続が強制的に閉鎖される前に、どのくらい送信されたデータは未確認残ることがあります。これは、ローカル、接続ごとのパラメータです。 TCPユーザのタイムアウトオプション - - 現在のユーザのタイムアウト値をアドバタイズするTCPコネクションの一方の端を可能にこの文書は、新しいTCPオプションを指定します。この情報は、それに応じて、ユーザタイムアウトを適合させるために、TCP接続のもう一方の端にアドバイスを提供します。 TCP接続の両端に、ユーザのタイムアウトを増やすと、それはエンド・ツー・エンドの接続せずに長期間生き残ることができます。ユーザーのタイムアウトを小さくすると、ビジー状態のサーバが明示的に、彼らは接続せずに短時間しか接続状態を維持することを顧客に通知することができます。
Table of Contents
目次
1. Introduction ....................................................2
2. Conventions .....................................................3
3. Operation .......................................................4
3.1. Changing the Local User Timeout ............................5
3.2. UTO Option Reliability .....................................8
3.3. Option Format ..............................................8
3.4. Reserved Option Values .....................................9
4. Interoperability Issues .........................................9
4.1. Middleboxes ................................................9
4.2. TCP Keep-Alives ...........................................10
5. Programming and Manageability Considerations ...................10
6. Security Considerations ........................................10
7. IANA Considerations ............................................12
8. Acknowledgments ................................................12
9. References .....................................................12
9.1. Normative References ......................................12
9.2. Informative References ....................................13
The Transmission Control Protocol (TCP) specification [RFC0793] defines a local, per-connection "user timeout" parameter that specifies the maximum amount of time that transmitted data may remain unacknowledged before TCP will forcefully close the corresponding connection. Applications can set and change this parameter with OPEN and SEND calls. If an end-to-end connectivity disruption lasts longer than the user timeout, a sender will receive no acknowledgments for any transmission attempt, including keep-alives, and it will close the TCP connection when the user timeout occurs.
伝送制御プロトコル（TCP）仕様[RFC0793]はTCPが強制的に対応する接続をクローズする前のデータが未確認のままであってもよい送信時間の最大量を指定ローカル、接続ごとの「ユーザタイムアウト」パラメータを定義します。アプリケーションは、設定および変更するには、このパラメータをOPENにし、通話を送ることができます。エンドツーエンド接続の中断が長く、ユーザのタイムアウト以上続く場合は、送信者は、キープアライブを含む、任意の送信試行のために何の確認応答を受信しないと、ユーザーのタイムアウトが発生した場合には、TCP接続を閉じます。
This document specifies a new TCP option -- the TCP User Timeout Option (UTO) -- that allows one end of a TCP connection to advertise its current user timeout value. This information provides advice to the other end of the connection to adapt its user timeout accordingly. That is, TCP remains free to disregard the advice provided by the UTO option if local policies suggest it to be appropriate.
TCPユーザのタイムアウト・オプション（UTO） - - TCPコネクションの一端が、現在のユーザのタイムアウト値を宣伝することができます。この文書は、新しいTCPオプションを指定します。この情報は、それに応じて、ユーザタイムアウトを適応させるため、接続のもう一方の端にアドバイスを提供します。これは、TCPがローカルポリシーは、それが適切であることを示唆場合UTOオプションが提供するアドバイスを無視して自由のまま、です。
Increasing the user timeouts on both ends of a TCP connection allows it to survive extended periods without end-to-end connectivity. Decreasing the user timeouts allows busy servers to explicitly notify their clients that they will maintain the connection state only for a short time without connectivity.
TCP接続の両端に、ユーザのタイムアウトを増やすと、それはエンド・ツー・エンドの接続せずに長期間生き残ることができます。ユーザーのタイムアウトを小さくすると、ビジー状態のサーバが明示的に、彼らは接続せずに短時間しか接続状態を維持することを顧客に通知することができます。
In the absence of an application-specified user timeout, the TCP specification [RFC0793] defines a default user timeout of 5 minutes. The Host Requirements RFC [RFC1122] refines this definition by introducing two thresholds, R1 and R2 (R2 > R1), that control the number of retransmission attempts for a single segment. It suggests that TCP should notify applications when R1 is reached for a segment, and close the connection when R2 is reached. [RFC1122] also defines the recommended values for R1 (3 retransmissions) and R2 (100 seconds), noting that R2 for SYN segments should be at least 3 minutes. Instead of a single user timeout, some TCP implementations offer finer-grained policies. For example, Solaris supports different timeouts depending on whether a TCP connection is in the SYN-SENT, SYN-RECEIVED, or ESTABLISHED state [SOLARIS].
アプリケーションが指定したユーザのタイムアウトの非存在下で、TCP仕様[RFC0793]は、5分のデフォルトのユーザのタイムアウトを定義します。ホスト要件RFC [RFC1122]は、単一セグメントの再送信試行回数を制御する2つの閾値、R1及びR2（R2> R1）を導入することによって、この定義を洗練します。これは、TCP R1はセグメントに達したときにアプリケーションに通知し、そしてR2に達したときに接続を閉じるべきであることを示唆しています。 [RFC1122]もR2 SYN用セグメントは少なくとも3分であるべきであることに留意、R1（3つの再送）及びR2（100秒）の推奨値を定義します。代わりに、単一のユーザー・タイムアウトのため、いくつかのTCP実装は、よりきめ細かいポリシーを提供します。たとえば、Solarisは、[SOLARIS] TCP接続がSYN-SENT、SYN-RECEIVED、または確立された状態であるか否かに応じて、異なるタイムアウトをサポートします。
Although some TCP implementations allow applications to set their local user timeout, TCP has no in-protocol mechanism to signal changes to the local user timeout to the other end of a connection. This causes local changes to be ineffective in allowing a connection to survive extended periods without connectivity, because the other end will still close the connection after its user timeout expires.
いくつかのTCP実装は、アプリケーションがローカルユーザータイムアウトを設定することを可能にするが、TCPは、接続の他端にローカルユーザーのタイムアウトの変更を通知するためのNo-プロトコル機構を有していません。これは、そのユーザのタイムアウトの有効期限が切れた後にもう一方の端はまだ接続を閉じますので、接続は接続せずに長期間生き残るためにできるようには効果がないことが地域の変化を引き起こします。
The ability to inform the other end of a connection about the local user timeout can improve TCP operation in scenarios that are currently not well supported. One example of such a scenario is mobile hosts that change network attachment points. Such hosts, maybe using Mobile IP [RFC3344], HIP [RFC4423], or transport-layer mobility mechanisms [TCP_MOB], are only intermittently connected to the Internet. In between connected periods, mobile hosts may experience periods without end-to-end connectivity. Other factors that can cause transient connectivity disruptions are high levels of congestion or link or routing failures inside the network. In these scenarios, a host may not know exactly when or for how long connectivity disruptions will occur, but it might be able to determine an increased likelihood for such events based on past mobility patterns and thus benefit from using longer user timeouts. In other scenarios, the time and duration of a connectivity disruption may even be predictable. For example, a node in space might experience connectivity disruptions due to line-of-sight blocking by planetary bodies. The timing of these events may be computable from orbital mechanics.
ローカルユーザのタイムアウトについての接続のもう一方の端を通知する機能は現在もサポートされていないシナリオでTCPの動作を改善することができます。そのようなシナリオの一例は、ネットワーク接続点を変更するモバイルホストです。多分、モバイルIP [RFC3344]、HIP [RFC4423]、またはトランスポート層のモビリティ・メカニズムを使用してこのようなホストは、[TCP_MOB]、断続的にしかインターネットに接続されています。接続された期間の間に、モバイルホストはエンドツーエンド接続せずに期間を経験するかもしれません。過渡的な接続の中断を引き起こす可能性がありますその他の要因には、ネットワーク内の輻輳やリンクまたはルーティング障害の高レベルです。これらのシナリオでは、ホストは、正確にいつまたは接続の中断が発生しますどのくらいのために知らないかもしれないが、過去の移動パターンに基づいて、このようなイベントのための可能性の増大を決定するため、長いユーザータイムアウトを使用して恩恵を受けることができるかもしれません。他のシナリオでは、接続の中断の時間および期間も予測可能であってもよいです。例えば、空間内のノードは、遊星体による視線ブロッキングによる接続中断を経験するかもしれません。これらのイベントのタイミングは、軌道力学から計算してもよいです。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
Use of the TCP User Timeout Option can be either enabled on a per-connection basis, e.g., through an API option, or controlled by a system-wide setting. TCP maintains four per-connection state variables to control the operation of the UTO option, three of which (ADV_UTO, ENABLED, and CHANGEABLE) are new:
TCPユーザタイムアウトオプションを使用すると、いずれかのAPIオプションを使用して、例えば、接続ごとに有効、またはシステム全体の設定によって制御することができます。 TCPは、UTOオプションの動作を制御するために4ごとの接続状態変数を維持そのうち3つの（ADV_UTO、ENABLED、およびCHANGEABLE）新たに追加されました。
USER_TIMEOUT TCP's USER TIMEOUT parameter, as specified in [RFC0793].
USER_TIMEOUT TCPのユーザのタイムアウトパラメータ、[RFC0793]で指定されています。
ADV_UTO UTO option advertised to the remote TCP peer. This is an application-specified value, and may be specified on a system-wide basis. If unspecified, it defaults to the default system-wide USER TIMEOUT.
リモートTCPピアにアドバタイズADV_UTO UTOオプション。これは、アプリケーションが指定した値であり、システム全体に基づいて指定することができます。デフォルトのシステム全体のユーザのタイムアウトに指定しない場合、それがデフォルトになります。
ENABLED (Boolean) Flag that controls whether the UTO option is enabled for a connection. This flag applies to both sending and receiving. Defaults to false.
UTOオプションは、接続のために有効になっているかどうかを制御ENABLED（ブール値）旗。このフラグは、送信と受信の両方に適用されます。デフォルトはfalse。
CHANGEABLE (Boolean) Flag that controls whether USER_TIMEOUT (TCP's USER TIMEOUT parameter) may be changed based on an UTO option received from the other end of the connection. Defaults to true and becomes false when an application explicitly sets USER_TIMEOUT.
USER_TIMEOUT（TCPのユーザのタイムアウトパラメータ）UTOオプションに基づいて変更することができるかどうかを制御CHANGEABLE（ブール）フラグは、接続のもう一方の端から受け取りました。デフォルトはtrueですし、アプリケーションが明示的USER_TIMEOUTを設定する場合はfalseになります。
Note that an exchange of UTO options between both ends of a connection is not a binding negotiation. Transmission of a UTO option is a suggestion that the other end consider adapting its user timeout. This adaptation only happens if the other end of the connection has explicitly allowed it (both ENABLED and CHANGEABLE are true).
接続の両端のUTOオプションの交換結合ネゴシエーションではないことに留意されたいです。 UTOオプションの送信は、もう一方の端は、そのユーザのタイムアウトを適応検討する提案です。接続のもう一方の端を明示的に（両方が有効になっており、CHANGEABLEが真である）、それを許可している場合は、この適応にのみ発生します。
Before opening a connection, an application that wishes to use the UTO option enables its use by setting ENABLED to true. It may choose an appropriate local UTO by explicitly setting ADV_UTO; otherwise, UTO is set to the default USER TIMEOUT value. Finally, the application should determine whether it will allow the local USER TIMEOUT to change based on received UTO options from the other end of a connection. The default is to allow this for connections that do not have specific user timeout concerns. If an application explicitly sets the USER_TIMEOUT, CHANGEABLE MUST become false in order to prevent UTO options (from the other end) from overriding local application requests. Alternatively, applications can set or clear CHANGEABLE directly through API calls.
接続を開く前に、UTOオプションを使用したいアプリケーションがtrueにENABLED設定することで、その使用を可能にします。これは、明示的にADV_UTOを設定することにより、適切なローカルUTOを選択することができます。それ以外の場合は、UTOは、デフォルトのユーザのタイムアウト値に設定されています。最後に、アプリケーションは、ローカルユーザのタイムアウトは、接続のもう一方の端から受信UTOオプションに基づいて変更することができますかどうかを判断する必要があります。デフォルトでは、特定のユーザーのタイムアウトの懸念を持っていない接続のためにこれを可能にすることです。アプリケーションが明示的USER_TIMEOUTを設定した場合、CHANGEABLEは、ローカルアプリケーション要求をオーバーライドから（もう一方の端から）UTOオプションを防ぐために偽にならなければなりません。また、アプリケーションはAPI呼び出しを介して直接設定またはクリアCHANGEABLEことができます。
Performing these steps before an active or passive open causes UTO options to be exchanged in the SYN and SYN-ACK packets and is a reliable way to initially exchange, and potentially adapt to, UTO values. TCP implementations MAY provide system-wide default settings for the ENABLED, ADV_UTO and CHANGEABLE connection parameters.
アクティブまたはパッシブオープンがUTOオプションはSYNおよびSYN-ACKパケットに交換されるようにすると、最初に交換し、そして潜在的にUTO値、に適応する信頼性の高い方法である前に、これらのステップを実行します。 TCP実装はENABLED、ADV_UTOとCHANGEABLE接続パラメータのためのシステム全体のデフォルト設定を提供することができます。
In addition to exchanging UTO options in the SYN segments, a connection that has enabled UTO options SHOULD include a UTO option in the first packet that does not have the SYN flag set. This helps to minimize the amount of state information TCP must keep for connections in non-synchronized states. Also, it is particularly useful when mechanisms such as "SYN cookies" [RFC4987] are implemented, allowing a newly-established TCP connection to benefit from the information advertised by the UTO option, even if the UTO contained in the initial SYN segment was not recorded.
SYNセグメントにUTOオプションを交換することに加えて、UTOオプションを有効にしている接続は、SYNフラグが設定されていない最初のパケットでUTOオプションを含めるべきです。これは、TCPが非同期状態での接続のために維持しなければならない状態情報の量を最小限に抑えることができます。そのような「SYNクッキー」[RFC4987]などのメカニズムは、初期SYNセグメントに含まUTOがなかった場合でも、UTOオプションによって通知情報から利益を新たに確立されたTCP接続を可能に実装されている場合にも、それは特に有用です記録。
A host that supports the UTO option SHOULD include one in the next possible outgoing segment whenever it starts using a new user timeout for the connection. This allows the other end of the connection to adapt its local user timeout accordingly. A TCP implementation that does not support the UTO option MUST silently ignore it [RFC1122], thus ensuring interoperability.
それは、接続のための新しいユーザー・タイムアウトを使用して起動するたびにUTOオプションをサポートするホストは、次の可能性の発信セグメントにおける1を含むべきです。これは、それに応じて、ローカルユーザのタイムアウトを適応させるため、接続のもう一方の端を可能にします。 UTOオプションをサポートしていないTCPの実装は黙っための相互運用性を確保し、[RFC1122]を、それを無視しなければなりません。
Hosts MUST impose upper and lower limits on the user timeouts they use for a connection. Section 3.1 discusses user timeout limits and potentially problematic effects of some user timeout settings.
ホストは、接続に使用するユーザタイムアウトに上限と下限を課すしなければなりません。 3.1節では、ユーザのタイムアウト制限や一部のユーザータイムアウト設定の潜在的な問題の影響について説明します。
Finally, it is worth noting that TCP's option space is limited to 40 bytes. As a result, if other TCP options are in use, they may already consume all the available TCP option space, thus preventing the use of the UTO option specified in this document. Therefore, TCP option space issues should be considered before enabling the UTO option.
最後に、TCPのオプション空間が40バイトに制限されていることは注目に値します。他のTCPオプションが使用されている場合はその結果、彼らはすでにので、この文書で指定されたUTOオプションの使用を防止し、使用可能なすべてのTCPオプションのスペースを消費する可能性があります。そのため、TCPオプション空間の問題は、UTOオプションを有効にする前に考慮すべきです。
When a host receives a TCP User Timeout Option, it must decide whether to change the local user timeout of the corresponding connection. If the CHANGEABLE flag is false, USER_TIMEOUT MUST NOT be changed, regardless of the received UTO option. Without this restriction, the UTO option would modify TCP semantics, because an application-requested USER TIMEOUT could be overridden by peer requests. In this case TCP SHOULD, however, notify the application about the user timeout value received from the other end system.
ホストがTCPユーザタイムアウトオプションを受け取ると、対応する接続のローカルユーザのタイムアウトを変更するかどうかを決定する必要があります。 CHANGEABLEフラグがfalseの場合、USER_TIMEOUTは関係なく、受信UTOオプションの、変更してはいけません。アプリケーションが要求したユーザのタイムアウトがピア要求によって上書きされる可能性があるため、この制限がなければ、UTOオプションは、TCPのセマンティクスを変更します。この場合、TCPは、しかし、他のエンド・システムから受信したユーザのタイムアウト値についてアプリケーションに通知すべきです。
In general, unless the application on the local host has requested a specific USER TIMEOUT for the connection, CHANGEABLE will be true and hosts SHOULD adjust the local TCP USER TIMEOUT (USER_TIMEOUT) in response to receiving a UTO option, as described in the remainder of this section.
ローカルホスト上のアプリケーションは、接続のための特定のユーザのタイムアウトを要求していない限り、一般的に、CHANGEABLEは真となり、の残りの部分に記載されているように、ホストは、UTOオプションを受信したことに応答して、ローカルTCPユーザTIMEOUT（USER_TIMEOUT）を調整する必要がありこのセクション。
The UTO option specifies the user timeout in seconds or minutes, rather than in number of retransmissions or round-trip times (RTTs). Thus, the UTO option allows hosts to exchange user timeout values from 1 second to over 9 hours at a granularity of seconds, and from 1 minute to over 22 days at a granularity of minutes.
UTOオプションではなく、再送信または往復時間（RTTの）の数に比べて、数秒から数分で、ユーザのタイムアウトを指定します。したがって、UTOオプションは分の単位で秒の粒度で9時間以上に、1分〜22日以上1秒からExchangeユーザーのタイムアウト値にホストを可能にします。
Very short USER TIMEOUT values can affect TCP transmissions over high-delay paths. If the user timeout occurs before an acknowledgment for an outstanding segment arrives, possibly due to packet loss, the connection closes. Many TCP implementations default to USER TIMEOUT values of a few minutes. Although the UTO option allows suggestion of short timeouts, applications advertising them should consider these effects.
非常に短いユーザのタイムアウト値は、高遅延パス上のTCP伝送に影響を与えることができます。優れたセグメントの確認応答がおそらくパケット損失に、到着する前に、ユーザーのタイムアウトが発生した場合、接続が閉じられます。多くのTCP実装数分のユーザのタイムアウト値にデフォルト。 UTOオプションは、短いタイムアウトの提案が許可されていますが、それらを広告するアプリケーションは、これらの影響を考慮する必要があります。
Long USER TIMEOUT values allow hosts to tolerate extended periods without end-to-end connectivity. However, they also require hosts to maintain the TCP state information associated with connections for long periods of time. Section 6 discusses the security implications of long timeout values.
長いユーザのタイムアウト値は、ホストがエンドツーエンド接続なしで長期間を耐えることを可能にします。しかし、彼らはまた、長時間の接続に関連付けられているTCP状態情報を維持するためにホストを必要としています。第6節は、長いタイムアウト値のセキュリティへの影響について説明します。
To protect against these effects, implementations MUST impose limits on the user timeout values they accept and use. The remainder of this section describes a RECOMMENDED scheme to limit TCP's USER TIMEOUT based on upper and lower limits.
これらの影響から保護するために、実装は、彼らが受け入れ、使用するユーザーのタイムアウト値に制限を課す必要があります。このセクションの残りの部分は、上限値と下限値に基づいてTCPのユーザタイムアウトを制限することが推奨方式が記載されています。
Under the RECOMMENDED scheme, and when CHANGEABLE is true, each end SHOULD compute the local USER TIMEOUT for a connection according to this formula:
推奨スキームの下で、及びCHANGEABLEが真である場合、各端部は、この式によると接続するためのローカルユーザタイムアウトを計算する必要があります。
USER_TIMEOUT = min(U_LIMIT, max(ADV_UTO, REMOTE_UTO, L_LIMIT))
USER_TIMEOUT =分（U_LIMIT、最大（ADV_UTO、REMOTE_UTO、L_LIMIT））
Each field is to be interpreted as follows:
各フィールドは、次のように解釈されるべきです。
USER_TIMEOUT USER TIMEOUT value to be adopted by the local TCP for this connection.
USER_TIMEOUTユーザのタイムアウト値は、この接続のローカルTCPによって採択されます。
U_LIMIT Current upper limit imposed on the user timeout of a connection by the local host.
ローカルホストによる接続のユーザタイムアウトに課さU_LIMIT電流上限。
ADV_UTO User timeout advertised to the remote TCP peer in a TCP User Timeout Option.
TCPユーザのタイムアウト・オプションでリモートのTCPピアにアドバタイズADV_UTOユーザーのタイムアウト。
REMOTE_UTO Last user timeout value received from the other end in a TCP User Timeout Option.
TCPユーザのタイムアウト・オプションでもう一方の端から受信REMOTE_UTO最終ユーザのタイムアウト値。
L_LIMIT Current lower limit imposed on the user timeout of a connection by the local host.
ローカルホストによる接続のユーザタイムアウトに課さL_LIMIT電流下限。
The RECOMMENDED formula results in the maximum of the two advertised values, adjusted for the configured upper and lower limits, to be adopted for the user timeout of the connection on both ends. The rationale is that choosing the maximum of the two values will let the connection survive longer periods without end-to-end connectivity. If the end that announced the lower of the two user timeout values did so in order to reduce the amount of TCP state information that must be kept on the host, it can close or abort the connection whenever it wants.
2つのアドバタイズされた値の最大値で推奨数式の結果は、両端の接続のユーザのタイムアウトのために採用されるように構成された上限と下限のために調整しました。根拠は、2つの値の最大値を選択すると、接続はエンドツーエンドの接続せずに長い期間を存続できるようになるということです。 2つのユーザのタイムアウト値の下限を発表し、エンドホスト上に維持されなければならないTCP状態情報の量を減らすために、そのようにした場合、それは望んでいる時はいつでも接続を終了または中止することができます。
It must be noted that the two endpoints of the connection will not necessarily adopt the same user timeout.
接続の2つのエンドポイントは、必ずしも同じユーザのタイムアウトを採用しないことに注意しなければなりません。
Enforcing a lower limit (L_LIMIT) prevents connections from closing due to transient network conditions, including temporary congestion, mobility hand-offs, and routing instabilities.
下限（L_LIMIT）を強制することは、一時的な輻輳、モビリティ・ハンドオフ、およびルーティングの不安定性を含む一時的なネットワーク条件に閉鎖からの接続を防止します。
An upper limit (U_LIMIT) can reduce the effect of resource exhaustion attacks. Section 6 discusses the details of these attacks.
上限（U_LIMIT）は、リソースの枯渇攻撃の影響を軽減することができます。第6節は、これらの攻撃の詳細を説明します。
Note that these limits MAY be specified as system-wide constants or at other granularities, such as on per-host, per-user, per-outgoing-interface, or even per-connection basis. Furthermore, these limits need not be static. For example, they MAY be a function of system resource utilization or attack status and could be dynamically adapted.
これらの制限は、システム全体の定数として、またはそのようなホストごと、ユーザごと、毎発信インターフェース、またはさらに接続ごとになど、他の粒度、で指定されてもよいことに留意されたいです。さらに、これらの制限は、静的である必要はありません。例えば、彼らは、システムリソースの使用率や攻撃状況の関数であってもよいし、動的に適合させることができます。
The Host Requirements RFC [RFC1122] does not impose any limits on the length of the user timeout. However, it recommends a time interval of at least 100 seconds. Consequently, the lower limit (L_LIMIT) SHOULD be set to at least 100 seconds when following the RECOMMENDED scheme described in this section. Adopting a user timeout smaller than the current retransmission timeout (RTO) for the connection would likely cause the connection to be aborted unnecessarily. Therefore, the lower limit (L_LIMIT) MUST be larger than the current retransmission timeout (RTO) for the connection. It is worth noting that an upper limit may be imposed on the RTO, provided it is at least 60 seconds [RFC2988].
ホスト要件RFC [RFC1122]は、ユーザのタイムアウトの長さの任意の制限を課しません。しかし、それは少なくとも100秒の時間間隔を推奨しています。このセクションで説明推奨スキームを以下の場合結果として、下限（L_LIMIT）は、少なくとも100秒に設定されるべきです。接続のために現在の再送タイムアウト（RTO）よりも小さく、ユーザタイムアウトを採用する可能性の高い接続が不必要に中止されるために引き起こします。したがって、下限（L_LIMIT）は、接続のための現在の再送タイムアウト（RTO）よりも大きくなければなりません。これは、上限はRTOに課されてもよいことは、注目に値することは、少なくとも60秒[RFC2988]提供されます。
The TCP User Timeout Option is an advisory TCP option that does not change processing of subsequent segments. Unlike other TCP options, it need not be exchanged reliably. Consequently, the specification does not define a reliability handshake for UTO option exchanges. When a segment that carries a UTO option is lost, the other end will simply not have the opportunity to update its local USER TIMEOUT.
TCPユーザタイムアウトオプションは、後続のセグメントの処理を変更しない諮問TCPオプションです。他のTCPオプションとは異なり、それは確実に交換する必要はありません。そのため、仕様はUTOオプションの交換のための信頼性のハンドシェイクを定義していません。 UTOオプションを運ぶセグメントが失われた場合は、もう一方の端は、単にそのローカルユーザのタイムアウトを更新する機会がありません。
Implementations MAY implement local mechanisms to improve delivery reliability, such as retransmitting a UTO option when they retransmit a segment that originally carried it, or "attaching" the option to a byte in the stream and retransmitting the option whenever that byte or its ACK are retransmitted.
実装は、そのような彼らはもともとそれを実施したセグメントを再送する際UTOオプションを再送信する、またはストリームにバイトにオプションを「添付」とそのバイトまたはそのACKが再送されるたびオプションを再送するように、配信の信頼性を向上させるために地元のメカニズムを実装してもよい（MAY） 。
It is important to note that although these mechanisms can improve transmission reliability for the UTO option, they do not guarantee delivery (a three-way handshake would be required for this). Consequently, implementations MUST NOT assume that UTO options are transmitted reliably.
これらのメカニズムはUTOオプションの伝送の信頼性を向上させることができますが、彼らは（スリーウェイハンドシェイクは、このために必要とされるであろう）の配信を保証しないことに注意することが重要です。その結果、実装はUTOオプションは確実に伝達されていると仮定してはいけません。
Sending a TCP User Timeout Option informs the other end of the connection of the current local user timeout and suggests that the other end adapt its user timeout accordingly. The user timeout value included in a UTO option contains the ADV_UTO value that is expected to be adopted for the TCP's USER TIMEOUT parameter during the synchronized states of a connection (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, or LAST-ACK). Connections in other states MUST use the default timeout values defined in [RFC0793] and [RFC1122].
TCPユーザのタイムアウトオプションを送信すると、現在のローカルユーザのタイムアウトの接続のもう一方の端を通知し、もう一方の端はそれに応じてユーザのタイムアウトを適応させることを示唆しています。 UTOオプションに含まれるユーザのタイムアウト値は、接続（ESTABLISHED、FIN-WAIT-1、FIN-WAIT-2、CLOSE-WAITの同期状態の間にTCPのユーザのタイムアウトパラメータに採用されることが期待されるADV_UTO値を含みます、CLOSING、またはLAST-ACK）。他の状態での接続は、[RFC0793]及び[RFC1122]で定義されたデフォルトのタイムアウト値を使用しなければなりません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind = 28 | Length = 4 |G| User Timeout |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(One tick mark represents one bit.)
（一目盛りは、1ビットを表します。）
Figure 1: Format of the TCP User Timeout Option
図1：TCPユーザのタイムアウト・オプションのフォーマット
Figure 1 shows the format of the TCP User Timeout Option. It contains these fields:
図1は、TCPユーザのタイムアウト・オプションのフォーマットを示しています。これは、これらのフィールドが含まれています。
Kind (8 bits) This MUST be 28, i.e., the TCP option number [RFC0793] that has been assigned by IANA (see Section 7).
種類（8ビット）は28、IANAによって割り当てられた、すなわち、TCPオプション番号[RFC0793]（セクション7を参照）でなければなりません。
Length (8 bits) Length of the TCP option in octets [RFC0793]; its value MUST be 4.
オクテット[RFC0793]でTCPオプションの長さ（8ビット）の長さ;その値は4でなければなりません。
Granularity (1 bit) Granularity bit, indicating the granularity of the "User Timeout" field. When set (G = 1), the time interval in the "User Timeout" field MUST be interpreted as minutes. Otherwise (G = 0), the time interval in the "User Timeout" field MUST be interpreted as seconds.
粒度（1ビット）粒度ビット、「ユーザタイムアウト」フィールドの粒度を示します。 （G = 1）に設定した場合、「ユーザタイムアウト」フィールドの時間間隔は、数分と解釈されなければなりません。そうでない場合（G = 0）、「ユーザタイムアウト」フィールドの時間間隔は、秒と解釈されなければなりません。
User Timeout (15 bits) Specifies the user timeout suggestion for this connection. It MUST be interpreted as a 15-bit unsigned integer. The granularity of the timeout (minutes or seconds) depends on the "G" field.
ユーザーのタイムアウト（15ビット）は、この接続のためのユーザのタイムアウトの提案を指定します。これは、15ビットの符号なし整数として解釈されなければなりません。タイムアウト（分または秒）の粒度は、「G」フィールドに依存します。
A TCP User Timeout Option with a "User Timeout" field of zero and a "Granularity" bit of either minutes (1) or seconds (0) is reserved for future use. Current TCP implementations MUST NOT send it and MUST ignore it upon reception.
ゼロの「ユーザのタイムアウト」フィールドと（0）は、将来の使用のために予約されるか分（1）または秒の「粒度」ビットとのTCPユーザのタイムアウトオプション。現在のTCP実装は、それを送ってはいけませんし、受信時に、それを無視しなければなりません。
This section discusses interoperability issues related to introducing the TCP User Timeout Option.
このセクションでは、TCPユーザのタイムアウト・オプションの導入に関連した相互運用性の問題について説明します。
A TCP implementation that does not support the TCP User Timeout Option MUST silently ignore it [RFC1122], thus ensuring interoperability. In a study of the effects of middleboxes on transport protocols, Medina et al. have shown that the vast majority of modern TCP stacks correctly handle unknown TCP options [MEDINA]. In this study, 3% of connections failed when an unknown TCP option appeared in the middle of a connection. Because the number of failures caused by unknown options is small and they are a result of incorrectly implemented TCP stacks that violate existing requirements to ignore unknown options, they do not warrant special measures. Thus, this document does not define a mechanism to negotiate support of the TCP User Timeout Option during the three-way handshake.
TCPユーザのタイムアウト・オプションをサポートしていないTCPの実装は黙っための相互運用性を確保し、[RFC1122]を、それを無視しなければなりません。トランスポートプロトコル、メディナらのミドルボックスの影響の研究では。 [MEDINA]現代のTCPスタックの大半が正しく不明なTCPオプションを扱うことが示されています。不明なTCPオプションは、接続の真ん中に現れたときに、この研究では、接続の3％に失敗しました。未知のオプションによって引き起こされる障害の数が少なく、彼らは未知のオプションを無視し、既存の要件に違反して正しく実装TCPスタックの結果なので、特別な措置を保証するものではありません。したがって、この文書は、3ウェイハンドシェイク中にTCPユーザのタイムアウト・オプションのサポートを交渉するためのメカニズムを定義していません。
Implementations may want to exchange UTO options on the very first data segments after the three-way handshake to determine if such a middlebox exists on the path. When segments carrying UTO options are persistently lost, an implementation should turn off the use of UTO for the connection. When the connection itself is reset, an implementation may be able to transparently re-establish another connection instance that does not use UTO before any application data has been successfully exchanged.
実装は、このようなミドルが経路上に存在するかどうかを決定するためにスリーウェイハンドシェイクの後に非常に最初のデータセグメントにUTOオプションを交換することができます。 UTOオプションを運ぶセグメントが永続的に失われた場合、実装は、接続用のUTOの使用をオフにする必要があります。接続自体がリセットされると、実装は、透過任意のアプリケーションデータが正常に交換された前UTOを使用しない別の接続インスタンスを再確立することができるかもしれません。
Stateful firewalls usually time out connection state after a period of inactivity. If such a firewall exists along the path, it may close or abort connections regardless of the use of the TCP User Timeout Option. In the future, such firewalls may learn to parse the TCP User Timeout Option in unencrypted TCP segments and adapt connection state management accordingly.
ステートフルファイアウォールは、通常、非アクティブの期間後に接続状態をタイムアウト。そのようなファイアウォールがパスに沿って存在している場合、それは関係なく、TCPユーザのタイムアウト・オプションの使用の接続を閉じるか、中止することがあります。将来的には、このようなファイアウォールは暗号化されていないTCPセグメントにおけるTCPユーザのタイムアウト・オプションを解析し、それに応じて、接続状態管理を適応することを学ぶことがあります。
Some TCP implementations, such as those in BSD systems, use a different abort policy for TCP keep-alives than for user data. Thus, the TCP keep-alive mechanism might abort a connection that would otherwise have survived the transient period without connectivity. Therefore, if a connection that enables keep-alives is also using the TCP User Timeout Option, then the keep-alive timer MUST be set to a value larger than that of the adopted USER TIMEOUT.
このようBSDシステムのものなど、一部のTCP実装は、ユーザデータのためのよりTCPキープアライブのためのさまざまなアボートポリシーを使用します。このように、TCPキープアライブメカニズムは、そうでない場合は、接続せずに、過渡期間を生き延びていた接続を中止することがあります。そのため、キープアライブを有効にし、接続もTCPユーザタイムアウトオプションを使用している場合は、キープアライブタイマーを採用しユーザのタイムアウトよりも大きい値に設定しなければなりません。
The IETF specification for TCP [RFC0793] includes a simple, abstract application programming interface (API). Similarly, the API for the UTO extension in Section 3 is kept abstract. TCP implementations, however, usually provide more complex and feature-rich APIs. The "socket" API that originated with BSD Unix and is now standardized by POSIX is one such example [POSIX]. It is expected that TCP implementations that choose to include the UTO extension will extend their API to allow applications to use and configure its parameters.
TCP [RFC0793]のためのIETF仕様は、単純な、抽象アプリケーション・プログラミング・インターフェース（API）を含みます。同様に、第3節でUTO拡張のためのAPIを抽象的に保持されます。 TCP実装は、しかし、通常より複雑かつ機能豊富なAPIを提供しています。 BSD Unixのが起源となりましPOSIXによって標準化された「ソケット」APIは、[POSIX]その一例です。 UTO拡張子を含めることを選択し、TCPの実装はアプリケーションがそのパラメータを使用して設定できるようにするために彼らのAPIを拡張することが期待されます。
The MIB objects defined in [RFC4022] and [RFC4898] allow management of TCP connections. It is expected that revisions to these documents will include definitions of objects for managing the UTO extension defined in this document.
MIBは[RFC4022]で定義されたオブジェクトと[RFC4898]はTCP接続の管理を可能にします。これらの文書の改訂は、この文書で定義されたUTO拡張を管理するためのオブジェクトの定義が含まれることが期待されます。
Lengthening user timeouts has obvious security implications. Flooding attacks cause denial of service by forcing servers to commit resources for maintaining the state of throw-away connections. However, TCP implementations do not become more vulnerable to simple
ユーザーのタイムアウトを長くする明らかなセキュリティ上の意味を持っています。フラッディング攻撃は、スローアウェイ接続の状態を維持するためのリソースをコミットするようにサーバーを強制することにより、サービス拒否を引き起こします。しかし、TCPの実装はシンプルに、より脆弱になることはありません。
SYN flooding by implementing the TCP User Timeout Option, because user timeouts exchanged during the handshake only affect the synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK), which simple SYN floods never reach.
ユーザータイムアウトがハンドシェイク中に交換するので、TCPユーザのタイムアウト・オプションを実装することにより、SYNフラッドのみ影響し、同期状態（ESTABLISHED、FIN-WAIT-1、FIN-WAIT-2、CLOSE-WAIT、CLOSING、LAST-ACK）、シンプルSYNフラッドは到達しません。
However, when an attacker completes the three-way handshakes of its throw-away connections, it can amplify the effects of resource exhaustion attacks because the attacked server must maintain the connection state associated with the throw-away connections for longer durations. Because connection state is kept longer, lower-frequency attack traffic, which may be more difficult to detect, can already exacerbate resource exhaustion.
攻撃者はそのスローアウェイ接続の3ウェイハンドシェイクが完了したときに攻撃したサーバが長い期間のためのスローアウェイ接続に関連する接続状態を維持しなければならないので、しかし、それはリソースの枯渇攻撃の効果を増幅することができます。接続状態が長く保たれているので、低周波の攻撃トラフィック、すでに資源の枯渇を悪化させることができ、検出するのがより困難になる可能性があります。
Several approaches can help mitigate this issue. First, implementations can require prior peer authentication, e.g., using IPsec [RFC4301] or TCP-MD5 [RFC2385], before accepting long user timeouts for the peer's connections. (Implementors that decide to use TCP-MD5 for this purpose are encouraged to monitor the development of TCP-AO [AUTH_OPT], its designated successor, and update their implementation when it is published as an RFC.) A similar approach is for a host to start accepting long user timeouts for an established connection only after in-band authentication has occurred, for example, after a TLS handshake across the connection has succeeded [RFC5246]. Although these are arguably the most complete solutions, they depend on external mechanisms to establish a trust relationship.
いくつかのアプローチは、この問題を軽減することができます。まず、実装は、ピアの接続のために長いユーザタイムアウトを受け入れる前に、IPsecの[RFC4301]またはTCP-MD5 [RFC2385]を使用して、例えば、前ピア認証を要求することができます。 （それはRFCとして公開されている場合、この目的のためにTCP-MD5を使用することを決定した実装者はTCP-AO [AUTH_OPT]、その指定された後継の開発を監視し、その実施をアップデートすることをお勧めします。）同様のアプローチは、ホストのためにあります後にのみインバンド認証が発生している確立された接続のための長いユーザタイムアウトを受け付けを開始するように、例えば、接続の両端のTLSハンドシェイクの後に[RFC5246]を成功しました。これらは間違いなく最も完全なソリューションですが、彼らは信頼関係を確立するために、外部のメカニズムに依存しています。
A second alternative that does not depend on external mechanisms would introduce a per-peer limit on the number of connections that may use increased user timeouts. Several variants of this approach are possible, such as fixed limits or shortening accepted user timeouts with a rising number of connections. Although this alternative does not eliminate resource exhaustion attacks from a single peer, it can limit their effects. Reducing the number of high-UTO connections a server supports in the face of an attack turns that attack into a denial-of-service attack against the service of high-UTO connections.
外部機構に依存しない第二の代替が増加ユーザタイムアウトを使用することができる接続の数に当たりピア制限を導入します。このアプローチのいくつかの変異体は、固定された限界または接続の立ち上がり数で受け付けたユーザタイムアウトを短くするように、可能です。この代替は、単一のピアからのリソースの枯渇攻撃を排除しませんが、それは彼らの影響を制限することができます。サーバーが攻撃に直面してサポートし、高UTO接続の数を減らすことは、高UTO接続のサービスに対するDoS攻撃にその攻撃を回します。
Per-peer limits cannot protect against distributed denial-of-service attacks, where multiple clients coordinate a resource exhaustion attack that uses long user timeouts. To protect against such attacks, TCP implementations could reduce the duration of accepted user timeouts with increasing resource utilization.
ピアごとの制限は、複数のクライアントが長いユーザーのタイムアウトを使用してリソースの枯渇攻撃を座標の分散サービス拒否攻撃から保護することはできません。このような攻撃から保護するために、TCPの実装は、リソース使用率の増加に伴って受け付けたユーザのタイムアウトの時間を減らすことができます。
TCP implementations under attack may be forced to shed load by resetting established connections. Some load-shedding heuristics, such as resetting connections with long idle times first, can negatively affect service for intermittently connected, trusted peers that have suggested long user timeouts. On the other hand, resetting connections to untrusted peers that use long user timeouts may be effective. In general, using the peers' level of trust as a parameter during the load-shedding decision process may be useful. Note that if TCP needs to close or abort connections with a long TCP User Timeout Option to shed load, these connections are still no worse off than without the option.
攻撃を受けてTCPの実装では、確立された接続をリセットすることにより、負荷を当てることを強制することができます。こうした最初の長いアイドル時間との接続をリセットするなど、一部の負荷をはじくヒューリスティックは、負の長いユーザータイムアウトを示唆している断続的に接続されている、信頼できるピアのサービスに影響を与えることができます。一方、長いユーザタイムアウトを使用し、信頼できないピアへの接続をリセットすることは効果的であり得ます。一般に、負荷シェディング決定プロセス中にパラメータとして信頼のピアのレベルを使用することは有用であり得ます。 TCPは、負荷を当てるために長いTCPユーザタイムアウトオプションで接続を閉じるか、中止する必要がある場合、これらの接続は依然として悪くない選択肢がない場合よりもオフになっていることに注意してください。
Finally, upper and lower limits on user timeouts, discussed in Section 3.1, can be an effective tool to limit the impact of these sorts of attacks.
最後に、3.1節で説明したユーザ・タイムアウトの上限と下限は、攻撃のこの種の影響を制限するために有効なツールであることができます。
This section is to be interpreted according to [RFC5226].
このセクションでは、[RFC5226]に従って解釈されるべきです。
This document does not define any new namespaces. IANA has allocated a new 8-bit TCP option number (28) for the UTO option from the "TCP Option Kind Numbers" registry maintained at http://www.iana.org.
このドキュメントは、新しい名前空間を定義していません。 IANAはhttp://www.iana.orgに保た「TCPオプション種別番号」レジストリからUTOオプションの新しい8ビットのTCPオプション番号（28）を割り当てています。
The following people have improved this document through thoughtful suggestions: Mark Allman, Caitlin Bestler, David Borman, Bob Braden, Scott Brim, Marcus Brunner, Wesley Eddy, Gorry Fairhurst, Abolade Gbadegesin, Ted Faber, Guillermo Gont, Tom Henderson, Joseph Ishac, Jeremy Harris, Alfred Hoenes, Phil Karn, Michael Kerrisk, Dan Krejsa, Jamshid Mahdavi, Kostas Pentikousis, Juergen Quittek, Anantha Ramaiah, Joe Touch, Stefan Schmid, Simon Schuetz, Tim Shepard, and Martin Stiemerling.
、マーク・オールマン、ケイトリンBestler、デビッド・ボーマン、ボブブレーデン、スコット・ブリム、マーカスブルンナー、ウェズリーエディ、Gorry Fairhurst、Abolade Gbadegesin、テッド・フェーバー、ギジェルモGont、トム・ヘンダーソン、ジョセフIshac：次の人は思慮深い提案を通じ、このドキュメントを改善していますジェレミー・ハリス、アルフレッドHoenes、フィル・カーン、マイケル・ケリスク、ダンKrejsa、ジャムシードMahdavi、コスタスPentikousis、ユルゲンQuittek、Anantha Ramaiah、ジョー・タッチ、ステファン・シュミット、サイモンSchuetz、ティム・シェパード、とマーティンStiemerling。
Lars Eggert is partly funded by [TRILOGY], a research project supported by the European Commission under its Seventh Framework Program.
ラースEggertのは、部分的に[TRILOGY]、その第七次フレームワーク計画の下で、欧州委員会でサポートされている研究プロジェクトによって資金を供給されます。
Fernando Gont wishes to thank Secretaria de Extension Universitaria at Universidad Tecnologica Nacional and Universidad Tecnologica Nacional/Facultad Regional Haedo for supporting him in this work.
フェルナンドGontはこの作品で彼をサポートするための国立工科大学の大学拡張と大学Tecnologicaナシオナル/ Facultad地域Haedo長官に感謝したいです。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、R.、 "インターネットホストのための要件 - 通信層"、STD 3、RFC 1122、1989年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[AUTH_OPT] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", Work in Progress, November 2008.
[AUTH_OPT]タッチ、J.、マンキン、A.、およびR. Bonica、 "TCP認証オプション"、進歩、2008年11月の作業。
[MEDINA] Medina, A., Allman, M., and S. Floyd, "Measuring Interactions Between Transport Protocols and Middleboxes", Proc. 4th ACM SIGCOMM/USENIX Conference on Internet Measurement, October 2004.
【MEDINA]メディナ、A.、オールマン、M.、およびS.フロイド、PROC "トランスポートプロトコルとのMiddleboxes間の相互作用を測定します"。インターネット計測、2004年10月の第4回ACM SIGCOMM / USENIX会議。
[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）"、Open Groupの技術標準：基本仕様6号、ISO / IEC 9945：2002、2001年12月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385] Heffernanの、A.、 "TCP MD5署名オプションを使用してBGPセッションの保護"、RFC 2385、1998年8月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[RFC2988]パクソン、V.とM.オールマン、 "コンピューティングTCPの再送信タイマー"、RFC 2988、2000年11月。
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344]パーキンス、C.、 "IPv4のIPモビリティサポート"、RFC 3344、2002年8月。
[RFC4022] Raghunarayan, R., "Management Information Base for the Transmission Control Protocol (TCP)", RFC 4022, March 2005.
[RFC4022] Raghunarayan、R.、 "伝送制御プロトコルのための管理情報ベース（TCP）"、RFC 4022、2005年3月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006.
[RFC4423]モスコウィッツ、R.とP. Nikander、 "ホストアイデンティティプロトコル（HIP）アーキテクチャ"、RFC 4423、2006年5月。
[RFC4898] Mathis, M., Heffner, J., and R. Raghunarayan, "TCP Extended Statistics MIB", RFC 4898, May 2007.
[RFC4898]マシス、M.、Heffner、J.、およびR. Raghunarayan、 "統計のMIB拡張TCP"、RFC 4898、2007年5月。
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, August 2007.
[RFC4987]エディ、W.、 "TCPのSYNフラッド攻撃と共通の軽減策"、RFC 4987、2007年8月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.2"、RFC 5246、2008年8月。
[SOLARIS] Sun Microsystems, "Solaris Tunable Parameters Reference Manual", Part No. 806-7009-10, 2002.
[SOLARIS]サン・マイクロシステムズ、 "マニュアルSolarisカーネルのチューンアップ・リファレンス"、部品番号806-7009-10、2002。
[TCP_MOB] Eddy, W., "Mobility Support For TCP", Work in Progress, April 2004.
[TCP_MOB]エディ、W.、 "TCPのモビリティサポート"、進歩、2004年4月に作業。
[TRILOGY] "Trilogy Project", <http://www.trilogy-project.org/>.
[TRILOGY] "トリロジープロジェクト"、<http://www.trilogy-project.org/>。
Authors' Addresses
著者のアドレス
Lars Eggert Nokia Research Center P.O. Box 407 Nokia Group 00045 Finland
ラースEggertのノキア・リサーチセンター私書箱ボックス407ノキアグループ00045フィンランド
Phone: +358 50 48 24461 EMail: lars.eggert@nokia.com URI: http://research.nokia.com/people/lars_eggert/
電話番号：+358 50 48 24461電子メール：lars.eggert@nokia.com URI：http://research.nokia.com/people/lars_eggert/
Fernando Gont Universidad Tecnologica Nacional / Facultad Regional Haedo Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina
フェルナンドGont大学Tecnologicaナシオナル/ Facultad地域Haedoエバリスト・キャリエゴ2644 Haedo、1706ブエノスアイレス州アルゼンチン
Phone: +54 11 4650 8472 EMail: fernando@gont.com.ar URI: http://www.gont.com.ar/
電話：+54 11 4650 8472 Eメール：URI fernando@gont.com.ar：http://www.gont.com.ar/