All interoperability techniques are a combination of the following :

Framing the problem (cf RFC6180)

The problem space is huge ! But you can reduce it to a combination of the following topologies.

Network_Ipv46_Topologies.svg

Stateless or stateful translation (cf RFC6145) ?

Stateless is of course better in terms of scalability (faster header conversion and less memory on router).

Note tunneling often needs no state since the packet carries both address types.

Tunneling considerations

RFC4213 forbids a tunnel encapsulator to accept a client large IPv6 packet and fragment it if the IPv4 MTU of the tunnel is lower.

Otherwise communication will be brittle since the decapsulator may NOT support fragment aggregation (breaks the Postel law)

Without adequate security policies, tunneling can bypass firewalls as follows :

Network_Tunnel_Spoofing.svg

DNS considerations

For nodes in IPv4/6 only networks behind a NAT you may need to use a proxy DNS to provide the appropriate A or AAAA records. This will break DNSSEC and breaks user choice.

Some well known interoperability recipes

RFC6333: Dual stack lite

Allows ISP to have a IPv6 core network but still provide IPv4 connectivity with a limited pool of IPv4 addresses.

Network_Ds_Lite.svg

RFC3056: 6to4 (similar to 6rd)

Allows tunneling over the IPv4 internet without any static configuration. It works by embedding the tunnel endpoints IPv4 address into the peer IPv6 address.

Network_6to4.svg

IPv6 rapid deployment is based on the same ideas but it uses the ISP assigned prefix instead of 2002::/16 and keeps tunnel endpoints inside the ISP network (not to rely on others to correctly configure their tunnels).

Many, many more ….

Be careful it is a trap ! 6in4 != 6to4 != 6over4