RFC 7289
Carrier-Grade NAT (CGN) Deployment with BGP/MPLS IP VPNs
Carrier-Grade NAT (CGN) Deployment with BGP/MPLS IP VPNs 💖
Okay bestie, this is RFC 7289, and it's all about Carrier-Grade NAT (CGN) Deployment with BGP/MPLS IP VPNs 🎀. It was written by V. Kuarsingh (the editor 📝) and J. Cianfarani, both from Rogers Communications 🇨🇦. It's an Informational doc, which means it's not a standards-track thing, just useful info 📚. The ISSN is 2070-1721 and it's dated June 2014 🗓️. The title block doesn't list anything it obsoletes or updates, so it's just doing its own thing ✨.
Abstract 🌸
So this doc is basically a plan for how an operator can slot a NAT layer into their network so it works as a Carrier-Grade NAT, aka CGN, aka Large-Scale NAT 🦋. The CGN setup will often end up as a NAT444 situation, because the subscriber's home network probably has its own NAT too 🏠. Running out of IPv4 addresses is the big reason operators are doing this, and honestly it's a whole mood 😭. Moving to IPv6 is the long-term strategic move, but near-term needs might not be met by IPv6 alone 💅.
This doc gives a practical integration model so the CGN can meet subscriber connectivity needs without disrupting existing services, and it deals with the tricky CGN challenges too 🫶. The model uses BGP/MPLS IP VPNs, which allow virtual routing separation and help ease the CGN's impact on the network 🌈. And ngl, it's not here to argue whether CGN is good or bad 🙈.
Status of This Memo 📜
This doc is not an Internet Standards Track spec, it's just published for informational purposes 📚.
It's a product of the IETF, so it reflects the consensus of the IETF community 🤝. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every doc the IESG approves can be a candidate for any level of Internet Standard, so see Section 2 of RFC 5741 for the details 💁♀️.
For info on the current status of this doc, any errata, and how to send feedback, check out 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 💜.
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. Please read these carefully, because they describe your rights and restrictions for this doc, no cap 📖. Code Components pulled out of this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License ⚖️.
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 ....................................191. Introduction ✨
Operators are facing near-term IPv4 address-exhaustion challenges, and it's giving stress 😩. Lots of operators might not have enough IPv4 addresses in the future to keep up with their growing subscriber base 📈. This challenge could also show up before or during an active transition to IPv6, which makes the whole problem space a bit more complicated 🌀.
To handle this, 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 get added into operator networks that already have active IPv4 and/or IPv6 services 💫.
The CGN addition brings in a translation layer that is controlled and administered by an operator, and it should be added in a way that minimizes disruption to existing services 🫧. The CGN system addition may also include interworking in a dual-stack environment where the IPv4 path needs translation 🧚.
This doc shows how BGP/MPLS IP VPNs, as described in [RFC4364], can be used to integrate the CGN infrastructure and solve the key integration challenges the operator faces 👑. This model has also been tested and validated in real production-network models, and it allows fluid operation alongside existing IPv4 and IPv6 services 🦋.
1.1. Acronyms and Terms 🌷
Acronyms and terms used in this doc are defined in the list below 📝.
- CGN - Carrier-Grade NAT
- DOCSIS - Data Over Cable Service Interface Specification
- CMTS - Cable Modem Termination System
- DSL - Digital Subscriber Line
- BRAS - Broadband Remote Access Server
- GGSN - Gateway GPRS Support Node
- GPRS - General Packet Radio Service
- ASN-GW - Access Service Network Gateway
- GRT - Global Routing Table
- Internal Realm - Addressing and/or network zone between the Customer Premises Equipment (CPE) and CGN, as specified in [RFC6888]
- External Realm - Public-side network zone and addressing on the Internet-facing side of the CGN, as specified in [RFC6888]
2. Existing Network Considerations 🧚
An operator might pick CGN for a bunch of different reasons 🤔. The big overall driver is depletion of IPv4 address pools, which leaves little to no addresses for a growing IPv4 service or for connection demand growth 📉. IPv6 is considered the strategic answer to IPv4 address depletion 💜, but the operator may independently decide that CGN is needed to supplement IPv6 and cover their particular IPv4 service deployment needs 🎯.
If the operator has chosen to deploy CGN, they should do this in a way that doesn't negatively impact the existing IPv4 or IPv6 subscriber base 🫶. That comes with a few challenges, since subscribers whose connections need translation will have network routing and flow needs that are different from legacy IPv4 connections 🌸.
3. CGN Network Deployment Requirements 👑
If a service provider is thinking about a CGN deployment with a provider NAT44 function, there are a number of basic architectural requirements that matter 📋. Preliminary architectural requirements may need all or some of the ones in the list below 🔍. Each architectural requirement item in the list gets expanded on in the subsections that follow 🧵. It should be noted that architectural CGN requirements are additive to the base CGN functional requirements contained in [RFC6888] 💅. The assessed architectural requirements for deployment are:
- Support distributed (sparse) and centralized (dense) deployment models. See Section 3.1.
- Allow coexistence with traditional IPv4-based deployments, which provide global-scoped IPv4 addresses to CPEs. See Section 3.2.
- Provide a framework for CGN bypass supporting non-translated flows between endpoints within a provider's network. See Section 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.
- 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.
- 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.
- Support deployment modes that allow for IPv4 address overlap within the operator's network (between various translation realms or zones). See Section 3.6.
- Allow for evolution to future dual-stack and IPv4/IPv6 transition deployment modes. See Section 3.5.
- Transactional logging and export capabilities to support auxiliary functions, including abuse mitigation. See Section 3.7.
- Support for stateful connection synchronization between translation instances/elements (redundancy). See Section 3.8.
- Support for CGN Shared Address Space [RFC6598] deployment modes if applicable. See Section 3.6.
- Allow for the enablement of CGN functionality (if required) while still minimizing costs and subscriber impact to the best extent possible. See Section 3.8.
Other requirements may be assessed on an operator-by-operator basis, but the ones listed above may be considered for any given deployment architecture 🌈.
3.1. Centralized versus Distributed Deployment ✨
okay so bestie, there are two vibes for where CGN lives 🌸. Centralized deployments are the ones that sit farther from the end user and/or handle higher densities of subscribers or connections per CGN instance. Distributed deployments are closer to the end user and/or spread the load across lower densities of subscribers or connections per instance 🦋.
Service providers will likely deploy CGN translation points more centrally during the early phases, if the early demand is low. Early on, these new systems may see light loading, because legacy IPv4 services keep running with most endpoints still using globally unique IPv4 addresses 💅. There are a few exceptions that can cause heavy usage right from the start. Operators that already translate a big chunk of their IPv4 traffic are one example 👑. Others are operators that move to CGN from older translation setups (like traditional firewalls), and operators building a greenfield deployment that might see quick growth in new IPv4 endpoints that need Internet connectivity 🧚.
Over time, some providers may need to expand and maybe distribute their translation points if CGN demand goes up 📈. How much the CGN infrastructure grows depends on things like how many IPv4 endpoints show up, how much IPv6 content is on the Internet, and how far the world has moved toward an IPv6-dominate Internet (which lowers the need for IPv4 connectivity) 🌈. Overall, CGN demand will probably follow a bell-like curve: it grows, peaks, and then declines 📉💜.
3.2. CGN and Traditional IPv4 Service Coexistence
the newer CGN-served endpoints are going to live right next to endpoints that still use traditional IPv4 globally routed addresses 🫶. Operators have to sort this out, because both groups have totally different forwarding needs 🍓. Traditional IPv4 services will likely want direct forwarding toward Internet peering points (or that's where they perform best), while CGN-mediated flows need to go through a translator. ngl, CGN-mediated and non-CGN-mediated flows are two fundamentally different forwarding situations 🙈.
The new CGN environments should not hurt the existing IPv4 service base by pushing all traffic through translation-enabled network points 🚫. Lots of flows don't need translation at all, and forcing them through would slow down the flows that are already working fine 😭. It would also mean the CGN has to scale massively, which is a cost and efficiency problem too 💀.
Efficiency of traffic flow and forwarding matters a lot here, since networks are under serious pressure to deliver more and more bandwidth 🔥. Nobody has room for the needless inefficiencies that CGN can introduce 💅✨.
3.3. CGN Bypass
the CGN environment is only needed for flows that actually require translation 🎀. A lot of flows that stay inside the operator's network don't need translation at all. Examples include operator-offered DNS services, DHCP services, NTP services, web caching, email, news, and other services that are local to the operator's network 🌸.
The operator may want to take advantage of this and offer third parties a platform to provide services without translation too 🦋. CGN bypass can be done in many ways, but a simplistic, deterministic, and scalable model is the one that's preferred 👑✨.
3.4. Routing Plane Separation
lowkey, many operators will want to engineer CGN flows separately from flows that belong to the more traditional IPv4 environment 🧚. The routing for these two major flow types often differs, so route separation may be required 🛣️.
Routing-plane separation also lets the operator use other addressing techniques that might not be feasible on a single routing plane 💜. Examples include overlapping private address space [RFC1918], Shared Address Space [RFC6598], or other IPv4 space that may overlap globally within the operator's network 🌈.
3.5. Flexible Deployment Options
service providers run complex routing environments and offer a whole bunch of IPv4-based services 💅. A lot of operator setups use distributed external routing infrastructure for transit and peering, and those can stretch across huge geographical areas 🌍. A CGN solution should give operators the ability to place CGN translation points at various spots within their network 🫶.
The CGN deployment should also be flexible enough to change over time, as translation demand increases or shifts, as noted in [RFC6264] 🔄. Then the deployment will need to adapt again as translation demand drops because flows move over to IPv6 📉. Translation points should be placeable and movable with as little re-engineering effort as possible, which keeps the risks to the subscriber base low 🛡️💖.
Depending on hardware capabilities, security practices, and IPv4 address availability, the translation environments may need to be segmented and/or scaled over time to keep up with organic IPv4 demand growth 🌱. Operators may also want models that can transition to other translation environments, like 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 look for deployment models that help meet these goals as well ✨.
3.6. IPv4 Overlap Space
ok so IPv4 address overlap for CGN translation realms may be required if the operator environment doesn't have enough IPv4 addresses to give every CGN subscriber an internally unique one 😭. The CGN deployment should provide mechanisms to manage IPv4 overlap if it's needed 🔧💅.
3.7. Transactional Logging for CGN Systems
CGNs may require transactional logging, because the source IP and related transport-protocol information aren't easily visible to external hosts and systems 🕵️♀️.
if logging is needed, CGN systems should be able to generate logs that identify internal-realm host parameters (i.e., IP/Port) and link them to the external-realm parameters the translator imposes 📝✨. The logged info should be stored on the CGN hardware and/or exported to another system for processing 💾. The operator may also choose to turn on mechanisms that help reduce logging, like block allocation of UDP and TCP ports or deterministic translation options, e.g., [CGN-DEPLOYMENTS] 🌸.
Operators may be legally obligated to keep track of translation information 🚨. They may need to use their standard practices for handling sensitive customer data when storing and/or transporting that data 🔐. For more on CGN logging requirements, see Section 4 of [RFC6888] 📚.
3.8. Base CGN Requirements
so the requirements above are the assessed architectural ones, but the CGN platform also needs to meet the base CGN requirements of a CGN function 🎀. Base requirements include things like Bulk Port Allocation and other CGN device-specific functions 🧩. These base CGN platform requirements are captured in [RFC6888] 💜.
4. BGP/MPLS IP VPN-Based CGN Framework 🌸
okay so the BGP/MPLS IP VPN [RFC4364] framework for CGN splits the internal realms inside the service-provider space into Layer 3 MPLS-based VPNs 🦋 it's giving organization. The operator can run a single realm for all the CGN-based flows, or make several realms based on how much translation is happening and other stuff like geographical proximity 🌍. In this model a realm is basically a "VPN" with its own unique Route Distinguisher / Route Target (RD/RT) combo, its own routing plane, and its own forwarding behaviors ✨.
The BGP/MPLS IP VPN setup gives you control-plane and forwarding separation between the traditional IPv4 service environment and the CGN environment(s) 💜. That separation means routing info (like default routes) can be sent out separately for CGN-based and non-CGN-based subscriber flows. So normal flows can go straight out to the Internet, while CGN-mediated flows get routed directly to translators 🚀. Lots of operators run a "default-route-free" core, sure, but IPv4 flows that need translation have to hit a translator first, so a default route is totally fine for the internal realms 💅.
The physical spot where the VRF (Virtual Routing and Forwarding) termination point for a BGP/MPLS IP VPN-enabled CGN lives can change, and it can sit anywhere in the operator's network 🧚. This model fully virtualizes the translation service away from the base IPv4 forwarding environment, which is probably carrying the Internet-bound traffic. The base IPv4 environment keeps handling traditional IPv4 subscriber flows plus the CGN flows after they've been translated 🫶.
Figure 1 gives you the basic vibe 👀. The access node gives CPE access to either the CGN VRF or the Global Routing Table (GRT), depending on whether the subscriber gets a private or a public IP. Translator-mediated traffic rides an MPLS Label Switched Path (LSP) that can be set up dynamically, and it can span one hop or many hops (with no need for complex routing policies) 🎀. Then the traffic goes to the translator, which can be an external appliance or be built into the VRF Termination (Provider Edge) router. Once it's translated, it goes to the GRT for general Internet forwarding 🌈. The GRT can also be its own VRF (Internet access VPN/VRF) if the provider wants to run their Internet services that way. The translation services are basically overlaid onto the network, but they live in their own separate forwarding and control plane 💖.
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
If there's more than one VRF (translation realm) in the operator's network, each VPN instance can handle CGN flows on its own for its realm 🧁. This architecture doesn't lock you into one redundancy model for keeping the network available when CGN fails 🙈. Deployments get to pick whichever redundancy model fits their network design best ✨. And if state info needs to be passed around or kept between hardware instances, the vendor would need to turn that feature on in a suitable way 🔧.
4.1. Service Separation 🦋
ngl this part is so cute 🥹 the MPLS/VPN CGN framework supports route separation 💅. Traditional IPv4 flows can get split off at the access node (the initial Layer 3 service point) from the ones that need translation. This kind of service separation works on common technologies that lots of operator networks already use for Internet access 🍓. It can be done on common access tech like DOCSIS (CMTS), Ethernet access, DSL (BRAS), and mobile access (GGSN/ASN-GW) architectures 📡.
4.2. Internal Service Delivery ✨
Okay bestie, so internal services can be delivered straight to the privately addressed endpoint inside the CGN domain, no translation needed 💖. There are two methods for this. Method one is "route leaking", which means swapping routes between the CGN VRF and the GRT 🔄. This can also come with cutting down the total number of VRFs in the system and exposing services in the GRT. Method two is the one this section breaks down in detail: a Services VRF 🧚. It's a more traditional extranet services model, but it takes more system resources to set up, so it's a bit of a commitment 💅.
Using direct route exchange (import/export) between the CGN VRFs and the Services VRFs gives you reachability through that extranet model, which is available in the BGP/MPLS IP VPN structure 🦋. The best part is that it lets the provider keep separate forwarding rules for two kinds of traffic. Translated flows have to pass through the translator to reach external network entities. Other flows need to reach internal services. Keeping them apart is seriously useful for things like service-access policies and endpoint identification 👑. Here's why it slaps:
- The provider can reduce the load on the translator, since internal services don't have to be counted when scaling the CGN hardware (which can be quite large 😭).
- More direct forwarding paths can be kept up, which means better network efficiency 🌸.
- The geographic locations of the translators and the services infrastructure can be deployed independently of each other 🌈.
There's one more point that's honestly the highkey best one 🫶. The operator can make CGN-subject endpoints reachable over an untranslated path, which cuts down on the complexity of provider-initiated management flows. This matters so much because NAT normally takes away transparency to the end device 🙈.
Figure 2 below shows how internal services are provided untranslated. Flows go directly from the access node to the services node/VRF over an MPLS LSP 🚀. This traffic never gets forwarded to the CGN translator, so it doesn't run into the NAT-related problems. The Services VRF holds routing information that can be "imported" into the access node VRF, and the CGN VRF routing information can be "imported" into the Services VRF. It's giving organized 🎀.
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 BypassAn extension to the services delivery LSP is that it can also carry direct subscriber-to-subscriber traffic flows between CGN zones 🤝. Each zone or realm might have its own separate CGN resources, but the subscribers underneath don't always need to be mediated (translated) by the CGN translators 💜. This option is shown in Figure 3. It's easy to implement, but it can only be turned on if there's no IPv4 address overlap between the communicating CGN zones ⚠️.
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 BypassThe built-in abilities of the BGP/MPLS IP VPN model show that CGN bypass can be offered in a standard and deterministic way 🎯. You don't need policy-based routing or traffic engineering to get there, which is a whole vibe 😌.
4.2.1. Dual-Stack Operation 🌈
The BGP/MPLS IP VPN CGN model can also be used alongside IPv4/IPv6 dual-stack service modes 💫. A lot of providers will run CGNs on an interim basis while IPv6 matures across the global Internet, or because of technical constraints, so having a dual-stack option is of strategic importance 🍓. Operators can offer this dual-stack service to both traditional IPv4 (global IP) endpoints and CGN-mediated endpoints.
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 IPv4 flows stay inside the IPv4 CGN VRF for translator services 🔀.
Figure 4 shows how IPv4 translation services can be provided alongside IPv6-based services ✨. The provider can have the CGN handle IPv4 flows (translated), while IPv6 flows are routed toward the Internet efficiently without translation 🚀. Again, sending flows to the translator doesn't affect IPv6 flows, because those don't need this service 🙌.
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 Operation4.3. Deployment Flexibility 🦋
The CGN translator services can be moved, separated or segmented (into new translation realms) without needing 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 can be changed easily 💖.
This kind of flexibility lets the service provider start out with more centralized translation services, based on relatively low loading factors. Then, over time, they can spread the translation points out to improve network-traffic efficiency and support higher translation load 📈.
Traffic-engineered paths aren't required in the MPLS/VPN deployment model, but nothing stops an operator from using technologies like MPLS with Traffic Engineering [RFC3031] 🛠️. Additional routing mechanisms can be used as the provider wants, and they can be seen as independent of each other 🌸. In most cases, there's no specific need to diversify the existing infrastructure 💅.
4.4. Comparison of BGP/MPLS IP VPN Option versus Other CGN Attachment Options 🎀
Other integration architecture options exist that can attach CGN-based service flows to a translator instance 🔗. Alternate options that can be used to attach these services include:
- 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 🧭
Policy-based routing (PBR) is another option for directing CGN-mediated flows to a translator 🗺️. PBR options are possible, but they're difficult to maintain because of the static policy, and they must be configured throughout the network with considerable maintenance overhead 😩.
More centralized deployments may be too difficult or too onerous to deploy using policy-based routing methods 🙈. Policy-based routing wouldn't achieve route separation (unless it's used together with other options), and it may add complexities to the providers' routing environment 💀.
4.4.2. Traffic Engineering
okay so traffic engineering can also be used to steer traffic from an access node over to a translator 🧭✨ it's giving "precise GPS for packets." but traffic engineering, like MPLS-TE, may be difficult to set up and maintain 😭 it gets extra perks when you pair it with MPLS, since it can help paths re-converge faster 🏃♀️💨 the catch is that the traffic engineering paths need updating and redefining over time whenever CGN translation points get added or moved around 🔄 so it's a lot of upkeep, bestie 💅
4.4.3. Multiple Routing Topologies
multiple routing topologies can be used to direct CGN-based flows to translators 🗺️ this option gets to the same basic goal as the MPLS/VPN option, but with extra implementation overhead and more platform configuration complexity 🙃 and here's the tea: operator-based translation has an unknown lifecycle, and its demand may vary a lot. it depends on how much operator IPv4 Global space is available and how much traffic shifts over to IPv6 🌊 so it may be too big of a lift for a provider to make this their main CGN option 🫠
4.5. Multicast Considerations
when you deploy BGP/MPLS IP VPNs as the service method for user-plane traffic going to a CGN, you have to be cognizant of current or future IP multicast requirements 📡 user-plane IP Multicast that may originate outside of the VRF needs special attention 👀 adding the requirement for user-plane IP multicast can cause extra complexity around importing and exporting IP multicast routes, plus suboptimal scaling and bandwidth utilization 📉
it is recommended to reference best practices and designs from [RFC6037], [RFC6513], and [RFC5332] 📚🫶
5. Experiences ✨
5.1. Basic Integration and Requirements Support
the MPLS/VPN CGN environment has been successfully integrated into real network environments that use existing network service delivery mechanisms 🎉 it solves a lot of issues related to provider-based translation environments, though it's still subject to problematic behaviors inherent within NAT 😤
the key issues that get solved or managed with the MPLS/VPN option include:
- Support for the centralized and distributed deployment model 🏢
- Routing plane separation for CGN flows versus traditional IPv4 flows 🚦
- Flexible translation point design (translators can be relocated and translation zones can be split easily) 🧩
- Low maintenance overhead (a dynamic routing environment with little maintenance of separate routing infrastructure, other than managing MPLS/VPNs) 🥱✅
- CGN bypass options (for internal and third-party services that exist within the provider domain) 🏃♀️
- IPv4 translation realm overlap support (IP addresses can be reused between zones, with some impact to the extranet service model) ♻️
- Simple failover techniques can be implemented with redundant translators, such as using a second default route 🛟
5.2. Performance
the MPLS/VPN CGN model was observed to support the basic functions that subscribers typically use within an operator environment 📶 a full review of the observed impacts related to CGN (NAT444) is covered in [RFC7021] 📖
6. Security Considerations 🔐
okay this part is SERIOUS, bestie 😤 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 keep using the standard security methods already in place for their standard MPLS deployment 🛡️ and they can also check the Security Considerations section in [RFC4364], which discusses both control-plane and data-plane security 🧠💜
7. BGP/MPLS IP VPN CGN Framework Discussion 🎀
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 with existing IPv4 operation 🙌 that's a big deal, because NAT444/CGN environments should be introduced with as little impact as possible, and they're expected to change over time 🦋
the MPLS/VPN-based CGN architecture solves many of the issues related to deploying this technology in existing operator networks 👑
8. Acknowledgements 🫶
thank you to the following people for their comments and feedback: Dan Wing, Chris Metz, Chris Donley, Tina TSOU, Christopher Liljenstolpe, and Tom Taylor 💖
thank you to the following people for their participation in integrating and testing the CGN environment, and for their guidance regarding IPv6 transition: Syd Alam, Richard Lawson, John E. Spence, John Jason Brzozowski, Chris Donley, Jason Weil, Lee Howard, and Jean-Francois Tremblay 🌸🧚
9. References 📚
9.1. Normative Reference
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.9.2. Informative References
[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.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", BCP
5, RFC 1918, February 1996.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS
Multicast Encapsulations", RFC 5332, August 2008.
[RFC6037] Rosen, E., Cai, Y., and IJ. Wijnands, "Cisco Systems'
Solution for Multicast in BGP/MPLS IP VPNs", RFC 6037,
October 2010.
[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.
[RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental
Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264,
June 2011.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", RFC 6333, August 2011.
[RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP
VPNs", RFC 6513, February 2012.
[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.
[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.
[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.Authors' Addresses 🌈
Victor Kuarsingh (editor)
Rogers Communications
8200 Dixie Road
Brampton, Ontario L6T 0C1
Canada
EMail: victor@jvknet.com
URI: http://www.rogers.com
John Cianfarani
Rogers Communications
8200 Dixie Road
Brampton, Ontario L6T 0C1
Canada
EMail: john.cianfarani@rci.rogers.com
URI: http://www.rogers.com📦 where this page comes from
- ietf: rfc7289 2014-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms