From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7239.txt | 899 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 899 insertions(+) create mode 100644 doc/rfc/rfc7239.txt (limited to 'doc/rfc/rfc7239.txt') diff --git a/doc/rfc/rfc7239.txt b/doc/rfc/rfc7239.txt new file mode 100644 index 0000000..3419a95 --- /dev/null +++ b/doc/rfc/rfc7239.txt @@ -0,0 +1,899 @@ + + + + + + +Internet Engineering Task Force (IETF) A. Petersson +Request for Comments: 7239 M. Nilsson +Category: Standards Track Opera Software +ISSN: 2070-1721 June 2014 + + + Forwarded HTTP Extension + +Abstract + + This document defines an HTTP extension header field that allows + proxy components to disclose information lost in the proxying + process, for example, the originating IP address of a request or IP + address of the proxy on the user-agent-facing interface. In a path + of proxying components, this makes it possible to arrange it so that + each subsequent component will have access to, for example, all IP + addresses used in the chain of proxied HTTP requests. + + This document also specifies guidelines for a proxy administrator to + anonymize the origin of a request. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7239. + + + + + + + + + + + + + + + + + +Petersson & Nilsson Standards Track [Page 1] + +RFC 7239 Forwarded HTTP Extension June 2014 + + +Copyright Notice + + Copyright (c) 2014 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction ....................................................3 + 2. Notational Conventions ..........................................4 + 3. Syntax Notations ................................................4 + 4. Forwarded HTTP Header Field .....................................4 + 5. Parameters ......................................................6 + 5.1. Forwarded By ...............................................6 + 5.2. Forwarded For ..............................................6 + 5.3. Forwarded Host .............................................7 + 5.4. Forwarded Proto ............................................7 + 5.5. Extensions .................................................7 + 6. Node Identifiers ................................................8 + 6.1. IPv4 and IPv6 Identifiers ..................................9 + 6.2. The "unknown" Identifier ...................................9 + 6.3. Obfuscated Identifier ......................................9 + 7. Implementation Considerations ..................................10 + 7.1. HTTP Lists ................................................10 + 7.2. Header Field Preservation .................................10 + 7.3. Relation to Via ...........................................10 + 7.4. Transition ................................................11 + 7.5. Example Usage .............................................11 + 8. Security Considerations ........................................12 + 8.1. Header Validity and Integrity .............................12 + 8.2. Information Leak ..........................................12 + 8.3. Privacy Considerations ....................................12 + 9. IANA Considerations ............................................14 + 10. References ....................................................14 + 10.1. Normative References .....................................14 + 10.2. Informative References ...................................15 + Appendix A. Acknowledgments .......................................16 + + + + + +Petersson & Nilsson Standards Track [Page 2] + +RFC 7239 Forwarded HTTP Extension June 2014 + + +1. Introduction + + In today's HTTP landscape, there are a multitude of different + applications that act as proxies for the user agents. In many cases, + these proxies exists without the action or knowledge of the end-user. + These cases occur, for example, when the proxy exists as a part of + the infrastructure within the organization running the web server. + Such proxies may be used for features such as load balancing or + crypto offload. Another example is when the proxy is used within the + same organization as the user, and the proxy is used to cache + resources. However, these proxies make the requests appear as if + they originated from the proxy's IP address, and they may change + other information in the original request. This represents a loss of + information from the original request. + + This loss of information can cause problems for a web server that has + a specific use for the clients' IP addresses that will not be met by + using the address of the proxy or other information changed by the + proxy. The main uses of this information are for diagnostics, access + control, and abuse management. Diagnostic functions can include + event logging, troubleshooting, and statistics gathering, and the + information collected is usually only stored for short periods of + time and only gathered in response to a particular problem or a + complaint from the client. Access control can be operated by + configuring a list of client IP addresses from which access is + permitted, but this approach will not work if a proxy is used, unless + the proxy is trusted and is, itself, configured with a list of + allowed client addresses for the server. Cases of abuse require + identification of the abuser and this uses many of the same features + identified for diagnostics. + + Most of the time that a proxy is used, this loss of information is + not the primary purpose, or even a desired effect, of using the + proxy. Thus, to restore the desired functionality when a proxy is in + use, a way of disclosing the original information at the HTTP level + is needed. Clearly, however, when the purpose of using a proxy is to + provide client anonymity, the proxy will not use the feature defined + in this document. + + It should be noted that the use of a reverse proxy also hides + information. Again, where the loss of information is not a + deliberate function of the use of the reverse proxy, it can be + desirable to find a way to encode the information within the HTTP + messages so that the consumer can see it. + + A common way to disclose this information is by using the non- + standard header fields such as X-Forwarded-For, X-Forwarded-By, and + X-Forwarded-Proto. There are many benefits to using a standardized + + + +Petersson & Nilsson Standards Track [Page 3] + +RFC 7239 Forwarded HTTP Extension June 2014 + + + approach to commonly desired protocol function: not least is + interoperability between implementations. This document standardizes + a header field called "Forwarded" and provides the syntax and + semantics for disclosing such information. "Forwarded" also combines + all the information within one single header field, making it + possible to correlate that information. With the header field format + described in this document, it is possible to know what information + belongs together, as long as the proxies are trusted. Such + conclusions are not possible to make with the X-Forwarded class of + header fields. The header field defined in this document is optional + such that implementations of proxies that are intended to provide + privacy are not required to operate or implement the header field. + + Note that similar issues to those described for proxies also arise + with use of NATs. This is discussed further in [RFC6269]. + +2. Notational Conventions + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +3. Syntax Notations + + This specification uses the Augmented Backus-Naur Form (ABNF) + notation of [RFC5234] with the list rule extension defined in Section + 7 of [RFC7230]. + +4. Forwarded HTTP Header Field + + The "Forwarded" HTTP header field is an OPTIONAL header field that, + when used, contains a list of parameter-identifier pairs that + disclose information that is altered or lost when a proxy is involved + in the path of the request. Due to the sensitive nature of the data + passed in this header field (see Sections 8.2 and 8.3), this header + field should be turned off by default. Further, each parameter + should be configured individually. "Forwarded" is only for use in + HTTP requests and is not to be used in HTTP responses. This applies + to forwarding proxies, as well as reverse proxies. Information + passed in this header field can be, for example, the source IP + address of the request, the IP address of the incoming interface on + the proxy, or whether HTTP or HTTPS was used. If the request is + passing through several proxies, each proxy can add a set of + parameters; it can also remove previously added "Forwarded" header + fields. + + + + + + +Petersson & Nilsson Standards Track [Page 4] + +RFC 7239 Forwarded HTTP Extension June 2014 + + + The top-level list is represented as a list of HTTP header + field-values as defined in Section 3.2 of [RFC7230]. The first + element in this list holds information added by the first proxy that + implements and uses this header field, and each subsequent element + holds information added by each subsequent proxy. Because this + header field is optional, any proxy in the chain may choose not to + update this header field. Each field-value is a semicolon-separated + list; this sublist consists of parameter-identifier pairs. + Parameter-identifier pairs are grouped together by an equals sign. + Each parameter MUST NOT occur more than once per field-value. The + parameter names are case-insensitive. The header field value can be + defined in ABNF syntax as: + + Forwarded = 1#forwarded-element + + forwarded-element = + [ forwarded-pair ] *( ";" [ forwarded-pair ] ) + + forwarded-pair = token "=" value + value = token / quoted-string + + token = + quoted-string = + + Examples: + + Forwarded: for="_gazonk" + Forwarded: For="[2001:db8:cafe::17]:4711" + Forwarded: for=192.0.2.60;proto=http;by=203.0.113.43 + Forwarded: for=192.0.2.43, for=198.51.100.17 + + Note that as ":" and "[]" are not valid characters in "token", IPv6 + addresses are written as "quoted-string". + + A proxy server that wants to add a new "Forwarded" header field value + can either append it to the last existing "Forwarded" header field + after a comma separator or add a new field at the end of the header + block. A proxy MAY remove all "Forwarded" header fields from a + request. It MUST, however, ensure that the correct header field is + updated in case of multiple "Forwarded" header fields. + + + + + + + + + + + +Petersson & Nilsson Standards Track [Page 5] + +RFC 7239 Forwarded HTTP Extension June 2014 + + +5. Parameters + + This document specifies a number of parameters and valid values for + each of them: + + o "by" identifies the user-agent facing interface of the proxy. + + o "for" identifies the node making the request to the proxy. + + o "host" is the host request header field as received by the proxy. + + o "proto" indicates what protocol was used to make the request. + +5.1. Forwarded By + + The "by" parameter is used to disclose the interface where the + request came in to the proxy server. When proxies choose to use the + "by" parameter, its default configuration SHOULD contain an + obfuscated identifier as described in Section 6.3. If the server + receiving proxied requests requires some address-based functionality, + this parameter MAY instead contain an IP address (and, potentially, a + port number). A third option is the "unknown" identifier described + in Section 6.2. + + The syntax of a "by" value, after potential quoted-string unescaping, + conforms to the "node" ABNF described in Section 6. + + This is primarily added by reverse proxies that wish to forward this + information to the backend server. It can also be interesting in a + multihomed environment to signal to backend servers from which the + request came. + +5.2. Forwarded For + + The "for" parameter is used to disclose information about the client + that initiated the request and subsequent proxies in a chain of + proxies. When proxies choose to use the "for" parameter, its default + configuration SHOULD contain an obfuscated identifier as described in + Section 6.3. If the server receiving proxied requests requires some + address-based functionality, this parameter MAY instead contain an IP + address (and, potentially, a port number). A third option is the + "unknown" identifier described in Section 6.2. + + The syntax of a "for" value, after potential quoted-string + unescaping, conforms to the "node" ABNF described in Section 6. + + + + + + +Petersson & Nilsson Standards Track [Page 6] + +RFC 7239 Forwarded HTTP Extension June 2014 + + + In a chain of proxy servers where this is fully utilized, the first + "for" parameter will disclose the client where the request was first + made, followed by any subsequent proxy identifiers. The last proxy + in the chain is not part of the list of "for" parameters. The last + proxy's IP address, and optionally a port number, are, however, + readily available as the remote IP address at the transport layer. + It can, however, be more relevant to read information about the last + proxy from preceding "Forwarded" header field's "by" parameter, if + present. + +5.3. Forwarded Host + + The "host" parameter is used to forward the original value of the + "Host" header field. This can be used, for example, by the origin + server if a reverse proxy is rewriting the "Host" header field to + some internal host name. + + The syntax for a "host" value, after potential quoted-string + unescaping, MUST conform to the Host ABNF described in Section 5.4 of + [RFC7230]. + +5.4. Forwarded Proto + + The "proto" parameter has the value of the used protocol type. The + syntax of a "proto" value, after potential quoted-string unescaping, + MUST conform to the URI scheme name as defined in Section 3.1 in + [RFC3986] and registered with IANA according to [RFC4395]. Typical + values are "http" or "https". + + For example, in an environment where a reverse proxy is also used as + a crypto offloader, this allows the origin server to rewrite URLs in + a document to match the type of connection as the user agent + requested, even though all connections to the origin server are + unencrypted HTTP. + +5.5. Extensions + + Extensions allow for additional parameters and values. Extensions + can be particularly useful in reverse proxy environments. All + extension parameters SHOULD be registered in the "HTTP Forwarded + Parameter" registry. If certain extensions are expected to have + widespread deployment, they SHOULD also be standardized. This is + further discussed in Section 9. + + + + + + + + +Petersson & Nilsson Standards Track [Page 7] + +RFC 7239 Forwarded HTTP Extension June 2014 + + +6. Node Identifiers + + The node identifier is one of the following: + + o The client's IP address, with an optional port number + + o A token indicating that the IP address of the client is not known + to the proxy server + + o A generated token, allowing for tracing and debugging, while + allowing the internal structure or sensitive information to be + hidden + + The node identifier is defined by the ABNF syntax as: + + node = nodename [ ":" node-port ] + nodename = IPv4address / "[" IPv6address "]" / + "unknown" / obfnode + + IPv4address = + IPv6address = + obfnode = "_" 1*( ALPHA / DIGIT / "." / "_" / "-") + + node-port = port / obfport + port = 1*5DIGIT + obfport = "_" 1*(ALPHA / DIGIT / "." / "_" / "-") + + DIGIT = + ALPHA = + + Each of the identifiers may optionally have the port identifier, for + example, allowing the identification of the endpoint in a NATed + environment. The "node-port" can be identified either by its port + number or by a generated token obfuscating the real port number. An + obfuscated port may be used in situations where the possessor of the + proxy wants the ability to trace requests -- for example, in debug + purposes -- but does not want to reveal internal information. + + Note that the ABNF above also allows port numbers to be appended to + the "unknown" identifier. Interpretation of such notation is, + however, left to the possessor of a proxy adding such a value to the + header field. To distinguish an "obfport" from a port, the "obfport" + MUST have a leading underscore. Further, it MUST also consist of + only "ALPHA", "DIGIT", and the characters ".", "_", and "-". + + It is important to note that an IPv6 address and any nodename with + node-port specified MUST be quoted, since ":" is not an allowed + character in "token". + + + +Petersson & Nilsson Standards Track [Page 8] + +RFC 7239 Forwarded HTTP Extension June 2014 + + + Examples: + + "192.0.2.43:47011" + "[2001:db8:cafe::17]:47011" + +6.1. IPv4 and IPv6 Identifiers + + The ABNF rules for "IPv6address" and "IPv4address" are defined in + [RFC3986]. The "IPv6address" SHOULD comply with textual + representation recommendations [RFC5952] (for example, lowercase, + compression of zeros). + + Note that the IP address may be one from the internal nets, as + defined in [RFC1918] and [RFC4193]. Also, note that an IPv6 address + is always enclosed in square brackets. + +6.2. The "unknown" Identifier + + The "unknown" identifier is used when the identity of the preceding + entity is not known, but the proxy server still wants to signal that + a forwarding of the request was made. One example would be a proxy + server process generating an outgoing request without direct access + to the incoming request TCP socket. + +6.3. Obfuscated Identifier + + A generated identifier may be used where there is a wish to keep the + internal IP addresses secret, while still allowing the "Forwarded" + header field to be used for tracing and debugging. This can also be + useful if the proxy uses some sort of interface labels and there is a + desire to pass them rather than an IP address. Unless static + assignment of identifiers is necessary for the server's use of the + identifiers, obfuscated identifiers SHOULD be randomly generated for + each request. If the server requires that identifiers persist across + requests, they SHOULD NOT persist longer than client IP addresses. + To distinguish the obfuscated identifier from other identifiers, it + MUST have a leading underscore "_". Furthermore, it MUST also + consist of only "ALPHA", "DIGIT", and the characters ".", "_", and + "-". + Example: + + Forwarded: for=_hidden, for=_SEVKISEK + + + + + + + + + +Petersson & Nilsson Standards Track [Page 9] + +RFC 7239 Forwarded HTTP Extension June 2014 + + +7. Implementation Considerations + +7.1. HTTP Lists + + Note that an HTTP list allows white spaces to occur between the + identifiers, and the list may be split over multiple header fields. + As an example, the header field + + Forwarded: for=192.0.2.43,for="[2001:db8:cafe::17]",for=unknown + + is equivalent to the header field + + Forwarded: for=192.0.2.43, for="[2001:db8:cafe::17]", for=unknown + + which is equivalent to the header fields + + Forwarded: for=192.0.2.43 + Forwarded: for="[2001:db8:cafe::17]", for=unknown + +7.2. Header Field Preservation + + There are some cases when this header field should be kept and some + cases where it should not be kept. A directly forwarded request + should preserve and possibly extend it. If a single incoming request + causes the proxy to make multiple outbound requests, special care + must be taken to decide whether or not the header field should be + preserved. In many cases, the header field should be preserved, but + if the outbound request is not a direct consequence of the incoming + request, the header field should not be preserved. Consider also the + case when a proxy has detected a content mismatch in a 304 response + and is following the instructions in [RFC7232], Section 4.1 to repeat + the request unconditionally, in which case the new request is still + basically a direct consequence of the origin request, and the header + field should probably be kept. + +7.3. Relation to Via + + The "Via" header field (see [RFC7230], Section 5.7.1) is a header + field with a similar use case as this header field. The "Via" header + field, however, only provides information about the proxy itself, and + thereby leaves out the information about the client connecting to the + proxy server. The "Forwarded" header field, on the other hand, has + relaying information from the client-facing side of the proxy server + as its main purpose. As "Via" is already widely deployed, its format + cannot be changed to address the problems that "Forwarded" addresses. + + + + + + +Petersson & Nilsson Standards Track [Page 10] + +RFC 7239 Forwarded HTTP Extension June 2014 + + + Note that it is not possible to combine information from this header + field with the information from the Via header field. Some proxies + will not update the "Forwarded" header field, some proxies will not + update the Via header field, and some proxies will update both. + +7.4. Transition + + If a proxy gets incoming requests with X-Forwarded-* header fields + present, it is encouraged to convert these into the header field + described in this document, if it can be done in a sensible way. If + the request only contains one type -- for example, X-Forwarded-For -- + this can be translated to "Forwarded", by prepending each element + with "for=". Note that IPv6 addresses may not be quoted in + X-Forwarded-For and may not be enclosed by square brackets, but they + are quoted and enclosed in square brackets in "Forwarded". + + X-Forwarded-For: 192.0.2.43, 2001:db8:cafe::17 + + becomes: + + Forwarded: for=192.0.2.43, for="[2001:db8:cafe::17]" + + However, special care must be taken if, for example, both + X-Forwarded-For and X-Forwarded-By exist. In such cases, it may not + be possible to do a conversion, since it is not possible to know in + which order the already existing fields were added. Also, note that + removing the X-Forwarded-For header field may cause issues for + parties that have not yet implemented support for this new header + field. + +7.5. Example Usage + + A request from a client with IP address 192.0.2.43 passes through a + proxy with IP address 198.51.100.17, then through another proxy with + IP address 203.0.113.60 before reaching an origin server. This + could, for example, be an office client behind a corporate malware + filter talking to a origin server through a reverse proxy. + + o The HTTP request between the client and the first proxy has no + "Forwarded" header field. + + o The HTTP request between the first and second proxy has a + "Forwarded: for=192.0.2.43" header field. + + o The HTTP request between the second proxy and the origin server + has a "Forwarded: for=192.0.2.43, + for=198.51.100.17;by=203.0.113.60;proto=http;host=example.com" + header field. + + + +Petersson & Nilsson Standards Track [Page 11] + +RFC 7239 Forwarded HTTP Extension June 2014 + + + Note that, at some points in a connection chain, the information + might not be updated in the "Forwarded" header field, either because + of lack of support of this HTTP extension or because of a policy + decision not to disclose information about this network component. + +8. Security Considerations + +8.1. Header Validity and Integrity + + The "Forwarded" HTTP header field cannot be relied upon to be + correct, as it may be modified, whether mistakenly or for malicious + reasons, by every node on the way to the server, including the client + making the request. + + One approach to ensure that the "Forwarded" HTTP header field is + correct is to verify the correctness of proxies and to whitelist them + as trusted. This approach has at least two weaknesses. First, the + chain of IP addresses listed before the request came to the proxy + cannot be trusted. Second, unless the communication between proxies + and the endpoint is secured, the data can be modified by an attacker + with access to the network. + +8.2. Information Leak + + The "Forwarded" HTTP header field can reveal internal structures of + the network setup behind the NAT or proxy setup, which may be + undesired. This can be addressed either by using obfuscated + elements, by preventing the internal nodes from updating the HTTP + header field, or by having an egress proxy remove entries that reveal + internal network information. + + This header field should never be copied into response messages by + origin servers or intermediaries, as it can reveal the whole proxy + chain to the client. As a side effect, special care must be taken in + hosting environments not to allow the TRACE request where the + "Forwarded" field is used, as it would appear in the body of the + response message. + +8.3. Privacy Considerations + + In recent years, there have been growing concerns about privacy. + There is a trade-off between ensuring privacy for users versus + disclosing information that is useful, for example, for debugging, + statistics, and generating location-dependent content. The + "Forwarded" HTTP header field, by design, exposes information that + some users consider privacy sensitive, in order to allow for such + uses. For any proxy, if the HTTP request contains header fields that + + + + +Petersson & Nilsson Standards Track [Page 12] + +RFC 7239 Forwarded HTTP Extension June 2014 + + + specifically request privacy semantics, the proxy SHOULD NOT use the + "Forwarded" header field, nor in any other manner pass private + information, such as IP addresses, on to the next hop. + + The client's IP address, that may be forwarded in the "for" parameter + of this header field, is considered to be privacy sensitive by many + people, as the IP address may be able to uniquely identify a client, + what operator the user is using, and possibly a rough estimation of + where the user is geographically located. + + Proxies using this extension will preserve the information of a + direct connection. This has an end-user privacy impact regardless of + whether the end-user or deployer knows or expects that this is the + case. + + Implementers and deployers of such proxies need to consider whether, + and how, deploying this extension affects user privacy. + + The default configuration for both the "by" and "for" parameters + SHOULD contain obfuscated identifiers. These identifiers SHOULD be + randomly generated per request. If identifiers that persist across + requests are required, their lifetimes SHOULD be limited and they + SHOULD NOT persist longer than client IP addresses. When generating + obfuscated identifiers, care must be taken not to include potentially + sensitive information in them. + + Note that users' IP addresses may already be forwarded by proxies + using the header field X-Forwarded-For, which is widely used. It + should also be noted that if the user were doing the connection + directly without passing the proxy, the client's IP address would be + sent to the web server. Users that do not actively choose an + anonymizing proxy cannot rely on having their IP address shielded. + These users who want to minimize the risk of being tracked must also + note that there are other ways information may leak, for example, by + browser header field fingerprinting. The Forwarded header field + itself, even when used without a uniquely identifying client + identifier, may make fingerprinting more feasible by revealing the + chain of proxies traversed by the client's request. + + + + + + + + + + + + + +Petersson & Nilsson Standards Track [Page 13] + +RFC 7239 Forwarded HTTP Extension June 2014 + + +9. IANA Considerations + + This document specifies the HTTP header field listed below, which has + been added to the "Permanent Message Header Field Names" registry + defined in [RFC3864]. + + Header field: Forwarded + Applicable protocol: http + Status: standard + Author/Change controller: + IETF (iesg@ietf.org) + Internet Engineering Task Force + Specification document(s): this specification (Section 4) + Related information: None + + The "Forwarded" header field contains parameters for which IANA has + created and now maintains a new registry entitled "HTTP Forwarded + Parameters". Initial registrations are given below. For future + assignments, the registration procedure is IETF Review [RFC5226]. + The security and privacy implications of all new parameters should be + thoroughly documented. New parameters and their values MUST conform + with the forwarded-pair as defined in ABNF in Section 4. Further, a + short description should be provided in the registration. + + +-------------+---------------------------------------+-------------+ + | Parameter | Description | Reference | + | name | | | + +-------------+---------------------------------------+-------------+ + | by | IP address of incoming interface of a | Section 5.1 | + | | proxy | | + | for | IP address of client making a request | Section 5.2 | + | | through a proxy | | + | host | Host header field of the incoming | Section 5.3 | + | | request | | + | proto | Application protocol used for | Section 5.4 | + | | incoming request | | + +-------------+---------------------------------------+-------------+ + + Table 1: Initial Assignments + +10. References + +10.1. Normative References + + [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and + E. Lear, "Address Allocation for Private Internets", + BCP 5, RFC 1918, February 1996. + + + + +Petersson & Nilsson Standards Track [Page 14] + +RFC 7239 Forwarded HTTP Extension June 2014 + + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration + Procedures for Message Header Fields", BCP 90, RFC 3864, + September 2004. + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, + RFC 3986, January 2005. + + [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast + Addresses", RFC 4193, October 2005. + + [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and + Registration Procedures for New URI Schemes", BCP 35, + RFC 4395, February 2006. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + + [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, January 2008. + + [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 + Address Text Representation", RFC 5952, August 2010. + + [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Message Syntax and Routing", + RFC 7230, June 2014. + + [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Conditional Requests", RFC 7232, + June 2014. + +10.2. Informative References + + [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. + Roberts, "Issues with IP Address Sharing", RFC 6269, + June 2011. + + + + + + + + + + +Petersson & Nilsson Standards Track [Page 15] + +RFC 7239 Forwarded HTTP Extension June 2014 + + +Appendix A. Acknowledgments + + Thanks to Per Cederqvist, Alissa Cooper, Adrian Farrel, Stephen + Farrell, Ned Freed, Per Hedbor, Amos Jeffries, Poul-Henning Kamp, + Murray S. Kucherawy, Barry Leiba, Salvatore Loreto, Alexey Melnikov, + S. Moonesamy, Susan Nichols, Mark Nottingham, Julian Reschke, John + Sullivan, Willy Tarreau, and Dan Wing for their feedback. + +Authors' Addresses + + Andreas Petersson + Opera Software + + EMail: andreas@sbin.se + + + Martin Nilsson + Opera Software + S:t Larsgatan 12 + Linkoping SE-582 24 + + EMail: nilsson@opera.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Petersson & Nilsson Standards Track [Page 16] + -- cgit v1.2.3