Internet Engineering Task Force (IETF)                 V. Kuarsingh, Ed.
Request for Comments: 7289                                 J. Cianfarani
Category: Informational                            Rogers Communications
ISSN: 2070-1721                                                June 2014
        
Internet Engineering Task Force (IETF)                 V. Kuarsingh, Ed.
Request for Comments: 7289                                 J. Cianfarani
Category: Informational                            Rogers Communications
ISSN: 2070-1721                                                June 2014
        

Carrier-Grade NAT (CGN) Deployment with BGP/MPLS IP VPNs

使用BGP/MPLS IP VPN部署运营商级NAT(CGN)

Abstract

摘要

This document specifies a framework to integrate a Network Address Translation (NAT) layer into an operator's network to function as a Carrier-Grade NAT (also known as CGN or Large-Scale NAT). The CGN infrastructure will often form a NAT444 environment as the subscriber home network will likely also maintain a subscriber-side NAT function. Exhaustion of the IPv4 address pool is a major driver compelling some operators to implement CGN. Although operators may wish to deploy IPv6 to strategically overcome IPv4 exhaustion, near-term needs may not be satisfied with an IPv6 deployment alone. This document provides a practical integration model that allows the CGN platform to be integrated into the network, meeting the connectivity needs of the subscriber while being mindful of not disrupting existing services and meeting the technical challenges that CGN brings. The model included in this document utilizes BGP/MPLS IP VPNs, which allow for virtual routing separation, helping ease the CGN's impact on the network. This document does not intend to defend the merits of CGN.

本文档指定了一个框架,用于将网络地址转换(NAT)层集成到运营商的网络中,以用作运营商级NAT(也称为CGN或大规模NAT)。CGN基础设施通常会形成NAT444环境,因为用户家庭网络可能也会保持用户端NAT功能。IPv4地址池的耗尽是迫使一些运营商实施CGN的主要驱动因素。尽管运营商可能希望部署IPv6以从战略上克服IPv4耗尽的问题,但仅部署IPv6可能无法满足短期需求。本文档提供了一个实用的集成模型,该模型允许将CGN平台集成到网络中,满足用户的连接需求,同时注意不中断现有服务并满足CGN带来的技术挑战。本文档中包含的模型利用BGP/MPLS IP VPN,允许虚拟路由分离,有助于缓解CGN对网络的影响。本文件不打算为CGN的优点辩护。

Status of This Memo

关于下段备忘

This document is not an Internet Standards Track specification; it is published for informational purposes.

本文件不是互联网标准跟踪规范;它是为了提供信息而发布的。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

本文件是互联网工程任务组(IETF)的产品。它代表了IETF社区的共识。它已经接受了公众审查,并已被互联网工程指导小组(IESG)批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准;见RFC 5741第2节。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7289.

有关本文件当前状态、任何勘误表以及如何提供反馈的信息,请访问http://www.rfc-editor.org/info/rfc7289.

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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本,并提供简化BSD许可证中所述的无担保。

Table of Contents

目录

   1. Introduction ....................................................4
      1.1. Acronyms and Terms .........................................4
   2. Existing Network Considerations .................................5
   3. CGN Network Deployment Requirements .............................5
      3.1. Centralized versus Distributed Deployment ..................6
      3.2. CGN and Traditional IPv4 Service Coexistence ...............7
      3.3. CGN Bypass .................................................7
      3.4. Routing Plane Separation ...................................8
      3.5. Flexible Deployment Options ................................8
      3.6. IPv4 Overlap Space .........................................9
      3.7. Transactional Logging for CGN Systems ......................9
      3.8. Base CGN Requirements ......................................9
   4. BGP/MPLS IP VPN-Based CGN Framework .............................9
      4.1. Service Separation ........................................11
      4.2. Internal Service Delivery .................................12
           4.2.1. Dual-Stack Operation ...............................14
      4.3. Deployment Flexibility ....................................16
      4.4. Comparison of BGP/MPLS IP VPN Option versus Other
           CGN Attachment Options ....................................16
           4.4.1. Policy-Based Routing ...............................16
           4.4.2. Traffic Engineering ................................17
           4.4.3. Multiple Routing Topologies ........................17
      4.5. Multicast Considerations ..................................17
   5. Experiences ....................................................17
      5.1. Basic Integration and Requirements Support ................17
      5.2. Performance ...............................................18
   6. Security Considerations ........................................18
   7. BGP/MPLS IP VPN CGN Framework Discussion .......................18
   8. Acknowledgements ...............................................19
   9. References .....................................................19
      9.1. Normative Reference .......................................19
      9.2. Informative References ....................................19
        
   1. Introduction ....................................................4
      1.1. Acronyms and Terms .........................................4
   2. Existing Network Considerations .................................5
   3. CGN Network Deployment Requirements .............................5
      3.1. Centralized versus Distributed Deployment ..................6
      3.2. CGN and Traditional IPv4 Service Coexistence ...............7
      3.3. CGN Bypass .................................................7
      3.4. Routing Plane Separation ...................................8
      3.5. Flexible Deployment Options ................................8
      3.6. IPv4 Overlap Space .........................................9
      3.7. Transactional Logging for CGN Systems ......................9
      3.8. Base CGN Requirements ......................................9
   4. BGP/MPLS IP VPN-Based CGN Framework .............................9
      4.1. Service Separation ........................................11
      4.2. Internal Service Delivery .................................12
           4.2.1. Dual-Stack Operation ...............................14
      4.3. Deployment Flexibility ....................................16
      4.4. Comparison of BGP/MPLS IP VPN Option versus Other
           CGN Attachment Options ....................................16
           4.4.1. Policy-Based Routing ...............................16
           4.4.2. Traffic Engineering ................................17
           4.4.3. Multiple Routing Topologies ........................17
      4.5. Multicast Considerations ..................................17
   5. Experiences ....................................................17
      5.1. Basic Integration and Requirements Support ................17
      5.2. Performance ...............................................18
   6. Security Considerations ........................................18
   7. BGP/MPLS IP VPN CGN Framework Discussion .......................18
   8. Acknowledgements ...............................................19
   9. References .....................................................19
      9.1. Normative Reference .......................................19
      9.2. Informative References ....................................19
        
1. Introduction
1. 介绍

Operators are faced with near-term IPv4 address-exhaustion challenges. Many operators may not have a sufficient amount of IPv4 addresses in the future to satisfy the needs of their growing subscriber base. This challenge may also be present before or during an active transition to IPv6, somewhat complicating the overall problem space.

运营商面临着近期IPv4地址耗尽的挑战。未来,许多运营商可能没有足够的IPv4地址来满足其不断增长的用户群的需求。这一挑战也可能在主动过渡到IPv6之前或期间出现,这在一定程度上使整个问题空间复杂化。

To face this challenge, operators may need to deploy CGN (Carrier-Grade NAT) as described in [RFC6888] to help extend the connectivity matrix once IPv4 address caches run out on the local operator. CGN deployments will most often be added into operator networks that already have active IPv4 and/or IPv6 services.

为了应对这一挑战,运营商可能需要部署[RFC6888]中所述的CGN(运营商级NAT),以便在本地运营商的IPv4地址缓存用完时帮助扩展连接矩阵。CGN部署通常会添加到已经具有活动IPv4和/或IPv6服务的运营商网络中。

The addition of the CGN introduces a translation layer that is controlled and administered by an operator and that should be added in a manner that minimizes disruption to existing services. The CGN system addition may also include interworking in a dual-stack environment where the IPv4 path requires translation.

CGN的增加引入了一个由运营商控制和管理的翻译层,该层的添加方式应尽量减少对现有服务的中断。CGN系统添加还可以包括在IPv4路径需要转换的双栈环境中的互通。

This document shows how BGP/MPLS IP VPNs as described in [RFC4364] can be used to integrate the CGN infrastructure solving key integration challenges faced by the operator. This model has also been tested and validated in real production-network models and allows fluid operation with existing IPv4 and IPv6 services.

