[要約] RFC 7620は、ホスト識別の複雑さに関連するシナリオを説明しています。このRFCの目的は、ネットワーク環境でのホスト識別に関連する問題を理解し、解決策を提供することです。
Independent Submission M. Boucadair, Ed.
Request for Comments: 7620 B. Chatras
Category: Informational Orange
ISSN: 2070-1721 T. Reddy
Cisco Systems
B. Williams
Akamai, Inc.
B. Sarikaya
Huawei
August 2015
Scenarios with Host Identification Complications
ホスト識別の複雑化を伴うシナリオ
Abstract
概要
This document describes a set of scenarios in which complications when identifying which policy to apply for a host are encountered. This problem is abstracted as "host identification". Describing these scenarios allows commonalities between scenarios to be identified, which is helpful during the solution design phase.
このドキュメントでは、ホストに適用するポリシーを特定する際に問題が発生する一連のシナリオについて説明します。この問題は「ホストの識別」として抽象化されています。これらのシナリオを記述することで、シナリオ間の共通点を識別できるようになり、ソリューションの設計フェーズで役立ちます。
This document does not include any solution-specific discussions.
このドキュメントには、ソリューション固有の説明は含まれていません。
IESG Note
IESG Note
This document describes use cases where IP addresses are overloaded with both location and identity properties. Such semantic overloading is seen as a contributor to a variety of issues within the routing system [RFC4984]. Additionally, these use cases may be seen as a way to justify solutions that are not consistent with IETF Best Current Practices on protecting privacy [BCP160] [BCP188].
このドキュメントでは、IPアドレスが場所とIDプロパティの両方で過負荷になるユースケースについて説明します。このようなセマンティックオーバーロードは、ルーティングシステム内のさまざまな問題の原因と見なされています[RFC4984]。さらに、これらの使用例は、プライバシー保護に関するIETFのベストカレントプラクティス[BCP160] [BCP188]と一致しないソリューションを正当化する方法と見なされる場合があります。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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/rfc7620.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7620で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 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.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Scenario 1: Carrier-Grade NAT (CGN) . . . . . . . . . . . . . 4
4. Scenario 2: Address plus Port (A+P) . . . . . . . . . . . . . 5
5. Scenario 3: On-Premise Application Proxy Deployment . . . . . 6
6. Scenario 4: Distributed Proxy Deployment . . . . . . . . . . 7
7. Scenario 5: Overlay Network . . . . . . . . . . . . . . . . . 8
8. Scenario 6: Policy and Charging Control Architecture (PCC) . 10
9. Scenario 7: Emergency Calls . . . . . . . . . . . . . . . . . 12
10. Other Deployment Scenarios . . . . . . . . . . . . . . . . . 13
10.1. Open WLAN or Provider WLAN . . . . . . . . . . . . . . . 13
10.2. Cellular Networks . . . . . . . . . . . . . . . . . . . 14
10.3. Femtocells . . . . . . . . . . . . . . . . . . . . . . . 14
10.4. Traffic Detection Function (TDF) . . . . . . . . . . . . 17
10.5. Fixed and Mobile Network Convergence . . . . . . . . . . 18
11. Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . 21
12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21
13. Security Considerations . . . . . . . . . . . . . . . . . . . 22
14. Informative References . . . . . . . . . . . . . . . . . . . 22
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 25
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
The goal of this document is to enumerate scenarios that encounter the issue of uniquely identifying a host among those sharing the same IP address. Within this document, a host can be any device directly connected to a network operated by a network provider, a Home Gateway, or a roaming device located behind a Home Gateway.
このドキュメントの目的は、同じIPアドレスを共有するホスト間でホストを一意に識別する問題に遭遇するシナリオを列挙することです。このドキュメントでは、ホストは、ネットワークプロバイダーが運営するネットワークに直接接続されている任意のデバイス、ホームゲートウェイ、またはホームゲートウェイの背後にあるローミングデバイスです。
An exhaustive list of encountered issues for the Carrier-Grade NAT (CGN), Address plus Port (A+P), and application proxies scenarios are documented in [RFC6269]. In addition to those issues, some of the scenarios described in this document suffer from additional issues such as:
キャリアグレードのNAT（CGN）、アドレスとポート（A + P）、およびアプリケーションプロキシのシナリオで発生した問題の完全なリストは、[RFC6269]に文書化されています。これらの問題に加えて、このドキュメントで説明されているシナリオのいくつかは、次のような追加の問題に悩まされています。
o Identifying which policy to enforce for a host (e.g., limit access to the service based on some counters such as volume-based service offerings); enforcing the policy will have an impact on all hosts sharing the same IP address. o Needing to correlate between the internal address:port and external address:port to generate and therefore enforce policies. o Querying a location server for the location of an emergency caller based on the source IP address.
o ホストに適用するポリシーを特定する（例：ボリュームベースのサービスの提供など、いくつかのカウンターに基づいてサービスへのアクセスを制限する）;ポリシーを適用すると、同じIPアドレスを共有するすべてのホストに影響があります。 o内部アドレス：ポートと外部アドレス：ポートを関連付けてポリシーを生成し、強制する必要があります。 o送信元IPアドレスに基づいて、ロケーションサーバーに緊急発信者の場所を問い合わせます。
The goal of this document is to identify scenarios the authors are aware of and that share the same complications in identifying which policy to apply for a host. This problem is abstracted as the host identification problem.
このドキュメントの目的は、作成者が認識しているシナリオを特定し、ホストに適用するポリシーを特定する際に同じ問題を共有することです。この問題は、ホスト識別問題として抽象化されます。
The analysis of the scenarios listed in this document indicates several root causes for the host identification issue:
このドキュメントにリストされているシナリオの分析は、ホスト識別問題のいくつかの根本的な原因を示しています。
1. Presence of address sharing (CGN, A+P, application proxies, etc.). 2. Use of tunnels between two administrative domains. 3. Combination of address sharing and presence of tunnels in the path.
1. アドレス共有の存在（CGN、A + P、アプリケーションプロキシなど）。 2. 2つの管理ドメイン間のトンネルの使用。 3.アドレス共有とパス内のトンネルの存在の組み合わせ。
Even if these scenarios share the same root causes, describing the scenario allows to identify what is common between the scenarios, and then this information would help during the solution design phase.
これらのシナリオが同じ根本原因を共有している場合でも、シナリオを説明することで、シナリオ間の共通点を特定でき、この情報はソリューションの設計段階で役立ちます。
This document can be used as a tool to design a solution(s) that mitigates the encountered issues. Note, [RFC6967] focuses only on the CGN, A+P, and application proxies cases. The analysis in [RFC6967] may not be accurate for some of the scenarios that do not span multiple administrative domains (e.g., Section 10.1).
このドキュメントは、発生した問題を軽減するソリューションを設計するためのツールとして使用できます。 [RFC6967]は、CGN、A + P、およびアプリケーションプロキシのケースのみに焦点を当てていることに注意してください。 [RFC6967]の分析は、複数の管理ドメインにまたがらないシナリオ（たとえば、セクション10.1）では正確でない場合があります。
This document does not target means that would lead to exposing a host beyond what the original packet, issued from that host, would have already exposed. Such means are not desirable nor required to solve the issues encountered in the scenarios discussed in this document. The focus is exclusively on means to restore the information conveyed in the original packet issued by a given host. These means are intended to help in identifying which policy to apply for a given flow. These means may rely on some bits of the source IP address and/or port number(s) used by the host to issue packets.
このドキュメントは、そのホストから発行された元のパケットがすでに公開していたものを超えてホストを公開することにつながることを意味していません。このような手段は、このドキュメントで説明されているシナリオで発生する問題を解決するためには望ましくなく、また必須でもありません。焦点は、特定のホストによって発行された元のパケットで伝達された情報を復元する手段に排他的にあります。これらの手段は、特定のフローに適用するポリシーを識別するのに役立つことを目的としています。これらの手段は、パケットを発行するためにホストが使用する送信元IPアドレスまたはポート番号、あるいはその両方のいくつかのビットに依存する場合があります。
To prevent side effects and misuses of such means on privacy, a solution specification document(s) should explain, in addition to what is already documented in [RFC6967], the following:
プライバシーに対するそのような手段の副作用や誤用を防ぐために、ソリューション仕様書は、[RFC6967]ですでに文書化されているものに加えて、以下について説明する必要があります。
o To what extent the solution can be used to nullify the effect of using address sharing to preserve privacy (see, for example, [EFFOpenWireless]). Note, this concern can be mitigated if the address-sharing platform is under the responsibility of the host's owner and the host does not leak information that would interfere with the host's privacy protection tool.
o アドレス共有を使用してプライバシーを保護する効果を無効にするために、ソリューションをどの程度使用できるか（たとえば、[EFFOpenWireless]を参照）。この問題は、アドレス共有プラットフォームがホストの所有者の責任下にあり、ホストがホストのプライバシー保護ツールに干渉する情報を漏らさない場合に軽減できることに注意してください。
o To what extent the solution can be used to expose privacy information beyond what the original packet would have already exposed. Note, the solutions discussed in [RFC6967] do not allow extra information to be revealed other than what is conveyed in the original packet.
o ソリューションを使用して、元のパケットがすでに公開していたものを超えてプライバシー情報を公開できる範囲。 [RFC6967]で説明されている解決策では、元のパケットで伝えられたもの以外の追加情報を明らかにできないことに注意してください。
This document covers both IPv4 and IPv6.
このドキュメントでは、IPv4とIPv6の両方を扱います。
This document does not include any solution-specific discussions. In particular, the document does not elaborate whether explicit authentication is enabled or not.
このドキュメントには、ソリューション固有の説明は含まれていません。特に、このドキュメントでは、明示的な認証が有効になっているかどうかについて詳しく説明していません。
This document does not discuss whether specific information is needed to be leaked in packets, whether this is achieved out of band, etc. Those considerations are out of scope.
このドキュメントでは、パケットで特定の情報をリークする必要があるかどうか、これが帯域外で行われるかどうかなどについては説明していません。これらの考慮事項は範囲外です。
Several flavors of stateful CGN have been defined. A non-exhaustive list is provided below:
ステートフルCGNのいくつかのフレーバーが定義されています。完全ではないリストを以下に示します。
1. IPv4-to-IPv4 NAT (NAT44) [RFC6888] [STATELESS-NAT44]
1. IPv4-to-IPv4 NAT（NAT44）[RFC6888] [STATELESS-NAT44]
2. DS-Lite NAT44 [RFC6333]
2. DS-Lite NAT44 [RFC6333]
3. Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (NAT64) [RFC6146]
3. IPv6クライアントからIPv4サーバー（NAT64）へのネットワークアドレスおよびプロトコル変換[RFC6146]
4. IPv6-to-IPv6 Network Prefix Translation (NPTv6) [RFC6296]
4. IPv6-to-IPv6ネットワークプレフィックス変換（NPTv6）[RFC6296]
As discussed in [RFC6967], remote servers are not able to distinguish between hosts sharing the same IP address (Figure 1). As a reminder, remote servers rely on the source IP address for various purposes such as access control or abuse management. The loss of the host identification will lead to issues discussed in [RFC6269].
[RFC6967]で説明されているように、リモートサーバーは同じIPアドレスを共有するホストを区別できません（図1）。リモートサーバーは、アクセス制御や乱用管理などのさまざまな目的で送信元IPアドレスに依存しています。ホストIDが失われると、[RFC6269]で説明されている問題が発生します。
+-----------+
| HOST_1 |----+
+-----------+ | +--------------------+ +------------+
| | |------| Server 1 |
+-----------+ +-----+ | | +------------+
| HOST_2 |--| CGN |----| INTERNET | ::
+-----------+ +-----+ | | +------------+
| | |------| Server n |
+-----------+ | +--------------------+ +------------+
| HOST_3 |-----+
+-----------+
Figure 1: CGN Reference Architecture
図1：CGNリファレンスアーキテクチャ
Some of the above-referenced CGN scenarios will be satisfied by eventual completion of the transition to IPv6 across the Internet (e.g., NAT64), but this is not true of all CGN scenarios (e.g., NPTv6 [RFC6296]) for which some of the issues discussed in [RFC6269] will be encountered (e.g., impact on geolocation).
上記のCGNシナリオの一部は、インターネットを介したIPv6への移行の最終的な完了（NAT64など）によって満たされますが、これは、CGNシナリオ（NPTv6 [RFC6296]など） [RFC6269]で説明されている問題が発生します（たとえば、ジオロケーションへの影響）。
Privacy-related considerations discussed in [RFC6967] apply for this scenario.
[RFC6967]で説明されているプライバシー関連の考慮事項は、このシナリオに適用されます。
A+P [RFC6346] [RFC7596] [RFC7597] denotes a flavor of address-sharing solutions that does not require any additional NAT function to be enabled in the service provider's network. A+P assumes subscribers are assigned with the same IPv4 address together with a port set. Subscribers assigned with the same IPv4 address should be assigned non-overlapping port sets. Devices connected to an A+P-enabled network should be able to restrict the IPv4 source port to be within a configured range of ports. To forward incoming packets to the appropriate host, a dedicated entity called the Port-Range Router (PRR) [RFC6346] is needed (Figure 2).
A + P [RFC6346] [RFC7596] [RFC7597]は、サービスプロバイダーのネットワークで追加のNAT機能を有効にする必要がないアドレス共有ソリューションの一種です。 A + Pは、加入者がポートセットとともに同じIPv4アドレスを割り当てられていることを前提としています。同じIPv4アドレスが割り当てられたサブスクライバーには、重複しないポートセットを割り当てる必要があります。 A + P対応ネットワークに接続されたデバイスは、IPv4送信元ポートを構成されたポート範囲内に制限できる必要があります。着信パケットを適切なホストに転送するには、Port-Range Router（PRR）[RFC6346]と呼ばれる専用エンティティが必要です（図2）。
Similar to the CGN case, remote servers rely on the source IP address for various purposes such as access control or abuse management. The loss of the host identification will lead to the issues discussed in
CGNの場合と同様に、リモートサーバーは、アクセス制御や乱用管理などのさまざまな目的で送信元IPアドレスに依存しています。ホストIDが失われると、で説明されている問題が発生します。
[RFC6269]. In particular, it will be impossible to identify hosts sharing the same IP address by remote servers.
[RFC6269]。特に、リモートサーバーが同じIPアドレスを共有しているホストを特定することはできません。
+-----------+
| HOST_1 |----+
+-----------+ | +--------------------+ +------------+
| | |------| Server 1 |
+-----------+ +-----+ | | +------------+
| HOST_2 |--| PRR |----| INTERNET | ::
+-----------+ +-----+ | | +------------+
| | |------| Server n |
+-----------+ | +--------------------+ +------------+
| HOST_3 |-----+
+-----------+
Figure 2: A+P Reference Architecture
図2：A + Pリファレンスアーキテクチャ
Privacy-related considerations discussed in [RFC6967] apply for this scenario.
[RFC6967]で説明されているプライバシー関連の考慮事項は、このシナリオに適用されます。
This scenario is similar to the CGN scenario (Section 3).
このシナリオは、CGNシナリオ（セクション3）に似ています。
Remote servers are not able to distinguish hosts located behind the proxy. Applying policies on the perceived external IP address as received from the proxy will impact all hosts connected to that proxy.
リモートサーバーは、プロキシの背後にあるホストを区別できません。プロキシから受信したと認識された外部IPアドレスにポリシーを適用すると、そのプロキシに接続されているすべてのホストに影響します。
Figure 3 illustrates a simple configuration involving a proxy. Note several (per-application) proxies may be deployed. This scenario is a typical deployment approach used within enterprise networks.
図3は、プロキシを含む単純な構成を示しています。複数の（アプリケーションごとの）プロキシがデプロイされる場合があることに注意してください。このシナリオは、企業ネットワーク内で使用される典型的な導入アプローチです。
+-----------+
| HOST_1 |----+
+-----------+ | +--------------------+ +------------+
| | |------| Server 1 |
+-----------+ +-----+ | | +------------+
| HOST_2 |--|Proxy|----| INTERNET | ::
+-----------+ +-----+ | | +------------+
| | |------| Server n |
+-----------+ | +--------------------+ +------------+
| HOST_3 |-----+
+-----------+
Figure 3: Proxy Reference Architecture
図3：プロキシリファレンスアーキテクチャ
The administrator of the proxy may have many reasons for wanting to proxy traffic - including caching, policy enforcement, malware scanning, reporting on network or user behavior for compliance, or security monitoring.
プロキシの管理者は、キャッシュ、ポリシーの適用、マルウェアのスキャン、コンプライアンスのためのネットワークまたはユーザーの動作のレポート、セキュリティの監視など、トラフィックをプロキシしたい理由がたくさんある場合があります。
The same administrator may also wish to selectively hide or expose the internal host identity to servers. He/she may wish to hide the identity to protect end-user privacy or to reduce the ability of a rogue agent to learn the internal structure of the network. He/she may wish to allow upstream servers to identify hosts to enforce access policies (for example, on documents or online databases), to enable account identification (on subscription-based services) or to prevent spurious misidentification of high-traffic patterns as a DoS attack. Application-specific protocols exist for enabling such forwarding on some plaintext protocols (e.g., Forwarded headers on HTTP [RFC7239] or time-stamp-line headers in SMTP [RFC5321]).
同じ管理者は、内部ホストIDをサーバーに対して選択的に非表示または公開することもできます。エンドユーザーのプライバシーを保護するため、またはネットワークの内部構造を学習する悪意のあるエージェントの能力を低下させるために、彼/彼女はアイデンティティを隠したいと思うかもしれません。彼/彼女は、上流のサーバーがホストを識別して、アクセスポリシー（ドキュメントやオンラインデータベースなど）を適用したり、アカウントの識別（サブスクリプションベースのサービス）を有効にしたり、トラフィックの多いパターンをDoS攻撃。一部のプレーンテキストプロトコルでこのような転送を可能にするために、アプリケーション固有のプロトコルが存在します（たとえば、HTTPの転送ヘッダー[RFC7239]またはSMTPのタイムスタンプ行ヘッダー[RFC5321]）。
Servers not receiving such notifications but wishing to perform host or user-specific processing are obliged to use other application-specific means of identification (e.g., cookies [RFC6265]).
そのような通知を受信しないが、ホストまたはユーザー固有の処理を実行したいサーバーは、他のアプリケーション固有の識別手段（たとえば、Cookie [RFC6265]）を使用する義務があります。
Packets/connections must be received by the proxy regardless of the IP address family in use. The requirements of this scenario are not satisfied by eventual completion of the transition to IPv6 across the Internet. Complications will arise for both IPv4 and IPv6.
パケット/接続は、使用中のIPアドレスファミリに関係なく、プロキシによって受信される必要があります。このシナリオの要件は、インターネットを介したIPv6への移行の最終的な完了によって満たされません。 IPv4とIPv6の両方で問題が発生します。
Privacy-related considerations discussed in [RFC6967] apply for this scenario.
[RFC6967]で説明されているプライバシー関連の考慮事項は、このシナリオに適用されます。
This scenario is similar to the proxy deployment scenario (Section 5) with the same use cases. However, in this instance part of the functionality of the application proxy is located in a remote site. This may be desirable to reduce infrastructure and administration costs or because the hosts in question are mobile or roaming hosts tied to a particular administrative zone of control but not to a particular network.
このシナリオは、同じ使用例のプロキシ展開シナリオ（セクション5）に似ています。ただし、この場合、アプリケーションプロキシの機能の一部はリモートサイトにあります。これは、インフラストラクチャと管理のコストを削減するため、または特定のネットワークではなく特定の管理ゾーンに関連付けられたモバイルホストまたはローミングホストであるため、望ましい場合があります。
In some cases, a distributed proxy is required to identify a host on whose behalf it is performing the caching, filtering, or other desired service - for example, to know which policies to enforce. Typically, IP addresses are used as a surrogate. However, in the presence of CGN, this identification becomes difficult. Alternative solutions include the use of cookies, which only work for HTTP traffic, tunnels, or proprietary extensions to existing protocols.
場合によっては、キャッシング、フィルタリング、またはその他の必要なサービスを実行しているホストを識別するために、たとえば、どのポリシーを適用するかを知るために、分散プロキシが必要です。通常、IPアドレスはサロゲートとして使用されます。ただし、CGNが存在する場合、この識別は困難になります。代替ソリューションには、HTTPトラフィック、トンネル、または既存のプロトコルに対する独自の拡張機能に対してのみ機能するCookieの使用が含まれます。
+-----------+ +----------+
| HOST_1 |-------------| |
+-----------+ | | +-------+ +----------+
| | | |----| Server 1 |
+-----------+ | | | | +----------+
| HOST_2 |----+ | INTERNET |---| Proxy | ::
+-----------+ +-----+ | | | | +----------+
|Proxy|----| | | |----| Server n |
+-----------+ +-----+ | | +-------+ +----------+
| HOST_3 |----+ +----------+
+-----------+
Figure 4: Distributed Proxy Reference Architecture (1)
図4：分散プロキシリファレンスアーキテクチャ（1）
+-----------+ +---+ +---+ +----------+
| HOST_1 +---------+ I | | I +--+ Server 1 |
+-----------+ | N | +---+ | N | +----------+
| T | | P | | T |
+-----------+ +---+ | E | | r | | E | +----------+
| HOST_2 +--+ P | | R +--+ o +--+ R +--+ Server 2 |
+-----------+ | r | | N | | x | | N | +----------+
| o |--+ E | | y | | E | ::
+-----------+ | x | | T | +---+ | T | +----------+
| HOST_3 +--+ y | | | | +--+ Server N |
+-----------+ +---+ +---+ +---+ +----------+
Figure 5: Distributed Proxy Reference Architecture (2)
図5：分散プロキシリファレンスアーキテクチャ（2）
Packets/connections must be received by the proxy regardless of the IP address family in use. The requirements of this scenario are not satisfied by eventual completion of the transition to IPv6 across the Internet. Complications will arise for both IPv4 and IPv6.
パケット/接続は、使用中のIPアドレスファミリに関係なく、プロキシによって受信される必要があります。このシナリオの要件は、インターネットを介したIPv6への移行の最終的な完了によって満たされません。 IPv4とIPv6の両方で問題が発生します。
If the proxy and the servers are under the responsibility of the same administrative entity (Figure 4), no privacy concerns are raised. Nevertheless, privacy-related considerations discussed in [RFC6967] apply if the proxy and the servers are not managed by the same administrative entity (Figure 5).
プロキシとサーバーが同じ管理エンティティの責任下にある場合（図4）、プライバシーの問題は発生しません。それにもかかわらず、[RFC6967]で説明されているプライバシー関連の考慮事項は、プロキシとサーバーが同じ管理エンティティによって管理されていない場合に適用されます（図5）。
An overlay network is a network of machines distributed throughout multiple autonomous systems within the public Internet that can be used to improve the performance of data transport (see Figure 6). IP packets from the sender are delivered first to one of the machines that make up the overlay network. That machine then relays the IP packets to the receiver via one or more machines in the overlay network, applying various performance enhancement methods.
オーバーレイネットワークは、パブリックインターネット内の複数の自律システム全体に分散されたマシンのネットワークであり、データ転送のパフォーマンスを向上させるために使用できます（図6を参照）。送信者からのIPパケットは、最初にオーバーレイネットワークを構成するマシンの1つに配信されます。次に、そのマシンは、オーバーレイネットワークの1つ以上のマシンを介してIPパケットをレシーバーにリレーし、さまざまなパフォーマンス強化方法を適用します。
+------------------------------------+
| |
| INTERNET |
| |
+-----------+ | +------------+ |
| HOST_1 |-----| OVRLY_IN_1 |-----------+ |
+-----------+ | +------------+ | |
| | |
+-----------+ | +------------+ +-----------+ | +--------+
| HOST_2 |-----| OVRLY_IN_2 |-----| OVRLY_OUT |-----| Server |
+-----------+ | +------------+ +-----------+ | +--------+
| | |
+-----------+ | +------------+ | |
| HOST_3 |-----| OVRLY_IN_3 |-----------+ |
+-----------+ | +------------+ |
| |
+------------------------------------+
Figure 6: Overlay Network Reference Architecture
図6：オーバーレイネットワークリファレンスアーキテクチャ
Such overlay networks are used to improve the performance of content delivery [IEEE1344002]. Overlay networks are also used for peer-to-peer data transport [RFC5694], and they have been suggested for use in both improved scalability for the Internet routing infrastructure [RFC6179] and provisioning of security services (intrusion detection, anti-virus software, etc.) over the public Internet [IEEE101109].
このようなオーバーレイネットワークは、コンテンツ配信のパフォーマンスを向上させるために使用されます[IEEE1344002]。オーバーレイネットワークは、ピアツーピアのデータ転送[RFC5694]にも使用され、インターネットルーティングインフラストラクチャの拡張性の向上[RFC6179]とセキュリティサービスのプロビジョニング（侵入検知、ウイルス対策ソフトウェア、など）公衆インターネット経由[IEEE101109]。
In order for an overlay network to intercept packets and/or connections transparently via base Internet connectivity infrastructure, the overlay ingress and egress hosts (OVERLAY_IN and OVERLAY_OUT) must be reliably in path in both directions between the connection-initiating HOST and the SERVER. When this is not the case, packets may be routed around the overlay and sent directly to the receiving host, presumably without invoking some of the advanced service functions offered by the overlay.
オーバーレイネットワークがベースインターネット接続インフラストラクチャを介して透過的にパケットや接続をインターセプトするためには、オーバーレイの入出力ホスト（OVERLAY_INおよびOVERLAY_OUT）が、接続を開始するHOSTとサーバーの間の両方向のパスに確実に存在する必要があります。そうでない場合、おそらくオーバーレイによって提供される高度なサービス機能の一部を呼び出すことなく、パケットがオーバーレイの周りにルーティングされ、受信ホストに直接送信される可能性があります。
For public overlay networks, where the ingress and/or egress hosts are on the public Internet, packet interception commonly uses network address translation for the source (SNAT) or destination (DNAT) addresses in such a way that the public IP addresses of the true endpoint hosts involved in the data transport are invisible to each other (see Figure 7). For example, the actual sender and receiver may use two completely different pairs of source and destination addresses to identify the connection on the sending and receiving networks in cases where both the ingress and egress hosts are on the public Internet.
入力ホストまたは出力ホスト、あるいはその両方がパブリックインターネット上にあるパブリックオーバーレイネットワークの場合、パケットインターセプションは通常、送信元（SNAT）または宛先（DNAT）アドレスのネットワークアドレス変換を使用して、真のパブリックIPアドレスがデータトランスポートに関与するエンドポイントホストは互いに見えません（図7を参照）。たとえば、実際の送信者と受信者は、完全に異なる2つの送信元アドレスと宛先アドレスのペアを使用して、入力ホストと出力ホストの両方がパブリックインターネット上にある場合に、送信ネットワークと受信ネットワークの接続を識別します。
IP hdr contains: IP hdr contains:
SENDER -> src = sender --> OVERLAY --> src = overlay2 --> RECEIVER
dst = overlay1 dst = receiver
Figure 7: NAT Operations in an Overlay Network
図7：オーバーレイネットワークでのNAT操作
In this scenario, the remote server is not able to distinguish among hosts using the overlay for transport. In addition, the remote server is not able to determine the overlay ingress point being used by the host, which can be useful for diagnosing host connectivity issues.
このシナリオでは、リモートサーバーは転送にオーバーレイを使用してホストを区別できません。さらに、リモートサーバーは、ホストで使用されているオーバーレイの進入ポイントを判別できません。これは、ホスト接続の問題の診断に役立ちます。
In some of the above-referenced scenarios, IP packets traverse the overlay network fundamentally unchanged, with the overlay network functioning much like a CGN (Section 3). In other cases, connection-oriented data flows (e.g., TCP) are terminated by the overlay in order to perform object caching and other such transport and application-layer optimizations, similar to the proxy scenario (Section 5). In both cases, address sharing is a requirement for packet/connection interception, which means that the requirements for this scenario are not satisfied by the eventual completion of the transition to IPv6 across the Internet.
上記のシナリオの一部では、IPパケットはオーバーレイネットワークを基本的に変更せずに通過し、オーバーレイネットワークはCGNのように機能します（セクション3）。他のケースでは、プロキシシナリオと同様に、オブジェクトキャッシングやその他のトランスポートおよびアプリケーション層の最適化を実行するために、接続指向のデータフロー（TCPなど）がオーバーレイによって終了されます（セクション5）。どちらの場合も、アドレス共有はパケット/接続インターセプトの要件です。つまり、このシナリオの要件は、インターネットを介したIPv6への移行の最終的な完了によっては満たされません。
More details about this scenario are provided in [OVERLAYPATH].
このシナリオの詳細については、[OVERLAYPATH]を参照してください。
This scenario does not introduce privacy concerns since the identification of the host is local to a single administrative domain (i.e., Content Delivery Network (CDN) Overlay Network) or passed to a remote server to help forwarding back the response to the appropriate host. The host identification information is not publicly available nor can be disclosed to other hosts connected to the Internet.
ホストの識別は単一の管理ドメイン（つまり、コンテンツ配信ネットワーク（CDN）オーバーレイネットワーク）に対してローカルであるか、リモートサーバーに渡されて適切なホストへの応答の転送を支援するため、このシナリオではプライバシーの問題は発生しません。ホスト識別情報は公開されておらず、インターネットに接続されている他のホストに開示することもできません。
This issue is related to the PCC framework defined by 3GPP in [TS23.203] when a NAT is located between the Policy and Charging Enforcement Function (PCEF) and the Application Function (AF) as shown in Figure 8.
この問題は、図8に示すように、NATがポリシーおよび課金実施機能（PCEF）とアプリケーション機能（AF）の間にある場合に、[TS23.203]で3GPPによって定義されたPCCフレームワークに関連しています。
The main issue is: PCEF, the Policy and Charging Rule Function (PCRF), and AF all receive information bound to the same User Equipment (UE) but without being able to correlate between the piece of data visible for each entity. Concretely, o PCEF is aware of the International Mobile Subscriber Identity (IMSI) and an internal IP address assigned to the UE.
主な問題は次のとおりです。PCEF、ポリシーおよび課金ルール機能（PCRF）、およびAFはすべて、同じユーザー機器（UE）にバインドされた情報を受信しますが、各エンティティに表示されるデータの一部を関連付けることができません。具体的には、PCEFは、UEに割り当てられた国際モバイルサブスクライバーアイデンティティ（IMSI）と内部IPアドレスを認識しています。
o AF receives an external IP address and port as assigned by the NAT function.
o AFは、NAT機能によって割り当てられた外部IPアドレスとポートを受信します。
o PCRF is not able to correlate between the external IP address/port assigned by the NAT (received from the AF) and the internal IP address and IMSI of the UE (received from the PCEF).
o PCRFは、NATによって割り当てられた外部IPアドレス/ポート（AFから受信）とUEの内部IPアドレスおよびIMSI（PCEFから受信）を関連付けることができません。
+------+
| PCRF |-----------------+
+------+ |
| |
+----+ +------+ +-----+ +-----+
| UE |------| PCEF |---| NAT |----| AF |
+----+ +------+ +-----+ +-----+
Figure 8: NAT Located between AF and PCEF
図8：AFとPCEFの間にあるNAT
This scenario can be generalized as follows (Figure 9):
このシナリオは、次のように一般化できます（図9）。
o Policy Enforcement Point (PEP) [RFC2753]
o ポリシー実施ポイント（PEP）[RFC2753]
o Policy Decision Point (PDP) [RFC2753]
o ポリシー決定ポイント（PDP）[RFC2753]
+------+
| PDP |-----------------+
+------+ |
| |
+----+ +------+ +-----+ +------+
| UE |------| PEP |---| NAT |----|Server|
+----+ +------+ +-----+ +------+
Figure 9: NAT Located between PEP and the Server
図9：PEPとサーバーの間にあるNAT
Note that an issue is encountered to enforce per-UE policies when the NAT is located before the PEP function (see Figure 10):
NATがPEP機能の前にある場合、UEごとのポリシーを適用する問題が発生することに注意してください（図10を参照）。
+------+
| PDP |------+
+------+ |
| |
+----+ +------+ +-----+ +------+
| UE |------| NAT |---| PEP |----|Server|
+----+ +------+ +-----+ +------+
Figure 10: NAT Located before PEP
図10：PEPの前にあるNAT
This scenario does not introduce privacy concerns since the identification of the host is local to a single administrative domain and is meant to help identify which policy to select for a UE.
ホストの識別は単一の管理ドメインに対してローカルであり、UEに対して選択するポリシーの識別を支援することを目的としているため、このシナリオではプライバシーの問題は発生しません。
Voice Service Providers (VSPs) operating under certain jurisdictions are required to route emergency calls from their subscribers and have to include information about the caller's location in signaling messages they send towards Public Safety Answering Points (PSAPs) [RFC6443] via an Emergency Service Routing Proxy (ESRP) [RFC6443]. This information is used both for the determination of the correct PSAP and to reveal the caller's location to the selected PSAP.
特定の管轄区域で運用されている音声サービスプロバイダー（VSP）は、サブスクライバーからの緊急コールをルーティングする必要があり、緊急サービスルーティングプロキシを介して公安通報ポイント（PSAP）[RFC6443]に送信するシグナリングメッセージに発信者の場所に関する情報を含める必要があります。 （ESRP）[RFC6443]。この情報は、正しいPSAPを決定するためと、選択したPSAPに発信者の場所を明らかにするための両方に使用されます。
In many countries, regulation bodies require that this information be provided by the network rather than the user equipment, in which case the VSP needs to retrieve this information (by reference or by value) from the access network where the caller is attached.
多くの国では、規制機関はこの情報がユーザー機器ではなくネットワークによって提供されることを要求しています。この場合、VSPは発信者が接続されているアクセスネットワークからこの情報を（参照または値によって）取得する必要があります。
This requires the VSP call server receiving an emergency call request to identify the relevant access network and to query a Location Information Server (LIS) in this network using a suitable lookup key. In the simplest case, the source IP address of the IP packet carrying the call request is used both for identifying the access network (thanks to a reverse DNS query) and as a lookup key to query the LIS. Obviously, the user-id as known by the VSP (e.g., telephone number or email-formatted URI) can't be used as it is not known by the access network.
これには、関連するアクセスネットワークを識別し、適切なルックアップキーを使用してこのネットワーク内のロケーション情報サーバー（LIS）にクエリを行うために、緊急コール要求を受信するVSPコールサーバーが必要です。最も単純なケースでは、呼び出し要求を運ぶIPパケットのソースIPアドレスは、アクセスネットワークの識別（リバースDNSクエリのおかげ）と、LISをクエリするための検索キーの両方に使用されます。明らかに、VSPが認識しているユーザーID（電話番号や電子メール形式のURIなど）は、アクセスネットワークが認識していないため使用できません。
The above mechanism is broken when there is a NAT between the user and the VSP and/or if the emergency call is established over a VPN tunnel (e.g., an employee remotely connected to a company Voice over IP (VoIP) server through a tunnel wishes to make an emergency call). In such cases, the source IP address received by the VSP call server will identify the NAT or the address assigned to the caller equipment by the VSP (i.e., the address inside the tunnel). This is similar to the CGN case in (Section 3) and overlay network case (Section 7) and applies irrespective of the IP versions used on both sides of the NAT and/or inside and outside the tunnel.
上記のメカニズムは、ユーザーとVSPの間にNATが存在する場合、および/またはVPNトンネルを介して緊急コールが確立された場合（たとえば、従業員がトンネルを介して会社のVoice over IP（VoIP）サーバーにリモート接続している場合）緊急電話をかけるため）。このような場合、VSPコールサーバーが受信したソースIPアドレスは、NATまたはVSPによって発信者の機器に割り当てられたアドレス（つまり、トンネル内のアドレス）を識別します。これは（セクション3）のCGNケースおよびオーバーレイネットワークケース（セクション7）に似ており、NATの両側やトンネルの内側と外側で使用されているIPバージョンに関係なく適用されます。
Therefore, the VSP needs to receive an additional piece of information that can be used to both identify the access network where the caller is attached and query the LIS for his/her location. This would require the NAT or the tunnel endpoint to insert this extra information in the call requests delivered to the VSP call servers. For example, this extra information could be a combination of the local IP address assigned by the access network to the caller's equipment with some form of identification of this access network.
したがって、VSPは、発信者が接続されているアクセスネットワークを識別し、LISに自分の場所を照会するために使用できる追加情報を受信する必要があります。これには、VSPコールサーバーに配信されるコールリクエストにこの追加情報を挿入するために、NATまたはトンネルエンドポイントが必要になります。たとえば、この追加情報は、アクセスネットワークによって発信者の機器に割り当てられたローカルIPアドレスと、このアクセスネットワークを識別する何らかの形式のIDの組み合わせです。
However, because it shall be possible to set up an emergency call regardless of the actual call control protocol used between the user and the VSP (e.g., SIP [RFC3261], Inter-Asterisk eXchange (IAX) [RFC5456], tunneled over HTTP, or proprietary protocol, possibly encrypted), this extra information has to be conveyed outside the call request, in the header of lower-layer protocols.
ただし、ユーザーとVSPの間で使用される実際の呼制御プロトコル（SIP [RFC3261]、Inter-Asterisk eXchange（IAX）[RFC5456]など）に関係なく、緊急呼をセットアップできるため、HTTPでトンネリングされます。または独自のプロトコル（暗号化されている可能性があります）の場合、この追加情報は、下位層プロトコルのヘッダーで、呼び出し要求の外部に伝達する必要があります。
Privacy-related considerations discussed in [RFC6967] apply for this scenario.
[RFC6967]で説明されているプライバシー関連の考慮事項は、このシナリオに適用されます。
This section lists deployment scenarios that are variants of scenarios described in previous sections.
このセクションでは、前のセクションで説明したシナリオのバリアントである展開シナリオを示します。
In the context of Provider WLAN, a dedicated Service Set Identifier (SSID) can be configured and advertised by the Residential Gateway (RG) for visiting terminals. These visiting terminals can be mobile terminals, PCs, etc.
プロバイダーWLANのコンテキストでは、専用のサービスセット識別子（SSID）を設定して、レジデンシャルゲートウェイ（RG）が訪問端末に通知することができます。これらの訪問端末は、モバイル端末、PCなどです。
Several deployment scenarios are envisaged:
いくつかの展開シナリオが想定されています。
1. Deploy a dedicated node in the service provider's network that will be responsible for intercepting all the traffic issued from visiting terminals (see Figure 11). This node may be co-located with a CGN function if private IPv4 addresses are assigned to visiting terminals. Similar to the CGN case discussed in Section 3, remote servers may not be able to distinguish visiting hosts sharing the same IP address (see [RFC6269]).
1. 訪問先の端末から発行されたすべてのトラフィックを傍受する責任を持つ専用ノードをサービスプロバイダーのネットワークに配置します（図11を参照）。プライベートIPv4アドレスが巡回端末に割り当てられている場合、このノードはCGN機能と同じ場所に配置できます。セクション3で説明したCGNの場合と同様に、リモートサーバーは、同じIPアドレスを共有する訪問ホストを区別できない場合があります（[RFC6269]を参照）。
2. Unlike the previous deployment scenario, IPv4 addresses are managed by the RG without requiring any additional NAT to be deployed in the service provider's network for handling traffic issued from visiting terminals. Concretely, a visiting terminal is assigned with a private IPv4 address from the IPv4 address pool managed by the RG. Packets issued from a visiting terminal are translated using the public IP address assigned to the RG (see Figure 12). This deployment scenario induces the following identification concerns:
2. 以前の展開シナリオとは異なり、IPv4アドレスはRGによって管理され、訪問先の端末から発行されたトラフィックを処理するためにサービスプロバイダーのネットワークに追加のNATを展開する必要はありません。具体的には、巡回端末には、RGが管理するIPv4アドレスプールからプライベートIPv4アドレスが割り当てられます。巡回端末から発行されたパケットは、RGに割り当てられたパブリックIPアドレスを使用して変換されます（図12を参照）。この展開シナリオは、次の識別の問題を引き起こします。
* The provider is not able to distinguish the traffic belonging to the visiting terminal from the traffic of the subscriber owning the RG. This is needed to identify which policies are to be enforced such as: accounting, Differentiated Services Code Point (DSCP) remarking, black list, etc.
* プロバイダーは、巡回端末に属するトラフィックとRGを所有する加入者のトラフィックを区別できません。これは、アカウンティング、Differentiated Services Code Point（DSCP）の再マーキング、ブラックリストなど、適用するポリシーを識別するために必要です。
* Similar to the CGN case Section 3, a misbehaving visiting terminal is likely to have some impact on the experienced service by the subscriber owning the RG (e.g., some of the issues are discussed in [RFC6269]).
* CGNケースのセクション3と同様に、不正な訪問端末は、RGを所有する加入者による経験豊富なサービスに何らかの影響を与える可能性があります（たとえば、[RFC6269]でいくつかの問題が説明されています）。
+-------------+
|Local_HOST_1 |----+
+-------------+ |
| |
+-------------+ +-----+ | +-----------+
|Local_HOST_2 |--| RG |-|--|Border Node|
+-------------+ +-----+ | +----NAT----+
| |
+-------------+ | | Service Provider
|Visiting Host|-----+
+-------------+
Figure 11: NAT Enforced in a Service Provider's Node
図11：サービスプロバイダーのノードで強制されるNAT
+-------------+
|Local_HOST_1 |----+
+-------------+ |
| |
+-------------+ +-----+ | +-----------+
|Local_HOST_2 |--| RG |-|--|Border Node|
+-------------+ +-NAT-+ | +-----------+
| |
+-------------+ | | Service Provider
|Visiting Host|-----+
+-------------+
Figure 12: NAT Located in the RG
図12：RGにあるNAT
This scenario does not introduce privacy concerns since the identification of the host is local to a single administrative domain and is meant to help identify which policy to select for a visiting UE.
ホストの識別は単一の管理ドメインに対してローカルであり、訪問しているUEに対して選択するポリシーを識別するのに役立つため、このシナリオではプライバシーの問題は発生しません。
Cellular operators allocate private IPv4 addresses to mobile terminals and deploy NAT44 function, generally co-located with firewalls, to access public IP services. The NAT function is located at the boundaries of the Public Land Mobile Network (PLMN). IPv6-only strategy, consisting in allocating IPv6 prefixes only to mobile terminals, is considered by various operators. A NAT64 function is also considered in order to preserve IPv4 service continuity for these customers.
携帯電話事業者は、モバイル端末にプライベートIPv4アドレスを割り当て、一般にファイアウォールと同じ場所にあるNAT44機能を展開して、パブリックIPサービスにアクセスします。 NAT機能は、Public Land Mobile Network（PLMN）の境界にあります。 IPv6プレフィックスをモバイル端末にのみ割り当てるというIPv6のみの戦略は、さまざまな事業者によって検討されています。これらの顧客のIPv4サービスの継続性を維持するために、NAT64機能も考慮されます。
These NAT44 and NAT64 functions bring some issues that are very similar to those mentioned in Figure 1 and Section 8. These issues are particularly encountered if policies are to be applied on the Gi interface.
これらのNAT44およびNAT64関数には、図1およびセクション8で述べたものと非常によく似たいくつかの問題があります。これらの問題は、Giインターフェイスにポリシーを適用する場合に特に発生します。
Note: 3GPP defines the Gi interface as the reference point between the Gateway GPRS Support Node (GGSN) and an external Packet Domain Network (PDN). This interface reference point is called SGi in 4G networks (i.e., between the PDN Gateway and an external PDN).
注：3GPPは、GiインターフェースをゲートウェイGPRSサポートノード（GGSN）と外部パケットドメインネットワーク（PDN）の間の参照ポイントとして定義します。このインターフェース参照ポイントは、4GネットワークではSGiと呼ばれます（つまり、PDNゲートウェイと外部PDNの間）。
Because private IP addresses are assigned to the mobile terminals, there is no correlation between the internal IP address and the external address:port assigned by the NAT function, etc.
プライベートIPアドレスはモバイル端末に割り当てられるため、内部IPアドレスと外部アドレス：NAT機能などによって割り当てられたポートとの間に相関関係はありません。
Privacy-related considerations discussed in [RFC6967] apply for this scenario.
[RFC6967]で説明されているプライバシー関連の考慮事項は、このシナリオに適用されます。
This scenario can be seen as a combination of the scenarios described in Sections 8 and 10.1.
このシナリオは、セクション8と10.1で説明されているシナリオの組み合わせとして見ることができます。
The reference architecture is shown in Figure 13.
リファレンスアーキテクチャを図13に示します。
A Femto Access Point (FAP) is defined as a home base station used to graft a local (femto) cell within a user's home to a mobile network.
フェムトアクセスポイント（FAP）は、ユーザーの自宅内のローカル（フェムト）セルをモバイルネットワークに接続するために使用されるホーム基地局として定義されます。
+---------------------------+
| +----+ +--------+ +----+ | +-----------+ +-------------------+
| | UE | | Stand- |<=|====|=|===|===========|==|=>+--+ +--+ |
| +----+ | Alone | | RG | | | | | | | | | Mobile |
| | FAP | +----+ | | | | |S | |F | Network|
| +--------+ (NAPT) | | Broadband | | |e | |A | |
+---------------------------+ | Fixed | | |G |-|P | +-----+|
| (BBF) | | |W | |G |-| Core||
+---------------------------+ | Network | | | | |W | | Ntwk||
| +----+ +------------+ | | | | | | | | +-----+|
| | UE | | Integrated |<====|===|===========|==|=>+--+ +--+ |
| +----+ | FAP (NAPT) | | +-----------+ +-------------------+
| +------------+ |
+---------------------------+
<=====> IPsec Tunnel
CoreNtwk Core Network
FAPGW FAP Gateway
NAPT Network Address Port Translator
SeGW Security Gateway
Figure 13: Femtocell Reference Architecture
図13：フェムトセルのリファレンスアーキテクチャ
UE is connected to the FAP at the RG, which is routed back to the 3GPP Evolved Packet Core (EPC). It is assumed that each UE is assigned an IPv4 address by the mobile network. A mobile operator's FAP leverages the IPsec Internet Key Exchange Protocol Version 2 (IKEv2) to interconnect FAP with the SeGW over the Broadband Fixed (BBF) network. Both the FAP and the SeGW are managed by the mobile operator, which may be a different operator for the BBF network.
UEはRGでFAPに接続され、これは3GPP Evolved Packet Core（EPC）にルーティングされます。各UEには、モバイルネットワークによってIPv4アドレスが割り当てられていると想定されます。モバイルオペレーターのFAPは、IPsecインターネットキーエクスチェンジプロトコルバージョン2（IKEv2）を利用して、ブロードバンド固定（BBF）ネットワーク経由でFAPをSeGWと相互接続します。 FAPとSeGWはどちらもモバイルオペレータによって管理されます。モバイルオペレータは、BBFネットワークでは別のオペレータになる場合があります。
An investigated scenario is when the mobile operator passes on its mobile subscriber's policies to the BBF to support traffic policy control. But most of today's broadband fixed networks are relying on the private IPv4 addressing plan (+NAPT) to support its attached devices, including the mobile operator's FAP. In this scenario, the mobile network needs to:
調査されたシナリオは、モバイルオペレーターがモバイル加入者のポリシーをBBFに渡して、トラフィックポリシー制御をサポートする場合です。しかし、今日のブロードバンド固定ネットワークのほとんどは、モバイルオペレーターのFAPを含む接続デバイスをサポートするために、プライベートIPv4アドレス指定計画（+ NAPT）に依存しています。このシナリオでは、モバイルネットワークは次のことを行う必要があります。
o determine the FAP's public IPv4 address to identify the location of the FAP to ensure its legitimacy to operate on the license spectrum for a given mobile operator prior to the FAP being ready to serve its mobile devices.
o FAPのパブリックIPv4アドレスを特定してFAPの場所を特定し、FAPがモバイルデバイスにサービスを提供する準備が整う前に、特定のモバイルオペレーターのライセンススペクトルを操作する正当性を確認します。
o determine the FAP's public IPv4 address together with the translated port number of the UDP header of the encapsulated IPsec tunnel for identifying the UE's traffic at the fixed broadband network.
o 固定ブロードバンドネットワークでのUEのトラフィックを識別するために、カプセル化されたIPsecトンネルのUDPヘッダーの変換されたポート番号とともにFAPのパブリックIPv4アドレスを決定します。
o determine the corresponding FAP's public IPv4 address associated with the UE's inner IPv4 address that is assigned by the mobile network to identify the mobile UE, which allows the PCRF to retrieve the special UE's policy (e.g., QoS) to be passed onto the Broadband Policy Control Function (BPCF) at the BBF network.
o モバイルネットワークによって割り当てられたUEの内部IPv4アドレスに関連付けられた対応するFAPのパブリックIPv4アドレスを決定して、モバイルUEを識別します。これにより、PCRFがブロードバンドポリシーコントロールに渡される特別なUEのポリシー（QoSなど）を取得できるようになります。 BBFネットワークでの機能（BPCF）。
SeGW would have the complete knowledge of such mapping, but the reasons for being unable to use SeGW for this purpose are explained in Section 2 of [IKEv2-CP-EXT].
SeGWはそのようなマッピングの完全な知識を持っていますが、この目的でSeGWを使用できない理由は、[IKEv2-CP-EXT]のセクション2で説明されています。
This scenario involves PCRF/BPCF, but it is valid in other deployment scenarios making use of Authentication, Authorization, and Accounting (AAA) servers.
このシナリオにはPCRF / BPCFが含まれますが、認証、承認、およびアカウンティング（AAA）サーバーを利用する他の展開シナリオでも有効です。
The issue of correlating the internal IP address and the public IP address is valid even if there is no NAT in the path.
パスにNATがない場合でも、内部IPアドレスとパブリックIPアドレスを関連付ける問題は有効です。
This scenario does not introduce privacy concerns since the identification of the host is local to a single administrative domain and is meant to help identify which policy to select for a UE.
ホストの識別は単一の管理ドメインに対してローカルであり、UEに対して選択するポリシーの識別を支援することを目的としているため、このシナリオではプライバシーの問題は発生しません。
Operators expect that the traffic subject to the packet inspection is routed via the Traffic Detection Function (TDF) as per the requirement specified in [TS29.212]; otherwise, the traffic may bypass the TDF. This assumption only holds if it is possible to identify individual UEs behind the Basic NAT or NAPT invoked in the RG connected to the fixed broadband network, as shown in Figure 14. As a result, additional mechanisms are needed to enable this requirement.
オペレーターは、パケット検査の対象となるトラフィックが、[TS29.212]で指定された要件に従って、トラフィック検出機能（TDF）経由でルーティングされることを期待します。そうしないと、トラフィックがTDFをバイパスする可能性があります。この仮定は、図14に示すように、固定ブロードバンドネットワークに接続されたRGで呼び出された基本NATまたはNAPTの背後にある個々のUEを識別できる場合にのみ当てはまります。そのため、この要件を有効にするには追加のメカニズムが必要です。
+--------+
| |
+-------+ PCRF |
| | |
| +--------+
+--------+ +--------+ +--------+ +----+----+
| | | | | +-----+ |
| ------------------------------------------------------------------
| | | | | | | TDF | / \
| ****************************************************************** |
+--------+ +--------+ +--------+ +----+----+ | |
| | | +-------+ | | |Service|
| | | | | | | \ /
| | | | | | | +--------+
| | | | | | +--------+ PDN |
| >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> |
| UE | | RG | | BNG +------------------+ Gateway|
+--------+ +--------+ +--------+ +--------+
Legend:
--------- 3GPP UE User-Plane Traffic Offloaded subject to packet
inspection
********* 3GPP UE User-Plane Traffic Offloaded not subject to packet
inspection
>>>>>>>>> 3GPP UE User-Plane Traffic Home Routed
BNG Broadband Network Gateway
Bongブロードバンドネットワークゲートウェイ
Figure 14: UE's Traffic Routed with TDF
図14：TDFでルーティングされたUEのトラフィック
This scenario does not introduce privacy concerns since the identification of the host is local to a single administrative domain and is meant to help identify which policy to select for a UE.
ホストの識別は単一の管理ドメインに対してローカルであり、UEに対して選択するポリシーの識別を支援することを目的としているため、このシナリオではプライバシーの問題は発生しません。
In the Policy for Convergence of Fixed Mobile Convergence (FMC) scenario, the fixed broadband network must partner with the mobile network to acquire the policies for the terminals or hosts attaching to the fixed broadband network, shown in Figure 15, so that host-specific QoS and accounting policies can be applied.
図15に示すように、固定ブロードバンドネットワークのコンバージェンスポリシー（FMC）シナリオでは、固定ブロードバンドネットワークは、固定ブロードバンドネットワークに接続する端末またはホストのポリシーを取得して、ホスト固有のポリシーを取得する必要があります。 QoSおよびアカウンティングポリシーを適用できます。
A UE is connected to the RG, which is routed back to the mobile network. The mobile operator's PCRF needs to maintain the interconnect with the BPCF in the BBF network for PCC (Section 8). The hosts (i.e., UEs) attaching to a fixed broadband network with a Basic NAT or NAPT deployed should be identified. Based on the UE identification, the BPCF can acquire the associated policy rules of the identified UE from the PCRF in the mobile network so that it can enforce policy rules in the fixed broadband network. Note, this scenario assumes private IPv4 addresses are assigned in the fixed broadband network. Requirements similar to those in Section 10.3 are raised in this scenario.
UEはRGに接続され、RGはモバイルネットワークにルーティングされます。モバイルオペレータのPCRFは、PCCのBBFネットワークでBPCFとの相互接続を維持する必要があります（セクション8）。基本NATまたはNAPTが展開されている固定ブロードバンドネットワークに接続しているホスト（UE）を特定する必要があります。 UEの識別に基づいて、BPCFはモバイルネットワークのPCRFから識別されたUEの関連するポリシールールを取得できるため、固定ブロードバンドネットワークでポリシールールを適用できます。このシナリオでは、固定ブロードバンドネットワークでプライベートIPv4アドレスが割り当てられていることを前提としています。このシナリオでは、セクション10.3と同様の要件が発生します。
+------------------------------+ +-------------+
| | | |
| +------+ | | +------+ |
| | BPCF +---+---+-+ PCRF | |
| +--+---+ | | +---+--+ |
+-------+ | | | | | |
|HOST_1 | Private IP1 +--+---+ | | +---+--+ |
+-------+ | +----+ | | | | | | |
| | RG | | | | | | | |
| |with+-------------+ BNG +--------+ PGW | |
+-------+ | | NAT| | | | | | | |
|HOST_2 | | +----+ | | | | | | |
+-------+ Private IP2 +------+ | | +------+ |
| | | |
| | | |
| Fixed | | Mobile |
| Broadband | | Network |
| Network | | |
| | | |
+------------------------------+ +-------------+
Figure 15: Reference Architecture for Policy for Convergence in Fixed and Mobile Network Convergence (1)
図15：固定およびモバイルネットワークの収束における収束のポリシーのリファレンスアーキテクチャ（1）
In an IPv6 network, similar issues exist when the IPv6 prefix is shared between multiple UEs attaching to the RG (see Figure 16). The case applies when RG is assigned a single prefix, the home network prefix, e.g., using DHCPv6 Prefix Delegation [RFC3633] with the edge router, and BNG acts as the Delegating Router (DR). RG uses the home network prefix in the address configuration using stateful (DHCPv6) or stateless address autoconfiguration (SLAAC) techniques.
IPv6ネットワークでは、RGに接続している複数のUE間でIPv6プレフィックスが共有されている場合、同様の問題が存在します（図16を参照）。このケースは、RGに単一のプレフィックス、たとえば、DHCPv6プレフィックス委任[RFC3633]をエッジルーターで使用してホームネットワークプレフィックスが割り当てられ、BNGが委任ルーター（DR）として機能する場合に適用されます。 RGは、ステートフル（DHCPv6）またはステートレスアドレス自動構成（SLAAC）技術を使用して、アドレス構成でホームネットワークプレフィックスを使用します。
+------------------------------+ +-------------+
| | | |
| | | +------+ |
| +-------------+ PCRF | |
| | | | +---+--+ |
+-------+ | | | | | |
|HOST_1 |--+ +--+---+ | | +---+--+ |
+-------+ | +----+ | | | | | | |
| | RG | | | | | | | |
| | +------------+ BNG +---------+ PGW | |
+-------+ | | | | | | | | | |
|HOST_2 |--+ +----+ | | | | | | |
+-------+ | +------+ | | +------+ |
| | | |
| | | |
| Fixed | | Mobile |
| Broadband | | Network |
| Network | | |
| | | |
+------------------------------+ +-------------+
Figure 16: Reference Architecture for Policy for Convergence in Fixed and Mobile Network Convergence (2)
図16：固定ネットワークとモバイルネットワークの収束における収束のポリシーのリファレンスアーキテクチャ（2）
BNG acting as PCEF initiates an IP Connectivity Access Network (IP-CAN) session with the policy server, a.k.a. Policy and Charging Rules Function (PCRF), to receive the Quality of Service (QoS) parameters and charging rules. BNG provides the PCRF with the IPv6 prefix assigned to the host; in this case, it's the home network prefix and an ID that has to be equal to the RG-specific home network line ID.
PCEFとして機能するBNGは、ポリシーサーバー（ポリシーおよび課金ルール機能（PCRF））とのIP接続アクセスネットワーク（IP-CAN）セッションを開始して、サービス品質（QoS）パラメーターと課金ルールを受信します。 BNGは、ホストに割り当てられたIPv6プレフィックスをPCRFに提供します。この場合、これはホームネットワークプレフィックスとRG固有のホームネットワークラインIDと等しくなければならないIDです。
HOST_1 in Figure 16 creates a 128-bit IPv6 address using this prefix and adding its interface ID. Having completed the address configuration, the host can start communication with a remote host over the Internet. However, no specific IP-CAN session can be assigned to HOST_1, and consequently the QoS and accounting performed will be based on RG subscription.
図16のHOST_1は、このプレフィックスを使用して128ビットのIPv6アドレスを作成し、そのインターフェースIDを追加します。アドレスの設定が完了すると、ホストはインターネット経由でリモートホストとの通信を開始できます。ただし、特定のIP-CANセッションをHOST_1に割り当てることはできないため、実行されるQoSおよびアカウンティングはRGサブスクリプションに基づいて行われます。
Another host, e.g., HOST_2, attaches to the RG and also establishes an IPv6 address using the home network prefix. The edge router, or BNG, is not involved with this or any other such address assignments.
別のホスト（HOST_2など）がRGに接続し、ホームネットワークプレフィックスを使用してIPv6アドレスを確立します。エッジルーター（BNG）は、このアドレス割り当てや他のそのようなアドレス割り当てには関与していません。
This leads to the case where no specific IP-CAN session/sub-session can be assigned to the hosts, HOST_1, HOST_2, etc., and consequently the QoS and accounting performed can only be based on RG subscription and is not host specific. Therefore, IPv6 prefix sharing in the Policy for Convergence scenario leads to similar issues as the address sharing as explained in the previous scenarios in this document.
これにより、特定のIP-CANセッション/サブセッションをホスト、HOST_1、HOST_2などに割り当てることができず、その結果、実行されるQoSおよびアカウンティングはRGサブスクリプションにのみ基づくことができ、ホスト固有ではありません。したがって、収束ポリシーのシナリオでIPv6プレフィックスを共有すると、このドキュメントの前のシナリオで説明したアドレス共有と同様の問題が発生します。
The following table shows whether each scenario is valid for IPv4/ IPv6 and if it is within one single administrative domain or spans multiple domains. The table also identifies the root cause of the identification issues.
次の表は、各シナリオがIPv4 / IPv6に有効かどうか、1つの単一の管理ドメイン内にあるか、複数のドメインにまたがっているかを示しています。この表は、識別の問題の根本的な原因も示しています。
The IPv6 column indicates for each scenario whether IPv6 is supported at the client's side and/or server's side.
IPv6列は、シナリオごとに、クライアント側またはサーバー側、あるいはその両方でIPv6がサポートされているかどうかを示しています。
+-------------------+----+-------------+------+-----------------+
| | | IPv6 |Single| Root Cause |
| Scenario | |------+------|Domain+-------+---------+
| |IPv4|Client|Server| |Address|Tunneling|
| | | | | |sharing| |
+-------------------+----+------+------+------+-------+---------+
| CGN |Yes |Yes(1)| No | No | Yes | No |
| A+P |Yes | No | No | No | Yes | No |
| Application Proxy |Yes | Yes | Yes | No | Yes | No |
| Distributed Proxy |Yes | Yes | Yes |Yes/No| Yes | No |
| Overlay Networks |Yes |Yes(2)|Yes(2)| No | Yes | No |
| PCC |Yes |Yes(1)| No | Yes | Yes | No |
| Emergency Calls |Yes | Yes | Yes | No | Yes | No |
| Provider WLAN |Yes | No | No | Yes | Yes | No |
| Cellular Networks |Yes |Yes(1)| No | Yes | Yes | No |
| Femtocells |Yes | No | No | No | Yes | Yes |
| TDF |Yes | Yes | No | Yes | Yes | No |
| FMC |Yes |Yes(1)| No | No | Yes | No |
+-------------------+----+------+------+------+-------+---------+
Notes: (1) For example, NAT64 (2) This scenario is a combination of CGN and application proxies
注：（1）たとえば、NAT64（2）このシナリオは、CGNとアプリケーションプロキシの組み合わせです。
Table 1: Synthesis
表1：合成
Privacy-related considerations that apply to means to reveal a host identifier are discussed in [RFC6967]. This document does not introduce additional privacy issues than those discussed in [RFC6967].
ホスト識別子を明らかにする手段に適用されるプライバシー関連の考慮事項は、[RFC6967]で説明されています。このドキュメントでは、[RFC6967]で説明されているもの以外のプライバシーの問題は紹介していません。
None of the scenarios inventoried in this document aim at revealing a customer identifier, account identifier, profile identifier, etc.
このドキュメントでインベントリされたシナリオは、顧客識別子、アカウント識別子、プロファイル識別子などを明らかにすることを目的としていません。
Particularly, none of these scenarios are endorsing the functionality
provided by the following proprietary headers (but not limited to)
that are known to be used to leak subscription-related information:
HTTP_MSISDN, HTTP_X_MSISDN, HTTP_X_UP_CALLING_LINE_ID,
HTTP_X_NOKIA_MSISDN, HTTP_X_HTS_CLID, HTTP_X_MSP_CLID,
HTTP_X_NX_CLID, HTTP__RAPMIN, HTTP_X_WAP_MSISDN, HTTP_COOKIE,
HTTP_X_UP_LSID, HTTP_X_H3G_MSISDN, HTTP_X_JINNY_CID,
HTTP_X_NETWORK_INFO, etc.
This document does not define an architecture nor a protocol; as such it does not raise any security concerns. Security considerations that are related to the host identifier are discussed in [RFC6967].
このドキュメントでは、アーキテクチャもプロトコルも定義していません。そのため、セキュリティ上の問題は発生しません。ホスト識別子に関連するセキュリティの考慮事項は、[RFC6967]で説明されています。
[BCP160] Barnes, R., Lepinski, M., Cooper, A., Morris, J., Tschofenig, H., and H. Schulzrinne, "An Architecture for Location and Location Privacy in Internet Applications", BCP 160, RFC 6280, July 2011.
[BCP160] Barnes、R.、Lepinski、M.、Cooper、A.、Morris、J.、Tschofenig、H。、およびH. Schulzrinne、「An Internet Location in Location and Location Privacy in Internet Applications」、BCP 160、RFC 6280、2011年7月。
[BCP188] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, May 2014.
[BCP188] Farrell、S。およびH. Tschofenig、「Pervasive Monitoring Is Is a Attack」、BCP 188、RFC 7258、2014年5月。
[EFFOpenWireless] EFF, "Open Wireless", 2014, <https://www.eff.org/issues/ open-wireless>.
[EFFOpenWireless] EFF、「Open Wireless」、2014、<https://www.eff.org/issues/ open-wireless>。
[IEEE101109] Salah, K., Calero, J., Zeadally, S., Almulla, S., and M. ZAaabi, "Using Cloud Computing to Implement a Security Overlay Network", IEEE Computer Society Digital Library, IEEE Security & Privacy, Vol. 11, Issue 1, pp. 44-53, DOI 10.1109/MSP.2012.88, Jan-Feb 2013.
[IEEE101109] Salah、K.、Calero、J.、Zeadally、S.、Almulla、S。、およびM. ZAaabi、「クラウドコンピューティングを使用したセキュリティオーバーレイネットワークの実装」、IEEE Computer Society Digital Library、IEEE Security＆Privacy 、Vol。 11、問題1、44-53ページ、DOI 10.1109 / MSP.2012.88、2013年1月から2月。
[IEEE1344002] Byers, J., Considine, J., Mitzenmacher, M., and S. Rost, "Informed content delivery across adaptive overlay networks", IEEE/ACM Transactions on Networking, Vol. 12, Issue 5, pp. 767-780, DOI 10.1109/TNET.2004.836103, October 2004.
[IEEE1344002] Byers、J.、Considine、J.、Mitzenmacher、M。、およびS. Rost、「適応型オーバーレイネットワークを介した情報に基づくコンテンツ配信」、IEEE / ACM Transactions on Networking、Vol。 12、第5号、767-780ページ、DOI 10.1109 / TNET.2004.836103、2004年10月。
[IKEv2-CP-EXT] So, T., "IKEv2 Configuration Payload Extension for Private IPv4 Support for Fixed Mobile Convergence", Work in Progress, draft-so-ipsecme-ikev2-cpext-02, June 2012.
[IKEv2-CP-EXT]したがって、T。、「固定モバイルコンバージェンスのプライベートIPv4サポート用のIKEv2構成ペイロード拡張機能」、作業中、draft-so-ipsecme-ikev2-cpext-02、2012年6月。
[OVERLAYPATH] Williams, B., "Overlay Path Option for IP and TCP", Work in Progress, draft-williams-overlaypath-ip-tcp-rfc-04, June 2013.
[OVERLAYPATH]ウィリアムズ、B。、「IPおよびTCPのオーバーレイパスオプション」、作業中、draft-williams-overlaypath-ip-tcp-rfc-04、2013年6月。
[RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, DOI 10.17487/RFC2753, January 2000, <http://www.rfc-editor.org/info/rfc2753>.
[RFC2753] Yavatkar、R.、Pendarakis、D。、およびR. Guerin、「A Framework for Policy-based Admission Control」、RFC 2753、DOI 10.17487 / RFC2753、2000年1月、<http：//www.rfc-editor .org / info / rfc2753>。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」 、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<http://www.rfc-editor.org/info/rfc3261>。
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, DOI 10.17487/RFC3633, December 2003, <http://www.rfc-editor.org/info/rfc3633>.
[RFC3633] Troan、O。およびR. Droms、「動的ホスト構成プロトコル（DHCP）バージョン6のIPv6プレフィックスオプション」、RFC 3633、DOI 10.17487 / RFC3633、2003年12月、<http：//www.rfc-editor。 org / info / rfc3633>。
[RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report from the IAB Workshop on Routing and Addressing", RFC 4984, DOI 10.17487/RFC4984, September 2007, <http://www.rfc-editor.org/info/rfc4984>.
[RFC4984] Meyer、D。、編、Zhang、L。、編、およびK. Fall、編、「ルーティングとアドレッシングに関するIABワークショップからの報告」、RFC 4984、DOI 10.17487 / RFC4984、2007年9月、 <http://www.rfc-editor.org/info/rfc4984>。
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, <http://www.rfc-editor.org/info/rfc5321>.
[RFC5321] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 5321、DOI 10.17487 / RFC5321、2008年10月、<http://www.rfc-editor.org/info/rfc5321>。
[RFC5456] Spencer, M., Capouch, B., Guy, E., Ed., Miller, F., and K. Shumard, "IAX: Inter-Asterisk eXchange Version 2", RFC 5456, DOI 10.17487/RFC5456, February 2010, <http://www.rfc-editor.org/info/rfc5456>.
[RFC5456] Spencer、M.、Capouch、B.、Guy、E.、Ed。、Miller、F。、およびK. Shumard、「IAX：Inter-Asterisk eXchange Version 2」、RFC 5456、DOI 10.17487 / RFC5456、 2010年2月、<http://www.rfc-editor.org/info/rfc5456>。
[RFC5694] Camarillo, G., Ed. and IAB, "Peer-to-Peer (P2P) Architecture: Definition, Taxonomies, Examples, and Applicability", RFC 5694, DOI 10.17487/RFC5694, November 2009, <http://www.rfc-editor.org/info/rfc5694>.
[RFC5694]カマリロ、G、エド。およびIAB、「Peer-to-Peer（P2P）Architecture：Definition、Taxonomies、Examples、and Applicability」、RFC 5694、DOI 10.17487 / RFC5694、2009年11月、<http://www.rfc-editor.org/info/ rfc5694>。
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, April 2011, <http://www.rfc-editor.org/info/rfc6146>.
[RFC6146] Bagnulo、M.、Matthews、P。、およびI. van Beijnum、「Stateful NAT64：Network Address and Protocol Translation to IPv6 Clients to IPv4 Servers」、RFC 6146、DOI 10.17487 / RFC6146、2011年4月、<http： //www.rfc-editor.org/info/rfc6146>。
[RFC6179] Templin, F., Ed., "The Internet Routing Overlay Network (IRON)", RFC 6179, DOI 10.17487/RFC6179, March 2011, <http://www.rfc-editor.org/info/rfc6179>.
[RFC6179] Templin、F。、編、「インターネットルーティングオーバーレイネットワーク（IRON）」、RFC 6179、DOI 10.17487 / RFC6179、2011年3月、<http://www.rfc-editor.org/info/rfc6179> 。
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, DOI 10.17487/RFC6265, April 2011, <http://www.rfc-editor.org/info/rfc6265>.
[RFC6265] Barth、A。、「HTTP State Management Mechanism」、RFC 6265、DOI 10.17487 / RFC6265、2011年4月、<http://www.rfc-editor.org/info/rfc6265>。
[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, DOI 10.17487/RFC6269, June 2011, <http://www.rfc-editor.org/info/rfc6269>.
[RFC6269] Ford、M.、Ed。、Boucadair、M.、Durand、A.、Levis、P。、およびP. Roberts、「Issues with IP Address Sharing」、RFC 6269、DOI 10.17487 / RFC6269、2011年6月、 <http://www.rfc-editor.org/info/rfc6269>。
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, <http://www.rfc-editor.org/info/rfc6296>.
[RFC6296] Wasserman、M。およびF. Baker、「IPv6-to-IPv6 Network Prefix Translation」、RFC 6296、DOI 10.17487 / RFC6296、2011年6月、<http://www.rfc-editor.org/info/rfc6296 >。
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, <http://www.rfc-editor.org/info/rfc6333>.
[RFC6333] Durand、A.、Droms、R.、Woodyatt、J。、およびY. Lee、「IPv4枯渇後のデュアルスタックLiteブロードバンド展開」、RFC 6333、DOI 10.17487 / RFC6333、2011年8月、<http：/ /www.rfc-editor.org/info/rfc6333>。
[RFC6346] Bush, R., Ed., "The Address plus Port (A+P) Approach to the IPv4 Address Shortage", RFC 6346, DOI 10.17487/RFC6346, August 2011, <http://www.rfc-editor.org/info/rfc6346>.
[RFC6346]ブッシュ、R。、編、「IPv4アドレス不足に対するアドレスとポート（A + P）のアプローチ」、RFC 6346、DOI 10.17487 / RFC6346、2011年8月、<http：//www.rfc-editor .org / info / rfc6346>。
[RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, "Framework for Emergency Calling Using Internet Multimedia", RFC 6443, DOI 10.17487/RFC6443, December 2011, <http://www.rfc-editor.org/info/rfc6443>.
[RFC6443] Rosen、B.、Schulzrinne、H.、Polk、J。、およびA. Newton、「インターネットマルチメディアを使用した緊急通話のフレームワーク」、RFC 6443、DOI 10.17487 / RFC6443、2011年12月、<http：// www .rfc-editor.org / info / rfc6443>。
[RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common Requirements for Carrier-Grade NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, April 2013, <http://www.rfc-editor.org/info/rfc6888>.
[RFC6888] Perreault、S.、Ed。、Yamagata、I.、Miyakawa、S.、Nakagawa、A.、and H. Ashida、 "Common Requirements for Carrier-Grade NATs（CGNs）"、BCP 127、RFC 6888、 DOI 10.17487 / RFC6888、2013年4月、<http://www.rfc-editor.org/info/rfc6888>。
[RFC6967] Boucadair, M., Touch, J., Levis, P., and R. Penno, "Analysis of Potential Solutions for Revealing a Host Identifier (HOST_ID) in Shared Address Deployments", RFC 6967, DOI 10.17487/RFC6967, June 2013, <http://www.rfc-editor.org/info/rfc6967>.
[RFC6967] Boucadair、M.、Touch、J.、Levis、P。、およびR. Penno、「共有アドレス配置におけるホスト識別子（HOST_ID）を明らかにするための潜在的なソリューションの分析」、RFC 6967、DOI 10.17487 / RFC6967、 2013年6月、<http://www.rfc-editor.org/info/rfc6967>。
[RFC7239] Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", RFC 7239, DOI 10.17487/RFC7239, June 2014, <http://www.rfc-editor.org/info/rfc7239>.
[RFC7239] Petersson、A。およびM. Nilsson、「Forwarded HTTP Extension」、RFC 7239、DOI 10.17487 / RFC7239、2014年6月、<http://www.rfc-editor.org/info/rfc7239>。
[RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. Farrer, "Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, July 2015, <http://www.rfc-editor.org/info/rfc7596>.
[RFC7596] Cui、Y.、Sun、Q.、Boucadair、M.、Tsou、T.、Lee、Y.、I。Farrer、「Lightweight 4over6：An Extension to the Dual-Stack Lite Architecture」、RFC 7596 、DOI 10.17487 / RFC7596、2015年7月、<http://www.rfc-editor.org/info/rfc7596>。
[RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., Murakami, T., and T. Taylor, Ed., "Mapping of Address and Port with Encapsulation (MAP-E)", RFC 7597, DOI 10.17487/RFC7597, July 2015, <http://www.rfc-editor.org/info/rfc7597>.
[RFC7597] Troan、O.、Ed。、Dec、W.、Li、X.、Bao、C.、Matsushima、S.、Murakami、T.、and T. Taylor、Ed。、 "Mapping of Address and Portカプセル化あり（MAP-E）」、RFC 7597、DOI 10.17487 / RFC7597、2015年7月、<http://www.rfc-editor.org/info/rfc7597>。
[STATELESS-NAT44] Tsou, T., Liu, W., Perreault, S., Penno, R., and M. Chen, "Stateless IPv4 Network Address Translation", Work in Progress, draft-tsou-stateless-nat44-02, October 2012.
[STATELESS-NAT44] Tsou、T.、Liu、W.、Perreault、S.、Penno、R。、およびM. Chen、「Stateless IPv4 Network Address Translation」、Work in Progress、draft-tsou-stateless-nat44- 2012年10月2日。
[TS23.203] 3GPP, "Policy and charging control architecture (Release 11)", 3GPP TS23.203, September 2012.
[TS23.203] 3GPP、「ポリシーおよび課金制御アーキテクチャ（リリース11）」、3GPP TS23.203、2012年9月。
[TS29.212] 3GPP, "Policy and Charging Control (PCC); Reference points (Release 11)", 3GPP TS29.212, December 2013.
[TS29.212] 3GPP、「Policy and Charging Control（PCC）; Reference points（Release 11）」、3GPP TS29.212、2013年12月。
Acknowledgments
謝辞
Many thanks to F. Klamm, D. Wing, D. von Hugo, G. Li, D. Liu, and Y. Lee for their review.
F. Klamm、D。Wing、D。von Hugo、G。Li、D。Liu、Y。Leeのレビューに感謝します。
J. Touch, S. Farrel, and S. Moonesamy provided useful comments in the intarea mailing list.
J. Touch、S。Farrel、およびS. Moonesamyは、intareaメーリングリストで有益なコメントを提供しました。
Figure 8 and part of the text in Section 10.3 were inspired by [IKEv2-CP-EXT].
図8およびセクション10.3のテキストの一部は、[IKEv2-CP-EXT]に触発されました。
Contributors
貢献者
Many thanks to the following people for contributing text and comments to the document:
ドキュメントにテキストとコメントを提供してくれた以下の人々に感謝します。
o David Binet o Sophie Durel o Li Xue o Richard Stewart Wheeldon
o デビッドビネットまたはソフィーデュレルまたは李雪またはリチャードスチュワートウィールドン
Authors' Addresses
著者のアドレス
Mohamed Boucadair (editor) Orange Rennes 35000 France
Mohamed Boucadair（編集者）Orange Rennes 35000フランス
Email: mohamed.boucadair@orange.com
Bruno Chatras Orange Paris France
ブルーノシャトラスオレンジパリフランス
Email: bruno.chatras@orange.com
Tirumaleswar Reddy Cisco Systems Cessna Business Park, Varthur Hobli Sarjapur Marathalli Outer Ring Road Bangalore, Karnataka 560103 India
Thirumaleshwar Reddy Business Park of Cisco Systems Chase、Vartur Hobli Sarjapur Marathalli Outer Ring Road Bangalore、Karnataka ೫೬೦೧೦೩ India
Email: tireddy@cisco.com
Brandon Williams Akamai, Inc. Cambridge MA United States
Brandon Williams Akamai、Inc.ケンブリッジMAアメリカ合衆国
Email: brandon.williams@akamai.com
Behcet Sarikaya Huawei 5340 Legacy Dr. Building 3, Plano, TX 75024 United States
Behcet Sarikaya Huawei 5340 Legacy Dr. Building 3、Plano、TX 75024 United States
Email: sarikaya@ieee.org