IPv6 Network - Manually Configured Tunnels and NAT
Manually configured tunnels themselves can deal with Network Address Translation (NAT) without problems if the configuration on both ends is changed to reflect the idea each end has about its own address and the remote end’s address. For instance, let’s assume a tunnel between 192.0.2.1 and 223.224.225.226. Now the host that used to have the address 223.224.225.226 is moved behind a NAT and given the new (private) address 10.0.0.203. The old address is given to the NAT box. To keep the tunnel working, the configuration on the host behind the NAT box must now reflect that it has a private address, so the tunnel source becomes 10.0.0.203. But the configuration on the other host remains the same.

However, many NAT implementations can deal with only TCP and UDP and fail to handle IP packets with a protocol 41 payload. A larger class of NATs can handle forwarding protocol 41 packets toward a fixed internal address, which would of course be the host that’s the local tunnel endpoint. This configuration item is often called “default host,” or “DMZ.” A small class of NATs can handle IPv6-in-IPv4 tunneling without any configuration. Unfortunately, there is no good way to find out what kind of NAT is implemented in a particular device other than just seeing what happens. It’s better to set up the default host or DMZ anyway, as otherwise the NAT limitation that external systems can’t initiate communications toward internal systems also applies to the tunneled IPv6 connectivity. But the effect is slightly different than in IPv4: when an internal system connects to the outside world over IPv6, the appropriate NAT state is set up so that incoming tunnel packets are delivered to the system that terminates the tunnel.

External systems can now connect to internal systems. When the tunnel is idle for some time, the NAT removes the mapping, and after that, systems elsewhere on the Internet can no longer reach IPv6 systems behind the tunnel that crosses the NAT device. You can solve this by periodically generating some traffic over the tunnel, for instance, by starting a one-packet ping to a remote system from the cron every minute. Very much the same thing happens when there is a stateful IPv4 filter that allows incoming protocol 41 packets only after there have been outgoing protocol 41 packets.

Comment an article   Name   E-mail    Title Available characters: 600 Enter what you see:

No comment posted