httpbis                                                      B. Schwartz
Internet-Draft                                                    Google
Intended status: Standards Track                           June 25, 2018
Expires: December 27, 2018


      Hybrid Encapsulation Layer for IP and UDP Messages (HELIUM)
                    draft-schwartz-httpbis-helium-00

Abstract

   HELIUM is a protocol that can be used to implement a UDP proxy, a
   VPN, or a hybrid of these.  It is intended to run over a reliable,
   secure substrate transport.  It can serve a variety of use cases, but
   its initial purpose is to enable HTTP proxies to forward non-TCP
   flows.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on December 27, 2018.

Copyright Notice

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

   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.



Schwartz                Expires December 27, 2018               [Page 1]


Internet-Draft                   HELIUM                        June 2018


Table of Contents

   1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  HELIUM Inner Protocol (HIP) . . . . . . . . . . . . . . . . .   3
     2.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Requirements  . . . . . . . . . . . . . . . . . . . . . .   4
     2.3.  Abstract Structure  . . . . . . . . . . . . . . . . . . .   4
       2.3.1.  Error codes . . . . . . . . . . . . . . . . . . . . .   6
     2.4.  CBOR-based Encoding (HIP-CBOR)  . . . . . . . . . . . . .   7
     2.5.  Addressing  . . . . . . . . . . . . . . . . . . . . . . .   8
       2.5.1.  IP Header . . . . . . . . . . . . . . . . . . . . . .   9
       2.5.2.  UDP Header  . . . . . . . . . . . . . . . . . . . . .   9
     2.6.  Example Configurations  . . . . . . . . . . . . . . . . .   9
       2.6.1.  Single IP tunnel  . . . . . . . . . . . . . . . . . .   9
       2.6.2.  Multiple source IPs in one context  . . . . . . . . .   9
       2.6.3.  Domain-based proxy  . . . . . . . . . . . . . . . . .  10
       2.6.4.  UDP proxy with PMTUD and traceroute . . . . . . . . .  10
       2.6.5.  Advanced DNS queries  . . . . . . . . . . . . . . . .  10
       2.6.6.  UDP Server Application  . . . . . . . . . . . . . . .  11
       2.6.7.  High-Performance Delay-based Congestion Control . . .  11
     2.7.  Optimizations . . . . . . . . . . . . . . . . . . . . . .  11
   3.  WebSocket as a HELIUM Substrate (HELIUM-WebSocket)  . . . . .  12
     3.1.  Direct Configuration  . . . . . . . . . . . . . . . . . .  12
     3.2.  Implicit Configuration from an HTTP proxy . . . . . . . .  12
     3.3.  Optimizations . . . . . . . . . . . . . . . . . . . . . .  13
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  13
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .  13
     6.2.  Informative References  . . . . . . . . . . . . . . . . .  14
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Overview

   This proposal describes a network tunnel that is intended as a
   natural extension or complement to existing HTTP proxies.  It has two
   components

   o  A flexible packet-oriented tunneling protocol that can act as
      either a VPN or a UDP proxy (Section 2)

   o  A substrate for this protocol that allows it to run as part of an
      HTTPS server (Section 3)

   This design combines the benefits of several existing protocols, such
   as [OpenConnect] and [TURN].  Like OpenConnect, this protocol gains
   the privacy, authentication, and management benefits of HTTPS.  Like




Schwartz                Expires December 27, 2018               [Page 2]


Internet-Draft                   HELIUM                        June 2018


   TURN, this protocol can be used as a UDP proxy for realtime and P2P
   applications.

2.  HELIUM Inner Protocol (HIP)

   The protocol is designed to span two different use cases

   o  a UDP tunnel (proxy)

   o  an IP tunnel (VPN)

   These two use cases are normally handled by entirely separate
   protocols, like [TURN] and [L2TP].  However, UDP is fundamentally
   very similar to IP (differing mostly by the addition of a 2-byte
   "port number"), so it seems plausible that a single protocol may
   serve both purposes.  Additionally, a UDP proxy can be enriched by
   partial support for ICMP (enabling [PMTUD], traceroute, etc.), so
   there may be configurations that benefit from blending these uses.

   The protocol is intended to run between a client and a proxy, on a
   substrate that provides confidentiality, integrity, flow control,
   congestion control, and reliability (at least optionally).  It should
   take advantage of substrates that support out-of-order delivery, but
   still function acceptably on strictly ordered transports.

