Package: tayga Version: 0.9.2-4 Severity: wishlist Tags: upstream ipv6 Dear Maintainer,
It would be nice to add CLAT support into tayga. Currently, it is mainly used for IPv6-only internal network to reach the IPv4 Internet. As ISPs begin to deliver IPv6-only mobile Internet, it is possible that user may want running IPv4-only apps on a Debian-powered mobile device connected to such a network. I have tried manually installing tayga on a client with only IPv6 Internet connectivity in a test environment, where the service provider has offered NAT64 at their gateway. The client is assigned a /64 which is routed from the service provider. Let me use the following as an example: Routed /56 (e.g. obtained from DHCPv6-PD): 2001:db8:0:ff00::/56 PLAT-NAT64: 2001:db8:ffff:ffff::/96 I then installed tayga on my client device, configured the IPv6 prefix to 2001:db8:ffff:ffff::/96, and no IPv4 prefix (because the IPv6 Internet cannot reach the IPv4-only private network behind the client). The addresses of tayga is set to 2001:db8:0:ff00::1, which is within the routed /56, and 172.16.0.1, which is a private IPv4 address. As I want the mapped IPv6 packet to go to the Internet (which in turn go through the PLAT), I commented out the default routes in /etc/init.d/tayga , and modified the configuration further later on. Because the client machine has no IPv4 addresses, I set the address of the nat64 interface to 172.16.0.2/30 and a default gateway to 172.16.0.1 after starting the daemon, by modifying the routes in /etc/init.d/tayga . This way, all outgoing IPv4 packets from the client will originate from 172.16.0.2 and pass through 172.16.0.1, at that point translated to IPv6 packets targeting 2001:db8:ffff:ffff::/96. However, in order to receive the return packet by the IPv4 application, I had to assign an additional IPv6 address to represent the IPv4 of the client, which was 2001:db8:0:ff00::2, also within the routed /56. It is NOT the IPv6 address of an interface, instead, it is routed into the nat64 interface. A static mapping of 2001:db8:0:ff00::2 <-> 172.16.0.2 was created in /etc/tayga.conf, which allowed the packet to return to 172.16.0.2 . I was able to traceroute to the IPv4 Internet after configuring the above, of course using real addresses instead of the above documentary addresses. However, manually doing so was tedious and error-prone. It will also be cumbersome when there is a lot of nodes in the private IPv4 subnet, as the above configuration only works for a single IPv4 host. Therefore, I suggest adding an option to set tayga into CLAT mode instead of PLAT mode. The details are follow: New option clat-prefix (optional) When set, tayga will work in CLAT instead of PLAT mode. When translating an IPv4 packet to an IPv6 packet, if the address is in the clat-ipv4-prefix, it will be translated into clat-prefix, otherwise, it will be translated into prefix as usual. In this case, prefix should be set to the provider NAT64 subnet, and clat-prefix should be set to a /96 routed to the client. Also, the ipv6-addr option, if not set, will be calculated using the clat-prefix instead of prefix. New option clat-ipv4-prefix (optional) It is meaningful only when clat-prefix is set. The addresses within this option are assigned to IPv4-only hosts behind the client. Those addresses enable IPv4 connectivity over IPv6 network by 464XLAT. Addresses in clat-ipv4-prefix will be translated using clat-prefix instead of prefix. If clat-prefix is set but clat-ipv4-prefix is not set, no IPv4 addresses will be translated to clat-prefix except static mappings, but IPv6 addresses within clat-prefix will still be translated to IPv4 prefix. IPv6 addresses in either prefix or clat-prefix will be directly translated to IPv4 over tayga, other IPv6 addresses will be translated using the dynamic-pool as usual. The dynamic-pool must not overlap with clat-ipv4-prefix, otherwise we don't know how to translate such addresses. To summarise the translation method, IPv4 -> IPv6 if in map, translate using it if in dynamic-pool, translate using it, reject the package if not found if in clat-ipv4-prefix, translate using clat-prefix otherwise, translate using prefix IPv6 -> IPv4 if in map, translate using it if in prefix or clat-prefix, translate using it otherwise, generate an IPv4 address in the dynamic pool. For example, the above configuration, under the above proposed configuration, will be configured as follows: ipv4-addr 172.16.0.1 prefix 2001:db8:ffff:ffff::/96 clat-prefix 2001:db8:0:ff00::/96 clat-ipv4-prefix 172.16.0.0/30 and create a dummy interface dummy0 with IPv4 address set to 172.16.0.2 . If there is a physical IPv4 local network behind the client, this step is omitted because the machine has already a working IPv4 address, and clat-ipv4-prefix is adjusted to hold all of the local network. That's all we should need. If we want the IPv6 Internet to access the IPv4 subnet behind the client, we may add a dynamic-pool, which must not overlap with clat-ipv4-prefix. In this case, the implicit ipv6-addr will be 2001:db8:0:ff00::172.16.0.1 because the ipv4-addr is located within the clat-ipv4-prefix. For example, if an IPv4 packet from 172.16.234.11 to 192.0.2.55 is routed into tayga, it will become 2001:db8:0:ff00::172.16.234.11 to 2001:db8:ffff:ffff::192.0.2.55 because the former is within the clat-ipv4-prefix which is translated using clat-prefix, but the latter is not therefore translated using prefix. The init script will then add the following into the IPv4 routing table: 0.0.0.0/0 dev nat64 172.16.0.1/32 dev nat64 (172.16.0.0/30 is already routed into the local IPv4 network) and the following into the IPv6 routing table: 2001:db8:0:ff00::/96 dev nat64 (note that 2001:db8:ffff:ffff::/96 is still routed to the public Internet) In this case, the IPv4 traffic from the application will go through 464XLAT to the IPv4 Internet. -- System Information: Debian Release: 7.8 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_HK.UTF-8, LC_CTYPE=en_HK.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_HK.UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages tayga depends on: ii libc6 2.13-38+deb7u8 tayga recommends no packages. tayga suggests no packages. -- Configuration Files: /etc/default/tayga changed [not included] /etc/tayga.conf changed [not included] -- no debconf information -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