本文档展示了如何使用[RFC4364]中所述的BGP/MPLS IP VPN集成CGN基础设施,以解决运营商面临的关键集成难题。该模型还已在实际生产网络模型中进行了测试和验证,并允许在现有IPv4和IPv6服务中流畅地运行。

1.1. Acronyms and Terms
1.1. 缩略语和术语

Acronyms and terms used in this document are defined in the list below.

本文件中使用的首字母缩略词和术语定义见下表。

CGN - Carrier-Grade NAT

CGN-载波级NAT

DOCSIS - Data Over Cable Service Interface Specification

DOCSIS-有线数据服务接口规范

CMTS - Cable Modem Termination System

CMTS-电缆调制解调器终端系统

DSL - Digital Subscriber Line

数字用户线路

BRAS - Broadband Remote Access Server

宽带远程访问服务器

GGSN - Gateway GPRS Support Node

GGSN-网关GPRS支持节点

GPRS - General Packet Radio Service

通用分组无线业务

ASN-GW - Access Service Network Gateway

ASN-GW-接入服务网络网关

GRT - Global Routing Table

GRT-全局路由表

Internal Realm - Addressing and/or network zone between the Customer Premises Equipment (CPE) and CGN as specified in [RFC6888]

内部领域-客户场所设备(CPE)和CGN之间的寻址和/或网络区域,如[RFC6888]所述

External Realm - Public-side network zone and addressing on the Internet-facing side of the CGN as specified in [RFC6888]

外部领域-公共侧网络区域和CGN面向互联网侧的寻址,如[RFC6888]所述

2. Existing Network Considerations
2. 现有网络注意事项

The selection of CGN may be made by an operator based on a number of factors. The overall driver to use CGN may be the depletion of IPv4 address pools, which leaves little to no addresses for a growing IPv4 service or connection demand growth. IPv6 is considered the strategic answer for IPv4 address depletion; however, the operator may independently decide that CGN is needed to supplement IPv6 and address their particular IPv4 service deployment needs.

操作员可基于多个因素选择CGN。使用CGN的总体驱动因素可能是IPv4地址池的耗尽,这使得IPv4服务或连接需求的增长几乎没有地址。IPv6被认为是IPv4地址耗尽的战略解决方案;然而,运营商可以独立决定需要CGN来补充IPv6并满足其特定IPv4服务部署需求。

If the operator has chosen to deploy CGN, they should do this in a manner as not to negatively impact the existing IPv4 or IPv6 subscriber base. This will include solving a number of challenges since subscribers whose connections require translation will have network routing and flow needs that are different from legacy IPv4 connections.

如果运营商已选择部署CGN,则应以不会对现有IPv4或IPv6用户群产生负面影响的方式进行部署。这将包括解决一系列挑战,因为其连接需要转换的订户将具有不同于传统IPv4连接的网络路由和流量需求。

3. CGN Network Deployment Requirements
3. CGN网络部署要求

If a service provider is considering a CGN deployment with a provider NAT44 function, there are a number of basic architectural requirements that are of importance. Preliminary architectural requirements may require all or some of those captured in the list below. Each of the architectural requirement items listed is expanded upon in the following subsections. It should be noted that architectural CGN requirements are additive to base CGN functional requirements contained in [RFC6888]. The assessed architectural requirements for deployment are:

如果服务提供商正在考虑使用提供商NAT44功能进行CGN部署,则有许多基本的体系结构需求非常重要。初步架构要求可能需要以下列表中的全部或部分内容。下列小节对列出的每个体系结构需求项进行了扩展。应该注意的是,架构CGN需求是[RFC6888]中包含的基本CGN功能需求的补充。经评估的部署架构要求包括:

- Support distributed (sparse) and centralized (dense) deployment models. See Section 3.1

- 支持分布式(稀疏)和集中式(密集)部署模型。见第3.1节

- Allow coexistence with traditional IPv4-based deployments, which provide global-scoped IPv4 addresses to CPEs. See Section 3.2.

- 允许与传统的基于IPv4的部署共存,后者为CPE提供全局范围的IPv4地址。见第3.2节。

- Provide a framework for CGN bypass supporting non-translated flows between endpoints within a provider's network. See Section 3.3.

- 为CGN旁路提供一个框架,支持提供者网络中端点之间的非转换流。见第3.3节。

- Provide a routing framework that allows the segmentation of routing control and forwarding paths between CGN-mediated and non-CGN-mediated flows. See Section 3.4.

- 提供一个路由框架,允许在CGN中介和非CGN中介流之间分割路由控制和转发路径。见第3.4节。

- Provide flexibility for operators to modify their deployments over time as translation demands change (connections, bandwidth, translation realms/zones, and other vectors). See Section 3.5.

- 随着翻译需求的变化(连接、带宽、翻译领域/区域和其他载体),运营商可以灵活地随时间修改其部署。见第3.5节。

- Flexibility should include integration options for common access technologies such as DSL (BRAS), DOCSIS (CMTS), Mobile (GGSN/PGW/ ASN-GW), and direct Ethernet. See Section 3.5.

- 灵活性应包括通用接入技术的集成选项,如DSL(BRAS)、DOCSIS(CMTS)、移动(GGSN/PGW/ASN-GW)和直接以太网。见第3.5节。

- Support deployment modes that allow for IPv4 address overlap within the operator's network (between various translation realms or zones). See Section 3.6.

- 支持允许运营商网络内IPv4地址重叠的部署模式(在各种翻译领域或区域之间)。见第3.6节。

- Allow for evolution to future dual-stack and IPv4/IPv6 transition deployment modes. See Section 3.5.

- 允许发展到未来的双栈和IPv4/IPv6过渡部署模式。见第3.5节。

- Transactional logging and export capabilities to support auxiliary functions, including abuse mitigation. See Section 3.7.

- 事务日志记录和导出功能,以支持辅助功能,包括滥用缓解。见第3.7节。

- Support for stateful connection synchronization between translation instances/elements (redundancy). See Section 3.8.

- 支持转换实例/元素之间的有状态连接同步(冗余)。见第3.8节。

- Support for CGN Shared Address Space [RFC6598] deployment modes if applicable. See Section 3.6.

- 如果适用,支持CGN共享地址空间[RFC6598]部署模式。见第3.6节。

- Allow for the enablement of CGN functionality (if required) while still minimizing costs and subscriber impact to the best extend possible. See Section 3.8.

- 允许启用CGN功能(如果需要),同时尽可能最大限度地降低成本和对订户的影响。见第3.8节。

Other requirements may be assessed on an operator-by-operator basis, but those listed above may be considered for any given deployment architecture.

其他需求可以逐个运营商进行评估,但上面列出的需求可以考虑用于任何给定的部署架构。

3.1. Centralized versus Distributed Deployment
3.1. 集中式部署与分布式部署

Centralized deployments of CGN (longer proximity to end user and/or higher densities of subscribers/connections to CGN instances) differ from distributed deployments of CGN (closer proximity to end user and/or lower densities of subscribers/connections to CGN instances). Service providers may likely deploy CGN translation points more centrally during initial phases if the early system demand is low. Early deployments may see light loading on these new systems since legacy IPv4 services will continue to operate with most endpoints using globally unique IPv4 addresses. Exceptional cases that may drive heavy usage in initial stages may include operators that

CGN的集中部署(更接近最终用户和/或更高密度的订阅服务器/连接到CGN实例)不同于CGN的分布式部署(更接近最终用户和/或更低密度的订阅服务器/连接到CGN实例)。如果早期系统需求较低,服务提供商可能会在初始阶段更集中地部署CGN转换点。早期部署可能会在这些新系统上看到轻负载,因为传统IPv4服务将继续在大多数使用全局唯一IPv4地址的端点上运行。在初始阶段可能导致大量使用的例外情况可能包括

already translate a significant portion of their IPv4 traffic, operators that may transition to a CGN implementation from legacy translation mechanisms (i.e., traditional firewalls), or operators that build a greenfield deployment that may see quick growth in the number of new IPv4 endpoints that require Internet connectivity.

