<?xmlversion='1.0' encoding='utf-8'?>version="1.0" encoding="UTF-8"?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?><!-- 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" number="9484" submissionType="IETF" category="std" consensus="true"submissionType="IETF"updates="9298" obsoletes="" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3"> <!-- xml2rfc v2v3 conversion 3.17.1 --> <front> <title>Proxying IP in HTTP</title> <seriesInfoname="Internet-Draft" value="draft-ietf-masque-connect-ip-13"/>name="RFC" value="9484"/> <author initials="T." surname="Pauly" fullname="Tommy Pauly" role="editor"> <organization>Apple Inc.</organization> <address> <email>tpauly@apple.com</email> </address> </author> <author initials="D." surname="Schinazi" fullname="David Schinazi"> <organization>Google LLC</organization> <address> <postal> <street>1600 Amphitheatre Parkway</street> <city>Mountain View</city> <region>CA</region> <code>94043</code> <country>United States of America</country> </postal> <email>dschinazi.ietf@gmail.com</email> </address> </author> <author initials="A." surname="Chernyakhovsky" fullname="Alex Chernyakhovsky"> <organization>Google LLC</organization> <address> <email>achernya@google.com</email> </address> </author> <author initials="M."surname="Kuehlewind"surname="Kühlewind" fullname="MirjaKuehlewind">Kühlewind"> <organization>Ericsson</organization> <address> <email>mirja.kuehlewind@ericsson.com</email> </address> </author> <author initials="M." surname="Westerlund" fullname="Magnus Westerlund"> <organization>Ericsson</organization> <address> <email>magnus.westerlund@ericsson.com</email> </address> </author> <date year="2023"month="April" day="28"/> <area>Transport</area> <workgroup>MASQUE</workgroup>month="October"/> <area>tsv</area> <workgroup>masque</workgroup> <keyword>quic</keyword> <keyword>http</keyword> <keyword>datagram</keyword> <keyword>VPN</keyword> <keyword>proxy</keyword> <keyword>tunnels</keyword> <keyword>quic in udp in IP in quic</keyword> <keyword>turtles all the way down</keyword> <keyword>masque</keyword> <keyword>http-ng</keyword> <abstract> <t>This document describes how to proxy IP packets in HTTP. This protocol is similar to UDP proxying inHTTP,HTTP but allows transmitting arbitrary IP packets. More specifically, this document defines a protocol that allows an HTTP client to create an IP tunnel through an HTTP server that acts as an IP proxy. This document updates RFC 9298.</t> </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/browse/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-connect-ip"/>.</t> </note></front> <middle> <section anchor="introduction"> <name>Introduction</name> <t>HTTP provides the CONNECT method (see <xref section="9.3.6" sectionFormat="of"target="HTTP"/>)target="RFC9110"/>) for creating a TCP <xreftarget="TCP"/>target="RFC9293"/> tunnel to a destination and a similar mechanism for UDP <xreftarget="CONNECT-UDP"/>.target="RFC9298"/>. However, these mechanisms cannot tunnel other 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 server acting as an IP-specific proxy over HTTP. This can be used for various usecasescases, such as remote access VPN, site-to-site VPN, secure point-to-point communication, or general-purpose packet tunnelling.</t> <t>IP proxying operates similarly to UDP proxying <xreftarget="CONNECT-UDP"/>,target="RFC9298"/>, whereby the proxy itself is identified with an absolute URL, optionally containing the traffic's destination. Clients generate these URLs using a URI Template <xreftarget="TEMPLATE"/>,target="RFC6570"/>, as described in <xref target="client-config"/>.</t> <t>This protocol supports all existing versions of HTTP by using HTTP Datagrams <xreftarget="HTTP-DGRAM"/>.target="RFC9297"/>. When using HTTP/2 <xreftarget="H2"/>target="RFC9113"/> or HTTP/3 <xreftarget="H3"/>,target="RFC9114"/>, it uses HTTP ExtendedCONNECTCONNECT, as described in <xreftarget="EXT-CONNECT2"/>target="RFC8441"/> and <xreftarget="EXT-CONNECT3"/>.target="RFC9220"/>. When using HTTP/1.x <xreftarget="H1"/>,target="RFC9112"/>, it uses HTTPUpgradeUpgrade, as defined in <xref section="7.8" sectionFormat="of"target="HTTP"/>.</t>target="RFC9110"/>.</t> <t>This document updates <xreftarget="CONNECT-UDP"/>target="RFC9298"/> to change the "masque" well-knownURI,URI; see <xref target="iana-uri"/>.</t> </section> <section anchor="conventions-and-definitions"> <name>Conventions and Definitions</name><t>The<t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> <t>In this document, we use the term "IP proxy" to refer to the HTTP server that 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 intermediaries (as defined in <xref section="3.7" sectionFormat="of"target="HTTP"/>)target="RFC9110"/>) between the client and 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> <t>This document uses terminology from <xreftarget="QUIC"/>.target="RFC9000"/>. Where this document defines protocol types, the definition format uses the notation from <xref section="1.3" sectionFormat="of"target="QUIC"/>.target="RFC9000"/>. This specification uses the variable-length integer encoding from <xref section="16" sectionFormat="of"target="QUIC"/>.target="RFC9000"/>. Variable-length integer values do not 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 streams (such as HTTP/1.1), any reference to "stream" in this document represents the entire connection.</t> </section> <section anchor="client-config"> <name>Configuration of Clients</name> <t>Clients are configured to use IP proxying over HTTP via a URI Template <xreftarget="TEMPLATE"/>.target="RFC6570"/>. The URI Template <bcp14>MAY</bcp14> contain two variables: "target" and "ipproto"; see <xref target="scope"/>. The optionality of the variables needs to be considered when defining the template so thateitherthe variable is either self-identifying orit ispossible to excludeitin the syntax.</t> <t>Examples are shown below:</t> <figure anchor="fig-template-examples"> <name>URI Template Examples</name> <artwork><![CDATA[ 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{?target,ipproto} https://masque.example.org/?user=bob ]]></artwork> </figure> <t>The following requirements apply to the URI Template:</t> <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 in absoluteform,form and <bcp14>MUST</bcp14> include non-empty scheme,authorityauthority, and path components.</li> <li>The path component of the URI Template <bcp14>MUST</bcp14> start with a slash "/".</li> <li>All template variables <bcp14>MUST</bcp14> be within the path or query components of the URI.</li> <li>The URI Template <bcp14>MAY</bcp14> contain the two variables "target" and "ipproto" and <bcp14>MAY</bcp14> contain other variables. If the "target" or "ipproto" variables are included, their values <bcp14>MUST NOT</bcp14> be empty. Clients can instead use "*" to indicate wildcard or no-preference values; see <xref target="scope"/>.</li> <li>The URI Template <bcp14>MUST NOT</bcp14> contain any non-ASCIIunicodeUnicode characters and <bcp14>MUST</bcp14> only contain ASCII characters in the range 0x21-0x7E inclusive (note that percent-encoding is allowed; seeSection 2.1 of<xreftarget="URI"/>).</li>target="RFC3986" section="2.1" sectionFormat="of" />).</li> <li>The URI Template <bcp14>MUST NOT</bcp14> use Reserved Expansion ("+" operator), Fragment Expansion ("#" operator), Label Expansion withDot- Prefix,Dot-Prefix, Path Segment Expansion with Slash-Prefix, nor Path-Style Parameter Expansion with Semicolon-Prefix.</li> </ul> <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 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 abort the request without sending it to the IP proxy.</t> <t>As with UDP proxying, some client configurations for IP proxies will only allow the user to configure the proxy host and proxy port. Clients with such limitations <bcp14>MAY</bcp14> attempt to access IP proxying capabilities using the default template, which is defined as: "https://$PROXY_HOST:$PROXY_PORT/.well-known/masque/ip/{target}/{ipproto}/", where $PROXY_HOST and $PROXY_PORT are the configured host and port of the IP proxy, respectively. IP proxy deployments <bcp14>SHOULD</bcp14> offer service at this location if they need to interoperate with such clients.</t> </section> <section anchor="tunnelling-ip-over-http"> <name>Tunnelling IP over HTTP</name> <t>To allow negotiation of a tunnel for IP over HTTP, this document defines the "connect-ip" HTTP upgrade token. The resulting IP tunnels use the Capsule Protocol (see <xref section="3.2" sectionFormat="of"target="HTTP-DGRAM"/>)target="RFC9297"/>) with HTTP Datagrams in the format defined in <xref target="payload-format"/>.</t> <t>To initiate an IP tunnel associated with a single HTTP stream, a client issues a request containing the "connect-ip" upgrade token.</t> <t>When sending its IP proxying request, the client <bcp14>SHALL</bcp14> perform URI Template expansion to determine the path and query of itsrequest,request; see <xref target="client-config"/>.</t> <t>By virtue of the definition of the Capsule Protocol (see <xref section="3.2" sectionFormat="of"target="HTTP-DGRAM"/>),target="RFC9297"/>), IP proxying requests do not carry any message content. Similarly, successful IP proxying responses also do not carry any message content.</t> <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 authentication.</t> <section anchor="ip-proxy-handling"> <name>IP Proxy Handling</name> <t>Upon receiving an IP proxying request:</t> <ul spacing="normal"><li>if<li>If the recipient is configured to use another HTTPproxy,server, it will act as an intermediary by forwarding the request toanotherthe other HTTP server. Note that 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, as the request encoding differs by version (see below).</li><li>otherwise,<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" and "ipproto" variables from the URI it has reconstructed from the request headers, decodes their percent-encoding, and establishes an IP tunnel.</li> </ul> <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 <bcp14>MUST</bcp14> treat the request as malformed; see <xref section="8.1.1" sectionFormat="of"target="H2"/>target="RFC9113"/> and <xref section="4.1.2" sectionFormat="of"target="H3"/>.target="RFC9114"/>. 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 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 appropriate Proxy-Status header field <xreftarget="PROXY-STATUS"/>.target="RFC9209"/>. For example, if DNS resolution returns an error, the proxy can use the <tt>dns_error</tt>Proxy Error Typeproxy error type from <xref section="2.3.2" sectionFormat="of"target="PROXY-STATUS"/>.</t>target="RFC9209"/>.</t> <t>The lifetime of the IP forwarding tunnel is tied to the IP proxying request stream. The IP proxy <bcp14>MUST</bcp14> maintain all IP address and route assignments 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 inactivity, but they <bcp14>MUST</bcp14> close the request stream when doing so.</t> <t>A successful IP proxying response (as defined in Sections <xref format="counter" target="resp1"/> and <xref format="counter" target="resp23"/>) indicates that the IP proxy has established an IP tunnel and is willing to proxy IP payloads. Any response other than a successful IP proxying response indicates that the request has failed; thus, the client <bcp14>MUST</bcp14> abort the request.</t> <t>Along with a successful IP proxying response, the IP proxy can send capsules to assign addresses and advertise routes to the client (<xref target="capsules"/>). The client can also assign addresses and advertise routes to the IP proxy for network-to-network routing.</t> </section> <section anchor="req1"> <name>HTTP/1.1 Request</name> <t>When using HTTP/1.1 <xreftarget="H1"/>,target="RFC9112"/>, an IP proxying request will meet the following requirements:</t> <ul spacing="normal"><li>the<li>The method <bcp14>SHALL</bcp14> be "GET".</li><li>the<li>The request <bcp14>SHALL</bcp14> include a single Host header field containing the host and optional port of the IP proxy.</li><li>the<li>The request <bcp14>SHALL</bcp14> include a Connection header field with value "Upgrade" (note that this requirement iscase-insensitivecase-insensitive, as per <xref section="7.6.1" sectionFormat="of"target="HTTP"/>).</li> <li>thetarget="RFC9110"/>).</li> <li>The request <bcp14>SHALL</bcp14> include an Upgrade header field with value "connect-ip".</li> </ul> <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 and <bcp14>SHOULD</bcp14> use the 400 (Bad Request) status code.</t> <t>For example, if the client is configured with URI Template "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 send the following request:</t> <figure anchor="fig-req-h1"> <name>Example HTTP/1.1 Request</name> <sourcecode type="http-message"><![CDATA[ GET https://example.org/.well-known/masque/ip/*/*/ HTTP/1.1 Host: example.org Connection: Upgrade Upgrade: connect-ip Capsule-Protocol: ?1 ]]></sourcecode> </figure> </section> <section anchor="resp1"> <name>HTTP/1.1 Response</name> <t>The server indicates a successful IP proxying response by replying with the following requirements:</t> <ul spacing="normal"><li>the<li>The HTTP status code on the response <bcp14>SHALL</bcp14> be 101 (Switching Protocols).</li><li>the<li>The response <bcp14>SHALL</bcp14> include a Connection header field with value "Upgrade" (note that this requirement iscase-insensitivecase-insensitive, as per <xref section="7.6.1" sectionFormat="of"target="HTTP"/>).</li> <li>thetarget="RFC9110"/>).</li> <li>The response <bcp14>SHALL</bcp14> include a single Upgrade header field with value "connect-ip".</li><li>the<li>The response <bcp14>SHALL</bcp14> meet the requirements of HTTP responses that start the Capsule Protocol; see <xref section="3.2" sectionFormat="of"target="HTTP-DGRAM"/>.</li>target="RFC9297"/>.</li> </ul> <t>If any of these requirements are not met, the client <bcp14>MUST</bcp14> treat this proxying attempt as failed and close the connection.</t> <t>For example, the server could respond with:</t> <figure anchor="fig-resp-h1"> <name>Example HTTP/1.1 Response</name> <sourcecode type="http-message"><![CDATA[ HTTP/1.1 101 Switching Protocols Connection: Upgrade Upgrade: connect-ip Capsule-Protocol: ?1 ]]></sourcecode> </figure> </section> <section anchor="req23"> <name>HTTP/2 and HTTP/3 Requests</name> <t>When using HTTP/2 <xreftarget="H2"/>target="RFC9113"/> or HTTP/3 <xreftarget="H3"/>,target="RFC9114"/>, IP proxying requests use HTTP Extended CONNECT. This requires that servers send an HTTPSettingSetting, as specified in <xreftarget="EXT-CONNECT2"/>target="RFC8441"/> and <xreftarget="EXT-CONNECT3"/>target="RFC9220"/>, and that requests use HTTP pseudo-header fields with the following requirements:</t> <ul spacing="normal"> <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 :authority pseudo-header field <bcp14>SHALL</bcp14> contain the authority of the IP proxy.</li> <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 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 requesting full-tunnel IP packet forwarding, or a specific proxied flow; see <xref target="scope"/>.</li> </ul> <t>An IP proxying request that does not conform to these restrictions is malformed; see <xref section="8.1.1" sectionFormat="of"target="H2"/>target="RFC9113"/> and <xref section="4.1.2" sectionFormat="of"target="H3"/>.</t>target="RFC9114"/>.</t> <t>For example, if the client is configured with URI Template "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 send the following request:</t> <figure anchor="fig-req-h2"> <name>Example HTTP/2 or HTTP/3 Request</name> <sourcecode type="http-message"><![CDATA[ HEADERS :method = CONNECT :protocol = connect-ip :scheme = https :path = /.well-known/masque/ip/*/*/ :authority = example.org capsule-protocol = ?1 ]]></sourcecode> </figure> </section> <section anchor="resp23"> <name>HTTP/2 and HTTP/3 Responses</name> <t>The server indicates a successful IP proxying response by replying with the following requirements:</t> <ul spacing="normal"><li>the<li>The HTTP status code on the response <bcp14>SHALL</bcp14> be in the 2xx (Successful) range.</li><li>the<li>The response <bcp14>SHALL</bcp14> meet the requirements of HTTP responses that start the Capsule Protocol; see <xref section="3.2" sectionFormat="of"target="HTTP-DGRAM"/>.</li>target="RFC9297"/>.</li> </ul> <t>If any of these requirements are not met, the client <bcp14>MUST</bcp14> treat this proxying 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 request.</t> <t>For example, the server could respond with:</t> <figure anchor="fig-resp-h2"> <name>Example HTTP/2 or HTTP/3 Response</name> <sourcecode type="http-message"><![CDATA[ HEADERS :status = 200 capsule-protocol = ?1 ]]></sourcecode> </figure> </section> <section anchor="scope"> <name>Limiting Request Scope</name> <t>Unlike UDP proxying requests, which require specifying a target host, IP proxying requests can allow endpoints to send arbitrary IP packets to any host. The client can choose to restrict a given request to a specific IP prefix or IP protocol by adding parameters to its request. When the IP proxy knows that a request is scoped to a target prefix or protocol, it can leverage this information to optimize its resource allocation; for example, the IP proxy can assign the same public IP address to two IP proxying requests that are scoped to different prefixes and/or different protocols.</t> <t>The scope of the request is indicated by the client to the IP proxy via the "target" and "ipproto" variables of the URI Template; see <xref target="client-config"/>. Both the "target" and "ipproto" variables are optional; if they are not included, they are considered to carry the wildcard value "*".</t> <dlspacing="compact">spacing="normal" newline="true"> <dt>target:</dt> <dd> <t>The variable "target" contains a hostname or IP prefix of a specific host to 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 any allowable host. "target" supports using DNS names, IPv6prefixesprefixes, and IPv4 prefixes. Note that IPv6 scoped addressing zone identifiers(<xref target="RFC6874"/>)<xref target="RFC6874"/> are 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 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 advertise to the client. The IP proxy <bcp14>SHOULD</bcp14> send a ROUTE_ADVERTISEMENT capsule 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 for which the IP proxy also sends an Assigned Address.</t> </dd> <dt>ipproto:</dt> <dd> <t>The variable "ipproto" contains anIP protocol number, asInternet Protocol Number; see the defined list in the "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 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" variable represents an allowable next header value carried in IP headers that are directly sent in HTTPdatagramsDatagrams (the outermost IP headers). ICMP traffic is always allowed, regardless of the value of this field.</t> </dd> </dl> <t>Using the terms IPv6address, IPv4address, and reg-name from <xreftarget="URI"/>,target="RFC3986"/>, the "target" and "ipproto" variables <bcp14>MUST</bcp14> adhere to the format in <xref target="target-format"/>, using notation from <xreftarget="ABNF"/>.target="RFC5234"/>. Additionally:</t> <ul spacing="normal"><li>if<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 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 percent-encoded slash ("/"): "%2F". The IP prefix length <bcp14>MUST</bcp14> represent a 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 strictly less than 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> <li>"ipproto" <bcp14>MUST</bcp14> represent a decimal integer between 0 and 255inclusive,inclusive or the wildcard value "*".</li> </ul> <figure anchor="target-format"> <name>URI Template Variable Format</name> <artwork type="ascii-art"><![CDATA[ target = IPv6prefix / IPv4prefix / reg-name / "*" IPv6prefix = IPv6address ["%2F" 1*3DIGIT] IPv4prefix = IPv4address ["%2F" 1*2DIGIT] ipproto = 1*3DIGIT / "*" ]]></artwork> </figure> <t>IP proxies <bcp14>MAY</bcp14> perform access control using the scoping information provided by theclient:client, i.e., if the client is not authorized to access any of the destinations included in the scope, then the IP proxy can immediatelyfailreject the request.</t> </section> <section anchor="capsules"> <name>Capsules</name> <t>This document defines multiple new capsule types that allow endpoints to exchange IP configuration information. Both endpoints <bcp14>MAY</bcp14> send any number of these new capsules.</t> <section anchor="addressassign-capsule"> <name>ADDRESS_ASSIGN Capsule</name> <t>The ADDRESS_ASSIGN capsule(see <xref target="iana-types"/> for the value of the capsule type)(capsule type 0x01) allows an endpoint toinformassign its peerof thea list of IP addresses orprefixes it has assigned to it.prefixes. Every capsule contains the full list of IP 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> <figure anchor="addr-assign-format"> <name>ADDRESS_ASSIGN Capsule Format</name> <artwork><![CDATA[ ADDRESS_ASSIGN Capsule { Type (i) =ADDRESS_ASSIGN,0x01, Length (i), Assigned Address (..) ..., } ]]></artwork> </figure> <t>The ADDRESS_ASSIGN capsule contains a sequence of zero or more Assigned Addresses.</t> <figure anchor="assigned-addr-format"> <name>Assigned Address Format</name> <artwork><![CDATA[ Assigned Address { Request ID (i), IP Version (8), IP Address (32..128), IP Prefix Length (8), } ]]></artwork> </figure> <t>Each Assigned Address contains the following fields:</t> <dlspacing="compact">spacing="normal" newline="true"> <dt>Request ID:</dt> <dd> <t>Request identifier, encoded as a variable-length integer. If this address 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 request. Otherwise, this field <bcp14>SHALL</bcp14> be zero.</t> </dd> <dt>IP Version:</dt> <dd> <t>IP Version of this address assignment, encoded as an unsigned 8-bit integer. It <bcp14>MUST</bcp14> be either 4 or 6.</t> </dd> <dt>IP Address:</dt> <dd> <t>Assigned 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 IP Address field <bcp14>SHALL</bcp14> have a length of 128 bits.</t> </dd> <dt>IP Prefix Length:</dt> <dd> <t>The number of bits in the IP address that are used to define the prefix that 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 Addressfield,field in bits. If the prefix length 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 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 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 <bcp14>MUST</bcp14> all be set to 0.</t> </dd> </dl> <t>If any of the capsule fields are malformed upon reception, the receiver of the capsule <bcp14>MUST</bcp14> follow theerror handlingerror-handling procedure defined in <xref section="3.3" sectionFormat="of"target="HTTP-DGRAM"/>.</t>target="RFC9297"/>.</t> <t>If an ADDRESS_ASSIGN capsule does not contain an address that was previously transmitted in another ADDRESS_ASSIGN capsule,thatit indicates that the address has been removed. An ADDRESS_ASSIGN capsule can also be empty, indicating that all addresses have been removed.</t> <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 packets. For example, in theRemote Accessremote access VPN case (<xreftarget="example-remote"/>)target="example-remote"/>), the client cannot send IP packets until it knows what address to use. In these deployments, the endpoint that is expecting an address assignment <bcp14>MUST</bcp14> send an ADDRESS_REQUEST capsule. This isn't required if the endpoint does not need any address assignment, forexampleexample, when it is configured out-of-band with static addresses.</t> <t>While ADDRESS_ASSIGN capsules are commonly sent in response to ADDRESS_REQUEST capsules, endpoints <bcp14>MAY</bcp14> send ADDRESS_ASSIGN capsules unprompted.</t> </section> <section anchor="addr_req"> <name>ADDRESS_REQUEST Capsule</name> <t>The ADDRESS_REQUEST capsule(see <xref target="iana-types"/> for the value of the capsule type)(capsule type 0x02) allows an endpoint to request assignment of IP addresses from its peer. The capsule allows the endpoint to optionally indicate a preference for which address it would get assigned.</t> <figure anchor="addr-req-format"> <name>ADDRESS_REQUEST Capsule Format</name> <artwork><![CDATA[ ADDRESS_REQUEST Capsule { Type (i) =ADDRESS_REQUEST,0x02, Length (i), Requested Address (..) ..., } ]]></artwork> </figure> <t>The ADDRESS_REQUEST capsule contains a sequence of one or more Requested Addresses.</t> <figure anchor="requested-addr-format"> <name>Requested Address Format</name> <artwork><![CDATA[ Requested Address { Request ID (i), IP Version (8), IP Address (32..128), IP Prefix Length (8), } ]]></artwork> </figure> <t>Each Requested Address contains the following fields:</t> <dlspacing="compact">spacing="normal" newline="true"> <dt>Request ID:</dt> <dd> <t>Request identifier, encoded as a variable-length integer. This is the 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 anendpoint,endpoint and <bcp14>MUST NOT</bcp14> be zero.</t> </dd> <dt>IP Version:</dt> <dd> <t>IP Version of this address request, encoded as an unsigned 8-bit integer. It <bcp14>MUST</bcp14> be either 4 or 6.</t> </dd> <dt>IP Address:</dt> <dd> <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 IP Address field <bcp14>SHALL</bcp14> have a length of 128 bits.</t> </dd> <dt>IP Prefix Length:</dt> <dd> <t>Length of the IP Prefixrequested,requested in bits, encoded as an unsigned 8-bit integer. It <bcp14>MUST</bcp14> be less than or equal to the length of the IP Addressfield,field in 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 prefix length <bcp14>MUST</bcp14> all be set to 0.</t> </dd> </dl> <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 for a specific address. In that scenario, the prefix length still indicates the sender's preference for the prefix length it is requesting.</t> <t>If any of the capsule fields are malformed upon reception, the receiver of the capsule <bcp14>MUST</bcp14> follow theerror handlingerror-handling procedure defined in <xref section="3.3" sectionFormat="of"target="HTTP-DGRAM"/>.</t>target="RFC9297"/>.</t> <t>Upon receiving the ADDRESS_REQUEST capsule, an endpoint <bcp14>SHOULD</bcp14> assign one or more IP addresses to itspeer,peer and then respond with an ADDRESS_ASSIGN capsule 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 Address with a 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 assigned values. If the requested address was not assigned, the IP address <bcp14>SHALL</bcp14> beall-zeroall-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 rejections <bcp14>SHOULD NOT</bcp14> be included in subsequent ADDRESS_ASSIGN capsules. Note that other Assigned Address entries that do not correspond to any Request ID can also be contained in the same ADDRESS_ASSIGN response.</t> <t>If an endpoint receives an ADDRESS_REQUEST capsule that contains zero Requested Addresses, it <bcp14>MUST</bcp14> abort the IP proxying request stream.</t> <t>Note that the ordering of Requested Addresses does not carry any semantics. Similarly, the Request ID is only meant as a uniqueidentifier,identifier; it does not convey any priority or importance.</t> </section> <section anchor="route-adv"> <name>ROUTE_ADVERTISEMENT Capsule</name> <t>The ROUTE_ADVERTISEMENT capsule(see <xref target="iana-types"/> for the value of the capsule type)(capsule type 0x03) 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 has an existing route to each addressrange,range and notifies its peerthatthat, if the 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 preexisting route. Any addresswhichthat is in one of the address ranges can be used as the destination address on IP packets originated by the receiver of this capsule.</t> <figure anchor="route-adv-format"> <name>ROUTE_ADVERTISEMENT Capsule Format</name> <artwork><![CDATA[ ROUTE_ADVERTISEMENT Capsule { Type (i) =ROUTE_ADVERTISEMENT,0x03, Length (i), IP Address Range (..) ..., } ]]></artwork> </figure> <t>The ROUTE_ADVERTISEMENT capsule contains a sequence of zero or more IP Address Ranges.</t> <figure anchor="addr-range-format"> <name>IP Address Range Format</name> <artwork><![CDATA[ IP Address Range { IP Version (8), Start IP Address (32..128), End IP Address (32..128), IP Protocol (8), } ]]></artwork> </figure> <t>Each IP Address Range contains the following fields:</t> <dlspacing="compact">spacing="normal" newline="true"> <dt>IP Version:</dt> <dd> <t>IP Version of this range, encoded as an unsigned 8-bit integer. It <bcp14>MUST</bcp14> be either 4 or 6.</t> </dd> <dt>Start IP Address and End IP Address:</dt> <dd> <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. If the IP Version field has value 6, these fields <bcp14>SHALL</bcp14> have a length of 128 bits. The Start IP Address <bcp14>MUST</bcp14> be less than or equal to the End IP Address.</t> </dd> <dt>IP Protocol:</dt> <dd> <t>The Internet Protocol Number for traffic that can be sent to this range, 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 carried in IP headers that aredirectlysent directly in HTTPdatagramsDatagrams (the outermost IP headers). ICMP traffic is always allowed, regardless of the value of this field.</t> </dd> </dl> <t>If any of the capsule fields are malformed upon reception, the receiver of the capsule <bcp14>MUST</bcp14> follow theerror handlingerror-handling procedure defined in <xref section="3.3" sectionFormat="of"target="HTTP-DGRAM"/>.</t>target="RFC9297"/>.</t> <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 policy), such as by installing entries in a routing table.</t> <t>Each ROUTE_ADVERTISEMENT contains the full list of address ranges. If multiple ROUTE_ADVERTISEMENT capsules are sent in one direction, each 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 ROUTE_ADVERTISEMENT capsule does not contain it, the receiver will consider that range withdrawn.</t> <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 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 in the same ROUTE_ADVERTISEMENT capsule, they <bcp14>MUST</bcp14> follow these requirements:</t> <ul spacing="normal"><li>IP<li>The IP Version of A <bcp14>MUST</bcp14> be less than or equal to the IP Version ofB</li>B.</li> <li>If the IP Version of A and B are equal, the IP Protocol of A <bcp14>MUST</bcp14> be less 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 Address of A <bcp14>MUST</bcp14> be strictly less than the Start IP Address of B.</li> </ul> <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> <t>Since setting the IP protocol to zero indicates all protocols are allowed, the requirements above make it possible for two routes to overlap when one has its IP 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 this requirement is <bcp14>OPTIONAL</bcp14>, but if an endpoint detects the violation, it <bcp14>MUST</bcp14> abort the IP proxying request stream.</t> </section> </section> <section anchor="ipv6-extension-headers"> <name>IPv6 Extension Headers</name> <t>Both request scoping (see <xref target="scope"/>) and the ROUTE_ADVERTISEMENT capsule (see <xref target="route-adv"/>) useIP protocol numbers.Internet Protocol Numbers. These numbers represent both upper layers (as defined in <xref section="2" sectionFormat="of"target="IPv6"/>,target="RFC8200"/>, with examples that include TCP and UDP) and IPv6 extension headers (as defined in <xref section="4" sectionFormat="of"target="IPv6"/>,target="RFC8200"/>, with examples that include Fragment and Options headers). IP proxies <bcp14>MAY</bcp14> reject requests to scope to protocol numbers that are used for extension headers. Upon receiving packets, implementations that support scoping or routing byIP protocol numberInternet Protocol Number <bcp14>MUST</bcp14> walk the chain of extensions to find the outermost non-extensionIP protocol numberInternet Protocol Number to match against the scoping rule. Note that the ROUTE_ADVERTISEMENT capsule usesIP protocol numberInternet Protocol Number 0 to indicate that all protocols areallowed,allowed; it does not restrict the route to the IPv6 Hop-by-Hop OptionsHeaderheader (<xref section="4.3" sectionFormat="of"target="IPv6"/>).</t>target="RFC8200"/>).</t> </section> </section> <section anchor="context-identifiers"> <name>Context Identifiers</name> <t>The mechanism for proxying IP in HTTP defined in this document allows future extensions to exchange HTTP Datagrams that carry different semantics from IP payloads. Some of these extensions can augment IP payloads with additional data or compress IP header fields, while others can exchange data that is completely separate from IP payloads. In order to accomplish this, all HTTP Datagrams associated with IP proxying request streams start with a Context ID field; see <xref target="payload-format"/>.</t> <t>Context IDs are 62-bit integers (0 to 2<sup>62</sup>-1). Context IDs are encoded as variable-length integers; see <xref section="16" sectionFormat="of"target="QUIC"/>.target="RFC9000"/>. The Context ID 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 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 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 request but <bcp14>MAY</bcp14> be allocated in any order. The Context ID allocation 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 Context ID has been allocated, those restrictions do not apply to the use of the Context ID; it can be used by either the client or the IP proxy, independent of which endpoint initially allocated it.</t> <t>Registration is the action by which an endpoint informs its peer of the semantics and format of a given Context ID. This document does not define how registration occurs. Future extensions <bcp14>MAY</bcp14> use HTTP header fields or capsules to register Context IDs. Depending on the method being used, it is possible for datagrams to be received with Context IDs that have not yet been registered. For instance, this can be due to reordering of the packet containing the datagram and the packet containing the registration message during transmission.</t> </section> <section anchor="payload-format"> <name>HTTP Datagram Payload Format</name> <t>When associated with IP proxying request streams, the HTTP Datagram Payload field of HTTP Datagrams (see <xreftarget="HTTP-DGRAM"/>)target="RFC9297"/>) has the format defined in <xref target="dgram-format"/>. Notethatthat, when HTTP Datagrams are encoded using QUIC DATAGRAM frames, the Context ID field defined below directly follows the Quarter Stream ID fieldwhichthat is at the start of the QUIC DATAGRAM frame payload:</t> <figure anchor="dgram-format"> <name>IP Proxying HTTP Datagram Format</name> <artwork><![CDATA[ IP Proxying HTTP Datagram Payload { Context ID (i), Payload (..), } ]]></artwork> </figure> <t>The IP Proxying HTTP Datagram Payload contains the following fields:</t> <dlspacing="compact">spacing="normal" newline="true"> <dt>Context ID:</dt> <dd> <t>A variable-length integer that contains the value of the Context ID. If an HTTP/3 datagramwhichthat carries an unknown Context ID is received, the receiver <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 ID.</t> </dd> <dt>Payload:</dt> <dd> <t>The payload of the datagram, whose semantics depend on value of the previous field. Note that this field can be empty.</t> </dd> </dl> <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 (from the IP Version field until the last byte of the IPPayload).</t>payload).</t> </section> <section anchor="ip-packet-handling"> <name>IP Packet Handling</name> <t>This document defines a tunneling mechanism that is conceptually an IP link. 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 them to anotherimplementationimplementation, such as a kernel.</t> <section anchor="link-operation"> <name>Link Operation</name> <t>The IP forwarding tunnels described in this document are not fully featured "interfaces" in the IPv6 addressing architecture sense <xreftarget="IPv6-ADDR"/>.target="RFC4291"/>. In particular, they do not necessarily have IPv6 link-local addresses. Additionally, IPv6 stateless autoconfiguration or router advertisement messages are not used in such interfaces, and neither is neighbor discovery.</t><t>Clients<t>When using HTTP/2 or HTTP/3, a client <bcp14>MAY</bcp14> optimistically start sending proxied IP packets before receiving the response to its IP proxying request, noting however that those may not be processed by the IP proxy if it responds to the request with afailure,failure or if the datagrams are received by the IP proxy before the request. Since receiving addresses and routes is required in order to know that a packet can be sent through the tunnel, such optimistic packets might be dropped by the IP proxy if it chooses to provide different addressing or routing information than what the client assumed.</t> <t>Note that it is possible for multiple proxied IP packets to be encapsulated in the same outer packet, forexampleexample, because a QUIC packet can carrytwomore than one QUIC DATAGRAMframes.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 TCP packets.</t> </section> <section anchor="routing-operation"> <name>Routing Operation</name> <t>The requirements in this section are a repetition of requirements that apply to IP routers ingeneral,general and might not apply to implementations of IP proxying that rely on external software for routing.</t> <t>When an endpoint receives an HTTP Datagram containing an IP packet, it will parse the packet's IP header, perform any local policy checks (e.g., source address validation), check their routing table to pick an outbound interface, and then send the IP packet on that interface or pass it to a local application. The endpoint can also choose to drop any received packets instead of forwarding them. If a received IP packet fails any correctness or policy checks, that is a forwarding error, not a protocolviolationviolation, as far as IP 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> <t>In the other direction, when an endpoint receives an IP packet, it checks to see if the packet matches the routes mapped for an IPtunnel,tunnel and performs the same forwarding checks as above before transmitting the packet over HTTP Datagrams.</t> <t>When IP proxying endpoints forward IP packets between different links, they will decrement the IP Hop Count (or TTL) uponencapsulation,encapsulation but not upon decapsulation. In other words, the Hop Count is decremented right before an IP packet is transmitted in an HTTP Datagram. This prevents infinite loops in the presence of routingloops,loops and matches the choices in IPsec <xreftarget="IPSEC"/>.target="RFC4301"/>. 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 traffic 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 addresses.</t> <t>IPv6 requires that every link have an MTU of at least 1280 bytes <xreftarget="IPv6"/>.target="RFC8200"/>. Since IP proxying in HTTP conveys IP packets in HTTP Datagrams and those can in turn be sent in QUIC DATAGRAM frameswhichthat cannot be fragmented <xreftarget="DGRAM"/>,target="RFC9221"/>, the MTU of an IP tunnel can be limited by the MTU of the 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 as routers and support IPv6 <bcp14>MUST</bcp14> ensure that the IP tunnel link MTU is at least 1280 bytes (i.e., that they can send HTTP Datagrams with payloads of at least 1280 bytes). This can be accomplished using various techniques:</t> <ul spacing="normal"><li>if<li>If both IP proxying endpoints know for certain that HTTP intermediaries are 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 in use, the overhead is 1 byte for the type, 20 bytes for the maximal connection ID length, 4 bytes for the maximal packet number length, 1 byte for the DATAGRAM frame type, 8 bytes for the maximalquarter streamQuarter Stream ID,one1 byte for the zero Context ID, and 16 bytes for theAEADAuthenticated Encryption with Associated Data (AEAD) authentication tag, for a total of 51 bytes ofoverheadoverhead, which 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 data to ascertain the link MTU and tear down the tunnel if they do not receive a response. Unless endpoints have an out-of-band means of guaranteeing that the previous techniquesisare sufficient, they <bcp14>MUST</bcp14> use this method. If an endpoint does not know an IPv6 address of its peer, it can send the ICMPv6 echo request to thelink locallink-local all nodes multicast address (ff02::1).</li> </ul> <t>If an endpoint is using QUIC DATAGRAM frames to convey IPv6packets,packets and it detects that the QUIC MTU is too low to allow sending 1280 bytes, it <bcp14>MUST</bcp14> abort the IP proxying request stream.</t> <section anchor="error-signal"> <name>Error Signalling</name> <t>Since IP proxying endpoints often forward IP packets onwards to other network interfaces, they need to handle errors in the forwarding process. For example, forwarding can fail if the endpoint does not have a route for the destination address,orif it is configured to reject a destination prefix by policy, or if the MTU of the outgoing link is lower than the size of the packet to be forwarded. In such scenarios, IP proxying endpoints <bcp14>SHOULD</bcp14> use ICMP <xreftarget="ICMP"/>target="RFC0792"/> <xreftarget="ICMPv6"/>target="RFC4443"/> to signal the forwarding error to its peer by generating ICMP packets and sending them using HTTP Datagrams.</t> <t>Endpoints are free to select the most appropriate ICMP errors to send. Some examples that are relevant for IP proxyinginclude:</t>include the following:</t> <ul spacing="normal"> <li>For invalid source addresses, send Destination Unreachable (<xref section="3.1" sectionFormat="of"target="ICMPv6"/>)target="RFC4443"/>) with code 5, "Source address failed ingress/egress policy".</li> <li>For unroutable destination addresses, send Destination Unreachable (<xref section="3.1" sectionFormat="of"target="ICMPv6"/>)target="RFC4443"/>) withacode 0, "No route to destination", or code 1, "Communication with destination administratively prohibited".</li> <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>target="RFC4443"/>).</li> </ul> <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 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 can originate from a source address different from that of the IP proxyingpeer,peer and also from outside the target if scoping is in use (see <xref target="scope"/>).</t> </section> </section> </section> <section anchor="examples"> <name>Examples</name> <t>IP proxying in HTTP enables many different use cases that can benefit from IP packet proxying and tunnelling. These examples are provided to help illustrate some of the ways in which IP proxying in HTTP can be used.</t> <section anchor="example-remote"> <name>Remote Access VPN</name> <t>The following example shows a point-to-network VPN setup, where a client receives a set of localaddresses,addresses and can send to any remote host through the IP proxy. Such VPN setups can be either full-tunnel or split-tunnel.</t> <figure anchor="diagram-tunnel"> <name>VPN Tunnel Setup</name> <artset> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1"height="128" width="512"viewBox="0 0512768 128" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px"> <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 248,32 L 248,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 8,32 L 80,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 80,48 L 248,48" fill="none" stroke="black"/> <path d="M 192,64 L 216,64" fill="none" stroke="black"/> <path d="M 320,64 L 448,64" fill="none" stroke="black"/> <path d="M 80,80 L 248,80" fill="none" stroke="black"/> <path d="M 8,96 L 80,96" fill="none" stroke="black"/> <path d="M 248,96 L 320,96" fill="none" stroke="black"/> <path d="M 416,96 L 448,96" fill="none" stroke="black"/> <polygon class="arrowhead" points="456,96 444,90.4 444,101.6" fill="black" transform="rotate(0,448,96)"/> <polygon class="arrowhead" points="456,64 444,58.4 444,69.6" fill="black" transform="rotate(0,448,64)"/> <polygon class="arrowhead" points="456,32 444,26.4 444,37.6" fill="black" transform="rotate(0,448,32)"/> <polygon class="arrowhead" points="224,64 212,58.4 212,69.6" fill="black" transform="rotate(0,216,64)"/> <polygon class="arrowhead" points="200,64 188,58.4 188,69.6" fill="black" transform="rotate(180,192,64)"/> <g class="text"> <text x="100" y="36">IP</text> <text x="120" y="36">A</text> <text x="212" y="36">IP</text> <text x="232" y="36">B</text> <text x="468" y="36">IP</text> <text x="488" y="36">D</text> <text x="284" y="52">IP</text> <text x="340" y="52">IP</text> <text x="360" y="52">C</text> <text x="44" y="68">Client</text> <text x="100" y="68">IP</text> <text x="140" y="68">Subnet</text> <text x="176" y="68">C</text> <text x="232" y="68">?</text> <text x="288" y="68">Proxy</text> <text x="468" y="68">IP</text> <text x="488" y="68">E</text> <text x="468" y="100">IP</text> <text x="496" y="100">...</text> </g> </svg> </artwork> <artwork type="ascii-art"><![CDATA[ +--------+ IP A IP B +--------+ +---> IP D | +--------------------+ IP | IP C | | Client | IP Subnet C <--> ? | Proxy +-----------+---> IP E | +--------------------+ | | +--------+ +--------+ +---> IP ... ]]></artwork> </artset> </figure> <t>In this case, the client does not specify any scope in its request. The IP proxy assigns the client an IPv4 address (192.0.2.11) and a full-tunnel route of all IPv4 addresses (0.0.0.0/0). The client can then send to any IPv4 host using its assigned address as its source address.</t> <figure anchor="fig-full-tunnel"> <name>VPN Full-Tunnel Example</name> <artwork><![CDATA[ [[ From Client ]] [[ From IP Proxy ]] SETTINGS H3_DATAGRAM = 1 SETTINGS ENABLE_CONNECT_PROTOCOL = 1 H3_DATAGRAM = 1 STREAM(44): HEADERS :method = CONNECT :protocol = connect-ip :scheme = https :path = /vpn :authority = proxy.example.com capsule-protocol = ?1 STREAM(44): HEADERS :status = 200 capsule-protocol = ?1 STREAM(44): DATA Capsule Type = ADDRESS_REQUEST (Request ID = 1 IP Version = 4 IP Address = 0.0.0.0 IP Prefix Length = 32) STREAM(44): DATA Capsule Type = ADDRESS_ASSIGN (Request ID = 1 IP Version = 4 IP Address = 192.0.2.11 IP Prefix Length = 32) STREAM(44): DATA Capsule Type = ROUTE_ADVERTISEMENT (IP Version = 4 Start IP Address = 0.0.0.0 End IP Address = 255.255.255.255 IP Protocol = 0) // Any DATAGRAM Quarter Stream ID = 11 Context ID = 0 Payload = Encapsulated IP Packet DATAGRAM Quarter Stream ID = 11 Context ID = 0 Payload = Encapsulated IP Packet ]]></artwork> </figure> <t>A setup for a split-tunnel VPN (the case where the client can only access a specific set of private subnets) is quite similar. In this case, the advertised route is restricted to 192.0.2.0/24, rather than 0.0.0.0/0.</t> <figure anchor="fig-split-tunnel"> <name>VPN Split-Tunnel Example</name> <artwork><![CDATA[ [[ From Client ]] [[ From IP Proxy ]] STREAM(44): DATA Capsule Type = ADDRESS_ASSIGN (Request ID = 0 IP Version = 4 IP Address = 192.0.2.42 IP Prefix Length = 32) STREAM(44): DATA Capsule Type = ROUTE_ADVERTISEMENT (IP Version = 4 Start IP Address = 192.0.2.0 End IP Address = 192.0.2.41 IP Protocol = 0) // Any (IP Version = 4 Start IP Address = 192.0.2.43 End IP Address = 192.0.2.255 IP Protocol = 0) // Any ]]></artwork> </figure> </section> <section anchor="site-to-site-vpn"> <name>Site-to-Site VPN</name> <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 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 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 IPProxyproxy is provisioned with an IP address from that subnet.</t> <figure anchor="diagram-s2s"><name>Site-to-site<name>Site-to-Site VPN Example</name> <artset> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1"height="128" width="560"viewBox="0 0560700 128" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px"> <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 216,32 L 216,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 424,32 L 424,96" 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 328,32 L 392,32" fill="none" stroke="black"/> <path d="M 424,32 L 456,32" fill="none" stroke="black"/> <path d="M 216,48 L 328,48" fill="none" stroke="black"/> <path d="M 88,64 L 144,64" fill="none" stroke="black"/> <path d="M 392,64 L 456,64" fill="none" stroke="black"/> <path d="M 216,80 L 328,80" fill="none" stroke="black"/> <path d="M 88,96 L 112,96" fill="none" stroke="black"/> <path d="M 144,96 L 216,96" fill="none" stroke="black"/> <path d="M 328,96 L 392,96" fill="none" stroke="black"/> <path d="M 424,96 L 456,96" fill="none" stroke="black"/> <polygon class="arrowhead" points="464,96 452,90.4 452,101.6" fill="black" transform="rotate(0,456,96)"/> <polygon class="arrowhead" points="464,64 452,58.4 452,69.6" fill="black" transform="rotate(0,456,64)"/> <polygon class="arrowhead" points="464,32 452,26.4 452,37.6" fill="black" transform="rotate(0,456,32)"/> <polygon class="arrowhead" points="96,96 84,90.4 84,101.6" fill="black" transform="rotate(180,88,96)"/> <polygon class="arrowhead" points="96,64 84,58.4 84,69.6" fill="black" transform="rotate(180,88,64)"/> <polygon class="arrowhead" points="96,32 84,26.4 84,37.6" fill="black" transform="rotate(180,88,32)"/> <g class="text"> <text x="40" y="36">192.0.2.1</text> <text x="512" y="36">203.0.113.9</text> <text x="356" y="52">IP</text> <text x="40" y="68">192.0.2.2</text> <text x="180" y="68">Client</text> <text x="236" y="68">IP</text> <text x="284" y="68">Proxying</text> <text x="360" y="68">Proxy</text> <text x="512" y="68">203.0.113.8</text> <text x="40" y="100">192.0.2.3</text> <text x="512" y="100">203.0.113.7</text> </g> </svg> </artwork> <artwork type="ascii-art"><![CDATA[ 192.0.2.1 <--+ +--------+ +-------+ +---> 203.0.113.9 | | +-------------+ IP | | 192.0.2.2 <--+---+ Client | IP Proxying | Proxy +---+---> 203.0.113.8 | | +-------------+ | | 192.0.2.3 <--+ +--------+ +-------+ +---> 203.0.113.7 ]]></artwork> </artset> </figure> <t>In this case, the client does not specify any scope in its request. The IP 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 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 communicate with eachother,other and allows the IP proxy to perform maintenance on legacy hosts in the branch office. Note that IP proxying endpoints will 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> <figure anchor="fig-s2s"><name>Site-to-site<name>Site-to-Site VPN Capsule Example</name> <artwork><![CDATA[ [[ From Client ]] [[ From IP Proxy ]] SETTINGS H3_DATAGRAM = 1 SETTINGS ENABLE_CONNECT_PROTOCOL = 1 H3_DATAGRAM = 1 STREAM(44): HEADERS :method = CONNECT :protocol = connect-ip :scheme = https :path = /corp :authority = proxy.example.com capsule-protocol = ?1 STREAM(44): HEADERS :status = 200 capsule-protocol = ?1 STREAM(44): DATA Capsule Type = ADDRESS_ASSIGN (Request ID = 0 IP Version = 4 IP Address = 192.0.2.200 IP Prefix Length = 32) STREAM(44): DATA Capsule Type = ROUTE_ADVERTISEMENT (IP Version = 4 Start IP Address = 192.0.2.0 End IP Address = 192.0.2.255 IP Protocol = 0) // Any STREAM(44): DATA Capsule Type = ADDRESS_ASSIGN (Request ID = 0 IP Version = 4 IP Address = 203.0.113.100 IP Prefix Length = 32) STREAM(44): DATA Capsule Type = ROUTE_ADVERTISEMENT (IP Version = 4 Start IP Address = 203.0.113.0 End IP Address = 203.0.113.255 IP Protocol = 0) // Any DATAGRAM Quarter Stream ID = 11 Context ID = 0 Payload = Encapsulated IP Packet DATAGRAM Quarter Stream ID = 11 Context ID = 0 Payload = Encapsulated IP Packet ]]></artwork> </figure> </section> <section anchor="ip-flow-forwarding"> <name>IP Flow Forwarding</name> <t>The following example shows an IP flow forwarding setup, where a client requests to establish a forwarding tunnel to target.example.com usingSCTPthe Stream Control Transmission Protocol (SCTP) (IP protocol132),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 protocol that isn't easily proxied with existing HTTP methods, such as ICMP,ESP,Encapsulating Security Payload (ESP), etc.</t> <figure anchor="diagram-flow"> <name>Proxied Flow Setup</name> <artset> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1"height="128" width="440"viewBox="0 0440660 128" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px"> <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 240,32 L 240,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 240,32 L 312,32" 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 312,64 L 392,64" fill="none" stroke="black"/> <path d="M 80,80 L 240,80" fill="none" stroke="black"/> <path d="M 8,96 L 80,96" fill="none" stroke="black"/> <path d="M 240,96 L 312,96" fill="none" stroke="black"/> <polygon class="arrowhead" points="400,64 388,58.4 388,69.6" fill="black" transform="rotate(0,392,64)"/> <polygon class="arrowhead" points="192,64 180,58.4 180,69.6" fill="black" transform="rotate(0,184,64)"/> <polygon class="arrowhead" points="168,64 156,58.4 156,69.6" fill="black" transform="rotate(180,160,64)"/> <g class="text"> <text x="100" y="36">IP</text> <text x="120" y="36">A</text> <text x="204" y="36">IP</text> <text x="224" y="36">B</text> <text x="276" y="52">IP</text> <text x="332" y="52">IP</text> <text x="352" y="52">C</text> <text x="44" y="68">Client</text> <text x="124" y="68">IP</text> <text x="144" y="68">C</text> <text x="200" y="68">D</text> <text x="280" y="68">Proxy</text> <text x="412" y="68">IP</text> <text x="432" y="68">D</text> </g> </svg> </artwork> <artwork type="ascii-art"><![CDATA[ +--------+ IP A IP B +--------+ | +-------------------+ IP | IP C | Client | IP C <--> D | Proxy +---------> IP D | +-------------------+ | +--------+ +--------+ ]]></artwork> </artset> </figure> <t>In this case, the clientspecfiesspecifies both a target hostname and anIP protocol numberInternet Protocol Number in the scope of its request, indicating that it only needs to communicate with a single host. The IP proxy is able to perform DNS resolution on behalf of the client and allocate a specific outbound socket for the client instead of allocating an entire IP address to the client. In this regard, the request is similar to a regular CONNECT proxy request.</t> <t>The IP proxy assigns a single IPv6 address to the client (2001:db8:1234::a) and a route to a single IPv6 host(2001:db8:3456::b),(2001:db8:3456::b) scoped to SCTP. The client can send and receive SCTP IP packets to the remote host.</t> <figure anchor="fig-flow"> <name>Proxied SCTP Flow Example</name> <artwork><![CDATA[ [[ From Client ]] [[ From IP Proxy ]] SETTINGS H3_DATAGRAM = 1 SETTINGS ENABLE_CONNECT_PROTOCOL = 1 H3_DATAGRAM = 1 STREAM(44): HEADERS :method = CONNECT :protocol = connect-ip :scheme = https :path = /proxy?target=target.example.com&ipproto=132 :authority = proxy.example.com capsule-protocol = ?1 STREAM(44): HEADERS :status = 200 capsule-protocol = ?1 STREAM(44): DATA Capsule Type = ADDRESS_ASSIGN (Request ID = 0 IP Version = 6 IP Address = 2001:db8:1234::a IP Prefix Length = 128) STREAM(44): DATA Capsule Type = ROUTE_ADVERTISEMENT (IP Version = 6 Start IP Address = 2001:db8:3456::b End IP Address = 2001:db8:3456::b IP Protocol = 132) DATAGRAM Quarter Stream ID = 11 Context ID = 0 Payload = Encapsulated SCTP/IP Packet DATAGRAM Quarter Stream ID = 11 Context ID = 0 Payload = Encapsulated SCTP/IP Packet ]]></artwork> </figure> </section> <section anchor="proxied-connection-racing"> <name>Proxied Connection Racing</name> <t>The following example shows a setup where a client is proxying UDP packets through an IP proxy in order to control connection establishment racing through an IP proxy, as defined in Happy Eyeballs <xreftarget="HEv2"/>.target="RFC8305"/>. This example is a variant of the proxiedflow,flow but highlights how IP-level proxying can enable newcapabilitiescapabilities, even for TCP and UDP.</t> <figure anchor="diagram-racing"> <name>Proxied Connection Racing Setup</name> <artset> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1"height="144" width="472"viewBox="0 0472708 144" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px"> <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 240,32 L 240,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 240,32 L 312,32" 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 144,64 L 168,64" fill="none" stroke="black"/> <path d="M 144,80 L 168,80" fill="none" stroke="black"/> <path d="M 80,96 L 240,96" fill="none" stroke="black"/> <path d="M 320,96 L 424,96" fill="none" stroke="black"/> <path d="M 8,112 L 80,112" fill="none" stroke="black"/> <path d="M 240,112 L 312,112" fill="none" stroke="black"/> <polygon class="arrowhead" points="432,96 420,90.4 420,101.6" fill="black" transform="rotate(0,424,96)"/> <polygon class="arrowhead" points="432,48 420,42.4 420,53.6" fill="black" transform="rotate(0,424,48)"/> <polygon class="arrowhead" points="328,96 316,90.4 316,101.6" fill="black" transform="rotate(180,320,96)"/> <polygon class="arrowhead" points="328,48 316,42.4 316,53.6" fill="black" transform="rotate(180,320,48)"/> <polygon class="arrowhead" points="176,80 164,74.4 164,85.6" fill="black" transform="rotate(0,168,80)"/> <polygon class="arrowhead" points="176,64 164,58.4 164,69.6" fill="black" transform="rotate(0,168,64)"/> <polygon class="arrowhead" points="152,80 140,74.4 140,85.6" fill="black" transform="rotate(180,144,80)"/> <polygon class="arrowhead" points="152,64 140,58.4 140,69.6" fill="black" transform="rotate(180,144,64)"/> <g class="text"> <text x="100" y="36">IP</text> <text x="120" y="36">A</text> <text x="204" y="36">IP</text> <text x="224" y="36">B</text> <text x="332" y="36">IP</text> <text x="352" y="36">C</text> <text x="444" y="52">IP</text> <text x="464" y="52">E</text> <text x="44" y="68">Client</text> <text x="108" y="68">IP</text> <text x="128" y="68">C</text> <text x="184" y="68">E</text> <text x="276" y="68">IP</text> <text x="128" y="84">D</text> <text x="184" y="84">F</text> <text x="280" y="84">Proxy</text> <text x="444" y="100">IP</text> <text x="464" y="100">F</text> <text x="332" y="116">IP</text> <text x="352" y="116">D</text> </g> </svg> </artwork> <artwork type="ascii-art"><![CDATA[ +--------+ IP A IP B +--------+ IP C | +-------------------+ |<------------> IP E | Client | IP C <--> E | IP | | | D <--> F | Proxy | | +-------------------+ |<------------> IP F +--------+ +--------+ IP D ]]></artwork> </artset> </figure> <t>As with proxied flows, the client specifies both a target hostname and anIP protocol numberInternet Protocol Number in the scope of its request. When the IP proxy performs DNS resolution on behalf of the client, it can send the various remote address options to the client as separate routes. It can also ensure that the client has both IPv4 and IPv6 addresses assigned.</t> <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 (198.51.100.2) and an IPv6 route (2001:db8:3456::b), which represent the resolved addresses of the target hostname, scoped to UDP. The client can send and receive UDP IP packets to either one of the IP proxy addresses to enable Happy Eyeballs through the IP proxy.</t> <figure anchor="fig-listen"> <name>Proxied Connection Racing Example</name> <artwork><![CDATA[ [[ From Client ]] [[ From IP Proxy ]] SETTINGS H3_DATAGRAM = 1 SETTINGS ENABLE_CONNECT_PROTOCOL = 1 H3_DATAGRAM = 1 STREAM(44): HEADERS :method = CONNECT :protocol = connect-ip :scheme = https :path = /proxy?target=target.example.com&ipproto=17 :authority = proxy.example.com capsule-protocol = ?1 STREAM(44): HEADERS :status = 200 capsule-protocol = ?1 STREAM(44): DATA Capsule Type = ADDRESS_ASSIGN (Request ID = 0 IP Version = 4 IP Address = 192.0.2.3 IP Prefix Length = 32), (Request ID = 0 IP Version = 6 IP Address = 2001:db8::1234:1234 IP Prefix Length = 128) STREAM(44): DATA Capsule Type = ROUTE_ADVERTISEMENT (IP Version = 4 Start IP Address = 198.51.100.2 End IP Address = 198.51.100.2 IP Protocol = 17), (IP Version = 6 Start IP Address = 2001:db8:3456::b End IP Address = 2001:db8:3456::b IP Protocol = 17) ... DATAGRAM Quarter Stream ID = 11 Context ID = 0 Payload = Encapsulated IPv6 Packet DATAGRAM Quarter Stream ID = 11 Context ID = 0 Payload = Encapsulated IPv4 Packet ]]></artwork> </figure> </section> </section> <section anchor="extensibility-considerations"> <name>Extensibility Considerations</name> <t>Extensions to IP proxying in HTTP can define behavior changes to this mechanism. Such extensions <bcp14>SHOULD</bcp14> define new capsule types to exchange configuration information if needed. It is <bcp14>RECOMMENDED</bcp14> for extensions that modify addressing to specify that their extension capsules be sent before the ADDRESS_ASSIGN capsule and that they do not take effect until the ADDRESS_ASSIGN capsule is parsed. This allows modifications to address assignment to operate atomically. Similarly, extensions that modify routing <bcp14>SHOULD</bcp14> behave similarly with regard to the ROUTE_ADVERTISEMENT capsule.</t> </section> <section anchor="performance-considerations"> <name>Performance Considerations</name> <t>Bursty traffic can often lead totemporally-correlatedtemporally correlated packet losses; in turn, this can lead to suboptimal responses from congestion controllers in protocols running inside the tunnel. To avoid this, IP proxying endpoints <bcp14>SHOULD</bcp14> strive to avoid increasing burstiness of IP traffic; they <bcp14>SHOULD NOT</bcp14> queue packets in order to increase batching beyond the minimal amount required to take advantage of hardware offloads.</t> <t>When the protocol running inside the tunnel uses congestion control (e.g., <xreftarget="TCP"/>target="RFC9293"/> or <xreftarget="QUIC"/>),target="RFC9000"/>), the proxied traffic will incur at least two nested congestion controllers. When tunneled packets are sent using QUIC DATAGRAM frames, the outer HTTP connection <bcp14>MAY</bcp14> disable congestion control for those packets that contain only QUIC DATAGRAM frames encapsulating IP packets. Implementers will benefit from reading the guidance in <xref section="3.1.11" sectionFormat="of"target="UDP-USAGE"/>.</t>target="RFC8085"/>.</t> <t>When the protocol running inside the tunnel uses loss recovery (e.g., <xreftarget="TCP"/>target="RFC9293"/> or <xreftarget="QUIC"/>),target="RFC9000"/>) and the outer HTTP connection runs over TCP, the proxied traffic will incur at least two nested loss recovery mechanisms. This can reduceperformanceperformance, 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 QUIC DATAGRAM frame.</t> <section anchor="mtu-considerations"> <name>MTU Considerations</name> <t>When using HTTP/3 with the QUIC Datagram extension <xreftarget="DGRAM"/>,target="RFC9221"/>, IP packets are 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 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 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 characteristic that methods such as Datagram Packetization Layer PMTU Discovery (DPLPMTUD) depend on <xreftarget="DPLPMTUD"/>.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 of the dropped packet; see <xref section="3.2" sectionFormat="of"target="ICMPv6"/>.</t>target="RFC4443"/>.</t> </section> <section anchor="ecn-considerations"> <name>ECN Considerations</name> <t>If an IP proxying endpoint with a connection containing an IPProxyingproxying request stream disables congestion control, it cannot signal Explicit Congestion Notification (ECN) <xreftarget="ECN"/>target="RFC3168"/> support on that outer connection. That is, the QUIC sender <bcp14>MUST</bcp14> mark all IP headers with theNot-ECTNot ECN-Capable Transport (Not-ECT) codepoint for QUIC packetswhichthat are outside of congestion control. The endpoint can still report ECN feedback via QUIC ACK_ECN frames or the TCPECEECN-Echo (ECE) bit, as the peer might not have disabled congestion control.</t> <t>Conversely, if congestion control is not disabled on the outer congestion, the guidance in <xreftarget="ECN-TUNNEL"/>target="RFC6040"/> about transferring ECN marks between inner 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 also use ECN, independently of whether it is in use on the outer connection.</t> </section> <section anchor="dscp-considerations"> <name>Differentiated Services Considerations</name> <t>Tunneled IP packets can have Differentiated Services Code Points(DSCP)(DSCPs) <xreftarget="DSCP"/>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 of a Differentiated Services domain, it <bcp14>MAY</bcp14> implement traffic differentiation 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 IP proxying endpoints.</t> <t>When an HTTP connection is congestion-controlled, marking packets with differentDSCPDSCPs can lead to reordering between them, and that can in turn lead the underlying transport connection's congestion controller to perform poorly. 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 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 outer IP header of 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 does not define a way for requests to scope to particular DSCP values; such support is left to future extensions.</t> <t>If tunneled packets use QUIC datagrams and are not subject to congestion control by the outer connection, the IP proxying endpoints <bcp14>MAY</bcp14> translate the 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 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 and egress belonging to the samedifferentiated serviceDifferentiated Service domain or not.</t> </section> </section> <section anchor="security-considerations"> <name>Security Considerations</name> <t>There are significant risks in allowing arbitrary clients to establish a tunnel that permits sending to arbitrary hosts, regardless of whether tunnels are scoped to specific hosts or not. Bad actors could abuse this capability to send traffic and have it attributed to the IP proxy. HTTP servers that support IP proxying <bcp14>SHOULD</bcp14> restrict its use to authenticated users. Depending on the deployment, possible authentication mechanisms include mutual TLS between IP proxying endpoints, HTTP-based authentication via the HTTP Authorization header <xreftarget="HTTP"/>,target="RFC9110"/>, or even bearer tokens. Proxies can enforce policies for authenticated users to further constrain client behavior or deal with possible abuse. For example, proxies can rate limit individual clients that send an excessively large amount of traffic through the proxy. As another example, proxies can restrict address (prefix) assignment to clients based on certain clientattributesattributes, such as geographic location.</t> <t>Address assignment can have privacy implications for endpoints. For example, if a proxy partitions its address space by the number of authenticated clients and then assigns distinct address ranges to each client, target hosts could use this information to determine when IP packets correspond to the same client. Avoiding such tracking vectors may be important for certain proxy deployments. Proxies <bcp14>SHOULD</bcp14> avoid persistent per-client address (prefix) assignment when possible.</t> <t>Falsifying IP source addresses in sent traffic has been common fordenial of servicedenial-of-service attacks. Implementations of this mechanism need to ensure that they do 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 prefix. For example, that can happen through out-of-band configurationinformation,information or when allowed prefixes are shared via ADDRESS_ASSIGN capsules. In such scenarios, endpoints <bcp14>MUST</bcp14> follow the recommendations from <xreftarget="BCP38"/>target="RFC2827"/> to prevent source address spoofing.</t> <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 differentIP protocol numbers.Internet 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. However, some of these ICMP packets carry part of the original IP packet that triggered the ICMP response. Forwarding such packets can accidentally divulge information about one client's traffic to another client. To avoid this, proxies that forward ICMP on shared external IP addresses <bcp14>MUST</bcp14> inspect the invoking packet included in the ICMP packet and only forward the ICMP packet to the client whose scoping matches the invoking packet.</t> <t>Implementers will benefit from reading the guidance in <xreftarget="TUNNEL-SECURITY"/>.target="RFC6169"/>. Since there are known risks with some IPv6 extension headers (e.g., <xreftarget="ROUTING-HDR"/>),target="RFC5095"/>), implementers need to follow the latest guidance regarding handling of IPv6 extension headers.</t> <t>Transferring DSCP markings from inner to outer packets (see <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 a single end-to-end flow. Because of this, such use ofDSCPDSCPs in 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-optimistic-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 anchor="iana-considerations"> <name>IANA Considerations</name> <section anchor="http-upgrade-token"> <name>HTTP UpgradeToken</name> <t>This document will request IANA to registerToken Registration</name> <t>IANA has registered "connect-ip" in theHTTP"HTTP UpgradeToken RegistryTokens" registry maintained at<<eref target="https://www.iana.org/assignments/http-upgrade-tokens"/>>.</t><eref target="https://www.iana.org/assignments/http-upgrade-tokens" brackets="angle"/>.</t> <dlspacing="compact">spacing="compact" newline="false"> <dt>Value:</dt> <dd> <t>connect-ip</t> </dd> <dt>Description:</dt> <dd> <t>Proxying of IP Payloads</t> </dd> <dt>Expected Version Tokens:</dt> <dd> <t>None</t> </dd> <dt>References:</dt> <dd><t>This document</t><t>RFC 9484</t> </dd> </dl> </section> <section anchor="iana-suffix"><name>Creation of the MASQUE<name>MASQUE URI SuffixesRegistry</name> <t>This document requests that IANA create a newRegistry Creation</name> <t>IANA has created the "MASQUE URI Suffixes" registry maintained atIANA_URL_TBD.<eref target="https://www.iana.org/assignments/masque" brackets="angle"/>. The registration policy is Expert Review; see <xref section="4.5" sectionFormat="of" target="RFC8126"/>. This new registry governs the path segment that immediately follows "masque" in paths that start with"/.well-known/masque/","/.well-known/masque/"; see<<eref target="https://www.iana.org/assignments/well-known-uris"/>><eref target="https://www.iana.org/assignments/well-known-uris" brackets="angle"/> for the registration of "masque" in the "Well-Known URIs"registry. Thisregistry.</t> <t>This new registry contains three columns:</t><dl><dl spacing="compact" newline="false"> <dt>Path Segment:</dt> <dd> <t>An ASCII string containing only characters allowed in tokens; see <xref section="5.6.2" sectionFormat="of"target="HTTP"/>.target="RFC9110"/>. Entries in this registry <bcp14>MUST</bcp14> all have distinct entries in this column.</t> </dd> <dt>Description:</dt> <dd> <t>A description of the entry.</t> </dd> <dt>Reference:</dt> <dd> <t>An optional reference defining the use of the entry.</t> </dd> </dl> <t>Theregistration policy for this registry is Expert Review; see <xref section="4.5" sectionFormat="of" target="IANA-POLICY"/>.</t> <t>There are initially tworegistry's initial entriesin this registry:</t>are as follows:</t> <table anchor="iana-suffixes-table"><name>New MASQUE<name>MASQUE URISuffixes</name>Suffixes Registry</name> <thead> <tr> <th align="left">Path Segment</th> <th align="left">Description</th> <th align="left">Reference</th> </tr> </thead> <tbody> <tr> <td align="left">udp</td> <td align="left">UDP Proxying</td> <td align="left">RFC 9298</td> </tr> <tr> <td align="left">ip</td> <td align="left">IP Proxying</td> <tdalign="left">This Document</td>align="left">RFC 9484</td> </tr> </tbody> </table> <t>Designated experts for this registry are advised that they should approve all 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) the use case is relevant to proxying.</t> </section> <section anchor="iana-uri"> <name>Updates to masque Well-KnownURI</name> <t>This document will request IANA to updateURI Registration</name> <t>IANA has updated the entry for the "masque" URI suffix in the "Well-Known URIs" registry maintained at<<eref target="https://www.iana.org/assignments/well-known-uris"/>>.</t><eref target="https://www.iana.org/assignments/well-known-uris" brackets="angle"/>.</t> <t>IANAis requested to updatehas updated the "Reference" field to include this documentin addition to previous values from that field.</t> <t>IANA is requested to replaceand has replaced the "Related Information" field with "For sub-suffix allocations, seeregistry at IANA_URL_TBD." where IANA_URL_TBD is the URL ofthenewregistrydescribed in <xref target="iana-suffix"/>.</t>at <eref target="https://www.iana.org/assignments/masque" brackets="angle"/>.".</t> </section> <section anchor="iana-types"><name>Capsule Type<name>HTTP Capsule Types Registrations</name><t>This document requests IANA to add<t>IANA has added the following values to the "HTTP Capsule Types" registry maintained at<<eref target="https://www.iana.org/assignments/http-capsule-protocol"/>>.</t><eref target="https://www.iana.org/assignments/masque" brackets="angle"/>.</t> <table anchor="iana-capsules-table"> <name>New Capsules</name> <thead> <tr> <th align="left">Value</th> <th align="left">Capsule Type</th><th align="left">Description</th></tr> </thead> <tbody> <tr> <td align="left">0x01</td> <td align="left">ADDRESS_ASSIGN</td><td align="left">Address Assignment</td></tr> <tr> <td align="left">0x02</td> <td align="left">ADDRESS_REQUEST</td><td align="left">Address Request</td></tr> <tr> <td align="left">0x03</td> <td align="left">ROUTE_ADVERTISEMENT</td><td align="left">Route Advertisement</td></tr> </tbody> </table> <t>All of these new entries use the following values for these fields:</t><dl><dl spacing="compact" newline="false"> <dt>Status:</dt> <dd><t>provisional (permanent when this document is approved)</t><t>permanent</t> </dd> <dt>Reference:</dt> <dd><t>This Document</t><t>RFC 9484</t> </dd> <dt>Change Controller:</dt> <dd> <t>IETF</t> </dd> <dt>Contact:</dt> <dd> <t>masque@ietf.org</t> </dd> <dt>Notes:</dt> <dd><t>Empty</t><t>None</t> </dd> </dl><t>RFC Editor: please remove the rest of this subsection before publication.</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 codepoints instead: 0x2575D601 for ADDRESS_ASSIGN, 0x2575D602 for ADDRESS_REQUEST, and 0x2575D603 for ROUTE_ADVERTISEMENT.</t></section> </section> </middle> <back> <displayreferencetarget="H1"target="RFC9112" to="HTTP/1.1"/> <displayreferencetarget="H2"target="RFC9113" to="HTTP/2"/> <displayreferencetarget="H3"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="OPTIMISTIC"/> <references> <name>References</name> <references> <name>Normative References</name><reference anchor="H1"> <front> <title>HTTP/1.1</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="Reschke"> <organization/> </author> <date month="June" year="2022"/> <abstract> <t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document specifies the HTTP/1.1 message syntax, message parsing, connection management, and related security concerns. </t> <t>This document obsoletes portions of RFC 7230.</t> </abstract> </front> <seriesInfo name="STD" value="99"/> <seriesInfo name="RFC" value="9112"/> <seriesInfo name="DOI" value="10.17487/RFC9112"/> </reference> <reference anchor="H2"> <front> <title>HTTP/2</title> <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson"> <organization/> </author> <author fullname="C. Benfield" initials="C." role="editor" surname="Benfield"> <organization/> </author> <date month="June" year="2022"/> <abstract> <t>This specification describes an optimized expression of the semantics 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 latency by introducing field compression and allowing multiple concurrent exchanges on the same connection.</t> <t>This document obsoletes RFCs 7540 and 8740.</t> </abstract> </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="Bishop"> <organization/> </author> <date month="June" year="2022"/> <abstract> <t>The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that 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="Reschke"> <organization/> </author> <date month="June" year="2022"/> <abstract> <t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, 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, 7232, 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 in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs 1011 and 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 small clarification in reset handling while in the SYN-RECEIVED state. The TCP header 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 describing a range of Uniform Resource Identifiers through variable expansion. This specification defines the URI Template syntax and the process for expanding a URI Template 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 conveying 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 Protocol (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-version-specific details need to be specified. This document describes how the mechanism 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</title> <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 signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. 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</title> <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 protocol specifications. This document aims to reduce the ambiguity by clarifying that 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="Iyengar"> <organization/> </author> <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson"> <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 communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion 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 characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [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 convey the details of an intermediary's response handling, including generated errors.</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 Uniform 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 scoped address, defined as <zone_id> in the IPv6 Scoped Address Architecture (RFC 4007), can be represented in a literal IPv6 address and in a Uniform Resource Identifier that includes such a literal address. It updates the URI Generic Syntax 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="Crocker"> <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 Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [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 (IPv6). 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 protocol to add support for sending and receiving unreliable datagrams over a QUIC connection.</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 Protocol 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="Gupta"> <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 Control 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="Ramakrishnan"> <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 Congestion 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 differentiated 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 Attacks 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 method for using ingress traffic filtering to prohibit DoS (Denial of Service) attacks which use forged IP addresses to be propagated from 'behind' an Internet Service Provider's (ISP) aggregation point. 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="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 constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations 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 describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t> <t>This is the third edition of this document; it obsoletes RFC 5226.</t> </abstract> </front> <seriesInfo name="BCP" value="26"/> <seriesInfo name="RFC" value="8126"/> <seriesInfo name="DOI" value="10.17487/RFC8126"/> </reference><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9112.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9113.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9114.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9293.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6570.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9297.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8441.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9220.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9000.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9209.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6874.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9221.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0792.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4443.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3168.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2474.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2827.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/> </references> <references> <name>Informative References</name> <reference anchor="IANA-PN" target="https://www.iana.org/assignments/protocol-numbers"> <front> <title>Protocol Numbers</title> <author> <organization>IANA</organization> </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 how the HTTP CONNECT method allows proxying TCP in HTTP. More specifically, this document 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> <seriesInfo name="RFC" value="9298"/> <seriesInfo name="DOI" value="10.17487/RFC9298"/> </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 IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses.</t> <t>This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture". [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 Architecture for IP", which is designed to provide security services for traffic at the IP layer. This document obsoletes RFC 2401 (November 1998). [STANDARDS-TRACK]</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 Concurrency</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 addresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, clients that attempt multiple connections in parallel have a chance of establishing a connection more quickly. This document specifies requirements for algorithms that reduce this user-visible delay and provides an example algorithm, referred to as "Happy Eyeballs". This document obsoletes the original 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-passing transport that has no inherent congestion control mechanisms. This document provides guidelines on the use of UDP for the designers of applications, tunnels, and other protocols that use UDP. Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, middlebox traversal, the use of Explicit Congestion Notification (ECN), Differentiated Services Code Points (DSCPs), and ports.</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 Internet transport must employ mechanisms to prevent congestion collapse and to establish 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 protocols (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 multicast 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 Transports</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 Discovery (DPLPMTUD). This is a robust method for Path MTU Discovery (PMTUD) for datagram Packetization Layers (PLs). It allows a PL, or a datagram application that uses a PL, to discover whether a network path can support the current size of datagram. This can be used to detect and reduce the message size when a sender encounters a packet black hole. It can also probe a network path to discover whether the maximum packet size can be increased. This provides functionality for datagram transports that is equivalent to the PLPMTUD specification for TCP, specified 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 Datagram PMTUD into IETF datagram transports or applications that use datagram transports.</t> <t>This specification updates RFC 4960, RFC 4821, RFC 6951, RFC 8085, 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 notification (ECN) field of the IP header should be constructed on entry to and exit from any 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 decapsulation, 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 field 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 supported. Tunnel endpoints can be updated in any order without affecting pre-existing uses of the ECN field, thus ensuring backward compatibility. Nonetheless, operators wanting to support two severity levels (e.g., for pre-congestion notification -- PCN) can require compliance with this new specification. A thorough 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 that 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 administrators and future protocol developers. The primary intent of this document is to raise the awareness level regarding the security issues with IP tunnels as deployed 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-Neil"> <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 the purposes of generating denial-of-service traffic. This document updates the IPv6 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="Chernyakhovsky"> <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 mailing list masque@ietf.org or on the GitHub repository which contains the draft: https://github.com/ietf-wg-masque/draft-ietf- masque-ip-proxy-reqs. </t> </abstract></front><seriesInfo name="Internet-Draft" value="draft-ietf-masque-ip-proxy-reqs-03"/></reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9298.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4291.xml"/> <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-masque-ip-proxy-reqs.xml"/> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.schwartz-httpbis-optimistic-upgrade.xml"/> </references> </references> <section numbered="false" anchor="acknowledgments"> <name>Acknowledgments</name> <t>The design of this method was inspired by discussions in the MASQUEworking groupWorking Group around <xreftarget="PROXY-REQS"/>.target="I-D.ietf-masque-ip-proxy-reqs"/>. The authors would 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"/> provided valuable feedback on the document.</t> <t>Most of the text on client configuration is based on the corresponding text in <xreftarget="CONNECT-UDP"/>.</t>target="RFC9298"/>.</t> </section> </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>