2.1.  Terminology

   o  Proxy: the server implementing this protocol, acting as a UDP
      proxy or IP tunnel endpoint

   o  Client: the endpoint that is implementing this protocol on the
      client side

   o  Destination: a service that the client is trying to reach through
      the proxy

   o  Context: the identity of the transport session used to transfer
      messages between a client and the proxy (e.g. one WebSocket)

   o  Substrate: the transport protocol used to transfer these messages
      (e.g.  WebSocket)

   o  Flow: a sequence of related packets between the client and a
      single destination

   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



Schwartz                Expires December 27, 2018               [Page 3]


Internet-Draft                   HELIUM                        June 2018


   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.2.  Requirements

   o  It shall be possible for a proxy to operate in an environment
      without elevated privileges.

      *  Such a proxy might only support operating as a UDP tunnel.

   o  It shall be possible for a proxy with elevated privileges to
      operate without any parsing of IP payloads.

      *  Such a proxy would operate as an IP tunnel.

   o  A client can direct the proxy to send multiple packets from the
      same IP (and UDP port).

   o  A client can tell what IP address and port the proxy is using to
      communicate on its behalf.

      *  A client can bind an address (or address:port) and learn it
         before emitting any packets.

   o  A client can tell if the proxy doesn't support a feature it's
      trying to use.

   o  New connections can be established without waiting for a roundtrip
      between client and proxy.

   o  The protocol enables good performance when tunneling streams that
      use delay-based congestion control (e.g.  TCP Vegas, [BBR],
      [RMCAT-GCC]).

   o  The client has an option to let the proxy resolve DNS names
      itself, with a latency benefit.

   o  The proxy can be implemented with tightly bounded memory usage.

2.3.  Abstract Structure

   Each HIP message consists of a type, optional metadata, and at most
   one packet (or prefix of a packet).  The packet (or prefix) is a
   standard [IPv4] or [IPv6] packet, starting with the IP header.

   There are three message types defined: "outbound", "inbound", and
   "meta".




Schwartz                Expires December 27, 2018               [Page 4]


Internet-Draft                   HELIUM                        June 2018


   A message from the client to the proxy is always of type "outbound".
   It always includes a complete packet for the proxy to send to the
   destination (potentially after header modifications).  The possible
   metadata fields that this message may contain are as follows:

   o  id (integer): An ID number identifying this message.  If present,
      the client is implicitly requesting a "meta" message from the
      proxy.  A client MUST NOT reuse an ID until a "meta" reply message
      is received.

   o  domain (UTF-8 string): A DNS name to override the destination IP.
      The proxy will perform an A or AAAA lookup, depending on the IP
      version of the included packet.  The proxy will buffer the packet
      until name lookup completes.  The proxy SHOULD avoid creating
      duplicate outstanding DNS queries, and SHOULD cache the result to
      provide a consistent mapping.

   o  dns (integer): The presence of this option indicates that the
      client wishes to direct the packet to one of the proxy's preferred
      DNS servers.  Its value is an index into the proxy's list of
      preferred recursive resolvers for this IP version, modulo the
      length of the list.  This option overrides the destination IP, and
      MUST NOT appear in a message with the "domain" option.

   A message from the proxy to the client may be of type "inbound" or
   "meta".  An "inbound" message contains a packet that the proxy
   received from the destination, unmodified, including the IP header.
   It contains one metadata field:

   o  timestamp (integer): A timestamp in microseconds modulo 2^32,
      indicating when the proxy received this packet from the
      destination.  The absolute base time is unspecified, as this is
      only used for computing time differences.  If the proxy
      reassembled the packet from fragments, this timestamp is the time
      when reassembly completed.

   A "meta" message is only sent by the proxy to a client after it
   receives an "outbound" message with an ID from the client.  If the
   proxy modified the outbound packet in any way, the "meta" message
   MUST contain a prefix of the outbound packet as sent, including any
   parts that were modified.  Changes might include the source IP,
   destination IP, TTL, DSCP priority, UDP source port, etc.  If there
   was an error, the proxy MAY include a modified prefix that would not
   have encountered the error (e.g. by changing the protocol ID from an
   unsupported protocol (e.g.  TCP) to a supported protocol (e.g.
   UDP)).  The message contains the following metadata:





Schwartz                Expires December 27, 2018               [Page 5]