已经转换了其IPv4流量的很大一部分,运营商可能会从传统转换机制(即传统防火墙)过渡到CGN实现,或者运营商构建了绿地部署,可能会看到需要互联网连接的新IPv4端点数量的快速增长。

Over time, some providers may need to expand and possibly distribute the translation points if demand for the CGN system increases. The extent of the expansion of the CGN infrastructure will depend on factors such as growth in the number of IPv4 endpoints, status of IPv6 content on the Internet, and the overall progress globally to an IPv6-dominate Internet (reducing the demand for IPv4 connectivity). The overall demand for CGN resources will probably follow a bell-like curve with a growth, peak, and decline period.

随着时间的推移,如果对CGN系统的需求增加,一些提供商可能需要扩展并可能分发翻译点。CGN基础设施的扩展程度将取决于各种因素,如IPv4端点数量的增长、互联网上IPv6内容的状态以及全球向IPv6主导互联网的总体进展(减少对IPv4连接的需求)。CGN资源的总体需求可能会遵循钟形曲线,有增长期、峰值期和下降期。

3.2. CGN and Traditional IPv4 Service Coexistence
3.2. CGN与传统IPv4服务共存

Newer CGN-serviced endpoints will exist alongside endpoints served by traditional IPv4 globally routed addresses. Operators will need to rationalize these environments since both have distinct forwarding needs. Traditional IPv4 services will likely require (or be best served by) direct forwarding toward Internet peering points while CGN-mediated flows require access to a translator. CGN-mediated and non-CGN-mediated flows pose two fundamentally different forwarding needs.

较新的CGN服务端点将与传统IPv4全局路由地址服务的端点共存。运营商需要合理化这些环境,因为两者都有不同的转发需求。传统IPv4服务可能需要(或最好通过)直接转发到Internet对等点,而CGN介导的流需要访问转换器。CGN介导和非CGN介导的流提出了两种根本不同的转发需求。

The new CGN environments should not negatively impact the existing IPv4 service base by forcing all traffic to translation-enabled network points since many flows do not require translation and this would reduce performance of the existing flows. This would also require massive scaling of the CGN, which is a cost and efficiency concern as well.

新的CGN环境不应通过强制将所有流量传输到支持转换的网络点而对现有IPv4服务基础产生负面影响,因为许多流不需要转换,这将降低现有流的性能。这还需要大规模扩展CGN,这也是一个成本和效率问题。

Efficiency of traffic flow and forwarding is considered important since networks are under considerable demand to deliver more and more bandwidth without the luxury of needless inefficiencies that can be introduced with CGN.

流量和转发的效率被认为是重要的,因为网络需要提供越来越多的带宽,而不需要CGN带来不必要的低效率。

3.3. CGN Bypass
3.3. CGN旁路

The CGN environment is only needed for flows with translation requirements. Many flows that remain within the operator's network do not require translation. Such services include operator-offered DNS services, DHCP services, NTP services, web caching, email, news, and other services that are local to the operator's network.

只有具有转换需求的流才需要CGN环境。许多留在运营商网络中的流不需要转换。此类服务包括运营商提供的DNS服务、DHCP服务、NTP服务、web缓存、电子邮件、新闻以及运营商网络本地的其他服务。

The operator may want to leverage opportunities to offer third parties a platform to also provide services without translation. CGN bypass can be accomplished in many ways, but a simplistic, deterministic, and scalable model is preferred.

运营商可能希望利用机会为第三方提供一个平台,以提供无需翻译的服务。CGN旁路可以通过多种方式实现,但最好采用简单、确定性和可扩展的模型。

3.4. Routing Plane Separation
3.4. 路由平面分离

Many operators will want to engineer traffic separately for CGN flows versus flows that are part of the more traditional IPv4 environment. Many times, the routing of these two major flow types differ; therefore, route separation may be required.

许多运营商希望分别为CGN流和作为更传统IPv4环境一部分的流设计流量。很多时候,这两种主要流量类型的路由不同;因此,可能需要进行路线分隔。

Routing-plane separation also allows the operator to utilize other addressing techniques, which may not be feasible on a single routing plane. Such examples include the use of overlapping private address space [RFC1918], Shared Address Space [RFC6598], or other IPv4 space that may overlap globally within the operator's network.

路由平面分离还允许操作员利用在单个路由平面上可能不可行的其他寻址技术。此类示例包括使用重叠的专用地址空间[RFC1918]、共享地址空间[RFC6598]或可能在运营商网络内全局重叠的其他IPv4空间。

3.5. Flexible Deployment Options
3.5. 灵活的部署选项

Service providers operate complex routing environments and offer a variety of IPv4-based services. Many operator environments utilize distributed external routing infrastructures for transit and peering, and these may span large geographical areas. A CGN solution should offer operators the ability to place CGN translation points at various points within their network.

服务提供商操作复杂的路由环境,并提供各种基于IPv4的服务。许多运营商环境利用分布式外部路由基础设施进行传输和对等,这些基础设施可能跨越很大的地理区域。CGN解决方案应为运营商提供将CGN翻译点放置在其网络内不同点的能力。

The CGN deployment should also be flexible enough to change over time as demand for translation services increase or change as noted in [RFC6264]. In turn, the deployment will need to then adapt as translation demand decreases due to the transition of flows to IPv6. Translation points should be able to be placed and moved with as little re-engineering effort as possible, minimizing the risks to the subscriber base.

CGN部署也应足够灵活,以便随着翻译服务需求的增加或[RFC6264]中所述的变化而变化。反过来,随着流向IPv6的过渡,翻译需求减少,部署需要随之调整。翻译点应该能够在尽可能少的重新设计工作的情况下放置和移动,从而最大限度地降低对订户群的风险。

Depending on hardware capabilities, security practices, and IPv4 address availability, the translation environments may need to be segmented and/or scaled over time to meet organic IPv4 demand growth. Operators may also want to choose models that support transition to other translation environments such as Dual-Stack Lite (DS-Lite) [RFC6333] and/or Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (NAT64) [RFC6146]. Operators will want to seek deployment models that are conducive to meeting these goals as well.

根据硬件功能、安全实践和IPv4地址可用性,翻译环境可能需要随着时间的推移进行细分和/或扩展,以满足IPv4需求的有机增长。运营商可能还希望选择支持转换到其他转换环境的型号,如双栈Lite(DS Lite)[RFC6333]和/或从IPv6客户端到IPv4服务器的网络地址和协议转换(NAT64)[RFC6146]。运营商也希望寻求有助于实现这些目标的部署模式。

3.6. IPv4 Overlap Space
3.6. IPv4重叠空间

IPv4 address overlap for CGN translation realms may be required if insufficient IPv4 addresses are available within the operator environment to assign internally unique IPv4 addresses to the CGN subscriber base. The CGN deployment should provide mechanisms to manage IPv4 overlap if required.

如果运营商环境中没有足够的IPv4地址可用于向CGN用户群分配内部唯一的IPv4地址,则可能需要CGN转换领域的IPv4地址重叠。如果需要,CGN部署应提供管理IPv4重叠的机制。

3.7. Transactional Logging for CGN Systems
3.7. CGN系统的事务日志记录

CGNs may require transactional logging since the source IP and related transport-protocol information are not easily visible to external hosts and system.

CGN可能需要事务性日志记录,因为源IP和相关传输协议信息对外部主机和系统不容易看到。

If needed, CGN systems should be able to generate logs that identify internal-realm host parameters (i.e., IP/Port) and associate them to external-realm parameters imposed by the translator. The logged information should be stored on the CGN hardware and/or exported to another system for processing. The operator may choose to also enable mechanisms to help reduce logging, such as block allocation of UDP and TCP ports or deterministic translation options, e.g., [CGN-DEPLOYMENTS].

