idnits 2.17.00 (12 Aug 2021) /tmp/idnits41850/draft-schwartz-httpbis-helium-00.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 seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- The document date (June 25, 2018) is 1419 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) == Unused Reference: 'CBOR' is defined on line 598, but no explicit reference was found in the text ** Obsolete normative reference: RFC 7049 (ref. 'CBOR') (Obsoleted by RFC 8949) == Outdated reference: A later version (-02) exists of draft-cardwell-iccrg-bbr-congestion-control-00 == Outdated reference: A later version (-03) exists of draft-mavrogiannopoulos-openconnect-00 -- Obsolete informational reference (is this intentional?): RFC 5766 (ref. 'TURN') (Obsoleted by RFC 8656) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 httpbis B. Schwartz 3 Internet-Draft Google 4 Intended status: Standards Track June 25, 2018 5 Expires: December 27, 2018 7 Hybrid Encapsulation Layer for IP and UDP Messages (HELIUM) 8 draft-schwartz-httpbis-helium-00 10 Abstract 12 HELIUM is a protocol that can be used to implement a UDP proxy, a 13 VPN, or a hybrid of these. It is intended to run over a reliable, 14 secure substrate transport. It can serve a variety of use cases, but 15 its initial purpose is to enable HTTP proxies to forward non-TCP 16 flows. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on December 27, 2018. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. HELIUM Inner Protocol (HIP) . . . . . . . . . . . . . . . . . 3 54 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 4 56 2.3. Abstract Structure . . . . . . . . . . . . . . . . . . . 4 57 2.3.1. Error codes . . . . . . . . . . . . . . . . . . . . . 6 58 2.4. CBOR-based Encoding (HIP-CBOR) . . . . . . . . . . . . . 7 59 2.5. Addressing . . . . . . . . . . . . . . . . . . . . . . . 8 60 2.5.1. IP Header . . . . . . . . . . . . . . . . . . . . . . 9 61 2.5.2. UDP Header . . . . . . . . . . . . . . . . . . . . . 9 62 2.6. Example Configurations . . . . . . . . . . . . . . . . . 9 63 2.6.1. Single IP tunnel . . . . . . . . . . . . . . . . . . 9 64 2.6.2. Multiple source IPs in one context . . . . . . . . . 9 65 2.6.3. Domain-based proxy . . . . . . . . . . . . . . . . . 10 66 2.6.4. UDP proxy with PMTUD and traceroute . . . . . . . . . 10 67 2.6.5. Advanced DNS queries . . . . . . . . . . . . . . . . 10 68 2.6.6. UDP Server Application . . . . . . . . . . . . . . . 11 69 2.6.7. High-Performance Delay-based Congestion Control . . . 11 70 2.7. Optimizations . . . . . . . . . . . . . . . . . . . . . . 11 71 3. WebSocket as a HELIUM Substrate (HELIUM-WebSocket) . . . . . 12 72 3.1. Direct Configuration . . . . . . . . . . . . . . . . . . 12 73 3.2. Implicit Configuration from an HTTP proxy . . . . . . . . 12 74 3.3. Optimizations . . . . . . . . . . . . . . . . . . . . . . 13 75 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 76 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 77 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 6.1. Normative References . . . . . . . . . . . . . . . . . . 13 79 6.2. Informative References . . . . . . . . . . . . . . . . . 14 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 82 1. Overview 84 This proposal describes a network tunnel that is intended as a 85 natural extension or complement to existing HTTP proxies. It has two 86 components 88 o A flexible packet-oriented tunneling protocol that can act as 89 either a VPN or a UDP proxy (Section 2) 91 o A substrate for this protocol that allows it to run as part of an 92 HTTPS server (Section 3) 94 This design combines the benefits of several existing protocols, such 95 as [OpenConnect] and [TURN]. Like OpenConnect, this protocol gains 96 the privacy, authentication, and management benefits of HTTPS. Like 97 TURN, this protocol can be used as a UDP proxy for realtime and P2P 98 applications. 100 2. HELIUM Inner Protocol (HIP) 102 The protocol is designed to span two different use cases 104 o a UDP tunnel (proxy) 106 o an IP tunnel (VPN) 108 These two use cases are normally handled by entirely separate 109 protocols, like [TURN] and [L2TP]. However, UDP is fundamentally 110 very similar to IP (differing mostly by the addition of a 2-byte 111 "port number"), so it seems plausible that a single protocol may 112 serve both purposes. Additionally, a UDP proxy can be enriched by 113 partial support for ICMP (enabling [PMTUD], traceroute, etc.), so 114 there may be configurations that benefit from blending these uses. 116 The protocol is intended to run between a client and a proxy, on a 117 substrate that provides confidentiality, integrity, flow control, 118 congestion control, and reliability (at least optionally). It should 119 take advantage of substrates that support out-of-order delivery, but 120 still function acceptably on strictly ordered transports. 122 2.1. Terminology 124 o Proxy: the server implementing this protocol, acting as a UDP 125 proxy or IP tunnel endpoint 127 o Client: the endpoint that is implementing this protocol on the 128 client side 130 o Destination: a service that the client is trying to reach through 131 the proxy 133 o Context: the identity of the transport session used to transfer 134 messages between a client and the proxy (e.g. one WebSocket) 136 o Substrate: the transport protocol used to transfer these messages 137 (e.g. WebSocket) 139 o Flow: a sequence of related packets between the client and a 140 single destination 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 144 "OPTIONAL" in this document are to be interpreted as described in BCP 145 14 [RFC2119] [RFC8174] when, and only when, they appear in all 146 capitals, as shown here. 148 2.2. Requirements 150 o It shall be possible for a proxy to operate in an environment 151 without elevated privileges. 153 * Such a proxy might only support operating as a UDP tunnel. 155 o It shall be possible for a proxy with elevated privileges to 156 operate without any parsing of IP payloads. 158 * Such a proxy would operate as an IP tunnel. 160 o A client can direct the proxy to send multiple packets from the 161 same IP (and UDP port). 163 o A client can tell what IP address and port the proxy is using to 164 communicate on its behalf. 166 * A client can bind an address (or address:port) and learn it 167 before emitting any packets. 169 o A client can tell if the proxy doesn't support a feature it's 170 trying to use. 172 o New connections can be established without waiting for a roundtrip 173 between client and proxy. 175 o The protocol enables good performance when tunneling streams that 176 use delay-based congestion control (e.g. TCP Vegas, [BBR], 177 [RMCAT-GCC]). 179 o The client has an option to let the proxy resolve DNS names 180 itself, with a latency benefit. 182 o The proxy can be implemented with tightly bounded memory usage. 184 2.3. Abstract Structure 186 Each HIP message consists of a type, optional metadata, and at most 187 one packet (or prefix of a packet). The packet (or prefix) is a 188 standard [IPv4] or [IPv6] packet, starting with the IP header. 190 There are three message types defined: "outbound", "inbound", and 191 "meta". 193 A message from the client to the proxy is always of type "outbound". 194 It always includes a complete packet for the proxy to send to the 195 destination (potentially after header modifications). The possible 196 metadata fields that this message may contain are as follows: 198 o id (integer): An ID number identifying this message. If present, 199 the client is implicitly requesting a "meta" message from the 200 proxy. A client MUST NOT reuse an ID until a "meta" reply message 201 is received. 203 o domain (UTF-8 string): A DNS name to override the destination IP. 204 The proxy will perform an A or AAAA lookup, depending on the IP 205 version of the included packet. The proxy will buffer the packet 206 until name lookup completes. The proxy SHOULD avoid creating 207 duplicate outstanding DNS queries, and SHOULD cache the result to 208 provide a consistent mapping. 210 o dns (integer): The presence of this option indicates that the 211 client wishes to direct the packet to one of the proxy's preferred 212 DNS servers. Its value is an index into the proxy's list of 213 preferred recursive resolvers for this IP version, modulo the 214 length of the list. This option overrides the destination IP, and 215 MUST NOT appear in a message with the "domain" option. 217 A message from the proxy to the client may be of type "inbound" or 218 "meta". An "inbound" message contains a packet that the proxy 219 received from the destination, unmodified, including the IP header. 220 It contains one metadata field: 222 o timestamp (integer): A timestamp in microseconds modulo 2^32, 223 indicating when the proxy received this packet from the 224 destination. The absolute base time is unspecified, as this is 225 only used for computing time differences. If the proxy 226 reassembled the packet from fragments, this timestamp is the time 227 when reassembly completed. 229 A "meta" message is only sent by the proxy to a client after it 230 receives an "outbound" message with an ID from the client. If the 231 proxy modified the outbound packet in any way, the "meta" message 232 MUST contain a prefix of the outbound packet as sent, including any 233 parts that were modified. Changes might include the source IP, 234 destination IP, TTL, DSCP priority, UDP source port, etc. If there 235 was an error, the proxy MAY include a modified prefix that would not 236 have encountered the error (e.g. by changing the protocol ID from an 237 unsupported protocol (e.g. TCP) to a supported protocol (e.g. 238 UDP)). The message contains the following metadata: 240 o id (integer): This is the ID number of the "outbound" message to 241 which this is a reply. 243 o error (Array of integer): If present, these error codes indicate 244 why the proxy could not send the packet contained in the 245 "outbound" message to the destination. 247 o timestamp (integer): The time when the outbound packet was sent 248 from the proxy to the destination, in the same format used for 249 "inbound" messages. If there was an error, this is the time that 250 the error was detected. 252 If the proxy receives a message from the client of an unrecognized 253 type, and the message has an "id" field, the server SHOULD reply with 254 a "meta" message matching that ID and indicating an "Unsupported 255 message type" error. 257 If the proxy receives a message from the client with unknown metadata 258 fields, it SHOULD ignore the unknown fields and process the message 259 as normal. 261 If the proxy receives an "outbound" message with an all-zero 262 destination address and no address-overriding metadata, the proxy 263 SHOULD rewrite the packet for transmission and establish any required 264 address or port mappings, but not attempt to send the packet. If an 265 ID number is present, the proxy SHOULD reply with a "meta" message 266 indicating success unless a non-address-related error occurred. 268 All messages can also include padding. Padding can be represented as 269 a metadata field named "padding" whose value is discarded by the 270 recipient. 272 All integer values defined in this section are non-negative. All 273 metadata keys defined here MUST NOT appear more than once. 274 Recipients SHOULD treat negative numbers and repeated keys as 275 metadata parsing errors. 277 2.3.1. Error codes 279 These are the numeric error codes that the proxy may include in a 280 "meta" message 281 +------+------------------------------------+ 282 | Code | Error | 283 +------+------------------------------------+ 284 | 1 | Unsupported message type | 285 | | | 286 | 2 | Metadata parsing error | 287 | | | 288 | 3 | Unsupported IP version | 289 | | | 290 | 4 | Invalid IP header | 291 | | | 292 | 5 | Can't send fragment | 293 | | | 294 | 6 | Packet too large | 295 | | | 296 | 7 | Unsupported IP option | 297 | | | 298 | 8 | Unsupported protocol | 299 | | | 300 | 9 | No route to host | 301 | | | 302 | 10 | Network unreachable | 303 | | | 304 | 11 | Destination IP not allowed | 305 | | | 306 | 12 | Destination DNS name not allowed | 307 | | | 308 | 13 | DNS name has no address (NXDOMAIN) | 309 | | | 310 | 14 | DNS name resolution failed | 311 | | | 312 | 15 | General server failure | 313 | | | 314 | 16 | Usage limit exceeded | 315 +------+------------------------------------+ 317 Additional error codes may be defined in the future. 319 2.4. CBOR-based Encoding (HIP-CBOR) 321 To encode abstract HIP messages into concrete form, we use a [CBOR]- 322 based encoding. Other equivalent but incompatible encodings might be 323 defined in the future. 325 In this encoding, each message is formed by concatenating a one-byte 326 type field, the metadata encoded in CBOR, and the packet or packet- 327 prefix. 329 +------+----------+ 330 | Byte | Type | 331 +------+----------+ 332 | 0x01 | outbound | 333 | | | 334 | 0x02 | inbound | 335 | | | 336 | 0x03 | meta | 337 +------+----------+ 339 Metadata is encoded in CBOR as a Map. For compactness, keys are 340 integer-valued, with the following significance: 342 +-----+-----------+ 343 | Key | Field | 344 +-----+-----------+ 345 | 0 | padding | 346 | | | 347 | 1 | id | 348 | | | 349 | 2 | domain | 350 | | | 351 | 3 | dns | 352 | | | 353 | 4 | timestamp | 354 | | | 355 | 5 | error | 356 +-----+-----------+ 358 Additional message types and metadata fields may be defined in the 359 future. 361 When sending a message, endpoints SHOULD use the most compact 362 available encoding of each metadata value. When receiving a message, 363 recipients are NOT REQUIRED to accept extremely inefficient or 364 obscure encodings that are allowed by CBOR (e.g. Bignums, Decimal 365 Fractions). 367 2.5. Addressing 369 There are two major modes of operation that a proxy might use: IP 370 tunnel and UDP tunnel. Both operation modes require the proxy to 371 inspect and possibly modify the IP header of the packet contained in 372 an "outbound" message before sending the packet to the destination. 373 The UDP tunnel mode in addition requires the proxy to inspect and 374 possibly modify the UDP header in the IP payload. 376 2.5.1. IP Header 378 Initially, the client does not know the IP address that the proxy 379 will use as the source IP for packets it sends to the destination. 380 The protocol does not require the client to correctly populate the 381 source IP in its outbound packets to the proxy. Rather, the client 382 chooses any IP address, and the proxy will rewrite this address into 383 one of its own outbound IP addresses. Within a single context, the 384 proxy MUST maintain a stable address mapping with a reasonable 385 lifetime, similar to Network Address Translation [NAT]. 387 In IP tunnel mode, the proxy MUST NOT map multiple contexts to the 388 same outbound IP address at the same time, as it would then be 389 impossible to determine unambiguously where to direct packets 390 received from the destination. These outbound IP addresses MAY be 391 publicly routable, or they MAY be in a reserved range (e.g. 392 [RFC1918], [RFC4193]), using [NAT] to reach the public internet. 394 2.5.2. UDP Header 396 In UDP tunnel mode, the proxy MAY also rewrite the UDP source port of 397 a packet before sending it to the destination. The client has no way 398 to initially know what source port the proxy will use in this mode, 399 so the protocol does not require the client to correctly populate the 400 source port in its outbound packets to the proxy. In UDP tunnel 401 mode, the proxy MAY map the same outbound IP address to multiple 402 contexts with overlapping lifetimes, but the proxy SHOULD ensure that 403 each UDP port is only mapped to a single context (i.e. an endpoint- 404 independent mapping policy as described in [RFC4787]). A proxy MAY 405 violate this condition only if it serves a limited use case in which 406 the correct context for an inbound packet will never be ambiguous. 408 2.6. Example Configurations 410 2.6.1. Single IP tunnel 412 The client sends outbound IP packets to the server with empty 413 metadata, and with various destinations and protocols (e.g. ICMP, 414 TCP, UDP). The proxy rewrites the source address of all packets to 415 match the reserved IP address for this client, and forwards all 416 incoming packets to the client. 418 2.6.2. Multiple source IPs in one context 420 A client sends IP packets to the proxy with various source addresses, 421 and includes an ID number in each one. For each ID number, the 422 server's "meta" reply reveals the proxy source IP that was mapped to 423 the client's chosen source IP. Once the client has learned the 424 mapping, the client stops including an ID number in subsequent 425 messages. 427 2.6.3. Domain-based proxy 429 The client sends its initial flight of packets with an ID number and 430 a domain in the metadata, and all zeroes in the destination IP 431 address. The "meta" replies indicate the rewritten destination IP 432 address, which is the resolved location of the destination. The 433 client then emits subsequent packets with this destination IP 434 address, and omits all metadata. 436 If the proxy does not know the exact IP header used (e.g. because it 437 is using the network through a UDP socket API), it will synthesize an 438 approximate IP header for the "meta" replies. 440 2.6.4. UDP proxy with PMTUD and traceroute 442 The client sends "outbound" UDP packets with the ID set and varying 443 size or TTL. The proxy MUST NOT fragment unless the packet is IPv4 444 and the DONT-FRAGMENT bit is unset. 446 If the proxy could not send the packet because it was too large, it 447 MUST reply with an error (Packet too large) and SHOULD include a 448 rewritten header indicating the maximum size. 450 If the proxy fragmented the packet, it will reply with success and a 451 prefix including the size of the first fragment. 453 If the proxy modified the outbound TTL, it will indicate this in the 454 reply prefix. 456 If the proxy receives an ICMP response (e.g. Time Exceeded, 457 Fragmentation Needed), it MAY forward it to the client. To support 458 this use case, it MUST do so. 460 A proxy with this behavior can be implemented without elevated 461 permissions on most common operating systems (see 462 [I-D.martinsen-tram-stuntrace]). 464 2.6.5. Advanced DNS queries 466 The client sends an "outbound" UDP packet to port 53 with an ID 467 number set, and a "dns" metadata value of 0. This packet is a DNS 468 query, perhaps for a DNSKEY, TLSA, or TXT record. 470 The proxy overwrites the destination IP address with the IP of its 471 first DNS server and sends the outbound packet. It also sends a 472 "meta" message to the client, containing the IP header with this 473 destination address, as well as the modified source address and port. 475 The client is now waiting for an "inbound" message containing a reply 476 from this DNS server to the modified source address and port. If no 477 reply is received within some timeout, the client retries. This 478 time, it sets a "dns" value of 1, indicating that the retry should 479 use the proxy's second DNS server, if one exists. 481 2.6.6. UDP Server Application 483 The client sends an "outbound" UDP packet with an ID number set and 484 all zeros in the destination IP. The "meta" reply includes the 485 rewritten source IP and port, which is bound to this context. The 486 client can now inform third parties to send data to this IP and port. 488 2.6.7. High-Performance Delay-based Congestion Control 490 The client is sending and receiving a flow that uses delay-based 491 congestion control. Between client and proxy, this flow is 492 transmitted according to the congestion control behaviors of the 493 HELIUM substrate. From the proxy to the destination, congestion 494 control is the responsibility of the client and destination. 496 To monitor delay on the proxy-destination path, the client can 497 include an ID number in every outbound message. This will cause the 498 proxy to reply with a "meta" message, including the send timestamp. 499 By comparing these send timestamps with the receive timestamps in 500 inbound messages, the client can accurately monitor the round-trip 501 time between proxy and destination. 503 If the proxy-destination roundtrip time is gradually increasing, the 504 client can reduce its send rate below the limit imposed by the HELIUM 505 substrate. 507 2.7. Optimizations 509 Proxies are NOT REQUIRED to perform reassembly of inbound IP 510 fragments. Proxies MAY reassemble IP fragments, or they MAY forward 511 each fragment independently to the client. This helps to limit proxy 512 memory usage. 514 When the client sends an "outbound" message with the "domain" 515 metadata, the proxy has to buffer the corresponding packet until the 516 domain name is resolved. To limit memory usage, the proxy can "peek" 517 at the query without removing it from the transport's receive buffer. 518 The transport's flow control will then limit the amount of memory 519 that the client can consume. 521 3. WebSocket as a HELIUM Substrate (HELIUM-WebSocket) 523 The HELIUM Inner Protocol (Section 2) requires a substrate transport 524 to deliver messages between client and proxy. The WebSocket protocol 525 is a suitable substrate. Each HIP-CBOR message (Section 2.4) can be 526 sent as a WebSocket message of type "binary". 528 If a browser is configured to act as a HELIUM client, communicating 529 with the proxy over a WebSocket, the WebSocket is controlled and 530 terminated by the browser itself, not associated with any particular 531 origin or webpage. 533 3.1. Direct Configuration 535 The location of a WebSocket HELIUM proxy is defined by a WebSocket 536 URL, e.g. "wss://proxy.example/example-path". If the client knows 537 the address of a WebSocket HELIUM proxy, then the client may simply 538 connect to the proxy by establishing a WebSocket connection. The 539 client's WebSocket handshake request MUST contain the "Sec-WebSocket- 540 Protocol" header with value "helium-cbor" as well as an authorization 541 header (e.g. Proxy-Authorization) if needed. 543 3.2. Implicit Configuration from an HTTP proxy 545 Operators that run both an HTTP proxy, defined by some http or https 546 URL, as well as a WebSocket HELIUM proxy, SHOULD return a response 547 containing a new header, "Helium-Proxy-URL", when a client sends a 548 proxy-specific request (e.g. HTTP CONNECT) to the operator's HTTP 549 proxy. This new header, containing the WebSocket address of the 550 HELIUM proxy, allows clients to discover the existence and location 551 of a HELIUM proxy when they already know about an associated HTTP 552 proxy. Clients can then connect to the discovered HELIUM proxy as 553 described above. 555 In cases where user-facing proxy configuration options are limited 556 (e.g. a web browser's settings menu), a user may not be able to 557 directly configure a HELIUM proxy even if they know its address. If 558 an option for configuring a HTTP(S) proxy is available, however, the 559 Helium-Proxy-URL header will allow a user to implicitly configure a 560 WebSocket HELIUM proxy by entering an associated HTTP(S) proxy 561 address. 563 A client with access to both an HTTP(S) proxy and a HELIUM proxy 564 SHOULD use the HTTP(S) proxy for all connections that it can support, 565 and use the HELIUM proxy for all other network activity. 567 3.3. Optimizations 569 After initiating the WebSocket connection, a client MAY send its 570 initial HIP messages without waiting for the server's reply. This 571 saves 1 RTT, similar to TLS False Start [FALSESTART]. 573 Clients and proxies MAY negotiate WebSocket DEFLATE compression with 574 context takeover (see Section 7 of [RFC7692]). This will replace 575 consistent headers with back-references to the previous matching 576 packet. On typical streams, this removes most of the IP and HIP-CBOR 577 overhead, and can even compress the payload if it contains patterns 578 that appear in each packet. However, implementers should use caution 579 when combining compression and padding, as compression can render 580 some padding schemes ineffective. 582 4. IANA Considerations 584 The names and numbers of the HIP message types, metadata fields, and 585 error codes will each require a new IANA registry. Additionally, 586 HELIUM-WebSocket will require registration of a new WebSocket 587 Protocol ("helium-cbor") and a new HTTP header ("Helium-Proxy-URL"). 589 5. Acknowledgements 591 Many thanks to Katharine Daly and Lucas Pardue for their early and 592 extensive review of this proposal. 594 6. References 596 6.1. Normative References 598 [CBOR] Bormann, C. and P. Hoffman, "Concise Binary Object 599 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 600 October 2013, . 602 [IPv4] Postel, J., "Internet Protocol", STD 5, RFC 791, 603 DOI 10.17487/RFC0791, September 1981, . 606 [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 607 (IPv6) Specification", STD 86, RFC 8200, 608 DOI 10.17487/RFC8200, July 2017, . 611 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 612 Requirement Levels", BCP 14, RFC 2119, 613 DOI 10.17487/RFC2119, March 1997, . 616 [RFC7692] Yoshino, T., "Compression Extensions for WebSocket", 617 RFC 7692, DOI 10.17487/RFC7692, December 2015, 618 . 620 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 621 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 622 May 2017, . 624 6.2. Informative References 626 [BBR] Cardwell, N., Cheng, Y., Yeganeh, S., and V. Jacobson, 627 "BBR Congestion Control", draft-cardwell-iccrg-bbr- 628 congestion-control-00 (work in progress), July 2017. 630 [FALSESTART] 631 Langley, A., Modadugu, N., and B. Moeller, "Transport 632 Layer Security (TLS) False Start", RFC 7918, 633 DOI 10.17487/RFC7918, August 2016, . 636 [I-D.martinsen-tram-stuntrace] 637 Martinsen, P. and D. Wing, "STUN Traceroute", draft- 638 martinsen-tram-stuntrace-01 (work in progress), June 2015. 640 [L2TP] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 641 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 642 RFC 2661, DOI 10.17487/RFC2661, August 1999, 643 . 645 [NAT] Srisuresh, P. and K. Egevang, "Traditional IP Network 646 Address Translator (Traditional NAT)", RFC 3022, 647 DOI 10.17487/RFC3022, January 2001, . 650 [OpenConnect] 651 Mavrogiannopoulos, N., "The OpenConnect VPN Protocol 652 Version 1.0", draft-mavrogiannopoulos-openconnect-00 (work 653 in progress), September 2016. 655 [PMTUD] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 656 DOI 10.17487/RFC1191, November 1990, . 659 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 660 and E. Lear, "Address Allocation for Private Internets", 661 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 662 . 664 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 665 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 666 . 668 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 669 Translation (NAT) Behavioral Requirements for Unicast 670 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 671 2007, . 673 [RMCAT-GCC] 674 Holmer, S., Lundin, H., Carlucci, G., Cicco, L., and S. 675 Mascolo, "A Google Congestion Control Algorithm for Real- 676 Time Communication", draft-ietf-rmcat-gcc-02 (work in 677 progress), July 2016. 679 [TURN] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 680 Relays around NAT (TURN): Relay Extensions to Session 681 Traversal Utilities for NAT (STUN)", RFC 5766, 682 DOI 10.17487/RFC5766, April 2010, . 685 Author's Address 687 Ben Schwartz 688 Google 690 Email: bemasc@google.com