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
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注释
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地址同时使用位置和标识属性重载的用例。这种语义重载被认为是路由系统中各种问题的原因[RFC4984]。此外，这些用例可能被视为证明解决方案不符合IETF关于保护隐私的最佳现行实践[BCP160][BCP188]的方法。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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编辑批准发布的文件不适用于任何级别的互联网标准；见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.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
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
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:
[RFC6269]中详细列出了运营商级NAT（CGN）、地址加端口（A+P）和应用程序代理方案遇到的问题。除这些问题外，本文档中描述的一些场景还存在其他问题，例如：
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.在两个管理域之间使用隧道。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][无状态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到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地址进行各种用途，如访问控制或滥用管理。主机标识丢失将导致[RFC6269]中讨论的问题。
+-----------+
| HOST_1 |----+
+-----------+ | +--------------------+ +------------+
| | |------| Server 1 |
+-----------+ +-----+ | | +------------+
| HOST_2 |--| CGN |----| INTERNET | ::
+-----------+ +-----+ | | +------------+
| | |------| Server n |
+-----------+ | +--------------------+ +------------+
| HOST_3 |-----+
+-----------+
+-----------+
| 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).
通过互联网（如NAT64）向IPv6过渡的最终完成将满足上述一些CGN场景，但并非所有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源端口限制在已配置的端口范围内。为了将传入的数据包转发到适当的主机，需要一个称为端口范围路由器（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地址进行各种用途，如访问控制或滥用管理。主机标识丢失将导致中讨论的问题
[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 |-----+
+-----------+
+-----------+
| 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 |-----+
+-----------+
+-----------+
| 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]).
同一管理员还可能希望有选择地隐藏或向服务器公开内部主机标识。他/她可能希望隐藏身份以保护最终用户隐私或降低流氓代理了解网络内部结构的能力。他/她可能希望允许上游服务器识别主机，以强制执行访问策略（例如，在文档或在线数据库上），启用帐户识别（在基于订阅的服务上），或防止将高流量模式错误识别为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的情况下，这种识别变得困难。替代解决方案包括使用cookie，cookie仅适用于HTTP流量、隧道或现有协议的专有扩展。
+-----------+ +----------+
| HOST_1 |-------------| |
+-----------+ | | +-------+ +----------+
| | | |----| Server 1 |
+-----------+ | | | | +----------+
| HOST_2 |----+ | INTERNET |---| Proxy | ::
+-----------+ +-----+ | | | | +----------+
|Proxy|----| | | |----| Server n |
+-----------+ +-----+ | | +-------+ +----------+
| HOST_3 |----+ +----------+
+-----------+
+-----------+ +----------+
| 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 |
+-----------+ +---+ +---+ +---+ +----------+
+-----------+ +---+ +---+ +----------+
| 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
覆盖网络是分布在公共互联网内多个自治系统中的机器网络，可用于提高数据传输性能（见图6）。来自发送方的IP数据包首先传送到组成覆盖网络的其中一台机器。然后，该机器将IP中继
packets to the receiver via one or more machines in the overlay network, applying various performance enhancement methods.
应用各种性能增强方法，通过覆盖网络中的一台或多台机器将数据包发送到接收器。
+------------------------------------+
| |
| INTERNET |
| |
+-----------+ | +------------+ |
| HOST_1 |-----| OVRLY_IN_1 |-----------+ |
+-----------+ | +------------+ | |
| | |
+-----------+ | +------------+ +-----------+ | +--------+
| HOST_2 |-----| OVRLY_IN_2 |-----| OVRLY_OUT |-----| Server |
+-----------+ | +------------+ +-----------+ | +--------+
| | |
+-----------+ | +------------+ | |
| HOST_3 |-----| OVRLY_IN_3 |-----------+ |
+-----------+ | +------------+ |
| |
+------------------------------------+
+------------------------------------+
| |
| 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.
为了使覆盖网络能够通过基本Internet连接基础设施透明地拦截数据包和/或连接，覆盖入口和出口主机（覆盖输入和覆盖输出）必须在连接发起主机和服务器之间的两个方向上可靠地处于路径中。当情况并非如此时，数据包可能会在覆盖层周围路由并直接发送到接收主机，可能不会调用覆盖层提供的某些高级服务功能。
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
对于公共覆盖网络，其中入口和/或出口主机位于公共Internet上，数据包截获通常使用源（SNAT）或目的地（DNAT）地址的网络地址转换，使得数据传输中涉及的真正端点主机的公共IP地址彼此不可见（参见图7）。例如，实际的发送方和接收方可以使用两对完全不同的源地址和目标地址来标识发送和接收端的连接
networks in cases where both the ingress and egress hosts are on the public Internet.
入口和出口主机都位于公共互联网上的情况下的网络。
IP hdr contains: IP hdr contains:
SENDER -> src = sender --> OVERLAY --> src = overlay2 --> RECEIVER
dst = overlay1 dst = receiver
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].
有关此场景的更多详细信息，请参见[OverlyPath]。
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）覆盖网络）的本地标识，或者传递到远程服务器以帮助将响应转发回相应的主机，因此此场景不会引入隐私问题。主机标识信息不公开，也不能向连接到Internet的其他主机披露。
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）之间时，该问题与3GPP在[TS23.203]中定义的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,
主要问题是：PCEF、策略和计费规则功能（PCRF）和AF都接收绑定到同一用户设备（UE）的信息，但无法关联每个实体可见的数据段。具体地说,，
o PCEF is aware of the International Mobile Subscriber Identity (IMSI) and an internal IP address assigned to the UE.
o 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 |
+----+ +------+ +-----+ +-----+
+------+
| 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|
+----+ +------+ +-----+ +------+
+------+
| 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|
+----+ +------+ +-----+ +------+
+------+
| 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）需要路由来自其用户的紧急呼叫，并且必须在通过紧急服务路由代理（ESRP）[RFC6443]向公共安全应答点（PSAP）[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.
这要求接收紧急呼叫请求的VSP呼叫服务器识别相关接入网络，并使用合适的查找键查询该网络中的位置信息服务器（LIS）。在最简单的情况下，承载呼叫请求的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隧道建立紧急呼叫（例如，通过隧道远程连接到公司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
因此，VSP需要接收一条附加信息，该信息既可用于识别呼叫者连接的接入网络，也可用于向LIS查询他/她的位置。这将要求NAT或隧道端点在发送到VSP呼叫服务器的呼叫请求中插入此额外信息。例如，该额外信息可以是接入网络分配给用户的本地IP地址的组合
caller's equipment with some form of identification of this access network.
呼叫方的设备，具有该接入网络的某种形式的标识。
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]、星号间交换（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的订户的通信量。这需要确定要实施哪些策略，例如：记帐、差异化服务代码点（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|-----+
+-------------+
+-------------+
|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|-----+
+-------------+
+-------------+
|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功能位于公共陆地移动网络（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) | | +-----------+ +-------------------+
| +------------+ |
+---------------------------+
+---------------------------+
| +----+ +--------+ +----+ | +-----------+ +-------------------+
| | 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
<=====> IPsec Tunnel
CoreNtwk Core Network
FAPGW FAP Gateway
NAPT Network Address Port Translator
SeGW Security Gateway
Figure 13: Femtocell Reference Architecture
图13:Femtocell参考架构
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，FAP被路由回3GPP演进包核心（EPC）。假设移动网络为每个UE分配了一个IPv4地址。移动运营商的FAP利用IPsec Internet密钥交换协议版本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以支持流量策略控制。但如今大多数宽带固定网络都依赖于专用IPv4寻址计划（+NAPT）来支持其连接设备，包括移动运营商的FAP。在这种情况下，移动网络需要：
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准备好为其移动设备提供服务之前，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 确定FAP的公共IPv4地址以及封装的IPsec隧道的UDP报头的转换端口号，以识别固定宽带网络上UE的流量。
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检索要传递到BBF网络上的宽带策略控制功能（BPCF）的特殊UE的策略（例如，QoS）。
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。仅当可以识别连接到固定宽带网络的RG中调用的基本NAT或NAPT后面的各个ue时，此假设成立，如图14所示。因此，需要额外的机制来实现这一要求。
+--------+
| |
+-------+ PCRF |
| | |
| +--------+
+--------+ +--------+ +--------+ +----+----+
| | | | | +-----+ |
| ------------------------------------------------------------------
| | | | | | | TDF | / \
| ****************************************************************** |
+--------+ +--------+ +--------+ +----+----+ | |
| | | +-------+ | | |Service|
| | | | | | | \ /
| | | | | | | +--------+
| | | | | | +--------+ PDN |
| >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> |
| UE | | RG | | BNG +------------------+ Gateway|
+--------+ +--------+ +--------+ +--------+
+--------+
| |
+-------+ PCRF |
| | |
| +--------+
+--------+ +--------+ +--------+ +----+----+
| | | | | +-----+ |
| ------------------------------------------------------------------
| | | | | | | TDF | / \
| ****************************************************************** |
+--------+ +--------+ +--------+ +----+----+ | |
| | | +-------+ | | |Service|
| | | | | | | \ /
| | | | | | | +--------+
| | | | | | +--------+ PDN |
| >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> |
| UE | | RG | | BNG +------------------+ Gateway|
+--------+ +--------+ +--------+ +--------+
Legend:
--------- 3GPP UE User-Plane Traffic Offloaded subject to packet
inspection
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 Offloaded not subject to packet
inspection
>>>>>>>>> 3GPP UE User-Plane Traffic Home Routed
>>>>>>>>> 3GPP UE User-Plane Traffic Home Routed
BNG Broadband Network Gateway
宽带网络网关
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.
在固定移动融合策略（FMC）场景中，固定宽带网络必须与移动网络合作，以获取连接到固定宽带网络的终端或主机的策略，如图15所示，以便应用特定于主机的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
UE连接到RG，RG被路由回移动网络。移动运营商的PCRF需要在PCC的BBF网络中保持与BPCF的互连（第8节）。连接到固定宽带网络的主机（即ue）具有
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.
应确定部署的基本NAT或NAPT。基于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 | | |
| | | |
+------------------------------+ +-------------+
+------------------------------+ +-------------+
| | | |
| +------+ | | +------+ |
| | 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 | | |
| | | |
+------------------------------+ +-------------+
+------------------------------+ +-------------+
| | | |
| | | +------+ |
| +-------------+ 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.
BNG作为PCEF启动与策略服务器（也称为策略和计费规则功能（PCRF））的IP连接接入网络（IP-CAN）会话，以接收服务质量（QoS）参数和计费规则。BNG向PCRF提供分配给主机的IPv6前缀；在这种情况下，家庭网络前缀和ID必须等于RG特定家庭网络线路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中的主机_1使用此前缀并添加其接口ID创建128位IPv6地址。完成地址配置后，主机可以通过Internet开始与远程主机通信。但是，不能将特定的IP-CAN会话分配给主机_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.
另一个主机，例如主机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
这导致无法将特定IP-CAN会话/子会话分配给主机、主机1、主机2等的情况，因此执行的QoS和记帐只能基于RG订阅，而不是主机特定的。因此，融合策略场景中的IPv6前缀共享会导致与
address sharing as explained in the previous scenarios in this document.
地址共享，如本文档前面的场景所述。
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有效，以及它是在单个管理域内还是跨多个域。该表还确定了识别问题的根本原因。
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 |
+-------------------+----+------+------+------+-------+---------+
+-------------------+----+-------------+------+-----------------+
| | | 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.
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，“互联网应用中的位置和位置隐私架构”，BCP 160，RFC 62802011年7月。
[BCP188] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, May 2014.
[BCP188]Farrell，S.和H.Tschofenig，“普遍监控是一种攻击”，BCP 188，RFC 7258，2014年5月。
[EFFOpenWireless] EFF, "Open Wireless", 2014, <https://www.eff.org/issues/ open-wireless>.
[EFF开放无线]EFF，“开放无线”，2014年<https://www.eff.org/issues/ 打开无线>。
[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计算机学会数字图书馆，IEEE安全与隐私，第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网络交易，第12卷，第5期，第767-780页，DOI 10.1109/TNET.2004.8361032004年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]So，T.“固定移动融合专用IPv4支持的IKEv2配置有效负载扩展”，正在进行的工作，草稿-So-ipsecme-IKEv2-cpext-022012年6月。
[OVERLAYPATH] Williams, B., "Overlay Path Option for IP and TCP", Work in Progress, draft-williams-overlaypath-ip-tcp-rfc-04, June 2013.
[OVERLAYPATH]Williams，B.，“IP和TCP的覆盖路径选项”，正在进行的工作，草稿-Williams-OVERLAYPATH-IP-TCP-rfc-042013年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，“基于政策的准入控制框架”，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：会话启动协议”，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.，Ed.，Zhang，L.，Ed.，和K.Fall，Ed.，“来自IAB路由和寻址研讨会的报告”，RFC 4984，DOI 10.17487/RFC49842007年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.，“简单邮件传输协议”，RFC 5321DOI 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:星号间交换版本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]Camarillo，G.，Ed.和IAB，“对等（P2P）体系结构：定义、分类、示例和适用性”，RFC 5694，DOI 10.17487/RFC56942009年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，“有状态NAT64：从IPv6客户端到IPv4服务器的网络地址和协议转换”，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.，Ed.“互联网路由覆盖网络（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状态管理机制”，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]福特，M.，Ed.，Boucadair，M.，Durand，A.，Levis，P.，和P.Roberts，“IP地址共享问题”，RFC 6269，DOI 10.17487/RFC62692011年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到IPv6网络前缀转换”，RFC 6296DOI 10.17487/RFC62962011年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]Bush，R.，Ed.，“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.，和H.Ashida，“载体级NAT（CGN）的通用要求”，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，“在共享地址部署中显示主机标识符（主机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]Peterson，A.和M.Nilsson，“转发HTTP扩展”，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，“轻量级4over6：双栈精简架构的扩展”，RFC 7596，DOI 10.17487/RFC75962015年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.，和T.Taylor，Ed.，“地址和端口的封装映射（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.
[无状态-NAT44]邹，T.，刘，W.，Perreault，S.，Penno，R.，和M.Chen，“无状态IPv4网络地址转换”，正在进行中的工作，草稿-Tsou-NSTABLE-NAT44-022012年10月。
[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，“政策和收费控制（PCC）；参考点（第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.克拉姆，D.温，D.冯雨果，G.李，D.刘和Y.李的评论。
J. Touch, S. Farrel, and S. Moonesamy provided useful comments in the intarea mailing list.
J.Touch、S.Farrel和S.Moonesamy在Intrea邮件列表中提供了有用的评论。
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
Email: mohamed.boucadair@orange.com
Bruno Chatras Orange Paris France
法国巴黎布鲁诺查特拉斯橙酒店
Email: bruno.chatras@orange.com
Email: bruno.chatras@orange.com
Tirumaleswar Reddy Cisco Systems Cessna Business Park, Varthur Hobli Sarjapur Marathalli Outer Ring Road Bangalore, Karnataka 560103 India
印度卡纳塔克邦班加罗尔外环路瓦图尔·霍布利·萨贾普尔·马拉塔利区蒂鲁马莱斯瓦尔·雷迪·思科系统塞斯纳商业园，邮编：560103
Email: tireddy@cisco.com
Email: tireddy@cisco.com
Brandon Williams Akamai, Inc. Cambridge MA United States
Brandon Williams Akamai，Inc.美国马萨诸塞州剑桥
Email: brandon.williams@akamai.com
Email: brandon.williams@akamai.com
Behcet Sarikaya Huawei 5340 Legacy Dr. Building 3, Plano, TX 75024 United States
Behcet Sarikaya华为5340 Legacy Dr.美国德克萨斯州普莱诺3号楼75024
Email: sarikaya@ieee.org
Email: sarikaya@ieee.org