Internet Engineering Task Force (IETF) R. Seggelmann
Request for Comments: 6520 M. Tuexen
Category: Standards Track Muenster Univ. of Appl. Sciences
ISSN: 2070-1721 M. Williams
GWhiz Arts & Sciences
February 2012
Transport Layer Security (TLS) and
Datagram Transport Layer Security (DTLS) Heartbeat Extension
Abstract
抽象
This document describes the Heartbeat Extension for the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols.
この文書では、トランスポート層セキュリティ（TLS）およびデータグラムトランスポート層セキュリティ（DTLS）プロトコルのためのハートビート拡張について説明します。
The Heartbeat Extension provides a new protocol for TLS/DTLS allowing the usage of keep-alive functionality without performing a renegotiation and a basis for path MTU (PMTU) discovery for DTLS.
ハートビート拡張は再交渉及びDTLSのパスMTU（PMTU）発見のための基礎を行うことなく、キープアライブ機能の使用を可能にするTLS / DTLSのための新しいプロトコルを提供します。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6520.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6520で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2012 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Heartbeat Hello Extension . . . . . . . . . . . . . . . . . . . 3
3. Heartbeat Protocol . . . . . . . . . . . . . . . . . . . . . . 4
4. Heartbeat Request and Response Messages . . . . . . . . . . . . 5
5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
This document describes the Heartbeat Extension for the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols, as defined in [RFC5246] and [RFC6347] and their adaptations to specific transport protocols described in [RFC3436], [RFC5238], and [RFC6083].
[RFC5246]と[RFC6347]で定義されて、[RFC3436]に記載されている特定のトランスポートプロトコルへの適応として、この文書では、[RFC5238]、トランスポート層セキュリティ（TLS）のためのハートビート拡張とデータグラムトランスポート層セキュリティ（DTLS）プロトコルについて説明します、および[RFC6083]。
DTLS is designed to secure traffic running on top of unreliable transport protocols. Usually, such protocols have no session management. The only mechanism available at the DTLS layer to figure out if a peer is still alive is a costly renegotiation, particularly when the application uses unidirectional traffic. Furthermore, DTLS needs to perform path MTU (PMTU) discovery but has no specific message type to realize it without affecting the transfer of user messages.
DTLSは、信頼性の低いトランスポートプロトコルの上で実行されているトラフィックを保護するように設計されています。通常、このようなプロトコルには、セッション管理を持っていません。ピアがまだ生きているかどうかを把握するDTLS層で利用可能な唯一のメカニズムでは、アプリケーションは、一方向トラフィックを使用する場合は特に、高価な再交渉です。また、DTLSは、パスMTU（PMTU）検出を実行する必要がなく、ユーザメッセージの転送に影響を与えることなく、それを実現する具体的なメッセージタイプを有していません。
TLS is based on reliable protocols, but there is not necessarily a feature available to keep the connection alive without continuous data transfer.
TLSは、信頼性の高いプロトコルに基づいていますが、連続データ転送せずに生きて接続を維持するために利用できる機能は必ずしもありません。
The Heartbeat Extension as described in this document overcomes these limitations. The user can use the new HeartbeatRequest message, which has to be answered by the peer with a HeartbeartResponse immediately. To perform PMTU discovery, HeartbeatRequest messages containing padding can be used as probe packets, as described in [RFC4821].
この文書で説明したように、ハートビート拡張は、これらの制限を克服します。ユーザーはすぐにHeartbeartResponseとのピアによって回答する必要があり、新たなHeartbeatRequestメッセージを、使用することができます。 [RFC4821]に記載されているようにPMTU検出を実行するために、パディングを含むHeartbeatRequestメッセージは、プローブパケットとして使用することができます。
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]に記載されているように解釈されます。
The support of Heartbeats is indicated with Hello Extensions. A peer cannot only indicate that its implementation supports Heartbeats, it can also choose whether it is willing to receive HeartbeatRequest messages and respond with HeartbeatResponse messages or only willing to send HeartbeatRequest messages. The former is indicated by using peer_allowed_to_send as the HeartbeatMode; the latter is indicated by using peer_not_allowed_to_send as the Heartbeat mode. This decision can be changed with every renegotiation. HeartbeatRequest messages MUST NOT be sent to a peer indicating peer_not_allowed_to_send. If an endpoint that has indicated peer_not_allowed_to_send receives a HeartbeatRequest message, the endpoint SHOULD drop the message silently and MAY send an unexpected_message Alert message.
ハートビートのサポートはこんにちは拡張機能で表示されます。その実装は、ハートビートをサポートしていることを示すことができない唯一のピアは、それはまた、HeartbeatRequestメッセージを受信し、HeartbeatResponseメッセージやHeartbeatRequestメッセージを送信するだけで喜んで応答する意思があるかどうかを選択することができます。前者はHeartbeatModeとしてpeer_allowed_to_send用いて示されています。後者は、ハートビートモードとしてpeer_not_allowed_to_send用いて示されています。この決定は、すべての再交渉で変更することができます。 HeartbeatRequestメッセージは、ピア示すpeer_not_allowed_to_sendに送ってはいけません。 peer_not_allowed_to_sendを示したエンドポイントがHeartbeatRequestメッセージを受信した場合、エンドポイントは静かにメッセージをドロップする必要があり、unexpected_message警告メッセージを送信することができます。
The format of the Heartbeat Hello Extension is defined by:
ハートビートこんにちは拡張子の形式は以下のように定義されています。
enum {
peer_allowed_to_send(1),
peer_not_allowed_to_send(2),
(255)
} HeartbeatMode;
struct {
HeartbeatMode mode;
} HeartbeatExtension;
Upon reception of an unknown mode, an error Alert message using illegal_parameter as its AlertDescription MUST be sent in response.
未知のモードを受信すると、そのAlertDescriptionとしてillegal_parameter使用エラー警告メッセージが応答で送信されなければなりません。
The Heartbeat protocol is a new protocol running on top of the Record Layer. The protocol itself consists of two message types: HeartbeatRequest and HeartbeatResponse.
ハートビートプロトコルは、レコード層の上で動作する新しいプロトコルです。 HeartbeatRequestとHeartbeatResponse：プロトコル自体は、2つのメッセージ・タイプで構成される。
enum {
heartbeat_request(1),
heartbeat_response(2),
(255)
} HeartbeatMessageType;
A HeartbeatRequest message can arrive almost at any time during the lifetime of a connection. Whenever a HeartbeatRequest message is received, it SHOULD be answered with a corresponding HeartbeatResponse message.
HeartbeatRequestメッセージは、接続の存続期間中、ほぼ任意の時間に到着することができます。 HeartbeatRequestメッセージが受信されるたびに、対応するHeartbeatResponseメッセージで答えられるべきです。
However, a HeartbeatRequest message SHOULD NOT be sent during handshakes. If a handshake is initiated while a HeartbeatRequest is still in flight, the sending peer MUST stop the DTLS retransmission timer for it. The receiving peer SHOULD discard the message silently, if it arrives during the handshake. In case of DTLS, HeartbeatRequest messages from older epochs SHOULD be discarded.
しかし、HeartbeatRequestメッセージはハンドシェイク中に送るべきではありません。 HeartbeatRequestが飛行中にある間のハンドシェイクが開始されている場合は、送信側ピアは、それのためにDTLS再送タイマーを停止する必要があります。それはハンドシェイク中に到着した場合の受信ピアは、静かにメッセージを捨てます。 DTLSの場合は、古いエポックからのHeartbeatRequestメッセージは破棄されるべきである（SHOULD）。
There MUST NOT be more than one HeartbeatRequest message in flight at a time. A HeartbeatRequest message is considered to be in flight until the corresponding HeartbeatResponse message is received, or until the retransmit timer expires.
一度に飛行中の複数のHeartbeatRequestメッセージがあってはなりません。 HeartbeatRequestメッセージは、対応するHeartbeatResponseメッセージが受信されるまで飛行中であると考えられ、または再送信タイマが満了するまでされています。
When using an unreliable transport protocol like the Datagram Congestion Control Protocol (DCCP) or UDP, HeartbeatRequest messages MUST be retransmitted using the simple timeout and retransmission scheme DTLS uses for flights as described in Section 4.2.4 of [RFC6347]. In particular, after a number of retransmissions without receiving a corresponding HeartbeatResponse message having the expected payload, the DTLS connection SHOULD be terminated. The threshold used for this SHOULD be the same as for DTLS handshake messages. Please note that after the timer supervising a HeartbeatRequest messages expires, this message is no longer considered in flight. Therefore, the HeartbeatRequest message is eligible for retransmission. The retransmission scheme, in combination with the restriction that only one HeartbeatRequest is allowed to be in flight, ensures that congestion control is handled appropriately in case of the transport protocol not providing one, like in the case of DTLS over UDP.
データグラム輻輳制御プロトコル（DCCP）またはUDPのような信頼性の低いトランスポートプロトコルを使用する場合、HeartbeatRequestメッセージは、[RFC6347]のセクション4.2.4に記載したようにDTLSが便を使用する単純なタイムアウトおよび再送信方式を使用して再送信されなければなりません。具体的には、予想されるペイロードを有する対応HeartbeatResponseメッセージを受信せずに再送回数の後、DTLS接続が終了されるべきです。このために使用される閾値は、DTLS握手メッセージと同じでなければなりません。 HeartbeatRequestメッセージを監督タイマが満了した後、このメッセージは、もはや飛行する際に考慮されないことに注意してください。したがって、HeartbeatRequestメッセージは、再送信の対象となります。再送信方式は、一つだけHeartbeatRequestが飛行中であることが許可されている制限と組み合わせて、輻輳制御はトランスポートプロトコルはUDP上DTLSの場合のように、一方を設けない場合には適切に処理されることを保証します。
When using a reliable transport protocol like the Stream Control Transmission Protocol (SCTP) or TCP, HeartbeatRequest messages only need to be sent once. The transport layer will handle retransmissions. If no corresponding HeartbeatResponse message has been received after some amount of time, the DTLS/TLS connection MAY be terminated by the application that initiated the sending of the HeartbeatRequest message.
ストリーム制御伝送プロトコル（SCTP）またはTCPのような信頼性の高いトランスポートプロトコルを使用する場合は、HeartbeatRequestメッセージは一度だけ送信される必要があります。トランスポート層は、再送信を処理します。該当するHeartbeatResponseメッセージは、ある程度の時間の後に受信されていない場合は、DTLS / TLS接続がHeartbeatRequestメッセージの送信を開始したアプリケーションによって終了させることができます。
The Heartbeat protocol messages consist of their type and an arbitrary payload and padding.
ハートビート・プロトコル・メッセージは、そのタイプと任意のペイロード及びパディングから成ります。
struct {
HeartbeatMessageType type;
uint16 payload_length;
opaque payload[HeartbeatMessage.payload_length];
opaque padding[padding_length];
} HeartbeatMessage;
The total length of a HeartbeatMessage MUST NOT exceed 2^14 or max_fragment_length when negotiated as defined in [RFC6066].
[RFC6066]で定義されるようにネゴシエートするときHeartbeatMessageの合計長さは2 ^ 14またはmax_fragment_lengthを超えてはなりません。
type: The message type, either heartbeat_request or heartbeat_response.
タイプ：メッセージタイプ、heartbeat_requestまたはheartbeat_responseのいずれか。
payload_length: The length of the payload.
payload_length：ペイロードの長さ。
payload: The payload consists of arbitrary content.
ペイロード：ペイロードは、任意のコンテンツで構成されています。
padding: The padding is random content that MUST be ignored by the receiver. The length of a HeartbeatMessage is TLSPlaintext.length for TLS and DTLSPlaintext.length for DTLS. Furthermore, the length of the type field is 1 byte, and the length of the payload_length is 2. Therefore, the padding_length is TLSPlaintext.length - payload_length - 3 for TLS and DTLSPlaintext.length - payload_length - 3 for DTLS. The padding_length MUST be at least 16.
パディング：パディングが受信機で無視しなければなりませんランダムな内容です。 HeartbeatMessageの長さは、DTLSのためのTLSとDTLSPlaintext.lengthためTLSPlaintext.lengthです。また、タイプフィールドの長さは1バイトであり、payload_lengthの長さは、したがって2である、するpadding_lengthはTLSPlaintext.lengthある - payload_length - TLSおよびDTLSPlaintext.length 3 - payload_length - 3 DTLSため。するpadding_lengthは、少なくとも16でなければなりません。
The sender of a HeartbeatMessage MUST use a random padding of at least 16 bytes. The padding of a received HeartbeatMessage message MUST be ignored.
HeartbeatMessageの送信者は、少なくとも16バイトのランダムなパディングを使用しなければなりません。受信HeartbeatMessageメッセージのパディングを無視しなければなりません。
If the payload_length of a received HeartbeatMessage is too large, the received HeartbeatMessage MUST be discarded silently.
受信HeartbeatMessageのpayload_lengthが大きすぎる場合、受信HeartbeatMessageは黙って捨てなければなりません。
When a HeartbeatRequest message is received and sending a HeartbeatResponse is not prohibited as described elsewhere in this document, the receiver MUST send a corresponding HeartbeatResponse message carrying an exact copy of the payload of the received HeartbeatRequest.
HeartbeatRequestメッセージが受信され、この文書の他の箇所に記載されるようにHeartbeatResponseの送信が禁止されていない場合、受信機は、受信されたHeartbeatRequestのペイロードの正確なコピーを保有する対応HeartbeatResponseメッセージを送らなければなりません。
If a received HeartbeatResponse message does not contain the expected payload, the message MUST be discarded silently. If it does contain the expected payload, the retransmission timer MUST be stopped.
受信HeartbeatResponseメッセージが予想されるペイロードが含まれていない場合、メッセージは静かに捨てなければなりません。それが予想されるペイロードを含まない場合は、再送タイマを停止する必要があります。
Each endpoint sends HeartbeatRequest messages at a rate and with the padding required for the particular use case. The endpoint should not expect its peer to send HeartbeatRequests. The directions are independent.
各エンドポイントは、レートで特定のユースケースに必要なパディングとHeartbeatRequestメッセージを送信します。エンドポイントは、そのピアがHeartbeatRequestsを送信するために期待するべきではありません。方向が独立しています。
DTLS performs path MTU discovery as described in Section 4.1.1.1 of [RFC6347]. A detailed description of how to perform path MTU discovery is given in [RFC4821]. The necessary probe packets are the HeartbeatRequest messages.
[RFC6347]のセクション4.1.1.1に記載されるようにDTLSは、パスMTU探索を行います。パスMTU探索を実行する方法の詳細な説明は、[RFC4821]に記載されています。必要なプローブパケットはHeartbeatRequestメッセージです。
This method of using HeartbeatRequest messages for DTLS is similar to the one for the Stream Control Transmission Protocol (SCTP) using the padding chunk (PAD-chunk) defined in [RFC4820].
DTLSためHeartbeatRequestメッセージを使用するこの方法は、[RFC4820]で定義されたパディングチャンク（PAD-チャンク）を使用してストリーム制御伝送プロトコル（SCTP）のためのものと同様です。
Sending HeartbeatRequest messages allows the sender to make sure that it can reach the peer and the peer is alive. Even in the case of TLS/TCP, this allows a check at a much higher rate than the TCP keep-alive feature would allow.
HeartbeatRequestメッセージを送信すると、送信者は、それがピアに到達できることを確認することができますし、ピアは生きています。でも、TLS / TCPの場合には、これは、TCPキープアライブ機能よりもはるかに高いレートでのチェックが可能になることができます。
Besides making sure that the peer is still reachable, sending HeartbeatRequest messages refreshes the NAT state of all involved NATs.
ピアがまだ到達可能であることを確認することに加えて、HeartbeatRequestメッセージを送信すると、すべての関与のNAT NAT状態を更新します。
HeartbeatRequest messages SHOULD only be sent after an idle period that is at least multiple round-trip times long. This idle period SHOULD be configurable up to a period of multiple minutes and down to a period of one second. A default value for the idle period SHOULD be configurable, but it SHOULD also be tunable on a per-peer basis.
HeartbeatRequestメッセージは、少なくとも複数の往復時間の長さであるアイドル期間の後に送ってください。このアイドル期間は、複数の分の時間まで1秒の期間まで設定可能であるべきです。アイドル期間のデフォルト値は設定する必要がありますが、それはまた、ピアごとに調整可能ですべきである（SHOULD）。
IANA has assigned the heartbeat content type (24) from the "TLS ContentType Registry" as specified in [RFC5246]. The reference is to RFC 6520.
[RFC5246]で指定されるようにIANAは、「TLSのContentTypeレジストリ」からハートビートコンテンツタイプ（24）を割り当てました。参照は、RFC 6520にあります。
IANA has created and now maintains a new registry for Heartbeat Message Types. The message types are numbers in the range from 0 to 255 (decimal). IANA has assigned the heartbeat_request (1) and the heartbeat_response (2) message types. The values 0 and 255 should be reserved. This registry uses the Expert Review policy as described in [RFC5226]. The reference is to RFC 6520.
IANAが作成され、今でハートビートメッセージタイプのための新しいレジストリを維持しています。メッセージタイプは0〜255（10進数）の範囲の数です。 IANAはheartbeat_request（1）及びheartbeat_response（2）メッセージタイプを割り当てました。値が0と255は予約する必要があります。 [RFC5226]で説明したように、このレジストリは、エキスパートレビューのポリシーを使用しています。参照は、RFC 6520にあります。
IANA has assigned the heartbeat extension type (15) from the TLS "ExtensionType Values" registry as specified in [RFC5246]. The reference is to RFC 6520.
[RFC5246]で指定されるようにIANAは、TLS「ExtensionType値」レジストリから心拍拡張型（15）を割り当てました。参照は、RFC 6520にあります。
IANA has created and now maintains a new registry for Heartbeat Modes. The modes are numbers in the range from 0 to 255 (decimal). IANA has assigned the peer_allowed_to_send (1) and the peer_not_allowed_to_send (2) modes. The values 0 and 255 should be reserved. This registry uses the Expert Review policy as described in [RFC5226]. The reference is to RFC 6520.
IANAが作成され、今でハートビートモードのための新しいレジストリを維持しています。モードは0〜255（10進数）の範囲の数です。 IANAはpeer_allowed_to_send（1）及びpeer_not_allowed_to_send（2）モードを割り当てました。値が0と255は予約する必要があります。 [RFC5226]で説明したように、このレジストリは、エキスパートレビューのポリシーを使用しています。参照は、RFC 6520にあります。
The security considerations of [RFC5246] and [RFC6347] apply to this document. This document does not introduce any new security considerations.
[RFC5246]と[RFC6347]のセキュリティ上の考慮事項は、この文書に適用されます。このドキュメントは、新しいセキュリティの考慮事項を導入しません。
The authors wish to thank Pasi Eronen, Adrian Farrel, Stephen Farrell, Adam Langley, Nikos Mavrogiannopoulos, Tom Petch, Eric Rescorla, Peter Saint-Andre, and Juho Vaehae-Herttua for their invaluable comments.
作者は彼らの貴重なコメントをパシEronen、エードリアンファレル、スティーブン・ファレル、アダム・ラングレー、ニコスMavrogiannopoulos、トム・ペッチ、エリックレスコラ、ピーター・サン・アンドレ、そしてたJuho Vaehae-Herttuaに感謝したいです。
[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月。
[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月。
[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, January 2011.
[RFC6066]イーストレイク、D.、 "トランスポート層セキュリティ（TLS）拡張機能：拡張定義"、RFC 6066、2011年1月。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012.
[RFC6347]レスコラ、E.およびN. Modadugu、 "データグラムトランスポート層セキュリティバージョン1.2"、RFC 6347、2012年1月。
[RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport Layer Security over Stream Control Transmission Protocol", RFC 3436, December 2002.
[RFC3436] Jungmaier、A.、レスコラ、E.、およびM. Tuexen、 "ストリーム制御伝送プロトコルを介してトランスポート層セキュリティ"、RFC 3436、2002年12月。
[RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP)", RFC 4820, March 2007.
[RFC4820] Tuexen、M.、スチュワート、R.、およびP.レイ、 "パディングチャンクおよびストリーム制御伝送プロトコル（SCTP）のパラメータ"、RFC 4820、2007年3月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4821]マシス、M.とJ. Heffner、 "パケット化レイヤのパスMTUディスカバリ"、RFC 4821、2007年3月。
[RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP)", RFC 5238, May 2008.
[RFC5238]フェラン、T.、RFC 5238、2008年5月、 "データグラム輻輳制御プロトコル（DCCP）を超えるデータグラムトランスポート層セキュリティ（DTLS）"。
[RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP)", RFC 6083, January 2011.
[RFC6083] Tuexen、M.、Seggelmann、R.、およびE.レスコラ、RFC 6083、2011年1月、 "ストリーム制御伝送プロトコル（SCTP）のためのデータグラムトランスポート層セキュリティ（DTLS）"。
Authors' Addresses
著者のアドレス
Robin Seggelmann Muenster University of Applied Sciences Stegerwaldstr. 39 48565 Steinfurt DE
応用科学StegerwaldstrのロビンSeggelmannミュンスター大学。 39 48565 Steinsfurt DE
EMail: seggelmann@fh-muenster.de
メールアドレス：seggelmann@fh-muenster.de
Michael Tuexen Muenster University of Applied Sciences Stegerwaldstr. 39 48565 Steinfurt DE
応用科学StegerwaldstrのマイケルTuexenミュンスター大学。 39 48565シュタインフルトDE
EMail: tuexen@fh-muenster.de
メールアドレス：tuexen@fh-muenster.de
Michael Glenn Williams GWhiz Arts & Sciences 2885 Denise Court Newbury Park, CA, 91320 USA
マイケル・グレン・ウィリアムズGWhiz芸術科学2885デニス・コートニューベリーパーク、CA、91320 USA
EMail: michael.glenn.williams@gmail.com
メールアドレス：michael.glenn.williams@gmail.com