Independent Submission C. Donley
Request for Comments: 7422 CableLabs
Category: Informational C. Grundemann
ISSN: 2070-1721 Internet Society
V. Sarawat
K. Sundaresan
CableLabs
O. Vautrin
Juniper Networks
December 2014
Independent Submission C. Donley
Request for Comments: 7422 CableLabs
Category: Informational C. Grundemann
ISSN: 2070-1721 Internet Society
V. Sarawat
K. Sundaresan
CableLabs
O. Vautrin
Juniper Networks
December 2014
Deterministic Address Mapping to Reduce Logging in Carrier-Grade NAT Deployments
确定性地址映射可减少运营商级NAT部署中的日志记录
Abstract
摘要
In some instances, Service Providers (SPs) have a legal logging requirement to be able to map a subscriber's inside address with the address used on the public Internet (e.g., for abuse response). Unfortunately, many logging solutions for Carrier-Grade NATs (CGNs) require active logging of dynamic translations. CGN port assignments are often per connection, but they could optionally use port ranges. Research indicates that per-connection logging is not scalable in many residential broadband services. This document suggests a way to manage CGN translations in such a way as to significantly reduce the amount of logging required while providing traceability for abuse response. IPv6 is, of course, the preferred solution. While deployment is in progress, SPs are forced by business imperatives to maintain support for IPv4. This note addresses the IPv4 part of the network when a CGN solution is in use.
在某些情况下，服务提供商（SP）有法律日志记录要求，以便能够将订户的内部地址与公共互联网上使用的地址进行映射（例如，用于滥用响应）。不幸的是，许多运营商级NAT（CGN）的日志记录解决方案需要动态转换的主动日志记录。CGN端口分配通常是针对每个连接的，但它们可以选择使用端口范围。研究表明，在许多住宅宽带服务中，每连接日志记录是不可伸缩的。本文件提出了一种管理CGN翻译的方法，以显著减少所需的日志记录量，同时提供滥用响应的可追溯性。当然，IPv6是首选解决方案。在部署过程中，业务需求迫使SP保持对IPv4的支持。本说明说明了使用CGN解决方案时网络的IPv4部分。
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/rfc7422.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7422.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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 ....................................................2
1.1. Requirements Language ......................................4
2. Deterministic Port Ranges .......................................4
2.1. IPv4 Port Utilization Efficiency ...........................7
2.2. Planning and Dimensioning ..................................7
2.3. Deterministic CGN Example ..................................8
3. Additional Logging Considerations ...............................9
3.1. Failover Considerations ...................................10
4. Impact on the IPv6 Transition ..................................10
5. Privacy Considerations .........................................11
6. Security Considerations ........................................11
7. References .....................................................11
7.1. Normative References ......................................11
7.2. Informative References ....................................12
Acknowledgements ..................................................13
Authors' Addresses ................................................14
1. Introduction ....................................................2
1.1. Requirements Language ......................................4
2. Deterministic Port Ranges .......................................4
2.1. IPv4 Port Utilization Efficiency ...........................7
2.2. Planning and Dimensioning ..................................7
2.3. Deterministic CGN Example ..................................8
3. Additional Logging Considerations ...............................9
3.1. Failover Considerations ...................................10
4. Impact on the IPv6 Transition ..................................10
5. Privacy Considerations .........................................11
6. Security Considerations ........................................11
7. References .....................................................11
7.1. Normative References ......................................11
7.2. Informative References ....................................12
Acknowledgements ..................................................13
Authors' Addresses ................................................14
It is becoming increasingly difficult to obtain new IPv4 address assignments from Regional/Local Internet Registries due to depleting supplies of unallocated IPv4 address space. To meet the growing demand for Internet connectivity from new subscribers, devices, and service types, some operators will be forced to share a single public IPv4 address among multiple subscribers using techniques such as Carrier-Grade NAT (CGN) [RFC6264] (e.g., NAT444 [NAT444], Dual-Stack Lite (DS-Lite) [RFC6333], NAT64 [RFC6146], etc.). However, address sharing poses additional challenges to operators when considering how they manage service entitlement, public safety requests, or attack/abuse/fraud reports [RFC6269]. In order to identify a specific user associated with an IP address in response to such a request or for service entitlement, an operator will need to map a subscriber's internal source IP address and source port with the
由于耗尽了未分配的IPv4地址空间，从区域/本地Internet注册中心获取新的IPv4地址分配变得越来越困难。为了满足新用户、设备和服务类型对互联网连接的日益增长的需求，一些运营商将被迫使用诸如载波级NAT（CGN）[RFC6264]（例如NAT444[NAT444]、双栈精简版（DS精简版）[RFC6333]、NAT64[RFC6146]等）等技术在多个用户之间共享一个公共IPv4地址。然而，在考虑如何管理服务授权、公共安全请求或攻击/滥用/欺诈报告时，地址共享给运营商带来了额外的挑战[RFC6269]。为了识别与IP地址相关联的特定用户以响应此类请求或服务授权，运营商需要将订户的内部源IP地址和源端口映射到
global public IP address and source port provided by the CGN for every connection initiated by the user.
CGN为用户发起的每个连接提供的全局公共IP地址和源端口。
CGN connection logging satisfies the need to identify attackers and respond to abuse/public safety requests, but it imposes significant operational challenges to operators. In lab testing, we have observed CGN log messages to be approximately 150 bytes long for NAT444 [NAT444] and 175 bytes for DS-Lite [RFC6333] (individual log messages vary somewhat in size). Although we are not aware of definitive studies of connection rates per subscriber, reports from several operators in the US sets the average number of connections per household at approximately 33,000 connections per day. If each connection is individually logged, this translates to a data volume of approximately 5 MB per subscriber per day, or about 150 MB per subscriber per month; however, specific data volumes may vary across different operators based on myriad factors. Based on available data, a 1-million-subscriber SP will generate approximately 150 terabytes of log data per month, or 1.8 petabytes per year. Note that many SPs compress log data after collection; compression factors of 2:1 or 3:1 are common.
CGN连接日志记录满足了识别攻击者和响应滥用/公共安全请求的需要，但它给操作员带来了重大的操作挑战。在实验室测试中，我们观察到，对于NAT444[NAT444]而言，CGN日志消息的长度约为150字节，对于DS Lite[RFC6333]而言，CGN日志消息的长度约为175字节（单个日志消息的大小有所不同）。尽管我们不知道对每个用户的连接率进行了明确的研究，但美国几家运营商的报告将每户的平均连接数设定为每天大约33000个连接。如果每个连接都是单独记录的，这将转换为每个订户每天大约5 MB的数据量，或者每个订户每月大约150 MB的数据量；但是，基于各种因素，不同运营商的特定数据量可能会有所不同。根据可用数据，100万用户SP每月将生成约150 TB的日志数据，即每年1.8 PB。请注意，许多SP在收集日志数据后压缩日志数据；压缩系数通常为2:1或3:1。
The volume of log data poses a problem for both operators and the public safety community. On the operator side, it requires a significant infrastructure investment by operators implementing CGN. It also requires updated operational practices to maintain the logging infrastructure, and requires approximately 23 Mbps of bandwidth between the CGN devices and the logging infrastructure per 50,000 users. On the public safety side, it increases the time required for an operator to search the logs in response to an abuse report, and it could delay investigations. Accordingly, an international group of operators and public safety officials approached the authors to identify a way to reduce this impact while improving abuse response.
日志数据量给操作员和公共安全社区带来了问题。在运营商方面，实施CGN的运营商需要大量的基础设施投资。它还需要更新操作实践来维护日志记录基础设施，并且每50000个用户需要CGN设备和日志记录基础设施之间约23 Mbps的带宽。在公共安全方面，这增加了运营商在收到滥用报告后搜索日志所需的时间，并可能推迟调查。因此，一个由运营商和公共安全官员组成的国际小组与提交人进行了接触，以确定一种在改善虐待反应的同时减少这种影响的方法。
The volume of CGN logging can be reduced by assigning port ranges instead of individual ports. Using this method, only the assignment of a new port range is logged. This may massively reduce logging volume. The log reduction may vary depending on the length of the assigned port range, whether the port range is static or dynamic, etc. This has been acknowledged in [RFC6269], which recommends the logging of source ports at the server and/or destination logging at the CGN, and [NAT-LOGGING], which describes information to be logged at a NAT.
通过分配端口范围而不是单个端口，可以减少CGN日志记录的数量。使用此方法，仅记录新端口范围的分配。这可能会大大减少日志记录量。日志减少可能因分配的端口范围的长度、端口范围是静态的还是动态的等而有所不同。这已在[RFC6269]中得到确认，它建议在服务器上记录源端口和/或在CGN上记录目标日志，以及[NAT-logging]，它描述了要在NAT上记录的信息。
However, the existing solutions still pose an impact on operators and public safety officials for logging and searching. Instead, CGNs could be designed and/or configured to deterministically map internal addresses to {external address + port range} in such a way as to be
然而，现有的解决方案仍然对操作员和公共安全官员的伐木和搜索造成影响。相反，CGN可以设计和/或配置为以如下方式确定地将内部地址映射到{外部地址+端口范围}
able to algorithmically calculate the mapping. Only inputs and configuration of the algorithm need to be logged. This approach reduces both logging volume and subscriber identification times. In some cases, when full deterministic allocation is used, this approach can eliminate the need for translation logging.
能够通过算法计算映射。只需记录算法的输入和配置。这种方法减少了日志记录量和订户识别时间。在某些情况下，当使用完全确定性分配时，这种方法可以消除转换日志的需要。
This document describes a method for such CGN address mapping, combined with block port reservations, that significantly reduces the burden on operators while offering the ability to map a subscriber's inside IP address with an outside address and external port number observed on the Internet.
本文档描述了一种用于此类CGN地址映射的方法，结合块端口保留，该方法显著降低了运营商的负担，同时提供了将用户的内部IP地址映射到Internet上观察到的外部地址和外部端口号的能力。
The activation of the proposed port range allocation scheme is compliant with BEHAVE requirements such as the support of Application-specific functions (APP).
建议的端口范围分配方案的激活符合行为要求，例如支持特定于应用程序的功能（APP）。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
While a subscriber uses thousands of connections per day, most subscribers use far fewer resources at any given time. When the compression ratio (see Appendix B of RFC 6269 [RFC6269]) is low (e.g., the ratio of the number of subscribers to the number of public IPv4 addresses allocated to a CGN is closer to 10:1 than 1000:1), each subscriber could expect to have access to thousands of TCP/UDP ports at any given time. Thus, as an alternative to logging each connection, CGNs could deterministically map customer private addresses (received on the customer-facing interface of the CGN, a.k.a., internal side) to public addresses extended with port ranges (used on the Internet-facing interface of the CGN, a.k.a., external side). This algorithm allows an operator to identify a subscriber internal IP address when provided the public side IP and port number without having to examine the CGN translation logs. This prevents an operator from having to transport and store massive amounts of session data from the CGN and then process it to identify a subscriber.
虽然订阅者每天使用数千个连接，但大多数订阅者在任何给定时间使用的资源要少得多。当压缩比（参见RFC 6269[RFC6269]的附录B）较低时（例如，订户数量与分配给CGN的公共IPv4地址数量的比率接近10:1而不是1000:1），每个订户在任何给定时间都可以访问数千个TCP/UDP端口。因此，作为记录每个连接的替代方案，CGN可以确定地将客户专用地址（在CGN内部面向客户的接口上接收）映射到扩展端口范围的公共地址（在CGN外部面向Internet的接口上使用）。该算法允许操作员在提供公共端IP和端口号时识别订户内部IP地址，而无需检查CGN转换日志。这避免了运营商必须传输和存储来自CGN的大量会话数据，然后对其进行处理以识别订户。
The algorithmic mapping can be expressed as:
算法映射可以表示为：
(External IP Address, Port Range) = function 1 (Internal IP Address)
（外部IP地址，端口范围）=功能1（内部IP地址）
Internal IP Address = function 2 (External IP Address, Port Number)
内部IP地址=功能2（外部IP地址、端口号）
The CGN SHOULD provide a method for administrators to test both mapping functions (e.g., enter an External IP Address + Port Number and receive the corresponding Internal IP Address).
CGN应为管理员提供一种测试两种映射功能的方法（例如，输入外部IP地址+端口号并接收相应的内部IP地址）。
Deterministic Port Range allocation requires configuration of the following variables:
确定性端口范围分配需要配置以下变量：
o Inside IPv4/IPv6 address range (I);
o IPv4/IPv6地址范围内（I）；
o Outside IPv4 address range (O);
o IPv4地址范围之外（O）；
o Compression ratio (e.g., inside IP addresses I / outside IP addresses O) (C);
o 压缩比（例如，内部IP地址I/外部IP地址O）（C）；
o Dynamic address pool factor (D), to be added to the compression ratio in order to create an overflow address pool;
o 动态地址池系数（D），添加到压缩比中，以创建溢出地址池；
o Maximum ports per user (M);
o 每个用户的最大端口数（M）；
o Address assignment algorithm (A) (see below); and
o 地址分配算法（A）（见下文）；和
o Reserved TCP/UDP port list (R)
o 保留TCP/UDP端口列表（R）
Note: The inside address range (I) will be an IPv4 range in NAT444 operation (NAT444 [NAT444]) and an IPv6 range in DS-Lite operation (DS-Lite [RFC6333]).
注意：内部地址范围（I）将是NAT444操作中的IPv4范围（NAT444[NAT444]）和DS Lite操作中的IPv6范围（DS Lite[RFC6333]）。
A subscriber is identified by an internal IPv4 address (e.g., NAT44) or an IPv6 prefix (e.g., DS-Lite or NAT64).
订户由内部IPv4地址（如NAT44）或IPv6前缀（如DS Lite或NAT64）标识。
The algorithm may be generalized to L2-aware NAT [L2NAT], but this requires the configuration of the Internal interface identifiers (e.g., Media Access Control (MAC) addresses).
该算法可以推广到L2感知NAT[L2NAT]，但这需要配置内部接口标识符（例如，媒体访问控制（MAC）地址）。
The algorithm is not designed to retrieve an internal host among those sharing the same internal IP address (e.g., in a DS-Lite context, only an IPv6 address/prefix can be retrieved using the algorithm while the internal IPv4 address used for the encapsulated IPv4 datagram is lost).
该算法不用于检索共享相同内部IP地址的主机之间的内部主机（例如，在DS Lite上下文中，当用于封装IPv4数据报的内部IPv4地址丢失时，使用该算法只能检索IPv6地址/前缀）。
Several address-assignment algorithms are possible. Using predefined algorithms, such as those that follow, simplifies the process of reversing the algorithm when needed. However, the CGN MAY support additional algorithms. Also, the CGN is not required to support all of the algorithms described below. Subscribers could be restricted
有几种地址分配算法是可能的。使用预定义的算法（如下面的算法）可以简化在需要时反转算法的过程。然而，CGN可以支持额外的算法。此外，CGN不需要支持下面描述的所有算法。订户可能会受到限制
to ports from a single IPv4 address or could be allocated ports across all addresses in a pool, for example. The following algorithms and corresponding values of A are as follows:
例如，从单个IPv4地址分配到端口，或者可以跨池中的所有地址分配端口。A的以下算法和相应值如下：
0: Sequential (e.g., the first block goes to address 1, the second block to address 2, etc.).
0：顺序（例如，第一个块转到地址1，第二个块转到地址2，等等）。
1: Staggered (e.g., for every n between 0 and ((65536-R)/(C+D))-1 , address 1 receives ports n*C+R, address 2 receives ports (1+n)*C+R, etc.).
1：交错（例如，对于0和（（65536-R）/（C+D））之间的每n个端口-1，地址1接收端口n*C+R，地址2接收端口（1+n）*C+R，等等）。
2: Round robin (e.g., the subscriber receives the same port number across a pool of external IP addresses. If the subscriber is to be assigned more ports than there are in the external IP pool, the subscriber receives the next highest port across the IP pool, and so on. Thus, if there are 10 IP addresses in a pool and a subscriber is assigned 1000 ports, the subscriber would receive a range such as ports 2000-2099 across all 10 external IP addresses).
2：循环赛（例如，订户在一个外部IP地址池中接收相同的端口号。如果要为订户分配的端口数超过外部IP池中的端口数，则订户将在整个IP池中接收下一个最高的端口数，依此类推。因此，如果一个池中有10个IP地址，并且为订户分配了1000个端口，则子端口数将增加scriber将在所有10个外部IP地址上接收端口2000-2099等范围。
3: Interlaced horizontally (e.g., each address receives every Cth port spread across a pool of external IP addresses).
3：水平交错（例如，每个地址接收分布在外部IP地址池中的每个Cth端口）。
4: Cryptographically random port assignment (Section 2.2 of RFC6431 [RFC6431]). If this algorithm is used, the SP needs to retain the keying material and specific cryptographic function to support reversibility.
4：加密随机端口分配（RFC6431[RFC6431]第2.2节）。如果使用此算法，SP需要保留键控材料和特定加密功能以支持可逆性。
5: Vendor-specific. Other vendor-specific algorithms may also be supported.
5：特定于供应商。也可支持其他特定于供应商的算法。
The assigned range of ports MAY also be used when translating ICMP requests (when rewriting the Identifier field).
在转换ICMP请求时（重写标识符字段时），也可以使用分配的端口范围。
The CGN then reserves ports as follows:
然后，CGN保留如下端口：
1. The CGN removes reserved ports (R) from the port candidate list (e.g., 0-1023 for TCP and UDP). At a minimum, the CGN SHOULD remove system ports [RFC6335] from the port candidate list reserved for deterministic assignment.
1. CGN从端口候选列表中删除保留端口（R）（例如，TCP和UDP为0-1023）。CGN至少应从为确定性分配保留的端口候选列表中删除系统端口[RFC6335]。
2. The CGN calculates the total compression ratio (C+D), and allocates 1/(C+D) of the available ports to each internal IP address. Specific port allocation is determined by the algorithm (A) configured on the CGN. Any remaining ports are allocated to the dynamic pool.
2. CGN计算总压缩比（C+D），并将1/（C+D）的可用端口分配给每个内部IP地址。具体端口分配由CGN上配置的算法（A）确定。所有剩余端口都分配给动态池。
Note: Setting D to 0 disables the dynamic pool. This option eliminates the need for per-subscriber logging at the expense of limiting the number of concurrent connections that 'power users' can initiate.
注意：将D设置为0将禁用动态池。此选项消除了对每个订户的日志记录的需要，但代价是限制“超级用户”可以启动的并发连接数。
3. When a subscriber initiates a connection, the CGN creates a translation mapping between the subscriber's inside local IP address/port and the CGN outside global IP address/port. The CGN MUST use one of the ports allocated in step 2 for the translation as long as such ports are available. The CGN SHOULD allocate ports randomly within the port range assigned by the deterministic algorithm. This is to increase subscriber privacy. The CGN MUST use the pre-allocated port range from step 2 for Port Control Protocol (PCP, [RFC6887]) reservations as long as such ports are available. While the CGN maintains its mapping table, it need not generate a log entry for translation mappings created in this step.
3. 当订阅者发起连接时，CGN在订阅者的内部本地IP地址/端口和CGN外部全局IP地址/端口之间创建转换映射。CGN必须使用步骤2中分配的一个端口进行转换，只要这些端口可用。CGN应在确定性算法分配的端口范围内随机分配端口。这是为了增加用户隐私。CGN必须使用步骤2中为端口控制协议（PCP，[RFC6887]）预留的预分配端口范围，只要这些端口可用。虽然CGN维护其映射表，但它不需要为此步骤中创建的转换映射生成日志条目。
4. If D>0, the CGN will have a pool of ports left for dynamic assignment. If a subscriber uses more than the range of ports allocated in step 2 (but fewer than the configured maximum ports M), the CGN assigns a block of ports from the dynamic assignment range for such a connection or for PCP reservations. The CGN MUST log dynamically assigned port blocks to facilitate subscriber-to-address mapping. The CGN SHOULD manage dynamic ports as described in [LOG-REDUCTION].
4. 如果D>0，CGN将有一个端口池，用于动态分配。如果订户使用的端口超过步骤2中分配的端口范围（但小于配置的最大端口M），则CGN将从动态分配范围中为此类连接或PCP保留分配一个端口块。CGN必须记录动态分配的端口块，以便于订户到地址的映射。CGN应按照[LOG-REDUCTION]中所述管理动态端口。
5. Configuration of reserved ports (e.g., system ports) is left to operator configuration.
5. 保留端口（如系统端口）的配置由操作员配置。
Thus, the CGN will maintain translation mapping information for all connections within its internal translation tables; however, it only needs to externally log translations for dynamically assigned ports.
因此，CGN将维护其内部翻译表中所有连接的翻译映射信息；但是，它只需要在外部记录动态分配端口的转换。
For SPs requiring an aggressive address-sharing ratio, the use of the algorithmic mapping may impact the efficiency of the address sharing. A dynamic port range allocation assignment is more suitable in those cases.
对于要求高地址共享率的SP，使用算法映射可能会影响地址共享的效率。在这些情况下，动态端口范围分配更合适。
Unlike dynamic approaches, the use of the algorithmic mapping requires more effort from operational teams to tweak the algorithm (e.g., size of the port range, address sharing ratio, etc.). Dedicated alarms SHOULD be configured when some port utilization thresholds are fired so that the configuration can be refined.
与动态方法不同，使用算法映射需要运营团队做出更多努力来调整算法（例如，端口范围的大小、地址共享率等）。当触发某些端口利用率阈值时，应配置专用警报，以便优化配置。
The use of algorithmic mapping also affects geolocation. Changes to the inside and outside address ranges (e.g., due to growth, address allocation planning, etc.) would require external geolocation providers to recalibrate their mappings.
算法映射的使用也会影响地理位置。对内部和外部地址范围的更改（例如，由于增长、地址分配规划等原因）将需要外部地理定位提供商重新校准其映射。
To illustrate the use of deterministic NAT, let's consider a simple example. The operator configures an inside address range (I) of 198.51.100.0/28 [RFC6598] and outside address (O) of 192.0.2.1. The dynamic address pool factor (D) is set to '2'. Thus, the total compression ratio is 1:(14+2) = 1:16. Only the system ports (e.g., ports < 1024) are reserved (R). This configuration causes the CGN to pre-allocate ((65536-1024)/16 =) 4032 TCP and 4032 UDP ports per inside IPv4 address. For the purposes of this example, let's assume that they are allocated sequentially, where 198.51.100.1 maps to 192.0.2.1 ports 1024-5055, 198.51.100.2 maps to 192.0.2.1 ports 5056-9087, etc. The dynamic port range thus contains ports 57472-65535 (port allocation illustrated in the table below). Finally, the maximum ports/subscriber is set to 5040.
为了说明确定性NAT的使用，让我们考虑一个简单的例子。操作员将内部地址范围（I）配置为198.51.100.0/28[RFC6598]，外部地址（O）配置为192.0.2.1。动态地址池系数（D）设置为“2”。因此，总压缩比为1：（14+2）=1:16。仅保留系统端口（例如<1024个端口）（R）。此配置导致CGN为每个内部IPv4地址预分配（（65536-1024）/16=）4032 TCP和4032 UDP端口。在本例中，假设它们是按顺序分配的，其中198.51.100.1映射到192.0.2.1端口1024-5055，198.51.100.2映射到192.0.2.1端口5056-9087，等等。因此，动态端口范围包含端口57472-65535（下表中说明了端口分配）。最后，最大端口/订户设置为5040。
+-----------------------+------------------------+
| Inside Address / Pool | Outside Address & Port |
+-----------------------+------------------------+
| Reserved | 192.0.2.1:0-1023 |
| 198.51.100.1 | 192.0.2.1:1024-5055 |
| 198.51.100.2 | 192.0.2.1:5056-9087 |
| 198.51.100.3 | 192.0.2.1:9088-13119 |
| 198.51.100.4 | 192.0.2.1:13120-17151 |
| 198.51.100.5 | 192.0.2.1:17152-21183 |
| 198.51.100.6 | 192.0.2.1:21184-25215 |
| 198.51.100.7 | 192.0.2.1:25216-29247 |
| 198.51.100.8 | 192.0.2.1:29248-33279 |
| 198.51.100.9 | 192.0.2.1:33280-37311 |
| 198.51.100.10 | 192.0.2.1:37312-41343 |
| 198.51.100.11 | 192.0.2.1:41344-45375 |
| 198.51.100.12 | 192.0.2.1:45376-49407 |
| 198.51.100.13 | 192.0.2.1:49408-53439 |
| 198.51.100.14 | 192.0.2.1:53440-57471 |
| Dynamic | 192.0.2.1:57472-65535 |
+-----------------------+------------------------+
+-----------------------+------------------------+
| Inside Address / Pool | Outside Address & Port |
+-----------------------+------------------------+
| Reserved | 192.0.2.1:0-1023 |
| 198.51.100.1 | 192.0.2.1:1024-5055 |
| 198.51.100.2 | 192.0.2.1:5056-9087 |
| 198.51.100.3 | 192.0.2.1:9088-13119 |
| 198.51.100.4 | 192.0.2.1:13120-17151 |
| 198.51.100.5 | 192.0.2.1:17152-21183 |
| 198.51.100.6 | 192.0.2.1:21184-25215 |
| 198.51.100.7 | 192.0.2.1:25216-29247 |
| 198.51.100.8 | 192.0.2.1:29248-33279 |
| 198.51.100.9 | 192.0.2.1:33280-37311 |
| 198.51.100.10 | 192.0.2.1:37312-41343 |
| 198.51.100.11 | 192.0.2.1:41344-45375 |
| 198.51.100.12 | 192.0.2.1:45376-49407 |
| 198.51.100.13 | 192.0.2.1:49408-53439 |
| 198.51.100.14 | 192.0.2.1:53440-57471 |
| Dynamic | 192.0.2.1:57472-65535 |
+-----------------------+------------------------+
When subscriber 1 using 198.51.100.1 initiates a low volume of connections (e.g., < 4032 concurrent connections), the CGN maps the outgoing source address/port to the pre-allocated range. These translation mappings are not logged.
当使用198.51.100.1的订户1启动少量连接（例如，<4032并发连接）时，CGN将传出源地址/端口映射到预先分配的范围。未记录这些转换映射。
Subscriber 2 concurrently uses more than the allocated 4032 ports (e.g., for peer-to-peer, mapping, video streaming, or other connection-intensive traffic types), the CGN allocates up to an additional 1008 ports using bulk port reservations. In this example, subscriber 2 uses outside ports 5056-9087, and then 100-port blocks between 58000-58999. Connections using ports 5056-9087 are not logged, while 10 log entries are created for ports 58000-58099, 58100-58199, 58200-58299, ..., 58900-58999.
订户2同时使用超过分配的4032端口（例如，对于对等、映射、视频流或其他连接密集型流量类型），CGN使用批量端口预留分配最多1008个端口。在此示例中，订户2使用外部端口5056-9087，然后使用58000-58999之间的100个端口块。不记录使用端口5056-9087的连接，同时为端口58000-58099、58100-58199、58200-58299、…、58900-58999创建10个日志条目。
In order to identify a subscriber behind a CGN (regardless of port allocation method), public safety agencies need to collect source address and port information from content provider log files. Thus, content providers are advised to log source address, source port, and timestamp for all log entries, per [RFC6302]. If a public safety agency collects such information from a content provider and reports abuse from 192.0.2.1, port 2001, the operator can reverse the mapping algorithm to determine that the internal IP address subscriber 1 has been assigned generated the traffic without consulting CGN logs (by correlating the internal IP address with DHCP/PPP lease connection records). If a second abuse report comes in for 192.0.2.1, port 58204, the operator will determine that port 58204 is within the dynamic pool range, consult the log file, correlate with connection records, and determine that subscriber 2 generated the traffic (assuming that the public safety timestamp matches the operator timestamp. As noted in RFC 6292 [RFC6292], accurate timekeeping (e.g., use of NTP or Simple NTP) is vital).
为了识别CGN背后的订户（无论端口分配方法如何），公共安全机构需要从内容提供商日志文件中收集源地址和端口信息。因此，建议内容提供商根据[RFC6302]记录所有日志条目的源地址、源端口和时间戳。如果公共安全机构从内容提供商处收集此类信息，并从端口2001的192.0.2.1报告滥用情况，则运营商可以反转映射算法，以确定内部IP地址订户1已被分配生成流量，而无需咨询CGN日志（通过将内部IP地址与DHCP/PPP租约连接记录关联）。如果192.0.2.1端口58204出现第二次滥用报告，操作员将确定端口58204在动态池范围内，查阅日志文件，与连接记录关联，并确定订户2生成了流量（假设公共安全时间戳与操作员时间戳匹配。如RFC 6292[RFC6292]中所述，准确的计时（例如，使用NTP或简单NTP）至关重要）。
In this example, there are no log entries for the majority of subscribers, who only use pre-allocated ports. Only minimal logging would be needed for those few subscribers who exceed their pre-allocated ports and obtain extra bulk port assignments from the dynamic pool. Logging data for those users will include inside address, outside address, outside port range, and timestamp.
在本例中，大多数订阅者没有日志条目，他们只使用预先分配的端口。对于超出预分配端口并从动态池获得额外大容量端口分配的少数订阅者，只需要最少的日志记录。这些用户的日志数据将包括内部地址、外部地址、外部端口范围和时间戳。
Note that in a production environment, operators are encouraged to consider [RFC6598] for assigning inside addresses.
注意，在生产环境中，鼓励操作员考虑[rfc698]分配内部地址。
In order to be able to identify a subscriber based on observed external IPv4 address, port, and timestamp, an operator needs to know how the CGN was configured with regard to internal and external IP addresses, dynamic address pool factor, maximum ports per user, and reserved port range at any given time. Therefore, the CGN MUST generate a record any time such variables are changed. The CGN SHOULD generate a log message any time such variables are changed. The CGN MAY keep such a record in the form of a router configuration file. If the CGN does not generate a log message, it would be up to
为了能够根据观察到的外部IPv4地址、端口和时间戳识别订户，运营商需要知道CGN在任何给定时间是如何配置的，包括内部和外部IP地址、动态地址池系数、每个用户的最大端口数和保留端口范围。因此，CGN必须在更改此类变量时生成记录。CGN应在任何时候更改此类变量时生成日志消息。CGN可以以路由器配置文件的形式保持这样的记录。如果CGN不生成日志消息，则由
the operator to maintain version control of router config changes. Also, the CGN SHOULD generate such a log message once per day to facilitate quick identification of the relevant configuration in the event of an abuse notification.
操作员负责维护路由器配置更改的版本控制。此外，CGN应每天生成一次这样的日志消息，以便于在发生滥用通知时快速识别相关配置。
Such a log message MUST, at minimum, include the timestamp, inside prefix I, inside mask, outside prefix O, outside mask, D, M, A, and reserved port list R; for example:
这样的日志消息必须至少包括时间戳、内部前缀I、内部掩码、外部前缀O、外部掩码、D、M、a和保留端口列表R；例如：
[Wed Oct 11 14:32:52 2000]:198.51.100.0:28:192.0.2.0:32:2:5040:0:1-1023,5004,5060.
[2000年10月11日星期三14:32:52]：198.51.100.0:28:192.0.2.0:32:2:5040:0:1-102350045060。
Due to the deterministic nature of algorithmically assigned translations, no additional logging is required during failover conditions provided that inside address ranges are unique within a given failover domain. Even when directed to a different CGN server, translations within the deterministic port range on either the primary or secondary server can be algorithmically reversed, provided the algorithm is known. Thus, if 198.51.100.1 port 3456 maps to 192.0.2.1 port 1000 on CGN 1 and 198.51.100.1 port 1000 on Failover CGN 2, an operator can identify the subscriber based on outside source address and port information.
由于算法分配的转换具有确定性，如果内部地址范围在给定的故障转移域中是唯一的，则在故障转移条件下不需要额外的日志记录。即使定向到不同的CGN服务器，只要算法已知，主服务器或辅助服务器上确定性端口范围内的转换也可以在算法上反转。因此，如果198.51.100.1端口3456映射到CGN 1上的192.0.2.1端口1000和故障转移CGN 2上的198.51.100.1端口1000，则操作员可以基于外部源地址和端口信息识别订户。
Similarly, assignments made from the dynamic overflow pool need to be logged as described above, whether translations are performed on the primary or failover CGN.
类似地，无论是在主CGN还是故障转移CGN上执行转换，都需要如上所述记录从动态溢出池进行的分配。
The solution described in this document is applicable to CGN transition technologies (e.g., NAT444, DS-Lite, and NAT64). As discussed in [RFC7021], the authors acknowledge that native IPv6 will offer subscribers a better experience than CGN. However, many Customer Premises Equipment (CPE) devices only support IPv4. Likewise, as of October 2014, only approximately 5.2% of the top 1 million websites were available using IPv6. Accordingly, Deterministic CGN should in no way be understood as making CGN a replacement for IPv6 service; however, until such time as IPv6 content and devices are widely available, Deterministic CGN will provide operators with the ability to quickly respond to public safety requests without requiring excessive infrastructure, operations, and bandwidth to support per-connection logging.
本文档中描述的解决方案适用于CGN转换技术（例如NAT444、DS Lite和NAT64）。正如[RFC7021]中所讨论的，作者承认本机IPv6将为用户提供比CGN更好的体验。然而，许多客户场所设备（CPE）设备仅支持IPv4。类似地，截至2014年10月，排名前100万的网站中只有约5.2%使用IPv6。因此，确定性CGN决不应被理解为使CGN取代IPv6服务；然而，在IPv6内容和设备广泛可用之前，确定性CGN将为运营商提供快速响应公共安全请求的能力，而无需过多的基础设施、操作和带宽来支持每次连接日志记录。
The algorithm described above makes it easier for SPs and public safety officials to identify the IP address of a subscriber through a CGN system. This is the equivalent level of privacy users could expect when they are assigned a public IP address and their traffic is not translated. However, this algorithm could be used by other actors on the Internet to map multiple transactions to a single subscriber, particularly if ports are distributed sequentially. While still preserving traceability, subscriber privacy can be increased by using one of the other values of the Address Assignment Algorithm (A), which would require interested parties to know more about the Service Provider's CGN configuration to be able to tie multiple connections to a particular subscriber.
上述算法使SPs和公共安全官员更容易通过CGN系统识别用户的IP地址。当用户被分配一个公共IP地址并且他们的流量没有被转换时，这是用户可以期望的同等隐私级别。但是，Internet上的其他参与者可以使用此算法将多个事务映射到单个订户，特别是在端口按顺序分布的情况下。在仍然保持可追溯性的同时，可以通过使用地址分配算法（A）的其他值之一来增加订户隐私，这将要求相关方更多地了解服务提供商的CGN配置，以便能够将多个连接绑定到特定订户。
The security considerations applicable to NAT operation for various protocols as documented in, for example, RFC 4787 [RFC4787] and RFC 5382 [RFC5382] also apply to this document.
如RFC 4787[RFC4787]和RFC 5382[RFC5382]中所述，适用于各种协议NAT操作的安全注意事项也适用于本文件。
Note that, with the possible exception of cryptographically based port allocations, attackers could reverse-engineer algorithmically derived port allocations to either target a specific subscriber or to spoof traffic to make it appear to have been generated by a specific subscriber. However, this is exactly the same level of security that the subscriber would experience in the absence of CGN. CGN is not intended to provide additional security by obscurity.
请注意，除了基于密码的端口分配之外，攻击者可以反向工程算法派生的端口分配，以特定订户为目标或欺骗流量，使其看起来是由特定订户生成的。然而，这与用户在没有CGN的情况下所体验到的安全级别完全相同。CGN不打算通过模糊性提供额外的安全性。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007, <http://www.rfc-editor.org/info/rfc4787>.
[RFC4787]Audet，F.和C.Jennings，“单播UDP的网络地址转换（NAT）行为要求”，BCP 127，RFC 4787，2007年1月<http://www.rfc-editor.org/info/rfc4787>.
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008, <http://www.rfc-editor.org/info/rfc5382>.
[RFC5382]Guha，S.，Biswas，K.，Ford，B.，Sivakumar，S.，和P.Srisuresh，“TCP的NAT行为要求”，BCP 142，RFC 5382，2008年10月<http://www.rfc-editor.org/info/rfc5382>.
[RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264, June 2011, <http://www.rfc-editor.org/info/rfc6264>.
[RFC6264]Jiang，S.，Guo，D.，和B.Carpenter，“用于IPv6过渡的增量载波级NAT（CGN）”，RFC 62642011年6月<http://www.rfc-editor.org/info/rfc6264>.
[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, June 2011, <http://www.rfc-editor.org/info/rfc6269>.
[RFC6269]福特，M.，布卡达尔，M.，杜兰德，A.，利维斯，P.，和P.罗伯茨，“IP地址共享问题”，RFC 6269，2011年6月<http://www.rfc-editor.org/info/rfc6269>.
[L2NAT] Miles, D. and M. Townsley, "Layer2-Aware NAT", Work in Progress, draft-miles-behave-l2nat-00, March 2009.
[L2NAT]Miles，D.和M.Townsley，“第二层感知NAT”，正在进行的工作，草稿-Miles-behave-L2NAT-00，2009年3月。
[LOG-REDUCTION] Tsou, T., Li, W., Taylor, T., and J. Huang, "Port Management To Reduce Logging In Large-Scale NATs", Work in Progress, draft-tsou-behave-natx4-log-reduction-04, July 2013.
[LOG-REDUCTION]邹，T.，李，W.，泰勒，T.，和J.黄，“港口管理减少大规模NAT中的日志记录”，正在进行的工作，草稿-Tsou-behave-natx4-LOG-REDUCTION-042013年7月。
[NAT-LOGGING] Sivakumar, S. and R. Penno, "IPFIX Information Elements for logging NAT Events", Work in Progress, draft-ietf-behave-ipfix-nat-logging-04, July 2014.
[NAT-LOGGING]Sivakumar，S.和R.Penno，“用于记录NAT事件的IPFIX信息元素”，正在进行的工作，草稿-ietf-behave-IPFIX-NAT-LOGGING-042014年7月。
[NAT444] Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J., and H. Ashida, "NAT444", Work in Progress, draft-shirasaki-nat444-06, July 2012.
[NAT444]山形，I.，白崎，Y.，中川，A.，山口，J.，和H.Ashida，“NAT444”，正在进行的工作，草稿-Shirasaki-NAT444-062012年7月。
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011, <http://www.rfc-editor.org/info/rfc6146>.
[RFC6146]Bagnulo，M.，Matthews，P.，和I.van Beijnum，“有状态NAT64：从IPv6客户端到IPv4服务器的网络地址和协议转换”，RFC 61462011年4月<http://www.rfc-editor.org/info/rfc6146>.
[RFC6292] Hoffman, P., "Requirements for a Working Group Charter Tool", RFC 6292, June 2011, <http://www.rfc-editor.org/info/rfc6292>.
[RFC6292]Hoffman，P.“工作组章程工具的要求”，RFC 62922011年6月<http://www.rfc-editor.org/info/rfc6292>.
[RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, "Logging Recommendations for Internet-Facing Servers", BCP 162, RFC 6302, June 2011, <http://www.rfc-editor.org/info/rfc6302>.
[RFC6302]Durand，A.，Gashinsky，I.，Lee，D.，和S.Sheppard，“面向互联网服务器的日志记录建议”，BCP 162，RFC 6302，2011年6月<http://www.rfc-editor.org/info/rfc6302>.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011, <http://www.rfc-editor.org/info/rfc6333>.
[RFC6333]Durand，A.，Droms，R.，Woodyatt，J.，和Y.Lee，“IPv4耗尽后的双栈Lite宽带部署”，RFC 63332011年8月<http://www.rfc-editor.org/info/rfc6333>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, August 2011, <http://www.rfc-editor.org/info/rfc6335>.
[RFC6335]Cotton，M.，Eggert，L.，Touch，J.，Westerlund，M.，和S.Cheshire，“互联网分配号码管理局（IANA）服务名称和传输协议端口号注册管理程序”，BCP 165，RFC 63352011年8月<http://www.rfc-editor.org/info/rfc6335>.
[RFC6431] Boucadair, M., Levis, P., Bajko, G., Savolainen, T., and T. Tsou, "Huawei Port Range Configuration Options for PPP IP Control Protocol (IPCP)", RFC 6431, November 2011, <http://www.rfc-editor.org/info/rfc6431>.
[RFC6431]Boucadair，M.，Levis，P.，Bajko，G.，Savolainen，T.，和T.Tsou，“华为PPP IP控制协议（IPCP）的端口范围配置选项”，RFC 64312011年11月<http://www.rfc-editor.org/info/rfc6431>.
[RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address Space", BCP 153, RFC 6598, April 2012, <http://www.rfc-editor.org/info/rfc6598>.
[RFC6598]Weil，J.，Kuarsingh，V.，Donley，C.，Liljenstolpe，C.，和M.Azinger，“IANA为共享地址空间保留IPv4前缀”，BCP 153，RFC 6598，2012年4月<http://www.rfc-editor.org/info/rfc6598>.
[RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 2013, <http://www.rfc-editor.org/info/rfc6887>.
[RFC6887]南柴郡Wing，D.，布卡达尔，M.，佩诺，R.，和P.Selkirk，“港口控制协议（PCP）”，RFC 6887，2013年4月<http://www.rfc-editor.org/info/rfc6887>.
[RFC7021] Donley, C., Howard, L., Kuarsingh, V., Berg, J., and J. Doshi, "Assessing the Impact of Carrier-Grade NAT on Network Applications", RFC 7021, September 2013, <http://www.rfc-editor.org/info/rfc7021>.
[RFC7021]Donley，C.，Howard，L.，Kuarsingh，V.，Berg，J.，和J.Doshi，“评估运营商级NAT对网络应用的影响”，RFC 7021，2013年9月<http://www.rfc-editor.org/info/rfc7021>.
Acknowledgements
致谢
The authors would like to thank the following people for their suggestions and feedback: Bobby Flaim, Lee Howard, Wes George, Jean-Francois Tremblay, Mohammed Boucadair, Alain Durand, David Miles, Andy Anchev, Victor Kuarsingh, Miguel Cros Cecilia, Fred Baker, Brian Carpenter, and Reinaldo Penno.
作者感谢以下人士的建议和反馈：鲍比·弗莱姆、李·霍华德、韦斯·乔治、让·弗朗索瓦·特雷姆布雷、穆罕默德·布卡代尔、阿兰·杜兰德、大卫·迈尔斯、安迪·安切夫、维克多·夸辛格、米格尔·克罗斯·塞西莉亚、弗雷德·贝克、布赖恩·卡彭特和雷纳尔多·佩诺。
Authors' Addresses
作者地址
Chris Donley CableLabs 858 Coal Creek Cir Louisville, CO 80027 United States
Chris Donley CableLabs 858煤矿溪Cir Louisville，科罗拉多州，美国，80027
EMail: c.donley@cablelabs.com
EMail: c.donley@cablelabs.com
Chris Grundemann Internet Society Denver, CO United States
美国丹佛克里斯·格伦德曼互联网协会
EMail: cgrundemann@gmail.com
EMail: cgrundemann@gmail.com
Vikas Sarawat CableLabs 858 Coal Creek Cir Louisville, CO 80027 United States
Vikas Sarawat CableLabs 858美国科罗拉多州路易斯维尔市煤溪Cir Louisville
EMail: v.sarawat@cablelabs.com
EMail: v.sarawat@cablelabs.com
Karthik Sundaresan CableLabs 858 Coal Creek Cir Louisville, CO 80027 United States
美国科罗拉多州路易斯维尔市煤溪858号卡尔蒂克孙代瑞森电缆实验室，邮编80027
EMail: k.sundaresan@cablelabs.com
EMail: k.sundaresan@cablelabs.com
Olivier Vautrin Juniper Networks 1194 N Mathilda Avenue Sunnyvale, CA 94089 United States
美国加利福尼亚州桑尼维尔市马蒂尔达大道北1194号奥利维尔·沃特林·朱尼珀网络公司，邮编94089
EMail: olivier@juniper.net
EMail: olivier@juniper.net