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 20141. Introduction Petersson & Nilsson Standards Track [ Page 3 ] 
RFC 7239 Forwarded HTTP Extension June 2014RFC6269].

2. Notational ConventionsRFC2119].

3. Syntax NotationsRFC5234] with the list rule extension defined in Section
   7 of [RFC7230].

4. Forwarded HTTP Header Field8.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 2014Section 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 = [RFC7230], Section 3.2.6

>
quoted-string = [RFC7230], Section 3.2.6>

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 20145. Parameters5.1. Forwarded BySection 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 ForSection 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 20146. Node Identifiers[RFC3986], Section 3.2.2>
       IPv6address = [RFC3986], Section 3.2.2

>
obfnode = “_” 1*( ALPHA / DIGIT / “.” / “_” / “-“)

node-port = port / obfport
port = 1*5DIGIT
obfport = “_” 1*(ALPHA / DIGIT / “.” / “_” / “-“)

DIGIT = [RFC5234], Section 3.4>
ALPHA = RFC5234], Section B.1>

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 20146.1. IPv4 and IPv6 IdentifiersRFC3986].  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" Identifier6.3. Obfuscated Identifier Petersson & Nilsson Standards Track [ Page 9 ]
RFC 7239 Forwarded HTTP Extension June 20147. Implementation Considerations7.1. HTTP Lists7.2. Header Field Preservation[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[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 20147.4. Transition7.5. Example Usage Petersson & Nilsson Standards Track [ Page 11 ]
 
RFC 7239 Forwarded HTTP Extension June 20148. Security Considerations8.1. Header Validity and Integrity8.2. Information Leak8.3. Privacy Considerations Petersson & Nilsson Standards Track [ Page 12 ]
RFC 7239 Forwarded HTTP Extension June 2014 Petersson & Nilsson Standards Track [ Page 13 ]

Leave a Reply

Your email address will not be published.