如果需要,CGN系统应该能够生成识别内部领域主机参数(即IP/端口)的日志,并将它们与转换器施加的外部领域参数相关联。记录的信息应存储在CGN硬件上和/或导出到另一个系统进行处理。操作员还可以选择启用有助于减少日志记录的机制,例如UDP和TCP端口的块分配或确定性转换选项,例如[CGN-DEPLOYMENTS]。

Operators may be legally obligated to keep track of translation information. The operator may need to utilize their standard practices in handling sensitive customer data when storing and/or transporting such data. Further information regarding CGN logging requirements can be found in Section 4 of [RFC6888].

运营商可能有法律义务跟踪翻译信息。在存储和/或传输此类数据时,运营商可能需要利用其处理敏感客户数据的标准做法。有关CGN测井要求的更多信息,请参见[RFC6888]第4节。

3.8. Base CGN Requirements
3.8. 基本CGN要求

Whereas the requirements above represent assessed architectural requirements, the CGN platform will also need to meet the base CGN requirements of a CGN function. Base requirements include functions such as Bulk Port Allocation and other CGN device-specific functions. These base CGN platform requirements are captured in [RFC6888].

鉴于上述需求代表评估的架构需求,CGN平台还需要满足CGN功能的基本CGN需求。基本需求包括批量端口分配等功能和其他CGN设备特定功能。这些基本CGN平台要求见[RFC6888]。

4. BGP/MPLS IP VPN-Based CGN Framework
4. 基于BGP/MPLS IP VPN的CGN框架

The BGP/MPLS IP VPN [RFC4364] framework for CGN segregates the internal realms within the service-provider space into Layer 3 MPLS-based VPNs. The operator can deploy a single realm for all CGN-based flows or can deploy multiple realms based on translation demand and other factors such as geographical proximity. A realm in this model refers to a "VPN", which shares a unique Route Distinguisher / Route Target (RD/RT) combination, routing plane, and forwarding behaviors.

CGN的BGP/MPLS IP VPN[RFC4364]框架将服务提供商空间内的内部领域隔离为基于第3层MPLS的VPN。运营商可以为所有基于CGN的流部署单个领域,也可以根据翻译需求和其他因素(如地理位置接近度)部署多个领域。该模型中的领域是指“VPN”,它共享唯一的路由识别器/路由目标(RD/RT)组合、路由平面和转发行为。

The BGP/MPLS IP VPN infrastructure provides control-plane and forwarding separation for the traditional IPv4 service environment and CGN environment(s). The separation allows for routing information (such as default routes) to be propagated separately for CGN-based and non-CGN-based subscriber flows. Traffic can be efficiently routed to the Internet for normal flows and routed directly to translators for CGN-mediated flows. Although many operators may run a "default-route-free" core, IPv4 flows that require translation must obviously be routed first to a translator, so a default route is acceptable for the internal realms.

BGP/MPLS IP VPN基础设施为传统IPv4服务环境和CGN环境提供控制平面和转发分离。这种分离允许为基于CGN和非基于CGN的订户流分别传播路由信息(例如默认路由)。对于正常流,流量可以有效地路由到Internet,对于CGN中介流,流量可以直接路由到转换器。尽管许多运营商可能运行“默认无路由”核心,但需要转换的IPv4流显然必须首先路由到转换器,因此内部领域可以接受默认路由。

The physical location of the Virtual Routing and Forwarding (VRF) termination point for a BGP/MPLS IP VPN-enabled CGN can vary and be located anywhere within the operator's network. This model fully virtualizes the translation service from the base IPv4 forwarding environment that will likely be carrying Internet-bound traffic. The base IPv4 environment can continue to service traditional IPv4 subscriber flows plus post translated CGN flows.

启用BGP/MPLS IP VPN的CGN的虚拟路由和转发(VRF)终结点的物理位置可能会有所不同,并位于运营商网络中的任何位置。此模型完全虚拟化了来自基本IPv4转发环境的翻译服务,该环境可能会承载Internet绑定的流量。基本IPv4环境可以继续为传统IPv4订户流加上转换后的CGN流提供服务。

Figure 1 provides a view of the basic model. The access node provides CPE access to either the CGN VRF or the Global Routing Table (GRT), depending on whether the subscriber receives a private or public IP. Translator-mediated traffic follows an MPLS Label Switched Path (LSP) that can be set up dynamically and can span one hop or many hops (with no need for complex routing policies). Traffic is then forwarded to the translator, which can be an external appliance or integrated into the VRF Termination (Provider Edge) router. Once traffic is translated, it is forwarded to the GRT for general Internet forwarding. The GRT can also be a separate VRF (Internet access VPN/VRF) should the provider choose to implement their Internet-based services in that fashion. The translation services are effectively overlaid onto the network but are maintained within a separate forwarding and control plane.

图1提供了基本模型的视图。接入节点向CPE提供对CGN VRF或全局路由表(GRT)的访问,这取决于订户接收的是私有IP还是公共IP。转换器介导的流量遵循MPLS标签交换路径(LSP),该路径可以动态设置,并且可以跨越一个或多个跃点(无需复杂的路由策略)。然后,流量被转发到转换器,转换器可以是外部设备,也可以集成到VRF终端(提供商边缘)路由器中。流量转换后,将转发至GRT进行一般互联网转发。如果提供商选择以这种方式实施基于互联网的服务,GRT也可以是单独的VRF(互联网访问VPN/VRF)。翻译服务有效地覆盖在网络上,但在单独的转发和控制平面内进行维护。

                   Access Node     VRF Termination        CGN
                  +-----------+     +-----------+    +-----------+
                  |           |     |           |    |           |
          CPE     | +-------+ |     | +-------+ |    | +-------+ |
         +----+   | |       | | LSP | |       | | IP | |       | |
         |  --+---+-+->VRF--+-+-----+-+->VRF--+-+----+-+->     | |
         +----+   | |       | |     | |       | |    | |       | |
                  | +-------+ |     | +-------+ |    | |       | |
                  |           |     |           |    | | XLATE | |
                  |           |     |           |    | |       | |
         CPE-CGN  | +-------+ |     | +-------+ |    | |       | |
         +----+   | |       | |     | |       | | IP | |       | |
         |  --+---+-+->GRT  | |     | |  GRT<-+-+----+-+--     | |
         +----+   | |   |   | |     | |   |   | |    | |       | |
                  | +---+---+ |     | +---+---+ |    | +-------+ |
                  +-----+-----+     +-----+-----+    +-----------+
                        |                 |
                        |                 |                IPv4
                        |                 |   IP       +---------+
                        |                 +------------+->       |
                        |                     IP       |    GRT  |
                        +------------------------------+->       |
                                                       +---------+
        
                   Access Node     VRF Termination        CGN
                  +-----------+     +-----------+    +-----------+
                  |           |     |           |    |           |
          CPE     | +-------+ |     | +-------+ |    | +-------+ |
         +----+   | |       | | LSP | |       | | IP | |       | |
         |  --+---+-+->VRF--+-+-----+-+->VRF--+-+----+-+->     | |
         +----+   | |       | |     | |       | |    | |       | |
                  | +-------+ |     | +-------+ |    | |       | |
                  |           |     |           |    | | XLATE | |
                  |           |     |           |    | |       | |
         CPE-CGN  | +-------+ |     | +-------+ |    | |       | |
         +----+   | |       | |     | |       | | IP | |       | |
         |  --+---+-+->GRT  | |     | |  GRT<-+-+----+-+--     | |
         +----+   | |   |   | |     | |   |   | |    | |       | |
                  | +---+---+ |     | +---+---+ |    | +-------+ |
                  +-----+-----+     +-----+-----+    +-----------+
                        |                 |
                        |                 |                IPv4
                        |                 |   IP       +---------+
                        |                 +------------+->       |
                        |                     IP       |    GRT  |
                        +------------------------------+->       |
                                                       +---------+
        

Figure 1: Basic BGP/MPLS IP VPN CGN Model

图1:基本BGP/MPLS IP VPN CGN模型

