メインコンテンツまでスキップ

RFC 9221 - An Unreliable Datagram Extension to QUIC

  • ステータス: Proposed Standard
  • 発行日: March 2022
  • ストリーム: IETF
  • エラッタ: エラッタなし

Abstract​

This document defines an extension to the QUIC transport protocol to add support for sending and receiving unreliable datagrams over a QUIC connection.

このドキュメントでは、QUICトランスポートプロトコルの拡張機能を定義して、QUIC接続を介した信頼性の低いデータグラムの送受信のサポートを追加します。

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 7841.

このドキュメントは、Internet Engineering Task Force（IETF）の成果物です。これはIETFコミュニティのコンセンサスを表しています。公開レビューを受けており、Internet Engineering Steering Group（IESG）によって公開が承認されています。インターネット標準の詳細については、RFC 7841のセクション2を参照してください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9221.

このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9221 で入手できます。

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.

Copyright (c) 2022 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、トラスト法的規定のセクション4.eで説明されている改訂BSDライセンスのテキストが含まれている必要があり、改訂BSDライセンスで説明されている保証なしで提供されます。

Table of Contents​

    1. Introduction
    1. Motivation
    1. Transport Parameter
    1. Datagram Frame Types
    1. Behavior and Usage
    1. Security Considerations
    1. IANA Considerations
    1. References
  • Acknowledgments
  • Authors' Addresses

1. Introduction​

The QUIC transport protocol [RFC9000] provides a secure, multiplexed connection for transmitting reliable streams of application data. QUIC uses various frame types to transmit data within packets, and each frame type defines whether the data it contains will be retransmitted. Streams of reliable application data are sent using STREAM frames.

QUICトランスポートプロトコル[RFC9000]は、アプリケーションデータの信頼性の高いストリームを送信するための安全な多重化接続を提供します。QUICはさまざまなフレームタイプを使用してパケット内でデータを送信し、各フレームタイプは、それに含まれるデータが再送信されるかどうかを定義します。信頼できるアプリケーションデータのストリームは、STREAMフレームを使用して送信されます。

Some applications, particularly those that need to transmit real-time data, prefer to transmit data unreliably. In the past, these applications have built directly upon UDP [RFC0768] as a transport and have often added security with DTLS [RFC6347]. Extending QUIC to support transmitting unreliable application data provides another option for secure datagrams with the added benefit of sharing the cryptographic and authentication context used for reliable streams.

一部のアプリケーション、特にリアルタイムデータを送信する必要があるアプリケーションは、データを信頼性の低い方法で送信することを好みます。これまで、これらのアプリケーションはトランスポートとしてUDP [RFC0768]上に直接構築されており、DTLS [RFC6347]でセキュリティを追加することがよくありました。信頼性の低いアプリケーションデータの送信をサポートするようにQUICを拡張すると、安全なデータグラムの別のオプションが提供され、信頼性の高いストリームに使用される暗号化および認証コンテキストを共有できるという利点も追加されます。

This document defines two new DATAGRAM QUIC frame types that carry application data without requiring retransmissions.

このドキュメントでは、再送信を必要とせずにアプリケーションデータを運ぶ2つの新しいDATAGRAM QUICフレームタイプを定義します。

1.1. Specification of Requirements​

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

このドキュメントのキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", および "OPTIONAL" は、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。これらは、ここに示すようにすべて大文字で表示される場合にのみ適用されます。

2. Motivation​

Transmitting unreliable data over QUIC provides benefits over existing solutions:

QUICを介して信頼性の低いデータを送信すると、既存のソリューションに比べて次のような利点があります。

  • Applications that want to use both a reliable stream and an unreliable flow to the same peer can benefit by sharing a single handshake and authentication context between a reliable QUIC stream and a flow of unreliable QUIC datagrams. This can reduce the latency required for handshakes compared to opening both a TLS connection and a DTLS connection.
  • 同じピアに対して信頼できるストリームと信頼できないフローの両方を使用したいアプリケーションは、信頼できるQUICストリームと信頼できないQUICデータグラムのフローの間で単一のハンドシェイクと認証コンテキストを共有することでメリットを得ることができます。これにより、TLS接続とDTLS接続の両方を開く場合と比較して、ハンドシェイクに必要なレイテンシを削減できます。
  • QUIC uses a more nuanced loss recovery mechanism than the DTLS handshake. This can allow loss recovery to occur more quickly for QUIC data.
  • QUICは、DTLSハンドシェイクよりも微妙な損失回復メカニズムを使用します。これにより、QUICデータの損失回復をより迅速に行うことができます。
  • QUIC datagrams are subject to QUIC congestion control. Providing a single congestion control for both reliable and unreliable data can be more effective and efficient.
  • QUICデータグラムは、QUIC輻輳制御の対象となります。信頼できるデータと信頼できないデータの両方に単一の輻輳制御を提供することで、より効果的かつ効率的になります。

These features can be useful for optimizing audio/video streaming applications, gaming applications, and other real-time network applications.

