What is NAT44

If you go through IPv6 training material or blogs or whatever your source is, if you have run an ISP *on a constrained budget or dodn't have AFRINIC  [1]as an RIR to get routable addresses for all your users,then the NAT technology is something you might have had to deal with.

NAT has been very successful in delaying large scale IPv6 deployment. But the end is near.

NAT44 is on most slides I have come across as an IPv6 transition mechanism. I have to say for some slides I was preparing, I had to throw it in just so I can rant about it.

NAT44 also goes by the names:
CGN - Carrier Grade NAT
LSN - Large scale NAT and
NAT444 - which implies multiple two NAT44 layers

There's also a distinction between SP NAT44 and Residential NAT44. The key difference really is the implementation and NAT placement. the SP gets a large box to do NAT and calls it CGN/LSN.

Lets have a quick look at the differences:
Residential NAT44
would be deployed on a CPE,
SP NAT44
generally deployed on the SP side .
The end topology would look like the following:

CGN is NAT44 on the SP end, CPE's are also running NAT

So you'd have two RFC1918 addresses back to back. The idea is to extend the 1918 space as much as possible.  Prolong the pain if you may.

The deployment models are varied. There's a NAT on a stick model that eliminates NAT from the main data path and uses source-IP based routing - This has almost killed our network several times.

You also have an inline model that forces all traffic to use the NAT path. You get a single point of failure as bonus.

Reasons I agree with alot of people that this is not an ideal solution:

• The most easy to identify from the diagram above is conflicting address space between the customers and SP's. there's a draft proposal for shared address space that Im yet to read.
• A single level of NAT (NAT4?) was very prevalent, and it worked to a large extent. Applications won't be aware of the other tiers of NAT which will undoubtedly break a few things.
• Troubleshooting will be a mess. I mean how many NAT's are we to learn - NAT, NAT4, NAT44,NAT64 - dare I say I expect someone after using all v6 space to propose NAT666 
• Application developers will have a hard time predicting or trying to work in what technologies will be used to reach their content/run their apps.
• There will be contention for port pools. Remember some applications leverage multiple ports to speed things up, NAT will be doing the same which means some customers will definately notice 'slow internet'.
• Accountability and logging? forget it in NAT44.

A few reasons why it will most likely be adopted more for IPv6 transition:
- It is well understood - I think * I suspect the real culprit is the ease of deployment not a good understanding, Most network engineers have no idea how NAT affects applications and guys writing apps have no clue how the network affects their work. Some do, actually most do, they just dont seem to be running networks. They're made managers:-)
- Its easy to enforce policy
- cluelessness/laziness/low budget/misplaced priorities
- NAT44 devices on the client end wont require replacing.

Fact:
- This NAT44 thing will be installed, mostly the NAT on a stick model.
- Customers WILL be affected during  the IPv6 transition
- It is inevitable that someone somewhere will be forced to host their application on an IPv6 only site. I expect this to begin happening in the next 3 years.
- Worse, it is inevitable that some devices maybe for home automation, maybe some large scale rfid tags to track rhinos , whatever, some device somewhere will be deployed without an IPv4 option.
-Even worse or better, high chances are they wont be connecting to a typical enterprise network, most likely going to be a mobile network of sortes. 3g/edge/umts/lte/wimax.
- the last fact from me here is that not many people know what is happening. there are too many prevailing not necessarily agreeing views on IPv6/IPv4 depletion, transition mechanisms and the effects on the internet.  I get the feeling 'no one really knows'...I sure as hell don't, but read widely, listen, work with others...who knows what sort of enlightened state we'll be in later.

Funny
In this part of the world -kenya, most mobile operators especially at high management level still have 'heads in the sand' as far as IPv6 is concerned. Early adoption would probably benefit them the most.

1-AFRINIC is probably the only RIR today that still has V4 addresses to dish out to LIR's.
*I posit that this could create a false sense of security for african operators forgeting that most of their customers access content 'outside' Africa, if said content is switched to IPv6, we're done for and the sad thing is most network admins might not be ready to explain to 'the suits' higher up what the hell happened.

References:
*For any reference to an rfc, google for it or  head to the ietf site
•  “basic-nat44” (Reference [RFC 2663])
•  “napt44” (Reference [RFC 2663])
•  “stateful-nat64” (Reference [NAT64])
•  “stateless-nat64” (Reference [XLATE])
•  “basic-nat66” (same as basic-nat44 but for IPv6 family)
•  “basic-nat-pt” (Reference [NAPT])
•  “napt-pt” (Reference [NAPT])
•  “twice-nat44” (Reference [RFC2663])
•  “dynamic-nat44” (Dynamic SRC Address-only)
•  “stateless-nat66” (Reference [NAT66])
•  “napt66” (same as napt44 but for IPv6 family)

*A Juniper implementation guide
* a paper from nanog
* jeff doyles post over at network world