draft-ietf-masque-connect-udp-05.txt   draft-ietf-masque-connect-udp-06.txt 
MASQUE D. Schinazi MASQUE D. Schinazi
Internet-Draft Google LLC Internet-Draft Google LLC
Intended status: Standards Track 7 October 2021 Intended status: Standards Track 25 October 2021
Expires: 10 April 2022 Expires: 28 April 2022
UDP Proxying Support for HTTP UDP Proxying Support for HTTP
draft-ietf-masque-connect-udp-05 draft-ietf-masque-connect-udp-06
Abstract Abstract
This document describes how to proxy UDP over HTTP. Similar to how This document describes how to proxy UDP over HTTP. Similar to how
the CONNECT method allows proxying TCP over HTTP, this document the CONNECT method allows proxying TCP over HTTP, this document
defines a new mechanism to proxy UDP. It is built using HTTP defines a new mechanism to proxy UDP. It is built using HTTP
Extended CONNECT. Extended CONNECT.
Discussion Venues Discussion Venues
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 10 April 2022. This Internet-Draft will expire on 28 April 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 8, line 6 skipping to change at page 8, line 6
4. Encoding of Proxied UDP Packets 4. Encoding of Proxied UDP Packets
UDP packets are encoded using HTTP Datagrams [HTTP-DGRAM] with the UDP packets are encoded using HTTP Datagrams [HTTP-DGRAM] with the
UDP_PAYLOAD HTTP Datagram Format Type (see value in Section 7.2). UDP_PAYLOAD HTTP Datagram Format Type (see value in Section 7.2).
When using the UDP_PAYLOAD HTTP Datagram Format Type, the payload of When using the UDP_PAYLOAD HTTP Datagram Format Type, the payload of
a UDP packet (referred to as "data octets" in [UDP]) is sent a UDP packet (referred to as "data octets" in [UDP]) is sent
unmodified in the "HTTP Datagram Payload" field of an HTTP Datagram. unmodified in the "HTTP Datagram Payload" field of an HTTP Datagram.
In order to use HTTP Datagrams, the client will first decide whether In order to use HTTP Datagrams, the client will first decide whether
or not to use HTTP Datagram Contexts and then register its context ID or not it will attempt to use HTTP Datagram Contexts and then
(or lack thereof) using the corresponding registration capsule, see register its context ID (or lack thereof) using the corresponding
[HTTP-DGRAM]. registration capsule, see [HTTP-DGRAM].
When sending a REGISTER_DATAGRAM_CONTEXT or When sending a registration capsule using the "Datagram Format Type"
REGISTER_DATAGRAM_NO_CONTEXT capsule using the "Datagram Format Type"
set to UDP_PAYLOAD, the "Datagram Format Additional Data" field SHALL set to UDP_PAYLOAD, the "Datagram Format Additional Data" field SHALL
be empty. Servers MUST NOT register contexts using the UDP_PAYLOAD be empty. Servers MUST NOT register contexts using the UDP_PAYLOAD
HTTP Datagram Format Type. Clients MUST NOT register more than one HTTP Datagram Format Type. Clients MUST NOT register more than one
context using the UDP_PAYLOAD HTTP Datagram Format Type. Endpoints context using the UDP_PAYLOAD HTTP Datagram Format Type. Endpoints
MUST NOT close contexts using the UDP_PAYLOAD HTTP Datagram Format MUST NOT close contexts using the UDP_PAYLOAD HTTP Datagram Format
Type. If an endpoint detects a violation of any of these Type. If an endpoint detects a violation of any of these
requirements, it MUST abort the stream. requirements, it MUST abort the stream.
Clients MAY optimistically start sending proxied UDP packets before Clients MAY optimistically start sending proxied UDP packets before
receiving the response to its UDP proxying request, noting however receiving the response to its UDP proxying request, noting however
skipping to change at page 11, line 31 skipping to change at page 11, line 31
[H3] Bishop, M., "Hypertext Transfer Protocol Version 3 [H3] Bishop, M., "Hypertext Transfer Protocol Version 3
(HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf-
quic-http-34, 2 February 2021, quic-http-34, 2 February 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-quic- <https://datatracker.ietf.org/doc/html/draft-ietf-quic-
http-34>. http-34>.
[HTTP-DGRAM] [HTTP-DGRAM]
Schinazi, D. and L. Pardue, "Using Datagrams with HTTP", Schinazi, D. and L. Pardue, "Using Datagrams with HTTP",
Work in Progress, Internet-Draft, draft-ietf-masque-h3- Work in Progress, Internet-Draft, draft-ietf-masque-h3-
datagram-04, 6 October 2021, datagram-05, 25 October 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-masque- <https://datatracker.ietf.org/doc/html/draft-ietf-masque-
h3-datagram-04>. h3-datagram-05>.
[MESSAGING] [MESSAGING]
Fielding, R. T., Nottingham, M., and J. Reschke, Fielding, R. T., Nottingham, M., and J. Reschke,
"HTTP/1.1", Work in Progress, Internet-Draft, draft-ietf- "HTTP/1.1", Work in Progress, Internet-Draft, draft-ietf-
httpbis-messaging-19, 12 September 2021, httpbis-messaging-19, 12 September 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis- <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
messaging-19>. messaging-19>.
[QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based [QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000, Multiplexed and Secure Transport", RFC 9000,
skipping to change at page 12, line 39 skipping to change at page 12, line 39
8.2. Informative References 8.2. Informative References
[BEHAVE] Audet, F., Ed. and C. Jennings, "Network Address [BEHAVE] Audet, F., Ed. and C. Jennings, "Network Address
Translation (NAT) Behavioral Requirements for Unicast Translation (NAT) Behavioral Requirements for Unicast
UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January
2007, <https://www.rfc-editor.org/rfc/rfc4787>. 2007, <https://www.rfc-editor.org/rfc/rfc4787>.
[PROXY-STATUS] [PROXY-STATUS]
Nottingham, M. and P. Sikora, "The Proxy-Status HTTP Nottingham, M. and P. Sikora, "The Proxy-Status HTTP
Response Header Field", Work in Progress, Internet-Draft, Response Header Field", Work in Progress, Internet-Draft,
draft-ietf-httpbis-proxy-status-06, 16 August 2021, draft-ietf-httpbis-proxy-status-08, 13 October 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis- <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
proxy-status-06>. proxy-status-08>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89, Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006, RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/rfc/rfc4443>. <https://www.rfc-editor.org/rfc/rfc4443>.
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion
Notification", RFC 6040, DOI 10.17487/RFC6040, November Notification", RFC 6040, DOI 10.17487/RFC6040, November
2010, <https://www.rfc-editor.org/rfc/rfc6040>. 2010, <https://www.rfc-editor.org/rfc/rfc6040>.
 End of changes. 9 change blocks. 
13 lines changed or deleted 12 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/