rfc9484.original.xml   rfc9484.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.29 (Ruby 3.1. 4) --> <!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.29 (Ruby 3.1. 4) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
-ietf-masque-connect-ip-13" category="std" consensus="true" submissionType="IETF <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
" updates="9298" tocInclude="true" sortRefs="true" symRefs="true" version="3"> -ietf-masque-connect-ip-13" number="9484" submissionType="IETF" category="std" c
onsensus="true" updates="9298" obsoletes="" xml:lang="en" tocInclude="true" sort
Refs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.17.1 --> <!-- xml2rfc v2v3 conversion 3.17.1 -->
<front> <front>
<title>Proxying IP in HTTP</title> <title>Proxying IP in HTTP</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-masque-connect-ip-13"/> <seriesInfo name="RFC" value="9484"/>
<author initials="T." surname="Pauly" fullname="Tommy Pauly" role="editor"> <author initials="T." surname="Pauly" fullname="Tommy Pauly" role="editor">
<organization>Apple Inc.</organization> <organization>Apple Inc.</organization>
<address> <address>
<email>tpauly@apple.com</email> <email>tpauly@apple.com</email>
</address> </address>
</author> </author>
<author initials="D." surname="Schinazi" fullname="David Schinazi"> <author initials="D." surname="Schinazi" fullname="David Schinazi">
<organization>Google LLC</organization> <organization>Google LLC</organization>
<address> <address>
<postal> <postal>
skipping to change at line 40 skipping to change at line 42
</postal> </postal>
<email>dschinazi.ietf@gmail.com</email> <email>dschinazi.ietf@gmail.com</email>
</address> </address>
</author> </author>
<author initials="A." surname="Chernyakhovsky" fullname="Alex Chernyakhovsky "> <author initials="A." surname="Chernyakhovsky" fullname="Alex Chernyakhovsky ">
<organization>Google LLC</organization> <organization>Google LLC</organization>
<address> <address>
<email>achernya@google.com</email> <email>achernya@google.com</email>
</address> </address>
</author> </author>
<author initials="M." surname="Kuehlewind" fullname="Mirja Kuehlewind"> <author initials="M." surname="Kühlewind" fullname="Mirja Kühlewind">
<organization>Ericsson</organization> <organization>Ericsson</organization>
<address> <address>
<email>mirja.kuehlewind@ericsson.com</email> <email>mirja.kuehlewind@ericsson.com</email>
</address> </address>
</author> </author>
<author initials="M." surname="Westerlund" fullname="Magnus Westerlund"> <author initials="M." surname="Westerlund" fullname="Magnus Westerlund">
<organization>Ericsson</organization> <organization>Ericsson</organization>
<address> <address>
<email>magnus.westerlund@ericsson.com</email> <email>magnus.westerlund@ericsson.com</email>
</address> </address>
</author> </author>
<date year="2023" month="April" day="28"/> <date year="2023" month="October"/>
<area>Transport</area> <area>tsv</area>
<workgroup>MASQUE</workgroup> <workgroup>masque</workgroup>
<keyword>quic</keyword> <keyword>quic</keyword>
<keyword>http</keyword> <keyword>http</keyword>
<keyword>datagram</keyword> <keyword>datagram</keyword>
<keyword>VPN</keyword> <keyword>VPN</keyword>
<keyword>proxy</keyword> <keyword>proxy</keyword>
<keyword>tunnels</keyword> <keyword>tunnels</keyword>
<keyword>quic in udp in IP in quic</keyword> <keyword>quic in udp in IP in quic</keyword>
<keyword>turtles all the way down</keyword> <keyword>turtles all the way down</keyword>
<keyword>masque</keyword> <keyword>masque</keyword>
<keyword>http-ng</keyword> <keyword>http-ng</keyword>
<abstract> <abstract>
<t>This document describes how to proxy IP packets in HTTP. This protocol is <t>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. similar to UDP proxying in HTTP but allows transmitting arbitrary IP packets.
More specifically, this document defines a protocol that allows an HTTP client More specifically, this document defines a protocol that allows an HTTP client
to create an IP tunnel through an HTTP server that acts as an IP proxy. This to create an IP tunnel through an HTTP server that acts as an IP proxy. This
document updates RFC 9298.</t> document updates RFC 9298.</t>
</abstract> </abstract>
<note removeInRFC="true">
<name>About This Document</name>
<t>
The latest revision of this draft can be found at <eref target="https://
ietf-wg-masque.github.io/draft-ietf-masque-connect-ip/draft-ietf-masque-connect-
ip.html"/>.
Status information for this document may be found at <eref target="https
://datatracker.ietf.org/doc/draft-ietf-masque-connect-ip/"/>.
</t>
<t>
Discussion of this document takes place on the
MASQUE Working Group mailing list (<eref target="mailto:masque@ietf.org"
/>),
which is archived at <eref target="https://mailarchive.ietf.org/arch/bro
wse/masque/"/>.
Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/masque/
"/>.
</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/ietf-wg-masque/draft-ietf-masque-connec
t-ip"/>.</t>
</note>
</front> </front>
<middle> <middle>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>HTTP provides the CONNECT method (see <xref section="9.3.6" sectionForm <t>HTTP provides the CONNECT method (see <xref section="9.3.6" sectionForm
at="of" target="HTTP"/>) for at="of" target="RFC9110"/>) for
creating a TCP <xref target="TCP"/> tunnel to a destination and a similar mechan creating a TCP <xref target="RFC9293"/> tunnel to a destination and a similar me
ism chanism
for UDP <xref target="CONNECT-UDP"/>. However, these mechanisms cannot tunnel ot for UDP <xref target="RFC9298"/>. However, these mechanisms cannot tunnel other
her
IP protocols <xref target="IANA-PN"/> nor convey fields of the IP header.</t> IP protocols <xref target="IANA-PN"/> nor convey fields of the IP header.</t>
<t>This document describes a protocol for tunnelling IP through an HTTP se rver <t>This document describes a protocol for tunnelling IP through an HTTP se rver
acting as an IP-specific proxy over HTTP. This can be used for various use acting as an IP-specific proxy over HTTP. This can be used for various use
cases such as remote access VPN, site-to-site VPN, secure point-to-point cases, such as remote access VPN, site-to-site VPN, secure point-to-point
communication, or general-purpose packet tunnelling.</t> communication, or general-purpose packet tunnelling.</t>
<t>IP proxying operates similarly to UDP proxying <xref target="CONNECT-UD P"/>, <t>IP proxying operates similarly to UDP proxying <xref target="RFC9298"/> ,
whereby the proxy itself is identified with an absolute URL, optionally whereby the proxy itself is identified with an absolute URL, optionally
containing the traffic's destination. Clients generate these URLs using a URI containing the traffic's destination. Clients generate these URLs using a URI
Template <xref target="TEMPLATE"/>, as described in <xref target="client-config" />.</t> Template <xref target="RFC6570"/>, as described in <xref target="client-config"/ >.</t>
<t>This protocol supports all existing versions of HTTP by using HTTP Data grams <t>This protocol supports all existing versions of HTTP by using HTTP Data grams
<xref target="HTTP-DGRAM"/>. When using HTTP/2 <xref target="H2"/> or HTTP/3 <xr <xref target="RFC9297"/>. When using HTTP/2 <xref target="RFC9113"/> or HTTP/3 <
ef target="H3"/>, it uses xref target="RFC9114"/>, it uses
HTTP Extended CONNECT as described in <xref target="EXT-CONNECT2"/> and HTTP Extended CONNECT, as described in <xref target="RFC8441"/> and
<xref target="EXT-CONNECT3"/>. When using HTTP/1.x <xref target="H1"/>, it uses <xref target="RFC9220"/>. When using HTTP/1.x <xref target="RFC9112"/>, it uses
HTTP Upgrade as HTTP Upgrade, as
defined in <xref section="7.8" sectionFormat="of" target="HTTP"/>.</t> defined in <xref section="7.8" sectionFormat="of" target="RFC9110"/>.</t>
<t>This document updates <xref target="CONNECT-UDP"/> to change the "masqu
e" well-known URI, <t>This document updates <xref target="RFC9298"/> to change the "masque" w
ell-known URI;
see <xref target="iana-uri"/>.</t> see <xref target="iana-uri"/>.</t>
</section> </section>
<section anchor="conventions-and-definitions"> <section anchor="conventions-and-definitions">
<name>Conventions and Definitions</name> <name>Conventions and Definitions</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14 <t>
>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
nterpreted as "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and be interpreted as
only when, they described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
appear in all capitals, as shown here.</t> when, and only when, they appear in all capitals, as shown here.
</t>
<t>In this document, we use the term "IP proxy" to refer to the HTTP serve r that <t>In this document, we use the term "IP proxy" to refer to the HTTP serve r that
responds to the IP proxying request. The term "client" is used in the HTTP responds to the IP proxying request. The term "client" is used in the HTTP
sense; the client constructs the IP proxying request. If there are HTTP sense; the client constructs the IP proxying request. If there are HTTP
intermediaries (as defined in <xref section="3.7" sectionFormat="of" target="HTT P"/>) between the client and intermediaries (as defined in <xref section="3.7" sectionFormat="of" target="RFC 9110"/>) between the client and
the IP proxy, those are referred to as "intermediaries" in this document. The the IP proxy, those are referred to as "intermediaries" in this document. The
term "IP proxying endpoints" refers to both the client and the IP proxy.</t> term "IP proxying endpoints" refers to both the client and the IP proxy.</t>
<t>This document uses terminology from <xref target="QUIC"/>. Where this d <t>This document uses terminology from <xref target="RFC9000"/>. Where thi
ocument s document
defines protocol types, the definition format uses the notation from <xref secti defines protocol types, the definition format uses the notation from <xref secti
on="1.3" sectionFormat="of" target="QUIC"/>. This specification uses the variabl on="1.3" sectionFormat="of" target="RFC9000"/>. This specification uses the vari
e-length integer encoding able-length integer encoding
from <xref section="16" sectionFormat="of" target="QUIC"/>. Variable-length inte from <xref section="16" sectionFormat="of" target="RFC9000"/>. Variable-length i
ger values do not nteger values do not
need to be encoded in the minimum number of bytes necessary.</t> need to be encoded in the minimum number of bytes necessary.</t>
<t>Note that, when the HTTP version in use does not support multiplexing s treams <t>Note that, when the HTTP version in use does not support multiplexing s treams
(such as HTTP/1.1), any reference to "stream" in this document represents the (such as HTTP/1.1), any reference to "stream" in this document represents the
entire connection.</t> entire connection.</t>
</section> </section>
<section anchor="client-config"> <section anchor="client-config">
<name>Configuration of Clients</name> <name>Configuration of Clients</name>
<t>Clients are configured to use IP proxying over HTTP via a URI Template <t>Clients are configured to use IP proxying over HTTP via a URI Template
<xref target="TEMPLATE"/>. The URI Template <bcp14>MAY</bcp14> contain two varia bles: "target" and <xref target="RFC6570"/>. The URI Template <bcp14>MAY</bcp14> contain two variab les: "target" and
"ipproto"; see <xref target="scope"/>. The optionality of the variables needs to be "ipproto"; see <xref target="scope"/>. The optionality of the variables needs to be
considered when defining the template so that either the variable is considered when defining the template so that the variable is either
self-identifying or it is possible to exclude it in the syntax.</t> self-identifying or possible to exclude in the syntax.</t>
<t>Examples are shown below:</t> <t>Examples are shown below:</t>
<figure anchor="fig-template-examples"> <figure anchor="fig-template-examples">
<name>URI Template Examples</name> <name>URI Template Examples</name>
<artwork><![CDATA[ <artwork><![CDATA[
https://example.org/.well-known/masque/ip/{target}/{ipproto}/ https://example.org/.well-known/masque/ip/{target}/{ipproto}/
https://proxy.example.org:4443/masque/ip?t={target}&i={ipproto} https://proxy.example.org:4443/masque/ip?t={target}&i={ipproto}
https://proxy.example.org:4443/masque/ip{?target,ipproto} https://proxy.example.org:4443/masque/ip{?target,ipproto}
https://masque.example.org/?user=bob https://masque.example.org/?user=bob
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The following requirements apply to the URI Template:</t> <t>The following requirements apply to the URI Template:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>The URI Template <bcp14>MUST</bcp14> be a level 3 template or lower. </li> <li>The URI Template <bcp14>MUST</bcp14> be a level 3 template or lower. </li>
<li>The URI Template <bcp14>MUST</bcp14> be in absolute form, and <bcp14 <li>The URI Template <bcp14>MUST</bcp14> be in absolute form and <bcp14>
>MUST</bcp14> include non-empty scheme, MUST</bcp14> include non-empty scheme,
authority and path components.</li> authority, and path components.</li>
<li>The path component of the URI Template <bcp14>MUST</bcp14> start wit h a slash "/".</li> <li>The path component of the URI Template <bcp14>MUST</bcp14> start wit h a slash "/".</li>
<li>All template variables <bcp14>MUST</bcp14> be within the path or que ry components of the URI.</li> <li>All template variables <bcp14>MUST</bcp14> be within the path or que ry components of the URI.</li>
<li>The URI Template <bcp14>MAY</bcp14> contain the two variables "targe t" and "ipproto" and <bcp14>MAY</bcp14> <li>The URI Template <bcp14>MAY</bcp14> contain the two variables "targe t" and "ipproto" and <bcp14>MAY</bcp14>
contain other variables. If the "target" or "ipproto" variables are included, contain other variables. If the "target" or "ipproto" variables are included,
their values <bcp14>MUST NOT</bcp14> be empty. Clients can instead use "*" to in dicate their values <bcp14>MUST NOT</bcp14> be empty. Clients can instead use "*" to in dicate
wildcard or no-preference values; see <xref target="scope"/>.</li> wildcard or no-preference values; see <xref target="scope"/>.</li>
<li>The URI Template <bcp14>MUST NOT</bcp14> contain any non-ASCII unico de characters and <bcp14>MUST</bcp14> <li>The URI Template <bcp14>MUST NOT</bcp14> contain any non-ASCII Unico de characters and <bcp14>MUST</bcp14>
only contain ASCII characters in the range 0x21-0x7E inclusive (note that only contain ASCII characters in the range 0x21-0x7E inclusive (note that
percent-encoding is allowed; see Section 2.1 of <xref target="URI"/>).</li> percent-encoding is allowed; see <xref target="RFC3986" section="2.1" sectionFor mat="of" />).</li>
<li>The URI Template <bcp14>MUST NOT</bcp14> use Reserved Expansion ("+" operator), Fragment <li>The URI Template <bcp14>MUST NOT</bcp14> use Reserved Expansion ("+" operator), Fragment
Expansion ("#" operator), Label Expansion with Dot- Prefix, Path Segment Expansion ("#" operator), Label Expansion with Dot-Prefix, Path Segment
Expansion with Slash-Prefix, nor Path-Style Parameter Expansion with Expansion with Slash-Prefix, nor Path-Style Parameter Expansion with
Semicolon-Prefix.</li> Semicolon-Prefix.</li>
</ul> </ul>
<t>Clients <bcp14>SHOULD</bcp14> validate the requirements above; however, clients <bcp14>MAY</bcp14> use a <t>Clients <bcp14>SHOULD</bcp14> validate the requirements above; however, clients <bcp14>MAY</bcp14> use a
general-purpose URI Template implementation that lacks this specific general-purpose URI Template implementation that lacks this specific
validation. If a client detects that any of the requirements above are not met validation. If a client detects that any of the requirements above are not met
by a URI Template, the client <bcp14>MUST</bcp14> reject its configuration and a bort the by a URI Template, the client <bcp14>MUST</bcp14> reject its configuration and a bort the
request without sending it to the IP proxy.</t> request without sending it to the IP proxy.</t>
<t>As with UDP proxying, some client configurations for IP proxies will on ly allow <t>As with UDP proxying, some client configurations for IP proxies will on ly allow
the user to configure the proxy host and proxy port. Clients with such the user to configure the proxy host and proxy port. Clients with such
skipping to change at line 186 skipping to change at line 176
template, which is defined as: template, which is defined as:
"https://$PROXY_HOST:$PROXY_PORT/.well-known/masque/ip/{target}/{ipproto}/", "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 where $PROXY_HOST and $PROXY_PORT are the configured host and port of the IP
proxy, respectively. IP proxy deployments <bcp14>SHOULD</bcp14> offer service at this location proxy, respectively. IP proxy deployments <bcp14>SHOULD</bcp14> offer service at this location
if they need to interoperate with such clients.</t> if they need to interoperate with such clients.</t>
</section> </section>
<section anchor="tunnelling-ip-over-http"> <section anchor="tunnelling-ip-over-http">
<name>Tunnelling IP over HTTP</name> <name>Tunnelling IP over HTTP</name>
<t>To allow negotiation of a tunnel for IP over HTTP, this document define s the <t>To allow negotiation of a tunnel for IP over HTTP, this document define s the
"connect-ip" HTTP upgrade token. The resulting IP tunnels use the Capsule "connect-ip" HTTP upgrade token. The resulting IP tunnels use the Capsule
Protocol (see <xref section="3.2" sectionFormat="of" target="HTTP-DGRAM"/>) with HTTP Datagrams in the format Protocol (see <xref section="3.2" sectionFormat="of" target="RFC9297"/>) with HT TP Datagrams in the format
defined in <xref target="payload-format"/>.</t> defined in <xref target="payload-format"/>.</t>
<t>To initiate an IP tunnel associated with a single HTTP stream, a client issues <t>To initiate an IP tunnel associated with a single HTTP stream, a client issues
a request containing the "connect-ip" upgrade token.</t> a request containing the "connect-ip" upgrade token.</t>
<t>When sending its IP proxying request, the client <bcp14>SHALL</bcp14> p erform URI Template <t>When sending its IP proxying request, the client <bcp14>SHALL</bcp14> p erform URI Template
expansion to determine the path and query of its request, see <xref target="clie expansion to determine the path and query of its request; see <xref target="clie
nt-config"/>.</t> nt-config"/>.</t>
<t>By virtue of the definition of the Capsule Protocol (see <xref section= <t>By virtue of the definition of the Capsule Protocol (see <xref section=
"3.2" sectionFormat="of" target="HTTP-DGRAM"/>), IP proxying requests do not car "3.2" sectionFormat="of" target="RFC9297"/>), IP proxying requests do not carry
ry any message content. any message content.
Similarly, successful IP proxying responses also do not carry any message Similarly, successful IP proxying responses also do not carry any message
content.</t> content.</t>
<t>IP proxying over HTTP <bcp14>MUST</bcp14> be operated over TLS or QUIC encryption, or another <t>IP proxying over HTTP <bcp14>MUST</bcp14> be operated over TLS or QUIC encryption, or another
equivalent encryption protocol, to provide confidentiality, integrity, and equivalent encryption protocol, to provide confidentiality, integrity, and
authentication.</t> authentication.</t>
<section anchor="ip-proxy-handling"> <section anchor="ip-proxy-handling">
<name>IP Proxy Handling</name> <name>IP Proxy Handling</name>
<t>Upon receiving an IP proxying request:</t> <t>Upon receiving an IP proxying request:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>if the recipient is configured to use another HTTP proxy, it will <li>If the recipient is configured to use another HTTP server, it will
act as an act as an
intermediary by forwarding the request to another HTTP server. Note that intermediary by forwarding the request to the other HTTP server. Note that
such intermediaries may need to re-encode the request if they forward it such intermediaries may need to re-encode the request if they forward it
using a version of HTTP that is different from the one used to receive it, using a version of HTTP that is different from the one used to receive it,
as the request encoding differs by version (see below).</li> as the request encoding differs by version (see below).</li>
<li>otherwise, the recipient will act as an IP proxy. The IP proxy can choose to <li>Otherwise, the recipient will act as an IP proxy. The IP proxy can choose to
reject the IP proxying request. Otherwise, it extracts the optional "target" reject the IP proxying request. Otherwise, it extracts the optional "target"
and "ipproto" variables from the URI it has reconstructed from the request and "ipproto" variables from the URI it has reconstructed from the request
headers, decodes their percent-encoding, and establishes an IP tunnel.</li> headers, decodes their percent-encoding, and establishes an IP tunnel.</li>
</ul> </ul>
<t>IP proxies <bcp14>MUST</bcp14> validate whether the decoded "target" and "ipproto" variables <t>IP proxies <bcp14>MUST</bcp14> validate whether the decoded "target" and "ipproto" variables
meet the requirements in <xref target="scope"/>. If they do not, the IP proxy <b cp14>MUST</bcp14> treat the meet the requirements in <xref target="scope"/>. If they do not, the IP proxy <b cp14>MUST</bcp14> treat the
request as malformed; see <xref section="8.1.1" sectionFormat="of" target="H2"/> and <xref section="4.1.2" sectionFormat="of" target="H3"/>. request as malformed; see <xref section="8.1.1" sectionFormat="of" target="RFC91 13"/> and <xref section="4.1.2" sectionFormat="of" target="RFC9114"/>.
If the "target" variable is a DNS name, the IP proxy <bcp14>MUST</bcp14> perform DNS If the "target" variable is a DNS name, the IP proxy <bcp14>MUST</bcp14> perform DNS
resolution (to obtain the corresponding IPv4 and/or IPv6 addresses via A and/or resolution (to obtain the corresponding IPv4 and/or IPv6 addresses via A and/or
AAAA records) before replying to the HTTP request. If errors occur during this AAAA records) before replying to the HTTP request. If errors occur during this
process, the IP proxy <bcp14>MUST</bcp14> reject the request and <bcp14>SHOULD</ bcp14> send details using an process, the IP proxy <bcp14>MUST</bcp14> reject the request and <bcp14>SHOULD</ bcp14> send details using an
appropriate Proxy-Status header field <xref target="PROXY-STATUS"/>. For example appropriate Proxy-Status header field <xref target="RFC9209"/>. For example,
, if DNS resolution returns an error, the proxy can use the <tt>dns_error</tt> pro
if DNS resolution returns an error, the proxy can use the <tt>dns_error</tt> Pro xy
xy error type from <xref section="2.3.2" sectionFormat="of" target="RFC9209"/>.</t>
Error Type from <xref section="2.3.2" sectionFormat="of" target="PROXY-STATUS"/>
.</t>
<t>The lifetime of the IP forwarding tunnel is tied to the IP proxying r equest <t>The lifetime of the IP forwarding tunnel is tied to the IP proxying r equest
stream. The IP proxy <bcp14>MUST</bcp14> maintain all IP address and route assig nments stream. The IP proxy <bcp14>MUST</bcp14> maintain all IP address and route assig nments
associated with the IP forwarding tunnel while the request stream is open. IP associated with the IP forwarding tunnel while the request stream is open. IP
proxies <bcp14>MAY</bcp14> choose to tear down the tunnel due to a period of ina ctivity, but proxies <bcp14>MAY</bcp14> choose to tear down the tunnel due to a period of ina ctivity, but
they <bcp14>MUST</bcp14> close the request stream when doing so.</t> they <bcp14>MUST</bcp14> close the request stream when doing so.</t>
<t>A successful response (as defined in Sections <xref format="counter" target="resp1"/> and <xref format="counter" target="resp23"/>) <t>A successful IP proxying response (as defined in Sections <xref forma t="counter" target="resp1"/> and <xref format="counter" target="resp23"/>)
indicates that the IP proxy has established an IP tunnel and is willing to indicates that the IP proxy has established an IP tunnel and is willing to
proxy IP payloads. Any response other than a successful response indicates that proxy IP payloads. Any response other than a successful IP proxying response ind icates that
the request has failed; thus, the client <bcp14>MUST</bcp14> abort the request.< /t> the request has failed; thus, the client <bcp14>MUST</bcp14> abort the request.< /t>
<t>Along with a successful response, the IP proxy can send capsules to a ssign <t>Along with a successful IP proxying response, the IP proxy can send c apsules to assign
addresses and advertise routes to the client (<xref target="capsules"/>). The cl ient can addresses and advertise routes to the client (<xref target="capsules"/>). The cl ient can
also assign addresses and advertise routes to the IP proxy for also assign addresses and advertise routes to the IP proxy for
network-to-network routing.</t> network-to-network routing.</t>
</section> </section>
<section anchor="req1"> <section anchor="req1">
<name>HTTP/1.1 Request</name> <name>HTTP/1.1 Request</name>
<t>When using HTTP/1.1 <xref target="H1"/>, an IP proxying request will meet the following <t>When using HTTP/1.1 <xref target="RFC9112"/>, an IP proxying request will meet the following
requirements:</t> requirements:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>the method <bcp14>SHALL</bcp14> be "GET".</li> <li>The method <bcp14>SHALL</bcp14> be "GET".</li>
<li>the request <bcp14>SHALL</bcp14> include a single Host header fiel <li>The request <bcp14>SHALL</bcp14> include a single Host header fiel
d containing the host d containing the host
and optional port of the IP proxy.</li> and optional port of the IP proxy.</li>
<li>the request <bcp14>SHALL</bcp14> include a Connection header field <li>The request <bcp14>SHALL</bcp14> include a Connection header field
with value "Upgrade" with value "Upgrade"
(note that this requirement is case-insensitive as per <xref section="7.6.1" sec (note that this requirement is case-insensitive, as per <xref section="7.6.1" se
tionFormat="of" target="HTTP"/>).</li> ctionFormat="of" target="RFC9110"/>).</li>
<li>the request <bcp14>SHALL</bcp14> include an Upgrade header field w <li>The request <bcp14>SHALL</bcp14> include an Upgrade header field w
ith value "connect-ip".</li> ith value "connect-ip".</li>
</ul> </ul>
<t>An IP proxying request that does not conform to these restrictions is <t>An IP proxying request that does not conform to these restrictions is
malformed. The recipient of such a malformed request <bcp14>MUST</bcp14> respond with an error malformed. The recipient of such a malformed request <bcp14>MUST</bcp14> respond with an error
and <bcp14>SHOULD</bcp14> use the 400 (Bad Request) status code.</t> and <bcp14>SHOULD</bcp14> use the 400 (Bad Request) status code.</t>
<t>For example, if the client is configured with URI Template <t>For example, if the client is configured with URI Template
"https://example.org/.well-known/masque/ip/{target}/{ipproto}/" and wishes to "https://example.org/.well-known/masque/ip/{target}/{ipproto}/" and wishes to
open an IP forwarding tunnel with no target or protocol limitations, it could open an IP forwarding tunnel with no target or protocol limitations, it could
send the following request:</t> send the following request:</t>
<figure anchor="fig-req-h1"> <figure anchor="fig-req-h1">
<name>Example HTTP/1.1 Request</name> <name>Example HTTP/1.1 Request</name>
skipping to change at line 268 skipping to change at line 258
GET https://example.org/.well-known/masque/ip/*/*/ HTTP/1.1 GET https://example.org/.well-known/masque/ip/*/*/ HTTP/1.1
Host: example.org Host: example.org
Connection: Upgrade Connection: Upgrade
Upgrade: connect-ip Upgrade: connect-ip
Capsule-Protocol: ?1 Capsule-Protocol: ?1
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="resp1"> <section anchor="resp1">
<name>HTTP/1.1 Response</name> <name>HTTP/1.1 Response</name>
<t>The server indicates a successful response by replying with the follo wing <t>The server indicates a successful IP proxying response by replying wi th the following
requirements:</t> requirements:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>the HTTP status code on the response <bcp14>SHALL</bcp14> be 101 ( <li>The HTTP status code on the response <bcp14>SHALL</bcp14> be 101 (
Switching Protocols).</li> Switching Protocols).</li>
<li>the response <bcp14>SHALL</bcp14> include a Connection header fiel <li>The response <bcp14>SHALL</bcp14> include a Connection header fiel
d with value "Upgrade" d with value "Upgrade"
(note that this requirement is case-insensitive as per <xref section="7.6.1" sec (note that this requirement is case-insensitive, as per <xref section="7.6.1" se
tionFormat="of" target="HTTP"/>).</li> ctionFormat="of" target="RFC9110"/>).</li>
<li>the response <bcp14>SHALL</bcp14> include a single Upgrade header <li>The response <bcp14>SHALL</bcp14> include a single Upgrade header
field with value field with value
"connect-ip".</li> "connect-ip".</li>
<li>the response <bcp14>SHALL</bcp14> meet the requirements of HTTP re <li>The response <bcp14>SHALL</bcp14> meet the requirements of HTTP re
sponses that start the sponses that start the
Capsule Protocol; see <xref section="3.2" sectionFormat="of" target="HTTP-DGRAM" Capsule Protocol; see <xref section="3.2" sectionFormat="of" target="RFC9297"/>.
/>.</li> </li>
</ul> </ul>
<t>If any of these requirements are not met, the client <bcp14>MUST</bcp 14> treat this proxying <t>If any of these requirements are not met, the client <bcp14>MUST</bcp 14> treat this proxying
attempt as failed and close the connection.</t> attempt as failed and close the connection.</t>
<t>For example, the server could respond with:</t> <t>For example, the server could respond with:</t>
<figure anchor="fig-resp-h1"> <figure anchor="fig-resp-h1">
<name>Example HTTP/1.1 Response</name> <name>Example HTTP/1.1 Response</name>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
HTTP/1.1 101 Switching Protocols HTTP/1.1 101 Switching Protocols
Connection: Upgrade Connection: Upgrade
Upgrade: connect-ip Upgrade: connect-ip
Capsule-Protocol: ?1 Capsule-Protocol: ?1
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="req23"> <section anchor="req23">
<name>HTTP/2 and HTTP/3 Requests</name> <name>HTTP/2 and HTTP/3 Requests</name>
<t>When using HTTP/2 <xref target="H2"/> or HTTP/3 <xref target="H3"/>, <t>When using HTTP/2 <xref target="RFC9113"/> or HTTP/3 <xref target="RF
IP proxying requests use HTTP C9114"/>, IP proxying requests use HTTP
Extended CONNECT. This requires that servers send an HTTP Setting as specified Extended CONNECT. This requires that servers send an HTTP Setting, as specified
in <xref target="EXT-CONNECT2"/> and <xref target="EXT-CONNECT3"/> and that requ in <xref target="RFC8441"/> and <xref target="RFC9220"/>, and that requests use
ests use HTTP HTTP
pseudo-header fields with the following requirements:</t> pseudo-header fields with the following requirements:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>The :method pseudo-header field <bcp14>SHALL</bcp14> be "CONNECT". </li> <li>The :method pseudo-header field <bcp14>SHALL</bcp14> be "CONNECT". </li>
<li>The :protocol pseudo-header field <bcp14>SHALL</bcp14> be "connect -ip".</li> <li>The :protocol pseudo-header field <bcp14>SHALL</bcp14> be "connect -ip".</li>
<li>The :authority pseudo-header field <bcp14>SHALL</bcp14> contain th e authority of the IP <li>The :authority pseudo-header field <bcp14>SHALL</bcp14> contain th e authority of the IP
proxy.</li> proxy.</li>
<li>The :path and :scheme pseudo-header fields <bcp14>SHALL NOT</bcp14 > be empty. Their values <li>The :path and :scheme pseudo-header fields <bcp14>SHALL NOT</bcp14 > be empty. Their values
<bcp14>SHALL</bcp14> contain the scheme and path from the URI Template after the URI <bcp14>SHALL</bcp14> contain the scheme and path from the URI Template after the URI
Template expansion process has been completed; see <xref target="client-config"/ >. Template expansion process has been completed; see <xref target="client-config"/ >.
Variables in the URI Template can determine the scope of the request, such as 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 requesting full-tunnel IP packet forwarding, or a specific proxied flow; see
<xref target="scope"/>.</li> <xref target="scope"/>.</li>
</ul> </ul>
<t>An IP proxying request that does not conform to these restrictions is <t>An IP proxying request that does not conform to these restrictions is
malformed; see <xref section="8.1.1" sectionFormat="of" target="H2"/> and <xref section="4.1.2" sectionFormat="of" target="H3"/>.</t> malformed; see <xref section="8.1.1" sectionFormat="of" target="RFC9113"/> and < xref section="4.1.2" sectionFormat="of" target="RFC9114"/>.</t>
<t>For example, if the client is configured with URI Template <t>For example, if the client is configured with URI Template
"https://example.org/.well-known/masque/ip/{target}/{ipproto}/" and wishes to "https://example.org/.well-known/masque/ip/{target}/{ipproto}/" and wishes to
open an IP forwarding tunnel with no target or protocol limitations, it could open an IP forwarding tunnel with no target or protocol limitations, it could
send the following request:</t> send the following request:</t>
<figure anchor="fig-req-h2"> <figure anchor="fig-req-h2">
<name>Example HTTP/2 or HTTP/3 Request</name> <name>Example HTTP/2 or HTTP/3 Request</name>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
HEADERS HEADERS
:method = CONNECT :method = CONNECT
:protocol = connect-ip :protocol = connect-ip
:scheme = https :scheme = https
:path = /.well-known/masque/ip/*/*/ :path = /.well-known/masque/ip/*/*/
:authority = example.org :authority = example.org
capsule-protocol = ?1 capsule-protocol = ?1
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="resp23"> <section anchor="resp23">
<name>HTTP/2 and HTTP/3 Responses</name> <name>HTTP/2 and HTTP/3 Responses</name>
<t>The server indicates a successful response by replying with the follo wing <t>The server indicates a successful IP proxying response by replying wi th the following
requirements:</t> requirements:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>the HTTP status code on the response <bcp14>SHALL</bcp14> be in th <li>The HTTP status code on the response <bcp14>SHALL</bcp14> be in th
e 2xx (Successful) range.</li> e 2xx (Successful) range.</li>
<li>the response <bcp14>SHALL</bcp14> meet the requirements of HTTP re <li>The response <bcp14>SHALL</bcp14> meet the requirements of HTTP re
sponses that start the sponses that start the
Capsule Protocol; see <xref section="3.2" sectionFormat="of" target="HTTP-DGRAM" Capsule Protocol; see <xref section="3.2" sectionFormat="of" target="RFC9297"/>.
/>.</li> </li>
</ul> </ul>
<t>If any of these requirements are not met, the client <bcp14>MUST</bcp 14> treat this proxying <t>If any of these requirements are not met, the client <bcp14>MUST</bcp 14> treat this proxying
attempt as failed and abort the request. As an example, any status code in the attempt as failed and abort the request. As an example, any status code in the
3xx range will be treated as a failure and cause the client to abort the 3xx range will be treated as a failure and cause the client to abort the
request.</t> request.</t>
<t>For example, the server could respond with:</t> <t>For example, the server could respond with:</t>
<figure anchor="fig-resp-h2"> <figure anchor="fig-resp-h2">
<name>Example HTTP/2 or HTTP/3 Response</name> <name>Example HTTP/2 or HTTP/3 Response</name>
<sourcecode type="http-message"><![CDATA[ <sourcecode type="http-message"><![CDATA[
HEADERS HEADERS
skipping to change at line 366 skipping to change at line 356
The client can choose to restrict a given request to a specific IP prefix or IP 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 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 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 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 assign the same public IP address to two IP proxying requests that are scoped
to different prefixes and/or different protocols.</t> to different prefixes and/or different protocols.</t>
<t>The scope of the request is indicated by the client to the IP proxy v ia the <t>The scope of the request is indicated by the client to the IP proxy v ia the
"target" and "ipproto" variables of the URI Template; see <xref target="client-c onfig"/>. "target" and "ipproto" variables of the URI Template; see <xref target="client-c onfig"/>.
Both the "target" and "ipproto" variables are optional; if they are not Both the "target" and "ipproto" variables are optional; if they are not
included, they are considered to carry the wildcard value "*".</t> included, they are considered to carry the wildcard value "*".</t>
<dl spacing="compact"> <dl spacing="normal" newline="true">
<dt>target:</dt> <dt>target:</dt>
<dd> <dd>
<t>The variable "target" contains a hostname or IP prefix of a speci fic host to <t>The variable "target" contains a hostname or IP prefix of a speci fic host to
which the client wants to proxy packets. If the "target" variable is not which the client wants to proxy packets. If the "target" variable is not
specified or its value is "*", the client is requesting to communicate with specified or its value is "*", the client is requesting to communicate with
any allowable host. "target" supports using DNS names, IPv6 prefixes and IPv4 any allowable host. "target" supports using DNS names, IPv6 prefixes, and IPv4
prefixes. Note that IPv6 scoped addressing zone identifiers (<xref target="RFC68 prefixes. Note that IPv6 scoped addressing zone identifiers <xref target="RFC687
74"/>) are 4"/> are
not supported. If the target is an IP prefix (IP address optionally followed by not supported. If the target is an IP prefix (IP address optionally followed by
a percent-encoded slash followed by the prefix length in bits), the request a percent-encoded slash followed by the prefix length in bits), the request
will only support a single IP version. If the target is a hostname, the IP will only support a single IP version. If the target is a hostname, the IP
proxy is expected to perform DNS resolution to determine which route(s) to proxy is expected to perform DNS resolution to determine which route(s) to
advertise to the client. The IP proxy <bcp14>SHOULD</bcp14> send a ROUTE_ADVERTI SEMENT capsule advertise to the client. The IP proxy <bcp14>SHOULD</bcp14> send a ROUTE_ADVERTI SEMENT capsule
that includes routes for all addresses that were resolved for the requested that includes routes for all addresses that were resolved for the requested
hostname, that are accessible to the IP proxy, and belong to an address family hostname, that are accessible to the IP proxy, and belong to an address family
for which the IP proxy also sends an Assigned Address.</t> for which the IP proxy also sends an Assigned Address.</t>
</dd> </dd>
<dt>ipproto:</dt> <dt>ipproto:</dt>
<dd> <dd>
<t>The variable "ipproto" contains an IP protocol number, as defined in the <t>The variable "ipproto" contains an Internet Protocol Number; see the defined list in the
"Assigned Internet Protocol Numbers" IANA registry <xref target="IANA-PN"/>. If present, it "Assigned Internet Protocol Numbers" IANA registry <xref target="IANA-PN"/>. If present, it
specifies that a client only wants to proxy a specific IP protocol for this specifies that a client only wants to proxy a specific IP protocol for this
request. If the value is "*", or the variable is not included, the client is request. If the value is "*", or the variable is not included, the client is
requesting to use any IP protocol. The IP protocol indicated in the "ipproto" requesting to use any IP protocol. The IP protocol indicated in the "ipproto"
variable represents an allowable next header value carried in IP headers that variable represents an allowable next header value carried in IP headers that
are directly sent in HTTP datagrams (the outermost IP headers). ICMP traffic are directly sent in HTTP Datagrams (the outermost IP headers). ICMP traffic
is always allowed, regardless of the value of this field.</t> is always allowed, regardless of the value of this field.</t>
</dd> </dd>
</dl> </dl>
<t>Using the terms IPv6address, IPv4address, and reg-name from <xref tar get="URI"/>, the <t>Using the terms IPv6address, IPv4address, and reg-name from <xref tar get="RFC3986"/>, the
"target" and "ipproto" variables <bcp14>MUST</bcp14> adhere to the format in "target" and "ipproto" variables <bcp14>MUST</bcp14> adhere to the format in
<xref target="target-format"/>, using notation from <xref target="ABNF"/>. Addit ionally:</t> <xref target="target-format"/>, using notation from <xref target="RFC5234"/>. Ad ditionally:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>if "target" contains an IPv6 literal or prefix, the colons (":") < bcp14>MUST</bcp14> be <li>If "target" contains an IPv6 literal or prefix, the colons (":") < bcp14>MUST</bcp14> be
percent-encoded. For example, if the target host is "2001:db8::42", it will percent-encoded. For example, if the target host is "2001:db8::42", it will
be encoded in the URI as "2001%3Adb8%3A%3A42".</li> be encoded in the URI as "2001%3Adb8%3A%3A42".</li>
<li>If present, the IP prefix length in "target" <bcp14>SHALL</bcp14> be preceded by a <li>If present, the IP prefix length in "target" <bcp14>SHALL</bcp14> be preceded by a
percent-encoded slash ("/"): "%2F". The IP prefix length <bcp14>MUST</bcp14> rep resent a percent-encoded slash ("/"): "%2F". The IP prefix length <bcp14>MUST</bcp14> rep resent a
decimal integer between 0 and the length of the IP address in bits, inclusive.</ li> decimal integer between 0 and the length of the IP address in bits, inclusive.</ li>
<li>If "target" contains an IP prefix and the prefix length is strictl y less than <li>If "target" contains an IP prefix and the prefix length is strictl y less than
the length of the IP address in bits, the lower bits of the IP address that the length of the IP address in bits, the lower bits of the IP address that
are not covered by the prefix length <bcp14>MUST</bcp14> all be set to 0.</li> are not covered by the prefix length <bcp14>MUST</bcp14> all be set to 0.</li>
<li>"ipproto" <bcp14>MUST</bcp14> represent a decimal integer between 0 and 255 inclusive, or <li>"ipproto" <bcp14>MUST</bcp14> represent a decimal integer between 0 and 255 inclusive or
the wildcard value "*".</li> the wildcard value "*".</li>
</ul> </ul>
<figure anchor="target-format"> <figure anchor="target-format">
<name>URI Template Variable Format</name> <name>URI Template Variable Format</name>
<artwork type="ascii-art"><![CDATA[ <artwork type="ascii-art"><![CDATA[
target = IPv6prefix / IPv4prefix / reg-name / "*" target = IPv6prefix / IPv4prefix / reg-name / "*"
IPv6prefix = IPv6address ["%2F" 1*3DIGIT] IPv6prefix = IPv6address ["%2F" 1*3DIGIT]
IPv4prefix = IPv4address ["%2F" 1*2DIGIT] IPv4prefix = IPv4address ["%2F" 1*2DIGIT]
ipproto = 1*3DIGIT / "*" ipproto = 1*3DIGIT / "*"
]]></artwork> ]]></artwork>
</figure> </figure>
<t>IP proxies <bcp14>MAY</bcp14> perform access control using the scopin g information provided by <t>IP proxies <bcp14>MAY</bcp14> perform access control using the scopin g information provided by
the client: if the client is not authorized to access any of the destinations the client, i.e., if the client is not authorized to access any of the destinati
included in the scope, then the IP proxy can immediately fail the request.</t> ons
included in the scope, then the IP proxy can immediately reject the request.</t>
</section> </section>
<section anchor="capsules"> <section anchor="capsules">
<name>Capsules</name> <name>Capsules</name>
<t>This document defines multiple new capsule types that allow endpoints to <t>This document defines multiple new capsule types that allow endpoints to
exchange IP configuration information. Both endpoints <bcp14>MAY</bcp14> send an y number of exchange IP configuration information. Both endpoints <bcp14>MAY</bcp14> send an y number of
these new capsules.</t> these new capsules.</t>
<section anchor="addressassign-capsule"> <section anchor="addressassign-capsule">
<name>ADDRESS_ASSIGN Capsule</name> <name>ADDRESS_ASSIGN Capsule</name>
<t>The ADDRESS_ASSIGN capsule (see <xref target="iana-types"/> for the <t>The ADDRESS_ASSIGN capsule (capsule type 0x01) allows an endpoint t
value of the capsule o assign its peer a list of IP addresses or
type) allows an endpoint to inform its peer of the list of IP addresses or prefixes. Every capsule contains the full list of IP
prefixes it has assigned to it. Every capsule contains the full list of IP
prefixes currently assigned to the receiver. Any of these addresses can be used prefixes currently assigned to the receiver. Any of these addresses can be used
as the source address on IP packets originated by the receiver of this capsule.< /t> as the source address on IP packets originated by the receiver of this capsule.< /t>
<figure anchor="addr-assign-format"> <figure anchor="addr-assign-format">
<name>ADDRESS_ASSIGN Capsule Format</name> <name>ADDRESS_ASSIGN Capsule Format</name>
<artwork><![CDATA[ <artwork><![CDATA[
ADDRESS_ASSIGN Capsule { ADDRESS_ASSIGN Capsule {
Type (i) = ADDRESS_ASSIGN, Type (i) = 0x01,
Length (i), Length (i),
Assigned Address (..) ..., Assigned Address (..) ...,
} }
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The ADDRESS_ASSIGN capsule contains a sequence of zero or more Assi gned <t>The ADDRESS_ASSIGN capsule contains a sequence of zero or more Assi gned
Addresses.</t> Addresses.</t>
<figure anchor="assigned-addr-format"> <figure anchor="assigned-addr-format">
<name>Assigned Address Format</name> <name>Assigned Address Format</name>
<artwork><![CDATA[ <artwork><![CDATA[
Assigned Address { Assigned Address {
Request ID (i), Request ID (i),
IP Version (8), IP Version (8),
IP Address (32..128), IP Address (32..128),
IP Prefix Length (8), IP Prefix Length (8),
} }
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Each Assigned Address contains the following fields:</t> <t>Each Assigned Address contains the following fields:</t>
<dl spacing="compact"> <dl spacing="normal" newline="true">
<dt>Request ID:</dt> <dt>Request ID:</dt>
<dd> <dd>
<t>Request identifier, encoded as a variable-length integer. If th is address <t>Request identifier, encoded as a variable-length integer. If th is address
assignment is in response to an Address Request (see <xref target="addr_req"/>), then this assignment is in response to an Address Request (see <xref target="addr_req"/>), then this
field <bcp14>SHALL</bcp14> contain the value of the corresponding field in the r equest. field <bcp14>SHALL</bcp14> contain the value of the corresponding field in the r equest.
Otherwise, this field <bcp14>SHALL</bcp14> be zero.</t> Otherwise, this field <bcp14>SHALL</bcp14> be zero.</t>
</dd> </dd>
<dt>IP Version:</dt> <dt>IP Version:</dt>
<dd> <dd>
<t>IP Version of this address assignment, encoded as an unsigned 8 -bit integer. <t>IP Version of this address assignment, encoded as an unsigned 8 -bit integer. It
<bcp14>MUST</bcp14> be either 4 or 6.</t> <bcp14>MUST</bcp14> be either 4 or 6.</t>
</dd> </dd>
<dt>IP Address:</dt> <dt>IP Address:</dt>
<dd> <dd>
<t>Assigned IP address. If the IP Version field has value 4, the I P Address <t>Assigned IP address. If the IP Version field has value 4, the I P Address
field <bcp14>SHALL</bcp14> have a length of 32 bits. If the IP Version field has value 6, the field <bcp14>SHALL</bcp14> have a length of 32 bits. If the IP Version field has value 6, the
IP Address field <bcp14>SHALL</bcp14> have a length of 128 bits.</t> IP Address field <bcp14>SHALL</bcp14> have a length of 128 bits.</t>
</dd> </dd>
<dt>IP Prefix Length:</dt> <dt>IP Prefix Length:</dt>
<dd> <dd>
<t>The number of bits in the IP address that are used to define th e prefix that <t>The number of bits in the IP address that are used to define th e prefix that
is being assigned, encoded as an unsigned 8-bit integer. This <bcp14>MUST</bcp14 > be less than is being assigned, encoded as an unsigned 8-bit integer. This <bcp14>MUST</bcp14 > be less than
or equal to the length of the IP Address field, in bits. If the prefix length or equal to the length of the IP Address field in bits. If the prefix length
is equal to the length of the IP address, the receiver of this capsule is is equal to the length of the IP address, the receiver of this capsule is
allowed to send packets from a single source address. If the prefix length is allowed to send packets from a single source address. If the prefix length is
less than the length of the IP address, the receiver of this capsule is allowed less than the length of the IP address, the receiver of this capsule is allowed
to send packets from any source address that falls within the prefix. If the to send packets from any source address that falls within the prefix. If the
prefix length is strictly less than the length of the IP address in bits, the prefix length is strictly less than the length of the IP address in bits, the
lower bits of the IP Address field that are not covered by the prefix length lower bits of the IP Address field that are not covered by the prefix length
<bcp14>MUST</bcp14> all be set to 0.</t> <bcp14>MUST</bcp14> all be set to 0.</t>
</dd> </dd>
</dl> </dl>
<t>If any of the capsule fields are malformed upon reception, the rece iver of the <t>If any of the capsule fields are malformed upon reception, the rece iver of the
capsule <bcp14>MUST</bcp14> follow the error handling procedure defined in <xref section="3.3" sectionFormat="of" target="HTTP-DGRAM"/>.</t> capsule <bcp14>MUST</bcp14> follow the error-handling procedure defined in <xref section="3.3" sectionFormat="of" target="RFC9297"/>.</t>
<t>If an ADDRESS_ASSIGN capsule does not contain an address that was p reviously <t>If an ADDRESS_ASSIGN capsule does not contain an address that was p reviously
transmitted in another ADDRESS_ASSIGN capsule, that indicates that the address transmitted in another ADDRESS_ASSIGN capsule, it indicates that the address
has been removed. An ADDRESS_ASSIGN capsule can also be empty, indicating that has been removed. An ADDRESS_ASSIGN capsule can also be empty, indicating that
all addresses have been removed.</t> all addresses have been removed.</t>
<t>In some deployments of IP proxying in HTTP, an endpoint needs to be assigned an <t>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 address by its peer before it knows what source address to set on its own
packets. For example, in the Remote Access VPN case (<xref target="example-remot packets. For example, in the remote access VPN case (<xref target="example-remot
e"/>) the e"/>), the
client cannot send IP packets until it knows what address to use. In these client cannot send IP packets until it knows what address to use.
In these
deployments, the endpoint that is expecting an address assignment <bcp14>MUST</b cp14> send an deployments, the endpoint that is expecting an address assignment <bcp14>MUST</b cp14> send an
ADDRESS_REQUEST capsule. This isn't required if the endpoint does not need any 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 address assignment, for example, when it is configured out-of-band with static
addresses.</t> addresses.</t>
<t>While ADDRESS_ASSIGN capsules are commonly sent in response to ADDR ESS_REQUEST <t>While ADDRESS_ASSIGN capsules are commonly sent in response to ADDR ESS_REQUEST
capsules, endpoints <bcp14>MAY</bcp14> send ADDRESS_ASSIGN capsules unprompted.< /t> capsules, endpoints <bcp14>MAY</bcp14> send ADDRESS_ASSIGN capsules unprompted.< /t>
</section> </section>
<section anchor="addr_req"> <section anchor="addr_req">
<name>ADDRESS_REQUEST Capsule</name> <name>ADDRESS_REQUEST Capsule</name>
<t>The ADDRESS_REQUEST capsule (see <xref target="iana-types"/> for th <t>The ADDRESS_REQUEST capsule (capsule type 0x02) allows an endpoint
e value of the capsule to request assignment of IP addresses from its peer.
type) allows an endpoint to request assignment of IP addresses from its peer.
The capsule allows the endpoint to optionally indicate a preference for which The capsule allows the endpoint to optionally indicate a preference for which
address it would get assigned.</t> address it would get assigned.</t>
<figure anchor="addr-req-format"> <figure anchor="addr-req-format">
<name>ADDRESS_REQUEST Capsule Format</name> <name>ADDRESS_REQUEST Capsule Format</name>
<artwork><![CDATA[ <artwork><![CDATA[
ADDRESS_REQUEST Capsule { ADDRESS_REQUEST Capsule {
Type (i) = ADDRESS_REQUEST, Type (i) = 0x02,
Length (i), Length (i),
Requested Address (..) ..., Requested Address (..) ...,
} }
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The ADDRESS_REQUEST capsule contains a sequence of one or more Requ ested <t>The ADDRESS_REQUEST capsule contains a sequence of one or more Requ ested
Addresses.</t> Addresses.</t>
<figure anchor="requested-addr-format"> <figure anchor="requested-addr-format">
<name>Requested Address Format</name> <name>Requested Address Format</name>
<artwork><![CDATA[ <artwork><![CDATA[
Requested Address { Requested Address {
Request ID (i), Request ID (i),
IP Version (8), IP Version (8),
IP Address (32..128), IP Address (32..128),
IP Prefix Length (8), IP Prefix Length (8),
} }
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Each Requested Address contains the following fields:</t> <t>Each Requested Address contains the following fields:</t>
<dl spacing="compact"> <dl spacing="normal" newline="true">
<dt>Request ID:</dt> <dt>Request ID:</dt>
<dd> <dd>
<t>Request identifier, encoded as a variable-length integer. This is the <t>Request identifier, encoded as a variable-length integer. This is the
identifier of this specific address request. Each request from a given endpoint identifier of this specific address request. Each request from a given endpoint
carries a different identifier. Request IDs <bcp14>MUST NOT</bcp14> be reused by an endpoint, carries a different identifier. Request IDs <bcp14>MUST NOT</bcp14> be reused by an endpoint
and <bcp14>MUST NOT</bcp14> be zero.</t> and <bcp14>MUST NOT</bcp14> be zero.</t>
</dd> </dd>
<dt>IP Version:</dt> <dt>IP Version:</dt>
<dd> <dd>
<t>IP Version of this address request, encoded as an unsigned 8-bi t integer. <t>IP Version of this address request, encoded as an unsigned 8-bi t integer. It
<bcp14>MUST</bcp14> be either 4 or 6.</t> <bcp14>MUST</bcp14> be either 4 or 6.</t>
</dd> </dd>
<dt>IP Address:</dt> <dt>IP Address:</dt>
<dd> <dd>
<t>Requested IP address. If the IP Version field has value 4, the IP Address <t>Requested IP address. If the IP Version field has value 4, the IP Address
field <bcp14>SHALL</bcp14> have a length of 32 bits. If the IP Version field has value 6, the field <bcp14>SHALL</bcp14> have a length of 32 bits. If the IP Version field has value 6, the
IP Address field <bcp14>SHALL</bcp14> have a length of 128 bits.</t> IP Address field <bcp14>SHALL</bcp14> have a length of 128 bits.</t>
</dd> </dd>
<dt>IP Prefix Length:</dt> <dt>IP Prefix Length:</dt>
<dd> <dd>
<t>Length of the IP Prefix requested, in bits, encoded as an unsig <t>Length of the IP Prefix requested in bits, encoded as an unsign
ned 8-bit ed 8-bit
integer. <bcp14>MUST</bcp14> be less than or equal to the length of the IP Addre integer. It <bcp14>MUST</bcp14> be less than or equal to the length of the IP Ad
ss field, in dress field in
bits. If the prefix length is strictly less than the length of the IP address bits. If the prefix length is strictly less than the length of the IP address
in bits, the lower bits of the IP Address field that are not covered by the in bits, the lower bits of the IP Address field that are not covered by the
prefix length <bcp14>MUST</bcp14> all be set to 0.</t> prefix length <bcp14>MUST</bcp14> all be set to 0.</t>
</dd> </dd>
</dl> </dl>
<t>If the IP address is all-zero (0.0.0.0 or ::), this indicates that the sender <t>If the IP address is all-zero (0.0.0.0 or ::), this indicates that the sender
is requesting an address of that address family but does not have a preference is requesting an address of that address family but does not have a preference
for a specific address. In that scenario, the prefix length still indicates the for a specific address. In that scenario, the prefix length still indicates the
sender's preference for the prefix length it is requesting.</t> sender's preference for the prefix length it is requesting.</t>
<t>If any of the capsule fields are malformed upon reception, the rece iver of the <t>If any of the capsule fields are malformed upon reception, the rece iver of the
capsule <bcp14>MUST</bcp14> follow the error handling procedure defined in <xref section="3.3" sectionFormat="of" target="HTTP-DGRAM"/>.</t> capsule <bcp14>MUST</bcp14> follow the error-handling procedure defined in <xref section="3.3" sectionFormat="of" target="RFC9297"/>.</t>
<t>Upon receiving the ADDRESS_REQUEST capsule, an endpoint <bcp14>SHOU LD</bcp14> assign one or <t>Upon receiving the ADDRESS_REQUEST capsule, an endpoint <bcp14>SHOU LD</bcp14> assign one or
more IP addresses to its peer, and then respond with an ADDRESS_ASSIGN capsule more IP addresses to its peer and then respond with an ADDRESS_ASSIGN capsule
to inform the peer of the assignment. For each Requested Address, the receiver to inform the peer of the assignment. For each Requested Address, the receiver
of the ADDRESS_REQUEST capsule <bcp14>SHALL</bcp14> respond with an Assigned Add ress with a of the ADDRESS_REQUEST capsule <bcp14>SHALL</bcp14> respond with an Assigned Add ress with a
matching Request ID. If the requested address was assigned, the IP Address and matching Request ID. If the requested address was assigned, the IP Address and
IP Prefix Length fields in the Assigned Address response <bcp14>SHALL</bcp14> be set to the IP Prefix Length fields in the Assigned Address response <bcp14>SHALL</bcp14> be set to the
assigned values. If the requested address was not assigned, the IP address assigned values. If the requested address was not assigned, the IP address
<bcp14>SHALL</bcp14> be all-zero and the IP Prefix Length <bcp14>SHALL</bcp14> b e the maximum length <bcp14>SHALL</bcp14> be all-zero, and the IP Prefix Length <bcp14>SHALL</bcp14> be the maximum length
(0.0.0.0/32 or ::/128) to indicate that no address was assigned. These address (0.0.0.0/32 or ::/128) to indicate that no address was assigned. These address
rejections <bcp14>SHOULD NOT</bcp14> be included in subsequent ADDRESS_ASSIGN ca psules. Note rejections <bcp14>SHOULD NOT</bcp14> be included in subsequent ADDRESS_ASSIGN ca psules. Note
that other Assigned Address entries that do not correspond to any Request ID that other Assigned Address entries that do not correspond to any Request ID
can also be contained in the same ADDRESS_ASSIGN response.</t> can also be contained in the same ADDRESS_ASSIGN response.</t>
<t>If an endpoint receives an ADDRESS_REQUEST capsule that contains ze ro Requested <t>If an endpoint receives an ADDRESS_REQUEST capsule that contains ze ro Requested
Addresses, it <bcp14>MUST</bcp14> abort the IP proxying request stream.</t> Addresses, it <bcp14>MUST</bcp14> abort the IP proxying request stream.</t>
<t>Note that the ordering of Requested Addresses does not carry any se mantics. <t>Note that the ordering of Requested Addresses does not carry any se mantics.
Similarly, the Request ID is only meant as a unique identifier, it does not Similarly, the Request ID is only meant as a unique identifier; it does not
convey any priority or importance.</t> convey any priority or importance.</t>
</section> </section>
<section anchor="route-adv"> <section anchor="route-adv">
<name>ROUTE_ADVERTISEMENT Capsule</name> <name>ROUTE_ADVERTISEMENT Capsule</name>
<t>The ROUTE_ADVERTISEMENT capsule (see <xref target="iana-types"/> fo <t>The ROUTE_ADVERTISEMENT capsule (capsule type 0x03) allows an endpo
r the value of the int to communicate to its peer that it is willing
capsule type) allows an endpoint to communicate to its peer that it is willing
to route traffic to a set of IP address ranges. This indicates that the sender to route traffic to a set of IP address ranges. This indicates that the sender
has an existing route to each address range, and notifies its peer that if the has an existing route to each address range and notifies its peer that, if the
receiver of the ROUTE_ADVERTISEMENT capsule sends IP packets for one of these receiver of the ROUTE_ADVERTISEMENT capsule sends IP packets for one of these
ranges in HTTP Datagrams, the sender of the capsule will forward them along its ranges in HTTP Datagrams, the sender of the capsule will forward them along its
preexisting route. Any address which is in one of the address ranges can be preexisting route. Any address that is in one of the address ranges can be
used as the destination address on IP packets originated by the receiver of used as the destination address on IP packets originated by the receiver of
this capsule.</t> this capsule.</t>
<figure anchor="route-adv-format"> <figure anchor="route-adv-format">
<name>ROUTE_ADVERTISEMENT Capsule Format</name> <name>ROUTE_ADVERTISEMENT Capsule Format</name>
<artwork><![CDATA[ <artwork><![CDATA[
ROUTE_ADVERTISEMENT Capsule { ROUTE_ADVERTISEMENT Capsule {
Type (i) = ROUTE_ADVERTISEMENT, Type (i) = 0x03,
Length (i), Length (i),
IP Address Range (..) ..., IP Address Range (..) ...,
} }
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The ROUTE_ADVERTISEMENT capsule contains a sequence of zero or more IP Address <t>The ROUTE_ADVERTISEMENT capsule contains a sequence of zero or more IP Address
Ranges.</t> Ranges.</t>
<figure anchor="addr-range-format"> <figure anchor="addr-range-format">
<name>IP Address Range Format</name> <name>IP Address Range Format</name>
<artwork><![CDATA[ <artwork><![CDATA[
IP Address Range { IP Address Range {
IP Version (8), IP Version (8),
Start IP Address (32..128), Start IP Address (32..128),
End IP Address (32..128), End IP Address (32..128),
IP Protocol (8), IP Protocol (8),
} }
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Each IP Address Range contains the following fields:</t> <t>Each IP Address Range contains the following fields:</t>
<dl spacing="compact"> <dl spacing="normal" newline="true">
<dt>IP Version:</dt> <dt>IP Version:</dt>
<dd> <dd>
<t>IP Version of this range, encoded as an unsigned 8-bit integer. <bcp14>MUST</bcp14> be <t>IP Version of this range, encoded as an unsigned 8-bit integer. It <bcp14>MUST</bcp14> be
either 4 or 6.</t> either 4 or 6.</t>
</dd> </dd>
<dt>Start IP Address and End IP Address:</dt> <dt>Start IP Address and End IP Address:</dt>
<dd> <dd>
<t>Inclusive start and end IP address of the advertised range. If the IP Version <t>Inclusive start and end IP address of the advertised range. If the IP Version
field has value 4, these fields <bcp14>SHALL</bcp14> have a length of 32 bits. I f the IP field has value 4, these fields <bcp14>SHALL</bcp14> have a length of 32 bits. I f the IP
Version field has value 6, these fields <bcp14>SHALL</bcp14> have a length of 12 8 bits. The Version field has value 6, these fields <bcp14>SHALL</bcp14> have a length of 12 8 bits. The
Start IP Address <bcp14>MUST</bcp14> be less than or equal to the End IP Address .</t> Start IP Address <bcp14>MUST</bcp14> be less than or equal to the End IP Address .</t>
</dd> </dd>
<dt>IP Protocol:</dt> <dt>IP Protocol:</dt>
<dd> <dd>
<t>The Internet Protocol Number for traffic that can be sent to th is range, <t>The Internet Protocol Number for traffic that can be sent to th is range,
encoded as an unsigned 8-bit integer. If the value is 0, all protocols are encoded as an unsigned 8-bit integer. If the value is 0, all protocols are
allowed. If the value is not 0, it represents an allowable next header value allowed. If the value is not 0, it represents an allowable next header value
carried in IP headers that are directly sent in HTTP datagrams (the outermost carried in IP headers that are sent directly in HTTP Datagrams (the outermost
IP headers). ICMP traffic is always allowed, regardless of the value of this IP headers). ICMP traffic is always allowed, regardless of the value of this
field.</t> field.</t>
</dd> </dd>
</dl> </dl>
<t>If any of the capsule fields are malformed upon reception, the rece iver of the <t>If any of the capsule fields are malformed upon reception, the rece iver of the
capsule <bcp14>MUST</bcp14> follow the error handling procedure defined in <xref section="3.3" sectionFormat="of" target="HTTP-DGRAM"/>.</t> capsule <bcp14>MUST</bcp14> follow the error-handling procedure defined in <xref section="3.3" sectionFormat="of" target="RFC9297"/>.</t>
<t>Upon receiving the ROUTE_ADVERTISEMENT capsule, an endpoint <bcp14> MAY</bcp14> update its <t>Upon receiving the ROUTE_ADVERTISEMENT capsule, an endpoint <bcp14> MAY</bcp14> update its
local state regarding what its peer is willing to route (subject to local local state regarding what its peer is willing to route (subject to local
policy), such as by installing entries in a routing table.</t> policy), such as by installing entries in a routing table.</t>
<t>Each ROUTE_ADVERTISEMENT contains the full list of address ranges. If multiple <t>Each ROUTE_ADVERTISEMENT contains the full list of address ranges. If multiple
ROUTE_ADVERTISEMENT capsules are sent in one direction, each ROUTE_ADVERTISEMENT capsules are sent in one direction, each
ROUTE_ADVERTISEMENT capsule supersedes prior ones. In other words, if a given ROUTE_ADVERTISEMENT capsule supersedes prior ones. In other words, if a given
address range was present in a prior capsule but the most recently received address range was present in a prior capsule but the most recently received
ROUTE_ADVERTISEMENT capsule does not contain it, the receiver will consider ROUTE_ADVERTISEMENT capsule does not contain it, the receiver will consider
that range withdrawn.</t> that range withdrawn.</t>
<t>If multiple ranges using the same IP protocol were to overlap, some routing <t>If multiple ranges using the same IP protocol were to overlap, some routing
table implementations might reject them. To prevent overlap, the ranges are table implementations might reject them. To prevent overlap, the ranges are
ordered; this places the burden on the sender and makes verification by the ordered; this places the burden on the sender and makes verification by the
receiver much simpler. If an IP Address Range A precedes an IP Address Range B receiver much simpler. If an IP Address Range A precedes an IP Address Range B
in the same ROUTE_ADVERTISEMENT capsule, they <bcp14>MUST</bcp14> follow these r equirements:</t> in the same ROUTE_ADVERTISEMENT capsule, they <bcp14>MUST</bcp14> follow these r equirements:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>IP Version of A <bcp14>MUST</bcp14> be less than or equal to IP Version of B</li> <li>The IP Version of A <bcp14>MUST</bcp14> be less than or equal to the IP Version of B.</li>
<li>If the IP Version of A and B are equal, the IP Protocol of A <bc p14>MUST</bcp14> be less <li>If the IP Version of A and B are equal, the IP Protocol of A <bc p14>MUST</bcp14> be less
than or equal to IP Protocol of B.</li> than or equal to the IP Protocol of B.</li>
<li>If the IP Version and IP Protocol of A and B are both equal, the End IP <li>If the IP Version and IP Protocol of A and B are both equal, the End IP
Address of A <bcp14>MUST</bcp14> be strictly less than the Start IP Address of B .</li> Address of A <bcp14>MUST</bcp14> be strictly less than the Start IP Address of B .</li>
</ul> </ul>
<t>If an endpoint receives a ROUTE_ADVERTISEMENT capsule that does not meet these <t>If an endpoint receives a ROUTE_ADVERTISEMENT capsule that does not meet these
requirements, it <bcp14>MUST</bcp14> abort the IP proxying request stream.</t> requirements, it <bcp14>MUST</bcp14> abort the IP proxying request stream.</t>
<t>Since setting the IP protocol to zero indicates all protocols are a llowed, the <t>Since setting the IP protocol to zero indicates all protocols are a llowed, the
requirements above make it possible for two routes to overlap when one has IP requirements above make it possible for two routes to overlap when one has its I
protocol set to zero and the other set to non-zero. Endpoints <bcp14>MUST NOT</b P
cp14> send a protocol set to zero and the other has it set to non-zero. Endpoints <bcp14>MUST
NOT</bcp14> send a
ROUTE_ADVERTISEMENT capsule with routes that overlap in such a way. Validating ROUTE_ADVERTISEMENT capsule with routes that overlap in such a way. Validating
this requirement is <bcp14>OPTIONAL</bcp14>, but if an endpoint detects the viol ation, it <bcp14>MUST</bcp14> this requirement is <bcp14>OPTIONAL</bcp14>, but if an endpoint detects the viol ation, it <bcp14>MUST</bcp14>
abort the IP proxying request stream.</t> abort the IP proxying request stream.</t>
</section> </section>
</section> </section>
<section anchor="ipv6-extension-headers"> <section anchor="ipv6-extension-headers">
<name>IPv6 Extension Headers</name> <name>IPv6 Extension Headers</name>
<t>Both request scoping (see <xref target="scope"/>) and the ROUTE_ADVER TISEMENT capsule (see <t>Both request scoping (see <xref target="scope"/>) and the ROUTE_ADVER TISEMENT capsule (see
<xref target="route-adv"/>) use IP protocol numbers. These numbers represent bot <xref target="route-adv"/>) use Internet Protocol Numbers. These numbers represe
h upper nt both upper
layers (as defined in <xref section="2" sectionFormat="of" target="IPv6"/>, exam layers (as defined in <xref section="2" sectionFormat="of" target="RFC8200"/>, w
ples include TCP and ith examples that include TCP and
UDP) and IPv6 extension headers (as defined in <xref section="4" sectionFormat=" UDP) and IPv6 extension headers (as defined in <xref section="4" sectionFormat="
of" target="IPv6"/>, examples of" target="RFC8200"/>, with examples
include Fragment and Options headers). IP proxies <bcp14>MAY</bcp14> reject requ that include Fragment and Options headers). IP proxies <bcp14>MAY</bcp14> reject
ests to scope requests to scope
to protocol numbers that are used for extension headers. Upon receiving to protocol numbers that are used for extension headers. Upon receiving
packets, implementations that support scoping or routing by IP protocol number packets, implementations that support scoping or routing by Internet Protocol Nu
<bcp14>MUST</bcp14> walk the chain of extensions to find outermost non-extension mber
IP protocol <bcp14>MUST</bcp14> walk the chain of extensions to find the outermost non-exten
number to match against the scoping rule. Note that the ROUTE_ADVERTISEMENT sion Internet Protocol
capsule uses IP protocol number 0 to indicate that all protocols are allowed, Number to match against the scoping rule. Note that the ROUTE_ADVERTISEMENT
it does not restrict the route to the IPv6 Hop-by-Hop Options Header capsule uses Internet Protocol Number 0 to indicate that all protocols are allow
(<xref section="4.3" sectionFormat="of" target="IPv6"/>).</t> ed;
it does not restrict the route to the IPv6 Hop-by-Hop Options header
(<xref section="4.3" sectionFormat="of" target="RFC8200"/>).</t>
</section> </section>
</section> </section>
<section anchor="context-identifiers"> <section anchor="context-identifiers">
<name>Context Identifiers</name> <name>Context Identifiers</name>
<t>The mechanism for proxying IP in HTTP defined in this document allows f uture <t>The mechanism for proxying IP in HTTP defined in this document allows f uture
extensions to exchange HTTP Datagrams that carry different semantics from IP extensions to exchange HTTP Datagrams that carry different semantics from IP
payloads. Some of these extensions can augment IP payloads with additional data 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 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 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 associated with IP proxying request streams start with a Context ID field; see
<xref target="payload-format"/>.</t> <xref target="payload-format"/>.</t>
<t>Context IDs are 62-bit integers (0 to 2<sup>62</sup>-1). Context IDs ar e <t>Context IDs are 62-bit integers (0 to 2<sup>62</sup>-1). Context IDs ar e
encoded as variable-length integers; see <xref section="16" sectionFormat="of" t arget="QUIC"/>. The Context ID encoded as variable-length integers; see <xref section="16" sectionFormat="of" t arget="RFC9000"/>. The Context ID
value of 0 is reserved for IP payloads, while non-zero values are dynamically value of 0 is reserved for IP payloads, while non-zero values are dynamically
allocated. Non-zero even-numbered Context IDs are client-allocated, and allocated. Non-zero even-numbered Context IDs are client-allocated, and
odd-numbered Context IDs are proxy-allocated. The Context ID namespace is tied odd-numbered Context IDs are proxy-allocated. The Context ID namespace is tied
to a given HTTP request; it is possible for a Context ID with the same numeric to a given HTTP request; it is possible for a Context ID with the same numeric
value to be simultaneously allocated in distinct requests, potentially with value to be simultaneously allocated in distinct requests, potentially with
different semantics. Context IDs <bcp14>MUST NOT</bcp14> be re-allocated within a given HTTP different semantics. Context IDs <bcp14>MUST NOT</bcp14> be re-allocated within a given HTTP
request but <bcp14>MAY</bcp14> be allocated in any order. The Context ID allocat ion request but <bcp14>MAY</bcp14> be allocated in any order. The Context ID allocat ion
restrictions to the use of even-numbered and odd-numbered Context IDs exist in restrictions to the use of even-numbered and odd-numbered Context IDs exist in
order to avoid the need for synchronization between endpoints. However, once a order to avoid the need for synchronization between endpoints. However, once a
Context ID has been allocated, those restrictions do not apply to the use of Context ID has been allocated, those restrictions do not apply to the use of
skipping to change at line 733 skipping to change at line 721
semantics and format of a given Context ID. This document does not define how semantics and format of a given Context ID. This document does not define how
registration occurs. Future extensions <bcp14>MAY</bcp14> use HTTP header fields or capsules registration occurs. Future extensions <bcp14>MAY</bcp14> use HTTP header fields or capsules
to register Context IDs. Depending on the method being used, it is possible for 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. 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 For instance, this can be due to reordering of the packet containing the
datagram and the packet containing the registration message during transmission. </t> datagram and the packet containing the registration message during transmission. </t>
</section> </section>
<section anchor="payload-format"> <section anchor="payload-format">
<name>HTTP Datagram Payload Format</name> <name>HTTP Datagram Payload Format</name>
<t>When associated with IP proxying request streams, the HTTP Datagram Pay load <t>When associated with IP proxying request streams, the HTTP Datagram Pay load
field of HTTP Datagrams (see <xref target="HTTP-DGRAM"/>) has the format defined field of HTTP Datagrams (see <xref target="RFC9297"/>) has the format defined in
in <xref target="dgram-format"/>. Note that, when HTTP Datagrams are encoded using
<xref target="dgram-format"/>. Note that when HTTP Datagrams are encoded using Q QUIC DATAGRAM
UIC DATAGRAM
frames, the Context ID field defined below directly follows the Quarter Stream frames, the Context ID field defined below directly follows the Quarter Stream
ID field which is at the start of the QUIC DATAGRAM frame payload:</t> ID field that is at the start of the QUIC DATAGRAM frame payload:</t>
<figure anchor="dgram-format"> <figure anchor="dgram-format">
<name>IP Proxying HTTP Datagram Format</name> <name>IP Proxying HTTP Datagram Format</name>
<artwork><![CDATA[ <artwork><![CDATA[
IP Proxying HTTP Datagram Payload { IP Proxying HTTP Datagram Payload {
Context ID (i), Context ID (i),
Payload (..), Payload (..),
} }
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The IP Proxying HTTP Datagram Payload contains the following fields:</t > <t>The IP Proxying HTTP Datagram Payload contains the following fields:</t >
<dl spacing="compact"> <dl spacing="normal" newline="true">
<dt>Context ID:</dt> <dt>Context ID:</dt>
<dd> <dd>
<t>A variable-length integer that contains the value of the Context ID . If an <t>A variable-length integer that contains the value of the Context ID . If an
HTTP/3 datagram which carries an unknown Context ID is received, the receiver HTTP/3 datagram that carries an unknown Context ID is received, the receiver
<bcp14>SHALL</bcp14> either drop that datagram silently or buffer it temporarily (on the order <bcp14>SHALL</bcp14> either drop that datagram silently or buffer it temporarily (on the order
of a round trip) while awaiting the registration of the corresponding Context of a round trip) while awaiting the registration of the corresponding Context
ID.</t> ID.</t>
</dd> </dd>
<dt>Payload:</dt> <dt>Payload:</dt>
<dd> <dd>
<t>The payload of the datagram, whose semantics depend on value of the previous <t>The payload of the datagram, whose semantics depend on value of the previous
field. Note that this field can be empty.</t> field. Note that this field can be empty.</t>
</dd> </dd>
</dl> </dl>
<t>IP packets are encoded using HTTP Datagrams with the Context ID set to zero. <t>IP packets are encoded using HTTP Datagrams with the Context ID set to zero.
When the Context ID is set to zero, the Payload field contains a full IP packet When the Context ID is set to zero, the Payload field contains a full IP packet
(from the IP Version field until the last byte of the IP Payload).</t> (from the IP Version field until the last byte of the IP payload).</t>
</section> </section>
<section anchor="ip-packet-handling"> <section anchor="ip-packet-handling">
<name>IP Packet Handling</name> <name>IP Packet Handling</name>
<t>This document defines a tunneling mechanism that is conceptually an IP link. <t>This document defines a tunneling mechanism that is conceptually an IP link.
However, because links are attached to IP routers, implementations might need However, because links are attached to IP routers, implementations might need
to handle some of the responsibilities of IP routers if they do not delegate to handle some of the responsibilities of IP routers if they do not delegate
them to another implementation such as a kernel.</t> them to another implementation, such as a kernel.</t>
<section anchor="link-operation"> <section anchor="link-operation">
<name>Link Operation</name> <name>Link Operation</name>
<t>The IP forwarding tunnels described in this document are not fully fe atured <t>The IP forwarding tunnels described in this document are not fully fe atured
"interfaces" in the IPv6 addressing architecture sense <xref target="IPv6-ADDR"/ >. "interfaces" in the IPv6 addressing architecture sense <xref target="RFC4291"/>.
In particular, they do not necessarily have IPv6 link-local addresses. In particular, they do not necessarily have IPv6 link-local addresses.
Additionally, IPv6 stateless autoconfiguration or router advertisement messages Additionally, IPv6 stateless autoconfiguration or router advertisement messages
are not used in such interfaces, and neither is neighbor discovery.</t> are not used in such interfaces, and neither is neighbor discovery.</t>
<t>Clients <bcp14>MAY</bcp14> optimistically start sending proxied IP pa ckets before receiving <t>When using HTTP/2 or HTTP/3, a client <bcp14>MAY</bcp14> optimistical ly start sending proxied IP packets before receiving
the response to its IP proxying request, noting however that those may not be 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 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 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 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 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 it chooses to provide different addressing or routing information than what the
client assumed.</t> client assumed.</t>
<t>Note that it is possible for multiple proxied IP packets to be encaps ulated in <t>Note that it is possible for multiple proxied IP packets to be encaps ulated in
the same outer packet, for example because a QUIC packet can carry two QUIC the same outer packet, for example, because a QUIC packet can carry more than on
DATAGRAM frames. It is also possible for a proxied IP packet to span multiple e QUIC
DATAGRAM frame. It is also possible for a proxied IP packet to span multiple
outer packets, because a DATAGRAM capsule can be split across multiple QUIC or outer packets, because a DATAGRAM capsule can be split across multiple QUIC or
TCP packets.</t> TCP packets.</t>
</section> </section>
<section anchor="routing-operation"> <section anchor="routing-operation">
<name>Routing Operation</name> <name>Routing Operation</name>
<t>The requirements in this section are a repetition of requirements tha t apply to <t>The requirements in this section are a repetition of requirements tha t apply to
IP routers in general, and might not apply to implementations of IP proxying IP routers in general and might not apply to implementations of IP proxying
that rely on external software for routing.</t> that rely on external software for routing.</t>
<t>When an endpoint receives an HTTP Datagram containing an IP packet, i t will <t>When an endpoint receives an HTTP Datagram containing an IP packet, i t will
parse the packet's IP header, perform any local policy checks (e.g., source 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, 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 and then send the IP packet on that interface or pass it to a local
application. The endpoint can also choose to drop any received packets instead application. The endpoint can also choose to drop any received packets instead
of forwarding them. If a received IP packet fails any correctness or policy of forwarding them. If a received IP packet fails any correctness or policy
checks, that is a forwarding error, not a protocol violation as far as IP checks, that is a forwarding error, not a protocol violation, as far as IP
proxying is concerned; see <xref target="error-signal"/>. IP proxying endpoints <bcp14>MAY</bcp14> proxying is concerned; see <xref target="error-signal"/>. IP proxying endpoints <bcp14>MAY</bcp14>
implement additional filtering policies on the IP packets they forward.</t> implement additional filtering policies on the IP packets they forward.</t>
<t>In the other direction, when an endpoint receives an IP packet, it ch ecks to see <t>In the other direction, when an endpoint receives an IP packet, it ch ecks to see
if the packet matches the routes mapped for an IP tunnel, and performs the same 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.</ t> forwarding checks as above before transmitting the packet over HTTP Datagrams.</ t>
<t>When IP proxying endpoints forward IP packets between different links , they <t>When IP proxying endpoints forward IP packets between different links , they
will decrement the IP Hop Count (or TTL) upon encapsulation, but not upon will decrement the IP Hop Count (or TTL) upon encapsulation but not upon
decapsulation. In other words, the Hop Count is decremented right before an IP 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 packet is transmitted in an HTTP Datagram. This prevents infinite loops in the
presence of routing loops, and matches the choices in IPsec <xref target="IPSEC" />. presence of routing loops and matches the choices in IPsec <xref target="RFC4301 "/>.
This does not apply to IP packets generated by the IP proxying endpoint itself.< /t> This does not apply to IP packets generated by the IP proxying endpoint itself.< /t>
<t>Implementers need to ensure that they do not forward any link-local t raffic <t>Implementers need to ensure that they do not forward any link-local t raffic
beyond the IP proxying interface that it was received on. IP proxying endpoints beyond the IP proxying interface that it was received on. IP proxying endpoints
also need to properly reply to packets destined to link-local multicast also need to properly reply to packets destined to link-local multicast
addresses.</t> addresses.</t>
<t>IPv6 requires that every link have an MTU of at least 1280 bytes <xre f target="IPv6"/>. <t>IPv6 requires that every link have an MTU of at least 1280 bytes <xref target ="RFC8200"/>.
Since IP proxying in HTTP conveys IP packets in HTTP Datagrams and those can in Since IP proxying in HTTP conveys IP packets in HTTP Datagrams and those can in
turn be sent in QUIC DATAGRAM frames which cannot be fragmented turn be sent in QUIC DATAGRAM frames that cannot be fragmented
<xref target="DGRAM"/>, the MTU of an IP tunnel can be limited by the MTU of the <xref target="RFC9221"/>, the MTU of an IP tunnel can be limited by the MTU of t
he
QUIC connection that IP proxying is operating over. This can lead to situations QUIC connection that IP proxying is operating over. This can lead to situations
where the IPv6 minimum link MTU is violated. IP proxying endpoints that operate where the IPv6 minimum link MTU is violated. IP proxying endpoints that operate
as routers and support IPv6 <bcp14>MUST</bcp14> ensure that the IP tunnel link M TU is at least as routers and support IPv6 <bcp14>MUST</bcp14> ensure that the IP tunnel link M TU is at least
1280 (i.e., that they can send HTTP Datagrams with payloads of at least 1280 1280 bytes (i.e., that they can send HTTP Datagrams with payloads of at least 12 80
bytes). This can be accomplished using various techniques:</t> bytes). This can be accomplished using various techniques:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>if both IP proxying endpoints know for certain that HTTP intermedi aries are <li>If both IP proxying endpoints know for certain that HTTP intermedi aries are
not in use, the endpoints can pad the QUIC INITIAL packets of the outer not in use, the endpoints can pad the QUIC INITIAL packets of the outer
QUIC connection that IP proxying is running over. (Assuming QUIC version 1 is QUIC connection that IP proxying is running over. (Assuming QUIC version 1 is
in use, the overhead is 1 byte type, 20 bytes maximal connection ID length, 4 in use, the overhead is 1 byte for the type, 20 bytes for the maximal connection
bytes maximal packet number length, 1 byte DATAGRAM frame type, 8 bytes ID length, 4
maximal quarter stream ID, one byte for the zero Context ID, and 16 bytes for bytes for the maximal packet number length, 1 byte for the DATAGRAM frame type,
the AEAD authentication tag, for a total of 51 bytes of overhead which 8 bytes
for the maximal Quarter Stream ID, 1 byte for the zero Context ID, and 16 bytes
for
the Authenticated Encryption with Associated Data (AEAD) authentication tag, for
a total of 51 bytes of overhead, which
corresponds to padding QUIC INITIAL packets to 1331 bytes or more.)</li> corresponds to padding QUIC INITIAL packets to 1331 bytes or more.)</li>
<li>IP proxying endpoints can also send ICMPv6 echo requests with 1232 bytes of <li>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 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 receive a response. Unless endpoints have an out-of-band means of
guaranteeing that the previous techniques is sufficient, they <bcp14>MUST</bcp14 > use this guaranteeing that the previous techniques are sufficient, they <bcp14>MUST</bcp1 4> use this
method. If an endpoint does not know an IPv6 address of its peer, it can send method. If an endpoint does not know an IPv6 address of its peer, it can send
the ICMPv6 echo request to the link local all nodes multicast address the ICMPv6 echo request to the link-local all nodes multicast address
(ff02::1).</li> (ff02::1).</li>
</ul> </ul>
<t>If an endpoint is using QUIC DATAGRAM frames to convey IPv6 packets, and it <t>If an endpoint is using QUIC DATAGRAM frames to convey IPv6 packets a nd it
detects that the QUIC MTU is too low to allow sending 1280 bytes, it <bcp14>MUST </bcp14> abort detects that the QUIC MTU is too low to allow sending 1280 bytes, it <bcp14>MUST </bcp14> abort
the IP proxying request stream.</t> the IP proxying request stream.</t>
<section anchor="error-signal"> <section anchor="error-signal">
<name>Error Signalling</name> <name>Error Signalling</name>
<t>Since IP proxying endpoints often forward IP packets onwards to oth er network <t>Since IP proxying endpoints often forward IP packets onwards to oth er network
interfaces, they need to handle errors in the forwarding process. For example, 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 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 address, 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 the MTU of the outgoing link is lower than the size of the packet to be
forwarded. In such scenarios, IP proxying endpoints <bcp14>SHOULD</bcp14> use IC MP forwarded. In such scenarios, IP proxying endpoints <bcp14>SHOULD</bcp14> use IC MP
<xref target="ICMP"/> <xref target="ICMPv6"/> to signal the forwarding error to its <xref target="RFC0792"/> <xref target="RFC4443"/> to signal the forwarding error to its
peer by generating ICMP packets and sending them using HTTP Datagrams.</t> peer by generating ICMP packets and sending them using HTTP Datagrams.</t>
<t>Endpoints are free to select the most appropriate ICMP errors to se nd. Some <t>Endpoints are free to select the most appropriate ICMP errors to se nd. Some
examples that are relevant for IP proxying include:</t> examples that are relevant for IP proxying include the following:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>For invalid source addresses, send Destination Unreachable (<xre <li>For invalid source addresses, send Destination Unreachable (<xre
f section="3.1" sectionFormat="of" target="ICMPv6"/>) with code 5, "Source addre f section="3.1" sectionFormat="of" target="RFC4443"/>) with code 5, "Source addr
ss failed ingress/egress policy".</li> ess failed ingress/egress policy".</li>
<li>For unroutable destination addresses, send Destination Unreachab <li>For unroutable destination addresses, send Destination Unreachab
le (<xref section="3.1" sectionFormat="of" target="ICMPv6"/>) with a code 0, "No le (<xref section="3.1" sectionFormat="of" target="RFC4443"/>) with code 0, "No
route to destination", or code 1, route to destination", or code 1,
"Communication with destination administratively prohibited".</li> "Communication with destination administratively prohibited".</li>
<li>For packets that cannot fit within the MTU of the outgoing link, send Packet <li>For packets that cannot fit within the MTU of the outgoing link, send Packet
Too Big (<xref section="3.2" sectionFormat="of" target="ICMPv6"/>).</li> Too Big (<xref section="3.2" sectionFormat="of" target="RFC4443"/>).</li>
</ul> </ul>
<t>In order to receive these errors, endpoints need to be prepared to receive ICMP <t>In order to receive these errors, endpoints need to be prepared to receive ICMP
packets. If an endpoint does not send ROUTE_ADVERTISEMENT capsules, such as a packets. If an endpoint does not send ROUTE_ADVERTISEMENT capsules, such as a
client opening an IP flow through an IP proxy, it <bcp14>SHOULD</bcp14> process proxied ICMP client opening an IP flow through an IP proxy, it <bcp14>SHOULD</bcp14> process proxied ICMP
packets from its peer in order to receive these errors. Note that ICMP messages 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 can originate from a source address different from that of the IP proxying
peer, and also from outside the target if scoping is in use (see <xref target="s cope"/>).</t> peer and also from outside the target if scoping is in use (see <xref target="sc ope"/>).</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="examples"> <section anchor="examples">
<name>Examples</name> <name>Examples</name>
<t>IP proxying in HTTP enables many different use cases that can benefit f rom IP <t>IP proxying in HTTP enables many different use cases that can benefit f rom IP
packet proxying and tunnelling. These examples are provided to help illustrate packet proxying and tunnelling. These examples are provided to help illustrate
some of the ways in which IP proxying in HTTP can be used.</t> some of the ways in which IP proxying in HTTP can be used.</t>
<section anchor="example-remote"> <section anchor="example-remote">
<name>Remote Access VPN</name> <name>Remote Access VPN</name>
<t>The following example shows a point-to-network VPN setup, where a cli ent <t>The following example shows a point-to-network VPN setup, where a cli ent
receives a set of local addresses, and can send to any remote host through the 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.</t> IP proxy. Such VPN setups can be either full-tunnel or split-tunnel.</t>
<figure anchor="diagram-tunnel"> <figure anchor="diagram-tunnel">
<name>VPN Tunnel Setup</name> <name>VPN Tunnel Setup</name>
<artset> <artset>
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= "1.1" height="128" width="512" viewBox="0 0 512 128" class="diagram" text-anchor ="middle" font-family="monospace" font-size="13px"> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= "1.1" viewBox="0 0 768 128" class="diagram" text-anchor="middle" font-family="m onospace" font-size="13px">
<path d="M 8,32 L 8,96" fill="none" stroke="black"/> <path d="M 8,32 L 8,96" fill="none" stroke="black"/>
<path d="M 80,32 L 80,96" fill="none" stroke="black"/> <path d="M 80,32 L 80,96" fill="none" stroke="black"/>
<path d="M 248,32 L 248,96" fill="none" stroke="black"/> <path d="M 248,32 L 248,96" fill="none" stroke="black"/>
<path d="M 320,32 L 320,96" fill="none" stroke="black"/> <path d="M 320,32 L 320,96" fill="none" stroke="black"/>
<path d="M 416,32 L 416,96" fill="none" stroke="black"/> <path d="M 416,32 L 416,96" fill="none" stroke="black"/>
<path d="M 8,32 L 80,32" fill="none" stroke="black"/> <path d="M 8,32 L 80,32" fill="none" stroke="black"/>
<path d="M 248,32 L 320,32" fill="none" stroke="black"/> <path d="M 248,32 L 320,32" fill="none" stroke="black"/>
<path d="M 416,32 L 448,32" fill="none" stroke="black"/> <path d="M 416,32 L 448,32" fill="none" stroke="black"/>
<path d="M 80,48 L 248,48" fill="none" stroke="black"/> <path d="M 80,48 L 248,48" fill="none" stroke="black"/>
<path d="M 192,64 L 216,64" fill="none" stroke="black"/> <path d="M 192,64 L 216,64" fill="none" stroke="black"/>
skipping to change at line 1039 skipping to change at line 1027
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="site-to-site-vpn"> <section anchor="site-to-site-vpn">
<name>Site-to-Site VPN</name> <name>Site-to-Site VPN</name>
<t>The following example shows how to connect a branch office network to a <t>The following example shows how to connect a branch office network to a
corporate network such that all machines on those networks can communicate. In corporate network such that all machines on those networks can communicate. In
this example, the IP proxying client is attached to the branch office network this example, the IP proxying client is attached to the branch office network
192.0.2.0/24, and the IP proxy is attached to the corporate network 192.0.2.0/24, and the IP proxy is attached to the corporate network
203.0.113.0/24. There are legacy clients on the branch office network that only 203.0.113.0/24. There are legacy clients on the branch office network that only
allow maintenance requests from machines on their subnet, so the IP Proxy is allow maintenance requests from machines on their subnet, so the IP proxy is
provisioned with an IP address from that subnet.</t> provisioned with an IP address from that subnet.</t>
<figure anchor="diagram-s2s"> <figure anchor="diagram-s2s">
<name>Site-to-site VPN Example</name> <name>Site-to-Site VPN Example</name>
<artset> <artset>
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= "1.1" height="128" width="560" viewBox="0 0 560 128" class="diagram" text-anchor ="middle" font-family="monospace" font-size="13px"> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= "1.1" viewBox="0 0 700 128" class="diagram" text-anchor="middle" font-family="mo nospace" font-size="13px">
<path d="M 112,32 L 112,96" fill="none" stroke="black"/> <path d="M 112,32 L 112,96" fill="none" stroke="black"/>
<path d="M 144,32 L 144,96" fill="none" stroke="black"/> <path d="M 144,32 L 144,96" fill="none" stroke="black"/>
<path d="M 216,32 L 216,96" fill="none" stroke="black"/> <path d="M 216,32 L 216,96" fill="none" stroke="black"/>
<path d="M 328,32 L 328,96" fill="none" stroke="black"/> <path d="M 328,32 L 328,96" fill="none" stroke="black"/>
<path d="M 392,32 L 392,96" fill="none" stroke="black"/> <path d="M 392,32 L 392,96" fill="none" stroke="black"/>
<path d="M 424,32 L 424,96" fill="none" stroke="black"/> <path d="M 424,32 L 424,96" fill="none" stroke="black"/>
<path d="M 88,32 L 112,32" fill="none" stroke="black"/> <path d="M 88,32 L 112,32" fill="none" stroke="black"/>
<path d="M 144,32 L 216,32" fill="none" stroke="black"/> <path d="M 144,32 L 216,32" fill="none" stroke="black"/>
<path d="M 328,32 L 392,32" fill="none" stroke="black"/> <path d="M 328,32 L 392,32" fill="none" stroke="black"/>
<path d="M 424,32 L 456,32" fill="none" stroke="black"/> <path d="M 424,32 L 456,32" fill="none" stroke="black"/>
skipping to change at line 1099 skipping to change at line 1087
192.0.2.3 <--+ +--------+ +-------+ +---> 203.0.113.7 192.0.2.3 <--+ +--------+ +-------+ +---> 203.0.113.7
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>In this case, the client does not specify any scope in its request. T he IP <t>In this case, the client does not specify any scope in its request. T he IP
proxy assigns the client an IPv4 address (203.0.113.100) and a split-tunnel proxy assigns the client an IPv4 address (203.0.113.100) and a split-tunnel
route to the corporate network (203.0.113.0/24). The client assigns the IP route to the corporate network (203.0.113.0/24). The client assigns the IP
proxy an IPv4 address (192.0.2.200) and a split-tunnel route to the branch proxy an IPv4 address (192.0.2.200) and a split-tunnel route to the branch
office network (192.0.2.0/24). This allows hosts on both networks to office network (192.0.2.0/24). This allows hosts on both networks to
communicate with each other, and allows the IP proxy to perform maintenance on communicate with each other and allows the IP proxy to perform maintenance on
legacy hosts in the branch office. Note that IP proxying endpoints will legacy hosts in the branch office. Note that IP proxying endpoints will
decrement the IP Hop Count (or TTL) when encapsulating forwarded packets, so decrement the IP Hop Count (or TTL) when encapsulating forwarded packets, so
protocols that require that field be set to 255 will not function.</t> protocols that require that field be set to 255 will not function.</t>
<figure anchor="fig-s2s"> <figure anchor="fig-s2s">
<name>Site-to-site VPN Capsule Example</name> <name>Site-to-Site VPN Capsule Example</name>
<artwork><![CDATA[ <artwork><![CDATA[
[[ From Client ]] [[ From IP Proxy ]] [[ From Client ]] [[ From IP Proxy ]]
SETTINGS SETTINGS
H3_DATAGRAM = 1 H3_DATAGRAM = 1
SETTINGS SETTINGS
ENABLE_CONNECT_PROTOCOL = 1 ENABLE_CONNECT_PROTOCOL = 1
H3_DATAGRAM = 1 H3_DATAGRAM = 1
skipping to change at line 1170 skipping to change at line 1158
DATAGRAM DATAGRAM
Quarter Stream ID = 11 Quarter Stream ID = 11
Context ID = 0 Context ID = 0
Payload = Encapsulated IP Packet Payload = Encapsulated IP Packet
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="ip-flow-forwarding"> <section anchor="ip-flow-forwarding">
<name>IP Flow Forwarding</name> <name>IP Flow Forwarding</name>
<t>The following example shows an IP flow forwarding setup, where a clie nt <t>The following example shows an IP flow forwarding setup, where a clie nt
requests to establish a forwarding tunnel to target.example.com using SCTP (IP requests to establish a forwarding tunnel to target.example.com using the Stream
protocol 132), and receives a single local address and remote address it can Control Transmission Protocol (SCTP) (IP
protocol 132) and receives a single local address and remote address it can
use for transmitting packets. A similar approach could be used for any other IP use for transmitting packets. A similar approach could be used for any other IP
protocol that isn't easily proxied with existing HTTP methods, such as ICMP, protocol that isn't easily proxied with existing HTTP methods, such as ICMP,
ESP, etc.</t> Encapsulating Security Payload (ESP), etc.</t>
<figure anchor="diagram-flow"> <figure anchor="diagram-flow">
<name>Proxied Flow Setup</name> <name>Proxied Flow Setup</name>
<artset> <artset>
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= "1.1" height="128" width="440" viewBox="0 0 440 128" class="diagram" text-anchor ="middle" font-family="monospace" font-size="13px"> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= "1.1" viewBox="0 0 660 128" class="diagram" text-anchor="middle" font-family="m onospace" font-size="13px">
<path d="M 8,32 L 8,96" fill="none" stroke="black"/> <path d="M 8,32 L 8,96" fill="none" stroke="black"/>
<path d="M 80,32 L 80,96" fill="none" stroke="black"/> <path d="M 80,32 L 80,96" fill="none" stroke="black"/>
<path d="M 240,32 L 240,96" fill="none" stroke="black"/> <path d="M 240,32 L 240,96" fill="none" stroke="black"/>
<path d="M 312,32 L 312,96" fill="none" stroke="black"/> <path d="M 312,32 L 312,96" fill="none" stroke="black"/>
<path d="M 8,32 L 80,32" fill="none" stroke="black"/> <path d="M 8,32 L 80,32" fill="none" stroke="black"/>
<path d="M 240,32 L 312,32" fill="none" stroke="black"/> <path d="M 240,32 L 312,32" fill="none" stroke="black"/>
<path d="M 80,48 L 240,48" fill="none" stroke="black"/> <path d="M 80,48 L 240,48" fill="none" stroke="black"/>
<path d="M 160,64 L 184,64" fill="none" stroke="black"/> <path d="M 160,64 L 184,64" fill="none" stroke="black"/>
<path d="M 312,64 L 392,64" fill="none" stroke="black"/> <path d="M 312,64 L 392,64" fill="none" stroke="black"/>
<path d="M 80,80 L 240,80" fill="none" stroke="black"/> <path d="M 80,80 L 240,80" fill="none" stroke="black"/>
skipping to change at line 1222 skipping to change at line 1210
<artwork type="ascii-art"><![CDATA[ <artwork type="ascii-art"><![CDATA[
+--------+ IP A IP B +--------+ +--------+ IP A IP B +--------+
| +-------------------+ IP | IP C | +-------------------+ IP | IP C
| Client | IP C <--> D | Proxy +---------> IP D | Client | IP C <--> D | Proxy +---------> IP D
| +-------------------+ | | +-------------------+ |
+--------+ +--------+ +--------+ +--------+
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>In this case, the client specfies both a target hostname and an IP pr <t>In this case, the client specifies both a target hostname and an Inte
otocol rnet Protocol
number in the scope of its request, indicating that it only needs to 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 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 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 instead of allocating an entire IP address to the client. In this regard, the
request is similar to a regular CONNECT proxy request.</t> request is similar to a regular CONNECT proxy request.</t>
<t>The IP proxy assigns a single IPv6 address to the client (2001:db8:12 34::a) and <t>The IP proxy assigns a single IPv6 address to the client (2001:db8:12 34::a) and
a route to a single IPv6 host (2001:db8:3456::b), scoped to SCTP. The client 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.</t> can send and receive SCTP IP packets to the remote host.</t>
<figure anchor="fig-flow"> <figure anchor="fig-flow">
<name>Proxied SCTP Flow Example</name> <name>Proxied SCTP Flow Example</name>
<artwork><![CDATA[ <artwork><![CDATA[
[[ From Client ]] [[ From IP Proxy ]] [[ From Client ]] [[ From IP Proxy ]]
SETTINGS SETTINGS
H3_DATAGRAM = 1 H3_DATAGRAM = 1
SETTINGS SETTINGS
skipping to change at line 1285 skipping to change at line 1273
Quarter Stream ID = 11 Quarter Stream ID = 11
Context ID = 0 Context ID = 0
Payload = Encapsulated SCTP/IP Packet Payload = Encapsulated SCTP/IP Packet
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="proxied-connection-racing"> <section anchor="proxied-connection-racing">
<name>Proxied Connection Racing</name> <name>Proxied Connection Racing</name>
<t>The following example shows a setup where a client is proxying UDP pa ckets <t>The following example shows a setup where a client is proxying UDP pa ckets
through an IP proxy in order to control connection establishment racing through through an IP proxy in order to control connection establishment racing through
an IP proxy, as defined in Happy Eyeballs <xref target="HEv2"/>. This example is an IP proxy, as defined in Happy Eyeballs <xref target="RFC8305"/>. This example
a is a
variant of the proxied flow, but highlights how IP-level proxying can enable variant of the proxied flow but highlights how IP-level proxying can enable
new capabilities even for TCP and UDP.</t> new capabilities, even for TCP and UDP.</t>
<figure anchor="diagram-racing"> <figure anchor="diagram-racing">
<name>Proxied Connection Racing Setup</name> <name>Proxied Connection Racing Setup</name>
<artset> <artset>
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= "1.1" height="144" width="472" viewBox="0 0 472 144" class="diagram" text-anchor ="middle" font-family="monospace" font-size="13px"> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= "1.1" viewBox="0 0 708 144" class="diagram" text-anchor="middle" font-family="mo nospace" font-size="13px">
<path d="M 8,32 L 8,112" fill="none" stroke="black"/> <path d="M 8,32 L 8,112" fill="none" stroke="black"/>
<path d="M 80,32 L 80,112" fill="none" stroke="black"/> <path d="M 80,32 L 80,112" fill="none" stroke="black"/>
<path d="M 240,32 L 240,112" fill="none" stroke="black"/> <path d="M 240,32 L 240,112" fill="none" stroke="black"/>
<path d="M 312,32 L 312,112" fill="none" stroke="black"/> <path d="M 312,32 L 312,112" fill="none" stroke="black"/>
<path d="M 8,32 L 80,32" fill="none" stroke="black"/> <path d="M 8,32 L 80,32" fill="none" stroke="black"/>
<path d="M 240,32 L 312,32" fill="none" stroke="black"/> <path d="M 240,32 L 312,32" fill="none" stroke="black"/>
<path d="M 80,48 L 240,48" fill="none" stroke="black"/> <path d="M 80,48 L 240,48" fill="none" stroke="black"/>
<path d="M 320,48 L 424,48" fill="none" stroke="black"/> <path d="M 320,48 L 424,48" fill="none" stroke="black"/>
<path d="M 144,64 L 168,64" fill="none" stroke="black"/> <path d="M 144,64 L 168,64" fill="none" stroke="black"/>
<path d="M 144,80 L 168,80" fill="none" stroke="black"/> <path d="M 144,80 L 168,80" fill="none" stroke="black"/>
skipping to change at line 1349 skipping to change at line 1337
+--------+ IP A IP B +--------+ IP C +--------+ IP A IP B +--------+ IP C
| +-------------------+ |<------------> IP E | +-------------------+ |<------------> IP E
| Client | IP C <--> E | IP | | Client | IP C <--> E | IP |
| | D <--> F | Proxy | | | D <--> F | Proxy |
| +-------------------+ |<------------> IP F | +-------------------+ |<------------> IP F
+--------+ +--------+ IP D +--------+ +--------+ IP D
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>As with proxied flows, the client specifies both a target hostname an <t>As with proxied flows, the client specifies both a target hostname an
d an IP d an Internet
protocol number in the scope of its request. When the IP proxy performs DNS 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 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 options to the client as separate routes. It can also ensure that the client
has both IPv4 and IPv6 addresses assigned.</t> has both IPv4 and IPv6 addresses assigned.</t>
<t>The IP proxy assigns both an IPv4 address (192.0.2.3) and an IPv6 <t>The IP proxy assigns 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 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 (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 resolved addresses of the target hostname, scoped to UDP. The client can send
and receive UDP IP packets to either one of the IP proxy addresses to enable and receive UDP IP packets to either one of the IP proxy addresses to enable
Happy Eyeballs through the IP proxy.</t> Happy Eyeballs through the IP proxy.</t>
<figure anchor="fig-listen"> <figure anchor="fig-listen">
skipping to change at line 1425 skipping to change at line 1413
Payload = Encapsulated IPv4 Packet Payload = Encapsulated IPv4 Packet
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
</section> </section>
<section anchor="extensibility-considerations"> <section anchor="extensibility-considerations">
<name>Extensibility Considerations</name> <name>Extensibility Considerations</name>
<t>Extensions to IP proxying in HTTP can define behavior changes to this <t>Extensions to IP proxying in HTTP can define behavior changes to this
mechanism. Such extensions <bcp14>SHOULD</bcp14> define new capsule types to exc hange mechanism. Such extensions <bcp14>SHOULD</bcp14> define new capsule types to exc hange
configuration information if needed. It is <bcp14>RECOMMENDED</bcp14> for extens configuration information if needed.
ions that It is <bcp14>RECOMMENDED</bcp14> for extensions that
modify addressing to specify that their extension capsules be sent before the 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 and that they do not take effect until the
ADDRESS_ASSIGN capsule is parsed. This allows modifications to address ADDRESS_ASSIGN capsule is parsed. This allows modifications to address
assignment to operate atomically. Similarly, extensions that modify routing assignment to operate atomically. Similarly, extensions that modify routing
<bcp14>SHOULD</bcp14> behave similarly with regard to the ROUTE_ADVERTISEMENT ca psule.</t> <bcp14>SHOULD</bcp14> behave similarly with regard to the ROUTE_ADVERTISEMENT ca psule.</t>
</section> </section>
<section anchor="performance-considerations"> <section anchor="performance-considerations">
<name>Performance Considerations</name> <name>Performance Considerations</name>
<t>Bursty traffic can often lead to temporally-correlated packet losses; i n turn, <t>Bursty traffic can often lead to temporally correlated packet losses; i n turn,
this can lead to suboptimal responses from congestion controllers in protocols this can lead to suboptimal responses from congestion controllers in protocols
running inside the tunnel. To avoid this, IP proxying endpoints <bcp14>SHOULD</b cp14> strive running inside the tunnel. To avoid this, IP proxying endpoints <bcp14>SHOULD</b cp14> strive
to avoid increasing burstiness of IP traffic; they <bcp14>SHOULD NOT</bcp14> que ue packets in to avoid increasing burstiness of IP traffic; they <bcp14>SHOULD NOT</bcp14> que ue packets in
order to increase batching beyond the minimal amount required to take advantage order to increase batching beyond the minimal amount required to take advantage
of hardware offloads.</t> of hardware offloads.</t>
<t>When the protocol running inside the tunnel uses congestion control (e. g., <t>When the protocol running inside the tunnel uses congestion control (e. g.,
<xref target="TCP"/> or <xref target="QUIC"/>), the proxied traffic will incur a t least two nested <xref target="RFC9293"/> or <xref target="RFC9000"/>), the proxied traffic will incur at least two nested
congestion controllers. When tunneled packets are sent using QUIC DATAGRAM congestion controllers. When tunneled packets are sent using QUIC DATAGRAM
frames, the outer HTTP connection <bcp14>MAY</bcp14> disable congestion control for those frames, the outer HTTP connection <bcp14>MAY</bcp14> disable congestion control for those
packets that contain only QUIC DATAGRAM frames encapsulating IP packets. packets that contain only QUIC DATAGRAM frames encapsulating IP packets.
Implementers will benefit from reading the guidance in <xref section="3.1.11" se Implementers will benefit from reading the guidance in <xref section="3.1.11" se
ctionFormat="of" target="UDP-USAGE"/>.</t> ctionFormat="of" target="RFC8085"/>.</t>
<t>When the protocol running inside the tunnel uses loss recovery (e.g., < <t>When the protocol running inside the tunnel uses loss recovery (e.g., <
xref target="TCP"/> xref target="RFC9293"/>
or <xref target="QUIC"/>), and the outer HTTP connection runs over TCP, the prox or <xref target="RFC9000"/>) and the outer HTTP connection runs over TCP, the pr
ied traffic oxied traffic
will incur at least two nested loss recovery mechanisms. This can reduce will incur at least two nested loss recovery mechanisms. This can reduce
performance as both can sometimes independently retransmit the same data. To performance, as both can sometimes independently retransmit the same data. To
avoid this, IP proxying <bcp14>SHOULD</bcp14> be performed over HTTP/3 to allow leveraging the avoid this, IP proxying <bcp14>SHOULD</bcp14> be performed over HTTP/3 to allow leveraging the
QUIC DATAGRAM frame.</t> QUIC DATAGRAM frame.</t>
<section anchor="mtu-considerations"> <section anchor="mtu-considerations">
<name>MTU Considerations</name> <name>MTU Considerations</name>
<t>When using HTTP/3 with the QUIC Datagram extension <xref target="DGRA M"/>, IP packets are <t>When using HTTP/3 with the QUIC Datagram extension <xref target="RFC9 221"/>, IP packets are
transmitted in QUIC DATAGRAM frames. Since these frames cannot be fragmented, transmitted in QUIC DATAGRAM frames. Since these frames cannot be fragmented,
they can only carry packets up to a given length determined by the QUIC they can only carry packets up to a given length determined by the QUIC
connection configuration and the Path MTU (PMTU). If an endpoint is using QUIC connection configuration and the Path MTU (PMTU). If an endpoint is using QUIC
DATAGRAM frames and it attempts to route an IP packet through the tunnel that DATAGRAM frames and it attempts to route an IP packet through the tunnel that
will not fit inside a QUIC DATAGRAM frame, the IP proxy <bcp14>SHOULD NOT</bcp14 > send the IP will not fit inside a QUIC DATAGRAM frame, the IP proxy <bcp14>SHOULD NOT</bcp14 > send the IP
packet in a DATAGRAM capsule, as that defeats the end-to-end unreliability packet in a DATAGRAM capsule, as that defeats the end-to-end unreliability
characteristic that methods such as Datagram Packetization Layer PMTU Discovery characteristic that methods such as Datagram Packetization Layer PMTU Discovery
(DPLPMTUD) depend on <xref target="DPLPMTUD"/>. In this scenario, the endpoint (DPLPMTUD) depend on <xref target="RFC8899"/>. In this scenario, the endpoint
<bcp14>SHOULD</bcp14> drop the IP packet and send an ICMP Packet Too Big message to the sender <bcp14>SHOULD</bcp14> drop the IP packet and send an ICMP Packet Too Big message to the sender
of the dropped packet; see <xref section="3.2" sectionFormat="of" target="ICMPv6 "/>.</t> of the dropped packet; see <xref section="3.2" sectionFormat="of" target="RFC444 3"/>.</t>
</section> </section>
<section anchor="ecn-considerations"> <section anchor="ecn-considerations">
<name>ECN Considerations</name> <name>ECN Considerations</name>
<t>If an IP proxying endpoint with a connection containing an IP Proxyin g request <t>If an IP proxying endpoint with a connection containing an IP proxyin g request
stream disables congestion control, it cannot signal Explicit Congestion stream disables congestion control, it cannot signal Explicit Congestion
Notification (ECN) <xref target="ECN"/> support on that outer connection. That i Notification (ECN) <xref target="RFC3168"/> support on that outer connection. Th
s, at is,
the QUIC sender <bcp14>MUST</bcp14> mark all IP headers with the Not-ECT codepoi the QUIC sender <bcp14>MUST</bcp14> mark all IP headers with the Not ECN-Capable
nt for QUIC Transport (Not-ECT) codepoint for QUIC
packets which are outside of congestion control. The endpoint can still report packets that are outside of congestion control. The endpoint can still report
ECN feedback via QUIC ACK_ECN frames or the TCP ECE bit, as the peer might not ECN feedback via QUIC ACK_ECN frames or the TCP ECN-Echo (ECE) bit, as the peer
might not
have disabled congestion control.</t> have disabled congestion control.</t>
<t>Conversely, if congestion control is not disabled on the outer conges tion, the <t>Conversely, if congestion control is not disabled on the outer conges tion, the
guidance in <xref target="ECN-TUNNEL"/> about transferring ECN marks between inn er guidance in <xref target="RFC6040"/> about transferring ECN marks between inner
and outer IP headers does not apply because the outer connection will react and outer IP headers does not apply because the outer connection will react
correctly to congestion notifications if it uses ECN. The inner traffic can correctly to congestion notifications if it uses ECN. The inner traffic can
also use ECN, independently of whether it is in use on the outer connection.</t> also use ECN, independently of whether it is in use on the outer connection.</t>
</section> </section>
<section anchor="dscp-considerations"> <section anchor="dscp-considerations">
<name>Differentiated Services Considerations</name> <name>Differentiated Services Considerations</name>
<t>Tunneled IP packets can have Differentiated Services Code Points (DSC <t>Tunneled IP packets can have Differentiated Services Code Points (DSC
P) Ps)
<xref target="DSCP"/> set in the traffic class IP header field to request a <xref target="RFC2474"/> set in the traffic class IP header field to request a
particular per-hop behavior. If an IP proxying endpoint is configured as part particular per-hop behavior. If an IP proxying endpoint is configured as part
of a Differentiated Services domain, it <bcp14>MAY</bcp14> implement traffic dif ferentiation of a Differentiated Services domain, it <bcp14>MAY</bcp14> implement traffic dif ferentiation
based on these markings. However, the use of HTTP can limit the possibilities based on these markings. However, the use of HTTP can limit the possibilities
for differentiated treatment of the tunneled IP packets on the path between the for differentiated treatment of the tunneled IP packets on the path between the
IP proxying endpoints.</t> IP proxying endpoints.</t>
<t>When an HTTP connection is congestion-controlled, marking packets wit h <t>When an HTTP connection is congestion-controlled, marking packets wit h
different DSCP can lead to reordering between them, and that can in turn lead different DSCPs can lead to reordering between them, and that can in turn lead
the underlying transport connection's congestion controller to perform poorly. the underlying transport connection's congestion controller to perform poorly.
If tunneled packets are subject to congestion control by the outer connection, If tunneled packets are subject to congestion control by the outer connection,
they need to avoid carrying DSCP markings that are not equivalent in forwarding they need to avoid carrying DSCP markings that are not equivalent in forwarding
behavior to prevent this situation. In this scenario, the IP proxying endpoint behavior to prevent this situation. In this scenario, the IP proxying endpoint
<bcp14>MUST NOT</bcp14> copy the DSCP field from the inner IP header to the oute r IP header of <bcp14>MUST NOT</bcp14> copy the DSCP field from the inner IP header to the oute r IP header of
the packet carrying this packet. Instead, an application would need to use the packet carrying this packet. Instead, an application would need to use
separate connections to the proxy, one for each DSCP. Note that this document separate connections to the proxy, one for each DSCP. Note that this document
does not define a way for requests to scope to particular DSCP values; such does not define a way for requests to scope to particular DSCP values; such
support is left to future extensions.</t> support is left to future extensions.</t>
<t>If tunneled packets use QUIC datagrams and are not subject to congest ion <t>If tunneled packets use QUIC datagrams and are not subject to congest ion
control by the outer connection, the IP proxying endpoints <bcp14>MAY</bcp14> tr anslate the control by the outer connection, the IP proxying endpoints <bcp14>MAY</bcp14> tr anslate the
DSCP field value from the tunneled traffic to the outer IP header. IP proxying DSCP field value from the tunneled traffic to the outer IP header. IP proxying
endpoints <bcp14>MUST NOT</bcp14> coalesce multiple inner packets into the same outer packet endpoints <bcp14>MUST NOT</bcp14> coalesce multiple inner packets into the same outer packet
unless they have the same DSCP marking or an equivalent traffic class. Note unless they have the same DSCP marking or an equivalent traffic class. Note
that the ability to translate DSCP values is dependent on the tunnel ingress that the ability to translate DSCP values is dependent on the tunnel ingress
and egress belonging to the same differentiated service domain or not.</t> and egress belonging to the same Differentiated Service domain or not.</t>
</section> </section>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>There are significant risks in allowing arbitrary clients to establish a tunnel <t>There are significant risks in allowing arbitrary clients to establish a tunnel
that permits sending to arbitrary hosts, regardless of whether tunnels are 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 scoped to specific hosts or not. Bad actors could abuse this capability to send
traffic and have it attributed to the IP proxy. HTTP servers that support IP traffic and have it attributed to the IP proxy. HTTP servers that support IP
proxying <bcp14>SHOULD</bcp14> restrict its use to authenticated users. Dependin g on the proxying <bcp14>SHOULD</bcp14> restrict its use to authenticated users. Dependin g on the
deployment, possible authentication mechanisms include mutual TLS between IP deployment, possible authentication mechanisms include mutual TLS between IP
proxying endpoints, HTTP-based authentication via the HTTP Authorization header proxying endpoints, HTTP-based authentication via the HTTP Authorization header
<xref target="HTTP"/>, or even bearer tokens. Proxies can enforce policies for a uthenticated <xref target="RFC9110"/>, or even bearer tokens. Proxies can enforce policies fo r authenticated
users to further constrain client behavior or deal with possible abuse. For users to further constrain client behavior or deal with possible abuse. For
example, proxies can rate limit individual clients that send an excessively example, proxies can rate limit individual clients that send an excessively
large amount of traffic through the proxy. As another example, proxies can large amount of traffic through the proxy. As another example, proxies can
restrict address (prefix) assignment to clients based on certain client restrict address (prefix) assignment to clients based on certain client
attributes such as geographic location.</t> attributes, such as geographic location.</t>
<t>Address assignment can have privacy implications for endpoints. For exa mple, if <t>Address assignment can have privacy implications for endpoints. For exa mple, if
a proxy partitions its address space by the number of authenticated clients and 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 then assigns distinct address ranges to each client, target hosts could use
this information to determine when IP packets correspond to the same client. this information to determine when IP packets correspond to the same client.
Avoiding such tracking vectors may be important for certain proxy deployments. Avoiding such tracking vectors may be important for certain proxy deployments.
Proxies <bcp14>SHOULD</bcp14> avoid persistent per-client address (prefix) assig nment when Proxies <bcp14>SHOULD</bcp14> avoid persistent per-client address (prefix) assig nment when
possible.</t> possible.</t>
<t>Falsifying IP source addresses in sent traffic has been common for deni <t>Falsifying IP source addresses in sent traffic has been common for deni
al of al-of-service
service attacks. Implementations of this mechanism need to ensure that they do attacks. Implementations of this mechanism need to ensure that they do
not facilitate such attacks. In particular, there are scenarios where an not facilitate such attacks. In particular, there are scenarios where an
endpoint knows that its peer is only allowed to send IP packets from a given endpoint knows that its peer is only allowed to send IP packets from a given
prefix. For example, that can happen through out-of-band configuration prefix. For example, that can happen through out-of-band configuration
information, or when allowed prefixes are shared via ADDRESS_ASSIGN capsules. information or when allowed prefixes are shared via ADDRESS_ASSIGN capsules.
In such scenarios, endpoints <bcp14>MUST</bcp14> follow the recommendations from In such scenarios, endpoints <bcp14>MUST</bcp14> follow the recommendations from
<xref target="BCP38"/> to prevent source address spoofing.</t> <xref target="RFC2827"/> to prevent source address spoofing.</t>
<t>Limiting request scope (see <xref target="scope"/>) allows two clients to share one of the <t>Limiting request scope (see <xref target="scope"/>) allows two clients to share one of the
proxy's external IP addresses if their requests are scoped to different IP proxy's external IP addresses if their requests are scoped to different Internet
protocol numbers. If the proxy receives an ICMP packet destined for that Protocol Numbers. If the proxy receives an ICMP packet destined for that
external IP address, it has the option to forward it back to the clients. external IP address, it has the option to forward it back to the clients.
However, some of these ICMP packets carry part of the original IP packet that However, some of these ICMP packets carry part of the original IP packet that
triggered the ICMP response. Forwarding such packets can accidentally divulge triggered the ICMP response. Forwarding such packets can accidentally divulge
information about one client's traffic to another client. To avoid this, information about one client's traffic to another client. To avoid this,
proxies that forward ICMP on shared external IP addresses <bcp14>MUST</bcp14> in spect the proxies that forward ICMP on shared external IP addresses <bcp14>MUST</bcp14> in spect the
invoking packet included in the ICMP packet and only forward the ICMP packet to invoking packet included in the ICMP packet and only forward the ICMP packet to
the client whose scoping matches the invoking packet.</t> the client whose scoping matches the invoking packet.</t>
<t>Implementers will benefit from reading the guidance in <t>Implementers will benefit from reading the guidance in
<xref target="TUNNEL-SECURITY"/>. Since there are known risks with some IPv6 <xref target="RFC6169"/>. Since there are known risks with some IPv6
extension headers (e.g., <xref target="ROUTING-HDR"/>), implementers need to fol extension headers (e.g., <xref target="RFC5095"/>), implementers need to follow
low
the latest guidance regarding handling of IPv6 extension headers.</t> the latest guidance regarding handling of IPv6 extension headers.</t>
<t>Transferring DSCP markings from inner to outer packets (see <t>Transferring DSCP markings from inner to outer packets (see
<xref target="dscp-considerations"/>) exposes end-to-end flow level information to an <xref target="dscp-considerations"/>) exposes end-to-end flow level information to an
on-path observer between the IP proxying endpoints. This can potentially expose on-path observer between the IP proxying endpoints. This can potentially expose
a single end-to-end flow. Because of this, such use of DSCP in a single end-to-end flow. Because of this, such use of DSCPs in
privacy-sensitive contexts is <bcp14>NOT RECOMMENDED</bcp14>.</t> privacy-sensitive contexts is <bcp14>NOT RECOMMENDED</bcp14>.</t>
<t>Opportunistic sending of IP packets (see <xref target="link-operation"/
>) is not allowed
in HTTP/1.x because a server could reject the HTTP Upgrade and
attempt to parse the IP packets as a subsequent HTTP request,
allowing request smuggling attacks; see <xref target="I-D.schwartz-httpbis-optim
istic-upgrade"/>. In particular,
an intermediary that re-encodes a request from HTTP/2 or 3 to
HTTP/1.1 MUST NOT forward any received capsules until it has parsed a
successful IP proxying response.
</t>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<section anchor="http-upgrade-token"> <section anchor="http-upgrade-token">
<name>HTTP Upgrade Token</name> <name>HTTP Upgrade Token Registration</name>
<t>This document will request IANA to register "connect-ip" in the HTTP <t>IANA has registered "connect-ip" in the "HTTP Upgrade
Upgrade Tokens" registry maintained at
Token Registry maintained at <eref target="https://www.iana.org/assignments/http-upgrade-tokens" brackets="an
&lt;<eref target="https://www.iana.org/assignments/http-upgrade-tokens"/>&gt;.</ gle"/>.</t>
t>
<dl spacing="compact"> <dl spacing="compact" newline="false">
<dt>Value:</dt> <dt>Value:</dt>
<dd> <dd>
<t>connect-ip</t> <t>connect-ip</t>
</dd> </dd>
<dt>Description:</dt> <dt>Description:</dt>
<dd> <dd>
<t>Proxying of IP Payloads</t> <t>Proxying of IP Payloads</t>
</dd> </dd>
<dt>Expected Version Tokens:</dt> <dt>Expected Version Tokens:</dt>
<dd> <dd>
<t>None</t> <t>None</t>
</dd> </dd>
<dt>References:</dt> <dt>References:</dt>
<dd> <dd>
<t>This document</t> <t>RFC 9484</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="iana-suffix"> <section anchor="iana-suffix">
<name>Creation of the MASQUE URI Suffixes Registry</name> <name>MASQUE URI Suffixes Registry Creation</name>
<t>This document requests that IANA create a new "MASQUE URI Suffixes" r <t>IANA has created the "MASQUE URI Suffixes" registry
egistry maintained at <eref target="https://www.iana.org/assignments/masque" brackets="a
maintained at IANA_URL_TBD. This new registry governs the path segment that ngle"/>. The registration policy is Expert Review; see <xref section="4.5" secti
immediately follows "masque" in paths that start with "/.well-known/masque/", onFormat="of" target="RFC8126"/>. This new registry governs the path segment tha
see &lt;<eref target="https://www.iana.org/assignments/well-known-uris"/>&gt; fo t
r the registration immediately follows "masque" in paths that start with "/.well-known/masque/";
of "masque" in the "Well-Known URIs" registry. This new registry contains three see <eref target="https://www.iana.org/assignments/well-known-uris" brackets="an
gle"/> for the registration
of "masque" in the "Well-Known URIs" registry.</t>
<t>This new registry contains three
columns:</t> columns:</t>
<dl> <dl spacing="compact" newline="false">
<dt>Path Segment:</dt> <dt>Path Segment:</dt>
<dd> <dd>
<t>An ASCII string containing only characters allowed in tokens; see <t>An ASCII string containing only characters allowed in tokens; see
<xref section="5.6.2" sectionFormat="of" target="HTTP"/>. Entries in this regist ry <bcp14>MUST</bcp14> all have distinct <xref section="5.6.2" sectionFormat="of" target="RFC9110"/>. Entries in this reg istry <bcp14>MUST</bcp14> all have distinct
entries in this column.</t> entries in this column.</t>
</dd> </dd>
<dt>Description:</dt> <dt>Description:</dt>
<dd> <dd>
<t>A description of the entry.</t> <t>A description of the entry.</t>
</dd> </dd>
<dt>Reference:</dt> <dt>Reference:</dt>
<dd> <dd>
<t>An optional reference defining the use of the entry.</t> <t>An optional reference defining the use of the entry.</t>
</dd> </dd>
</dl> </dl>
<t>The registration policy for this registry is Expert Review; see <t>The registry's initial entries are as follows:</t>
<xref section="4.5" sectionFormat="of" target="IANA-POLICY"/>.</t>
<t>There are initially two entries in this registry:</t>
<table anchor="iana-suffixes-table"> <table anchor="iana-suffixes-table">
<name>New MASQUE URI Suffixes</name> <name>MASQUE URI Suffixes Registry</name>
<thead> <thead>
<tr> <tr>
<th align="left">Path Segment</th> <th align="left">Path Segment</th>
<th align="left">Description</th> <th align="left">Description</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">udp</td> <td align="left">udp</td>
<td align="left">UDP Proxying</td> <td align="left">UDP Proxying</td>
<td align="left">RFC 9298</td> <td align="left">RFC 9298</td>
</tr> </tr>
<tr> <tr>
<td align="left">ip</td> <td align="left">ip</td>
<td align="left">IP Proxying</td> <td align="left">IP Proxying</td>
<td align="left">This Document</td> <td align="left">RFC 9484</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>Designated experts for this registry are advised that they should app rove all <t>Designated experts for this registry are advised that they should app rove all
requests as long as the expert believes that both (1) the requested Path requests as long as the expert believes that both (1) the requested Path
Segment will not conflict with existing or expected future IETF work and (2) Segment will not conflict with existing or expected future IETF work and (2)
the use case is relevant to proxying.</t> the use case is relevant to proxying.</t>
</section> </section>
<section anchor="iana-uri"> <section anchor="iana-uri">
<name>Updates to masque Well-Known URI</name> <name>Updates to masque Well-Known URI Registration</name>
<t>This document will request IANA to update the entry for the "masque" <t>IANA has updated the entry for the "masque"
URI suffix in the "Well-Known URIs" registry maintained at URI suffix in the "Well-Known URIs" registry maintained at
&lt;<eref target="https://www.iana.org/assignments/well-known-uris"/>&gt;.</t> <eref target="https://www.iana.org/assignments/well-known-uris" brackets="angle"
<t>IANA is requested to update the "Reference" field to include this />.</t>
document in addition to previous values from that field.</t> <t>IANA has updated the "Reference" field to include this
<t>IANA is requested to replace the "Related Information" field with document and has replaced the "Related Information" field with
"For sub-suffix allocations, see registry at IANA_URL_TBD." where "For sub-suffix allocations, see the registry at <eref target="https://www.iana.
IANA_URL_TBD is the URL of the new registry described in <xref target="iana-suff org/assignments/masque" brackets="angle"/>.".</t>
ix"/>.</t>
</section> </section>
<section anchor="iana-types"> <section anchor="iana-types">
<name>Capsule Type Registrations</name> <name>HTTP Capsule Types Registrations</name>
<t>This document requests IANA to add the following values to the "HTTP <t>IANA has added the following values to the "HTTP Capsule
Capsule
Types" registry maintained at Types" registry maintained at
&lt;<eref target="https://www.iana.org/assignments/http-capsule-protocol"/>&gt;. <eref target="https://www.iana.org/assignments/masque" brackets="angle"/>.</t>
</t>
<table anchor="iana-capsules-table"> <table anchor="iana-capsules-table">
<name>New Capsules</name> <name>New Capsules</name>
<thead> <thead>
<tr> <tr>
<th align="left">Value</th> <th align="left">Value</th>
<th align="left">Capsule Type</th> <th align="left">Capsule Type</th>
<th align="left">Description</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">0x01</td> <td align="left">0x01</td>
<td align="left">ADDRESS_ASSIGN</td> <td align="left">ADDRESS_ASSIGN</td>
<td align="left">Address Assignment</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x02</td> <td align="left">0x02</td>
<td align="left">ADDRESS_REQUEST</td> <td align="left">ADDRESS_REQUEST</td>
<td align="left">Address Request</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x03</td> <td align="left">0x03</td>
<td align="left">ROUTE_ADVERTISEMENT</td> <td align="left">ROUTE_ADVERTISEMENT</td>
<td align="left">Route Advertisement</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>All of these new entries use the following values for these fields:</ t> <t>All of these new entries use the following values for these fields:</ t>
<dl> <dl spacing="compact" newline="false">
<dt>Status:</dt> <dt>Status:</dt>
<dd> <dd>
<t>provisional (permanent when this document is approved)</t> <t>permanent</t>
</dd> </dd>
<dt>Reference:</dt> <dt>Reference:</dt>
<dd> <dd>
<t>This Document</t> <t>RFC 9484</t>
</dd> </dd>
<dt>Change Controller:</dt> <dt>Change Controller:</dt>
<dd> <dd>
<t>IETF</t> <t>IETF</t>
</dd> </dd>
<dt>Contact:</dt> <dt>Contact:</dt>
<dd> <dd>
<t>masque@ietf.org</t> <t>masque@ietf.org</t>
</dd> </dd>
<dt>Notes:</dt> <dt>Notes:</dt>
<dd> <dd>
<t>Empty</t> <t>None</t>
</dd> </dd>
</dl> </dl>
<t>RFC Editor: please remove the rest of this subsection before publicat
ion.</t>
<t>Since this document has not yet been published, it might still change
before
publication as RFC. Any implementer that wishes to deploy IP proxying in
production before publication <bcp14>MUST</bcp14> use the following temporary co
depoints
instead: 0x2575D601 for ADDRESS_ASSIGN, 0x2575D602 for ADDRESS_REQUEST, and
0x2575D603 for ROUTE_ADVERTISEMENT.</t>
</section> </section>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="H1" to="HTTP/1.1"/>
<displayreference target="H2" to="HTTP/2"/> <displayreference target="RFC9112" to="HTTP/1.1"/>
<displayreference target="H3" to="HTTP/3"/> <displayreference target="RFC9113" to="HTTP/2"/>
<displayreference target="RFC9114" to="HTTP/3"/>
<displayreference target="RFC9110" to="HTTP"/>
<displayreference target="RFC9293" to="TCP"/>
<displayreference target="RFC6570" to="TEMPLATE"/>
<displayreference target="RFC9297" to="HTTP-DGRAM"/>
<displayreference target="RFC8441" to="EXT-CONNECT2"/>
<displayreference target="RFC9220" to="EXT-CONNECT3"/>
<displayreference target="RFC9000" to="QUIC"/>
<displayreference target="RFC3986" to="URI"/>
<displayreference target="RFC9209" to="PROXY-STATUS"/>
<displayreference target="RFC5234" to="ABNF"/>
<displayreference target="RFC8200" to="IPv6"/>
<displayreference target="RFC9221" to="DGRAM"/>
<displayreference target="RFC0792" to="ICMP"/>
<displayreference target="RFC4443" to="ICMPv6"/>
<displayreference target="RFC3168" to="ECN"/>
<displayreference target="RFC2474" to="DSCP"/>
<displayreference target="RFC2827" to="BCP38"/>
<displayreference target="RFC8126" to="IANA-POLICY"/>
<displayreference target="RFC9298" to="CONNECT-UDP"/>
<displayreference target="RFC4291" to="IPv6-ADDR"/>
<displayreference target="RFC4301" to="IPSEC"/>
<displayreference target="RFC8305" to="HEv2"/>
<displayreference target="RFC8085" to="UDP-USAGE"/>
<displayreference target="RFC8899" to="DPLPMTUD"/>
<displayreference target="RFC6040" to="ECN-TUNNEL"/>
<displayreference target="RFC6169" to="TUNNEL-SECURITY"/>
<displayreference target="RFC5095" to="ROUTING-HDR"/>
<displayreference target="I-D.ietf-masque-ip-proxy-reqs" to="PROXY-REQS"/>
<displayreference target="RFC6874" to="IPv6-ZONE-ID"/>
<displayreference target="I-D.schwartz-httpbis-optimistic-upgrade" to="OPTIM
ISTIC"/>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="H1">
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9112.xml"
<title>HTTP/1.1</title> />
<author fullname="R. Fielding" initials="R." role="editor" surname=" <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9113.xml"
Fielding"> />
<organization/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9114.xml"
</author> />
<author fullname="M. Nottingham" initials="M." role="editor" surname <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml"
="Nottingham"> />
<organization/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9293.xml"
</author> />
<author fullname="J. Reschke" initials="J." role="editor" surname="R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6570.xml"
eschke"> />
<organization/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9297.xml"
</author> />
<date month="June" year="2022"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8441.xml"
<abstract> />
<t>The Hypertext Transfer Protocol (HTTP) is a stateless applicati <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9220.xml"
on-level protocol for distributed, collaborative, hypertext information systems. />
This document specifies the HTTP/1.1 message syntax, message parsing, connectio <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"
n management, and related security concerns. </t> />
<t>This document obsoletes portions of RFC 7230.</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"
</abstract> />
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9000.xml"
<seriesInfo name="STD" value="99"/> />
<seriesInfo name="RFC" value="9112"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"
<seriesInfo name="DOI" value="10.17487/RFC9112"/> />
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9209.xml"
<reference anchor="H2"> />
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6874.xml"
<title>HTTP/2</title> />
<author fullname="M. Thomson" initials="M." role="editor" surname="T <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"
homson"> />
<organization/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml"
</author> />
<author fullname="C. Benfield" initials="C." role="editor" surname=" <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9221.xml"
Benfield"> />
<organization/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0792.xml"
</author> />
<date month="June" year="2022"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4443.xml"
<abstract> />
<t>This specification describes an optimized expression of the sem <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3168.xml"
antics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 />
(HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2474.xml"
latency by introducing field compression and allowing multiple concurrent excha />
nges on the same connection.</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2827.xml"
<t>This document obsoletes RFCs 7540 and 8740.</t> />
</abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"
</front> />
<seriesInfo name="RFC" value="9113"/>
<seriesInfo name="DOI" value="10.17487/RFC9113"/>
</reference>
<reference anchor="H3">
<front>
<title>HTTP/3</title>
<author fullname="M. Bishop" initials="M." role="editor" surname="Bi
shop">
<organization/>
</author>
<date month="June" year="2022"/>
<abstract>
<t>The QUIC transport protocol has several features that are desir
able in a transport for HTTP, such as stream multiplexing, per-stream flow contr
ol, and low-latency connection establishment. This document describes a mapping
of HTTP semantics over QUIC. This document also identifies HTTP/2 features tha
t are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP
/3.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9114"/>
<seriesInfo name="DOI" value="10.17487/RFC9114"/>
</reference>
<reference anchor="HTTP">
<front>
<title>HTTP Semantics</title>
<author fullname="R. Fielding" initials="R." role="editor" surname="
Fielding">
<organization/>
</author>
<author fullname="M. Nottingham" initials="M." role="editor" surname
="Nottingham">
<organization/>
</author>
<author fullname="J. Reschke" initials="J." role="editor" surname="R
eschke">
<organization/>
</author>
<date month="June" year="2022"/>
<abstract>
<t>The Hypertext Transfer Protocol (HTTP) is a stateless applicati
on-level protocol for distributed, collaborative, hypertext information systems.
This document describes the overall architecture of HTTP, establishes common te
rminology, and defines aspects of the protocol that are shared by all versions.
In this definition are core protocol elements, extensibility mechanisms, and the
"http" and "https" Uniform Resource Identifier (URI) schemes. </t>
<t>This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7
232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t>
</abstract>
</front>
<seriesInfo name="STD" value="97"/>
<seriesInfo name="RFC" value="9110"/>
<seriesInfo name="DOI" value="10.17487/RFC9110"/>
</reference>
<reference anchor="TCP">
<front>
<title>Transmission Control Protocol (TCP)</title>
<author fullname="W. Eddy" initials="W." role="editor" surname="Eddy
">
<organization/>
</author>
<date month="August" year="2022"/>
<abstract>
<t>This document specifies the Transmission Control Protocol (TCP)
. TCP is an important transport-layer protocol in the Internet protocol stack,
and it has continuously evolved over decades of use and growth of the Internet.
Over this time, a number of changes have been made to TCP as it was specified i
n RFC 793, though these have only been documented in a piecemeal fashion. This
document collects and brings those changes together with the protocol specificat
ion from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6
093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs 1011 a
nd 1122, and it should be considered as a replacement for the portions of those
documents dealing with TCP requirements. It also updates RFC 5961 by adding a s
mall clarification in reset handling while in the SYN-RECEIVED state. The TCP h
eader control bits from RFC 793 have also been updated based on RFC 3168.</t>
</abstract>
</front>
<seriesInfo name="STD" value="7"/>
<seriesInfo name="RFC" value="9293"/>
<seriesInfo name="DOI" value="10.17487/RFC9293"/>
</reference>
<reference anchor="TEMPLATE">
<front>
<title>URI Template</title>
<author fullname="J. Gregorio" initials="J." surname="Gregorio">
<organization/>
</author>
<author fullname="R. Fielding" initials="R." surname="Fielding">
<organization/>
</author>
<author fullname="M. Hadley" initials="M." surname="Hadley">
<organization/>
</author>
<author fullname="M. Nottingham" initials="M." surname="Nottingham">
<organization/>
</author>
<author fullname="D. Orchard" initials="D." surname="Orchard">
<organization/>
</author>
<date month="March" year="2012"/>
<abstract>
<t>A URI Template is a compact sequence of characters for describi
ng a range of Uniform Resource Identifiers through variable expansion. This spec
ification defines the URI Template syntax and the process for expanding a URI Te
mplate into a URI reference, along with guidelines for the use of URI Templates
on the Internet. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6570"/>
<seriesInfo name="DOI" value="10.17487/RFC6570"/>
</reference>
<reference anchor="HTTP-DGRAM">
<front>
<title>HTTP Datagrams and the Capsule Protocol</title>
<author fullname="D. Schinazi" initials="D." surname="Schinazi">
<organization/>
</author>
<author fullname="L. Pardue" initials="L." surname="Pardue">
<organization/>
</author>
<date month="August" year="2022"/>
<abstract>
<t>This document describes HTTP Datagrams, a convention for convey
ing multiplexed, potentially unreliable datagrams inside an HTTP connection.</t>
<t>In HTTP/3, HTTP Datagrams can be sent unreliably using the QUIC
DATAGRAM extension. When the QUIC DATAGRAM frame is unavailable or undesirable,
HTTP Datagrams can be sent using the Capsule Protocol, which is a more general
convention for conveying data in HTTP connections.</t>
<t>HTTP Datagrams and the Capsule Protocol are intended for use by
HTTP extensions, not applications.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9297"/>
<seriesInfo name="DOI" value="10.17487/RFC9297"/>
</reference>
<reference anchor="EXT-CONNECT2">
<front>
<title>Bootstrapping WebSockets with HTTP/2</title>
<author fullname="P. McManus" initials="P." surname="McManus">
<organization/>
</author>
<date month="September" year="2018"/>
<abstract>
<t>This document defines a mechanism for running the WebSocket Pro
tocol (RFC 6455) over a single stream of an HTTP/2 connection.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8441"/>
<seriesInfo name="DOI" value="10.17487/RFC8441"/>
</reference>
<reference anchor="EXT-CONNECT3">
<front>
<title>Bootstrapping WebSockets with HTTP/3</title>
<author fullname="R. Hamilton" initials="R." surname="Hamilton">
<organization/>
</author>
<date month="June" year="2022"/>
<abstract>
<t>The mechanism for running the WebSocket Protocol over a single
stream of an HTTP/2 connection is equally applicable to HTTP/3, but the HTTP-ver
sion-specific details need to be specified. This document describes how the mech
anism is adapted for HTTP/3.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9220"/>
<seriesInfo name="DOI" value="10.17487/RFC9220"/>
</reference>
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<author fullname="S. Bradner" initials="S." surname="Bradner">
<organization/>
</author>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized.
This document defines these words as they should be interpreted in IETF document
s. This document specifies an Internet Best Current Practices for the Internet
Community, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba">
<organization/>
</author>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying tha
t only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="QUIC">
<front>
<title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
<author fullname="J. Iyengar" initials="J." role="editor" surname="I
yengar">
<organization/>
</author>
<author fullname="M. Thomson" initials="M." role="editor" surname="T
homson">
<organization/>
</author>
<date month="May" year="2021"/>
<abstract>
<t>This document defines the core of the QUIC transport protocol.
QUIC provides applications with flow-controlled streams for structured communic
ation, low-latency connection establishment, and network path migration. QUIC in
cludes security measures that ensure confidentiality, integrity, and availabilit
y in a range of deployment circumstances. Accompanying documents describe the i
ntegration of TLS for key negotiation, loss detection, and an exemplary congesti
on control algorithm.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9000"/>
<seriesInfo name="DOI" value="10.17487/RFC9000"/>
</reference>
<reference anchor="URI">
<front>
<title>Uniform Resource Identifier (URI): Generic Syntax</title>
<author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee
">
<organization/>
</author>
<author fullname="R. Fielding" initials="R." surname="Fielding">
<organization/>
</author>
<author fullname="L. Masinter" initials="L." surname="Masinter">
<organization/>
</author>
<date month="January" year="2005"/>
<abstract>
<t>A Uniform Resource Identifier (URI) is a compact sequence of ch
aracters that identifies an abstract or physical resource. This specification d
efines the generic URI syntax and a process for resolving URI references that mi
ght be in relative form, along with guidelines and security considerations for t
he use of URIs on the Internet. The URI syntax defines a grammar that is a supe
rset of all valid URIs, allowing an implementation to parse the common component
s of a URI reference without knowing the scheme-specific requirements of every p
ossible identifier. This specification does not define a generative grammar for
URIs; that task is performed by the individual specifications of each URI schem
e. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="66"/>
<seriesInfo name="RFC" value="3986"/>
<seriesInfo name="DOI" value="10.17487/RFC3986"/>
</reference>
<reference anchor="PROXY-STATUS">
<front>
<title>The Proxy-Status HTTP Response Header Field</title>
<author fullname="M. Nottingham" initials="M." surname="Nottingham">
<organization/>
</author>
<author fullname="P. Sikora" initials="P." surname="Sikora">
<organization/>
</author>
<date month="June" year="2022"/>
<abstract>
<t>This document defines the Proxy-Status HTTP response field to c
onvey the details of an intermediary's response handling, including generated er
rors.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9209"/>
<seriesInfo name="DOI" value="10.17487/RFC9209"/>
</reference>
<reference anchor="RFC6874">
<front>
<title>Representing IPv6 Zone Identifiers in Address Literals and Un
iform Resource Identifiers</title>
<author fullname="B. Carpenter" initials="B." surname="Carpenter">
<organization/>
</author>
<author fullname="S. Cheshire" initials="S." surname="Cheshire">
<organization/>
</author>
<author fullname="R. Hinden" initials="R." surname="Hinden">
<organization/>
</author>
<date month="February" year="2013"/>
<abstract>
<t>This document describes how the zone identifier of an IPv6 scop
ed address, defined as &lt;zone_id&gt; in the IPv6 Scoped Address Architecture (
RFC 4007), can be represented in a literal IPv6 address and in a Uniform Resourc
e Identifier that includes such a literal address. It updates the URI Generic S
yntax specification (RFC 3986) accordingly.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6874"/>
<seriesInfo name="DOI" value="10.17487/RFC6874"/>
</reference>
<reference anchor="ABNF">
<front>
<title>Augmented BNF for Syntax Specifications: ABNF</title>
<author fullname="D. Crocker" initials="D." role="editor" surname="C
rocker">
<organization/>
</author>
<author fullname="P. Overell" initials="P." surname="Overell">
<organization/>
</author>
<date month="January" year="2008"/>
<abstract>
<t>Internet technical specifications often need to define a formal
syntax. Over the years, a modified version of Backus-Naur Form (BNF), called A
ugmented BNF (ABNF), has been popular among many Internet specifications. The c
urrent specification documents ABNF. It balances compactness and simplicity with
reasonable representational power. The differences between standard BNF and AB
NF involve naming rules, repetition, alternatives, order-independence, and value
ranges. This specification also supplies additional rule definitions and encod
ing for a core lexical analyzer of the type common to several Internet specifica
tions. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="68"/>
<seriesInfo name="RFC" value="5234"/>
<seriesInfo name="DOI" value="10.17487/RFC5234"/>
</reference>
<reference anchor="IPv6">
<front>
<title>Internet Protocol, Version 6 (IPv6) Specification</title>
<author fullname="S. Deering" initials="S." surname="Deering">
<organization/>
</author>
<author fullname="R. Hinden" initials="R." surname="Hinden">
<organization/>
</author>
<date month="July" year="2017"/>
<abstract>
<t>This document specifies version 6 of the Internet Protocol (IPv
6). It obsoletes RFC 2460.</t>
</abstract>
</front>
<seriesInfo name="STD" value="86"/>
<seriesInfo name="RFC" value="8200"/>
<seriesInfo name="DOI" value="10.17487/RFC8200"/>
</reference>
<reference anchor="DGRAM">
<front>
<title>An Unreliable Datagram Extension to QUIC</title>
<author fullname="T. Pauly" initials="T." surname="Pauly">
<organization/>
</author>
<author fullname="E. Kinnear" initials="E." surname="Kinnear">
<organization/>
</author>
<author fullname="D. Schinazi" initials="D." surname="Schinazi">
<organization/>
</author>
<date month="March" year="2022"/>
<abstract>
<t>This document defines an extension to the QUIC transport protoc
ol to add support for sending and receiving unreliable datagrams over a QUIC con
nection.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9221"/>
<seriesInfo name="DOI" value="10.17487/RFC9221"/>
</reference>
<reference anchor="ICMP">
<front>
<title>Internet Control Message Protocol</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization/>
</author>
<date month="September" year="1981"/>
</front>
<seriesInfo name="STD" value="5"/>
<seriesInfo name="RFC" value="792"/>
<seriesInfo name="DOI" value="10.17487/RFC0792"/>
</reference>
<reference anchor="ICMPv6">
<front>
<title>Internet Control Message Protocol (ICMPv6) for the Internet P
rotocol Version 6 (IPv6) Specification</title>
<author fullname="A. Conta" initials="A." surname="Conta">
<organization/>
</author>
<author fullname="S. Deering" initials="S." surname="Deering">
<organization/>
</author>
<author fullname="M. Gupta" initials="M." role="editor" surname="Gup
ta">
<organization/>
</author>
<date month="March" year="2006"/>
<abstract>
<t>This document describes the format of a set of control messages
used in ICMPv6 (Internet Control Message Protocol). ICMPv6 is the Internet Con
trol Message Protocol for Internet Protocol version 6 (IPv6). [STANDARDS-TRACK]
</t>
</abstract>
</front>
<seriesInfo name="STD" value="89"/>
<seriesInfo name="RFC" value="4443"/>
<seriesInfo name="DOI" value="10.17487/RFC4443"/>
</reference>
<reference anchor="ECN">
<front>
<title>The Addition of Explicit Congestion Notification (ECN) to IP<
/title>
<author fullname="K. Ramakrishnan" initials="K." surname="Ramakrishn
an">
<organization/>
</author>
<author fullname="S. Floyd" initials="S." surname="Floyd">
<organization/>
</author>
<author fullname="D. Black" initials="D." surname="Black">
<organization/>
</author>
<date month="September" year="2001"/>
<abstract>
<t>This memo specifies the incorporation of ECN (Explicit Congesti
on Notification) to TCP and IP, including ECN's use of two bits in the IP header
. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3168"/>
<seriesInfo name="DOI" value="10.17487/RFC3168"/>
</reference>
<reference anchor="DSCP">
<front>
<title>Definition of the Differentiated Services Field (DS Field) in
the IPv4 and IPv6 Headers</title>
<author fullname="K. Nichols" initials="K." surname="Nichols">
<organization/>
</author>
<author fullname="S. Blake" initials="S." surname="Blake">
<organization/>
</author>
<author fullname="F. Baker" initials="F." surname="Baker">
<organization/>
</author>
<author fullname="D. Black" initials="D." surname="Black">
<organization/>
</author>
<date month="December" year="1998"/>
<abstract>
<t>This document defines the IP header field, called the DS (for d
ifferentiated services) field. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2474"/>
<seriesInfo name="DOI" value="10.17487/RFC2474"/>
</reference>
<reference anchor="BCP38">
<front>
<title>Network Ingress Filtering: Defeating Denial of Service Attack
s which employ IP Source Address Spoofing</title>
<author fullname="P. Ferguson" initials="P." surname="Ferguson">
<organization/>
</author>
<author fullname="D. Senie" initials="D." surname="Senie">
<organization/>
</author>
<date month="May" year="2000"/>
<abstract>
<t>This paper discusses a simple, effective, and straightforward m
ethod for using ingress traffic filtering to prohibit DoS (Denial of Service) at
tacks which use forged IP addresses to be propagated from 'behind' an Internet S
ervice Provider's (ISP) aggregation point. This document specifies an Internet
Best Current Practices for the Internet Community, and requests discussion and s
uggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="38"/>
<seriesInfo name="RFC" value="2827"/>
<seriesInfo name="DOI" value="10.17487/RFC2827"/>
</reference>
<reference anchor="IANA-POLICY">
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs
</title>
<author fullname="M. Cotton" initials="M." surname="Cotton">
<organization/>
</author>
<author fullname="B. Leiba" initials="B." surname="Leiba">
<organization/>
</author>
<author fullname="T. Narten" initials="T." surname="Narten">
<organization/>
</author>
<date month="June" year="2017"/>
<abstract>
<t>Many protocols make use of points of extensibility that use con
stants to identify various protocol parameters. To ensure that the values in th
ese fields do not have conflicting uses and to promote interoperability, their a
llocations are often coordinated by a central record keeper. For IETF protocols
, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
<t>To make assignments in a given registry prudently, guidance des
cribing the conditions under which new values should be assigned, as well as whe
n and how modifications to existing values can be made, is needed. This documen
t defines a framework for the documentation of these guidelines by specification
authors, in order to assure that the provided guidance for the IANA Considerati
ons is clear and addresses the various issues that are likely in the operation o
f a registry.</t>
<t>This is the third edition of this document; it obsoletes RFC 52
26.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="26"/>
<seriesInfo name="RFC" value="8126"/>
<seriesInfo name="DOI" value="10.17487/RFC8126"/>
</reference>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="IANA-PN" target="https://www.iana.org/assignments/pro tocol-numbers"> <reference anchor="IANA-PN" target="https://www.iana.org/assignments/pro tocol-numbers">
<front> <front>
<title>Protocol Numbers</title> <title>Protocol Numbers</title>
<author> <author>
<organization>IANA</organization> <organization>IANA</organization>
</author> </author>
<date/>
</front>
</reference>
<reference anchor="CONNECT-UDP">
<front>
<title>Proxying UDP in HTTP</title>
<author fullname="D. Schinazi" initials="D." surname="Schinazi">
<organization/>
</author>
<date month="August" year="2022"/>
<abstract>
<t>This document describes how to proxy UDP in HTTP, similar to ho
w the HTTP CONNECT method allows proxying TCP in HTTP. More specifically, this d
ocument defines a protocol that allows an HTTP client to create a tunnel for UDP
communications through an HTTP server that acts as a proxy.</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="9298"/>
<seriesInfo name="DOI" value="10.17487/RFC9298"/>
</reference> </reference>
<reference anchor="IPv6-ADDR">
<front>
<title>IP Version 6 Addressing Architecture</title>
<author fullname="R. Hinden" initials="R." surname="Hinden">
<organization/>
</author>
<author fullname="S. Deering" initials="S." surname="Deering">
<organization/>
</author>
<date month="February" year="2006"/>
<abstract>
<t>This specification defines the addressing architecture of the I
P Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, t
ext representations of IPv6 addresses, definition of IPv6 unicast addresses, any
cast addresses, and multicast addresses, and an IPv6 node's required addresses.<
/t>
<t>This document obsoletes RFC 3513, "IP Version 6 Addressing Arch
itecture". [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4291"/>
<seriesInfo name="DOI" value="10.17487/RFC4291"/>
</reference>
<reference anchor="IPSEC">
<front>
<title>Security Architecture for the Internet Protocol</title>
<author fullname="S. Kent" initials="S." surname="Kent">
<organization/>
</author>
<author fullname="K. Seo" initials="K." surname="Seo">
<organization/>
</author>
<date month="December" year="2005"/>
<abstract>
<t>This document describes an updated version of the "Security Arc
hitecture for IP", which is designed to provide security services for traffic at
the IP layer. This document obsoletes RFC 2401 (November 1998). [STANDARDS-TR
ACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4301"/>
<seriesInfo name="DOI" value="10.17487/RFC4301"/>
</reference>
<reference anchor="HEv2">
<front>
<title>Happy Eyeballs Version 2: Better Connectivity Using Concurren
cy</title>
<author fullname="D. Schinazi" initials="D." surname="Schinazi">
<organization/>
</author>
<author fullname="T. Pauly" initials="T." surname="Pauly">
<organization/>
</author>
<date month="December" year="2017"/>
<abstract>
<t>Many communication protocols operating over the modern Internet
use hostnames. These often resolve to multiple IP addresses, each of which may
have different performance and connectivity characteristics. Since specific ad
dresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optima
l on a network, clients that attempt multiple connections in parallel have a cha
nce of establishing a connection more quickly. This document specifies requirem
ents for algorithms that reduce this user-visible delay and provides an example
algorithm, referred to as "Happy Eyeballs". This document obsoletes the origina
l algorithm description in RFC 6555.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8305"/>
<seriesInfo name="DOI" value="10.17487/RFC8305"/>
</reference>
<reference anchor="UDP-USAGE">
<front>
<title>UDP Usage Guidelines</title>
<author fullname="L. Eggert" initials="L." surname="Eggert">
<organization/>
</author>
<author fullname="G. Fairhurst" initials="G." surname="Fairhurst">
<organization/>
</author>
<author fullname="G. Shepherd" initials="G." surname="Shepherd">
<organization/>
</author>
<date month="March" year="2017"/>
<abstract>
<t>The User Datagram Protocol (UDP) provides a minimal message-pas
sing transport that has no inherent congestion control mechanisms. This documen
t provides guidelines on the use of UDP for the designers of applications, tunne
ls, and other protocols that use UDP. Congestion control guidelines are a prima
ry focus, but the document also provides guidance on other topics, including mes
sage sizes, reliability, checksums, middlebox traversal, the use of Explicit Con
gestion Notification (ECN), Differentiated Services Code Points (DSCPs), and por
ts.</t>
<t>Because congestion control is critical to the stable operation
of the Internet, applications and other protocols that choose to use UDP as an I
nternet transport must employ mechanisms to prevent congestion collapse and to e
stablish some degree of fairness with concurrent traffic. They may also need to
implement additional mechanisms, depending on how they use UDP.</t>
<t>Some guidance is also applicable to the design of other protoco
ls (e.g., protocols layered directly on IP or via IP-based tunnels), especially
when these protocols do not themselves provide congestion control.</t>
<t>This document obsoletes RFC 5405 and adds guidelines for multic
ast UDP usage.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="145"/>
<seriesInfo name="RFC" value="8085"/>
<seriesInfo name="DOI" value="10.17487/RFC8085"/>
</reference>
<reference anchor="DPLPMTUD">
<front>
<title>Packetization Layer Path MTU Discovery for Datagram Transport
s</title>
<author fullname="G. Fairhurst" initials="G." surname="Fairhurst">
<organization/>
</author>
<author fullname="T. Jones" initials="T." surname="Jones">
<organization/>
</author>
<author fullname="M. Tüxen" initials="M." surname="Tüxen">
<organization/>
</author>
<author fullname="I. Rüngeler" initials="I." surname="Rüngeler">
<organization/>
</author>
<author fullname="T. Völker" initials="T." surname="Völker">
<organization/>
</author>
<date month="September" year="2020"/>
<abstract>
<t>This document specifies Datagram Packetization Layer Path MTU D
iscovery (DPLPMTUD). This is a robust method for Path MTU Discovery (PMTUD) for
datagram Packetization Layers (PLs). It allows a PL, or a datagram application t
hat uses a PL, to discover whether a network path can support the current size o
f datagram. This can be used to detect and reduce the message size when a sende
r encounters a packet black hole. It can also probe a network path to discover w
hether the maximum packet size can be increased. This provides functionality fo
r datagram transports that is equivalent to the PLPMTUD specification for TCP, s
pecified in RFC 4821, which it updates. It also updates the UDP Usage Guidelines
to refer to this method for use with UDP datagrams and updates SCTP.</t>
<t>The document provides implementation notes for incorporating Da
tagram PMTUD into IETF datagram transports or applications that use datagram tra
nsports.</t>
<t>This specification updates RFC 4960, RFC 4821, RFC 6951, RFC 80
85, and RFC 8261.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8899"/>
<seriesInfo name="DOI" value="10.17487/RFC8899"/>
</reference>
<reference anchor="ECN-TUNNEL">
<front>
<title>Tunnelling of Explicit Congestion Notification</title>
<author fullname="B. Briscoe" initials="B." surname="Briscoe">
<organization/>
</author>
<date month="November" year="2010"/>
<abstract>
<t>This document redefines how the explicit congestion notificatio
n (ECN) field of the IP header should be constructed on entry to and exit from a
ny IP-in-IP tunnel. On encapsulation, it updates RFC 3168 to bring all IP-in-IP
tunnels (v4 or v6) into line with RFC 4301 IPsec ECN processing. On decapsulat
ion, it updates both RFC 3168 and RFC 4301 to add new behaviours for previously
unused combinations of inner and outer headers. The new rules ensure the ECN fi
eld is correctly propagated across a tunnel whether it is used to signal one or
two severity levels of congestion; whereas before, only one severity level was s
upported. Tunnel endpoints can be updated in any order without affecting pre-ex
isting uses of the ECN field, thus ensuring backward compatibility. Nonetheless
, operators wanting to support two severity levels (e.g., for pre-congestion not
ification -- PCN) can require compliance with this new specification. A thoroug
h analysis of the reasoning for these changes and the implications is included.
In the unlikely event that the new rules do not meet a specific need, RFC 4774
gives guidance on designing alternate ECN semantics, and this document extends t
hat to include tunnelling issues. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6040"/>
<seriesInfo name="DOI" value="10.17487/RFC6040"/>
</reference>
<reference anchor="TUNNEL-SECURITY">
<front>
<title>Security Concerns with IP Tunneling</title>
<author fullname="S. Krishnan" initials="S." surname="Krishnan">
<organization/>
</author>
<author fullname="D. Thaler" initials="D." surname="Thaler">
<organization/>
</author>
<author fullname="J. Hoagland" initials="J." surname="Hoagland">
<organization/>
</author>
<date month="April" year="2011"/>
<abstract>
<t>A number of security concerns with IP tunnels are documented in
this memo. The intended audience of this document includes network administrat
ors and future protocol developers. The primary intent of this document is to r
aise the awareness level regarding the security issues with IP tunnels as deploy
ed and propose strategies for the mitigation of those issues. [STANDARDS-TRACK]<
/t>
</abstract>
</front>
<seriesInfo name="RFC" value="6169"/>
<seriesInfo name="DOI" value="10.17487/RFC6169"/>
</reference>
<reference anchor="ROUTING-HDR">
<front>
<title>Deprecation of Type 0 Routing Headers in IPv6</title>
<author fullname="J. Abley" initials="J." surname="Abley">
<organization/>
</author>
<author fullname="P. Savola" initials="P." surname="Savola">
<organization/>
</author>
<author fullname="G. Neville-Neil" initials="G." surname="Neville-Ne
il">
<organization/>
</author>
<date month="December" year="2007"/>
<abstract>
<t>The functionality provided by IPv6's Type 0 Routing Header can
be exploited in order to achieve traffic amplification over a remote path for th
e purposes of generating denial-of-service traffic. This document updates the I
Pv6 specification to deprecate the use of IPv6 Type 0 Routing Headers, in light
of this security concern. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5095"/>
<seriesInfo name="DOI" value="10.17487/RFC5095"/>
</reference>
<reference anchor="PROXY-REQS">
<front>
<title>Requirements for a MASQUE Protocol to Proxy IP Traffic</title
>
<author fullname="Alex Chernyakhovsky" initials="A." surname="Cherny
akhovsky">
<organization>Google LLC</organization>
</author>
<author fullname="Dallas McCall" initials="D." surname="McCall">
<organization>Google LLC</organization>
</author>
<author fullname="David Schinazi" initials="D." surname="Schinazi">
<organization>Google LLC</organization>
</author>
<date day="27" month="August" year="2021"/>
<abstract>
<t> There is interest among MASQUE working group participants in
designing a protocol that can proxy IP traffic over HTTP. This
document describes the set of requirements for such a protocol.
Discussion of this work is encouraged to happen on the MASQUE IETF <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9298.xml"
mailing list masque@ietf.org or on the GitHub repository which />
contains the draft: https://github.com/ietf-wg-masque/draft-ietf- <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4291.xml"
masque-ip-proxy-reqs. />
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4301.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8305.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8085.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8899.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6040.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6169.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5095.xml"
/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-ma
sque-ip-proxy-reqs.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.schwart
z-httpbis-optimistic-upgrade.xml"/>
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-masque-ip-proxy-re
qs-03"/>
</reference>
</references> </references>
</references> </references>
<section numbered="false" anchor="acknowledgments"> <section numbered="false" anchor="acknowledgments">
<name>Acknowledgments</name> <name>Acknowledgments</name>
<t>The design of this method was inspired by discussions in the MASQUE wor <t>The design of this method was inspired by discussions in the MASQUE Wor
king king
group around <xref target="PROXY-REQS"/>. The authors would Group around <xref target="I-D.ietf-masque-ip-proxy-reqs"/>. The authors would
like to thank participants in those discussions for their feedback. like to thank participants in those discussions for their feedback.
Additionally, <contact fullname="Mike Bishop"/>, <contact fullname="Lucas Pardue "/>, and <contact fullname="Alejandro Sedeño"/> Additionally, <contact fullname="Mike Bishop"/>, <contact fullname="Lucas Pardue "/>, and <contact fullname="Alejandro Sedeño"/>
provided valuable feedback on the document.</t> provided valuable feedback on the document.</t>
<t>Most of the text on client configuration is based on the corresponding text in <t>Most of the text on client configuration is based on the corresponding text in
<xref target="CONNECT-UDP"/>.</t> <xref target="RFC9298"/>.</t>
</section> </section>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA+196Xrb2JXg//sUiGq6IyUktdplq+I4tCRX6WsviiUnnS+d
rxokryS0QYABQMmKynmWeYV5hZkXm7PeBQAluao6nU6Xs0gigbuce+7Zl+Fw
aJqsye1+snZSlR9vsuIiOT5JsiL55uzsZM3MymmRzuHrWZWeN8PMNufDeVr/
eWmH07Io7BQ+Wwy3d83VfrJr6uVkntV1VhbNzQJeOj46e2mmaWMvyupmP6mb
mUkrm+4nZ1Va1Iuyasz1xX7yenz62/dHpljOJ7baNzN4Yd/A8LUt6mW9nzTV
0prlAj+Hv57uPH1irmyxhIeS5KIqlwtYPY+xBp/w1Gu/L6sPuJuv8QH8fJ5m
OXzOq/8N7mRUVhf4TVpNL+Gby6ZZ1Pubm/ggfpRd2ZE+tokfbE6q8rq2mzzE
Jr56kTWXywm8TJC5vhDgbN4FLnwvx700waTx+yMed5SVd45055ejy2aer5kP
9ua6rGYIq2Hy52U2pV9wWvoFgJpeVOmc/vjdyRv6uUBUoN+aJQyX1+5lxIzl
bIE/GE3ciM2yAjyqkzTPk+bSJtfpTTIrrwv6khfnZh4WFyZdNpdlRcuC/yUw
Fpzt2Sg5SZf5DX3CiHdWzuc3wadVidhqZ1lTVvQBnE5aZH9JG0C7/WS8WOQ2
OS6mI/rS8qk3C3z/Nyl+OZqW83jWw1FyCsddpH/JgokP06tsFn8BU+0nX5fl
BUzx6tUBfVY3lbVwktuPt7aS8XxxCSdnU/gQ1lx9ACjQU9OsgQvwulwWTQpQ
+11mr3k39oKWfTDmx8oZzPx0b2tvV/6GF/DqvC+yxsJqGsSbpDyHmWyVTdNw
k7Na1kpY+5sL/LS72fEoObi0VXGTfrgsr+oPIazHuf3Y920M4hYAZPZ0yu/9
5oK+7k78epT8y9Je5vY6K2bBpK+z6j/S9lfxjEew1boui3C+Ob42+uBe+42V
h3pn/j3cNlvly3jm9KJY1u3vHjA1vTe6du/FcxdlNYe3r4g+fbO9T68+20/e
vTx4ur29Q3/OsnqRp3CwSGY3t0fb+OhO69Hdnkfx9W92Ww/u9Ty4a7LiPFzJ
8fjNeHjyhl/1t8/hNX5PfwcMoSmnZZ68IcJcr/EsSJ2T8zSvLT+dVhc2pGTX
19ejLC1SJpvADS6KuS2aenMh4w0LHc8Mh8MkncAVSqeNMWeXWQ00Y7rE55OZ
radVNgF0vyyvk6ZkqoRkZ5FOP9imVi41SuhFHT7JalNnc6Th+Nb7wxN+E5mB
vDFIJssGKRWQc+AuwIvmWdPgA2k1yeCDKpxnZF6XcJ3rhZ1m53Dn8vxmACQu
Xut5ViDx86toLlM3RcrTJtM8g6cNrGoKbLCx+AXMw0QW3gBWdXHpnq5tdWUr
GWgK+01reYH2w9s2bg3CIBEliEeODMN3ns1muTXmC6CKTVXOllPEbGNoDhgJ
qBy8hST74O2bN0cHZ8ncAnLMkvXa2uT29tTSC8nT0e7oMZKen+Gbzxjztj59
2kgAzQxtiCCYnB2cwGs/gx/00M7T3U+f3B5LeADmg0fpgsGGZvCJntfcTi/h
8tVzA2PS0d3ePpdlDeFPGfDJp0+j5Jvy2gJ88Chsbf2rdTJNi6JsdMoSvq8M
Q42OpoZB5TLAwuC2ApktruxNcp7ZfEbUFaEBbwAhn9lqtBozg/PGBfOMuQhR
/edp4CgJTnKYQ8Urwe8SzzxAa9hMMrHJsgbyj3NcpVVWAtWCD0C0qmER9XJ6
icNVdl4iTk2ntq6Rlw8Aro0dNuUQf8ondroEZF6UWdHgN/QLCFvz+bIA3MYz
GQA9SC5sYas0Hy6W1aIE8PJdCHYIUDkObla5gMcR/eQo85vO5Vt1lANzDSdk
JzcEdoZC1tQ2P4ernAB2Fg3AB7Z/DawVgQYUo8yXsKP3717BYhe4aLyVKDMi
e8XJcCi4yOcA2J/XIcYB+6NbWMsWYRhGIBgMoco4/P7dsTmz8wXKaYTMR69P
Xo3PjnDVjx99CWg/QJArJsyQstze8v1GGew8uwAcFcRxOFIvFyj0spBkP2Y1
YQIcOIrMhHiEKAAJXgf9dSgSWm1gHfjJ8PDrd+PXAr8v8Sr8/tIWwSubO7CW
b3YAuctKmAF+sIuLzhrEnJpv/9HHxhYzWL3e/O6Wfnb0r2dD+XoH53yyt7cN
I8O9NfG3u7yina2+FW2PPuIStoMl8O7eL2BvM8BaoGRERGVepTpfjp4oXDxA
OzTv9jbALKQ2QGGBGlzQ2arMv5ZcA+oOPxQgleIBDwwTOGRWw2WV0fhfJAdI
DIqGTgSp0yEuK6O/cXqbgESdoEhdg9bx/vRsbcA/kzdv6fd3R799f/zu6BB/
P/1m/OqV+8XIE6ffvH3/6tD/5t88ePv69dGbQ34ZPk2ijwxoOX+Ab3BVa29P
zo7fvhm/WkN4xdwIdCyEAFANuNu2WlQWZUeCcHC2Lw5O/u//3t7DM4aD29ne
fgqA4z+ebH+5B3/AtSx4trKA+8x/AkBvDAjSFsg1jIKYPE0XWQMCAV2J+hLB
ixcaoPmLPyJk/rSf/GoyXWzv/Vo+wA1HHyrMog8JZt1POi8zEHs+6pnGQTP6
vAXpeL3jP0R/K9yDD4ESto5gAKiGSM5kyFbzZE2J5RoeTWXPLUkn+H2b2ZvK
gm5cAH7JAyGdrSxgct0gc9CRmeqsIbEkLkH4wMMaVKHtV/Q3P4a8DuStJcoT
K8c+Jg4IWISYROMQIs1B6wLuA/dtnQhFz3XdHX3pr+sGoGBzbW0Rzo+EI5wY
MQoZDE5FYKlgTBQT4HrFs3YxnaBgYvjiRoCoEV+DV2hIguQEBIHWQiIIdIkL
EikcPCvKvLwA+aAq53hDAFcPiNhtbSmxwxsXvmxUIvTy4M3C1nR9GHJEURKW
0GUq+ArkFpaLZC6Bq9ke7SJccWackRbqBFJ6wQ2BAkI6ye0wt8UFbBmBeAGo
ZQvQLgE6Jh4aFFcS6tqb+t2KYa7SHJAENoprNYXl0wJaQ+N79AOoZfPlPGFh
H6eY3CCpLiyKJyBhA7zflMR9U7wvl9ajrbJEsjYAbsxKfBFEOmGgyXyZNxno
8h/xtFEDR/a4roKQ6lQbSLxuGAVgdUQU1/jpHqpZWSCUNUkGsA6DLABOVewp
KDgIcwDWvqwY5rApFSZuv4iZvzH6Tcqj0GsMLNxSJDupyJdcZSkLH4kKH6ZX
+ODrHz6XAJ1KRP5JmuvSoQHov2uso63R3VvLFoSTa18lzP7qKchuOqQKU1lz
o3KwGyjBw+arZMk8B6IZ7oiOjnFaBS9dVF2y+mLRKFJFw5GaBjLeUAQ8hkSF
0gGKTCUojvgUzGY/TvMliAj4DeNIfQP7/AgHcvQxhZksA5k5z8SCyrVvzF//
+lejKqnlx0gjHXkhQA152WLzlkH0afNWwPNp073N1CEYY39vb2/Xv/y8eaav
/3P2zA3w4Pdvn/Pbg86bYgwMl/8ckKd6NikntMHb/eQLQKyhAnxoFSCkxD9b
i1BEobX2iQWZ8xLVU6X8gO1zRtjFgqX3poVjANVf9CAeMnS4/2mSgz6WJ7v+
+OE4YQLSoO54MQskeqSHLHLQt1nBR1+UxRBeA6Ssp5ewzIFREwYiKj6+SIFG
gRoDjBM34WaMP1ec7q6jhjNoRMNI6jytL5O1zTUaZowWTX3Y3wZdPr4jeEmT
wabh0KqbYDXBtCtAEV5evEDhBY7ub+LuL0Np/AeTuFdJ1fUvKiP3A8Da/Pt+
Arw9AuoZghbeyRylV4GNaDyegdegUDfNQJwANZmI2tq//YLEm6yYIVtCA9F1
ls+maTXDqQtQNz0x5uHbVGg1puASdKNI1hEnxqcHx8cJaq7AelDkR0MS8nvF
IFgBya76Ir8QPCgAr0hZ2Pq4sz3c+vjlEUOjzq5ssl4ok4KxQMmdIpFXXoqk
imw8dsYbUaa6M9rGQwfiDRtBur379MljkIju2R8C8Z0lWXAG13WRFsQG19d+
uSYadlkBV3tZpRckZSTRQ19ED71KgRQG3xNuH5bNMDmBQ8g+DpITRNdT2x2K
Hj3FSzDUZ9FMgs8PT5ubnGzb6RzUiqr1FgxzaudwHDmcDr878qxQxHI4+Wwm
ineL9EyAF36FBj827UzlRbwfCJvUtO0SERwzJG84ErNnYj15Ov1QM6tXgcnI
AsgaAFckVZFwBjtiwRhNboVjgd010pVBiQSAYEBfj5n2IJQz6XAr+x8wMpo1
nCwQ2L8mKNOg0CESOIGyXIK8A5IsoVnT1gUAquOaDyo0sgyA5c5DWd9PVZP5
SN5HIR6uZs63g1CYpHLkLqQ9q8AS2GRATGepmf9EQcyTAloJCmAmz+ZZIzPi
uaUNEk/agJimQtkHdMd0koG8gStig4GIyCnIeKZxEL2+zEC6y7zekdb7xhmd
/9fJu7f/+odvv3l7erYvv5+8fXf2cG6/JlaoJBiJNhuMxor1ZSTOeaDgGTrT
oRHdBlU5JAnAGIFu6sZhD4u8vJmHl6I8R5UQr34GxDFtGGXzksV7k9HIN4kK
3KQaidHNA18vDMmqZ5E10gmZwPtLPnEY7KJsMifLpmoyFURxr6wydyPKrgWO
TRZil2LSacoPtmCxEsCAErvYRdmn6PTjg3QB31rj/A0tw/PuaEd1SjZ9oWZJ
W47tY0rLWaeKzUmL9CYv09mQv2NLEgIxw+237PBpXZdT/Hjm5AFYea6KOukP
A080srqGO2tSVZ+TlhUyAlAMG2PITuZved2nj0fUhE0gcO64k1hTsI4SA34g
KUPN1XrBBLGUJROAJs7lxmd4d62XL25AI6mapVXEDjRX+UQOL7n78Ex0eIO+
XapKCRShqm6I+s5RUbyg69agtm9O1bY8QGxHWnK+zFuDoemkJj80KB+rhjRu
SNOviKlwJzdsxl+dvTpFOQZVZVR3q5uFs5enBfsZkFMAe8Gj8k84K8BA/Fjo
c2EqQsoP6VsDVrEr+hU1NRRw8VumAHilv8C9UpxG8g08gVfbmPewYdj31GZX
ZLsu+qALonvyiyRTdjbNFoK7PaqpbCVRBxHSsaxhdgFSE3suDDlXnXnmBo3W
gJLXIOop4ut9QMIfDsmmrlHyJhCsmHq1rEzz1NO7yrLQZaOhlSrKzLBMHEuN
+GpFULs6sXWkY9k5CaENW1lwQJDT2XhGUyEsUd9EWRi3G07pRD8epcaN60SE
+6SAoqAHAKddX2e1SAQe8DEwI5+e5/EkX08vS5RzmtJQuACJESsNd2/9fHBi
9iM5Vnn9qtk7ZYD2FikUXiFwcEECAyNdknvJmQ7RFaVPyNw4GrvL6gGQCTyp
WvSIttDM+h28A3Nl9aWtI/Lrr2SmyoeTF4FDOzsCzzFbpRy5vZi5tU1XiiOu
4Ewfx4JHTC8GEYB5DUj1YxktRQTNkQyr8O+p3pPRNisA5IXBlfnv9uA7Zmi7
SGTbKlpgHwEUPnxzSsEKfUtSJgDPoMkYFWhCQkDhcuJUyWlZiT2Z2e/VHq5n
kzj81eMknc3gaySYaHsay3dmDP/oxKtZjWbc85LMs4uc8C00XIdGY1tVJdyI
cjpdVslsWTElyGqUhpBa9+0iQGkHWYCXSEXIGpGXpVnunHMFuh9A9qmIdRM5
HGJgzLIWDGRHLipfJLsNT8/GZ+9P2T219RTP+yVsX0wlAxStEMwBCCvbLCty
//CWBoEUjHdSJZd/nxX1t/TEv/M6zBH+kZzdLGzLggsaocgx4ZrEpWWTPDu3
TTa3gfM5pKYsmGRo1mEatYICGJZOWmSE4DwHhGDdOSeWKQdPwK5KtL0EsRqm
LQOtXBOI5XlMk3kJuFi4XKhgsTBMtxnNHErPkgZdSBgixiYPHm+2tBwkANid
lTMSVQp0mV8RX5wsG0M3lfY0zcu6d3I2SZZkHS5RVQrlBZUR2l4MOSn0Jv4K
n9l2V5f+3IHrumHUtCFKYoTPSCU9WZu1pEoYKWOli6+QCeJZSDitR8mYzNWy
vFJoHXq8e9cfr8WEcMClnMOlQdLUXC7rrkbqlE53gwFMoLVfOKG3O2Pr/uJV
oAs6ZSGwZr8NYpHxdIU03BmwyAb4EqOa82zJgtZB+JQh0EZC2KsqLF53FOV4
3ORh47olYmhKYZvrsvqA0Q7yKz3NMQwgU6m7IHknwLv9AkCy/Umk88iLve28
2P1yFjN2x3KchdWEzIfsqOQj4UAblulB2lz7+uiMbY7hWfLXagr12ghqnhHB
aykeqJoa5vGO+cdaqjMl3D3hgfOBxPMRopAZL1kTPz5KFd5ixmpjsHUSONPa
DjMK7s1QMUZGCpc98vk/Ju6JoW7sSLxviYWLI1i5wEALQ0zvPz1atPM2oWiM
DJaRqiY1tqkyoRLA1hz/Vy1XxTuAMDujvIjg5hCuRyzZhbQQEzEB41MWs7e1
lay/SGeKnBtoqUZWh9IPbCTkZCrfO8U0FO7ZVBTqi2s/yD3CAtc1C3BAzZDY
y6Xo4RI4eVFKsCDqS84vGpiLSGidlst8ZoisRDco0GT++te/chixanNwbZKH
b+YX8B8fd4nXaD8J3jIe3fcVrYz83E88GhlRfYeq+u4nz7cjrwyseHi5ra4Y
8b50yA16Y2IqJOQdyRByIZYQJEDA0/x+njC58WKa49z3kCGxazi0Skoxiuug
jkBtb20n66cwLkYaXzilvw4vaPTO3ykRWbFGoaz30BIYsUVNeoft1ztUF/WG
Ctoju59QvUg6JpW2ctFjD0Ol6TywWNdtm7W3VnclAVVtOFKNCKJRo60TI+i2
e3krcotHNKjxuEpXOSJ1fZfXIT4iVw9u/Zj3sV7cfSH5TMIbuUMblyC6d2qq
IgkBBMKuiHBH6F2v0QvpPFll27F4EuQhx6hoQoCtWerSuNJT22hEqXg47MyQ
fhvG7jlhNgzZkw9p7O6SFrVdzspheA3qHqKSdIgK0qt9EW56BgkEHlnImvOL
7TvGcPeL7QtI73qX8OqXQzerf94b7pNAKOIFqe10n33PfWPXiQtNC9ykZ4Eb
FR1jnfllQOe/jswuzquVnjdi88Co1MR/4Q2+ol+T2D/BgCv0PecY9vfVKuNu
4iJ8nOE8mhWF+9iITNaS0CXGtmMOujGJfoQYASwpHwrvd4H0gVzAJtMkCn1G
zfYcMIpWDMOFPuEfWVz7AeaanwQuotlH48Ojd6dGL/kzpVrG399nIW3Wu/OM
5TTDt+pZcoeIZoLr/CwS0ERXHAZT9UleO72EfiegzD0SWIveK5NmWYwo/t+N
MCa3dufjR5DJ3OwbHMvwP0gq6VoykjHb7vSa4hJCkDLkzC5AjgM/SGufWJ6U
fMtwojgFesBJ8klVIZM1oqWj7bb/4aKQXitZ7LNkZ2vrQeiOgs1D8D0ScF4h
JUDcVMPHKVH42y+Y8BrzvsizDzbO4lAxQT3ycqJCy2/Y8yJkBy0QA+cNj+Qe
ZC/shHbBughTFmx6krDYi8RBCCMTG4gCm6KSfFjDBagFReSE8vyGmAkGpyRk
BzcOtBjKMSNCutAIF5o6cJdKckNkZkL6pWEjzkGAEScISA5nVpj4eb1TMONt
YPxclV5wKLFP32OHLppw5tlfrCylLpcVxgnkGiHwFXntI9wLDXVG7GeEkylK
MctJzpBQSzDyzeuyX0zlrVUiBMwwhc170XhLbJJDx0L4jQjxYubuEyEoyUcI
6SyRLCB/y6KNoI+Cgg7ucfr0xfmtlIReaGD4vaMiANSU9pVzPgoZMy6Czn8c
RMliUA25oXEmFxUniu+//QKlWEmlNGafJE/nCXLrEtkRiRPeA3QMJRrTw1h1
HmI5xaaApMAXNQDrdSrXTSJ5JM+xEy4Y+qJwh0694EDdWpYP3+IOIhqe1aE8
SBFFmmLG8SoGbzNRAJqB7rWf2WVKsWqlbrB6wF6rEOPIp2X0k8CtzI/KFRQk
x8H+gs5el1YG93uds14eP8Gslw08OBMEm6N1TwAjVzjzPluC+npwiXw2mjB6
wmmTxl5Q+JBjTINnxMdEI7qY+wQoYb0xCO+L8XFbGg7vLBfHLnS+b80OaZQ8
iAsCvgNVwpJfF5HC+xVDp1gUVCK0H43u6/UGIpk3xUe2/ZYrKnTrpcm7t+/P
jr4dH/7u6N3Z8enR66M3Z+pLMOys5ytVq3kfSRz6r7wXgB67tuSdhKVeSZZk
AC+gVuG+hY5xKJqGmIdEht3T6MVnxE2d0wEkgnmW31Buqr9Tbm/kpsCdEXqM
id7Ccsb8MtxvoSg9F9zRGn/DVeNhvsRZFJJz6DxWRArdRMcYPVHAWXcStym3
m2oNAHe8CdNfCU0k7wH5kLviSvL1PnMGWEw32gw1zIRFDtbKJ2pTi7KTEEDS
YERGPTkxMTnhQJWbcOIQ1SQT3LEVkZUdoI2bNUj7UJGEPi/sR+de4YUj+c54
LJcbLK43xKgZSEHTBm8lLViMMzMXnbZOURhLvEFIl/0QGwCgg9cnmq5qKKb4
Or1xocUYRngB3CInAhPCkv6A58kIMUJ5sAZiDiB6toYWgHRKus17F1aJk9dE
FwWliZ7uuT/IGWwvhsRZxIENPBStVw9iu+xZnHE+VCnqDmU4ZYW5FaXWBeEN
hLq3k55+Nn7x5iW66x/t7O4hjsIVypSskqIErLeHKRZM8fOswRBhFrE4eplN
ljnaAdbX9tc2NL6rHdKNtL5PwQ/kWcJfEMu392eTJ/v7eztrLjoKRuvmQaEI
ksor/7Q7hpfg/+G/8CLpaOH9c+SkxQTcXp3ut8AgpRnzjbS7C+Eu62ubaxv7
ydo/7bxcC25HOLp4o2QJNNYM7vQ8zV3GlybxbbmUOXnX+xGVQArDGvj4ed3j
iuPS1ejIra3XCYvzcKsI+dEZzvkJD1gDPYXpJ/R3z5MSe6Zq6BRj/FaxYsZs
1hJrS5LpFu3NX4M2KO8B5M6jRx5MSA1lY23ZkERDVBXTepplQ9DIRVAEPRDx
Xda5STfZ/eFu8SaOYIIHn4X3P/kjIUey/Yvdw+Ovj8/+ZIJRnoXEwT+5I0/K
xuExfVsmU9U0uu69GUlqgsRLB88gsQqDv8Z/cMKIhI4j9lRA2X2kOMp3XNrD
q0sSYUmSl2ci+11zHR67WJn+InoazxME/we1A2on47tMNJQuCdVaGiGlxswp
lrGxKAymWR7ZKEgDF6NK3a0wwQHWmucI3OhaJSPOJE18fZFIgzb2o2S+w1Li
VIMAQqOElB7/IoJanAo3PmXTsNEmmJwiy2Hh48PDd0enp9+OT0+Pv37jQrhJ
yWt9p8teD7LtaQufPjlRLeBm1kuA8NBGUEJFV8vh74QVeK8XltNL6bqDgIO/
+0uOumDltAONZUxVZiLVfpQcXVHClqzUkSjiX8s8D8b1Q02XFeq4mD4RjMZH
TAGkFcfzONuXX1FQ08NIeKnq86pGFKHtA9DzAlHQEyedwkkAsnYmFab/eJJb
9B5gbNp6tgHXNn4Kg11fMbGDr/GvtgibrI9GG8loNBqYT+6S44qHDIHWTV+x
CH/V70CWQNOt8cJgwhhs9S+2KpGvzzEcUZdnxgpY3X173bhvtXEdH+r2AMC/
08DdJ/qJ2+ruzmi0veM+51wmByD8PICBTDgkYLSg0F6M3/9RCipE5/sY+5w1
nv1MIP34jZAioX96hXbgRBAyY67IBxepHIVNntj4+D82yXjTMWtBukCdUS40
vv4tUDUK7BdCCOL6Kp9bfNWj4FR+RTPylE4GMc1e1vWSEKIExwzLYRJUgrMt
420GYY4xoIpkWchRPBlOKNmYAWU0GUCymPcQAx/znAITmtMrYo76ONUnWA+v
H6kQg2LPyX0yWAS6y/SKU2tV2tndIXHmISM/Zqk9wOo7RwZs56FpZxHCO5U1
yObPGuc4bMlUJFFpND2zslCiIrErQ0cle60Zag88DPaK64l4oRCF9j8v01xp
cEc8jEAwUCnRgTGS9nB1d4/mNKa7iDFqraLCOdu2knRSdZzdJqb+/YvC0dx+
f9iqVLE0/atCb0nMjuhUz+GtOkp35vxOWa15gOz+cMnd9EruMR47XLtPejf9
0vsKdTnyWTmoiZ8fp/MxfUvNvZFEoC7crbpvGGeZntNzFPIHt5DzeNiFP0N/
04rCKrvtPCp1r63ioaFjXLKm4wO9xqCpyl5hPbEcJGUthMdza85O/+hiSusJ
h1Z24mIRsC7ZFWrW45VLZW9QXbrgiYGOzGI+mlgisx8Rr2h0KsJDya9hciXL
gt36f6E4GZS18KJc6kKYEaOcnCmZEECQ2OVzTW7S1mUpCcdQ4sYVXBfGGdhj
2wJfh3dctm3syrZRcBsapeXJIRd2Q9M04ZPze5GR2pIF3N3gJQgBeWt9wcKA
KsN9LVgiNQGkGHe9iC2pUmwXlryyLgeV2gmsODipE6s5HZ06U67Q7Kwuft6o
u3Cmupib0WErZXzBBTR9DDvwcXGQf9YOuyiXzbA8H05Sja5FX2o29QHplHWJ
SQv9uKgFW+ZzNrGLMS+UhVr71BteD/oUqlWzLAvASkB1Qt1QpVLoOaH9Cydh
xSJzC8w/roLls5zcWbf1KmIWejPEJytL0dKaEUqVoXNECQeVUHQ1IZxl3R0+
mtbId44GD72dLS2nA7F+NUce6+o579RRcL+ig4El/VpOexH9ak77zFboOeih
UjXHra6j53TX/Z+t6DiXSp+m011OS9XpPvA303WEAhEB9W870cj5MRTtnOuC
Fq6XQYQ2jixQxDbsF8DpvePbzzEKDiQuplJZkpHRgutHGxhX/EYe+2wFx4Xm
/ajajT+8f1D15lVbLJVHHM4PvIB6F2SNQ7qOlpJ8vpZiVmsp30PENvcbxx8s
YpuHGMhXi9ht2Z+UkiEZeNa3RvQfBNf+/obo/T2iJjJYW5k41iAQVGhXgQDE
/lsq/uzEDcETz4TIvZt2SIKITSjuTW2BRXgHPUcCS8jzaKnW8Cp/XrcZXc+B
tuIm2gF0f9/KSKsQQbOa7cXyt8QESIASsz5DrC8SNyQKC4WNgfqLVC7ziVT9
4pbxJmOCemAy9gKOiOe9nCqGppF3V3F1pkCdpbUtffyFARbJKQ+eUbgL74iP
w+HrwHzdJq1UNqLDwwVZRN3orKIbWCrXF/HF6UMcxX7Pusid0l6bkh43vLvn
QQXOeMXuUfx2nn6kQpKiyitx2NzdYfqwicJLWHWMb2lR9oKM3KDeGG84/Zwi
xH3RWI6u9Z6eejlh6axZJc5z2BEHrYja3IYzvF25uAotTOLsnxrf6HHAhEqx
CEqB4wl9e63F6Ek6w4C7YoK4dXhD2khL63ICGR1Qj+hJzu5WAnFfaL4kogc1
PunRsgJSSKVWzruXjMqKqs3ClWyp7TzFKih1VP+FNWcn6WK2Oaprc5sWXFQD
q8L9eWkjWTHzdN9IzXecYQHEnLNAKiwhBttKgUaLWtYXo+RVM4pLAmH4SuT8
OyKaHqyfOSJ9l34WhtMFlFEU9yZINUfaxwn+EmAisbC2pdFxKHStsvJKbnuZ
SnC1lC+XsUumnNFgTKcB2hxR1Fokb7bFoe6EIAdXBdYOBB8xDPGxGd6Di75x
taEGwQ7azJTi6bSCDHwBIj7FfsFyUcaJN8o+PUdZtChZVgTraEFU3H2GpH1x
90UtED7f52d6fH53ImqsEfc82tWKA7byjhzKfUqxw/+2LnjHYmLN+K7zfogX
MFAs3jECMzg6y7/t1YRPKcVhlT58xMa11bqyFr1q+QPJVICztsDSWVRLQ+58
f5+CfL9WKBfxYc4VDYtq64IdKOG9joHD87uymZw6QoV+ilBl9FdEwkVnkq/S
VfhMvypZ2zjn7gEqpLlbhbx3RKc6Ur3xDjDu1/NiUKkGKmmq6ltbFb/JTEJp
N3Fpjh+oXYi8O2fzsHNuB2RuDUh18x1SMAZanETdp5E/bxE3fXDwpFkdPJl8
fvCkWRk8mXx+8KS5O3jyv7cCdgd1jZUwqrBK3TSI72FWSU6mcyvwoxw2Fi6E
i0fVbEQMWAdRmes5lVS7MjeLMs+mNxsuUZTcKQWMzG+qVIwOJy3LkmAJHWRr
bDXs28LKCJ22MAPHp0FUvRwysvor8iErZ4ykc0TB5q6XMQ4fUNHOqN5/xjIJ
GwxYF6BuIRRMKsZDEy1THXE6fSqj6PBoryBNCMNP8Xwp6kgwa3bnyjo+wKxp
4SVJP5qnwgqM5sQ1l7MqvS5YnXChaCLUBBF4qIqEYdfXEv6L5qI8XUhNWjlc
03Cwd1Sqt07m2cVlExQDwxpWJXknyfWgI9HSeQFIokid4BpHmCeYp1NpgjBZ
wjeF5k6K3IfcaJ5+wFpnoIS4zgliznIQmSOi1rRAJpUcqRoz5rGG4Na9X78w
oZ525y1sXDkrTw5amZIU8xzz9vE9XCd++oVE4bYsqjQOQuUFoT+97PR2x4U6
s1Ggane+8IUXo/4ZOV+nNbZfAfXoCJbBfBND0bz04NeywvjZ4c+ynpU68Z0y
aJxjrumztY2ydz9bKz7NUJatpXKDf1x6hZQs4wb5xW3u7NlbcxmvRQpUI6Lj
qlwnBZIirsugUpbcKnakIs1DwSjMhhRDUGSsYYom32ANdvJP4Emp51N9F+wW
vpM8kQVMF0S2E1kSGV2ogBLwcmxGwgW7kXz0VIPRnjzc1y+Lz9kX9QbGn5W5
9DiTAzMPPDCqvXr1mFtmESp/wwKI4fxB94KEI69HZe03HPjuMxCY21tvU4D3
fK+QMBGoVjOW/BmEndMVWi6AIZk8vaH0tlXNeihh+2e4LWrstbNFbc1cCwmt
i4P9/NCw+P7wZEMT7h5jcVEBhApzK+fZY0PD1eNweA2ldsXsaei3C2YHgXQX
x4MLh/CJqSXHYBvOSoqA5MVL1z2vs+pREktNGqsx6HAotv1Lxp0eMwypQsvk
pueg2Lt2neYfWHy8pDYN534dtAOA2SxIDaJuF26hwaDSIhlfIaNxkl6gFCTm
GVlSRSEXsdmtB+ucJEqNg7orT7a6NtXVVMgEpjWfhE3cWs1DfMUAc74pF8PJ
zRB+uOPmu2TWw7Ibux5rNrT3ToN6xbFP3WQTgmv9SEfs7vDxiVckwpy5qFUa
G9fOlw3I2iY+FRdJ3yozLioY2ie9w9dZKdlJjFTUVXU8LefeRBUePVl4l4z9
x74OpDgGXNIT6UGG+lTOF8TRnP4jishA6nASceZx3erx5UTjebQuTH5jaosp
7o3VBQdlKFFwRclKEiLwnay+JNCxothqTNiuFrqaktZxoxV3pIe8Ea790luu
3T/KmPd4J1RpgfoQvu78Cm7orx/v/GoTfw63gYC0Xgw15BXhAnW7tgW3yPLN
t2wwqHHK5BY776R7hzZbEKDqCSnH1O4qpPzeFOmcG8saSehHtfuNPooysDTN
xfpQLUBIPrt7kYuHl7PZ6lfocIbBVPGWONUaCKHVkrOGTMYc9xBW/f2q3a6J
fafBUK7sCQnCsCJslSww45A7kLRBtUgLS1GIiVsVXtYZmV4Dej+AqRoumY75
qJhH3nMH40OPYy78tjWUNdyYK96AggTym4mNV0S2ALwbHaD5UgxGCaBSEtw/
MnIk/NFZUm3OVSdFhmcMAfB38arMWIygIDkEdn1TTC+rUhtWuxwzF4kWNMot
UeZMg5vk60UF2MPt+KItiLcqagzF+6H0Kj/gV1rKQjvWAlMMen9pLnEVyVsD
LKprF6ijcZQZW9WdAMddGvIYNzCB6h0nNEt2E0t46VR1Oh4llATZA1y3s4aM
p914HmKxLZ2yHuxPnCM+T0tZnkS5X5bXpgpXRaWwMfCTGExI+7WlDV2nuJaY
V/1rct7QgPB1gByj5JAgRjKINNzjUkwcVY/AH/RcTuNNanz71IrAFzVEP2IZ
ZArFDd6AwC/xtrwajMJDfznZcgCxJEpDDl/KOFc2dPiR651LgcWlat2qfB5o
32NJBFrtDqF1xjl6ua61VV/Eo5ITpsNicE9uv2ixGKnk9xmcjDXU3lnEcq1V
lbzoIFpB3MrkMlXzPi3NyyrACGf4nmeDgVhHSltreFLihb2xfYZaVRyOz8Y4
mTmvuIZGfGnFKq7zUv8Cb5BlowSv8LdL4N2AiKcEAeNedW4w9RQSj5cTj5aQ
0BKUK+47V82JArn/1NB3EyxYPFT6LTqmQvdLCLTA87Jijtgddf9a7nPJ+HVy
VtDKhpyxw73tBY6oDpkujFRxcpeFwe7CD9Hcz82NA1CRSMJXvBXDwr4Ooc6z
CqRxNnXo6HWWs6ERLvlkSd2JsA2VRQc57Ai+WBfKQ3fcEMEEaR9vcJUtNkTg
Sa/TrOm9wL05YLJ0wC24xCcOTfalmR8fgWbmylJRtkKe5ek4sxOkjBFINdlB
TP6RkuQyy4SCcQ3HlV4B76jtXrrWrXQiUHAsgWVlZFw9qfjcgmf46BQDo2rf
VKlsmQd1Fs26qyPZiZ7k9AD8Kk9RyrlpwpYDMgGrW/Q3UWHfa6Y/S1n7RuHe
vS7mVY4CPSJL5uCkz8KTH0bGySUTy+XV8GNRK5smnV5y2hQ8Tzpk1aOTs9UY
hSFklOQ9sWxtdjWmKCQmcy3GOORBBnQlnETAmdncXqQUx2PnYd+aVmM5dWWk
yQf02OUjKadWfACN1jJ6O3LSKc7Y6rHe7d2NS8EjBeJrU5QbsGsrOgfP0b69
5rPufP8OCnysppcZ2rqW7MrAEtK3z/GpIcb8oI1nb+fpNjUdKbC+GVyVZZ5W
gwgG2p8XLzhxf6mpUXwYslMoSKQI63JIZSZyGZE9Nl2inSBql1sJ4L33l/Ys
nLw2unltY+2bAtHOJZxESBY6Ii2c/4QqjtUUnHoTNBtEAYuLptUNK1fCl7Td
lhYdDe6ya3Si1qAAh1ycTY9MMKAgF/hbOhcqUUGqRF2MSpSetA2KD+lw5QKy
c3anxo2/w3aAviAhVc7JWPSeRbzfCXPt4WVfwZijhE3QfqtxZwUxynpbKx2I
00SQz4hNyMlq3ikNS4P3L5jqMdKL/88fiIM532GUGYEHLXphg9YlrvGn1Yeo
gZbX/IJbEFjkogp66B24FnuY5lCBtLecUzqJ5wQ9Cq1zffVgjOt9TQK7aInG
KbyM7vxwnL2kRC9lASkAopSJuy7pGxOLTmid4WpeGBnY0rs76yPz6ALGdD7Q
cEH1IFiFmybMycPzXADlBLWqgqk8JGjNoE6gbViz24gIvhPYt+hgu/cSZ12I
eYUoPpqwbeN6y0UvMKKJ9mlC+l0k0hCUaYPwg1BXbbOMOCNQHJ5YoaMsSD2r
0OBWl+fNNS7r3KOTdutbFVcZS4uB5pIGcV2+VhDQ31qb8+E3Pw+segNf9qS4
YT96wn50uAYW+5mu29HFaCCZh86b7Puabgz4SZwgq2LHOl2hDL5DF96ymZDI
5qgsJ6A02pfQXUXGJ+2q6h6nKkspJ2qRkYi9/gh+bVxHopsDmYtq9UU7Sfjk
Tu1Cv/R2SXNhlC3j5nJzadzq3vBLPKdeUTgcSZbTpiAfYCUQNAzBgZNP0nBo
afdEGOQt4s5txJVnq8T5ySStVKQckAVcbWkaaYjhN2lOddYCrhGlCRqHoaHJ
9zzLG1acadkkuhTxYdTMt2X1nADrPXRB/ML1XWgbo6agF6WwWmk6qoAll4P4
14U9zFOi2ER9gmZHfBkFh2tn/jMBoGWiVN2VyqE0B1k1BsU715nRydV6H/sB
q/GcEXNn05hnGyRwsvjDVRVndipeRYE0OikO4II0oOxUydnZqw2O8vEEnyCM
1kISXOA7A4P477pRIGQ1cMNSQ1uZFGPhhBkSMAik4pAi+1Y7QTuGiBinJGYC
Lw8168Q8n3Kh8f+G/YQcSKlkgR4QChocMtzQbMqxOccnQKxZnDw9OiBRcneL
RElRCcQO5shuAHem0E2Xs4cnhpKVzc8Ri/U6IIHX9o8gzXIzYmbgTlrVYyY6
6WVULaU3sTdlQMN8GrhSL2X516nXkxM6tT6s4k5UuqYF9d/NpcY3fSI75uhe
fipYFXHPKehdUTIyic1xmwdL5YjwTYlFLJLXZ+/JJAlIa1Fz2955skXqG7Yr
Yy/ZSKIKehLeE452j2KnOzHSYnxDosyN3Q12wXOBhvB8jymndlaIgoVc/PiC
sdnc3v6MrFzcem9nW+oIus2E/dFE3KDq9B5V5ElEXJrc9x1JpMRrElJhbtea
SStXuRBcWjnlGhwZKKJcyovbPTtFag53hdJMEOo4bVYL3acQyF4iwyEL3CIW
CzmpWIKAVE8xDU4uiBYOB3sP59QTNnTC69nIjgYB3ruea31GBudAbGOKIUzZ
CAAysYFnz1ku0FRVLmFjoMVT+kSt5RYprKAfCqQLIAsABihlfmByWl+roSu6
3xIp8olKXlx0gBe2SGfebHj85vjsePzKB8UzQyIww0gPQYkKQOwRYn2MIr+z
jGrj1m0srpJEq8LnURrDMbbZUIL5GINkR+8dJSalebiA40OJGh4ke1gNMnpO
CLm41/U5GbtlIOWpnvAIMJKO8WexwEqfw+PDAQXu0BCaS0I+Q29KYrq+/VhW
c+4KDY6PxodJ3GQYBMSLgSgTTdmkFKD1aFtexcR0hQpn6SeB9Y5VM6me3nt6
8P327q4bjQP4RxsS3NaDWU5W5CoXB68p8ATYko//ILzf3sGYb1kjVrAklzf2
DPQoaf0tIzrX13wyNgdRSxNuBZz63KrkfZFzOpeuUkl0WHkC85BkMRdwZCkc
htVSJpEpMrhqZPNbIt/KtBqoBAZy7wFCUfbyaFhit3oGXUathBrE3PvUSfHQ
IUgFEXoA6xKUEWZi9wH5qKC2vo6PuSy6JFk/P9/a2d/f3ugG2mV1nzNC2Qfl
MlEqFlf2Vs2U+mViF3eN3hLA0SBCK5sSo4yv6agpdFJNO547tiLzzAMCvb5I
uIvrKcnuZNW8/SIS500Pp/X4ALojSJk9AmhZ4CccekcSobSjNKGJi05dRQyx
aEpfXd/fXqVoMSi1GtqGYjYcBJWeXFluRZIdOExHSUiQnqSyilidugVXyM1H
QVlplNYkqc3AyFnxCs1Wnq3jrbmgRq2EajA0Z6W7aM4aex7EzkOyueguiTuL
qVAzs+vBiqMJmisi0qOAgj9RPtn68ik2/5FPOCRub28PW2SR3IAH3wY/B+2z
WdBwfaAbFXcpAgkzE5yfAIUCwU+yL/c5CzDo3a2WDBCVtayO5dommWLEwhbI
NI3giFT04qAj42L5XCRcBeNcYY6kxqd4SZHC8YDfDxP265I1oVXcCDGUiPFh
cNLviwpD5Mm2sB4mKUj/PQYoujqJWlMLlkeDZO00rpskLV1gMfjnpqUfgjxY
A5fXtSwQVWmuniS6z1gfLIxX2F5fyivcghW+KX38WjAbFy+np7bREbl24LIx
cT4aJV4cSpfs+LpCWxNA/TKboKDrN+aV+tRVdzrPmrDg2qprI3tmdw2m+gFd
fJFdxIexE22VzQXOnquMTkLUCJfCckZKkLj09CJ1F59fo8sUtpHo5U20yLuS
MHySSKomWuxy5Y1o5xwfz8bloAMvUXm53NoLzRlDg7XFNYsii3YfBKJmEnjJ
nKdiSuHvkqHpivnF+OztDOKPSzutdyng1BU0IFGHnoXTxXwMlk2kgcO5L3Vc
i6TajjImv92RBtiaPkUQCCRVap+jxuxXuCSlzzVUYA2hsIh/Pp6RiK8bkaQo
kpuQRWpAsqM4EmfGdZiRldl8kWR5vqRrYE3opaN8rawQVbJXf/UxRWJn7lRN
Ax4d10tjy7P30Kvlvb6kfOqEsDPsCo2j1LZZLshkRkZpxkIT5ApI3nTLFzaQ
LlFqNC3FnkmL5D4s3iXiDgaoNOK7m9epZuLiCtvoYawXmuLlb60JntZXF8b8
cij/fkl5D4n7B3+9SIJv/T/88Nf4/aH5Lvys8++XPEySfIc/DvjJ7+AldrTx
x6fLCWYuHiS/wlGfw4ccRhEN6aY8esCUPE2w4O9M7z6iDa3e5WgkecEUIJIR
t1XQSogIHsMZf3KKp0F+fnFV4N2IGlJ4osZ9r7hUAbU3yoq4XRT7gaXXCteh
qMOhWFrfc3RjffvpzmhrtDPa3uZ4+zRCBGJIFG1BTn//oq1d5ZzNrU4X9dCk
X0rrDHiXmoSzJIKL9vUPXfE9+rxVoJRB+cc/Ji+ROAgi/OlP0XnotxpRA9+D
3Hx0dnb85utT7Mq7+63TBZ4l28b0Har/F7x597+jN+MXr46+lYaE3568e3v2
9uDtK5rjvnc7azo9e3c0fr2+t7exn/x4TQ+vFkXc3ZCpgfY4nJbzFU3f7oNR
z2rvfiPuNHf3syuWFE6KwNM+vFxwoFN+z6wHZTvoTIIglWdoNgkyt54lgtAm
6RSJeZbs7mx8DkRocXc/vmLpXF/lnnc7+7r7X3vX9z7tYeLpwwNe+5sDrS/X
5O4B1j8PFp38vgBL7v7XKufwDHtwjIL/PQicDvm3NpLNTSwHYpyP3sQRkoIK
22HINbyncW3w+1EYOOAiru47IDfd3Y+tWMzdL7WWevfD924k7FIZMrGA5b7E
j4XviuyKnHfMIlGi1di86EPyEhUEoEK53o4fMDsqBqS9PIyr5SbCG+jNVyi3
1yS11BsoUf95ia6ymisMSbG3iPH7ihWGdULO9qAoeRZx9V5ube7sDRKQci/V
kOHY8vfnnHcfxH8Znbv3zv0IdG5v5yc6F0Pk8ymdg+XDeEYPkftb7W1v93tv
7geQ8JBQRcQmoFSn9HmXVIE6egrEA1VJ/In06W7d85Jt1iIqAnmbVGmB0XFo
/LdqFiY53UzLCgOuG/8x2UhcPuY8xeKBGh5S1u45ViaDOmFI1Dh9urdLLJmL
XWekMAIXn+pdoYkpXtpytfeN09mO2dnahTG2t3dpFFJbUPWusNbARYohTxLQ
KfEvK2BF1pVCMuiuASxoVC9SjnEUZxGZMmKAYXQUswGMpnKB0LJ8QxYMRGrr
6zgGxYy8YYfHiLVyJ6ehVoxa6QoF9pfBp6ywepg8jRH6uyRQimPd+ZdOTUdd
2V0Jmpu+DvV1l+PwXaCnt+d+8jlz+0fc3Ls/YN9fdrX1eqfW26jXrZbrFt7G
/xKV3S98e2tLtfaQjpgoD7p7qdfjaxCr7+EK/LJWmQ12+lcQZ2LzLTKtW7Qe
XmgNF5AcabQU0KWhUABHZJrStFv7ciVAcnGpYdOlEDnaEDSaDe9qWRi59jxf
1nPp4x6/fX4eirB8SDAXhcYFwVyYyKN+Je+LrEtXE0MMpNr1nBujUGqFL5yK
nf0onIwD+QuywP9kM/lhNhO8Mv/zjCYikbdl7paw1S8MbW11awGLXHzf9H2y
bVvCu1M8vVNEW6lGP/yg/mF0nIhx/KTmtIHyPUw67t2fDDr07z/PoHOXQKZY
FKtJMM5LlM5fuhiKe5x03usbhF2s8tH5kkDwM51QzZK0m39HIhA5VUPmIeEY
pwdnJ4jBvgjWNlwx7YztvYAZ9W2LvIDyDLn8gvY1oIVh6V+t4unD252/fKxm
J47qQOFpSj1vJkHlIio8QRalcHGSxICdlWxaZxxaQG5vFsS0djE5UZkHB152
9GkPzNHpySCxzfRhLsWWR/FuT17Ldxg6DfkbcRgeJvRMx2f4EAeldxbe7SAM
1txRLTiugFH5RABIiHq/IxCVCapuTWJxGrYKp/7LJP/2VnEKWwhriJ7LJ2y1
P0NEIpumNivrCt0OKXHqoNu3KuKa+SNC9+GbUzRflvmSgmGodMhlmp+7tGzV
dGau7EbYFcMlDtUlZ92UYYkPI4k7CbspS9kJRYU0WdTZwalE9KI3vHLVUV/e
znLrdb0plGsEz2ACq8qUslnfYTmCgSpRDk5RiGS0CtTGpMH79s7u3v5+SgqV
Sb0OFY9CHn7/0u7eo8f7+xMseoqHS8YPJCyhUmdcsEBAWpj8xOmFnLTpAgl+
0iN+mB5ByPCcb+mzLhv4Z+lq/gzI/j+OuvHwJf0dC9aPP1Owjm/w95CtsdL7
37dwfS9IeoXrmEp9Dwn78waIhext0lh+HPkaqeXmP4yQ3dpN5DrtkU+IVZCQ
EsvY+v2BT0t5RwVM7ouHY39rLFVTLrza194fOsZkeoIwo3BKzH+uyig5xgnl
ZJOraE0aFmeiYM64kOg3IBXfJEc3dkINiG9vn39zdLVDJUt3tx5xRT7v1CBZ
x1DNncLFW6pQjHDkbM3L7OIyx2RL9sYcnwxze2XzwBVCwgpKTaaw10hYU1dE
BBMsSeKR0qgIme8lPatULP/uFm9/FX7s4ui8QO3F6SN5I1Hp20/Bvxzycy/d
ZywlfPf9l/LyocI3S/QdCVzRIcbxDg57gXysOW/B0dYdyTx7kGju9an7RfNR
4sr1OMR3mc4gVBsvVCcrhOooB4c+17y7WHs05SIqIei8AYmr3cl52FQTwiVL
tfMMRd6kWn+cxYdeA63jG5T98N1VewVnhuIqr8Puhofn1WMTeEbaknS0G7rs
1xabO9ducA5xhKGfjB5to2FstBONrs0GegRuDiH25ZBZfYATufJBjdYlErYw
IpTX8Uq3QygpZyoU15EixtK6RO4GzYA8HMNWdkJaWrQtrJvigoR/Evj/NgL/
lz/J+73//nsY0h0d+n5G9MHfn+LCFBP/7x9Sd/l+MUKeI3yPKKGHv9zSWb68
Hz/+2+tlX24YSpL4sVwfwKZVL/vRhtxzQ4baEfb+QZHsPtkx1JO0kQPJ9Df4
MDXAkdoQ5iiqBL8qI0mq/qKMd0UNey65NY305DKuGKIk+gTlfyVZTUYQDcN1
fYzqz5u4il5Y1Sw7J4Mw5cCSrvbu6ODta7iKh0eHcb8Djlsw83JGkS++XhpV
CON4GJUYs7BPgmuQpHVAfC05098MVeLAWpVaGuxHYs/PMeDNVaFcNQJqnVgf
axaHoNDqJcuSQKSCsm/iS8nVXJEjSZtSyqpjtTvXOrQFk0Rgov2J5GToUF1A
sBQbF6u0irB35DJSKt4J6wUU2NLGsBfLqgbE075lFLRMieNaqkQqrcLqh1Rk
gS+BZOHlJQqSX5GisqyKgWk6lU6WEyq2l+audoHEqwE6XWByKh4ua+m51FJz
QS5Gq2Zkhc9D5LwzbMukdciz+xKtMTr6inpz8CtZMa3QT4XtMnD/WSHlCY5d
B7evGGuCZrzAd5c2KFvj66HLcHADtYVyUPCHCrqgd25OIT+ujCF5/z5QPHda
NOkF5VJdwqlSwbfy/JybIBhfltUJVyuhwk00uoCVOm3m9vbs4OTTJ0ziu73l
PgIbg8gyoXhwzf3Dp8vKV3DBUoAF9+HtPzvVSWktQfk019PsvmLQXBVQKwUp
2cQKmrOsJs9Rz97Y5VPW1sSpy9JpjNxVvSUf4ngrrz+N4tpPBIooCxUOW9Pn
k4tlNqOLFbaaMbsjYPCU1P0cdLPh+9Px10dkKdp68ojaSHz2oeJNQ32Pyotq
3T05TxOfp2uR1AtNmKfmOmbwbu/hm7sPv7UUx1zqoKwPIPhyCgcSEB5V+0mB
LUGdyuZU08uV3KcKVuqZZrsHWkewiAredrPqtjtCqfYPLJ2lddo2d31VDrSs
VemFFnvvwQnO6cX09jaZpPPylRJgWFdOmcfRgoueY93eSmn1QaibY+2hVgG1
PuTUuqicBi4I21fcCkmu1GMiTOeqnTrbcpEELTOk8DfWMqnmXGT9xm3BBDgS
c3rFpxPUZBE46yfw/xudBPuowEq7XqgUUsFAbCxpXftejWHxv6RbsZUFBh/H
SM1W6IqkfZCLg8lD+h2UkXTF7IqeiqMDbo7MJfBtKi274GUMLMExlgVwwYzN
sFjHMa3SKRZJpHKyzMo5wsEFOATF23FebZLxChtjJQjM5FArB5v1w5NX+NHh
RlA+/Pb2uX5MZOTJ06dUzFErmErBkbiQlYoQUlQ9rJ+pRUAI+FhRQEpsa8UG
bWogAoa03NZ651Igl8dqN6lpVXjgK3V08KZzpVxHw24RPlf/IsTIuI6pixwX
e6iRUlTCKPq4oNo7KfaaC6kcfcT6oPDxgXsaa/D6pozrsPINrMYCPxHyu9uP
nwAD1apqWuyLSa1fL5JCioih68l4Kt0fqQjQPK0+SOK061vmCAosYIhhBFjY
g+GBLI4uld5raSpSWVeiAUDe3XFPzVP4PkdRDJdv8FjOQXCfwLDJVSYXanzw
L9/SN3xxJaICfQxHB0fYgHig7cOpeoUrdmtIUpUDmPUth7oSYLEziwJw1rdk
bezrhtHi/gpheZ4jMmLu+xxWPTx7/+bN0Ss8q8dbe1twVumkxMalSHPPbUW1
THF3eAS+GGcGJ1eRTZUnCs6lVVRSSxVHi1I0vWbgAj0wUvWVKzIG+ywC9Kql
khFxeFgUnxetJZTIud4jTgrPDFo8kxrVWLL2ck0kqcnRhptiJt3HQ624wT1G
Tm11RSU24zua3H4xq6eL4TT6FAtaqIQXMDZELkKA1WMDmp6wXL5+eHpwskGF
GeEXPKydvS/38GIxVSbyrwDI026rMS6Vwqaw1Pgi8igDDC+B3qkyHHRO7Sn2
GVWQSknba7iDxKpdzEpME+ByXiCX+qK5utxZ8CKSk0laOyymMuzVB1hD2A8J
NyttmZxKT/Un+Y5RbW1x+WG1qWgGktqASc2t9zI2Pacj2EDGaMX5sARIpDYF
Jabb0mMWEtahk/1nA92Ym7HVFAvPOVIMg548wYLmA6+2c/VPUizpLSKlSySi
+Y1rtUNk2C/w532EP2c1TUPOFmUJI4yQAfWrKr53dA99EpGpfa9EDtMCRSys
kjCGS6Xd69EnrgoWUhXUB6/SXEqb+ihR48w5jW9AzNxei4euEgD6DtW49mPT
csFboEXxbXKdOpj2+MsmAkCLKGrHLVctXrbJ7Y/pQ1wbxd5Rf++gDndyTTGl
CihAfN8C0IPTORvFFY+OLDIkYVQqLrzTNUVbV5h2Myzq3coV1NvdOrlUpKMd
BBBuiPcVyW5G+TzWg7PnhBLn7RZaXGmwg0l4o4mdzqLCtnrsvUhm7kOylcfL
fSboRuTcJ9Oa4Hy5/Yw7ZbdYJVr9xxzVmzXBVB6VAHEB93xBfsYfbyRRAbLd
hMAsC+mWbKW/h3ssvCsJV/QO7kjEFRgJjHMxi0xO23GgCE6Vy1y7Fm9x0U2u
90YygNR8wxZUxYVYJ71CGpPfmjmDMAZcMBwvmd1AIl5WfVZdn1qKYihJA2gZ
yuoP3IBeI2PSCoStKq187mkrplxy+mj/C9TpsESO1vYrg/cpiW0gZsNcjF0q
Nmg7GFRNvePZhdhKwh3vK3kB1BvEG6zxx8Hh6UTLgvrglBut/2f0uBCqdMys
AlbZZNn4bFznY2Z+Q60rtW+uL2Bs2iq/a/CayX3DPftCslROmMxS7SZ1BpAg
L2/m5Ph3zStaNWi9YcO1IJ4vsX9Qcvbq1PGscFnuhgxoH0Nm/a1hUczGPdNO
x+zoFX2Qb53hxmxoN0CCh4r7xMLZIDH+ADRnJKFV0l8VzfBT68vzU5B+CARD
QGDSVdGBozwHBwOoJkEFjtWgdGFhhxzS4gCDR0zFPY1L2V4EayDazRILxotf
ZTOEksNZOkVRNu1HrIVB1QdNjk5wtYui7KLEKLABCFqMa9cDqW8FrtOljwfh
sp8bSWyS1zU5oUwL80pwikNNr7tf2BKo9wIUrkQba8LtVndXMLwTgKmsx/SG
ZEMn6BPz8s0ww0KpWI001RAe5EaiGqA4ItNwF1ThChIchGJqhOy6OQwRb6SL
IEXMuPalOlzl/EPETzUEJghD0duN7JnudtTEpvQ2JE5dDfUAV4k5opoSV2/G
KBhR9gyVD6jgLar4bZmmYJeiiUXQwZ3X+qB6SAwif3eB9epVEIrAYtcCHaDo
iyOqONR4pTtQAzdhFN/heF+CxpWda/vmdu1R6gkVMiPXvxSzIUqOyQMWk1Hh
aqMcgmoQfMAoqW4vGIKxb1p2R78BQ1awdIp0lovHIJ66oTsdtZTTaE1ajaws
HEOnYs215ndoTcpaitdwZ20l6OFJS7lJsi0aBmoLsZ0Yf4kNOgp3s8MS1ZGt
0QRoRuSPe4bIGngOKepYX1L1TySn/d67mvqLtQvytqQYDkOV5AY8Pfhebyxs
DzXUFwcnu09IRX2y8yWX4VVxvFVpE7C+POcWPa+QGkaFnUnebBXKdBnp12XI
4mlrQewWc5if174xkM9bsdo9LgvkWz5w5eReCeuGGHKZVEdp45YsvmywbyXB
3pa0MT1rIa1Y24hy0CCxHSlBDV+SoSkKvKuDBnx11KA8qlqsZm3fz1PKnuaR
8RjWBQT84oKaGJNkgYP4oukvg+w9RIzQeJFOpxnKhdSiDbjYMr+wIT6KIQmP
hZf+8zqUn5U/aQJR7J80yq04U1+LcuPqsJEf43L/8RKeZgXKYxxHmBVXZaBq
q3Qycw35gnMji1aRu/Y8nQea0gQxndLAUgq8hk1YWpO2G6Q82EkGN+o5m+iG
p0cH798dn/2BbHXbj8mi7bweQra4kSiLxiSUEI5QaKf3tKilznnFnqNH/PjN
18NvuN/go62nj8g1loVrViLLNIDAgAoDXFa3XhaYcRuX0nySvcRYpr49Pcar
hkbGWOfnir9s2SsjVYjb8WKT3R5bG9AI+3FBHecCD8S5urPyNl9OMYVuSGae
csJydGhe6dcdA8dd2NacJzYuxay1ANAFxBQq/EsSOuUT2n6GjIGkoSF2gsyw
7jRZUgB6pI2hFhkEi3DHz/GbcUdn+kI6Kb9fgDQGovgZysLtTqBifpUIORym
CfpWr/kwTde8MhzT0JiJtPO+4XogKVE9oCu/+uOf1imkc39z8/r6epSlRToq
q4tNL0bUm/jAcMnDDVlc3/g1bOp3qH5S/9ggVNQcUv9NopP0nfNpcCSCxB9R
GBBefliHhnbRSmt66Q0QJOxBTiR+amvpUhtaRFY0jwWQHqDtMPNNcF+PT3/7
/iiBa5mcYgsIZLYOHrdf4J6H1Bvi46c27L1xheqhIPAxKoLSNTGuaK1n7DXt
xHtjImDT69++f/fq27MX2uwcx9Cnkwv0lUklGkL22l5IiRU4qmxOvV4aG/SN
XpunNSyQDh7fUL2EAuCIsqxtjjAAfEgkZ5Mf31wbGGTZDzp8//YQ9H44eJeN
GvYbRvNyuBj8fu33+Oq/EK0D+ARw6dt80Ku5shiWlS/nhAzkoD1lSHDT5yIZ
nx4cH1MADCaTeC8aO4vVd1k7GQtXRMhFfj3j/XqPRo/Zs8fK6Sg5KhrqppP5
TFleH7e5gJuo/iBSPkDcjJ/ndY+612AsjWkXIWbi2xiD7hBdN8hyBoUXyTds
+FPe4wiUH+OsdSTa1JCPK9wK/I53D1Dknb3K7HUbKHujRzj4zxBfhydvXx0f
EDd7sr3Drk9v6cEWaExWUdhrw0InhE19l4THiEkxAXwob8aBIKGUmv0oOebu
P4cutWY5W9DP7yh5IKjDBeO/PEie7jx9kiRByk7Gj0uCT/A84eehUoHvKBoy
oBO2Hkq3Rw6LfAOY3EcJPhEeoFe2IUkIgV73nAg16ZxdYf3LQC2qL9kWhTH0
2Eckz30dhhSDZ9CaJo58Ps+JBYnnSgUyikxZ396Q20pv2hmdhNGTcCEIqLHk
aGyIaxuQ4iN0WozEx0dnLxOqaIVy2PrOhlGMpJKhtC/pg8GN3Aio7KJ7v5ih
MIJfMLVIYiKh5BhITYcW9/LBJQ3oL4KjTkqNDI7Kp3Y/Yfo+3LFDIFGKxNVl
dQD0eKlrDtvXvOdP7XEU3ep2nRWuc6UqaZTNJLZfXySP266vmBu76HFLPppc
Yn69lKXLIP/WGqq79XIiyO6KDIDIMqC4CI+3Laa2xnq4CT+kXkIwLfypJCsi
/FG/7tvbkBtLnEUUG/8uIHG1oguF9a5m3oosAEia36dpChRFeVsjwUmmMzjd
D8QNkpzaaSSEId8lJD1xymC0QaFHSUwik4gstgngnZ/CXFsft7Z51JZVgeZS
s9/Ym44SeWsnfkvKjEdvae6GElZ4axe/74vf/Y5aGFt4N2xRHpBXtXJ0yavA
iGjqOM+9Ro3IpJxHQxg6ByxUAaPOEM9RrjilRCBiuK4QJTDcdXQ5pIXaz2I3
HOW/MjmebbTZdsQzjDmg+HJKXmZvLT2ExJMCRhoQUegTplO/yWxzjvjD7bJ5
XUfzRXMD0wDrOgISUFaw1JxicjGX8Up7jteNM7bBrdXGzxJKvlhOXLNgba0V
7wltG8gBbmzD9j56BRsXkumDI2E4woZj5mVoEwyNfAiWOcICT6E+yqTpGker
2cKKZs5WzD+aEWbLVasOu7SFJysh3CQ6SkhRraVR9gELdx59+ejwMeA9nn2M
9gP/9U70teA3ueuNe2aXnunBZ2wvNByS/QdVvPEU2UBuZ8Raa8BqNkfZ2bO1
8zSvKTkCxbQZyQSBhZSy8LBNKlpEKJB6gtaaerqsOZZeexSxjIHMF52XF1W5
XIDwQLVibm+fn7x7+69/GMImTp8dDw9HiFJDRi/QzIYE8SEQxZrTutk3hPZp
cl6bPPsgsXFp8UEMrtkidU3F0YgSrknuVFa5aKsRehCkyTLGQt3e3r7GQV/A
+ZeLT+j8gY9eLUFOACmkmi0tfZbS6m/Huf0P+LUqQUyc2f/3f0r40rguN3iR
iSa40C7xdCoew2G8LmsfL4I5L6VzBrXSPAJnCRmKnHmfMetjw0YdSYscgjSJ
zOj/A6i/bO/SCwEA
</rfc> </rfc>
 End of changes. 182 change blocks. 
1660 lines changed or deleted 465 lines changed or added

This html diff was produced by rfcdiff 1.48.