Change:
This adds some additional security considerations, touching on privacy considerations at the same time. Do we want to say anything about IP fragmentation, or at least point to some existing guidance around how to avoid sharp edges there? Please feel free to reframe or modify the text as you see fit!

Discussion:
However, these mechanisms cannot tunnel other IP protocols IANA-PN nor convey fields of the IP header. <del> This document describes a protocol for tunnelling IP to an HTTP </del> <ins> This document describes a protocol for tunnelling IP through an HTTP </ins> server acting as an IP-specific proxy over HTTP.  This can be used for various use cases such as point-to-network VPN, secure point-to- point communication, or general-purpose packet tunnelling.

defines protocol types, the definition format uses the notation from QUIC.  This specification uses the variable-length integer encoding from QUIC.  Variable-length integer values do not need to be encoded <del> on the minimum number of bytes necessary. </del> <ins> in the minimum number of bytes necessary. </ins> Note that, when the HTTP version in use does not support multiplexing streams (such as HTTP/1.1), any reference to "stream" in this

10. There are significant risks in allowing arbitrary clients to <del> establish a tunnel that permits sending to arbitrary hosts, as that could allow bad actors to send traffic and have it attributed to the IP proxy.  IP proxies SHOULD restrict its use to authenticated users. The HTTP Authorization header HTTP MAY be used to authenticate clients.  More complex authentication schemes are out of scope for this document but can be implemented using extensions. </del> <ins> establish a tunnel that permits sending to arbitrary hosts, regardless of whether tunnels are scoped to specific hosts or not. Bad actors could abuse this capability to send traffic and have it attributed to the IP proxy.  IP proxies SHOULD restrict its use to authenticated users.  Depending on the deployment, possible authentication mechanisms include mutual TLS between clients and proxies, HTTP-based authentication via the HTTP Authorization header HTTP, or even bearer tokens.  Proxies can enforce policies for authenticated users to further constrain client behavior or deal with possible abuse.  For example, proxies can rate limit individual clients that send an excessively large amount of traffic through the proxy.  As another example, proxies can restrict address (prefix) assignment to clients based on certain client attributes such as geographic location. Address assignment can have privacy implications for endpoints.  For example, if a proxy partitions its address space by the number of authenticated clients and then assigns distinct address ranges to each client, target hosts could use this information to determine when IP packets correspond to the same client.  Avoiding such tracking vectors may be important for certain proxy deployments. Proxies SHOULD avoid persistent per-client address (prefix) assignment when possible. </ins> Falsifying IP source addresses in sent traffic has been common for denial of service attacks.  Implementations of this mechanism need to