Draft: draft-ietf-masque-connect-ip

Commentary: Almost all the changes here are editorial and exist to make connect - ip prose closer to the RFC 9298 finished product . There are also some non - editorial changes ( like specifying that connect - ip over h1 uses GET just like connect - udp ) but none of them should be controversial . 
 So some direct editorial things , some we may want to transfer to issues if further discussion is needed ?
Paragraph (version A):
This document describes a method of proxying IP packets over HTTP.
This protocol is similar to CONNECT-UDP, but allows transmitting
arbitrary IP packets, without being limited to just TCP like CONNECT
or UDP like CONNECT-UDP.
Paragraph (version A):
This document describes a method of proxying IP packets over HTTP.
When using HTTP/2 or HTTP/3, IP proxying uses HTTP Extended CONNECT
as described in EXT-CONNECT2 and EXT-CONNECT3.  When using HTTP/1.x,
IP proxying uses HTTP Upgrade as defined in SEMANTICS.  This protocol
is similar to CONNECT-UDP CONNECT-UDP, but allows transmitting
arbitrary IP packets, without being limited to just TCP like CONNECT
SEMANTICS or UDP like CONNECT-UDP.
Paragraph (version A):
The HTTP Upgrade Token defined for this mechanism is "connect-ip",
which is also referred to as CONNECT-IP in this document.
Paragraph (version A):
The CONNECT-IP protocol allows endpoints to set up a tunnel for
proxying IP packets using an HTTP proxy.  This can be used for
various solutions that include general-purpose packet tunnelling,
such as for a point-to-point or point-to-network VPN, or for limited
forwarding of packets to specific hosts.
Paragraph (version A):
Forwarded IP packets can be sent efficiently via the proxy using HTTP
Datagram support HTTP-DGRAM.
Paragraph (version B):
This document describes how to proxy IP packets in HTTP.  This
protocol is similar to UDP proxying in HTTP, but allows transmitting
arbitrary IP packets.  More specifically, this document defines a
protocol that allows an HTTP client to create an IP tunnel through an
HTTP server that acts as a proxy.
Paragraph (version B):
HTTP provides the CONNECT method (see HTTP) for creating a TCP TCP
tunnel to a proxy and a similar mechanism for UDP CONNECT-UDP.
However, these mechanisms cannot tunnel other protocols nor convey
fields of the IP header.
Paragraph (version B):
This document describes a protocol for tunnelling IP to an HTTP
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.
Paragraph (version B):
IP proxying operates similarly to UDP proxying CONNECT-UDP, whereby
the proxy itself is identified with an absolute URL, optionally
containing the traffic's destination.  Clients generate these URLs
using a URI Template TEMPLATE, as described in client-config.
Paragraph (version B):
This protocol supports all existing versions of HTTP by using HTTP
Datagrams HTTP-DGRAM.  When using HTTP/2 H2 or HTTP/3 H3, it uses
HTTP Extended CONNECT as described in EXT-CONNECT2 and EXT-CONNECT3.
When using HTTP/1.x H1, it uses HTTP Upgrade as defined in HTTP.
Paragraph (version A):
In this document, we use the term "proxy" to refer to the HTTP server
that responds to the CONNECT-IP request.  If there are HTTP
intermediaries (as defined in SEMANTICS) between the client and the
proxy, those are referred to as "intermediaries" in this document.
Paragraph (version A):
Clients are configured to use IP Proxying over HTTP via an URI
Template TEMPLATE.  The URI template MAY contain two variables:
"target" and "ipproto" (scope).  The optionality of the variables
needs to be considered when defining the template so that either the
variable is self-identifying or it works to exclude it in the syntax.
Paragraph (version B):
In this document, we use the term "IP proxy" to refer to the HTTP
server that responds to the IP proxying request.  If there are HTTP
intermediaries (as defined in HTTP) between the client and the proxy,
those are referred to as "intermediaries" in this document.
Paragraph (version B):
Note that, when the HTTP version in use does not support multiplexing
streams (such as HTTP/1.1), any reference to "stream" in this
document represents the entire connection.
Paragraph (version B):
Clients are configured to use IP proxying over HTTP via an URI
Template TEMPLATE.  The URI template MAY contain two variables:
"target" and "ipproto" (scope).  The optionality of the variables
needs to be considered when defining the template so that either the
variable is self-identifying or it is possible to exclude it in the
syntax.
Paragraph (version A):
The URI template MAY contain the two variables "target" and
"ipproto" and MAY contain other variables.  If the "target" or
"ipproto" variables are included, their values MUST NOT be empty.
Clients can instead use "*" to indicate wildcard or no-preference
values, see scope.
Paragraph (version B):
The URI template MAY contain the two variables "target" and
"ipproto" and MAY contain other variables.  If the "target" or
"ipproto" variables are included, their values MUST NOT be empty.
Clients can instead use "*" to indicate wildcard or no-preference
values; see scope.
Paragraph (version A):
As with CONNECT-UDP, some client configurations for CONNECT-IP
proxies will only allow the user to configure the proxy host and
proxy port.  Clients with such limitations MAY attempt to access IP
proxying capabilities using the default template, which is defined
as: "https://$PROXY_HOST:$PROXY_PORT/.well-known/masque/
ip/{target}/{ipproto}/", where $PROXY_HOST and $PROXY_PORT are the
configured host and port of the IP proxy, respectively.  IP proxy
deployments SHOULD offer service at this location if they need to
interoperate with such clients.
Paragraph (version B):
As with UDP proxying, some client configurations for IP proxies will
only allow the user to configure the proxy host and proxy port.
Clients with such limitations MAY attempt to access IP proxying
capabilities using the default template, which is defined as:
"https://$PROXY_HOST:$PROXY_PORT/.well-known/masque/
ip/{target}/{ipproto}/", where $PROXY_HOST and $PROXY_PORT are the
configured host and port of the IP proxy, respectively.  IP proxy
deployments SHOULD offer service at this location if they need to
interoperate with such clients.
Paragraph (version A):
This document defines the "connect-ip" HTTP Upgrade Token. "connect-
ip" uses the Capsule Protocol as defined in HTTP-DGRAM.
Paragraph (version A):
The ":method" pseudo-header field SHALL be set to "CONNECT".
Paragraph (version A):
The ":protocol" pseudo-header field SHALL be set to "connect-ip".
Paragraph (version A):
The ":authority" pseudo-header field SHALL contain the host and
port of the proxy, not an individual endpoint with which a
connection is desired.
Paragraph (version A):
The contents of the ":path" pseudo-header SHALL be determined by
the URI template expansion, see client-config.  Variables in the
URI template can determine the scope of the request, such as
requesting full-tunnel IP packet forwarding, or a specific proxied
flow, see scope.
Paragraph (version A):
The client SHOULD also include the "Capsule-Protocol" header with a
value of "?1" to negotiate support for sending and receiving HTTP
capsules (HTTP-DGRAM).
Paragraph (version A):
Any 2xx (Successful) response indicates that the proxy is willing to
open an IP forwarding tunnel between it and the client.  Any response
other than a successful response indicates that the tunnel has not
been formed.
Paragraph (version A):
A proxy MUST NOT send any Transfer-Encoding or Content-Length header
fields in a 2xx (Successful) response to the IP Proxying request.  A
client MUST treat a successful response containing any Content-Length
or Transfer-Encoding header fields as malformed.
Paragraph (version A):
The lifetime of the forwarding tunnel is tied to the CONNECT stream.
Closing the stream (in HTTP/3 via the FIN bit on a QUIC STREAM frame,
or a QUIC RESET_STREAM frame) closes the associated forwarding
tunnel.
Paragraph (version A):
Along with a successful response, the proxy can send capsules to
assign addresses and advertise routes to the client (capsules).  The
client can also assign addresses and advertise routes to the proxy
for network-to-network routing.
Paragraph (version A):
Unlike CONNECT-UDP requests, which require specifying a target host,
CONNECT-IP requests can allow endpoints to send arbitrary IP packets
to any host.  The client can choose to restrict a given request to a
specific prefix or IP protocol by adding parameters to its request.
When the server knows that a request is scoped to a target prefix or
protocol, it can leverage this information to optimize its resource
allocation; for example, the server can assign the same public IP
address to two CONNECT-IP requests that are scoped to different
prefixes and/or different protocols.
Paragraph (version A):
The scope of the request is indicated by the client to the proxy via
the "target" and "ipproto" variables of the URI Template; see client-
config.  Both the "target" and "ipproto" variables are optional; if
they are not included they are considered to carry the wildcard value
"*".
Paragraph (version B):
To allow negotiation of a tunnel for IP over HTTP, this document
defines the "connect-ip" HTTP Upgrade Token.  The resulting IP
tunnels use the Capsule Protocol (see HTTP-DGRAM) with HTTP Datagrams
in the format defined in payload-format.
Paragraph (version B):
To initiate an IP tunnel associated with a single HTTP stream, a
client issues a request containing the "connect-ip" upgrade token.
The target of the tunnel is indicated by the client to the UDP proxy
via the "target_host" and "target_port" variables of the URI
Template; see client-config.
Paragraph (version B):
A successful response indicates that the IP proxy is willing to open
an IP forwarding tunnel between it and the client.  Any response
other than a successful response indicates that the tunnel has not
been formed.
Paragraph (version B):
The lifetime of the IP forwarding tunnel is tied to the IP proxying
request stream.  Closing that stream (in HTTP/3 via the FIN bit on a
QUIC STREAM frame, or a QUIC RESET_STREAM frame) closes the
associated IP tunnel.
Paragraph (version B):
Along with a successful response, the IP proxy can send capsules to
assign addresses and advertise routes to the client (capsules).  The
client can also assign addresses and advertise routes to the IP proxy
for network-to-network routing.
Paragraph (version B):
By virtue of the definition of the Capsule Protocol (see HTTP-DGRAM),
IP proxying requests do not carry any message content.  Similarly,
successful IP proxying responses also do not carry any message
content.
Paragraph (version B):
the method SHALL be "GET".
Paragraph (version B):
the request SHALL include a single Host header field containing
the origin of the IP proxy.
Paragraph (version B):
the request SHALL include a Connection header field with value
"Upgrade" (note that this requirement is case-insensitive as per
HTTP).
Paragraph (version B):
the request SHALL include an Upgrade header field with value
"connect-ip".
Paragraph (version B):
An IP proxying request that does not conform to these restrictions is
malformed.  The recipient of such a malformed request MUST respond
with an error and SHOULD use the 400 (Bad Request) status code.
Paragraph (version B):
the HTTP status code on the response SHALL be 101 (Switching
Protocols).
Paragraph (version B):
the response SHALL include a Connection header field with value
"Upgrade" (note that this requirement is case-insensitive as per
HTTP).
Paragraph (version B):
the response SHALL include a single Upgrade header field with
value "connect-ip".
Paragraph (version B):
If any of these requirements are not met, the client MUST treat this
proxying attempt as failed and abort the connection.
Paragraph (version B):
The :method pseudo-header field SHALL be "CONNECT".
Paragraph (version B):
The :protocol pseudo-header field SHALL be "connect-ip".
Paragraph (version B):
The :authority pseudo-header field SHALL contain the authority of
the IP proxy.
Paragraph (version B):
The :path and :scheme pseudo-header fields SHALL NOT be empty.
Their values SHALL contain the scheme and path from the URI
Template after the URI Template expansion process has been
completed; see client-config.  Variables in the URI template can
determine the scope of the request, such as requesting full-tunnel
IP packet forwarding, or a specific proxied flow; see scope.
Paragraph (version B):
An IP proxying request that does not conform to these restrictions is
malformed (see H2 and H3).
Paragraph (version B):
the HTTP status code on the response SHALL be in the 2xx
(Successful) range.
Paragraph (version B):
If any of these requirements are not met, the client MUST treat this
proxying attempt as failed and abort the request.
Paragraph (version B):
Unlike UDP proxying requests, which require specifying a target host,
IP proxying requests can allow endpoints to send arbitrary IP packets
to any host.  The client can choose to restrict a given request to a
specific IP prefix or IP protocol by adding parameters to its
request.  When the IP proxy knows that a request is scoped to a
target prefix or protocol, it can leverage this information to
optimize its resource allocation; for example, the IP proxy can
assign the same public IP address to two IP proxying requests that
are scoped to different prefixes and/or different protocols.
Paragraph (version B):
The scope of the request is indicated by the client to the IP proxy
via the "target" and "ipproto" variables of the URI Template; see
client-config.  Both the "target" and "ipproto" variables are
optional; if they are not included, they are considered to carry the
wildcard value "*".
Paragraph (version A):
In some deployments of CONNECT-IP, an endpoint needs to be assigned
an address by its peer before it knows what source address to set on
its own packets.  For example, in the Remote Access case (example-
remote) the client cannot send IP packets until it knows what address
to use.  In these deployments, the endpoint that is expecting an
address assignment MUST send an ADDRESS_REQUEST capsule.  This isn't
required if the endpoint does not need any address assignment, for
example when it is configured out-of-band with static addresses.
Paragraph (version B):
In some deployments of IP proxying in HTTP, an endpoint needs to be
assigned an address by its peer before it knows what source address
to set on its own packets.  For example, in the Remote Access case
(example-remote) the client cannot send IP packets until it knows
what address to use.  In these deployments, the endpoint that is
expecting an address assignment MUST send an ADDRESS_REQUEST capsule.
This isn't required if the endpoint does not need any address
assignment, for example when it is configured out-of-band with static
addresses.
Paragraph (version A):
If an endpoint received a ROUTE_ADVERTISEMENT capsule that does not
meet these requirements, it MUST abort the stream.
Paragraph (version A):
This protocol allows future extensions to exchange HTTP Datagrams
which carry different semantics from IP packets.  For example, an
extension could define a way to send compressed IP header fields.  In
order to allow for this extensibility, all HTTP Datagrams associated
with IP proxying request streams start with a context ID, see
payload-format.
Paragraph (version A):
Registration is the action by which an endpoint informs its peer of
the semantics and format of a given context ID.  This document does
not define how registration occurs.  Depending on the method being
used, it is possible for datagrams to be received with Context IDs
which have not yet been registered, for instance due to reordering of
the datagram and the registration packets during transmission.
Paragraph (version B):
If an endpoint received a ROUTE_ADVERTISEMENT capsule that does not
meet these requirements, it MUST abort the IP proxying request
stream.
Paragraph (version B):
The mechanism for proxying IP in HTTP defined in this document allows
future extensions to exchange HTTP Datagrams that carry different
semantics from IP payloads.  Some of these extensions can augment IP
payloads with additional data or compress IP header fields, while
others can exchange data that is completely separate from IP
payloads.  In order to accomplish this, all HTTP Datagrams associated
with IP proxying request streams start with a Context ID field; see
payload-format.
Paragraph (version B):
Registration is the action by which an endpoint informs its peer of
the semantics and format of a given Context ID.  This document does
not define how registration occurs.  Future extensions MAY use HTTP
header fields or capsules to register Context IDs.  Depending on the
method being used, it is possible for datagrams to be received with
Context IDs that have not yet been registered.  For instance, this
can be due to reordering of the packet containing the datagram and
the packet containing the registration message during transmission.
Paragraph (version A):
Clients MAY optimistically start sending proxied IP packets before
receiving the response to its IP proxying request, noting however
that those may not be processed by the proxy if it responds to the
request with a failure, or if the datagrams are received by the proxy
before the request.  Since receiving addresses and routes is required
in order to know that a packet can be sent through the tunnel, such
optimistic packets might be dropped by the proxy if it chooses to
provide different addressing or routing information than what the
client assumed.
Paragraph (version A):
When a CONNECT-IP endpoint receives an HTTP Datagram containing an IP
packet, it will parse the packet's IP header, perform any local
policy checks (e.g., source address validation), check their routing
table to pick an outbound interface, and then send the IP packet on
that interface.
Paragraph (version A):
In the other direction, when a CONNECT-IP endpoint receives an IP
packet, it checks to see if the packet matches the routes mapped for
a CONNECT-IP forwarding tunnel, and performs the same forwarding
checks as above before transmitting the packet over HTTP Datagrams.
Paragraph (version A):
Note that CONNECT-IP endpoints will decrement the IP Hop Count (or
TTL) upon encapsulation but not decapsulation.  In other words, the
Hop Count is decremented right before an IP packet is transmitted in
an HTTP Datagram.  This prevents infinite loops in the presence of
routing loops, and matches the choices in IPsec IPSEC.
Paragraph (version A):
CONNECT-IP endpoints can also send ICMPv6 echo requests with 1232
bytes of data to ascertain the link MTU and tear down the tunnel
if they do not receive a response.  Unless endpoints have an out
of band means of guaranteeing that the previous techniques is
sufficient, they MUST use this method.
Paragraph (version B):
Clients MAY optimistically start sending proxied IP packets before
receiving the response to its IP proxying request, noting however
that those may not be processed by the IP proxy if it responds to the
request with a failure, or if the datagrams are received by the IP
proxy before the request.  Since receiving addresses and routes is
required in order to know that a packet can be sent through the
tunnel, such optimistic packets might be dropped by the IP proxy if
it chooses to provide different addressing or routing information
than what the client assumed.
Paragraph (version B):
When an endpoint receives an HTTP Datagram containing an IP packet,
it will parse the packet's IP header, perform any local policy checks
(e.g., source address validation), check their routing table to pick
an outbound interface, and then send the IP packet on that interface
or pass it to a local application.
Paragraph (version B):
In the other direction, when an endpoint receives an IP packet, it
checks to see if the packet matches the routes mapped for an IP
tunnel, and performs the same forwarding checks as above before
transmitting the packet over HTTP Datagrams.
Paragraph (version B):
Note that endpoints will decrement the IP Hop Count (or TTL) upon
encapsulation but not decapsulation.  In other words, the Hop Count
is decremented right before an IP packet is transmitted in an HTTP
Datagram.  This prevents infinite loops in the presence of routing
loops, and matches the choices in IPsec IPSEC.
Paragraph (version B):
IP proxying endpoints can also send ICMPv6 echo requests with 1232
bytes of data to ascertain the link MTU and tear down the tunnel
if they do not receive a response.  Unless endpoints have an out
of band means of guaranteeing that the previous techniques is
sufficient, they MUST use this method.
Paragraph (version A):
If an endpoint is using QUIC DATAGRAM frames to convey IPv6 packets,
and it detects that the QUIC MTU is too low to allow sending 1280
bytes, it MUST abort the CONNECT-IP stream.
Paragraph (version A):
Since CONNECT-IP endpoints often forward IP packets onwards to other
network interfaces, they need to handle errors in the forwarding
process.  For example, forwarding can fail if the endpoint doesn't
have a route for the destination address, or if it is configured to
reject a destination prefix by policy, or if the MTU of the outgoing
link is lower than the size of the packet to be forwarded.  In such
scenarios, CONNECT-IP endpoints SHOULD use ICMP ICMP ICMPv6 to signal
the forwarding error to its peer.
Paragraph (version B):
If an endpoint is using QUIC DATAGRAM frames to convey IPv6 packets,
and it detects that the QUIC MTU is too low to allow sending 1280
bytes, it MUST abort the IP proxying request stream.
Paragraph (version B):
Since IP proxying endpoints often forward IP packets onwards to other
network interfaces, they need to handle errors in the forwarding
process.  For example, forwarding can fail if the endpoint does not
have a route for the destination address, or if it is configured to
reject a destination prefix by policy, or if the MTU of the outgoing
link is lower than the size of the packet to be forwarded.  In such
scenarios, IP proxying endpoints SHOULD use ICMP ICMP ICMPv6 to
signal the forwarding error to its peer.
Paragraph (version A):
In order to receive these errors, endpoints need to be prepared to
receive ICMP packets.  If an endpoint sends ROUTE_ADVERTISEMENT
capsules, its routes SHOULD include an allowance for receiving ICMP
messages.  If an endpoint does not send ROUTE_ADVERTISEMENT capsules,
such as a client opening an IP flow through a proxy, it SHOULD
process proxied ICMP packets from its peer in order to receive these
errors.  Note that ICMP messages can originate from a source address
different from that of the CONNECT-IP peer.
Paragraph (version A):
CONNECT-IP enables many different use cases that can benefit from IP
packet proxying and tunnelling.  These examples are provided to help
illustrate some of the ways in which CONNECT-IP can be used.
Paragraph (version A):
The following example shows a point-to-network VPN setup, where a
client receives a set of local addresses, and can send to any remote
server through the proxy.  Such VPN setups can be either full-tunnel
or split-tunnel.
Paragraph (version A):
In this case, the client does not specify any scope in its request.
The server assigns the client an IPv4 address (192.0.2.11) and a
full-tunnel route of all IPv4 addresses (0.0.0.0/0).  The client can
then send to any IPv4 host using a source address in its assigned
prefix.
Paragraph (version B):
In order to receive these errors, endpoints need to be prepared to
receive ICMP packets.  If an endpoint sends ROUTE_ADVERTISEMENT
capsules, its routes SHOULD include an allowance for receiving ICMP
messages.  If an endpoint does not send ROUTE_ADVERTISEMENT capsules,
such as a client opening an IP flow through an IP proxy, it SHOULD
process proxied ICMP packets from its peer in order to receive these
errors.  Note that ICMP messages can originate from a source address
different from that of the IP proxying peer.
Paragraph (version B):
IP proxying in HTTP enables many different use cases that can benefit
from IP packet proxying and tunnelling.  These examples are provided
to help illustrate some of the ways in which IP proxying in HTTP can
be used.
Paragraph (version B):
The following example shows a point-to-network VPN setup, where a
client receives a set of local addresses, and can send to any remote
host through the IP proxy.  Such VPN setups can be either full-tunnel
or split-tunnel.
Paragraph (version B):
In this case, the client does not specify any scope in its request.
The IP proxy assigns the client an IPv4 address (192.0.2.11) and a
full-tunnel route of all IPv4 addresses (0.0.0.0/0).  The client can
then send to any IPv4 host using a source address in its assigned
prefix.
Paragraph (version A):
In this case, the client specfies both a target hostname and an IP
protocol number in the scope of its request, indicating that it only
needs to communicate with a single host.  The proxy server is able to
perform DNS resolution on behalf of the client and allocate a
specific outbound socket for the client instead of allocating an
entire IP address to the client.  In this regard, the request is
similar to a traditional CONNECT proxy request.
Paragraph (version A):
The server assigns a single IPv6 address to the client
(2001:db8::1234:1234) and a route to a single IPv6 host
(2001:db8::3456), scoped to SCTP.  The client can send and recieve
SCTP IP packets to the remote host.
Paragraph (version A):
The following example shows a setup where a client is proxying UDP
packets through a CONNECT-IP proxy in order to control connection
establishement racing through a proxy, as defined in Happy Eyeballs
HEv2.  This example is a variant of the proxied flow, but highlights
how IP-level proxying can enable new capabilities even for TCP and
UDP.
Paragraph (version A):
As with proxied flows, the client specfies both a target hostname and
an IP protocol number in the scope of its request.  When the proxy
server performs DNS resolution on behalf of the client, it can send
the various remote address options to the client as separate routes.
It can also ensure that the client has both IPv4 and IPv6 addresses
assigned.
Paragraph (version A):
The server assigns the client both an IPv4 address (192.0.2.3) and an
IPv6 address (2001:db8::1234:1234) to the client, as well as an IPv4
route (198.51.100.2) and an IPv6 route (2001:db8::3456), which
represent the resolved addresses of the target hostname, scoped to
UDP.  The client can send and recieve UDP IP packets to the either of
the server addresses to enable Happy Eyeballs through the proxy.
Paragraph (version A):
Extensions to CONNECT-IP can define behavior changes to this
mechanism.  Such extensions SHOULD define new capsule types to
exchange configuration information if needed.  It is RECOMMENDED for
extensions that modify addressing to specify that their extension
capsules be sent before the ADDRESS_ASSIGN capsule and that they do
not take effect until the ADDRESS_ASSIGN capsule is parsed.  This
allows modifications to address assignement to operate atomically.
Similarly, extensions that modify routing SHOULD behave similarly
with regards to the ROUTE_ADVERTISEMENT capsule.
Paragraph (version B):
In this case, the client specfies both a target hostname and an IP
protocol number in the scope of its request, indicating that it only
needs to communicate with a single host.  The IP proxy is able to
perform DNS resolution on behalf of the client and allocate a
specific outbound socket for the client instead of allocating an
entire IP address to the client.  In this regard, the request is
similar to a traditional CONNECT proxy request.
Paragraph (version B):
The IP proxy assigns a single IPv6 address to the client
(2001:db8:1234::a) and a route to a single IPv6 host
(2001:db8:3456::b), scoped to SCTP.  The client can send and receive
SCTP IP packets to the remote host.
Paragraph (version B):
The following example shows a setup where a client is proxying UDP
packets through an IP proxy in order to control connection
establishment racing through an IP proxy, as defined in Happy
Eyeballs HEv2.  This example is a variant of the proxied flow, but
highlights how IP-level proxying can enable new capabilities even for
TCP and UDP.
Paragraph (version B):
As with proxied flows, the client specfies both a target hostname and
an IP protocol number in the scope of its request.  When the IP proxy
performs DNS resolution on behalf of the client, it can send the
various remote address options to the client as separate routes.  It
can also ensure that the client has both IPv4 and IPv6 addresses
assigned.
Paragraph (version B):
The IP proxy assigns the client both an IPv4 address (192.0.2.3) and
an IPv6 address (2001:db8:1234::a) to the client, as well as an IPv4
route (198.51.100.2) and an IPv6 route (2001:db8:3456::b), which
represent the resolved addresses of the target hostname, scoped to
UDP.  The client can send and recieve UDP IP packets to the either of
the IP proxy addresses to enable Happy Eyeballs through the IP proxy.
Paragraph (version B):
Extensions to IP proxying in HTTP can define behavior changes to this
mechanism.  Such extensions SHOULD define new capsule types to
exchange configuration information if needed.  It is RECOMMENDED for
extensions that modify addressing to specify that their extension
capsules be sent before the ADDRESS_ASSIGN capsule and that they do
not take effect until the ADDRESS_ASSIGN capsule is parsed.  This
allows modifications to address assignement to operate atomically.
Similarly, extensions that modify routing SHOULD behave similarly
with regards to the ROUTE_ADVERTISEMENT capsule.
Paragraph (version A):
There are significant risks in allowing arbitrary clients to
establish a tunnel to arbitrary servers, as that could allow bad
actors to send traffic and have it attributed to the proxy.  Proxies
that support CONNECT-IP SHOULD restrict its use to authenticated
users.  The HTTP Authorization header SEMANTICS MAY be used to
authenticate clients.  More complex authentication schemes are out of
scope for this document but can be implemented using CONNECT-IP
extensions.
Paragraph (version B):
There are significant risks in allowing arbitrary clients to
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.