[要約] RFC 6967は、共有アドレス展開におけるホスト識別子（HOST_ID）の公開方法に関する潜在的な解決策の分析を提供しています。このRFCの目的は、共有アドレス環境でのホスト識別子の公開に関する問題を理解し、解決策の選択肢を提供することです。
Internet Engineering Task Force (IETF) M. Boucadair
Request for Comments: 6967 France Telecom
Category: Informational J. Touch
ISSN: 2070-1721 USC/ISI
P. Levis
France Telecom
R. Penno
Cisco
June 2013
Analysis of Potential Solutions for Revealing a Host Identifier (HOST_ID) in Shared Address Deployments
共有アドレスの展開でホスト識別子（HOST_ID）を明らかにするための潜在的なソリューションの分析
Abstract
概要
This document is a collection of potential solutions for revealing a host identifier (denoted as HOST_ID) when a Carrier Grade NAT (CGN) or application proxies are involved in the path. This host identifier could be used by a remote server to sort packets according to the sending host. The host identifier must be unique to each host under the same shared IP address.
このドキュメントは、キャリアグレードのNAT（CGN）またはアプリケーションプロキシがパスに関与している場合にホスト識別子（HOST_IDと表記）を明らかにするための潜在的なソリューションのコレクションです。このホスト識別子は、送信サーバーに従ってパケットをソートするためにリモートサーバーで使用できます。ホスト識別子は、同じ共有IPアドレスの下で各ホストに一意である必要があります。
This document analyzes a set of potential solutions for revealing a host identifier and does not recommend a particular solution, although it does highlight the hazards of some approaches.
このドキュメントは、ホスト識別子を明らかにするための潜在的なソリューションのセットを分析し、特定のソリューションを推奨しませんが、いくつかのアプローチの危険性を強調しています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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/rfc6967.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6967で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 4
2. On HOST_ID . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. HOST_ID and Privacy . . . . . . . . . . . . . . . . . . . . . 6
4. Detailed Solutions Analysis . . . . . . . . . . . . . . . . . 8
4.1. Use the Identification Field of the IPv4 Header (IP-ID) . 8
4.1.1. Description . . . . . . . . . . . . . . . . . . . . . 8
4.1.2. Analysis . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Define an IP Option . . . . . . . . . . . . . . . . . . . 9
4.2.1. Description . . . . . . . . . . . . . . . . . . . . . 9
4.2.2. Analysis . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Define a TCP Option . . . . . . . . . . . . . . . . . . . 9
4.3.1. Description . . . . . . . . . . . . . . . . . . . . . 9
4.3.2. Analysis . . . . . . . . . . . . . . . . . . . . . . 10
4.4. Inject Application Protocol Message Headers . . . . . . . 11
4.4.1. Description . . . . . . . . . . . . . . . . . . . . . 11
4.4.2. Analysis . . . . . . . . . . . . . . . . . . . . . . 12
4.5. PROXY Protocol . . . . . . . . . . . . . . . . . . . . . 13
4.5.1. Description . . . . . . . . . . . . . . . . . . . . . 13
4.5.2. Analysis . . . . . . . . . . . . . . . . . . . . . . 13
4.6. Assign Port Sets . . . . . . . . . . . . . . . . . . . . 14
4.6.1. Description . . . . . . . . . . . . . . . . . . . . . 14
4.6.2. Analysis . . . . . . . . . . . . . . . . . . . . . . 14
4.7. Host Identity Protocol (HIP) . . . . . . . . . . . . . . 14
4.7.1. Description . . . . . . . . . . . . . . . . . . . . . 14
4.7.2. Analysis . . . . . . . . . . . . . . . . . . . . . . 14
4.8. Use of a Notification Channel (e.g., ICMP) . . . . . . . 15
4.8.1. Description . . . . . . . . . . . . . . . . . . . . . 15
4.8.2. Analysis . . . . . . . . . . . . . . . . . . . . . . 15
4.9. Use Out-of-Band Mechanisms (e.g., Ident) . . . . . . . . 16
4.9.1. Description . . . . . . . . . . . . . . . . . . . . . 16
4.9.2. Analysis . . . . . . . . . . . . . . . . . . . . . . 17
5. Solutions Analysis: Synthesis . . . . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . 21
As reported in [RFC6269], several issues are encountered when an IP address is shared among several subscribers. These issues are encountered in various deployment contexts, e.g., Carrier-Grade NAT (CGN), application proxies, or Address plus Port (A+P) [RFC6346]. Examples of such issues are: implicit identification (Section 13.2 of [RFC6269]), spam (Section 13.3 of [RFC6269]), blacklisting a misbehaving host (Section 13.1 of [RFC6269]), or redirecting users with infected machines to a dedicated portal (Section 5.1 of [RFC6269]).
[RFC6269]で報告されているように、IPアドレスが複数のサブスクライバー間で共有されている場合、いくつかの問題が発生します。これらの問題は、キャリアグレードNAT（CGN）、アプリケーションプロキシ、アドレスプラスポート（A + P）[RFC6346]など、さまざまな展開状況で発生します。このような問題の例としては、暗黙的な識別（[RFC6269]のセクション13.2）、スパム（[RFC6269]のセクション13.3）、不正なホストのブラックリストへの登録（[RFC6269]のセクション13.1）、感染したマシンを持つユーザーを専用ポータルにリダイレクトするなどがあります。 （[RFC6269]のセクション5.1）。
In particular, some servers use the source IPv4 address as an identifier to treat some incoming connections differently. Due to the deployment of CGNs (e.g., NAT44 [RFC3022], NAT64 [RFC6146]), that address will be shared. In particular, when a server receives packets from the same source address, because this address is shared, the server does not know which host is the sending host [RFC6269]. The sole use of the IPv4 address is not sufficient to uniquely distinguish a host. As a mitigation, it is tempting to investigate ways that would disclose information to be used by the remote server as a means of uniquely disambiguating packets sent from hosts using the same IPv4 address.
特に、一部のサーバーはソースIPv4アドレスを識別子として使用して、着信接続を異なる方法で処理します。 CGN（NAT44 [RFC3022]、NAT64 [RFC6146]など）の導入により、そのアドレスは共有されます。特に、サーバーが同じ送信元アドレスからパケットを受信するとき、このアドレスは共有されているため、サーバーは送信元ホストがどのホストであるかを知りません[RFC6269]。ホストを一意に区別するには、IPv4アドレスを単独で使用するだけでは不十分です。緩和策として、同じIPv4アドレスを使用してホストから送信されたパケットを一意に区別する手段としてリモートサーバーが使用する情報を開示する方法を調査するのは魅力的です。
The risk of not mitigating these issues include: OPEX (Operational Expenditure) increase for IP connectivity service providers (costs induced by calls to a hotline), revenue loss for content providers (loss of users' audience), and customers' dissatisfaction (low quality of experience, service segregation, etc.).
これらの問題を軽減しないリスクには、IP接続サービスプロバイダーのOPEX（運用支出）の増加（ホットラインへの通話によって引き起こされるコスト）、コンテンツプロバイダーの収益の損失（ユーザーの聴衆の損失）、顧客の不満（低品質）などがあります。経験、サービスの分離など）。
The purpose of this document is to analyze a set of alternative channels to convey a host identifier and to assess to what extent the alternatives solve the problem described in Section 2. The evaluation is intended to be comprehensive, regardless of the maturity or validity of any currently known or proposed solution. The alternatives analyzed in the document are listed below:
このドキュメントの目的は、一連の代替チャネルを分析してホスト識別子を伝え、セクション2で説明されている問題を代替手段がどの程度解決するかを評価することです。評価は、成熟度や妥当性に関係なく、包括的であることを目的としています。現在知られている、または提案されているソリューション。ドキュメントで分析された代替案を以下に示します。
o Use the Identification field of the IP header (denoted as IP-ID, Section 4.1). o Define a new IP option (Section 4.2). o Define a new TCP option (Section 4.3). o Inject application headers (Section 4.4). o Enable Proxy Protocol (Section 4.5). o Assign port sets (Section 4.6). o Activate HIP (Host Identity Protocol) (Section 4.7). o Use a notification channel (Section 4.8). o Use an out-of-band mechanism (Section 4.9).
o IPヘッダーの識別フィールドを使用します（IP-IDと表記、セクション4.1）。 o新しいIPオプションを定義します（セクション4.2）。 o新しいTCPオプションを定義します（セクション4.3）。 oアプリケーションヘッダーを挿入します（セクション4.4）。 oプロキシプロトコルを有効にします（セクション4.5）。 oポートセットを割り当てます（セクション4.6）。 o HIP（ホスト識別プロトコル）を有効にします（セクション4.7）。 o通知チャネルを使用します（セクション4.8）。 o帯域外メカニズムを使用します（セクション4.9）。
A synthesis is provided in Section 5, while the detailed analysis is elaborated in Section 4.
合成についてはセクション5で説明し、詳細な分析についてはセクション4で詳しく説明します。
Section 3 discusses privacy issues common to all proposed solutions. It is out of scope of this document to elaborate on privacy issues specific to each solution.
セクション3では、提案されたすべてのソリューションに共通するプライバシーの問題について説明します。各ソリューションに固有のプライバシー問題について詳しく説明することは、このドキュメントの範囲外です。
This document does not include any recommendations because the working group felt that it was too premature to include one.
ワーキンググループは1つを含めるには時期尚早であると感じたため、このドキュメントには推奨事項は含まれていません。
Policies that rely on source IP addresses and that are enforced by some servers will be applied to all hosts sharing the same IP address. For example, blacklisting the IP address of a spammer host will result in all other hosts that share that address having their access to the requested service restricted. [RFC6269] describes the issues in detail. Therefore, due to address sharing, servers need extra information beyond the source IP address to differentiate the sending host. We call this information the HOST_ID.
ソースIPアドレスに依存し、一部のサーバーによって適用されるポリシーは、同じIPアドレスを共有するすべてのホストに適用されます。たとえば、スパマーホストのIPアドレスをブラックリストに登録すると、そのアドレスを共有する他のすべてのホストは、要求されたサービスへのアクセスが制限されます。 [RFC6269]は問題を詳細に説明しています。したがって、アドレス共有のため、サーバーは送信元ホストを区別するためにソースIPアドレス以外の追加情報を必要とします。この情報をHOST_IDと呼びます。
The HOST_ID identifies a host under a shared IP address. Privacy-related considerations are discussed in Section 3.
HOST_IDは、共有IPアドレスでホストを識別します。プライバシー関連の考慮事項については、セクション3で説明します。
Within this document, a host can be any computer located behind a Home Gateway or directly connected to an address-sharing function located in the network provider's domain (typically this would be the Home Gateway itself).
このドキュメントでは、ホストは、ホームゲートウェイの背後にあるコンピューター、またはネットワークプロバイダーのドメインにあるアドレス共有機能に直接接続されている任意のコンピューターです（通常、これはホームゲートウェイ自体です）。
Because the HOST_ID is used by a remote server to sort out the packets by sending host, the HOST_ID must be unique to each host under the same shared IP address, where possible. In the case where only the Home Gateway is revealed to the operator side of the translation function, the HOST_ID need only be unique to the Home Gateway. The HOST_ID does not need to be globally unique. Of course, the combination of the (public) IP source address and the identifier (i.e., HOST_ID) ends up being unique.
リモートサーバーはHOST_IDを使用して、ホストを送信することでパケットを整理するため、可能な場合は、HOST_IDは同じ共有IPアドレスの下にある各ホストで一意である必要があります。ホームゲートウェイのみが変換機能のオペレーター側に公開されている場合、HOST_IDはホームゲートウェイに対してのみ一意である必要があります。 HOST_IDはグローバルに一意である必要はありません。もちろん、（パブリック）IPソースアドレスと識別子（つまり、HOST_ID）の組み合わせは一意になります。
If the HOST_ID is conveyed at the IP level, all packets will have to bear the identifier. If it is conveyed at a higher connection-oriented level, the identifier is only needed once in the session establishment phase (for instance, a TCP three-way handshake), then all packets received in this session will be attributed to the HOST_ID designated during the session opening.
HOST_IDがIPレベルで伝達される場合、すべてのパケットは識別子を保持する必要があります。それがより高い接続指向レベルで伝達される場合、識別子はセッション確立フェーズで一度だけ必要です（たとえば、TCP 3ウェイハンドシェイク）。このセッションで受信されたすべてのパケットは、中に指定されたHOST_IDに起因します。セッションの開始。
Within this document, we assume the operator-side address-sharing function injects the HOST_ID. Another deployment option to avoid potential performance degradation is to let the host or Home Gateway inject its HOST_ID, but the address-sharing function will check its content (just like an IP anti-spoofing function). For some proposals, the HOST_ID is retrieved using an out-of-band mechanism or signaled in a dedicated notification channel.
このドキュメントでは、オペレーター側のアドレス共有関数がHOST_IDを挿入すると想定しています。潜在的なパフォーマンス低下を回避するための別の展開オプションは、ホストまたはホームゲートウェイにHOST_IDを挿入させることですが、アドレス共有機能は（IPスプーフィング防止機能と同様に）その内容をチェックします。一部の提案では、HOST_IDは、帯域外メカニズムを使用して取得されるか、専用の通知チャネルで通知されます。
For A+P [RFC6346] and its variants, port set announcements may be needed as discussed in Section 4.6.
A + P [RFC6346]およびそのバリアントについては、セクション4.6で説明するように、ポートセットのアナウンスが必要になる場合があります。
Security considerations are common to all analyzed solutions (see Section 6). Privacy-related aspects are discussed in Section 3.
セキュリティに関する考慮事項は、分析されるすべてのソリューションに共通です（セクション6を参照）。プライバシー関連の側面については、セクション3で説明します。
The HOST_ID can be ambiguous for hosts with multiple interfaces or multiple addresses assigned to a single interface. HOST_IDs that are the same may be used to imply or infer the same end system, but HOST_IDs that are different should not be used to imply or infer whether the end systems are the same or different.
HOST_IDは、複数のインターフェースまたは単一のインターフェースに割り当てられた複数のアドレスを持つホストの場合にあいまいになる可能性があります。同じHOST_IDを使用して、同じエンドシステムを示唆または推測できますが、異なるHOST_IDを使用して、エンドシステムが同じか異なるかを示唆または推測しないでください。
IP address sharing is motivated by a number of different factors. For years, many network operators have conserved public IPv4 addresses by making use of Customer Premises Equipment (CPE) that assigns a single public IPv4 address to all hosts within the customer's local area network and uses NAT [RFC3022] to translate between locally unique private IPv4 addresses and the CPE's public address. With the exhaustion of IPv4 address space, address sharing between customers on a much larger scale is likely to become much more prevalent. While many individual users are unaware of and uninvolved in decisions about whether their unique IPv4 addresses get revealed when they send data via IP, some users realize privacy benefits associated with IP address sharing, and some may even take steps to ensure that NAT functionality sits between them and the public Internet. IP address sharing makes the actions of all users behind the NAT function unattributable to any single host, creating room for abuse but also providing some identity protection for non-abusive users who wish to transmit data with reduced risk of being uniquely identified.
IPアドレスの共有は、さまざまな要因によって動機付けられます。長年にわたり、多くのネットワークオペレーターは、顧客のローカルエリアネットワーク内のすべてのホストに単一のパブリックIPv4アドレスを割り当て、NAT [RFC3022]を使用してローカルで一意のプライベートIPv4間を変換するCustomer Premises Equipment（CPE）を利用して、パブリックIPv4アドレスを保存してきましたアドレスとCPEのパブリックアドレス。 IPv4アドレス空間が使い果たされると、はるかに大規模な顧客間のアドレス共有がはるかに普及する可能性があります。多くの個々のユーザーは、IP経由でデータを送信したときに固有のIPv4アドレスが公開されるかどうかを知らず、意思決定に関与しませんが、一部のユーザーはIPアドレス共有に関連するプライバシー上の利点を実現し、一部のユーザーはNAT機能が間にあることを確認するための措置を講じるそれらと公共のインターネット。 IPアドレスの共有により、NAT機能の背後にあるすべてのユーザーのアクションが単一のホストに起因せず、悪用の余地が生まれるだけでなく、一意に識別されるリスクを減らしてデータを送信したい非攻撃的なユーザーにID保護を提供します。
The proposals considered in this document help differentiate between hosts that share a public IP address. The extent of that differentiation depends on what information is included in the HOST_ID.
このドキュメントで検討されている提案は、パブリックIPアドレスを共有するホストを区別するのに役立ちます。その区別の程度は、HOST_IDに含まれる情報によって異なります。
The volatility of the HOST_ID information is similar to that of the internal IP address: a distinct HOST_ID may be used by the address-sharing function when the host reboots or gets a new internal IP address. As with persistent IP addresses, persistent HOST_IDs facilitate user tracking over time.
HOST_ID情報の変動性は、内部IPアドレスの変動性に似ています。ホストが再起動するか、新しい内部IPアドレスを取得するときに、アドレス共有機能によって個別のHOST_IDが使用される場合があります。永続的なIPアドレスと同様に、永続的なHOST_IDは、長期にわたるユーザーの追跡を容易にします。
As a general matter, the HOST_ID proposals do not seek to make hosts any more identifiable than they would be if they were using a public, non-shared IP address. However, depending on the solution proposal, the addition of HOST_ID information may allow a device to be fingerprinted more easily than it otherwise would be. To prevent this, the following design considerations are to be taken into account:
一般的な問題として、HOST_IDプロポーザルは、ホストが非共有のパブリックIPアドレスを使用している場合よりも、ホストを識別可能にすることを目指していません。ただし、ソリューションの提案によっては、HOST_ID情報を追加することで、他の方法よりも簡単にデバイスのフィンガープリントを作成できる場合があります。これを防ぐには、次の設計上の考慮事項を考慮する必要があります。
o It is recommended that HOST_IDs be limited to providing local uniqueness rather than global uniqueness.
o HOST_IDは、グローバルな一意性ではなくローカルな一意性の提供に限定することをお勧めします。
o The address-sharing function should not use permanent HOST_ID values.
o アドレス共有機能では、恒久的なHOST_ID値を使用しないでください。
Should multiple solutions be combined (e.g., TCP option and Forwarded header) that include different pieces of information in the HOST_ID, fingerprinting may become even easier. To prevent this, an address-sharing function that is able to inject HOST_IDs in several layers should reveal the same subsets of information at each layer. For example, if one layer references the lower 16 bits of an IPv4 address, the other layer should reference these 16 bits too.
HOST_IDにさまざまな情報を含む複数のソリューション（TCPオプションと転送ヘッダーなど）を組み合わせると、フィンガープリント作成がさらに簡単になる場合があります。これを防ぐために、HOST_IDを複数のレイヤーに挿入できるアドレス共有関数は、各レイヤーで同じ情報のサブセットを公開する必要があります。たとえば、1つの層がIPv4アドレスの下位16ビットを参照する場合、他の層もこれらの16ビットを参照する必要があります。
A HOST_ID can be spoofed, as this is also the case for spoofing an IP address. Furthermore, users of network-based anonymity services (like Tor [TOR]) may be capable of stripping HOST_ID information before it reaches its destination.
HOST_IDは、IPアドレスをスプーフィングする場合にも当てはまるため、スプーフィングされる可能性があります。さらに、ネットワークベースの匿名サービス（Tor [TOR]など）のユーザーは、宛先に到達する前にHOST_ID情報を取り除くことができる場合があります。
In order to control the information revealed to external parties, an address-sharing function should be able to strip, rewrite, and add HOST_ID fields.
外部の関係者に公開される情報を制御するには、アドレス共有機能がHOST_IDフィールドを削除、書き換え、追加できる必要があります。
An address-sharing function may be configured to enforce different end-user preferences with regards to HOST_ID injection. For example, HOST_ID injection can be disabled for some users. This feature is policy based and deployment specific.
アドレス共有機能は、HOST_IDインジェクションに関してさまざまなエンドユーザー設定を強制するように構成できます。たとえば、一部のユーザーに対してHOST_IDインジェクションを無効にすることができます。この機能はポリシーベースで、展開固有です。
HOST_ID specification document(s) should explain the privacy impact of the solutions they specify, including the extent of HOST_ID uniqueness and persistence, assumptions made about the lifetime of the HOST_ID, whether and how the HOST_ID can be obfuscated or recycled, whether location information can be exposed, and the impact of the use of the HOST_ID on device or implementation fingerprinting. [IAB-PRIVACY] provides further guidance.
HOST_IDの仕様書では、HOST_IDの一意性と永続性の範囲、HOST_IDの有効期間に関する想定、HOST_IDを難読化またはリサイクルできるかどうか、場所情報が可能かどうかなど、それらが指定するソリューションのプライバシーへの影響を説明する必要があります。公開され、HOST_IDの使用がデバイスまたは実装のフィンガープリントに与える影響。 [IAB-PRIVACY]は、さらなるガイダンスを提供します。
For more discussion about privacy, refer to [RFC6462].
プライバシーの詳細については、[RFC6462]を参照してください。
The IPv4 ID (Identification field of IP header, i.e., IP-ID) can be used to insert information that uniquely distinguishes a host among those sharing the same IPv4 address. Use of the IP-ID as a channel to convey the HOST_ID is a theoretical construct (i.e., it is an undocumented proposal).
IPv4 ID（IPヘッダーの識別フィールド、つまりIP-ID）を使用して、同じIPv4アドレスを共有するホスト間でホストを一意に区別する情報を挿入できます。 HOST_IDを伝達するチャネルとしてIP-IDを使用することは、理論的な構成です（つまり、文書化されていない提案です）。
An address-sharing function can rewrite the IP-ID field to insert a value that is unique to the host (16 bits are sufficient to uniquely disambiguate hosts sharing the same IP address). The address-sharing function injecting the HOST_ID must follow the rules defined in [RFC6864]; in particular, the same HOST_ID is not reassigned to another host sharing the same IP address during a given time interval.
アドレス共有機能は、IP-IDフィールドを書き換えて、ホストに固有の値を挿入できます（同じIPアドレスを共有するホストを一意に区別するには、16ビットで十分です）。 HOST_IDを挿入するアドレス共有関数は、[RFC6864]で定義された規則に従う必要があります。特に、同じHOST_IDは、特定の時間間隔で同じIPアドレスを共有する別のホストに再割り当てされません。
A variant of this approach relies upon the format of certain packets, such as TCP SYN, where the IP-ID can be modified to contain a 16-bit HOST_ID.
このアプローチのバリアントは、TCP SYNなどの特定のパケットのフォーマットに依存しています。IP-IDを変更して、16ビットのHOST_IDを含めることができます。
Address-sharing devices using this solution would be required to indicate that they do so, possibly using a special DNS record.
このソリューションを使用しているアドレス共有デバイスは、特別なDNSレコードを使用している可能性があることを示す必要があります。
This usage is not consistent with the fragment reassembly use of the Identification field [RFC0791] or the updated handling rules for the Identification field [RFC6864].
この使用法は、識別フィールド[RFC0791]のフラグメント再構成の使用または識別フィールド[RFC6864]の更新された処理規則と一致していません。
Complications may arise if the packet is fragmented before reaching the device that is injecting the HOST_ID. To appropriately handle those packet fragments, the address-sharing function will need to maintain a lot of state.
HOST_IDを挿入しているデバイスに到達する前にパケットがフラグメント化されている場合は、問題が発生する可能性があります。これらのパケットフラグメントを適切に処理するには、アドレス共有機能が多くの状態を維持する必要があります。
Another complication to be encountered is where translation is balanced among several NATs; setting the appropriate HOST_ID by a given NAT would alter the coordination between those NATs. Of course, one can argue that this coordinated NAT scenario is not a typical deployment scenario; regardless, using the IP-ID as a channel to convey a HOST_ID is ill-advised.
遭遇するもう1つの問題は、変換が複数のNAT間でバランスが取れている場合です。特定のNATによって適切なHOST_IDを設定すると、それらのNAT間の調整が変更されます。もちろん、この調整されたNATシナリオは典型的な展開シナリオではないと主張できます。とにかく、HOST_IDを伝達するチャネルとしてIP-IDを使用することはお勧めできません。
An alternate way to convey the HOST_ID is to define an IP option [RFC0791]. A HOST_ID IP option can be inserted by the address-sharing function to uniquely distinguish a host among those sharing the same IP address. An example of such an option is documented in [REVEAL-IP]. This IP option allows the conveyance of an IPv4 address, an IPv6 prefix, a Generic Routing Encapsulation (GRE) key, an IPv6 Flow Label, etc.
HOST_IDを伝達する別の方法は、IPオプション[RFC0791]を定義することです。 HOST_ID IPオプションをアドレス共有機能によって挿入して、同じIPアドレスを共有するホスト間でホストを一意に区別できます。そのようなオプションの例は、[REVEAL-IP]に文書化されています。このIPオプションを使用すると、IPv4アドレス、IPv6プレフィックス、Generic Routing Encapsulation（GRE）キー、IPv6フローラベルなどを伝達できます。
An IP option may also be used as described in Section 4.6 of [RFC3022].
[RFC3022]のセクション4.6で説明されているように、IPオプションを使用することもできます。
This proposal can apply to any transport protocol. However, it is widely known that routers and other middleboxes filter IP options (e.g., drop IP packets with unknown IP options, strip unknown IP options, etc.).
この提案は、任意のトランスポートプロトコルに適用できます。ただし、ルーターやその他のミドルボックスがIPオプションをフィルタリングすることは広く知られています（たとえば、不明なIPオプションを含むIPパケットをドロップしたり、不明なIPオプションを取り除いたりするなど）。
Injecting the HOST_ID IP option introduces some implementation complexity in the following cases:
HOST_ID IPオプションを挿入すると、次の場合に実装が複雑になります。
o The packet is at or close to the MTU size.
o パケットはMTUサイズまたはそれに近いサイズです。
o The options space is exhausted.
o オプションスペースが使い果たされました。
Previous studies demonstrated that "IP Options are not an option" (refer to [Not_An_Option] and [Options]).
以前の調査では、「IPオプションはオプションではない」ことが示されていました（[Not_An_Option]および[Options]を参照）。
In conclusion, using an IP option to convey a HOST_ID is not viable.
結論として、HOST_IDを伝えるためにIPオプションを使用することは現実的ではありません。
The HOST_ID may be conveyed in a dedicated TCP option. An example is specified in [REVEAL-TCP]. This option encloses the TCP client's identifier (e.g., the lower 16 bits of its IPv4 address, its VLAN ID, VRF ID, or subscriber ID). The address-sharing device inserts this TCP option into the TCP SYN packet.
HOST_IDは、専用のTCPオプションで伝達できます。例は[REVEAL-TCP]で指定されています。このオプションは、TCPクライアントの識別子（IPv4アドレスの下位16ビット、VLAN ID、VRF ID、またはサブスクライバーIDなど）を囲みます。アドレス共有デバイスは、このTCPオプションをTCP SYNパケットに挿入します。
Using a new TCP option to convey the HOST_ID does not require any modification to the applications, but it is applicable only for TCP-based applications. Applications relying on other transport protocols are therefore left unsolved.
新しいTCPオプションを使用してHOST_IDを伝達する場合、アプリケーションを変更する必要はありませんが、TCPベースのアプリケーションにのみ適用できます。したがって、他のトランスポートプロトコルに依存するアプリケーションは解決されません。
[REVEAL-TCP] discusses the interference with other TCP options.
[REVEAL-TCP]は、他のTCPオプションとの干渉について説明しています。
The risk of session failure due to handling a new TCP option is low as measured in [Options]. [REVEAL-TCP-EXP] provides a detailed implementation and experimentation report of a HOST_ID TCP option. This document provides an in-depth investigation of the impact of implementing HOST_ID on the host, the address-sharing function, and the enforcement of policies at the server side. It also reports a failure ratio of 0.103% among the top 100,000 websites.
[オプション]で測定されるように、新しいTCPオプションの処理によるセッション障害のリスクは低いです。 [REVEAL-TCP-EXP]は、HOST_ID TCPオプションの詳細な実装および実験レポートを提供します。このドキュメントでは、ホストへのHOST_IDの実装の影響、アドレス共有機能、およびサーバー側でのポリシーの実施について詳細に調査します。また、上位100,000のWebサイトの失敗率は0.103％と報告されています。
Some downsides have been identified with defining a TCP option to reveal a host identity:
ホストIDを明らかにするためのTCPオプションを定義することで、いくつかの欠点が確認されています。
o Conveying an IP address in a TCP option may be seen as a violation of OSI layers, but since IP addresses are already used for the checksum computation, this is not seen as a blocking point. Moreover, the updated version of [REVEAL-TCP] no longer allows conveyance of a full IP address because the HOST_ID is encoded in 16 bits.
o TCPオプションでIPアドレスを伝達すると、OSI層の違反と見なされる場合がありますが、IPアドレスはチェックサムの計算にすでに使用されているため、これはブロッキングポイントとは見なされません。さらに、[REVEAL-TCP]の更新バージョンでは、HOST_IDが16ビットでエンコードされているため、完全なIPアドレスを伝達できなくなりました。
o TCP option space is limited and might be consumed by the TCP client. [REVEAL-TCP-EXP] discusses two approaches to sending the HOST_ID: sending the HOST_ID in the TCP SYN (which consumes more bytes in the TCP header of the TCP SYN) and sending the HOST_ID in a TCP ACK (which consumes only two bytes in the TCP SYN).
o TCPオプションスペースは制限されており、TCPクライアントによって消費される可能性があります。 [REVEAL-TCP-EXP]では、HOST_IDを送信する2つの方法について説明します。TCPSYNでHOST_IDを送信する（TCP SYNのTCPヘッダーでより多くのバイトを消費する）とTCP ACKでHOST_IDを送信する（2バイトのみを消費する） TCP SYNで）。
o Content providers may find it more desirable to receive the HOST_ID in the TCP SYN, as that more closely preserves the HOST_ID received in the source IP address as per current practices. Moreover, sending the HOST_ID in the TCP SYN does not interfere with [FASTOPEN]. In the ACK mode, if the server is configured to deliver different data based on HOST_ID, then it would have to wait for the ACK before transmitting data.
o コンテンツプロバイダーは、TCP SYNでHOST_IDを受信する方が望ましい場合があります。これは、現在の慣行に従って、送信元IPアドレスで受信したHOST_IDをより厳密に保持するためです。さらに、TCP SYNでHOST_IDを送信しても、[FASTOPEN]は妨害されません。 ACKモードでは、HOST_IDに基づいて異なるデータを配信するようにサーバーが構成されている場合、データを送信する前にACKを待機する必要があります。
o HOST_ID mechanisms need to be aware of end-to-end (E2E) issues and avoid interfering with them. One example of such interference would be injecting or removing TCP options of transited packets; another such interference involves terminating and re-originating TCP connections not belonging to the transit device. The HOST_ID TCP option handled by the source node avoids this issue.
o HOST_IDメカニズムは、エンドツーエンド（E2E）の問題を認識し、それらに干渉しないようにする必要があります。そのような干渉の1つの例は、通過したパケットのTCPオプションを挿入または削除することです。別のこのような干渉には、中継デバイスに属していないTCP接続の終了と再発信が含まれます。ソースノードによって処理されるHOST_ID TCPオプションは、この問題を回避します。
o Injecting the HOST_ID TCP option introduces some implementation complexity if the options space is exhausted. Specification document(s) should specify the behavior of the address-sharing function in detail in such a case.
o HOST_ID TCPオプションを挿入すると、オプションのスペースが使い果たされると、実装が複雑になります。そのような場合の仕様書では、アドレス共有機能の動作を詳細に指定する必要があります。
o It is more complicated to implement sending the HOST_ID in a TCP ACK, as it can introduce MTU issues if the ACK packet also contains TCP data or if a TCP segment is lost. Note that MTU complications can be experienced if user data is included in a SYN packet (e.g., [FASTOPEN]).
o ACKパケットにTCPデータも含まれている場合、またはTCPセグメントが失われた場合にMTUの問題が発生する可能性があるため、TCP ACKでのHOST_IDの送信の実装はより複雑です。ユーザーデータがSYNパケットに含まれている場合、MTUが複雑になる可能性があることに注意してください（[FASTOPEN]など）。
o When there are several NATs in the path, the original HOST_ID may be lost. The loss of the original HOST_ID may not be a problem, as the target usage is between proxies or between a CGN and server. Only the information leaked in the last communication leg (i.e., between the last address-sharing function and the server) is likely to be useful.
o パスに複数のNATがある場合、元のHOST_IDが失われる可能性があります。ターゲットの使用はプロキシ間またはCGNとサーバー間であるため、元のHOST_IDが失われても問題にはなりません。最後の通信レッグ（つまり、最後のアドレス共有機能とサーバーの間）で漏洩した情報のみが役立つ可能性があります。
o Interference with usages such as a Forwarded HTTP header (see Section 4.4) should be elaborated to specify the behavior of servers when both options are used; in particular, specify which information to use: the content of the TCP option or what is conveyed in the application headers.
o Forwarded HTTPヘッダー（セクション4.4を参照）などの使用法との干渉は、両方のオプションを使用する場合のサーバーの動作を指定するために詳しく説明する必要があります。特に、使用する情報を指定します。TCPオプションの内容またはアプリケーションヘッダーで伝えられるものを指定します。
o When load balancers or proxies are in the path, this option does not allow the preservation of the original source IP address and source port. Preserving such information is required for logging purposes (e.g., [RFC6302]). [REVEAL-TCP-EXP] defines a TCP option that allows various combinations of source information (e.g., source port, source port and source IP address, source IPv6 prefix, etc.) to be revealed.
o ロードバランサーまたはプロキシがパスにある場合、このオプションでは元の送信元IPアドレスと送信元ポートを保持できません。このような情報を保存することは、ロギングの目的で必要です（例、[RFC6302]）。 [REVEAL-TCP-EXP]は、送信元情報（送信元ポート、送信元ポートと送信元IPアドレス、送信元IPv6プレフィックスなど）のさまざまな組み合わせを明らかにできるようにするTCPオプションを定義します。
More discussion about issues raised when extending TCP can be found at [ExtendTCP].
TCPの拡張時に発生する問題についての詳細な議論は[ExtendTCP]にあります。
Another option is to not require any change within the transport or the IP levels but to convey the required information that will be used to disambiguate hosts at the application payload. The format of the conveyed information and the related semantics depend on its application (e.g., HTTP, SIP, SMTP, etc.).
別のオプションは、トランスポートまたはIPレベル内の変更を必要とせず、アプリケーションペイロードでホストを明確にするために使用される必要な情報を伝えることです。伝達される情報の形式と関連するセマンティクスは、そのアプリケーション（HTTP、SIP、SMTPなど）によって異なります。
Related mechanisms could be developed for other application-layer protocols, but the discussion in this document is limited to HTTP and similar protocols.
他のアプリケーション層プロトコル用に関連するメカニズムを開発することもできますが、このドキュメントの説明はHTTPおよび類似のプロトコルに限定されています。
For HTTP, the Forwarded header [HTTP-FRWD] can be used to display the original IP address when an address-sharing device is involved. Service providers operating address-sharing devices can enable the feature of injecting the Forwarded header, which will enclose the original IPv4 address or the IPv6 prefix part (see the example shown in Figure 1). The address-sharing device has to strip all included Forwarded headers before injecting its own. Servers may rely on the contents of this field to enforce some policies such as blacklisting misbehaving users.
HTTPの場合、Forwardedヘッダー[HTTP-FRWD]を使用して、アドレス共有デバイスが関係する場合に元のIPアドレスを表示できます。アドレス共有デバイスを操作するサービスプロバイダーは、元のIPv4アドレスまたはIPv6プレフィックス部分を囲む転送ヘッダーを挿入する機能を有効にできます（図1の例を参照）。アドレス共有デバイスは、それを挿入する前に、含まれているすべてのForwardedヘッダーを取り除く必要があります。サーバーは、このフィールドの内容に依存して、誤動作しているユーザーをブラックリストに登録するなど、いくつかのポリシーを適用する場合があります。
Note that [HTTP-FRWD] standardizes the Forwarded header field, to replace the de facto (and not standard) X-Forwarded-For (XFF) header.
[HTTP-FRWD]はForwardedヘッダーフィールドを標準化し、事実上の（標準ではない）X-Forwarded-For（XFF）ヘッダーを置き換えることに注意してください。
Forwarded: for=192.0.2.1,for=[2001:db8::1]
Forwarded: proto=https;by=192.0.2.15
Figure 1: Example of Forwarded-For
図1：Forwarded-Forの例
Not all applications impacted by address sharing can support the ability to disclose the original IP address. Only a subset of protocols (e.g., HTTP) can rely on this solution.
アドレス共有の影響を受けるすべてのアプリケーションが、元のIPアドレスを開示する機能をサポートできるわけではありません。プロトコルのサブセット（HTTPなど）だけがこのソリューションに依存できます。
For the HTTP case, to prevent users from injecting invalid HOST_IDs, an initiative has been launched by Wikimedia to maintain a list of trusted ISPs (Internet Service Providers) using XFF (see the list available at [Trusted_ISPs]). If an address-sharing device is on the list of trusted XFF ISPs, users editing Wikimedia located behind the address-sharing device will appear to be editing from their "original" IP address and not from the NATed IP address. If an offending activity is detected, individual hosts can be blacklisted instead of blacklisting all hosts sharing the same IP address.
HTTPの場合、ユーザーが無効なHOST_IDを挿入しないようにするために、XFFを使用して信頼できるISP（インターネットサービスプロバイダー）のリストを維持するイニシアチブがウィキメディアによって開始されました（[Trusted_ISPs]で利用可能なリストを参照）。アドレス共有デバイスが信頼できるXFF ISPのリストにある場合、アドレス共有デバイスの背後にあるWikimediaを編集しているユーザーは、NATされたIPアドレスからではなく、「元の」IPアドレスから編集しているように見えます。問題のあるアクティビティが検出された場合、同じIPアドレスを共有するすべてのホストをブラックリストに登録する代わりに、個々のホストをブラックリストに登録できます。
XFF header injection is a common practice of load balancers. When a load balancer is in the path, the original content of any included XFF header should not be stripped. Otherwise, the information about the "origin" IP address will be lost.
XFFヘッダーインジェクションは、ロードバランサーの一般的な方法です。ロードバランサーがパスにある場合、含まれているXFFヘッダーの元のコンテンツは削除しないでください。そうしないと、「元の」IPアドレスに関する情報が失われます。
When several address-sharing devices are crossed, the Forwarded header can convey the list of IP addresses (e.g., Figure 1). The origin HOST_ID can be exposed to the target server.
複数のアドレス共有デバイスが交差する場合、転送ヘッダーはIPアドレスのリストを伝達できます（図1など）。オリジンHOST_IDはターゲットサーバーに公開できます。
Injecting the Forwarded header also introduces some implementation complexity if the HTTP message is at or close to the MTU size.
Forwardedヘッダーを挿入すると、HTTPメッセージがMTUサイズ以下の場合、実装が複雑になります。
It has been reported that some HTTP proxy implementations may encounter parsing issues when injecting an XFF header.
XFFヘッダーを挿入するときに、一部のHTTPプロキシ実装で解析の問題が発生する可能性があることが報告されています。
Injecting the Forwarded header for all HTTPS traffic is infeasible. This may be problematic given the current HTTPS usage trends.
すべてのHTTPSトラフィックにForwardedヘッダーを挿入することは不可能です。現在のHTTPSの使用傾向を考えると、これは問題になる可能性があります。
The solution, referred to as the Proxy Protocol [Proxy], does not require any application-specific knowledge. The proposed solution (Proxy Protocol Version 1) would insert identification data directly into the application-data stream prior to the actual protocol data being sent, regardless of the protocol. Every application protocol would begin with a textual string of "PROXY", followed by some textual identification data, and with a CRLF; only then would the application data be inserted. Figure 2 shows an example of a line of data used for this purpose, in this case, for a TCP-over-IPv4 connection received from 192.0.2.1:56324 and destined to 192.0.2.15:443.
プロキシプロトコル[プロキシ]と呼ばれるこのソリューションは、アプリケーション固有の知識を必要としません。提案されたソリューション（プロキシプロトコルバージョン1）は、プロトコルに関係なく、実際のプロトコルデータが送信される前に、アプリケーションデータストリームに識別データを直接挿入します。すべてのアプリケーションプロトコルは、「PROXY」のテキスト文字列で始まり、その後にいくつかのテキスト識別データが続き、CRLFで始まります。その後、アプリケーションデータが挿入されます。図2は、この目的で使用されるデータ行の例を示しています。この場合、192.0.2.1：56324から受信され、192.0.2.15：443宛てのTCP-over-IPv4接続に使用されます。
PROXY TCP4 192.0.2.1 192.0.2.15 56324 443\r\n
プロキシTCP4 192.0.2.1 192.0.2.15 56324 443 \ r \ n
Figure 2: Example of PROXY Connection Report
図2：PROXY接続レポートの例
Upon receipt of a message conveying this line, the server removes the line from the incoming stream. The line is parsed to retrieve the transported protocol. The content of this line is recorded in logs and used to enforce policies.
このラインを伝えるメッセージを受信すると、サーバーは着信ストリームからラインを削除します。回線は解析され、転送されたプロトコルが取得されます。この行の内容はログに記録され、ポリシーを適用するために使用されます。
Proxy Protocol Version 2 is designed to accommodate IPv4/IPv6 and also non-TCP protocols (see [Proxy] for more details).
プロキシプロトコルバージョン2は、IPv4 / IPv6および非TCPプロトコルに対応するように設計されています（詳細については、[プロキシ]を参照してください）。
This solution can be deployed in a controlled environment, but it cannot be deployed to all access services available in the Internet. If the remote server does not support the Proxy Protocol, the session will fail. Other complications will arise due to the presence of firewalls, for instance.
このソリューションは制御された環境に展開できますが、インターネットで利用可能なすべてのアクセスサービスに展開することはできません。リモートサーバーがプロキシプロトコルをサポートしていない場合、セッションは失敗します。たとえば、ファイアウォールの存在により、他の複雑な問題が発生します。
As a consequence, this solution is infeasible and cannot be recommended.
結果として、このソリューションは実行不可能であり、推奨できません。
This solution does not require any action from the address-sharing function to disclose a host identifier. Instead of assuming that all transport ports are associated with one single host, each host under the same external IP address is assigned a restricted port set. These port sets are then advertised to remote servers using offline means. This announcement is not required for the delivery of internal services (i.e., offered by the service provider deploying the address-sharing function) relying on implicit identification.
このソリューションでは、ホスト識別子を開示するためのアドレス共有機能からのアクションは必要ありません。すべてのトランスポートポートが単一のホストに関連付けられていると想定する代わりに、同じ外部IPアドレスの下の各ホストには、制限されたポートセットが割り当てられます。これらのポートセットは、オフライン手段を使用してリモートサーバーにアドバタイズされます。このアナウンスは、暗黙の識別に依存する内部サービス（つまり、アドレス共有機能を展開するサービスプロバイダーによって提供される）の配信には必要ありません。
Port sets assigned to hosts may be static or dynamic.
ホストに割り当てられたポートセットは、静的または動的です。
Port set announcements to remote servers are not required to reveal the identity of individual hosts; they are used to advertise the enforced policy to generate non-overlapping port sets (e.g., the transport space associated with an IP address is fragmented to contiguous blocks of 2048 port numbers).
個々のホストのIDを明らかにするために、リモートサーバーへのポートセットアナウンスは必要ありません。それらは、強制されたポリシーをアドバタイズして、重複しないポートセットを生成するために使用されます（たとえば、IPアドレスに関連付けられたトランスポートスペースは、2048個のポート番号の連続したブロックにフラグメント化されます）。
Examples of such an approach are documented in [RFC6346] and [DETERMCGN].
そのようなアプローチの例は、[RFC6346]と[DETERMCGN]に文書化されています。
The solution does not require defining new fields or options; it is policy based.
このソリューションでは、新しいフィールドやオプションを定義する必要はありません。それはポリシーベースです。
The solution may contradict the port randomization [RFC6056] as identified in [RFC6269]. A mitigation would be to avoid assigning static port sets to individual hosts.
[RFC6269]で特定されているように、このソリューションはポートのランダム化[RFC6056]と矛盾する場合があります。緩和策は、静的ポートセットを個々のホストに割り当てないようにすることです。
The method is convenient for the delivery of services offered by the service provider that is also offering the Internet access service.
この方法は、インターネットアクセスサービスも提供しているサービスプロバイダーが提供するサービスの配信に便利です。
[RFC5201] specifies an architecture that introduces a new namespace to convey identity information.
[RFC5201]は、アイデンティティ情報を伝達するために新しい名前空間を導入するアーキテクチャを指定しています。
This solution requires both the client and the server to support HIP [RFC5201]. Additional architectural considerations are to be taken into account, such as the key exchanges.
このソリューションでは、クライアントとサーバーの両方がHIP [RFC5201]をサポートする必要があります。鍵の交換など、追加のアーキテクチャ上の考慮事項を考慮に入れる必要があります。
An alternative deployment model that does not require the client to be HIP-enabled is having the address-sharing function behave as a UDP/TCP-HIP relay. This model is also not viable as it assumes all servers are HIP-enabled.
クライアントがHIP対応であることを必要としない代替の配備モデルは、アドレス共有機能をUDP / TCP-HIPリレーとして動作させることです。このモデルは、すべてのサーバーがHIP対応であることを前提としているため、現実的ではありません。
This solution is a theoretical construct (i.e., the proposal is not documented).
このソリューションは理論的な構成です（つまり、提案は文書化されていません）。
Another alternative is to convey the HOST_ID using a separate notification channel than the one the packets issued to invoke the service.
別の代替方法は、サービスを呼び出すためにパケットが発行されたものとは別の通知チャネルを使用してHOST_IDを伝達することです。
This solution relies on a mechanism where the address-sharing function encapsulates the necessary host-identifying information into an ICMP Echo Request packet that it sends in parallel with the initial session creation (e.g., SYN). The information included in the ICMP Request Data portion describes the five-tuples as seen on both sides of the address-sharing function. An implementation example is defined in [REVEAL-ICMP].
このソリューションは、アドレス共有機能が必要なホスト識別情報を、初期セッションの作成（SYNなど）と並行して送信するICMPエコー要求パケットにカプセル化するメカニズムに依存しています。 ICMP要求データ部分に含まれる情報は、アドレス共有機能の両側で見られる5つのタプルを説明しています。実装例は[REVEAL-ICMP]で定義されています。
o This ICMP proposal is valid for any transport protocol that uses a port number. The address-sharing function may be configured with the transport protocols that will trigger issuing those ICMP messages.
o このICMPプロポーザルは、ポート番号を使用するすべてのトランスポートプロトコルに有効です。アドレス共有機能は、これらのICMPメッセージの発行をトリガーするトランスポートプロトコルで構成できます。
o A hint should be provided to the ultimate server (or intermediate nodes) that the ICMP Echo Request conveys a HOST_ID. This may be implemented using magic numbers (a magic number is a self-selected codepoint whose primary value is its unlikely collision with values selected by others).
o ICMPエコー要求がHOST_IDを伝達する最終的なサーバー（または中間ノード）にヒントを提供する必要があります。これは、マジックナンバーを使用して実装できます（マジックナンバーは、他のユーザーが選択した値との衝突の可能性が低いことが主な値である自己選択コードポイントです）。
o Even if ICMP packets are blocked in the communication path, the user connection does not have to be impacted.
o 通信パスでICMPパケットがブロックされている場合でも、ユーザー接続に影響を与える必要はありません。
o Implementations requiring a session establishment to be delayed until receipt of the companion ICMP Echo Request may lead to some user-experience degradation.
o コンパニオンICMPエコー要求を受信するまでセッションの確立を遅らせる必要がある実装では、ユーザーエクスペリエンスが低下する可能性があります。
o Because of the presence of load balancers in the path, the ultimate server receiving the SYN packet may not be the one that receives the ICMP message conveying the HOST_ID.
o パスにロードバランサーが存在するため、SYNパケットを受信する最終的なサーバーは、HOST_IDを伝達するICMPメッセージを受信するサーバーではない可能性があります。
o Because of the presence of load balancers in the path, the port number assigned by address sharing may be lost. Therefore, the mapping information conveyed in the ICMP may not be sufficient to associate a SYN packet with a received ICMP.
o パスにロードバランサーが存在するため、アドレス共有によって割り当てられたポート番号が失われる可能性があります。したがって、ICMPで伝達されるマッピング情報は、SYNパケットを受信したICMPに関連付けるのに十分でない場合があります。
o The proposal is not compatible with the presence of cascaded NAT. The main reason is that each NAT in the path will generate an ICMP message to reveal the internal host identifier. Because these messages will be translated by the downstream address-sharing devices, the remote server will receive multiple ICMP messages and will need to decide which host identifier to use.
o この提案は、カスケードされたNATの存在と互換性がありません。主な理由は、パス内の各NATがICMPメッセージを生成して内部ホスト識別子を明らかにするためです。これらのメッセージはダウンストリームアドレス共有デバイスによって変換されるため、リモートサーバーは複数のICMPメッセージを受信し、使用するホスト識別子を決定する必要があります。
o The ICMP proposal will add traffic overhead for both the server and the address-sharing device.
o ICMPプロポーザルは、サーバーとアドレス共有デバイスの両方にトラフィックのオーバーヘッドを追加します。
o The ICMP proposal is similar to other mechanisms (e.g., IPFIX [IPFIX-NAT] and Syslog [SYSLOG-NAT]) for reporting dynamic mappings to a mediation platform (mainly for legal traceability purposes). Performance degradation is likely to be experienced by address-sharing functions because ICMP messages are sent for each new instantiated mapping (even if the mapping exists).
o ICMPの提案は、動的マッピングをメディエーションプラットフォームに報告するための（主に法的な追跡可能性の目的で）他のメカニズム（IPFIX [IPFIX-NAT]やSyslog [SYSLOG-NAT]など）に似ています。 ICMPメッセージはインスタンス化された新しいマッピングごとに送信されるため（マッピングが存在する場合でも）、アドレス共有機能によってパフォーマンスが低下する可能性があります。
o In some scenarios (e.g., Section 3 of [REVEAL-PCP]), the HOST_ID should be interpreted by intermediate devices that embed Policy Enforcement Points (PEP) [RFC2753] responsible for granting access to some services. These PEPs need to inspect all received packets in order to find the companion (traffic) messages to be correlated with ICMP messages conveying HOST_IDs. This induces more complexity to these intermediate devices.
o 一部のシナリオ（[REVEAL-PCP]のセクション3など）では、HOST_IDは、一部のサービスへのアクセスの許可を担当するポリシー実施ポイント（PEP）[RFC2753]を組み込んだ中間デバイスによって解釈される必要があります。これらのPEPは、HOST_IDを伝達するICMPメッセージと関連付けられるコンパニオン（トラフィック）メッセージを見つけるために、すべての受信パケットを検査する必要があります。これにより、これらの中間デバイスの複雑さが増します。
Another alternative is to retrieve the HOST_ID using a dedicated query channel.
別の方法は、専用のクエリチャネルを使用してHOST_IDを取得することです。
An implementation example may rely on the Identification Protocol (Ident) [RFC1413]. This solution assumes that the address-sharing function implements the server part of IDENT, while remote servers implement the client part of the protocol. IDENT needs to be updated to be able to return a host identifier instead of the user-id as defined in [RFC1413]. The IDENT response syntax uses the same USERID field described in [RFC1413], but rather than returning a username, a host identifier (e.g., a 16-bit value) is returned. For any new incoming connection, the server contacts the IDENT server to retrieve the associated identifier. During that phase, the connection may be delayed.
実装例は、Identification Protocol（Ident）[RFC1413]に依存する場合があります。このソリューションでは、アドレス共有機能がIDENTのサーバー部分を実装し、リモートサーバーがプロトコルのクライアント部分を実装していることを前提としています。 IDENTは、[RFC1413]で定義されているユーザーIDではなく、ホストIDを返すことができるように更新する必要があります。 IDENT応答構文は、[RFC1413]で説明されているのと同じUSERIDフィールドを使用しますが、ユーザー名を返すのではなく、ホスト識別子（16ビット値など）が返されます。新しい着信接続の場合、サーバーはIDENTサーバーに接続して、関連する識別子を取得します。そのフェーズの間、接続が遅れる可能性があります。
o IDENT is specific to TCP. Alternative out-of-band mechanisms may be designed to cover other transport protocols such as UDP.
o IDENTはTCPに固有です。代替の帯域外メカニズムは、UDPなどの他のトランスポートプロトコルをカバーするように設計できます。
o This solution requires the address-sharing function to embed an IDENT server.
o このソリューションでは、IDENTサーバーを組み込むためにアドレス共有機能が必要です。
o A hint should be provided to the ultimate server (or intermediate nodes) that the address-sharing function implements the IDENT protocol, for example, publishing this capability using DNS (other solutions can be envisaged).
o ヒントは、アドレス共有機能がIDENTプロトコルを実装する最終的なサーバー（または中間ノード）に提供する必要があります。たとえば、DNSを使用してこの機能を公開します（他のソリューションを想定できます）。
o An out-of-band mechanism may require some administrative setup (e.g., contract agreement) between the entity managing the address-sharing function and the entity managing the remote server. Such a deployment is not feasible in the Internet at large because establishing and maintaining agreements between ISPs and all service actors is burdensome and not scalable.
o アウトオブバンドメカニズムでは、アドレス共有機能を管理するエンティティとリモートサーバーを管理するエンティティとの間に、いくつかの管理設定（契約契約など）が必要になる場合があります。 ISPとすべてのサービスアクターとの間で合意を確立および維持することは負担が大きく、スケーラブルではないため、このような展開はインターネット全体では実現可能ではありません。
o Implementations requiring delay of the establishment of a session until receipt of the companion IDENT response may lead to some user-experience degradation.
o コンパニオンIDENT応答を受信するまでセッションの確立を遅らせる必要がある実装では、ユーザーエクスペリエンスが低下する可能性があります。
o The IDENT proposal will add traffic overhead for both the server and the address-sharing device.
o IDENTプロポーザルは、サーバーとアドレス共有デバイスの両方にトラフィックのオーバーヘッドを追加します。
o Performance degradation is likely to be experienced by address-sharing functions embedding the IDENT server. This is further exacerbated if the address-sharing function has to handle an IDENT query for each new instantiated mapping (even if the mapping exists).
o パフォーマンスの低下は、IDENTサーバーを組み込んだアドレス共有機能によって発生する可能性があります。これは、アドレス共有機能が新しいインスタンス化されたマッピングごとにIDENTクエリを処理する必要がある場合（マッピングが存在する場合でも）、さらに悪化します。
o In some scenarios (e.g., Section 3 of [REVEAL-PCP]), the HOST_ID should be interpreted by intermediate devices that embed Policy Enforcement Points (PEP) [RFC2753] responsible for granting access to some services. These PEPs need to inspect all received packets in order to generate the companion IDENT queries. This may induce more complexity to these intermediate devices.
o 一部のシナリオ（[REVEAL-PCP]のセクション3など）では、HOST_IDは、一部のサービスへのアクセスの許可を担当するポリシー実施ポイント（PEP）[RFC2753]を組み込んだ中間デバイスによって解釈される必要があります。これらのPEPは、コンパニオンIDENTクエリを生成するために、すべての受信パケットを検査する必要があります。これにより、これらの中間デバイスがさらに複雑になる可能性があります。
o IDENT queries may be generated by illegitimate TCP servers. This would require the address-sharing function to enforce some policies (e.g., rate-limit queries, filter based on the source IP address, etc.).
o IDENTクエリは、不正なTCPサーバーによって生成される可能性があります。これには、一部のポリシー（レート制限クエリ、送信元IPアドレスに基づくフィルターなど）を実施するためにアドレス共有機能が必要になります。
Table 1 summarizes the approaches analyzed in this document.
表1は、このドキュメントで分析したアプローチをまとめたものです。
+-----+------+------+------+-----+-----+-----+-----+-----+
|IP-ID| IP | TCP |HTTP |PROXY|Port | HIP |ICMP |IDENT|
| |Option|Option|Header| | Set | | | |
----------+-----+------+------+------+-----+-----+-----+-----+-----+
UDP | Yes | Yes | No | No | No | Yes | | Yes | No |
----------+-----+------+------+------+-----+-----+-----+-----+-----+
TCP | Yes | Yes | Yes | No | Yes | Yes | | Yes | Yes |
----------+-----+------+------+------+-----+-----+-----+-----+-----+
HTTP | Yes | Yes | Yes | Yes | Yes | Yes | | Yes | Yes |
----------+-----+------+------+------+-----+-----+-----+-----+-----+
Encrypted | Yes | Yes | Yes | No | Yes | Yes | | Yes | Yes |
Traffic | | | | | | | | | |
----------+-----+------+------+------+-----+-----+-----+-----+-----+
Success | High| Low | High | High | Low | 100%|Low |High |High |
Ratio | | | | | | | | | |
----------+-----+------+------+------+-----+-----+-----+-----+-----+
Possible | Low | High | Low | Med | High| No | N/A | High|High |
Perf | to | | to | to | | | | | |
Impact | Med | | Med | High | | | | | |
----------+-----+------+------+------+-----+-----+-----+-----+-----+
OS TCP/IP | Yes | Yes | Yes | No | No | No | | Yes | Yes |
Modif | | | | | | | | | |
----------+-----+------+------+------+-----+-----+-----+-----+-----+
Deployable| Yes | Yes | Yes | Yes | No | Yes | No | Yes | Yes |
Today | | | | | | | | | |
----------+-----+------+------+------+-----+-----+-----+-----+-----+
Notes | (1) | (8) | (8) | (2) | (8) | (1) | (4) | (6) | (1) |
| (7) | | | | | (3) | (7) | (8) | (6) |
| | | | | | | | | (8) |
----------+-----+------+------+------+-----+-----+-----+-----+-----+
Table 1: Summary of Analyzed Solutions
表1：分析されたソリューションの概要
o "Encrypted Traffic" refers to TLS. The use of IPsec and its complications traversing NATs are discussed in Section 2.2 of [RFC6889]. Similar to what is suggested in Section 13.5 of [RFC6269], HOST_ID specification document(s) should analyze the compatibility of each IPsec mode in detail.
o 「暗号化されたトラフィック」とはTLSを指します。 IPsecの使用とNATを通過する複雑な問題については、[RFC6889]のセクション2.2で説明されています。 [RFC6269]のセクション13.5で提案されているものと同様に、HOST_ID仕様ドキュメントは、各IPsecモードの互換性を詳細に分析する必要があります。
o "Success ratio" indicates the ratio of successful communications with remote servers when the HOST_ID is injected using a proposed solution. More details are provided below to explain how the success ratio is computed for each proposed solution.
o 「成功率」は、提案されたソリューションを使用してHOST_IDが挿入された場合のリモートサーバーとの通信の成功率を示します。以下に、提案されたソリューションごとに成功率がどのように計算されるかを説明するための詳細を示します。
o "Possible Perf Impact" indicates the level of expected performance degradation. The indicated degradation is an estimate based on the need for processing at the IP layer.
o 「パフォーマンスへの影響の可能性」は、予想されるパフォーマンス低下のレベルを示します。示されている低下は、IP層での処理の必要性に基づく推定です。
o "OS TCP/IP Modif" indicates whether a modification of the OS TCP/IP stack is required at the server side.
o 「OS TCP / IP Modif」は、サーバー側でOS TCP / IPスタックの変更が必要かどうかを示します。
o "Deployable today" indicates if the solution can be generalized without any constraint on current architectures and practices.
o 「今すぐ導入可能」は、現在のアーキテクチャやプラクティスに制約を課すことなくソリューションを一般化できるかどうかを示します。
Notes: (1) Requires mechanism to advertise that NAT is participating in this scheme (e.g., DNS PTR record). (2) This solution is widely deployed (e.g., HTTP severs, load balancers, etc.). (3) When the port set is not advertised, the solution is less efficient for third-party services. (4) Requires that the client and the server to be HIP-compliant and that HIP infrastructure be deployed. If the client and the server are HIP-enabled, the address-sharing function does not need to insert an identifier. If the client is not HIP-enabled, designing the device that performs address sharing to act as a UDP/TCP-HIP relay is not viable. (6) The solution is inefficient in some scenarios (see Section 5). (7) The solution is a theoretical construct (i.e., the solution is not documented). (8) The solution is a documented proposal.
注：（1）NATがこのスキームに参加していることを通知するメカニズムが必要です（DNS PTRレコードなど）。 （2）このソリューションは広く展開されています（HTTPサーバー、ロードバランサーなど）。 （3）ポートセットがアドバタイズされていない場合、ソリューションはサードパーティサービスに対して効率が低下します。 （4）クライアントとサーバーがHIP準拠であり、HIPインフラストラクチャが展開されている必要があります。クライアントとサーバーがHIP対応である場合、アドレス共有機能は識別子を挿入する必要がありません。クライアントがHIP対応でない場合、アドレス共有を実行してUDP / TCP-HIPリレーとして機能するデバイスを設計することはできません。 （6）このソリューションは、一部のシナリオでは非効率的です（セクション5を参照）。 （7）解は理論的な構成です（つまり、解は文書化されていません）。 （8）解決策は文書化された提案です。
Provided success ratio figures for TCP and IP options are based on the results documented in [Options] and [REVEAL-TCP-EXP].
TCPおよびIPオプションの成功率の数値は、[オプション]および[REVEAL-TCP-EXP]に記載されている結果に基づいています。
The provided success ratio for the IP-ID is theoretical; it assumes the address-sharing function follows the rules (see [RFC6864])to rewrite the IP Identification field.
IP-IDに提供される成功率は理論的なものです。これは、アドレス共有機能が規則（[RFC6864]を参照）に従ってIP識別フィールドを書き換えることを前提としています。
Since PROXY and HIP are not widely deployed, the success ratio for establishing communication with remote servers using these protocols is low.
PROXYとHIPは広く展開されていないため、これらのプロトコルを使用してリモートサーバーとの通信を確立する成功率は低いです。
The success ratio for the ICMP-based solution is implementation specific, but it is likely to be close to 100%. The success ratio depends on how efficiently the solution is implemented on the server side. A remote server that does not support the ICMP-based solution will ignore received companion ICMP messages. An upgraded server will need to delay the acceptance of a session until it receives the companion ICMP message.
ICMPベースのソリューションの成功率は実装固有ですが、100％に近い可能性があります。成功率は、ソリューションがサーバー側にどの程度効率的に実装されているかに依存します。 ICMPベースのソリューションをサポートしないリモートサーバーは、受信したコンパニオンICMPメッセージを無視します。アップグレードされたサーバーは、対応するICMPメッセージを受信するまで、セッションの受け入れを遅らせる必要があります。
The success ratio for the IDENT solution is implementation specific but it is likely to be close to 100%. The success ratio depends on how efficient the solution is implemented on the server side. A remote server that does not support IDENT will accept a session establishment request following its normal operation. An upgraded server will need to delay the acceptance of a session until it receives a response to the IDENT request it will send to the host.
IDENTソリューションの成功率は実装固有ですが、100％に近い可能性があります。成功率は、ソリューションがサーバー側でどの程度効率的に実装されているかに依存します。 IDENTをサポートしないリモートサーバーは、通常の操作の後にセッション確立要求を受け入れます。アップグレードされたサーバーは、ホストに送信するIDENT要求に対する応答を受信するまで、セッションの受け入れを遅らせる必要があります。
The provided success ratio for the Port Set and HTTP header solutions is 100% because no additional Layer 3 or Layer 4 field is needed to convey HOST_ID for these solutions.
ポートセットおよびHTTPヘッダーソリューションに提供される成功率は100％です。これは、これらのソリューションのHOST_IDを伝達するために追加のレイヤー3またはレイヤー4フィールドが必要ないためです。
If the server trusts the content of the HOST_ID field, a third-party user can be impacted by a misbehaving user revealing a "faked" HOST_ID (e.g., original IP address). This same security concern applies for the injection of an IP option, TCP option, and application-related content (e.g., the Forwarded HTTP header) by the address-sharing device.
サーバーがHOST_IDフィールドのコンテンツを信頼している場合、動作が不正なユーザーが「偽の」HOST_ID（例：元のIPアドレス）を公開することにより、サードパーティのユーザーが影響を受ける可能性があります。これと同じセキュリティ上の問題が、アドレス共有デバイスによるIPオプション、TCPオプション、およびアプリケーション関連のコンテンツ（転送されたHTTPヘッダーなど）の挿入に適用されます。
The HOST_ID may be used to leak information about the internal structure of a network behind an address-sharing function. If this behavior is undesired for the network administrator, the address-sharing function can be configured to strip any existing HOST_ID in received packets from internal hosts.
HOST_IDは、アドレス共有機能の背後にあるネットワークの内部構造に関する情報をリークするために使用される可能性があります。この動作がネットワーク管理者にとって望ましくない場合は、アドレス共有機能を構成して、内部ホストから受信したパケット内の既存のHOST_IDを取り除くことができます。
HOST_ID specification documents should elaborate further on threats inherent to each individual solution used to convey the HOST_ID (e.g., use of the IP-ID field to count hosts behind a NAT [Count]).
HOST_ID仕様ドキュメントでは、HOST_IDの伝達に使用される個々のソリューションに固有の脅威についてさらに詳しく説明する必要があります（たとえば、NAT [カウント]の背後にあるホストをカウントするためのIP-IDフィールドの使用）。
For more discussion of privacy issues related to the HOST_ID, see Section 3.
HOST_IDに関連するプライバシー問題の詳細については、セクション3を参照してください。
Many thanks to D. Wing, C. Jacquenet, J. Halpern, B. Haberman, and P. Yee for their review, comments, and inputs.
D. Wing、C。Jacquenet、J。Halpern、B。Haberman、およびP. Yeeのレビュー、コメント、および入力に感謝します。
Thanks also to P McCann, T. Tsou, Z. Dong, B. Briscoe, T. Taylor, M. Blanchet, D. Wing, and A. Yourtchenko for the discussions in Prague.
プラハでの議論については、Pマッキャン、T。ツォウ、Z。ドン、B。ブリスコー、T。テイラー、M。ブランシェ、D。ウィング、A。ユアチェンコにも感謝します。
Some of the issues related to defining a new TCP option have been raised by L. Eggert.
新しいTCPオプションの定義に関連する問題のいくつかは、L。エガートによって提起されました。
The privacy text was provided by A. Cooper.
プライバシーテキストはA. Cooperによって提供されました。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[RFC3022] Srisuresh、P。およびK. Egevang、「Traditional IP Network Address Translator（Traditional NAT）」、RFC 3022、2001年1月。
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-Protocol Port Randomization", BCP 156, RFC 6056, January 2011.
[RFC6056] Larsen、M。、およびF. Gont、「Recommendations for Transport-Protocol Port Randomization」、BCP 156、RFC 6056、2011年1月。
[Count] Belloven, S., "A Technique for Counting NATted Hosts", <http://www.cs.columbia.edu/~smb/papers/fnat.pdf>.
[カウント] Belloven、S。、「A NATted Hosts Counting for counted Hosts」、<http://www.cs.columbia.edu/~smb/papers/fnat.pdf>。
[DETERMCGN] Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K., and O. Vautrin, "Deterministic Address Mapping to Reduce Logging in Carrier Grade NAT Deployments", Work in Progress, January 2013.
[DETERMCGN] Donley、C.、Grundemann、C.、Sarawat、V.、Sundaresan、K。、およびO. Vautrin、「Deterministic Address Mapping to Reduce Logging in Carrier Grade NAT Deployments」、Work in Progress、2013年1月。
[ExtendTCP] Honda, M., Nishida, Y., Raiciu, C., Greenhalgh, A., Handley, M. and H. Tokuda,, "Is It Still Possible to Extend TCP?", November 2011, <http://nrg.cs.ucl.ac.uk/mjh/tmp/mboxes.pdf>.
[ExtendTCP] Honda、M。、西田、Y.、Raiciu、C.、Greenhalgh、A.、Handley、M。、およびH. Tokuda、「Is It Is Itibleible to TCP TCP ??」、2011年11月、<http： //nrg.cs.ucl.ac.uk/mjh/tmp/mboxes.pdf>。
[FASTOPEN] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", Work in Progress, February 2013.
[FASTOPEN] Cheng、Y.、Chu、J.、Radhakrishnan、S。、およびA. Jain、「TCP Fast Open」、Work in Progress、2013年2月。
[HTTP-FRWD] Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", Work in Progress, October 2012.
[HTTP-FRWD] Petersson、A.およびM. Nilsson、「Forwarded HTTP Extension」、Work in Progress、2012年10月。
[IAB-PRIVACY] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", Work in Progress, July 2012.
[IABプライバシー] Cooper、A.、Tschofenig、H.、Aboba、B.、Peterson、J.、Morris、J.、Hansen、M。、およびR. Smith、「インターネットプロトコルのプライバシーに関する考慮事項」、Work in進捗状況、2012年7月。
[IPFIX-NAT] Sivakumar, S. and R. Penno, "IPFIX Information Elements for Logging NAT Events", Work in Progress, March 2013.
[IPFIX-NAT] Sivakumar、S。、およびR. Penno、「NATイベントをログに記録するためのIPFIX情報要素」、作業中、2013年3月。
[Not_An_Option] R. Fonseca, G. Porter, R. Katz, S. Shenker, and I. Stoica,, "IP Options Are Not An Option", 2005, <http://www.eecs.berkeley.edu/Pubs/TechRpts/2005/ EECS-2005-24.html>.
[Not_An_Option] R.フォンセカ、G。ポーター、R。カッツ、S。シェンカー、およびI.ストイカ、「IPオプションはオプションではない」、2005年、<http://www.eecs.berkeley.edu/Pubs / TechRpts / 2005 / EECS-2005-24.html>。
[Options] Medina, A, Allman, M. and S. Floyd, "Measuring Interactions Between Transport Protocols and Middleboxes", 2005, <http://conferences.sigcomm.org/imc/2004/papers/ p336-medina.pdf>.
[オプション] Medina、A、Allman、M.、S。Floyd、「Measuring Interactions between Transport Protocols and Middleboxes」、2005年、<http://conferences.sigcomm.org/imc/2004/papers/ p336-medina.pdf >。
[Proxy] Tarreau, W., "The PROXY protocol", November 2010, <http://haproxy.1wt.eu/download/1.5/doc/ proxy-protocol.txt>.
[プロキシ]タロー、W、「PROXYプロトコル」、2010年11月、<http://haproxy.1wt.eu/download/1.5/doc/proxy-protocol.txt>。
[REVEAL-ICMP] Yourtchenko, A., "Revealing Hosts Sharing An IP Address Using ICMP Echo Request", Work in Progress, March 2012.
[REVEAL-ICMP] Yourtchenko、A。、「ICMPエコー要求を使用してIPアドレスを共有するホストを明らかにする」、2012年3月、作業中。
[REVEAL-IP] Wu, Y., Ji, H., Chen, Q., and T. ZOU), "IPv4 Header Option For User Identification In CGN Scenario", Work in Progress, March 2011.
[REVEAL-IP] Wu、Y.、Ji、H.、Chen、Q。、およびT. ZOU）、「CGNシナリオでのユーザー識別のためのIPv4ヘッダーオプション」、進行中の作業、2011年3月。
[REVEAL-PCP] Boucadair, M., Reddy, T., Patil, P., and D. Wing, "Using PCP to Reveal a Host behind NAT", Work in Progress, November 2012.
[REVEAL-PCP] Boucadair、M.、Reddy、T.、Patil、P。、およびD. Wing、「PCPを使用してNATの背後にあるホストを明らかにする」、Work in Progress、2012年11月。
[REVEAL-TCP-EXP] Abdo, E., Boucadair, M., and J. Queiroz, "HOST_ID TCP Options: Implementation & Preliminary Test Results", Work in Progress, July 2012.
[REVEAL-TCP-EXP] Abdo、E.、Boucadair、M.、J。Queiroz、「HOST_ID TCP Options：Implementation＆Preliminary Test Results」、Work in Progress、2012年7月。
[REVEAL-TCP] Yourtchenko, A. and D. Wing, "Revealing Hosts Sharing An IP Address Using TCP Option", Work in Progress, December 2011.
[REVEAL-TCP] Yourtchenko、A。およびD. Wing、「TCPオプションを使用してIPアドレスを共有するホストを明らかにする」、進行中の作業、2011年12月。
[RFC1413] St. Johns, M., "Identification Protocol", RFC 1413, February 1993.
[RFC1413]セントジョンズ、M。、「識別プロトコル」、RFC 1413、1993年2月。
[RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 2000.
[RFC2753] Yavatkar、R.、Pendarakis、D。、およびR. Guerin、「A Framework for Policy-based Admission Control」、RFC 2753、2000年1月。
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[RFC5201] Moskowitz、R.、Nikander、P.、Jokela、P。、およびT. Henderson、「Host Identity Protocol」、RFC 5201、2008年4月。
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6146] Bagnulo、M.、Matthews、P。、およびI. van Beijnum、「Stateful NAT64：Network Address and Protocol Translation to IPv6 Clients to IPv4 Servers」、RFC 6146、2011年4月。
[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月。
[RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, "Logging Recommendations for Internet-Facing Servers", BCP 162, RFC 6302, June 2011.
[RFC6302] Durand、A.、Gashinsky、I.、Lee、D。、およびS. Sheppard、「インターネットに面したサーバーのロギングに関する推奨事項」、BCP 162、RFC 6302、2011年6月。
[RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the IPv4 Address Shortage", RFC 6346, August 2011.
[RFC6346]ブッシュR。、「IPv4アドレス不足に対するアドレスとポート（A + P）のアプローチ」、RFC 6346、2011年8月。
[RFC6462] Cooper, A., "Report from the Internet Privacy Workshop", RFC 6462, January 2012.
[RFC6462]クーパー、A。、「インターネットプライバシーワークショップからの報告」、RFC 6462、2012年1月。
[RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", RFC 6864, February 2013.
[RFC6864] Touch、J。、「IPv4 IDフィールドの更新された仕様」、RFC 6864、2013年2月。
[RFC6889] Penno, R., Saxena, T., Boucadair, M., and S. Sivakumar, "Analysis of Stateful 64 Translation", RFC 6889, April 2013.
[RFC6889] Penno、R.、Saxena、T.、Boucadair、M.、and S. Sivakumar、 "Analysis of Stateful 64 Translation"、RFC 6889、April 2013。
[SYSLOG-NAT] Chen, Z., Zhou, C., Tsou, T., and T. Taylor, "Syslog Format for NAT Logging", Work in Progress, May 2013.
[SYSLOG-NAT] Chen、Z.、Zhou、C.、Tsou、T。、およびT. Taylor、「NATログのSyslog形式」、作業中、2013年5月。
[TOR] Dingledine, R., Mathewson, N., and P. Syverson, "Tor: The secondgeneration onion router", In Proceedings of the 13th USENIX Security Symposium, August 2004.
[TOR] Dingledine、R.、Mathewson、N。、およびP. Syverson、「Tor：第2世代オニオンルーター」、第13回USENIXセキュリティシンポジウムの議事録、2004年8月。
[Trusted_ISPs] Wikimedia, "Trusted XFF List", May 2013, <http://meta.wikimedia.org/w/ index.php?title=XFF_project&oldid=5507690>.
[Trusted_ISPs] Wikimedia、「Trusted XFF List」、2013年5月、<http://meta.wikimedia.org/w/ index.php？title = XFF_project＆oldid = 5507690>。
Authors' Addresses
著者のアドレス
Mohamed Boucadair France Telecom Rennes 35000 France
Mohamed Boucadair France Telecom Rennes 35000 France
EMail: mohamed.boucadair@orange.com
Joe Touch USC/ISI 4676 Admiralty Way Marina del Rey, CA 90292-6695 United States
Joe Touch USC / ISI 4676 Admiralty Wayマリナデルレイ、CA 90292-6695アメリカ合衆国
Phone: +1 (310) 448-9151
EMail: touch@isi.edu
Pierre Levis France Telecom Caen 14000 France
Pierre Levis France Telecom Caen 14000フランス
EMail: pierre.levis@orange.com
Reinaldo Penno Cisco United States
Reinaldo Pennoシスコアメリカ合衆国
EMail: repenno@cisco.com