Internet-Draft                   HELIUM                        June 2018


   o  id (integer): This is the ID number of the "outbound" message to
      which this is a reply.

   o  error (Array of integer): If present, these error codes indicate
      why the proxy could not send the packet contained in the
      "outbound" message to the destination.

   o  timestamp (integer): The time when the outbound packet was sent
      from the proxy to the destination, in the same format used for
      "inbound" messages.  If there was an error, this is the time that
      the error was detected.

   If the proxy receives a message from the client of an unrecognized
   type, and the message has an "id" field, the server SHOULD reply with
   a "meta" message matching that ID and indicating an "Unsupported
   message type" error.

   If the proxy receives a message from the client with unknown metadata
   fields, it SHOULD ignore the unknown fields and process the message
   as normal.

   If the proxy receives an "outbound" message with an all-zero
   destination address and no address-overriding metadata, the proxy
   SHOULD rewrite the packet for transmission and establish any required
   address or port mappings, but not attempt to send the packet.  If an
   ID number is present, the proxy SHOULD reply with a "meta" message
   indicating success unless a non-address-related error occurred.

   All messages can also include padding.  Padding can be represented as
   a metadata field named "padding" whose value is discarded by the
   recipient.

   All integer values defined in this section are non-negative.  All
   metadata keys defined here MUST NOT appear more than once.
   Recipients SHOULD treat negative numbers and repeated keys as
   metadata parsing errors.

2.3.1.  Error codes

   These are the numeric error codes that the proxy may include in a
   "meta" message










Schwartz                Expires December 27, 2018               [Page 6]


Internet-Draft                   HELIUM                        June 2018


               +------+------------------------------------+
               | Code | Error                              |
               +------+------------------------------------+
               | 1    | Unsupported message type           |
               |      |                                    |
               | 2    | Metadata parsing error             |
               |      |                                    |
               | 3    | Unsupported IP version             |
               |      |                                    |
               | 4    | Invalid IP header                  |
               |      |                                    |
               | 5    | Can't send fragment                |
               |      |                                    |
               | 6    | Packet too large                   |
               |      |                                    |
               | 7    | Unsupported IP option              |
               |      |                                    |
               | 8    | Unsupported protocol               |
               |      |                                    |
               | 9    | No route to host                   |
               |      |                                    |
               | 10   | Network unreachable                |
               |      |                                    |
               | 11   | Destination IP not allowed         |
               |      |                                    |
               | 12   | Destination DNS name not allowed   |
               |      |                                    |
               | 13   | DNS name has no address (NXDOMAIN) |
               |      |                                    |
               | 14   | DNS name resolution failed         |
               |      |                                    |
               | 15   | General server failure             |
               |      |                                    |
               | 16   | Usage limit exceeded               |
               +------+------------------------------------+

   Additional error codes may be defined in the future.

2.4.  CBOR-based Encoding (HIP-CBOR)

   To encode abstract HIP messages into concrete form, we use a [CBOR]-
   based encoding.  Other equivalent but incompatible encodings might be
   defined in the future.

   In this encoding, each message is formed by concatenating a one-byte
   type field, the metadata encoded in CBOR, and the packet or packet-
   prefix.




Schwartz                Expires December 27, 2018               [Page 7]


Internet-Draft                   HELIUM                        June 2018


                            +------+----------+
                            | Byte | Type     |
                            +------+----------+
                            | 0x01 | outbound |
                            |      |          |
                            | 0x02 | inbound  |
                            |      |          |
                            | 0x03 | meta     |
                            +------+----------+

   Metadata is encoded in CBOR as a Map.  For compactness, keys are
   integer-valued, with the following significance:

                            +-----+-----------+
                            | Key | Field     |
                            +-----+-----------+
                            | 0   | padding   |
                            |     |           |
                            | 1   | id        |
                            |     |           |
                            | 2   | domain    |
                            |     |           |
                            | 3   | dns       |
                            |     |           |
                            | 4   | timestamp |
                            |     |           |
                            | 5   | error     |
                            +-----+-----------+

   Additional message types and metadata fields may be defined in the
   future.

   When sending a message, endpoints SHOULD use the most compact
   available encoding of each metadata value.  When receiving a message,
   recipients are NOT REQUIRED to accept extremely inefficient or
   obscure encodings that are allowed by CBOR (e.g.  Bignums, Decimal
   Fractions).

2.5.  Addressing

   There are two major modes of operation that a proxy might use: IP
   tunnel and UDP tunnel.  Both operation modes require the proxy to
   inspect and possibly modify the IP header of the packet contained in
   an "outbound" message before sending the packet to the destination.
   The UDP tunnel mode in addition requires the proxy to inspect and
   possibly modify the UDP header in the IP payload.





