NAT444/CGN + Tunneled IPv6

IPv4 public addresses are already depleted in over half the world (Asia/Pac and EU/ME), and will soon be depleted in North America as well (perhaps by late 2014, early 2015). ISPs are dragging their heels in their transition to IPv6 because of cost and lack of skills and expertise (there are plenty of products to support it, and upstream IPv6 bandwidth is readily available). 

Many ISPs are desperately trying to keep IPv4 alive for just a little longer by deploying two layers of NAT44 - the one at the customer site (in their modem/router CPE) and a new one at the ISP. This is known as NAT444 (NAT44 followed by another NAT44), Carrier Grade NAT (CGN) or Large Scale NAT (LSN).

The key specification is in RFC 6264, "An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition", June 2011.

From the RFC:

Global IPv6 deployment was slower than originally expected.  As IPv4
address exhaustion approaches, IPv4 to IPv6 transition issues become
more critical and less tractable.  Host-based transition mechanisms
used in dual-stack environments cannot meet all transition
requirements.  Most end users are not sufficiently expert to
configure or maintain host-based transition mechanisms.  Carrier-
Grade NAT (CGN) devices with integrated transition mechanisms can
reduce the operational changes required during the IPv4 to IPv6
migration or coexistence period.

This document proposes an incremental CGN approach for IPv6
transition.  It can provide IPv6 access services for IPv6 hosts and
IPv4 access services for IPv4 hosts while leaving much of a legacy
ISP network unchanged during the initial stage of IPv4 to IPv6
migration.  Unlike CGN alone, incremental CGN also supports and
encourages smooth transition towards dual-stack or IPv6-only ISP
networks.  An integrated configurable CGN device and an adaptive home
gateway (HG) device are described.  Both are reusable during
different transition phases, avoiding multiple upgrades.  This
enables IPv6 migration to be incrementally achieved according to real
user requirements.

Some ISPs are deploying NAT444/CGN without any IPv6 support. This may temporarily relieve the lack of public IPv4 addresses needed for supporting new customers, but it does not advance IPv6 at all (which is the only viable long term solution to IPv4 depletion), and it introduces significant problems to the customer.

NAT44 involves a single NAT gateway from IPv4 to IPv4. An IPv4 packet going through NAT44 transits two regions of IPv4 - the public IPv4 space (from ISP to CPE) and an RFC 1918 private IPv4 space on the user's side of the NAT gateway in the CPE.

NAT444 involves two NAT44 gateways, from IPv4 to IPv4. An IPv4 packet going through NAT444 transits three regions of IPv4 - the public IPv4 space (from ISP native space to ISP CGN gateway), the ISP private space (from ISP CGN gateway to home gateway) and finally the user's private space (on the user's side of the home gateway). 

One problem with stacking NAT44 gateways like this is that NAT requires two non-overlapping address blocks on the two sides of the NAT gateway. You can do NAT44 from a public address (e.g. to a block of private addresses (e.g. 192.168/16). You can also do NAT44 from a private address (e.g. to a different block of private addresses (e.g. 192.168.2/24). However, the external private address cannot fall within the internal address block. So, you could not do NAT44 from to 192.168.1/24, or to 192.168/16.

When an ISP deploys CGN, no matter what private addresses they provide to customers, there could be conflicts for some users. Many home gateways use 192.168.1/24 by default, but not all do. And virtually all can be changed to any RFC 1918 address range. I use 172.20/16 (and occassionally 172.21/16) internally. No address in any of the RFC 1918 blocks (10/8, 172.16/12 or 192.168/16) are "safe" to use by the ISP. Because of this, yet another block, 100.64/10 has been allocated by IANA (per RFC 6598, "IANA-Reserved IPv4 prefix for Shared Address Space", April 2012) for use in CGN systems. It behaves exactly like the RFC 1918 address ranges, but may only be used by Internet Service Providers (to prevent conflicts such as those described above). This works out to addresses to, a total of 4,194,302 available addresses. So, if you check the external address of your NAT gateway, and it is either an RFC 1918 address, or anything that starts with 100.64 to 100.127, congratulations, you are behind a CGN. If you go to, you will still see a public address (not private or "shared"). However, that is one of the handful of public IPv4 addresses used by the CGN, and may be shared by many thousands of users, from many different organizations.

The function of each NAT44 stage is as described under Network Address Translation. The only difference is one in your network will have a private or "shared space" address on the external NIC, not a public address.

CGN is not a long term solution, and it introduces many problems:

  • You cannot host any publicly accessible server, even with Port Mapping.
  • You cannot obtain IPv6 via 6in4 or 6to4 tunnel
  • Various protocols may not work (VoIP, P2P games, IPsec, etc)
  • Someone has to pay for the massive logging of every address translation, with timestamps (gigabytes per user) and that someone will probably be you.

CGN does not solve the IPv4 address depletion problem. All ISPs will eventually have to go to IPv6. It just delays the transition for a little longer, while causing new problems. For the cost of deploying CGN, an ISP could deploy IPv6, so they are increasing their overall transition cost with no real benefit.

CGN equipment vendors are encouraging ISPs to buy and deploy this technology today, because they know they (or someone) will also be able to sell them IPv6 equipment later.

The standards clearly state that ISPs should not deploy CGN with just IPv4. It should be deployed with tunneled IPv6 as part of the package, so that customers can begin moving to IPv6, and will have a reliable NAT-less