これらの機能は、オーディオ/ビデオストリーミングアプリケーション、ゲームアプリケーション、およびその他のリアルタイムネットワークアプリケーションの最適化に役立ちます。

Unreliable QUIC datagrams can also be used to implement an IP packet tunnel over QUIC, such as for a Virtual Private Network (VPN). Internet-layer tunneling protocols generally require a reliable and authenticated handshake followed by unreliable secure communication.

信頼性の低いQUICデータグラムは、仮想プライベートネットワーク（VPN）など、QUICを介したIPパケットトンネルの実装にも使用できます。インターネット層トンネリングプロトコルには通常、信頼性の高い認証済みハンドシェイクと、それに続く信頼性の低い安全な通信が必要です。

3. Transport Parameter​

This document defines a new transport parameter, max_datagram_frame_size (value 0x20). This parameter represents the maximum size of a DATAGRAM frame (including the frame type, length, and payload) that the endpoint is willing to receive, in bytes.

このドキュメントでは、新しいトランスポートパラメータ max_datagram_frame_size（値0x20）を定義します。このパラメータは、エンドポイントが受信する意思のあるDATAGRAMフレーム（フレームタイプ、長さ、ペイロードを含む）の最大サイズをバイト単位で表します。

4. Datagram Frame Types​

This document defines two new frame types:

このドキュメントでは、次の2つの新しいフレームタイプを定義します。

  • DATAGRAM (0x30): A DATAGRAM frame containing application data. The frame does not contain a length field; the data extends to the end of the packet.
  • DATAGRAM (0x30): アプリケーションデータを含むDATAGRAMフレーム。フレームには長さフィールドが含まれていません。データはパケットの終わりまで続きます。
  • DATAGRAM_WITH_LEN (0x31): A DATAGRAM frame containing application data. The frame contains a length field.
  • DATAGRAM_WITH_LEN (0x31): アプリケーションデータを含むDATAGRAMフレーム。フレームには長さフィールドが含まれています。

5. Behavior and Usage​

5.1. Multiplexing Datagrams​

DATAGRAM frames are multiplexed with other QUIC frames within QUIC packets.

DATAGRAMフレームは、QUICパケット内の他のQUICフレームと多重化されます。

5.2. Acknowledgement Handling​

Although DATAGRAM frames are not retransmitted upon loss, they are acknowledged. This allows the sender to maintain congestion control state and potentially gather statistics about delivery.

DATAGRAMフレームは損失時に再送信されませんが、確認応答されます。これにより、送信者は輻輳制御状態を維持し、配信に関する統計を収集できる可能性があります。

5.3. Flow Control​

DATAGRAM frames are not subject to flow control. The max_datagram_frame_size transport parameter limits the size of individual frames, but there is no limit on the total number of bytes or frames.

DATAGRAMフレームはフロー制御の対象ではありません。max_datagram_frame_sizeトランスポートパラメータは個々のフレームのサイズを制限しますが、バイトまたはフレームの総数に制限はありません。

5.4. Congestion Control​

DATAGRAM frames are congestion controlled. The sender MUST respect the congestion controller's limits when sending DATAGRAM frames.

DATAGRAMフレームは輻輳制御されます。送信者は、DATAGRAMフレームを送信するときに、輻輳コントローラーの制限を尊重しなければなりません（MUST）。

6. Security Considerations​

The security considerations for this document are similar to those for QUIC [RFC9000]. The use of unreliable datagrams introduces some additional considerations, such as the potential for amplification attacks if the datagrams are used to reflect traffic.

このドキュメントのセキュリティに関する考慮事項は、QUIC [RFC9000]の考慮事項と同様です。信頼性の低いデータグラムを使用すると、データグラムがトラフィックの反映に使用される場合の増幅攻撃の可能性など、いくつかの追加の考慮事項が生じます。

7. IANA Considerations​

7.1. QUIC Transport Parameter​

This document registers a new value in the "QUIC Transport Parameters" registry:

このドキュメントでは、「QUIC Transport Parameters」レジストリに新しい値を登録します。

  • Value: 0x20
  • Parameter Name: max_datagram_frame_size
  • Status: permanent
  • Specification: RFC 9221

7.2. QUIC Frame Types​

This document registers two new values in the "QUIC Frame Types" registry:

このドキュメントでは、「QUIC Frame Types」レジストリに2つの新しい値を登録します。

  • Value: 0x30-0x31
  • Frame Name: DATAGRAM
  • Status: permanent
  • Specification: RFC 9221

8. References​

8.1. Normative References​

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, https://www.rfc-editor.org/info/rfc2119.

[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, https://www.rfc-editor.org/info/rfc9000.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, https://www.rfc-editor.org/info/rfc8174.

8.2. Informative References​

[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, https://www.rfc-editor.org/info/rfc0768.

[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, https://www.rfc-editor.org/info/rfc6347.

Acknowledgements​

The authors would like to thank...

著者は、...に感謝します。

Authors' Addresses​

Tommy Pauly Apple Inc. Email: [email protected]

Eric Kinnear Apple Inc. Email: [email protected]

David Schinazi Google LLC Email: [email protected]

に最終更新