Schwartz                Expires December 27, 2018               [Page 8]


Internet-Draft                   HELIUM                        June 2018


2.5.1.  IP Header

   Initially, the client does not know the IP address that the proxy
   will use as the source IP for packets it sends to the destination.
   The protocol does not require the client to correctly populate the
   source IP in its outbound packets to the proxy.  Rather, the client
   chooses any IP address, and the proxy will rewrite this address into
   one of its own outbound IP addresses.  Within a single context, the
   proxy MUST maintain a stable address mapping with a reasonable
   lifetime, similar to Network Address Translation [NAT].

   In IP tunnel mode, the proxy MUST NOT map multiple contexts to the
   same outbound IP address at the same time, as it would then be
   impossible to determine unambiguously where to direct packets
   received from the destination.  These outbound IP addresses MAY be
   publicly routable, or they MAY be in a reserved range (e.g.
   [RFC1918], [RFC4193]), using [NAT] to reach the public internet.

2.5.2.  UDP Header

   In UDP tunnel mode, the proxy MAY also rewrite the UDP source port of
   a packet before sending it to the destination.  The client has no way
   to initially know what source port the proxy will use in this mode,
   so the protocol does not require the client to correctly populate the
   source port in its outbound packets to the proxy.  In UDP tunnel
   mode, the proxy MAY map the same outbound IP address to multiple
   contexts with overlapping lifetimes, but the proxy SHOULD ensure that
   each UDP port is only mapped to a single context (i.e. an endpoint-
   independent mapping policy as described in [RFC4787]).  A proxy MAY
   violate this condition only if it serves a limited use case in which
   the correct context for an inbound packet will never be ambiguous.

2.6.  Example Configurations

2.6.1.  Single IP tunnel

   The client sends outbound IP packets to the server with empty
   metadata, and with various destinations and protocols (e.g.  ICMP,
   TCP, UDP).  The proxy rewrites the source address of all packets to
   match the reserved IP address for this client, and forwards all
   incoming packets to the client.

2.6.2.  Multiple source IPs in one context

   A client sends IP packets to the proxy with various source addresses,
   and includes an ID number in each one.  For each ID number, the
   server's "meta" reply reveals the proxy source IP that was mapped to
   the client's chosen source IP.  Once the client has learned the



Schwartz                Expires December 27, 2018               [Page 9]


Internet-Draft                   HELIUM                        June 2018


   mapping, the client stops including an ID number in subsequent
   messages.

2.6.3.  Domain-based proxy

   The client sends its initial flight of packets with an ID number and
   a domain in the metadata, and all zeroes in the destination IP
   address.  The "meta" replies indicate the rewritten destination IP
   address, which is the resolved location of the destination.  The
   client then emits subsequent packets with this destination IP
   address, and omits all metadata.

   If the proxy does not know the exact IP header used (e.g. because it
   is using the network through a UDP socket API), it will synthesize an
   approximate IP header for the "meta" replies.

2.6.4.  UDP proxy with PMTUD and traceroute

   The client sends "outbound" UDP packets with the ID set and varying
   size or TTL.  The proxy MUST NOT fragment unless the packet is IPv4
   and the DONT-FRAGMENT bit is unset.

   If the proxy could not send the packet because it was too large, it
   MUST reply with an error (Packet too large) and SHOULD include a
   rewritten header indicating the maximum size.

   If the proxy fragmented the packet, it will reply with success and a
   prefix including the size of the first fragment.

   If the proxy modified the outbound TTL, it will indicate this in the
   reply prefix.

   If the proxy receives an ICMP response (e.g.  Time Exceeded,
   Fragmentation Needed), it MAY forward it to the client.  To support
   this use case, it MUST do so.

   A proxy with this behavior can be implemented without elevated
   permissions on most common operating systems (see
   [I-D.martinsen-tram-stuntrace]).

2.6.5.  Advanced DNS queries

   The client sends an "outbound" UDP packet to port 53 with an ID
   number set, and a "dns" metadata value of 0.  This packet is a DNS
   query, perhaps for a DNSKEY, TLSA, or TXT record.

   The proxy overwrites the destination IP address with the IP of its
   first DNS server and sends the outbound packet.  It also sends a



Schwartz                Expires December 27, 2018              [Page 10]