If more then one VRF (translation realm) is used within the operator's network, each VPN instance can manage CGN flows independently for the respective realm. The described architecture does not prescribe a single redundancy model that ensures network availability as a result of CGN failure. Deployments are able to select a redundancy model that fits best with their network design. If state information needs to be passed or maintained between hardware instances, the vendor would need to enable this feature in a suitable manner.

如果在运营商的网络中使用多个VRF(翻译领域),则每个VPN实例可以独立地管理各自领域的CGN流。所述体系结构没有规定单一冗余模型,以确保CGN故障导致的网络可用性。部署能够选择最适合其网络设计的冗余模型。如果需要在硬件实例之间传递或维护状态信息,则供应商需要以适当的方式启用此功能。

4.1. Service Separation
4.1. 服务分离

The MPLS/VPN CGN framework supports route separation. The traditional IPv4 flows can be separated at the access node (initial Layer 3 service point) from those that require translation. This type of service separation is possible on common technologies used for Internet access within many operator networks. Service separation can be accomplished on common access technology, including those used for DOCSIS (CMTS), Ethernet access, DSL (BRAS), and mobile access (GGSN/ASN-GW) architectures.

MPLS/VPN CGN框架支持路由分离。传统的IPv4流可以在接入节点(初始第3层服务点)与需要转换的IPv4流分离。这种类型的服务分离在许多运营商网络中用于互联网接入的通用技术上是可能的。服务分离可以在公共接入技术上实现,包括用于DOCSIS(CMTS)、以太网接入、DSL(BRAS)和移动接入(GGSN/ASN-GW)体系结构的技术。

4.2. Internal Service Delivery
4.2. 内部服务提供

Internal services can be delivered directly to the privately addressed endpoint within the CGN domain without translation. This can be accomplished in one of two methods. The first method is the use of "route leaking", a method of exchanging routes between the CGN VRF and GRT; this method may also include reducing the overall number of VRFs in the system and exposing services in the GRT. The second method, which is described in detail within this section, is the use of a Services VRF. The second model is a more traditional extranet services model but requires more system resources to implement.

内部服务可以直接交付到CGN域内的私有寻址端点,而无需转换。这可以通过两种方法之一实现。第一种方法是使用“路由泄漏”,即CGN VRF和GRT之间交换路由的方法;该方法还可以包括减少系统中VRF的总数和在GRT中公开服务。第二种方法是使用服务VRF,本节对此进行了详细描述。第二个模型是更传统的外联网服务模型,但需要更多的系统资源来实现。

Using direct route exchange (import/export) between the CGN VRFs and the Services VRFs creates reachability using the aforementioned extranet model available in the BGP/MPLS IP VPN structure. This model allows the provider to maintain separate forwarding rules for translated flows, which require a pass through the translator to reach external network entities, versus those flows that need to access internal services. This operational detail can be advantageous for a number of reasons, such as service-access policies and endpoint identification. First, the provider can reduce the load on the translator since internal services do not need to be factored into the scaling of the CGN hardware (which may be quite large). Second, more direct forwarding paths can be maintained to provide better network efficiency. Third, geographic locations of the translators and the services infrastructure can be deployed in locations in an independent manner. Additionally, the operator can allow CGN subject endpoints to be accessible via an untranslated path, reducing the complexities of provider-initiated management flows. This last point is of key interest since NAT removes transparency to the end device in normal cases.

使用CGN VRF和服务VRF之间的直接路由交换(导入/导出),可以使用上述BGP/MPLS IP VPN结构中可用的外联网模型创建可达性。此模型允许提供商为翻译流维护单独的转发规则,与需要访问内部服务的流相比,翻译流需要通过转换器到达外部网络实体。由于许多原因,例如服务访问策略和端点标识,此操作细节可能是有利的。首先,提供者可以减少转换器的负载,因为内部服务不需要考虑到CGN硬件的扩展中(这可能相当大)。第二,可以维护更多的直接转发路径,以提供更好的网络效率。第三,笔译人员的地理位置和服务基础设施可以独立地部署在不同的地点。此外,操作员可以允许通过未翻译的路径访问CGN主题端点,从而降低提供者发起的管理流的复杂性。最后一点非常重要,因为NAT在正常情况下会消除终端设备的透明度。

Figure 2 below shows how internal services are provided untranslated since flows are sent directly from the access node to the services node/VRF via an MPLS LSP. This traffic is not forwarded to the CGN translator and therefore is not subject to problematic behaviors related to NAT. The Services VRF contains routing information that can be "imported" into the access node VRF, and the CGN VRF routing information can be "imported" into the Services VRF.

下面的图2显示了内部服务是如何提供的,因为流是通过MPLS LSP直接从接入节点发送到服务节点/VRF的。此流量不会转发给CGN转换器,因此不会受到与NAT相关的问题行为的影响。服务VRF包含可“导入”到接入节点VRF中的路由信息,CGN VRF路由信息可“导入”到服务VRF中。

              Access Node     VRF Termination     CGN
            +-------------+    +-----------+  +----------+
            |             |    |           |  |          |
     CPE    | +---------+ |    | +-------+ |  | +------+ |
   +-----+  | |         | |    | |       | |  | |      | |
   |   --+--+-+-> VRF --+-+--+ | |  VRF  | |  | |      | |
   +-----+  | |         | |  | | |       | |  | |      | |
            | +---------+ |  | | +-------+ |  | |      | |
            |             |  | |           |  | |XLATE | |
            |             |  | |           |  | |      | |
   CPE-CGN  | +---------+ |  | | +-------+ |  | |      | |
   +-----+  | |         | |  | | |       | |  | |      | |
   |   --+--+-+-> GRT   | |  | | |  GRT  | |  | |      | |
   +-----+  | |    |    | |  | | |       | |  | |      | |
            | +----+----+ |  | | +-------+ |  | +------+ |
            +------+------+  | +-----------+  +----------+
                   |         |
                   |         |                    IPv4
                   |         |               +-----------+
                   |         +---------------+->Services |
                   |                         |    VRF    |
                   .-------------------------+->   |     |
                                             +-----+-----+
                                                   |
                                             +-----V-----+
                                             |           |
                                             |   Local   |
                                             |  Content  |
                                             +-----------+
        
              Access Node     VRF Termination     CGN
            +-------------+    +-----------+  +----------+
            |             |    |           |  |          |
     CPE    | +---------+ |    | +-------+ |  | +------+ |
   +-----+  | |         | |    | |       | |  | |      | |
   |   --+--+-+-> VRF --+-+--+ | |  VRF  | |  | |      | |
   +-----+  | |         | |  | | |       | |  | |      | |
            | +---------+ |  | | +-------+ |  | |      | |
            |             |  | |           |  | |XLATE | |
            |             |  | |           |  | |      | |
   CPE-CGN  | +---------+ |  | | +-------+ |  | |      | |
   +-----+  | |         | |  | | |       | |  | |      | |
   |   --+--+-+-> GRT   | |  | | |  GRT  | |  | |      | |
   +-----+  | |    |    | |  | | |       | |  | |      | |
            | +----+----+ |  | | +-------+ |  | +------+ |
            +------+------+  | +-----------+  +----------+
                   |         |
                   |         |                    IPv4
                   |         |               +-----------+
                   |         +---------------+->Services |
                   |                         |    VRF    |
                   .-------------------------+->   |     |
                                             +-----+-----+
                                                   |
                                             +-----V-----+
                                             |           |
                                             |   Local   |
                                             |  Content  |
                                             +-----------+
        

Figure 2: Internal Services and CGN Bypass

图2:内部服务和CGN旁路

An extension to the services delivery LSP is the ability to also provide direct subscriber-to-subscriber traffic flows between CGN zones. Each zone or realm may be fitted with separate CGN resources, but the subtending subscribers don't necessarily need to be mediated (translated) by the CGN translators. This option, as shown in Figure 3, is easy to implement and can only be enabled if no IPv4 address overlap is used between communicating CGN zones.

