Carrier Grade NAT - TEC Study Paper-Ver2
-
Upload
pravesh-kumar-thakur -
Category
Documents
-
view
217 -
download
0
Transcript of Carrier Grade NAT - TEC Study Paper-Ver2
-
7/30/2019 Carrier Grade NAT - TEC Study Paper-Ver2
1/17
Study Paper by I-Division TEC
(30th
September 2012)
J.M.Suri, DDG(I), TEC
B.K.Nath, Dir(I), TEC
Carrier Grade Network Address Translation for IPv6 Adoption
1.0 Introduction
1.1 It is well evident by now that there is a global shortage of new IPv4 addresses. IANA
has already allocated the final /8 pool of IPv4 addresses to all the regional RIRs in
February 2011. These RIRs will further distribute these IPv4 addresses amongst the
greater internet community of service providers, vendors and customers. As long as the
internet is expanding and new networks are created, the demand for IPv4 addresses will
remain. Therefore, all the stakeholders are facing severe IPv4 address shortage.
1.2 The IETF correctly envisioned this future state and hence invented the next version of
the Internet Protocol, IP Version 6 or IPv6. The protocol offered a number of
improvements and optimizations over its predecessor, IPv4, including auto-
configuration, header simplification, extended routing headers, and a flow labeling. The
most significant improvement was the increase in number of bits used for addressing,
from 32 in IPv4 to 128 in IPv6 thereby offering a much larger address space to meet the
future requirements of Internet.
1.3 However the two protocols are not interoperable and IPv6 is not backward compatible
with IPv4. Therefore, this poses a serious challenge to the service providers transition
plans. The IETF has specified many solutions to make the two protocols work with
each other during the period of transition by the service providers.
1.4 The Indian Service providers are currently at a nascent stage and evaluating various
solutions and products for addressing this challenge. Since the networks currently are
predominantly IPv4 based, service providers are reluctant to move to IPv6 because this
implies investment to upgrade the current network infrastructure to make it IPv6 ready.
Therefore, many service providers are looking for solutions which not only increases
the lifetime of their current IPv4 address pool but also simultaneously help in the
transition to IPv6 by facilitating the co-existence of IPv4 and IPv6. In the meanwhile
service providers also get more time to upgrade their network infrastructure to make it
IPv6 ready.
1.5 Service providers have multiple options to address IPv4 exhaustion such as acquiringadditional IPv4 addresses, prolonging the use of existing IPv4 addresses with NAT
techniques, migrating to IPv6 etc. One of the solutions being evaluated for addressing
the issue of IPv4 depletion and preservation is Carrier Grade NAT. This is a NAT
based solution and allows Service Providers to multiplex customers behind a single
IPv4 address.
-
7/30/2019 Carrier Grade NAT - TEC Study Paper-Ver2
2/17
2
Carrier Grade NAT (CGN)
2.0 Carrier-Grade NAT
IPv4 address exhaustion will require Service Providers to extend the life of IPv4 services, whilesimultaneously transitioning their network to IPv6, by enabling IPv4 address sharing among
customers. This is done with Carrier-Grade NAT (CGN). It is a centralized network address
translation (NAT) mechanism, allowing the sharing of a pool of IPv4 addresses among a much
larger number of end users. The CGN Solution allows for various deployment options to address
the various scenarios in Service Provider networks. The deployment options are as listed below -
1. NAT 44(4)
2. NAT64
3. 6rd
4. DS Lite
The Service Provider can deploy any of the listed solution depending on their network
architecture and transition plan. Each of the CGN solution is described below.
3.0 NAT44(4)
NAT44(4) uses three layers of IPv4 addressing:
A private IPv4 block within the user network (behind the CPE NAT)
A different private IPv4 block for the user-to-provider links (between the CPE NAT
and the CGN )
A public IPv4 address on the outside of the CGN
A key advantage of this architecture is that it imposes no special requirements on the CPE
NAT (assuming that RFC 1918 address space is used). However, to enable IPv6 services,
either natively or via an IPv6 rapid deployment (6rd) tunneling technology, the CPE devices
will need to be upgraded. Figure below shows a NAT44(4) implementation.
-
7/30/2019 Carrier Grade NAT - TEC Study Paper-Ver2
3/17
3
Carrier Grade NAT (CGN)
In NAT44(4), the same IPv4 address block can be reused within each customer network, and
the same IPv4 block can be reused on the inside of each CGN for the user-to-provider links. It
is this reuse of addresses behind multiple CGNs that provides the IPv4 address scaling for
NAT444 architecture.
4.0 NAT64
Another technology for IPv4/IPv6 coexistence is an IPv4to-IPv6 Network Address Translator
(NAT64). It is also known as AFT (Address Family Translation) because addresses are
changed between IPv4 family and IPv6 family. From a purely functional standpoint, this
solution is straightforward. The headers of packets passing between an IPv6-only end system
and an IPv4-only end system are converted from one protocol to the other, allowing the end
systems to communicate without knowing that the remote system is using a different IP
version. A special DNS ALG (Application level Gateway), known as DNS 64, is used to
trick IPv6 hosts into thinking that the IPv4 destination is an IPv6 address. The IPv6 host
thinks that it is communicating with another IPv6 system, and the IPv4 system thinks that it is
talking to another IPv4 system. Neither end system participates directly in the translation
process. Figure below shows the NAT64 architecture.
-
7/30/2019 Carrier Grade NAT - TEC Study Paper-Ver2
4/17
4
Carrier Grade NAT (CGN)
5.0 6rd (IPv6 Rapid Deployment)
6rd (or IPv6 rapid deployment) is another transition technology to provide IPv6
services to end users over an existing IPv4 infrastructure. 6rd builds on 6to4 tunneling concept
and overcomes some of its limitations. The key difference with 6to4 is that 6rd addresses are
derived from an IPv6 prefix tied to the service provider address space, guaranteeing return
reachability of the IPv6 packets. IPv6 packets are tunneled in IPv4 with stateless v6 to v4
mapping and automatic prefix delegation derived from the v6 destination of each packet. The
-
7/30/2019 Carrier Grade NAT - TEC Study Paper-Ver2
5/17
5
Carrier Grade NAT (CGN)
key component changes are to the routed CPE to make it 6rd capable via software or hardware
upgrade, and introduction of a 6rd border relay function in the Internet service provider (ISP)
network to route the packets to IPv6 networks.
This transition technology enables IPv6 services over IPv4 infrastructure; however, itdoes not mitigate any IPv4 exhaustion concerns. 6rd can therefore be used as a complement to
NAT444.
6.0 Dual-Stack Lite
DS Lite is a promising approach that uses IPv6-only links between the provider and the
customer. When a device in the customer network sends an IPv4 packet to an external
destination, the IPv4 packet is encapsulated in an IPv6 packet for transport into the provider
network. At the CGN , the packet is decapsulated to IPv4 and NAT44 (which translates an
IPv4 address to another IPv4 address) before delivering to the public internet. This tunneling of
IPv4 packets enables IPv4 applications and IPv4 hosts to communicate with the IPv4 Internet
over the IPv6-only links. Using this approach, a service provider can deploy IPv6 and still
provide an IPv4 service.
A DS Lite CGN must adapt its NAT binding table. The source address of the encapsulating
IPv6 packet (the address of the customer end of the IPv6 link) is added to the bindings beside
the IPv4 source address and port. Because the IPv6 address is unique to each customer, the
combination of the IPv6 source address with the IPv4 source address and port makes the
-
7/30/2019 Carrier Grade NAT - TEC Study Paper-Ver2
6/17
6
Carrier Grade NAT (CGN)
mapping unambiguous. When a responding IPv4 packet is received from the outside, its IPv4
destination address and port can be correctly matched to a specific customer behind the NAT
based on the IPv6 address in the mapping table.
The packets IPv4 destination address and port can then be mapped to the inside IPv4
destination address and port, encapsulated in IPv6 using the mapped IPv6 address as the IPv6
destination address, and then forwarded to the customer. In other words, the mapped IPv6
address not only disambiguates the customer RFC1918 address, it provides the reference for
the tunnel endpoint.
7.0 Key Design Considerations for CGN Deployment
When a service provider is evaluating a CGN solution, it is necessary to decide on the right
technology or set of techniques (CGN + tunneling) to be used. The important step is to take a
deeper look into the aspects of deployment. Some of the factors are choosing the optimal
placement in the network, evaluating sizing based on subscriber traffic characteristics and
hardware capabilities, feature support, and last but also critically important, support for a port
allocation method that can scale with minimal impact on logging infrastructure. Logging
infrastructure is an essential component when deploying a CGN solution because security
guidelines demand that each session set up at the NAT device is properly logged to enable
tracing of the actual subscriber identities.
Key metrics to be considered by Service Providers for the deployment of any CGN device
include:
-
7/30/2019 Carrier Grade NAT - TEC Study Paper-Ver2
7/17
7
Carrier Grade NAT (CGN)
Throughput
Number of translations
Translation setup rate
Application-layer gateway (ALG) support
Logging Requirements
8.0 Choosing the Right Network Addressing Technology
Choice of an Addressing solution depends on whether the goal is to preserve IPv4, or enable
IPv6 services, or both. Support for coexistence of IPv4 and IPv6 can be achieved in several
ways depending on the customer environment. Table-1 below describes at a high level how to
pick a Network Addressing technique. In reality, a complete solution may include a set of
techniques to satisfy multiple service needs. It is important to understand the backbone
technology being used on the network and also to know if the provider has control over the
access customer premises equipment (CPE).
Table 1
(Choosing the right solution to take care of addressing requirements)
CPE ACCESS DESTINATION SOLUTION
IPv4 IPv4 IPv4 NAT 44
IPv4/IPv6 IPv6 IPv4 DS Lite with NAT44
IPv4/IPv6 IPv4 IPv6 6rd
IPv6 IPv6 IPv4 NAT64
9.0 CGN Placement in the Network
There are several factors that influence the decision about where to place the CGN
solution in the network. These factors include
(i) Current network architecture,
(ii) Types of subscriber services,
(iii) Subscriber scale, and
(iv) Traffic characteristics.
Placing the solution closer to the network core means fewer routers are needed, but the
scale requirements are high for the CGN device. A distributed or decentralized solution means
more routers need CGN capability, and multiple service points are available to meet overall
scale and deployment flexibility. The decision is influenced by the existing ISP network
architecture and what the deployed routers can support. The routers should be able to create
-
7/30/2019 Carrier Grade NAT - TEC Study Paper-Ver2
8/17
8
Carrier Grade NAT (CGN)
softwires1. CGN only has to be deployed on routers that will be terminating softwires, or
performing NAT functions, or both. If the routers are not capable then the CGN has to be
placed deeper into the network.
To maintain the network efficiency and performance, the CGN function may becentralized or distributed based on existing policies deployed to steer traffic to preferred
peering points. As the mix of IPv4 and IPv6 services shift, the placement of CGN can also
change over time. Centralized CGN is positioned deep in the operator network and is large and
more scalable but fewer numbers are needed to support the customer population. Distributed is
positioned closer to the customer and is smaller and less scalable but more numbers are needed
to support the customer population. A provider may start off initially with a centralized model
and as the translation load and scale demands increase, the CGN function can be decentralized
to meet the increased demand.
Network planners sometimes make the mistake of selecting the distributed model
(because it is less expensive) without taking into consideration the key performance and scale
attributes of the centralized model. The unfortunate end result is the added cost and complexity
of an undersized NAT44 deployment.
Figure below illustrates the two models. On the left is shown a single larger NAT44
entity positioned upstream from the subscriber termination vehicles (e.g. BNG2Broadband
Network Gateway). On the right is shown N number of NAT44 entities positioned near or
inside the BNG.
1Softwires are tunnels created between 2 routers for passing data packets of other protocol from one edge of the
single protocol network to the other edge of the single protocol network.
2 BNG routers route traffic to and from broadband remote access devices such as digital subscriber line access
multiplexers (DSLAM) and Ethernet Aggregation Switches, on an Internet service provider's (ISP) network.
-
7/30/2019 Carrier Grade NAT - TEC Study Paper-Ver2
9/17
9
Carrier Grade NAT (CGN)
CGN Centralized and Distributed Deployment Models
Observations:
Centralized leaves the BNG infrastructure untouched; Distributed requires touching
all BNGs either by inserting and configuring a NAT44 blade or configuring ports to
attach to an adjacent NAT44 box.
Centralized offers maximum IPv4 address %, that is no NAT44 resources are unused.
Distributed IPv4 address % is not optimal and thus some NAT44 will go unused.
Conversely and worse, there could be situations where NAT44 resources are
insufficient.
Centralized offers an ideal location to offer new IPv6 transition services that can
operate over the top of the IPv4 infrastructure (e.g. 6rd is one) or in parallel (NAT64 is
one). A distributed implementation may not have sufficient resources (e.g. CPU,
memory) or might be constrained topologically (e.g. 6rd requires connectivity to
operators IPv6 routing space, which is not available in a distributed topology)
CGN is not the ultimate solution. It is merely one step on the multi-path journey to
IPv6. The location of CGN in the network and the IPv6 functions that can be activated
on the CGN platform makes it ideal to move forward in this journey.
-
7/30/2019 Carrier Grade NAT - TEC Study Paper-Ver2
10/17
10
Carrier Grade NAT (CGN)
10.0 Phase wise migration by ISPs using CGN solutions
ISPs choosing to deploy CGN solutions for IPv6 transition can use a phase-wised approach.
Initially the ISP infrastructure will be completely IPv4 ready only infrastructure. The ISPs will
not only like to extend the life of existing IPv4 addresses but also start to carry the IPv6 traffic
without disturbing the IPv4 operations. A combination of CPE upgrades and CGN deployment
can start the IPv6 deployment.
10.1 Phase-1
In phase-1, new CPEs deployed at customer premises will be dual stack. At the customer end,
the clients could be v4 only or dual-stack. The ISP infrastructure will be predominantly IPv4,
so the IPv6 traffic from the client can be carried by v6-over-v4 tunnels to the CGN gateway.
The v4 traffic from client will travel to the CGN gateway normally. At the CGN gateway, the
v6 traffic is sent to the IPv6 internet and the v4 traffic towards the IPv4 internet. The V4
internet and the v6 internet are also interconnected with a NAT64 solution. In phase-1 tunnels
-
7/30/2019 Carrier Grade NAT - TEC Study Paper-Ver2
11/17
11
Carrier Grade NAT (CGN)
could be 6RD, ISATAP3, VET
4or 6PE
5. Of these methods 6RD is most preferred. During this
phase, the ISP can gain experience and confidence with IPv6 deployment.
10.2 Phase-2
In this phase, the service provider can decide to switch the whole network to IPv6. It canchoose to deploy native IPv6 to avoid dual-stack but then it will have to implement DS Lite
using v4-over-v6 tunnels to carry the IPv4 traffic. Alternatively, these tunnels are not required
if the ISP upgrades the network itself to dual stack.
11.0 CGN - The Challenges
3 ISATAP (Intra-Site Automatic Tunnel Addressing Protocol) is an IPv6 transition mechanism meant to transmit
IPv6 packets between dual-stack nodes on top of an IPv4 network. ISATAP is implemented in Microsoft Windows
XP, Windows Vista, Windows 7, Windows Mobile, Linux, and in some versions of Cisco IOS.
4 VETVirtual Enterprise Traversal, RFC5558. Enterprise networks connect routers over various link types, and may also
connect to provider networks and/or the global Internet. Enterprise network nodes require a means to automatically
provision IP addresses/prefixes and support internetworking operation in a wide variety of use cases including Small
Office, Home Office (SOHO) networks, Mobile Ad hoc Networks (MANETs), multi-organizational corporate networks
and the inter-domain core of the global Internet itself. Virtual Enterprise Traversal (VET) is a method for auto-
configuration and operation of nodes in enterprise networks.
5 6PE RFC4798. It is a method for connecting IPv6 islands over IPv4 MPLS using dual stack IPv6 Provider Edge
Routers.
-
7/30/2019 Carrier Grade NAT - TEC Study Paper-Ver2
12/17
12
Carrier Grade NAT (CGN)
CGN solution is good for the short term but it has its own set of problems. Listed below are the
issues that pose a bigger challenge to the Service Providers and should be given due diligence
before undertaking the CGN deployment in their networks.
1. Loss of geo-location information2. User Traceability Challenges
3. Application Performance issues
4. Anti-spoofing
5. NAT State Maintenance impact on Device Battery Life
6. NAT limited Application support
7. NAT implications on network designHA , traffic symmetricity
8. Customer Experience
11.1 Loss of geo-location information:Often, translation zones will cross traditional geographic boundaries. Since the
source addresses of packets traversing CGN are set to the external address of the CGN,
it is difficult for external entities to associate IP/Port information to specific
locations/areas and hence disable geo-location based services.
IP addresses are frequently used to indicate, with some level of granularity and some
level of confidence, where a host is physically located. Geo-location services are used
by content providers to allow them to conform with regional content licensing
restrictions, to target advertising at specific geographic areas, or to provide customized
content. Geo-location services are also necessary for emergency services provision. In
some deployment contexts (e.g., centralized CGN), shared addressing will reduce the
level of confidence and level of location granularity that IP-based geo-location services
can provide. Viewed from the content provider, a subscriber behind a CGN
geolocates to wherever the prefix of the CGN appears to be; very often that will be in a
different city than the subscriber.
11.2 User Traceability Challenges :
Due to the nature of NAT444 address sharing, it will be hard to determine thecustomer/endpoint responsible for initiating a specific IPv4 flow based on source IP
address alone. Content providers, service providers, and law enforcement agencies will
need to use new mechanisms (e.g., logging source port and timestamp in addition to
source IP address) to potentially mitigate this new problem. This may be complex and
impact the timely response to various identification requests.
-
7/30/2019 Carrier Grade NAT - TEC Study Paper-Ver2
13/17
13
Carrier Grade NAT (CGN)
The lawful interception agencies in many jurisdictions including India , impose legal
obligation on service providers to provide the identity of a subscriber upon request .
Such legal requests have traditionally included the source IPv4 address and date (and
usually the time), which is sufficient information when subscribers are assigned IPv4
addresses for a long duration. However, where one public IPv4 address is sharedbetween several subscribers, the IPv4 address no longer uniquely identifies a
subscriber. There are two solutions to this problem
(i) The first solution is for servers to additionally log the source port of
incoming connections and for the legal request to include the source port.
The legal request should include the Information: [Source IP address, Source
Port, Timestamp] (and possibly other information). Accurate time-keeping
(e.g., use of NTP or SNTP) is vital because port assignments are dynamic. A
densely populated CGN could mean even very small amounts of clock skew
between a third party's server and the CGN operator will result in ambiguity
about which customer was using a specific port at a given time.
(ii) The second solution considers it is unrealistic to expect all servers to log the
source port number of incoming connections. To deal with this, service
providers using IPv4 address sharing may need to log IP destination
addresses. Destination logging is imperfect if multiple subscribers are
accessing the same (popular) server at nearly the same time, it can be
impossible to distinguish which subscriber accessed the server, especially
with protocols that involve several connections (e.g., HTTP). Thus, logging
the destination address on the NAT is inferior to logging the source port at
the server.
If neither solution is used (that is, the server is not logging source port numbers
and the NAT is not logging destination IP addresses), the service provider cannot
trace a particular activity to a specific subscriber. In this circumstance, the service
provider would need to disclose the identity of all subscribers who had active
sessions on the NAT during the time period in question. This may be a large number
of subscribers. Address sharing solutions must record and store all mappings
(typically during 6-12 months, depending on the local jurisdiction) that they create.
If we consider one mapping per session, a service provider should record and retain
traces of all sessions created by all subscribers during one year (if the legal storage
duration is one year). This may be challenging due to the volume of data requiring
storage, the volume of data to repeatedly transfer to the storage location, and the
volume of data to search in response to a query. This is a huge cost implication and
administrative nightmare for Service Providers to log and maintain the records for all
the subscribers and the sessions for a period of 6-12 Months.
-
7/30/2019 Carrier Grade NAT - TEC Study Paper-Ver2
14/17
14
Carrier Grade NAT (CGN)
11.3 Application Performance issues :
Several tests have been done regarding NAT impact on various applications. It was
observed that there was significant drop or degradation in application performance with
NAT. Below are few application issues listed in tests done by IETF :
(i) peer-to-peer gaming- Xbox
(ii)peer-to-peer SIP callsPJSIP
(iii)seeding sessions initiated on Bittorent and uTorrent
Details can be found at http://tools.ietf.org/html/draft-donley-nat444-impacts-03 .
There are other issues also as given below.
(i) MTU issues: Applications where the end hosts are attempting to use path MTU
Discovery [RFC1191] to optimize transmitted packet size with underlying
network MTU, shared addressing has a number of items which must be
considered. ICMP "Packet Too Big" messages must be properly translated
through the address sharing solution in both directions. However, even when
this is done incorrectly, MTU can be a concern. Many end hosts cache PMTU
discovery information for a certain period of time. If the MTU behind the
address sharing solution is inconsistent, the public end host may have the
incorrect MTU value cached. This may cause it to send packets that are too
large, causing them to be dropped if the DF (Don't Fragment) bit is set, or
causing them to be fragmented by the network, increasing load and overhead.
Because the host eventually will reduce MTU to the lowest common value forall hosts behind a given public address, it may also send packets that are below
optimal size for the specific connection, increasing overhead and reducing
throughput. This issue also generates a potential attack vector, that a malevolent
user could send an ICMP "Packet Too Big" (Type 3, Code 4) message
indicating a Next-Hop MTU of anything down to 68 octets. This value will be
cached by the off-net server for all subscribers sharing the address of the
malevolent user. This could lead to a DoS against both the remote server and
the large-scale NAT device itself (as they will both have to handle many more
packets per second).
(ii) P2P issues: The first limitation occurs when two clients sharing the same IP
address want to simultaneously retrieve the SAME file located in a SINGLE
remote peer. This limitation is due to the default BitTorrent configuration on the
remote peer which does not permit sending the same file to multiple ports of
the same IP address. This is a problem with any address sharing when two hosts
behind the same IP address are attempting to retrieve the same data from the
http://tools.ietf.org/html/draft-donley-nat444-impacts-03http://tools.ietf.org/html/draft-donley-nat444-impacts-03http://tools.ietf.org/html/draft-donley-nat444-impacts-03 -
7/30/2019 Carrier Grade NAT - TEC Study Paper-Ver2
15/17
15
Carrier Grade NAT (CGN)
same remote BitTorrent peer. BitTorrent behaves like that on purpose, in order
to reduce the threat of leeching bandwidth.
11.4
Anti-spoofing :Multiplexing users behind a single IP address can lead to situations where traffic
from that address triggers anti-spoofing/DDoS protection mechanisms, resulting in
unintentional loss of connectivity for some users. Identifying abusers has to do with
SPAM blacklisting. When a spammer is behind a CGN or using a port-shared
address, blacklisting of their IP address will result in all other subscribers sharing
that address having their ability to source SMTP packets restricted to same extent.
11.5 NAT State Maintenance impact on Battery Life
In order for hosts to maintain network state in the presence of NAT, keep-alivemessages have to be sent at frequent intervals. For battery-powered devices, sending
these keep-alive messages can result in significantly reduced mobile device battery
performance. Many NAT-friendly applications send frequent application-level
messages to ensure their session will not be timed out by a NAT. These are
commonly called "NAT keepalive" messages, even though they are not sent to the
NAT itself (rather, they are sent 'through' the NAT).
11.6 NAT limited application support
Applications that carry address and/or port information in their payload - wheretranslation of port and/or address information is performed at the IP and transport layers
by the address sharing solution, an ALG will also be required to ensure application
layer data is appropriately modified. Not many applications including messengers work
in NAT64 scenario due to lack of ALG or end-to-end protocol mechanism to support
NAT.
CGN is an interim solution for transition to IPv6, while NAT64 provides the
network layer communication between IPv4 and IPv6 node but not many applications
work on NAT64 including messenger , skype , voip , video etc. Hence NAT64 is not a
viable solution for operators. NAT44 helps operators to preserve IPv4 address thebusiness continuity issues but have significant implication on application performance,
cost and operation.
11.7 NAT implication on network design :
-
7/30/2019 Carrier Grade NAT - TEC Study Paper-Ver2
16/17
16
Carrier Grade NAT (CGN)
High availability (HA), traffic symmetry and scalability are the key design aspects and
have implication on existing network deployments.
(i) High Availability (HA) - It is a major requirement for every network service
provider. In general, there are two mechanisms to achieve high reliability, i.e. cold-standby and hot-standby. Cold-standby has synchronized configuration and
mechanisms to failover traffic between the hot and cold systems such as VRRP
[RFC5798]. Unlike hot-standby, cold- standby does not synchronize NAT64
session state. This makes cold- standby less resource intensive and generally
simpler, but it requires clients to re-establish sessions when a fail-over occurs. Hot-
standby has all the features of cold-standby but must also synchronize the binding
information base (BIB). Hot standby solution is not available with many CGN
vendors and also has huge implication of cost.
(ii)Traffic symmetry - NAT builds state information when the packets flow from a
subscriber side to network side and packets will not be allowed to traverse without
state information from network side to subscriber side, hence traffic symmetry is
required in network.
(iii)Scalability - A heavy broadband user requires hundreds of ports to access
applications like google map etc. and hence CGN solution scalability(session
concurrency and setup rate) is critical for high scale network with millions of
subscribers.
11.8 Customer Experience:
Customer experience is one of the top priorities for service providers to attract new
customers and reduce churn. A bad addressing architecture may impact on SP brand
and can lead to customer churn, hence proper planning is important in each layer of
network. IP address architecture plays an important role in overall customer experience
and hence it is recommended to deploy non shared IP architecture (IPv4 or IPv6).
12.0 Conclusion and Recommendations
a) Carrier Grade NAT (CGN) is one of the transition mechanisms to preserve the IPv4
addresses and allow communication between IPv6 and IPv4 nodes. However CGN
should not be seen as an alternative to IPv6. It only extends the useful life of IPv4
addresses in some situations; how long that life can be extended depends upon the
-
7/30/2019 Carrier Grade NAT - TEC Study Paper-Ver2
17/17
17
Carrier Grade NAT (CGN)
address usage and growth rates of the network in question. By their nature, CGN
architectures will have a finite lifetime in most networks.
b)
A CGN does not remove the need to invest in IPv6. IPv6 is the end-goal and should bepursued and deployed aggressively alongside a CGN. Over time as IPv6 reaches
critical mass, the need for a CGN or any SP-class stateful translation vehicle
diminishes. It should be noted that many CGN platforms can be software-upgradable
to support IPv6-related functions such as NAT64 or 6rd. The CGN platform should
offer investment and future protection.
c) Organizations should be aware that address sharing solution (NAT44) has limitations
like Loss of geo-location information, User Traceability , Application Performance
issues, Anti-spoofing, NAT State Maintenance impact on Device Battery Life etc.which impacts on user experience. Hence CGN should be deployed only as a
temporary solution with a clear roadmap and action plan defined for IPv6 adoption.
d) Organizations are highly recommended to deploy dual-stack and native IPv6 as the
transition mechanisms to IPv6. It is suggested that IPv6 adoption should be initiated
without any further delay. Only this will ensure good user experience thereby
sustaining and growing business for the organizations.
13.0References
(i) http://tools.ietf.org/html/draft-donley-nat444-impacts-03
(ii) http://www.ietf.org/rfc/rfc6269.txt
(iii) http://tools.ietf.org/html/draft-boucadair-behave-bittorrent-portrange-02
(iv) https://datatracker.ietf.org/doc/draft-ietf-pcp-base/?include_text=1
(v) http://code.google.com/p/androidsipservice/wiki/NatTraversal
(vi) http://www.v6summit.com/Conference/Presentations/APP&SERVICES_KESSEN.pdf
http://tools.ietf.org/html/draft-donley-nat444-impacts-03http://tools.ietf.org/html/draft-donley-nat444-impacts-03http://www.ietf.org/rfc/rfc6269.txthttp://www.ietf.org/rfc/rfc6269.txthttp://tools.ietf.org/html/draft-boucadair-behave-bittorrent-portrange-02http://tools.ietf.org/html/draft-boucadair-behave-bittorrent-portrange-02https://datatracker.ietf.org/doc/draft-ietf-pcp-base/?include_text=1https://datatracker.ietf.org/doc/draft-ietf-pcp-base/?include_text=1http://code.google.com/p/androidsipservice/wiki/NatTraversalhttp://code.google.com/p/androidsipservice/wiki/NatTraversalhttp://www.v6summit.com/Conference/Presentations/APP&SERVICES_KESSEN.pdfhttp://www.v6summit.com/Conference/Presentations/APP&SERVICES_KESSEN.pdfhttp://www.v6summit.com/Conference/Presentations/APP&SERVICES_KESSEN.pdfhttp://code.google.com/p/androidsipservice/wiki/NatTraversalhttps://datatracker.ietf.org/doc/draft-ietf-pcp-base/?include_text=1http://tools.ietf.org/html/draft-boucadair-behave-bittorrent-portrange-02http://www.ietf.org/rfc/rfc6269.txthttp://tools.ietf.org/html/draft-donley-nat444-impacts-03