Internet-Draft                   HELIUM                        June 2018


   "meta" message to the client, containing the IP header with this
   destination address, as well as the modified source address and port.

   The client is now waiting for an "inbound" message containing a reply
   from this DNS server to the modified source address and port.  If no
   reply is received within some timeout, the client retries.  This
   time, it sets a "dns" value of 1, indicating that the retry should
   use the proxy's second DNS server, if one exists.

2.6.6.  UDP Server Application

   The client sends an "outbound" UDP packet with an ID number set and
   all zeros in the destination IP.  The "meta" reply includes the
   rewritten source IP and port, which is bound to this context.  The
   client can now inform third parties to send data to this IP and port.

2.6.7.  High-Performance Delay-based Congestion Control

   The client is sending and receiving a flow that uses delay-based
   congestion control.  Between client and proxy, this flow is
   transmitted according to the congestion control behaviors of the
   HELIUM substrate.  From the proxy to the destination, congestion
   control is the responsibility of the client and destination.

   To monitor delay on the proxy-destination path, the client can
   include an ID number in every outbound message.  This will cause the
   proxy to reply with a "meta" message, including the send timestamp.
   By comparing these send timestamps with the receive timestamps in
   inbound messages, the client can accurately monitor the round-trip
   time between proxy and destination.

   If the proxy-destination roundtrip time is gradually increasing, the
   client can reduce its send rate below the limit imposed by the HELIUM
   substrate.

2.7.  Optimizations

   Proxies are NOT REQUIRED to perform reassembly of inbound IP
   fragments.  Proxies MAY reassemble IP fragments, or they MAY forward
   each fragment independently to the client.  This helps to limit proxy
   memory usage.

   When the client sends an "outbound" message with the "domain"
   metadata, the proxy has to buffer the corresponding packet until the
   domain name is resolved.  To limit memory usage, the proxy can "peek"
   at the query without removing it from the transport's receive buffer.
   The transport's flow control will then limit the amount of memory
   that the client can consume.



Schwartz                Expires December 27, 2018              [Page 11]


Internet-Draft                   HELIUM                        June 2018


3.  WebSocket as a HELIUM Substrate (HELIUM-WebSocket)

   The HELIUM Inner Protocol (Section 2) requires a substrate transport
   to deliver messages between client and proxy.  The WebSocket protocol
   is a suitable substrate.  Each HIP-CBOR message (Section 2.4) can be
   sent as a WebSocket message of type "binary".

   If a browser is configured to act as a HELIUM client, communicating
   with the proxy over a WebSocket, the WebSocket is controlled and
   terminated by the browser itself, not associated with any particular
   origin or webpage.

3.1.  Direct Configuration

   The location of a WebSocket HELIUM proxy is defined by a WebSocket
   URL, e.g. "wss://proxy.example/example-path".  If the client knows
   the address of a WebSocket HELIUM proxy, then the client may simply
   connect to the proxy by establishing a WebSocket connection.  The
   client's WebSocket handshake request MUST contain the "Sec-WebSocket-
   Protocol" header with value "helium-cbor" as well as an authorization
   header (e.g.  Proxy-Authorization) if needed.