服务交付LSP的一个扩展是还能够在CGN区域之间提供直接的用户到用户流量。每个区域或领域可能配备有单独的CGN资源,但子终端订户不一定需要由CGN翻译人员进行调解(翻译)。如图3所示,此选项易于实现,并且只有在通信CGN区域之间未使用IPv4地址重叠时才能启用。

             Access Node-1     VRF Termination   CGN-1
            +-------------+    +-----------+  +----------+
            |             |    |           |  |          |
     CPE-1  | +---------+ |    | +-------+ |  | +------+ |
   +-----+  | |         | |    | |       | |  | |      | |
   |   --+--+-+-  VRF --+-+-+  | |  VRF  | |  | |      | |
   +-----+  | |         | | |  | |       | |  | |      | |
            | +---------+ | |  | +-------+ |  | |      | |
            |             | |  |           |  | |XLATE | |
            |             | |  |           |  | |      | |
   CPE-2-CGN| +---------+ | |  | +-------+ |  | |      | |
   +-----+  | |         | | |  | |       | |  | |      | |
   |   --+--+-+-  GRT   | | |  | |  GRT  | |  | |      | |
   +-----+  | |         | | |  | |       | |  | |      | |
            | +---------+ | |  | +-------+ |  | +------+ |
            +-------------+ |  +-----------+  +----------+
                            |
                        LSP |
                            |
             Access Node-2  |  VRF Termination   CGN-2
            +-------------+ |  +-----------+  +----------+
            |             | |  |           |  |          |
   CPE-3-CGN| +---------+ | |  | +-------+ |  | +------+ |
   +-----+  | |         | | |  | |       | |  | |      | |
   |   --+--+-+-- VRF --+-+-+  | |  VRF  | |  | |      | |
   +-----+  | |         | |    | |       | |  | |      | |
            | +---------+ |    | +-------+ |  | |      | |
            |             |    |           |  | |XLATE | |
            |             |    |           |  | |      | |
     CPE-4  | +---------+ |    | +-------+ |  | |      | |
   +-----+  | |         | |    | |       | |  | |      | |
   |   --+--+-+-  GRT   | |    | |  GRT  | |  | |      | |
   +-----+  | |         | |    | |       | |  | |      | |
            | +---------+ |    | +-------+ |  | +------+ |
            +-------------+    +-----------+  +----------+
        
             Access Node-1     VRF Termination   CGN-1
            +-------------+    +-----------+  +----------+
            |             |    |           |  |          |
     CPE-1  | +---------+ |    | +-------+ |  | +------+ |
   +-----+  | |         | |    | |       | |  | |      | |
   |   --+--+-+-  VRF --+-+-+  | |  VRF  | |  | |      | |
   +-----+  | |         | | |  | |       | |  | |      | |
            | +---------+ | |  | +-------+ |  | |      | |
            |             | |  |           |  | |XLATE | |
            |             | |  |           |  | |      | |
   CPE-2-CGN| +---------+ | |  | +-------+ |  | |      | |
   +-----+  | |         | | |  | |       | |  | |      | |
   |   --+--+-+-  GRT   | | |  | |  GRT  | |  | |      | |
   +-----+  | |         | | |  | |       | |  | |      | |
            | +---------+ | |  | +-------+ |  | +------+ |
            +-------------+ |  +-----------+  +----------+
                            |
                        LSP |
                            |
             Access Node-2  |  VRF Termination   CGN-2
            +-------------+ |  +-----------+  +----------+
            |             | |  |           |  |          |
   CPE-3-CGN| +---------+ | |  | +-------+ |  | +------+ |
   +-----+  | |         | | |  | |       | |  | |      | |
   |   --+--+-+-- VRF --+-+-+  | |  VRF  | |  | |      | |
   +-----+  | |         | |    | |       | |  | |      | |
            | +---------+ |    | +-------+ |  | |      | |
            |             |    |           |  | |XLATE | |
            |             |    |           |  | |      | |
     CPE-4  | +---------+ |    | +-------+ |  | |      | |
   +-----+  | |         | |    | |       | |  | |      | |
   |   --+--+-+-  GRT   | |    | |  GRT  | |  | |      | |
   +-----+  | |         | |    | |       | |  | |      | |
            | +---------+ |    | +-------+ |  | +------+ |
            +-------------+    +-----------+  +----------+
        

Figure 3: Subscriber-to-Subscriber CGN Bypass

图3:用户对用户CGN旁路

The inherent capabilities of the BGP/MPLS IP VPN model demonstrates the ability to offer CGN bypass in a standard and deterministic manner without the need of policy-based routing or traffic engineering.

BGP/MPLS IP VPN模型的固有功能证明了以标准和确定的方式提供CGN旁路的能力,而无需基于策略的路由或流量工程。

4.2.1. Dual-Stack Operation
4.2.1. 双堆栈操作

The BGP/MPLS IP VPN CGN model can also be used in conjunction with IPv4/IPv6 dual-stack service modes. Since many providers will use CGNs on an interim basis while IPv6 matures within the global

BGP/MPLS IP VPN CGN模型还可以与IPv4/IPv6双栈服务模式结合使用。因为当IPv6在全球范围内成熟时,许多提供商将临时使用CGN

Internet or due to technical constraints, a dual-stack option is of strategic importance. Operators can offer this dual-stack service for both traditional IPv4 (global IP) endpoints and CGN-mediated endpoints.

由于技术限制,双堆栈选项具有战略重要性。运营商可以为传统IPv4(全局IP)端点和CGN介导的端点提供这种双堆栈服务。

Operators can separate the IP flows for IPv4 and IPv6 traffic, or they can use other routing techniques to move IPv6-based flows toward the GRT (Global Routing Table) while allowing IPv4 flows to remain within the IPv4 CGN VRF for translator services.

运营商可以分离IPv4和IPv6流量的IP流,也可以使用其他路由技术将基于IPv6的流移动到GRT(全局路由表)中,同时允许IPv4流保留在IPv4 CGN VRF中以用于转换器服务。

Figure 4 shows how IPv4 translation services can be provided alongside IPv6-based services. This model allows the provider to enable CGN to manage IPv4 flows (translated), and IPv6 flows are routed without translation efficiently toward the Internet. Once again, forwarding of flows to the translator does not impact IPv6 flows, which do not require this service.

图4显示了IPv4翻译服务如何与基于IPv6的服务一起提供。此模型允许提供商使CGN能够管理IPv4流(转换),并且IPv6流在没有转换的情况下被有效地路由到Internet。同样,将流转发到转换器不会影响IPv6流,IPv6流不需要此服务。

             Access Node   VRF Termination        CGN
            +-----------+   +-----------+    +-----------+
            |           |   |           |    |           |
    CPE-CG  | +-------+ |   | +-------+ |    | +-------+ |
   +-----+  | |       | |LSP| |       | | IP | |       | |
   |   --+--+-+->VRF--+-+---+-+->VRF--+-+----+-+>      | |
   |IPv4 |  | |       | |   | |       | |    | |       | |
   |     |  | +-------+ |   | +-------+ |    | |       | |
   +-----|  |           |   |           |    | | XLATE | |
   |IPv6 |  |           |   |           |    | |       | |
   |     |  | +-------+ |   | +-------+ |    | |       | |
   |     |  | |  IPv6 | |   | |  IPv4 | | IP | |       | |
   |   --+--+-+->GRT  | |   | |  GRT<-+-+----+-+--     | |
   +-----+  | |   |   | |   | |   |   | |    | |       | |
            | +---+---+ |   | +---+---+ |    | +-------+ |
            +-----+-----+   +-----+-----+    +-----------+
                  |               |
                  |               |          +-----------+
                  |               |    IP    |    IPv4   |
                  |               +----------+->  GRT    |
                  |                          +-----------+
                  |
                  |
                  |
                  |               IP         +-----------+
                  +--------------------------+->  IPv6   |
                                             |    GRT    |
                                             +-----------+
        
             Access Node   VRF Termination        CGN
            +-----------+   +-----------+    +-----------+
            |           |   |           |    |           |
    CPE-CG  | +-------+ |   | +-------+ |    | +-------+ |
   +-----+  | |       | |LSP| |       | | IP | |       | |
   |   --+--+-+->VRF--+-+---+-+->VRF--+-+----+-+>      | |
   |IPv4 |  | |       | |   | |       | |    | |       | |
   |     |  | +-------+ |   | +-------+ |    | |       | |
   +-----|  |           |   |           |    | | XLATE | |
   |IPv6 |  |           |   |           |    | |       | |
   |     |  | +-------+ |   | +-------+ |    | |       | |
   |     |  | |  IPv6 | |   | |  IPv4 | | IP | |       | |
   |   --+--+-+->GRT  | |   | |  GRT<-+-+----+-+--     | |
   +-----+  | |   |   | |   | |   |   | |    | |       | |
            | +---+---+ |   | +---+---+ |    | +-------+ |
            +-----+-----+   +-----+-----+    +-----------+
                  |               |
                  |               |          +-----------+
                  |               |    IP    |    IPv4   |
                  |               +----------+->  GRT    |
                  |                          +-----------+
                  |
                  |
                  |
                  |               IP         +-----------+
                  +--------------------------+->  IPv6   |
                                             |    GRT    |
                                             +-----------+
        

