[要約] RFC 7239は、HTTPリクエストやレスポンスに転送情報を含めるための拡張機能です。その目的は、クライアントとサーバー間のネットワークプロキシやロードバランサーなどの中間ノードでの転送情報の透過的な伝達を可能にすることです。
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
転送されたHTTP拡張
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.
このドキュメントでは、HTTP拡張ヘッダーフィールドを定義して、プロキシコンポーネントがプロキシプロセスで失われた情報（リクエストの発信元IPアドレスやユーザーエージェント向けのインターフェースのプロキシのIPアドレスなど）を開示できるようにします。これにより、プロキシコンポーネントのパスでは、後続の各コンポーネントが、たとえばプロキシされたHTTPリクエストのチェーンで使用されるすべてのIPアドレスにアクセスできるようにコンポーネントを配置できます。
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.
これはInternet Standards Trackドキュメントです。
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.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
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.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7239で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、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
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.
今日のHTTPランドスケープには、ユーザーエージェントのプロキシとして機能するさまざまなアプリケーションが多数あります。多くの場合、これらのプロキシは、エンドユーザーのアクションや知識なしに存在します。これらのケースは、たとえば、プロキシがWebサーバーを実行している組織内のインフラストラクチャの一部として存在する場合に発生します。このようなプロキシは、負荷分散や暗号化オフロードなどの機能に使用できます。別の例は、ユーザーと同じ組織内でプロキシが使用され、リソースのキャッシュにプロキシが使用される場合です。ただし、これらのプロキシは、リクエストがプロキシのIPアドレスから発信されたように見せかけ、元のリクエストの他の情報を変更する場合があります。これは、元の要求からの情報の損失を表しています。
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.
この情報の損失は、プロキシーのアドレスまたはプロキシーによって変更された他の情報を使用することでは満たされないクライアントのIPアドレスの特定の用途を持つWebサーバーに問題を引き起こす可能性があります。この情報の主な用途は、診断、アクセス制御、および乱用管理です。診断機能には、イベントロギング、トラブルシューティング、統計収集が含まれ、収集された情報は通常、短期間のみ保存され、特定の問題またはクライアントからの苦情への応答としてのみ収集されます。アクセス制御は、アクセスが許可されるクライアントIPアドレスのリストを構成することによって操作できますが、プロキシが信頼されていて、それ自体が許可されたクライアントアドレスのリストで構成されていない限り、プロキシが使用されている場合、このアプローチは機能しませんサーバー。虐待のケースでは、虐待者の識別が必要であり、これは診断のために識別された同じ機能の多くを使用します。
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.
プロキシが使用されるほとんどの場合、この情報の損失は、プロキシを使用することの主な目的、または望ましい効果でさえありません。したがって、プロキシが使用されているときに必要な機能を復元するには、元の情報をHTTPレベルで開示する方法が必要です。ただし、明らかに、プロキシを使用する目的がクライアントの匿名性を提供することである場合、プロキシはこのドキュメントで定義されている機能を使用しません。
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.
リバースプロキシを使用すると、情報も非表示になることに注意してください。この場合も、情報の損失がリバースプロキシの使用による意図的な機能ではない場合、コンシューマが情報を確認できるように、HTTPメッセージ内の情報をエンコードする方法を見つけることが望ましい場合があります。
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 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.
この情報を公開する一般的な方法は、X-Forwarded-For、X-Forwarded-By、X-Forwarded-Protoなどの非標準のヘッダーフィールドを使用することです。一般的に望まれるプロトコル機能に標準化されたアプローチを使用することには多くの利点があります。特に、実装間の相互運用性です。このドキュメントは、「Forwarded」と呼ばれるヘッダーフィールドを標準化し、そのような情報を開示するための構文とセマンティクスを提供します。 「転送」は、1つの単一ヘッダーフィールド内のすべての情報を組み合わせて、その情報を関連付けることを可能にします。このドキュメントで説明するヘッダーフィールド形式を使用すると、プロキシが信頼されている限り、どの情報が一緒に属しているかを知ることができます。このような結論は、ヘッダーフィールドのX-Forwardedクラスでは作成できません。このドキュメントで定義されているヘッダーフィールドはオプションであり、プライバシーを提供することを目的としたプロキシの実装は、ヘッダーフィールドを操作または実装する必要はありません。
Note that similar issues to those described for proxies also arise with use of NATs. This is discussed further in [RFC6269].
プロキシについて説明した問題と同様の問題がNATの使用でも発生することに注意してください。これは[RFC6269]でさらに議論されます。
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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234] with the list rule extension defined in Section 7 of [RFC7230].
この仕様では、[RFC5234]のAugmented Backus-Naur Form（ABNF）表記と、[RFC7230]のセクション7で定義されているリストルール拡張を使用しています。
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.
"Forwarded" HTTPヘッダーフィールドは、オプションのヘッダーフィールドであり、使用すると、リクエストのパスにプロキシが関与すると変更または失われる情報を開示するパラメーターとIDのペアのリストが含まれます。このヘッダーフィールド（セクション8.2および8.3を参照）で渡されるデータの機密性のため、このヘッダーフィールドはデフォルトでオフにする必要があります。さらに、各パラメーターは個別に構成する必要があります。 「転送」はHTTP要求でのみ使用され、HTTP応答では使用されません。これは、転送プロキシとリバースプロキシに適用されます。このヘッダーフィールドで渡される情報には、たとえば、要求の送信元IPアドレス、プロキシの受信インターフェイスのIPアドレス、HTTPまたはHTTPSのどちらが使用されたかなどがあります。リクエストが複数のプロキシを通過している場合、各プロキシは一連のパラメータを追加できます。以前に追加された「転送」ヘッダーフィールドを削除することもできます。
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:
最上位のリストは、[RFC7230]のセクション3.2で定義されているHTTPヘッダーのフィールド値のリストとして表されます。このリストの最初の要素は、このヘッダーフィールドを実装および使用する最初のプロキシによって追加された情報を保持し、後続の各要素は、後続の各プロキシによって追加された情報を保持します。このヘッダーフィールドはオプションであるため、チェーン内のプロキシはこのヘッダーフィールドを更新しないことを選択できます。各フィールド値はセミコロンで区切られたリストです。このサブリストは、パラメータと識別子のペアで構成されています。パラメータと識別子のペアは、等号でグループ化されます。各パラメーターは、フィールド値ごとに複数回出現してはなりません。パラメータ名は大文字と小文字を区別しません。ヘッダーフィールド値は、ABNF構文で次のように定義できます。
Forwarded = 1#forwarded-element
転送済み= 1＃forwarded-element
forwarded-element = [ forwarded-pair ] *( ";" [ forwarded-pair ] )
forwarded-element = [forwarded-pair] *（ ";" [forwarded-pair]）
forwarded-pair = token "=" value
value = token / quoted-string
token = <Defined in [RFC7230], Section 3.2.6>
quoted-string = <Defined in [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".
「：」と「[]」は「トークン」の有効な文字ではないため、IPv6アドレスは「引用文字列」として書き込まれることに注意してください。
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.
新しい「転送」ヘッダーフィールド値を追加するプロキシサーバーは、コンマ区切り記号の後にある最後の既存の「転送」ヘッダーフィールドに値を追加するか、ヘッダーブロックの最後に新しいフィールドを追加できます。プロキシは、リクエストからすべての「転送された」ヘッダーフィールドを削除する場合があります。ただし、「Forwarded」ヘッダーフィールドが複数ある場合は、正しいヘッダーフィールドが更新されるようにする必要があります。
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 "by"は、プロキシのユーザーエージェント向けインターフェースを識別します。
o "for" identifies the node making the request to the proxy.
o 「for」は、プロキシへのリクエストを行うノードを識別します。
o "host" is the host request header field as received by the proxy.
o 「ホスト」は、プロキシが受信したホスト要求ヘッダーフィールドです。
o "proto" indicates what protocol was used to make the request.
o 「proto」は、要求を行うために使用されたプロトコルを示します。
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.
「by」パラメータは、リクエストがプロキシサーバーに送信されたインターフェースを公開するために使用されます。プロキシが「by」パラメータを使用することを選択した場合、そのデフォルト設定には、セクション6.3で説明されているように難読化された識別子が含まれる必要があります（SHOULD）。プロキシされたリクエストを受信するサーバーがアドレスベースの機能を必要とする場合、このパラメーターは代わりにIPアドレス（および、場合によってはポート番号）を含むことができます（MAY）。 3番目のオプションは、セクション6.2で説明されている「不明な」識別子です。
The syntax of a "by" value, after potential quoted-string unescaping, conforms to the "node" ABNF described in Section 6.
「by」値の構文は、引用符で囲まれた文字列がエスケープ解除された後、セクション6で説明されている「ノード」ABNFに準拠します。
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.
これは主に、この情報をバックエンドサーバーに転送するリバースプロキシによって追加されます。マルチホーム環境では、リクエストの送信元であるバックエンドサーバーに信号を送ることも興味深い場合があります。
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.
「for」パラメータは、リクエストを開始したクライアントと、プロキシのチェーン内の後続のプロキシに関する情報を開示するために使用されます。プロキシが「for」パラメータの使用を選択した場合、そのデフォルト設定には、セクション6.3で説明されているように難読化された識別子を含める必要があります（SHOULD）。プロキシされたリクエストを受信するサーバーがアドレスベースの機能を必要とする場合、このパラメーターは代わりにIPアドレス（および、場合によってはポート番号）を含むことができます（MAY）。 3番目のオプションは、セクション6.2で説明されている「不明な」識別子です。
The syntax of a "for" value, after potential quoted-string unescaping, conforms to the "node" ABNF described in Section 6.
「for」値の構文は、引用符で囲まれた文字列がエスケープ解除された後、セクション6で説明されている「ノード」ABNFに準拠します。
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.
これが完全に利用されるプロキシサーバーのチェーンでは、最初の「for」パラメーターは、要求が最初に行われたクライアントを開示し、その後に続くプロキシ識別子が続きます。チェーンの最後のプロキシは、「for」パラメータのリストの一部ではありません。ただし、最後のプロキシのIPアドレス、およびオプションでポート番号は、トランスポート層でリモートIPアドレスとしてすぐに使用できます。ただし、存在する場合は、前の「Forwarded」ヘッダーフィールドの「by」パラメータから最後のプロキシに関する情報を読み取る方が適切な場合があります。
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.
「host」パラメータは、「Host」ヘッダーフィールドの元の値を転送するために使用されます。これは、たとえば、リバースプロキシが「Host」ヘッダーフィールドを内部ホスト名に書き換えている場合に、オリジンサーバーで使用できます。
The syntax for a "host" value, after potential quoted-string unescaping, MUST conform to the Host ABNF described in Section 5.4 of [RFC7230].
「ホスト」値の構文は、引用符で囲まれた文字列がエスケープ解除される可能性がある場合、[RFC7230]のセクション5.4で説明されているホストABNFに準拠する必要があります。
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".
「proto」パラメータには、使用されるプロトコルタイプの値が含まれます。 「proto」値の構文は、引用符で囲まれた文字列がエスケープ解除された後、[RFC3986]のセクション3.1で定義され、[RFC4395]に従ってIANAに登録されたURIスキーム名に準拠する必要があります。一般的な値は「http」または「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.
たとえば、リバースプロキシが暗号オフローダーとしても使用される環境では、これにより、オリジンサーバーへのすべての接続が、たとえオリジンサーバーがドキュメント内のURLを書き換えて、ユーザーエージェントが要求した接続のタイプに一致させることができます。暗号化されていないHTTP。
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.
拡張機能では、追加のパラメーターと値を使用できます。拡張機能は、リバースプロキシ環境で特に役立ちます。すべての拡張パラメータは、「HTTP転送パラメータ」レジストリに登録する必要があります（SHOULD）。特定の拡張機能が広範囲に展開されることが予想される場合は、それらも標準化する必要があります（SHOULD）。これについては、セクション9で詳しく説明します。
The node identifier is one of the following:
ノード識別子は次のいずれかです。
o The client's IP address, with an optional port number
o オプションのポート番号を含むクライアントのIPアドレス
o A token indicating that the IP address of the client is not known to the proxy server
o クライアントのIPアドレスがプロキシサーバーに認識されていないことを示すトークン
o A generated token, allowing for tracing and debugging, while allowing the internal structure or sensitive information to be hidden
o 生成されたトークン。トレースとデバッグを可能にし、内部構造または機密情報を非表示にできます。
The node identifier is defined by the ABNF syntax as:
ノード識別子は、ABNF構文で次のように定義されます。
node = nodename [ ":" node-port ]
nodename = IPv4address / "[" IPv6address "]" /
"unknown" / obfnode
IPv4address = <Defined in [RFC3986], Section 3.2.2>
IPv6address = <Defined in [RFC3986], Section 3.2.2>
obfnode = "_" 1*( ALPHA / DIGIT / "." / "_" / "-")
node-port = port / obfport
port = 1*5DIGIT
obfport = "_" 1*(ALPHA / DIGIT / "." / "_" / "-")
DIGIT = <Defined in [RFC5234], Section 3.4>
ALPHA = <Defined in [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.
各識別子はオプションでポート識別子を持つことができ、たとえば、NATされた環境でのエンドポイントの識別を可能にします。 「ノードポート」は、そのポート番号、または実際のポート番号を難読化して生成されたトークンのいずれかで識別できます。難読化されたポートは、プロキシの所有者が要求をトレースする機能（デバッグ目的など）を望んでいるが、内部情報を明らかにしたくない場合に使用できます。
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 "-".
上記のABNFでは、「不明な」識別子にポート番号を追加することもできます。ただし、そのような表記の解釈は、ヘッダーフィールドにそのような値を追加するプロキシの所有者に任されています。 「obfport」とポートを区別するには、「obfport」に先行アンダースコアが必要です。さらに、「ALPHA」、「DIGIT」、および文字「。」、「_」、「-」のみで構成する必要があります。
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".
「：」は「トークン」で許可された文字ではないため、IPv6アドレスとノードポートが指定されたノード名は引用符で囲む必要があることに注意することが重要です。
Examples:
例：
"192.0.2.43:47011"
"[2001:db8:cafe::17]:47011"
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).
「IPv6address」と「IPv4address」のABNFルールは[RFC3986]で定義されています。 「IPv6address」は、テキスト表現の推奨事項[RFC5952]（小文字、ゼロの圧縮など）に準拠する必要があります（SHOULD）。
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.
[RFC1918]と[RFC4193]で定義されているように、IPアドレスは内部ネットのIPアドレスである可能性があることに注意してください。また、IPv6アドレスは常に角括弧で囲まれていることに注意してください。
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.
「不明な」識別子は、先行するエンティティのIDが不明な場合に使用されますが、プロキシサーバーは、要求の転送が行われたことを通知する必要があります。 1つの例は、着信要求のTCPソケットに直接アクセスせずに発信要求を生成するプロキシサーバープロセスです。
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:
生成された識別子は、内部IPアドレスを秘密にしたい場合に使用できますが、「転送」ヘッダーフィールドをトレースおよびデバッグに使用することはできます。これは、プロキシがなんらかのインターフェースラベルを使用していて、IPアドレスではなくそれらを渡したい場合にも役立ちます。サーバーが識別子を使用するために識別子の静的な割り当てが必要でない限り、難読化された識別子は、要求ごとにランダムに生成する必要があります（SHOULD）。サーバーが識別子が要求間で持続することを要求する場合、それらはクライアントIPアドレスより長く持続してはなりません。難読化された識別子を他の識別子と区別するには、先頭にアンダースコア「_」を付ける必要があります。さらに、「ALPHA」、「DIGIT」、および文字「。」、「_」、「-」のみで構成する必要があります。例：
Forwarded: for=_hidden, for=_SEVKISEK
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
HTTPリストでは、識別子の間に空白を入れることができ、リストは複数のヘッダーフィールドに分割される場合があることに注意してください。例として、ヘッダーフィールド
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
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.
このヘッダーフィールドを保持する必要がある場合と保持しない場合があります。直接転送されるリクエストは、それを保持し、場合によっては拡張する必要があります。単一の着信要求によってプロキシが複数の発信要求を行う場合、ヘッダーフィールドを保持する必要があるかどうかを決定するために特別な注意を払う必要があります。多くの場合、ヘッダーフィールドは保持する必要がありますが、発信要求が受信要求の直接の結果でない場合は、ヘッダーフィールドを保持しないでください。プロキシが304レスポンスでコンテンツの不一致を検出し、[RFC7232]のセクション4.1に従って無条件にリクエストを繰り返す場合も考慮してください。この場合、新しいリクエストは基本的に元のリクエストの直接の結果です。 、およびヘッダーフィールドはおそらく保持する必要があります。
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.
「Via」ヘッダーフィールド（[RFC7230]、セクション5.7.1を参照）は、このヘッダーフィールドと同様の使用例を持つヘッダーフィールドです。ただし、「Via」ヘッダーフィールドはプロキシ自体に関する情報のみを提供するため、プロキシサーバーに接続しているクライアントに関する情報は除外されます。一方、 "Forwarded"ヘッダーフィールドは、主な目的として、プロキシサーバーのクライアント側にある情報を中継します。 「Via」はすでに広く導入されているため、「Forwarded」が対処する問題に対処するためにその形式を変更することはできません。
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.
このヘッダーフィールドからの情報とViaヘッダーフィールドからの情報を組み合わせることができないことに注意してください。一部のプロキシは「転送済み」ヘッダーフィールドを更新しません。一部のプロキシはViaヘッダーフィールドを更新しません。一部のプロキシは両方を更新します。
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- *ヘッダーフィールドが存在する受信リクエストを取得する場合、賢明な方法で実行できる場合は、これらをこのドキュメントで説明されているヘッダーフィールドに変換することをお勧めします。リクエストに1つのタイプ（たとえば、X-Forwarded-For）しか含まれていない場合、各要素の前に「for =」を付けることで、これを「Forwarded」に変換できます。 IPv6アドレスはX-Forwarded-Forで引用できず、角括弧で囲まれていない場合がありますが、「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.
ただし、たとえばX-Forwarded-ForとX-Forwarded-Byの両方が存在する場合は、特別な注意が必要です。このような場合、既存のフィールドが追加された順序がわからないため、変換できない場合があります。また、X-Forwarded-Forヘッダーフィールドを削除すると、この新しいヘッダーフィールドのサポートをまだ実装していない当事者に問題が発生する可能性があることに注意してください。
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.
IPアドレス192.0.2.43のクライアントからの要求は、IPアドレス198.51.100.17のプロキシを通過し、次にIPアドレス203.0.113.60の別のプロキシを通過してから、オリジンサーバーに到達します。これは、たとえば、リバースプロキシを介してオリジンサーバーと通信する企業マルウェアフィルターの背後にあるオフィスクライアントである可能性があります。
o The HTTP request between the client and the first proxy has no "Forwarded" header field.
o クライアントと最初のプロキシ間のHTTPリクエストには、「転送」ヘッダーフィールドがありません。
o The HTTP request between the first and second proxy has a "Forwarded: for=192.0.2.43" header field.
o 1番目と2番目のプロキシ間のHTTPリクエストには、「Forwarded：for = 192.0.2.43」ヘッダーフィールドがあります。
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.
o 2番目のプロキシとオリジンサーバー間のHTTPリクエストには、「Forwarded：for = 192.0.2.43、for = 198.51.100.17; by = 203.0.113.60; proto = http; host = example.com」ヘッダーフィールドがあります。
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.
このHTTP拡張のサポートの欠如、またはこのネットワークコンポーネントに関する情報を開示しないというポリシーの決定により、接続チェーンのある時点で、「転送」ヘッダーフィールドの情報が更新されない場合があります。
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.
"Forwarded" HTTPヘッダーフィールドは、誤ってまたは悪意のある理由で、リクエストを行うクライアントを含むサーバーへの途中のすべてのノードによって変更される可能性があるため、正しいとは言えません。
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.
「転送された」HTTPヘッダーフィールドが正しいことを確認する1つの方法は、プロキシが正しいことを確認し、それらを信頼できるものとしてホワイトリストに登録することです。このアプローチには少なくとも2つの弱点があります。まず、リクエストがプロキシに届く前にリストされたIPアドレスのチェーンは信頼できません。第2に、プロキシとエンドポイント間の通信が保護されていない限り、ネットワークにアクセスできる攻撃者がデータを変更できます。
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.
「Forwarded」HTTPヘッダーフィールドは、NATまたはプロキシ設定の背後にあるネットワーク設定の内部構造を明らかにする可能性があり、これは望ましくない場合があります。これは、難読化された要素を使用するか、内部ノードがHTTPヘッダーフィールドを更新しないようにするか、または内部ネットワーク情報を明らかにするエントリを出力プロキシに削除させることによって対処できます。
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.
このヘッダーフィールドは、プロキシチェーン全体をクライアントに明らかにする可能性があるため、配信元サーバーまたは仲介者が応答メッセージにコピーしないでください。副作用として、ホスティング環境では、 "Forwarded"フィールドが使用されているTRACE要求が応答メッセージの本文に表示されるため、許可しないように特別な注意を払う必要があります。
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 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.
近年、プライバシーへの懸念が高まっています。ユーザーのプライバシーを確保することと、デバッグ、統計、場所に依存するコンテンツの生成などに役立つ情報を開示することの間にはトレードオフがあります。 "Forwarded" HTTPヘッダーフィールドは、意図的に、一部のユーザーがプライバシーを重視する情報を公開し、そのような用途を可能にします。プロキシの場合、HTTP要求にプライバシーセマンティクスを具体的に要求するヘッダーフィールドが含まれている場合、プロキシは「転送」ヘッダーフィールドを使用しないでください。
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.
このヘッダーフィールドの「for」パラメータで転送される可能性のあるクライアントのIPアドレスは、IPアドレスがクライアントを一意に識別できる可能性があるため、ユーザーが使用している演算子、そして、おそらくユーザーが地理的にどこにいるかの大まかな見積もり。
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.
「by」パラメータと「for」パラメータの両方のデフォルト設定には、難読化された識別子を含める必要があります（SHOULD）。これらの識別子はリクエストごとにランダムに生成する必要があります。リクエスト間で持続する識別子が必要な場合、それらのライフタイムは制限されるべきであり（SHOULD）、クライアントIPアドレスよりも長く持続すべきではありません（SHOULD NOT）。難読化された識別子を生成するときは、機密情報が含まれる可能性がないように注意する必要があります。
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.
ユーザーのIPアドレスは、広く使用されているヘッダーフィールドX-Forwarded-Forを使用して、プロキシによって既に転送されている場合があります。また、ユーザーがプロキシを通過せずに直接接続を行った場合、クライアントのIPアドレスがWebサーバーに送信されることにも注意してください。匿名化プロキシを積極的に選択しないユーザーは、IPアドレスをシールドすることに依存できません。追跡されるリスクを最小限に抑えたいユーザーは、ブラウザのヘッダーフィールドのフィンガープリントなど、他の方法で情報が漏洩する可能性があることにも注意する必要があります。 Forwardedヘッダーフィールド自体は、一意に識別されるクライアント識別子なしで使用された場合でも、クライアントの要求が通過するプロキシのチェーンを明らかにすることにより、フィンガープリントをより実行可能にする可能性があります。
This document specifies the HTTP header field listed below, which has been added to the "Permanent Message Header Field Names" registry defined in [RFC3864].
このドキュメントは、[RFC3864]で定義されている「Permanent Message Header Field Names」レジストリに追加された、以下にリストされているHTTPヘッダーフィールドを指定します。
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
ヘッダーフィールド：転送適用プロトコル：httpステータス：標準Author / Changeコントローラー：IETF（iesg@ietf.org）Internet Engineering Task Force仕様書：この仕様（セクション4）関連情報：なし
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.
"Forwarded"ヘッダーフィールドには、IANAが作成したパラメーターが含まれており、 "HTTP Forwarded Parameters"というタイトルの新しいレジストリが保持されています。初期登録は以下のとおりです。将来の割り当てでは、登録手順はIETFレビュー[RFC5226]です。すべての新しいパラメータのセキュリティとプライバシーへの影響は、完全に文書化する必要があります。新しいパラメーターとその値は、セクション4のABNFで定義されている転送ペアに準拠する必要があります。さらに、登録には短い説明を提供する必要があります。
+-------------+---------------------------------------+-------------+
| 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
表1：初期割り当て
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、Moskowitz、R.、Karrenberg、D.、Groot、G。、およびE. Lear、「プライベートインターネットのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
[RFC3864]クライン、G。、ノッティンガム、M。、およびJ.モーグル、「メッセージヘッダーフィールドの登録手順」、BCP 90、RFC 3864、2004年9月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、2005年1月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193] Hinden、R。およびB. Haberman、「Unique Local IPv6 Unicast Addresses」、RFC 4193、2005年10月。
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", BCP 35, RFC 4395, February 2006.
[RFC4395] Hansen、T.、Hardie、T。、およびL. Masinter、「新しいURIスキームのガイドラインと登録手順」、BCP 35、RFC 4395、2006年2月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、2008年1月。
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010.
[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.
[RFC7230]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing」、RFC 7230、2014年6月。
[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, June 2014.
[RFC7232]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Conditional Requests」、RFC 7232、2014年6月。
[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, June 2011.
[RFC6269]フォード、M。、ブーカデア、M。、デュランド、A。、リーバイス、P。、およびP.ロバーツ、「IPアドレス共有の問題」、RFC 6269、2011年6月。
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.
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に感謝しますノッティンガム、ジュリアンレシュケ、ジョンサリバン、ウィリータロー、ダンウィングのフィードバックを集めました。
Authors' Addresses
著者のアドレス
Andreas Petersson Opera Software
Andreas Petersson Operaソフトウェア
EMail: andreas@sbin.se
Martin Nilsson Opera Software S:t Larsgatan 12 Linkoping SE-582 24
Martin Nilsson Opera Software S：t Larsgatan 12 Linkoping SE-582 24
EMail: nilsson@opera.com