3.2.  Implicit Configuration from an HTTP proxy

   Operators that run both an HTTP proxy, defined by some http or https
   URL, as well as a WebSocket HELIUM proxy, SHOULD return a response
   containing a new header, "Helium-Proxy-URL", when a client sends a
   proxy-specific request (e.g.  HTTP CONNECT) to the operator's HTTP
   proxy.  This new header, containing the WebSocket address of the
   HELIUM proxy, allows clients to discover the existence and location
   of a HELIUM proxy when they already know about an associated HTTP
   proxy.  Clients can then connect to the discovered HELIUM proxy as
   described above.

   In cases where user-facing proxy configuration options are limited
   (e.g. a web browser's settings menu), a user may not be able to
   directly configure a HELIUM proxy even if they know its address.  If
   an option for configuring a HTTP(S) proxy is available, however, the
   Helium-Proxy-URL header will allow a user to implicitly configure a
   WebSocket HELIUM proxy by entering an associated HTTP(S) proxy
   address.

   A client with access to both an HTTP(S) proxy and a HELIUM proxy
   SHOULD use the HTTP(S) proxy for all connections that it can support,
   and use the HELIUM proxy for all other network activity.






Schwartz                Expires December 27, 2018              [Page 12]


Internet-Draft                   HELIUM                        June 2018


3.3.  Optimizations

   After initiating the WebSocket connection, a client MAY send its
   initial HIP messages without waiting for the server's reply.  This
   saves 1 RTT, similar to TLS False Start [FALSESTART].

   Clients and proxies MAY negotiate WebSocket DEFLATE compression with
   context takeover (see Section 7 of [RFC7692]).  This will replace
   consistent headers with back-references to the previous matching
   packet.  On typical streams, this removes most of the IP and HIP-CBOR
   overhead, and can even compress the payload if it contains patterns
   that appear in each packet.  However, implementers should use caution
   when combining compression and padding, as compression can render
   some padding schemes ineffective.

4.  IANA Considerations

   The names and numbers of the HIP message types, metadata fields, and
   error codes will each require a new IANA registry.  Additionally,
   HELIUM-WebSocket will require registration of a new WebSocket
   Protocol ("helium-cbor") and a new HTTP header ("Helium-Proxy-URL").

5.  Acknowledgements

   Many thanks to Katharine Daly and Lucas Pardue for their early and
   extensive review of this proposal.

6.  References

6.1.  Normative References

   [CBOR]     Bormann, C. and P. Hoffman, "Concise Binary Object
              Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
              October 2013, <https://www.rfc-editor.org/info/rfc7049>.

   [IPv4]     Postel, J., "Internet Protocol", STD 5, RFC 791,
              DOI 10.17487/RFC0791, September 1981, <https://www.rfc-
              editor.org/info/rfc791>.

   [IPv6]     Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017, <https://www.rfc-
              editor.org/info/rfc8200>.

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



Schwartz                Expires December 27, 2018              [Page 13]


Internet-Draft                   HELIUM                        June 2018


   [RFC7692]  Yoshino, T., "Compression Extensions for WebSocket",
              RFC 7692, DOI 10.17487/RFC7692, December 2015,
              <https://www.rfc-editor.org/info/rfc7692>.

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

6.2.  Informative References

   [BBR]      Cardwell, N., Cheng, Y., Yeganeh, S., and V. Jacobson,
              "BBR Congestion Control", draft-cardwell-iccrg-bbr-
              congestion-control-00 (work in progress), July 2017.

   [FALSESTART]
              Langley, A., Modadugu, N., and B. Moeller, "Transport
              Layer Security (TLS) False Start", RFC 7918,
              DOI 10.17487/RFC7918, August 2016, <https://www.rfc-
              editor.org/info/rfc7918>.

   [I-D.martinsen-tram-stuntrace]
              Martinsen, P. and D. Wing, "STUN Traceroute", draft-
              martinsen-tram-stuntrace-01 (work in progress), June 2015.

   [L2TP]     Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
              G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
              RFC 2661, DOI 10.17487/RFC2661, August 1999,
              <https://www.rfc-editor.org/info/rfc2661>.

   [NAT]      Srisuresh, P. and K. Egevang, "Traditional IP Network
              Address Translator (Traditional NAT)", RFC 3022,
              DOI 10.17487/RFC3022, January 2001, <https://www.rfc-
              editor.org/info/rfc3022>.

   [OpenConnect]
              Mavrogiannopoulos, N., "The OpenConnect VPN Protocol
              Version 1.0", draft-mavrogiannopoulos-openconnect-00 (work
              in progress), September 2016.

   [PMTUD]    Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
              DOI 10.17487/RFC1191, November 1990, <https://www.rfc-
              editor.org/info/rfc1191>.

   [RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
              and E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
              <https://www.rfc-editor.org/info/rfc1918>.




Schwartz                Expires December 27, 2018              [Page 14]


Internet-Draft                   HELIUM                        June 2018


   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
              <https://www.rfc-editor.org/info/rfc4193>.

   [RFC4787]  Audet, F., Ed. and C. Jennings, "Network Address
              Translation (NAT) Behavioral Requirements for Unicast
              UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January
              2007, <https://www.rfc-editor.org/info/rfc4787>.

   [RMCAT-GCC]
              Holmer, S., Lundin, H., Carlucci, G., Cicco, L., and S.
              Mascolo, "A Google Congestion Control Algorithm for Real-
              Time Communication", draft-ietf-rmcat-gcc-02 (work in
              progress), July 2016.

   [TURN]     Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
              Relays around NAT (TURN): Relay Extensions to Session
              Traversal Utilities for NAT (STUN)", RFC 5766,
              DOI 10.17487/RFC5766, April 2010, <https://www.rfc-
              editor.org/info/rfc5766>.

Author's Address

   Ben Schwartz
   Google

   Email: bemasc@google.com
























Schwartz                Expires December 27, 2018              [Page 15]