Figure 4: CGN with IPv6 Dual-Stack Operation

图4:具有IPv6双堆栈操作的CGN

4.3. Deployment Flexibility
4.3. 部署灵活性

The CGN translator services can be moved, separated or segmented (new translation realms) without the need to change the overall translation design. Since dynamic LSPs are used to forward traffic from the access nodes to the translation points, the physical location of the VRF termination points can vary and be changed easily.

CGN翻译服务可以移动、分离或分割(新的翻译领域),而无需更改整体翻译设计。由于动态LSP用于将流量从接入节点转发到转换点,因此VRF终端点的物理位置可能会发生变化,并且很容易改变。

This type of flexibility allows the service provider to initially deploy more centralized translation services based on relatively low loading factors and distribute the translation points over time to improve network-traffic efficiencies and support higher translation load.

这种灵活性允许服务提供商最初基于相对较低的负载因素部署更集中的翻译服务,并随着时间的推移分配翻译点,以提高网络流量效率并支持更高的翻译负载。

Although traffic-engineered paths are not required within the MPLS/ VPN deployment model, nothing precludes an operator from using technologies like MPLS with Traffic Engineering [RFC3031]. Additional routing mechanisms can be used as desired by the provider and can be seen as independent. There is no specific need to diversify the existing infrastructure in most cases.

尽管在MPLS/VPN部署模型中不需要流量工程路径,但没有什么可以阻止运营商将MPLS等技术与流量工程结合使用[RFC3031]。提供者可以根据需要使用额外的路由机制,并且可以将其视为独立的。在大多数情况下,没有具体需要使现有基础设施多样化。

4.4. Comparison of BGP/MPLS IP VPN Option versus Other CGN Attachment Options

4.4. BGP/MPLS IP VPN选项与其他CGN连接选项的比较

Other integration architecture options exist that can attach CGN based service flows to a translator instance. Alternate options that can be used to attach such services include:

存在其他集成体系结构选项,可以将基于CGN的服务流附加到转换器实例。可用于附加此类服务的备选选项包括:

- policy-based routing (static) to direct translation-bound traffic to a network-based translator;

- 基于策略的路由(静态)将翻译绑定的通信量定向到基于网络的转换器;

- traffic engineering; and

- 交通工程;和

- multiple routing topologies.

- 多路由拓扑。

4.4.1. Policy-Based Routing
4.4.1. 基于策略的路由

Policy-based routing (PBR) provides another option to direct CGN-mediated flows to a translator. PBR options, although possible, are difficult to maintain (due to static policy) and must be configured throughout the network with considerable maintenance overhead.

基于策略的路由(PBR)提供了另一种将CGN介导的流定向到转换器的选项。PBR选项虽然可能,但很难维护(由于静态策略),并且必须在整个网络中配置,维护开销很大。

More centralized deployments may be difficult or too onerous to deploy using policy-based routing methods. Policy-based routing would not achieve route separation (unless used with others options) and may add complexities to the providers' routing environment.

使用基于策略的路由方法部署更集中的部署可能比较困难或过于繁重。基于策略的路由不会实现路由分离(除非与其他选项一起使用),并且可能会增加提供商路由环境的复杂性。

4.4.2. Traffic Engineering
4.4.2. 交通工程

Traffic engineering can also be used to direct traffic from an access node toward a translator. Traffic engineering, like MPLS-TE, may be difficult to set up and maintain. Traffic engineering provides additional benefits if used with MPLS by adding potential for faster path re-convergence. Traffic engineering paths would need to be updated and redefined over time as CGN translation points are augmented or moved.

流量工程还可用于将来自接入节点的流量定向到转换器。流量工程,如MPLS-TE,可能难以设置和维护。如果与MPLS一起使用,流量工程通过增加更快路径重新聚合的潜力提供了额外的好处。随着CGN转换点的增加或移动,流量工程路径需要随着时间的推移进行更新和重新定义。

4.4.3. Multiple Routing Topologies
4.4.3. 多路由拓扑

Multiple routing topologies can be used to direct CGN-based flows to translators. This option would achieve the same basic goal as the MPLS/VPN option but with additional implementation overhead and platform configuration complexity. Since operator based translation is expected to have an unknown lifecycle, and may see various degrees of demand (dependent on operator IPv4 Global space availability and shift of traffic to IPv6), it may be too large of an undertaking for the provider to enabled this as their primary option for CGN.

可以使用多种路由拓扑将基于CGN的流定向到转换器。此选项将实现与MPLS/VPN选项相同的基本目标,但会增加实现开销和平台配置复杂性。由于基于运营商的翻译预计会有一个未知的生命周期,并且可能会出现不同程度的需求(取决于运营商IPv4的全球空间可用性和流量向IPv6的转移),因此,对于提供商来说,将此作为其CGN的主要选项可能太大。

4.5. Multicast Considerations
4.5. 多播注意事项

When deploying BGP/MPLS IP VPNs as a service method for user-plane traffic to access CGN, one needs to be cognizant of current or future IP multicast requirements. User-plane IP Multicast that may originate outside of the VRF requires specific consideration. Adding the requirement for user plane IP multicast can potentially cause additional complexity related to importing and exporting the IP multicast routes in addition to suboptimal scaling and bandwidth utilization.

当部署BGP/MPLS IP VPN作为用户平面流量访问CGN的服务方法时,需要了解当前或未来的IP多播需求。可能起源于VRF之外的用户平面IP多播需要特别考虑。添加对用户平面IP多播的需求可能会导致与导入和导出IP多播路由相关的额外复杂性,以及次优的扩展和带宽利用率。

It is recommended to reference best practice and designs from [RFC6037], [RFC6513], and [RFC5332].

建议参考[RFC6037]、[RFC6513]和[RFC5332]中的最佳实践和设计。

5. Experiences
5. 经历
5.1. Basic Integration and Requirements Support
5.1. 基本集成和需求支持

The MPLS/VPN CGN environment has been successfully integrated into real network environments utilizing existing network service delivery mechanisms. It solves many issues related to provider-based translation environments while still subject to problematic behaviors inherent within NAT.

MPLS/VPN CGN环境已利用现有的网络服务提供机制成功地集成到实际网络环境中。它解决了许多与基于提供者的翻译环境相关的问题,同时仍然受制于NAT中固有的问题行为。

The key issues that are solved or managed with the MPLS/VPN option include:

使用MPLS/VPN选项解决或管理的关键问题包括:

- Support for the centralized and distributed deployment model

- 对集中式和分布式部署模型的支持

- Routing plane separation for CGN flows versus traditional IPv4 flows

- CGN流与传统IPv4流的路由平面分离

- Flexible translation point design (can relocate translators and split translation zones easily)

- 灵活的翻译点设计(可以轻松地重新定位翻译人员和分割翻译区域)

