Documentation > Introduction > What is SIIT/NAT64?

Introduction to IPv4/IPv6 Translation


  1. Introduction
  2. IPv4/IPv6 Translation
    1. SIIT with EAM
    2. SIIT (traditional)
    3. Stateful NAT64
    4. MAP-T


This document provides a general introduction to SIIT and NAT64.

It only focuses on what, exactly, IPv4/IPv6 translators do. If you’re more interested in down-to-earth setups which apply these ideas, try Defined Architectures.

IPv4/IPv6 Translation

SIIT (Stateless IP/ICMP Translation) and NAT64 (“NAT six four”, not “NAT sixty-four”) are technologies meant to communicate networking nodes which only speak IPv4 with nodes that only speak IPv6.

  • SIIT mangles packets, simply replacing IPv4 headers and IPv6 headers.
  • Stateful NAT64 (or “NAT64” for short) is a combination between an SIIT and a (theoretical) IPv6 NAT; the point is to mask several IPv6 nodes behind a few IPv4 addresses.

In their basic forms, SIIT only helps communicating nodes speaking different protocols, while NAT64 also helps with IPv4 address exhaustion (at the cost of being more computationally expensive and generally hindering end-to-end transparency).

Some people label SIIT as “Stateless NAT64”. We don’t, but we won’t bite if you do.

That’s all, really. Keep reading for more detail and examples.


This is the easiest one to explain. Consider the following setup:

Fig.1 - EAM sample network

(T stands for “Translator”.)

Assuming everyone’s default gateway is T, how do you communicate A (IPv6) with V (IPv4)?

  • You tell T, “The IPv4 address of A should be, and the IPv6 address of V should be 2001:db8:4::16”.
  • You tell A, “V’s address is 2001:db8:4::16”.
  • You tell V, “A’s address is”.

This will happen:

Fig.2 - EAM flow

The translator is “fooling” each node into thinking the other one can speak their language.

“EAM” stands for “Explicit Address Mapping”, and is more versatile than simply binding arbitrary addresses to other arbitrary addresses. See the EAM RFC or our summary of it for more information.

SIIT (traditional)

The basic form of SIIT is more constrictive. As a consequence, we need to change the sample IPv6 network:

Fig.3 - Vanilla sample network

The idea is to simply remove a prefix while translating from IPv6 to IPv4, and append it in the other direction:

Fig.4 - Vanilla flow

Of course, this means each node’s IPv4 address has to be encoded inside its IPv6 address, which is a little annoying.

While this explanation might make it seem like “EAM” SIIT and “traditional” SIIT are different things, this is not the case. Implementations are expected to always try to translate an address based on the EAM table first, and if no mapping is found, fall back to append or remove the prefix. The separation was done here for illustrative purposes only.

SIIT is defined by RFC 7915. The address translation hack has more ways to embed the IPv4 address not shown here, and is fully defined by RFC 6052. Whenever RFC 6052 is involved, it’s usually convenient to also have a DNS64 so users don’t need to be aware of the prefix.

SIIT-DC is an architecture that uses both SIIT “modes” in concert to achieve a scalable IPv4/IPv6 coexistence setup for Data Centres.

Stateful NAT64

This mode is more akin to what people understand as “NAT” (though, more specifically, it’s NAPT). As such, allow me to remind you the big picture of how (stateful) NAT operates:

Fig.5 - NAT sample network

The left network is called “Private” because it uses addresses unavailable in the global Internet. To make up for this, NAT mangles packet addresses so outsiders think any traffic started by the private nodes was actually started by itself:

Fig.6 - NAT flow

As a result, for outside purposes, nodes A through E are “sharing” NAT’s global address (or addresses).

The price of being able to condense the addresses of several nodes into the ones from a single one is state. The address of the hidden node is completely deleted from the packet, therefore NAT has to remember it so it can tell who the answer should be forwarded to.

These are two drawbacks that should be considered:

  • The mappings/masks are limited by availability (transport addresses) and/or memory. In other words, NAT is a potential DoS attack victim.
  • V cannot start a packet stream to A, because NAT cannot infer a destination from a packet that hasn’t been previously masked (and therefore, can’t be remembered). NAT assumes most communication will be started from the private network.

Stateful NAT64 is pretty much the same. The only difference is that the “Private Network” is actually an IPv6 network:

Fig.7 - Stateful network

This is what you tell to each node:

  • A needs to think V’s address is 64:ff9b::
  • T needs a function that will use its own addresses to mask A, and also pretend that the IPv4 Internet is a network named 64:ff9b::/96.
  • V thinks it’s talking to T, so it doesn’t need any unusual tweaking.

Fig.8 - Stateful flow

Now, that’s where the similarities with NAT end. You don’t normally say the IPv6 network is “Private”, because the whole point is that it should also be connected to the IPv6 Internet:

Fig.9 - Stateful Internet

In this way, A through E are IPv6-only nodes, but they have access to both Internets (the IPv6 one via router R, and the IPv4 one via T).

Stateful NAT64 is defined by RFC 6146 and is most of the time coupled with DNS64.