TAYGA FAQ

Back to main page

Pre-installation

Q1.1. What, exactly, does TAYGA do?

TAYGA is a daemon that performs translation of packets between IPv4 and IPv6. Officially, this is called "Stateless IP/ICMP Translation (SIIT)" and is described in draft-ietf-behave-v6v4-xlate. Unofficially, this is known as NAT64, but the comparison to traditional Network Address Translation (NAT) can cause confusion.

TAYGA is not:

Q1.2. Can I use TAYGA to connect my IPv6 hosts to the IPv6 Internet?

TAYGA only handles translation to and from IPv4. It cannot be used to create connectivity between an IPv6-enabled site and IPv6 servers on the wider Internet.

The IPv6 Internet is, conceptually, a separate global network from the IPv4 Internet. Your organization will need to establish an upstream link to the IPv6 Internet which operates in parallel to your existing IPv4 upstream link.

Fortunately, there is no need to purchase separate physical infrastructure. If your upstream provider supports IPv6 natively, you can request that they enable IPv6 on your existing IPv4 link, and both protocols can share the same line. If your upstream provider does not support IPv6, you can create an IPv6-in-IPv4 tunnel (similar to a VPN) to a free tunnel broker such as Hurricane Electric or SixXS.

Q1.3. I don't want to roll out IPv6 on my internal network; I just want to IPv6-enable my border router and use NAT to give my internal clients access to the IPv6 Internet. Can TAYGA do this?

No. What you're looking for doesn't really exist.

Some network "experts" have asserted that there is no need for organizations to migrate their internal networks to IPv6, and suggest that it is possible to use NAT to give IPv4-only clients access to the IPv6 Internet. These experts generally decline to describe the technical means as to how this could be accomplished, instead advising readers to wait for their equipment vendors to come up with the solution.

It is technically impossible for a translation system operating purely at the IP layer to allow IPv4 hosts to establish connections to any arbitrary IPv6 server. Such a system would need to represent every IPv6 server on the Internet with a unique IPv4 address, which is clearly infeasible given the size of the IPv6 address space.

A number of years ago the IETF attempted to standardize a system called NAT-PT that used a DNS translation function to assign temporary IPv4 addresses to IPv6 servers, giving the appearance of full, bi-directional communication between IPv4 and IPv6. It is perhaps this standard to which the experts above were referring. However, NAT-PT was found to be fundamentally flawed and too fragile to use in a production environment, so the IETF deprecated it in 2007.

The only known method for reliably giving IPv4-only clients access to the IPv6 Internet is with application-level proxies, e.g. Squid for HTTP traffic.

Installation

Q2.1. Which distributions is TAYGA included in?

TAYGA 0.9.1 was added to the Debian testing repository on 2011-04-10.

If you are a maintainer for a distribution and need help packaging TAYGA, please email.

Q2.2. Is TAYGA 64-bit-safe? Big-endian- and little-endian-safe?

Yes.

Configuration and Running

Q3.1. Why does TAYGA need its own IPv4 and IPv6 addresses?

When TAYGA is unable to translate a packet (for example, if the destination address is invalid), it must send an ICMP error to the packet sender. TAYGA places its own IP address in the source-address field of the ICMP error packet to identify that the error was generated by TAYGA.

For diagnostic purposes, TAYGA will also respond to ICMP echo requests (pings) destined to its IP addresses.

Q3.2. Can TAYGA share the same IP addresses with the host it runs on?

It is very much not recommended. Linux hosts are known to behave poorly in the presence of duplicate IP address assignments. If you're a Linux networking guru you might get this to work, but otherwise it's an invitation for bizarre problems, some of which may not be immediately apparent.

Q3.3. What addresses should I assign to the nat64 TUN interface?

You can use any addresses that are assigned to your router's other network interfaces, or you can use new addresses that you have allocated specifically for this purpose.

Note that if you use addresses from a different interface, you MUST NOT add a prefix length to the address when configuring it on the nat64 interface.

Example of correct configuration:

# ip addr add 192.168.0.1 dev nat64
# ip addr add 2001:db8:1::1 dev nat64

Example of wrong configuration:

# ip addr add 192.168.0.1/24 dev nat64
# ip addr add 2001:db8:1::1/64 dev nat64

Q3.4. I didn't configure any addresses at all on the nat64 interface and it seems to work. Is this okay?

If you don't configure addresses on your nat64 interface, you may encounter subtle problems with ICMP errors. If the Linux host needs to emit an ICMP error out of the nat64 interface, it will arbitrarily choose a source address from another interface or it may completely suppress the error. This could cause problems with path MTU discovery, among other issues.

Explicitly configuring an IPv4 address and an IPv6 address on the nat64 interface is the best way to ensure proper ICMP functionality.