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.


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.


3/17

3


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.


4/17

4


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


5/17

5


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


6/17

6


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/17

7


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


8/17

8


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.


9/17

9


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.


10/17

10


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


11/17

11


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.


12/17

12


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.


13/17

13


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.


14/17

14


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


15/17

15


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 :


16/17

16


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


17/17

17


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

carrier grade nat - tec study paper-ver2

Documents