IPv6 transition mechanisms

IPv6 transition mechanisms enable communication between devices that have only IPv4 addresses and devices that have only IPv6 address. They can also enable limited IPv4 top IPv4 communication over IPv6 only network connections. These translation mechanisms do the translation between IPv4 and IPv6 addresses.

Note:
  • The IPv6 transition mechanism feature is not supported on Virtual Engines.
  • Only one translation mode can be activated at a time.
  • In order to use these translation mechanisms Secure SD-WAN engine must have at least one IPv4 address and at least one IPv6 address.
  • Protocols with separate control and data or media connections and connections that use IPv4 or IPv6 addresses in the payload will not work through these translation mechanisms.
  • IPv6 prefixes used in the translations must not overlap with the engines own IPv6 addresses.
  • Translation in the transition mechanisms support only unicast communication.
  • Translated connections traverse through Secure SD-WAN as two separate connections. However, depending on the translation mode, either IPv4 or IPv6 packets to and from translation are handled without creating rules manually.
  • Use of translation can lead to Path MTU discovery related problems if there are any faults in the way the networks in the path work.

NAT64

NAT64 is a stateful IPv6 to IPv4 translation mechanism defined in RFC 6146. When NAT64 mechanism is activated, access rules that control traffic are made in the IPv6 side. IPv6 traffic with destination address matching the configured prefix will go to NAT64 translation. There is no need to create any rules for this traffic in the IPv4 access rules. All traffic configured to the IPv4 pool will go to translation.

Note:
  • NAT64 supports only unicast UDP, TCP, and ICMP traffic.
  • NAT64 can not be used with active-active clustering.
  • In the RFC 6877, NAT64 is referred as 464XLAT PLAT.
  • Due to RFC 6146 compliant NAT functionality, size of the IPv4 pool will set strict limit to maximum number of connections.
  • Due to RFC 6146 compliant NAT implementation, there will be additional connection state for the NAT processing.
  • Local IPv4 pool addresses must not overlap with the engines own addresses or NAT addresses used in IPv4 rules.

Configuration: See the section Engine Editor > Add-Ons > IPv6 Transition Mechanism.

464XLAT CLAT

Client side translation of RFC 6877. Used together with 464XLAT PLAT at the other edge of IPv6 only network in order to allow IPv4 traffic through IPv6 only network.

When used, local IPv4 addresses are detected based on the configured routing. Access rules controlling the traffic must be made in the IPv4 access rules. There is no need to create any rules for translated traffic in the IPv6 access rules. In the IPv4 side, traffic which does not have any route will be sent to translation. In the IPv6 side, the traffic from the remote IPv6 prefix to the local IPv6 prefix will be sent to translation.

Configuration: See the section Engine Editor > Add-Ons > IPv6 Transition Mechanism.

SIIT EAM

Stateless IPv4/IPv6 translation as defined in RFC 7757. When used without defining any explicit address mapping entries, same as SIIT, access rules controlling the traffic must be made in the IPv4 access rules.

There is no need to create any rules for translated traffic in the IPv6 access rules. In the IPv4 side, traffic which does not have any route will be sent to translation. In the IPv6 side, traffic which will have valid IPv4 route after translation are sent to translation.

Configuration: See the section Engine Editor > Add-Ons > IPv6 Transition Mechanism.