idnits 2.17.1 draft-cms-masque-connect-ip-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (12 July 2021) is 1019 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 7540 (ref. 'H2') (Obsoleted by RFC 9113) == Outdated reference: A later version (-11) exists of draft-ietf-masque-h3-datagram-03 ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 7235 (ref. 'AUTH') (Obsoleted by RFC 9110) == Outdated reference: A later version (-03) exists of draft-ietf-masque-ip-proxy-reqs-02 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MASQUE A. Chernyakhovsky 3 Internet-Draft D. McCall 4 Intended status: Standards Track D. Schinazi 5 Expires: 13 January 2022 Google LLC 6 12 July 2021 8 The CONNECT-IP HTTP Method 9 draft-cms-masque-connect-ip-01 11 Abstract 13 This document describes the CONNECT-IP HTTP method. CONNECT-IP is 14 similar to CONNECT-UDP, but allows transmitting IP packets, without 15 being limited to just TCP like CONNECT or UDP like CONNECT-UDP. 17 Discussion Venues 19 This note is to be removed before publishing as an RFC. 21 Discussion of this document takes place on the Multiplexed 22 Application Substrate over QUIC Encryption Working Group mailing list 23 (masque@ietf.org), which is archived at 24 https://mailarchive.ietf.org/arch/browse/masque/. 26 Source for this draft and an issue tracker can be found at 27 https://github.com/DavidSchinazi/draft-cms-masque-connect-ip. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on 13 January 2022. 46 Copyright Notice 48 Copyright (c) 2021 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 53 license-info) in effect on the date of publication of this document. 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. Code Components 56 extracted from this document must include Simplified BSD License text 57 as described in Section 4.e of the Trust Legal Provisions and are 58 provided without warranty as described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Conventions and Definitions . . . . . . . . . . . . . . . 3 64 2. The CONNECT-IP Method . . . . . . . . . . . . . . . . . . . . 3 65 3. Transmitting IP Packets using HTTP Datagrams . . . . . . . . 4 66 4. Forwarding of IP Packets . . . . . . . . . . . . . . . . . . 5 67 5. Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 6. Capsules . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 6.1. ADDRESS_ASSIGN Capsule . . . . . . . . . . . . . . . . . 6 70 6.2. ADDRESS_REQUEST Capsule . . . . . . . . . . . . . . . . . 6 71 6.3. ROUTE_ADVERTISEMENT Capsule . . . . . . . . . . . . . . . 7 72 6.4. ROUTE_REJECTION Capsule . . . . . . . . . . . . . . . . . 8 73 6.5. ROUTE_RESET Capsule . . . . . . . . . . . . . . . . . . . 8 74 6.6. SHUTDOWN Capsule . . . . . . . . . . . . . . . . . . . . 9 75 6.7. ATOMIC_START Capsule . . . . . . . . . . . . . . . . . . 9 76 6.8. ATOMIC_END Capsule . . . . . . . . . . . . . . . . . . . 10 77 7. Extensibility Considerations . . . . . . . . . . . . . . . . 10 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 79 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 80 9.1. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 11 81 9.2. Capsule Type Registrations . . . . . . . . . . . . . . . 11 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 84 10.2. Informative References . . . . . . . . . . . . . . . . . 13 85 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 13 86 A.1. Consumer VPN . . . . . . . . . . . . . . . . . . . . . . 13 87 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 90 1. Introduction 92 This document describes the CONNECT-IP HTTP method. CONNECT-IP is 93 similar to CONNECT-UDP, but allows transmitting IP packets, without 94 being limited to just TCP like CONNECT or UDP like CONNECT-UDP. 96 CONNECT-IP allows endpoints to set up an IP tunnel between one 97 another. This can be used to implement a consumer VPN, point-to- 98 point, point-to-network, and network-to-network capabilities as 99 described in [REQS]. 101 1.1. Conventions and Definitions 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 105 "OPTIONAL" in this document are to be interpreted as described in BCP 106 14 [RFC2119] [RFC8174] when, and only when, they appear in all 107 capitals, as shown here. 109 In this document, we use the term "proxy" to refer to the HTTP server 110 that responds to the CONNECT-IP request. If there are HTTP 111 intermediaries (as defined in Section 2.3 of [RFC7230]) between the 112 client and the proxy, those are referred to as "intermediaries" in 113 this document. 115 2. The CONNECT-IP Method 117 The CONNECT-IP method establishes a stream to an endpoint server that 118 then permits the exchange of control data, such as IP address 119 information, reachable IP ranges, and other relevant information for 120 successfully transmitting IP datagrams between hosts. 122 The request-target of a CONNECT-IP request is a URI [URI] which uses 123 the "https" scheme and a client-specified path. When using HTTP/2 124 [H2] or later, CONNECT-IP requests use HTTP pseudo-headers with the 125 following requirements: 127 * The ":method" pseudo-header field is set to "CONNECT-IP". 129 * The ":scheme" pseudo-header field is set to "https". 131 * The ":path" pseudo-header field is set to the value provided by 132 the client. That value MUST NOT be empty. 134 * The ":authority" pseudo-header field contains the host and port of 135 the proxy. The target of a CONNECT-IP request is the server 136 providing the CONNECT-IP featureset, not an individual endpoint 137 with which a connection is desired. 139 A CONNECT-IP request that does not conform to these restrictions is 140 malformed (see [H2], Section 8.1.2.6). 142 Any 2xx (Successful) response indicates that the proxy is willing to 143 open an IP tunnel between it and the client. Any response other than 144 a successful response indicates that the tunnel has not yet been 145 formed. 147 A proxy MUST NOT send any Transfer-Encoding or Content-Length header 148 fields in a 2xx (Successful) response to CONNECT-IP. A client MUST 149 treat a successful response to CONNECT-IP containing any Content- 150 Length or Transfer-Encoding header fields as malformed. 152 A payload within a CONNECT-IP request message has no defined 153 semantics; a CONNECT-IP request with a non-empty payload is 154 malformed. Note that the CONNECT-IP stream is used to convey control 155 messages, but they are not semantically part of the request or 156 response themselves. 158 Responses to the CONNECT-IP method are not cacheable. 160 The lifetime of the tunnel is tied to the CONNECT-IP stream. Closing 161 the stream (via the FIN bit on a QUIC STREAM frame, or a QUIC 162 RESET_STREAM frame) closes the associated tunnel. 164 3. Transmitting IP Packets using HTTP Datagrams 166 IP packets are sent using HTTP Datagrams [HTTP-DGRAM]. The HTTP 167 Datagram Payload contains a full IP packet, from the IP Version field 168 until the last byte of the IP Payload. In order to use HTTP 169 Datagrams, the CONNECT-IP client will first decide whether or not to 170 use HTTP Datagram Contexts and then register its context ID (or lack 171 thereof) using the corresponding registration capsule, see 172 [HTTP-DGRAM]. 174 Since HTTP Datagrams require prior negotiation (for example, in 175 HTTP/3 it is necessary to both send and receive the H3_DATAGRAM 176 SETTINGS Parameter), clients MUST NOT send any HTTP Datagrams until 177 they have established support on a given connection. If negotiation 178 of HTTP Datagrams fails (for example if an HTTP/3 SETTINGS frame was 179 received without the H3_DATAGRAM SETTINGS Parameter), the client MUST 180 consider its CONNECT-IP request as failed. 182 4. Forwarding of IP Packets 184 Since CONNECT-IP allows the transmission of IP packets over HTTP, 185 CONNECT-IP endpoints will most often forward these packets to and 186 from traditional IP interfaces. As such, CONNECT-IP endpoints act as 187 IP routers. When a CONNECT-IP endpoint receives an HTTP Datagram 188 containing an IP packet, it will parse the packet's IP header, 189 perform any local policy checks (e.g., source address validation), 190 check their routing table to pick an outbound interface, and then use 191 an implementation-specific mechanism (such as raw sockets) to send 192 the IP packet on that interface. 194 Conversely, when a CONNECT-IP endpoint receives an IP packet whose 195 destination address does not match any local addresses, it consults 196 its routing table to pick a forwarding destination, and if the table 197 points to a CONNECT-IP tunnel, the endpoint performs the same 198 forwarding checks before transmitting the packet inside the tunnel. 200 Note that CONNECT-IP endpoints will decrement the IP Hop Count (or 201 TTL) upon encapsulation but not decapsulation. In other words, the 202 Hop Count is decremented right before an IP packet is transmitted in 203 an HTTP Datagram. This prevents infinite loops in the presence of 204 routing loops, and matches the choices in IPsec [IPSEC]. 206 Endpoints MAY implement additional filtering policies on the IP 207 packets they forward. 209 5. Routes 211 Endpoints have the ability to advertise and reject routes using the 212 ROUTE_ADVERTISEMENT (Section 6.3) and ROUTE_REJECTION (Section 6.3) 213 capsule. Note that these capsules are purely informational: receipt 214 of a ROUTE_ADVERTISEMENT capsule does not require the recipient to 215 start routing traffic to its peer. Additionally, if an endpoint 216 receives a ROUTE_REJECTION for a given prefix that it had previously 217 received a ROUTE_ADVERTISEMENT capsule for, then the two cancel out 218 and the endpoint MUST remove its state from the ROUTE_ADVERTISEMENT 219 capsule instead of installing new state for the ROUTE_REJECTION 220 capsule. Conversely, the same is true of a ROUTE_ADVERTISEMENT that 221 matches a previous ROUTE_REJECTION. Routes are handled via longest- 222 prefix-first preference, meaning that if a given IP prefix is covered 223 by multiple route advertisement and route rejections, the one with 224 the longest prefix is used. 226 When processing ROUTE_ADVERTISEMENT capsules, endpoints MUST check 227 their local policy before deciding whether to forward packets to 228 their peer. Since ignoring these capsules is allowed by the 229 protocol, such policy decisions will not prevent interoperability. 231 6. Capsules 233 6.1. ADDRESS_ASSIGN Capsule 235 The ADDRESS_ASSIGN capsule allows an endpoint to inform its peer that 236 it has assigned an IP address to it. It allows assigning a prefix 237 which can contain multiple addresses. This capsule uses a Capsule 238 Type of 0xfff100. Its value uses the following format: 240 ADDRESS_ASSIGN Capsule { 241 IP Version (8), 242 IP Address (32..128), 243 IP Prefix Length (8), 244 } 246 Figure 1: ADDRESS_ASSIGN Capsule Format 248 IP Version: IP Version of this address assignment. MUST be either 4 249 or 6. 251 IP Address: Assigned IP address. If the IP Version field has value 252 4, the IP Address field SHALL have a length of 32 bits. If the IP 253 Version field has value 6, the IP Address field SHALL have a 254 length of 128 bits. 256 IP Prefix Length: Length of the IP Prefix assigned, in bits. MUST 257 be lesser or equal to the length of the IP Address field, in bits. 259 6.2. ADDRESS_REQUEST Capsule 261 The ADDRESS_REQUEST capsule allows an endpoint to request assignment 262 of an IP address from its peer. It allows the endpoint to optionally 263 indicate a preference for which address it would get assigned. This 264 capsule uses a Capsule Type of 0xfff101. Its value uses the 265 following format: 267 ADDRESS_REQUEST Capsule { 268 IP Version (8), 269 IP Address (32..128), 270 IP Prefix Length (8), 271 } 273 Figure 2: ADDRESS_REQUEST Capsule Format 275 IP Version: IP Version of this address request. MUST be either 4 or 276 6. 278 IP Address: Requested IP address. If the IP Version field has value 279 4, the IP Address field SHALL have a length of 32 bits. If the IP 280 Version field has value 6, the IP Address field SHALL have a 281 length of 128 bits. 283 IP Prefix Length: Length of the IP Prefix requested, in bits. MUST 284 be lesser or equal to the length of the IP Address field, in bits. 286 Upon receiving the ADDRESS_REQUEST capsule, an endpoint SHOULD assign 287 an IP address to its peer, and then respond with an ADDRESS_ASSIGN 288 capsule to inform the peer of the assignment. 290 6.3. ROUTE_ADVERTISEMENT Capsule 292 The ROUTE_ADVERTISEMENT capsule allows an endpoint to communicate to 293 its peer that it is willing to route traffic to a given prefix. This 294 indicates that the sender has an existing route to the prefix, and 295 notifies its peer that if the receiver of the ROUTE_ADVERTISEMENT 296 capsule sends IP packets for this prefix in HTTP Datagrams, the 297 sender of the capsule will forward them along its preexisting route. 298 This capsule uses a Capsule Type of 0xfff102. Its value uses the 299 following format: 301 ROUTE_ADVERTISEMENT Capsule { 302 IP Version (8), 303 IP Address (32..128), 304 IP Prefix Length (8), 305 } 307 Figure 3: ROUTE_ADVERTISEMENT Capsule Format 309 IP Version: IP Version of this route advertisement. MUST be either 310 4 or 6. 312 IP Address: IP address of the advertised route. If the IP Version 313 field has value 4, the IP Address field SHALL have a length of 32 314 bits. If the IP Version field has value 6, the IP Address field 315 SHALL have a length of 128 bits. 317 IP Prefix Length: Length of the IP Prefix of the advertised route, 318 in bits. MUST be lesser or equal to the length of the IP Address 319 field, in bits. 321 Upon receiving the ROUTE_ADVERTISEMENT capsule, an endpoint MAY start 322 routing IP packets in that prefix to its peer. 324 6.4. ROUTE_REJECTION Capsule 326 The ROUTE_REJECTION capsule allows an endpoint to communicate to its 327 peer that it is not willing to route traffic to a given prefix. This 328 capsule uses a Capsule Type of 0xfff103. Its value uses the 329 following format: 331 ROUTE_REJECTION Capsule { 332 IP Version (8), 333 IP Address (32..128), 334 IP Prefix Length (8), 335 } 337 Figure 4: ROUTE_REJECTION Capsule Format 339 IP Version: IP Version of this route rejection. MUST be either 4 or 340 6. 342 IP Address: IP address of the rejected route. If the IP Version 343 field has value 4, the IP Address field SHALL have a length of 32 344 bits. If the IP Version field has value 6, the IP Address field 345 SHALL have a length of 128 bits. 347 IP Prefix Length: Length of the IP Prefix of the advertised route, 348 in bits. MUST be lesser or equal to the length of the IP Address 349 field, in bits. 351 Upon receiving the ROUTE_REJECTION capsule, an endpoint MUST stop 352 routing IP packets in that prefix to its peer. Note that this 353 capsule can be reordered with DATAGRAM frames, and therefore an 354 endpoint that receives packets for routes it has rejected MUST NOT 355 treat that as an error. 357 6.5. ROUTE_RESET Capsule 359 The ROUTE_RESET capsule allows an endpoint to cancel any routes it 360 had previously advertised or denied. This capsule uses a Capsule 361 Type of 0xfff104. Its value uses the following format: 363 ROUTE_RESET Capsule { 364 } 366 Figure 5: ROUTE_RESET Capsule Format 368 Upon receiving the ROUTE_RESET capsule, an endpoint MUST stop routing 369 IP packets to its peer. Note that this capsule can be reordered with 370 DATAGRAM frames, and therefore an endpoint that receives packets for 371 routes it has rejected MUST NOT treat that as an error. 373 The main purpose of the ROUTE_RESET capsule is to allow endpoints to 374 not have to remember the full list of routes they have shared with 375 their peer. In practice, it is expected that ROUTE_RESET capsules 376 will be closely followed by ROUTE_ADVERTISEMENT capsules that will 377 refill the routing table that was just cleared. 379 6.6. SHUTDOWN Capsule 381 The SHUTDOWN capsule allows an endpoint to communicate to its peer 382 that it is about to close the CONNECT-IP stream, with a string 383 explaining the reason for the shutdown. This capsule uses a Capsule 384 Type of 0xfff105. Its value uses the following format: 386 SHUTDOWN Capsule { 387 Reason Phrase (..), 388 } 390 Figure 6: SHUTDOWN Capsule Format 392 Reason Phrase: Additional diagnostic information for the shutdown. 393 This SHOULD be a UTF-8 encoded string [UTF8], though the frame 394 does not carry information, such as language tags, that would aid 395 comprehension by any entity other than the one that created the 396 text. 398 Note that the SHUTDOWN capsule is informational, the tunnel is only 399 closed when its corresponding CONNECT-IP stream is closed. Endpoints 400 MAY close the tunnel with a reason phrase by sending the SHUTDOWN 401 capsule with the FIN bit set on the underlying QUIC STREAM frame that 402 carried it. 404 6.7. ATOMIC_START Capsule 406 The ATOMIC_START capsule allows an endpoint to create an atomic set 407 of capsules. This capsule uses a Capsule Type of 0xfff106. Its 408 value uses the following format: 410 ATOMIC_START Capsule { 411 } 413 Figure 7: ATOMIC_START Capsule Format 415 Upon receiving an ATOMIC_START capsule, an endpoint MUST buffer all 416 incoming known CONNECT-IP-specific capsules (i.e., capsules defined 417 in this document) until it receives an ATOMIC_END capsule. Endpoints 418 MUST NOT send two ATOMIC_START capsules without an ATOMIC_END capsule 419 between them. 421 Endpoints MUST NOT buffer unknown capsules. Endpoints MAY choose to 422 immediately process IP_PACKET and SHUTDOWN capsules instead of 423 buffering them. Capsules defined in other documents are by default 424 not buffered by ATOMIC_START. Extensions that register new capsule 425 types MAY specify that these capsules should be buffered by 426 ATOMIC_START, and whether it is allowed to skip buffering for them. 428 The purpose of this frame is to avoid timing issues where an endpoint 429 installs a route before an important route rejection was received. 430 Endpoints SHOULD group their initial configuration into an atomic 431 block to allow their peer to mark the tunnel as operational once the 432 whole block is parsed. 434 6.8. ATOMIC_END Capsule 436 The ATOMIC_END capsule allows an endpoint to end an atomic set of 437 capsules. This capsule uses a Capsule Type of 0xfff107. Its value 438 uses the following format: 440 ATOMIC_END Capsule { 441 } 443 Figure 8: ATOMIC_END Capsule Format 445 Upon receiving an ATOMIC_END capsule, an endpoint MUST parse all 446 previously buffered capsules, in order of receipt. Endpoints MUST 447 NOT send an ATOMIC_END capsule without a preceding ATOMIC_START 448 capsule. 450 7. Extensibility Considerations 452 CONNECT-IP can be extended via multiple mechanisms to increase 453 functionality. There are three main ways to extend CONNECT-IP: HTTP 454 headers, Capsule Types, and HTTP Datagram Registration Extension 455 Data. For example, an authentication extension could define an HTTP 456 header that allows endpoints to send authentication credentials to 457 their peer during the creation of the tunnel. Alternatively, one 458 could specify an extension that defines a new Capsule Type which 459 allows exchanging DNS configuration between endpoints. Additionally, 460 an extension to CONNECT-IP can use multiple HTTP Datagram Contexts 461 [HTTP-DGRAM] simultaneously to compress some IP packets by 462 associating the compression context with an HTTP Datagram Context ID. 464 8. Security Considerations 466 There are significant risks in allowing arbitrary clients to 467 establish a tunnel to arbitrary servers, as that could allow bad 468 actors to send traffic and have it attributed to the proxy. Proxies 469 that support CONNECT-IP SHOULD restrict its use to authenticated 470 users. The HTTP Authorization header [AUTH] MAY be used to 471 authenticate clients. More complex authentication schemes are out of 472 scope for this document but can be implemented using CONNECT-IP 473 extensions. 475 Since CONNECT-IP endpoints can proxy IP packets send by their peer, 476 they SHOULD follow the guidance in [BCP38] to help prevent denial of 477 service attacks. 479 In theory, endpoints could use ROUTE_ADVERTISEMENT capsules to divert 480 traffic from naive endpoints. To avoid this, receivers of 481 ROUTE_ADVERTISEMENT capsules MUST check their local policy before 482 acting on such capsules, see Section 5. 484 9. IANA Considerations 486 9.1. HTTP Method 488 This document will request IANA to register "CONNECT-IP" in the HTTP 489 Method Registry (IETF review) maintained at 490 . 492 +-------------+------+------------+---------------+ 493 | Method Name | Safe | Idempotent | Reference | 494 +-------------+------+------------+---------------+ 495 | CONNECT-IP | no | no | This document | 496 +-------------+------+------------+---------------+ 498 9.2. Capsule Type Registrations 500 This document will request IANA to add the following values to the 501 "HTTP Capsule Types" registry created by [HTTP-DGRAM]: 503 +----------+---------------------+---------------------+---------------+ 504 | Value | Type | Description | Reference | 505 +----------+---------------------+---------------------+---------------+ 506 | 0xfff100 | ADDRESS_ASSIGN | Address Assignment | This document | 507 | 0xfff101 | ADDRESS_REQUEST | Address Request | This document | 508 | 0xfff102 | ROUTE_ADVERTISEMENT | Route Advertisement | This document | 509 | 0xfff103 | ROUTE_REJECTION | Route Rejection | This document | 510 | 0xfff104 | ROUTE_RESET | Route Reset | This document | 511 | 0xfff105 | SHUTDOWN | Shutdown Reason | This document | 512 | 0xfff106 | ATOMIC_START | Atomic Start | This document | 513 | 0xfff107 | ATOMIC_END | Atomic End | This document | 514 +----------+---------------------+---------------------+---------------+ 516 10. References 518 10.1. Normative References 520 [BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering: 521 Defeating Denial of Service Attacks which employ IP Source 522 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 523 May 2000, . 525 [H2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 526 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 527 DOI 10.17487/RFC7540, May 2015, 528 . 530 [HTTP-DGRAM] 531 Schinazi, D. and L. Pardue, "Using Datagrams with HTTP", 532 Work in Progress, Internet-Draft, draft-ietf-masque-h3- 533 datagram-03, 12 July 2021, 534 . 537 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 538 Requirement Levels", BCP 14, RFC 2119, 539 DOI 10.17487/RFC2119, March 1997, 540 . 542 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 543 Protocol (HTTP/1.1): Message Syntax and Routing", 544 RFC 7230, DOI 10.17487/RFC7230, June 2014, 545 . 547 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 548 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 549 May 2017, . 551 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 552 Resource Identifier (URI): Generic Syntax", STD 66, 553 RFC 3986, DOI 10.17487/RFC3986, January 2005, 554 . 556 [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 557 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 558 2003, . 560 10.2. Informative References 562 [AUTH] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 563 Protocol (HTTP/1.1): Authentication", RFC 7235, 564 DOI 10.17487/RFC7235, June 2014, 565 . 567 [IPSEC] Kent, S. and K. Seo, "Security Architecture for the 568 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 569 December 2005, . 571 [REQS] Chernyakhovsky, A., McCall, D., and D. Schinazi, 572 "Requirements for a MASQUE Protocol to Proxy IP Traffic", 573 Work in Progress, Internet-Draft, draft-ietf-masque-ip- 574 proxy-reqs-02, 30 April 2021, 575 . 578 Appendix A. Examples 580 A.1. Consumer VPN 582 In this scenario, the client will typically receive a single IP 583 address that the proxy has picked from a pool of addresses it 584 maintains. The client will route all traffic through the tunnel. 585 The exchange could look as follows: 587 Client Server 589 ADDRESS_REQUEST --------> 590 IP Version = 4 591 IP Address = 0.0.0.0 592 IP Prefix Length = 0 594 <-------- ADDRESS_ASSIGN 595 IP Version = 4 596 IP Address = 192.0.2.42 597 IP Prefix Length = 32 599 <-------- ROUTE_ADVERTISEMENT 600 IP Version = 4 601 IP Address = 0.0.0.0 602 IP Prefix Length = 0 604 Acknowledgments 606 The design of CONNECT-IP was inspired by discussions in the MASQUE 607 working group around [REQS]. The authors would like to thank 608 participants in those discussions for their feedback. 610 Authors' Addresses 612 Alex Chernyakhovsky 613 Google LLC 614 1600 Amphitheatre Parkway 615 Mountain View, California 94043, 616 United States of America 618 Email: achernya@google.com 620 Dallas McCall 621 Google LLC 622 1600 Amphitheatre Parkway 623 Mountain View, California 94043, 624 United States of America 626 Email: dallasmccall@google.com 627 David Schinazi 628 Google LLC 629 1600 Amphitheatre Parkway 630 Mountain View, California 94043, 631 United States of America 633 Email: dschinazi.ietf@gmail.com