NAT, PAT, What ?!: Part 2: IPv6 and NAT

 

 Some weeks ago in Linked-In there were a discussion about NAT and IPv6 and one of the engineer meant that as the IPv6 standard does not define NAT and PAT,  using NAT and/or PAT on IPv6 is not a good way of implementation.

Now VMware SD-WAN also has full IPv6 support in Underlay and Overlay it uses NAT and specifically SNAT also with IPv6

The implemented IPv6 NAT features are:

  • Default NAT66 on VCG 
  • DIA NAT66 at edge (Many-to-one)
  • 1:1 NAT66 and Port Forwarding
  • Policy NAT66 on Edge and VCG
  • SNAT66 when forwarding to Internet-Underlay


And in my opinion this is a valid and sound decision.

 

But let's look at possible alternative solutions to NAT in IPv6.

The standard defines a kind of Souce Routing with the use of the 

IPv6 Routing Header 

to force traffic via specific intermediate hops.


 

Unfortunately that method outside a Provider Segment routing environment, where a slightly different Header is used, is a very bad idea from the security point of view. The mechanism is an equivalent to the IPv4 Source-Routing which due to security reasons is mostly forbidden and blocked. 

Else ?

The only other method which comes to my mind is 

LISP (Locator/Identifier Separation Protocol).


 

This protocol, developed and for some years pushed by Cisco is quite mighty and by using the gateway address as Locator and the original IPv6 address as Identifier also return traffic could be routed via Gateway. However that protocol needs some specific infrastructure like a Mapping Server (MS) and a Map Resolver (MR) which is typically not implemented neither in SD-WAN nor in the Internet.

So therefore a classical NAT or PAT is the only way to force a return path also in IPv6 communication.

Comments

Popular posts from this blog

Orchestrator Upgrade to Version 5.2

Deep Dive on DMPO and its Performance Features (available and missing) Part 1

Deep Dive on DMPO and its Performance Features (available and missing) Part 2