- Low maintenance overhead (dynamic routing environment with little maintenance of separate routing infrastructure other than management of MPLS/VPNs)

- 低维护开销(动态路由环境,除了管理MPLS/VPN外,对单独的路由基础设施的维护很少)

- CGN bypass options (for internal and third-party services that exist within the provider domain)

- CGN旁路选项(用于提供商域中存在的内部和第三方服务)

- IPv4 translation realm overlap support (can reuse IP addresses between zones with some impact to extranet service model)

- IPv4转换域重叠支持(可以在区域之间重用IP地址,对外部网服务模型有一定影响)

- Simple failover techniques can be implemented with redundant translators, such as using a second default route

- 简单的故障切换技术可以通过冗余转换器实现,例如使用第二条默认路由

5.2. Performance
5.2. 表演

The MPLS/VPN CGN model was observed to support basic functions that are typically used by subscribers within an operator environment. A full review of the observed impacts related to CGN (NAT444) are covered in [RFC7021].

据观察,MPLS/VPN CGN模型支持运营商环境中订户通常使用的基本功能。[RFC7021]中涵盖了与CGN(NAT444)相关的观测影响的全面审查。

6. Security Considerations
6. 安全考虑

An operator implementing CGN using BGP/MPLS IP VPNs should refer to Section 7 of [RFC6888] for security considerations related to CGN deployments. The operator should continue to employ the standard security methods in place for their standard MPLS deployment and can also refer to the Security Considerations section in [RFC4364], which discusses both control-plane and data-plane security.

使用BGP/MPLS IP VPN实施CGN的运营商应参考[RFC6888]第7节,了解与CGN部署相关的安全注意事项。运营商应继续为其标准MPLS部署使用现有的标准安全方法,也可参考[RFC4364]中的安全注意事项部分,其中讨论了控制平面和数据平面安全。

7. BGP/MPLS IP VPN CGN Framework Discussion
7. BGP/MPLS IP VPN CGN框架探讨

The MPLS/VPN delivery method for a CGN deployment is an effective and scalable way to deliver mass translation services. The architecture avoids the complex requirements of traffic engineering and policy-based routing when combining these new service flows to existing IPv4

用于CGN部署的MPLS/VPN交付方法是提供大规模翻译服务的有效且可扩展的方法。当将这些新服务流与现有IPv4相结合时,该体系结构避免了流量工程和基于策略的路由的复杂要求

operation. This is advantageous since the NAT444/CGN environments should be introduced with as little impact as possible, and these environments are expected to change over time.

活动这是有利的,因为引入NAT444/CGN环境时应尽可能减少影响,并且这些环境预计会随着时间的推移而变化。

The MPLS/VPN-based CGN architecture solves many of the issues related to deploying this technology in existing operator networks.

基于MPLS/VPN的CGN体系结构解决了许多与在现有运营商网络中部署该技术相关的问题。

8. Acknowledgements
8. 致谢

Thanks to the following people for their comments and feedback: Dan Wing, Chris Metz, Chris Donley, Tina TSOU, Christopher Liljenstolpe, and Tom Taylor.

感谢以下人士的评论和反馈:Dan Wing、Chris Metz、Chris Donley、Tina TSOU、Christopher Liljenstolpe和Tom Taylor。

Thanks to the following people for their participation in integrating and testing the CGN environment and for their guidance in regard to IPv6 transition: Syd Alam, Richard Lawson, John E. Spence, John Jason Brzozowski, Chris Donley, Jason Weil, Lee Howard, and Jean-Francois Tremblay.

感谢以下人员参与CGN环境的集成和测试,并就IPv6过渡提供指导:Syd Alam、Richard Lawson、John E.Spence、John Jason Brzowski、Chris Donley、Jason Weil、Lee Howard和Jean Francois Tremblay。

9. References
9. 工具书类
9.1. Normative Reference
9.1. 规范性引用文件

[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.

[RFC4364]Rosen,E.和Y.Rekhter,“BGP/MPLS IP虚拟专用网络(VPN)”,RFC 4364,2006年2月。

9.2. Informative References
9.2. 资料性引用

[CGN-DEPLOYMENTS] Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K., and O. Vautrin, "Deterministic Address Mapping to Reduce Logging in Carrier Grade NAT Deployments", Work in Progress, January 2014.

[CGN-部署]Donley,C.,Grundemann,C.,Sarawat,V.,Sundaresan,K.,和O.Vautrin,“确定性地址映射以减少运营商级NAT部署中的日志记录”,正在进行的工作,2014年1月。

[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.

[RFC1918]Rekhter,Y.,Moskowitz,R.,Karrenberg,D.,Groot,G.,和E.Lear,“私人互联网地址分配”,BCP 5,RFC 1918,1996年2月。

[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.

[RFC3031]Rosen,E.,Viswanathan,A.,和R.Callon,“多协议标签交换体系结构”,RFC 30312001年1月。

[RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS Multicast Encapsulations", RFC 5332, August 2008.

[RFC5332]Eckert,T.,Rosen,E.,Aggarwal,R.,和Y.Rekhter,“MPLS多播封装”,RFC 5332,2008年8月。

[RFC6037] Rosen, E., Cai, Y., and IJ. Wijnands, "Cisco Systems' Solution for Multicast in BGP/MPLS IP VPNs", RFC 6037, October 2010.

[RFC6037]Rosen,E.,Cai,Y.,和IJ。Wijnands,“思科系统在BGP/MPLS IP VPN中的多播解决方案”,RFC 6037,2010年10月。

[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011.

[RFC6146]Bagnulo,M.,Matthews,P.,和I.van Beijnum,“有状态NAT64:从IPv6客户端到IPv4服务器的网络地址和协议转换”,RFC 61462011年4月。

[RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264, June 2011.

[RFC6264]Jiang,S.,Guo,D.,和B.Carpenter,“IPv6过渡的增量载波级NAT(CGN)”,RFC 62642011年6月。

[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011.

[RFC6333]Durand,A.,Droms,R.,Woodyatt,J.,和Y.Lee,“IPv4耗尽后的双栈Lite宽带部署”,RFC 63332011年8月。

[RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP VPNs", RFC 6513, February 2012.

[RFC6513]Rosen,E.和R.Aggarwal,“MPLS/BGP IP VPN中的多播”,RFC 6513,2012年2月。

[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.

[RFC6598]Weil,J.,Kuarsingh,V.,Donley,C.,Liljenstolpe,C.,和M.Azinger,“IANA为共享地址空间保留IPv4前缀”,BCP 153,RFC 6598,2012年4月。

[RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common Requirements for Carrier-Grade NATs (CGNs)", BCP 127, RFC 6888, April 2013.

[RFC6888]Perreault,S.,Yamagata,I.,Miyakawa,S.,Nakagawa,A.,和H.Ashida,“载体级NAT(CGN)的通用要求”,BCP 127,RFC 6888,2013年4月。

[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.

[RFC7021]Donley,C.,Howard,L.,Kuarsingh,V.,Berg,J.,和J.Doshi,“评估运营商级NAT对网络应用的影响”,RFC 7021,2013年9月。

Authors' Addresses

作者地址

Victor Kuarsingh (editor) Rogers Communications 8200 Dixie Road Brampton, Ontario L6T 0C1 Canada

Victor Kuarsingh(编辑)加拿大安大略省布兰顿市迪克西路8200号罗杰斯通讯有限公司L6T 0C1

   EMail: victor@jvknet.com
   URI:   http://www.rogers.com
        
   EMail: victor@jvknet.com
   URI:   http://www.rogers.com
        

John Cianfarani Rogers Communications 8200 Dixie Road Brampton, Ontario L6T 0C1 Canada

John Cianfarani Rogers Communications加拿大安大略省布兰顿迪克西路8200号L6T 0C1

   EMail: john.cianfarani@rci.rogers.com
   URI:   http://www.rogers.com
        
   EMail: john.cianfarani@rci.rogers.com
   URI:   http://www.rogers.com