MAP66 (NAT from IPv6 to IPv6, NAT66) for Linux Sven-Ola T cke Freifunk 06-OCT-2010 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Table of Contents Installation DKMS integration Configuration Motivation These files implement a Linux netfilter target to change the IPv6 address of packets. The address change is done checksum neutral, thus no checksum re-calculation for the IPv6 packet is necessary. You can change the IPv6 source address of outgoing packets as well as the IPv6 destination address of incoming packets. This allows you to map an internal IPv6 address range to a second, externally used IPv6 address range. IPv6 address mapping is not very similar to IPv4 network address translation, but one can describe it as some sort of stateless NAT. The implmementation is based on the expired the IETF discussion paper published here: http://tools.ietf.org/html/draft-mrw-behave-nat66-02 Installation MAP66 implements two pieces of software: a shared library that extends the ip6tables command and a Linux kernel module. The shared library file adds the '-j MAP66' target to the ip6tables command. To build and install, you need ip6tables installed as well as the necessary headers. The Linux kernel module requires the Linux source file tree and Linux configuration files to compile. On a Debian/(EKU)buntu, the following command prepares the build environment: sudo apt-get install build-essential linux-headers iptables-dev Unpack the source tgz archive, change to the directory and issue "make" to build. If this compiles without errors, install the ip6tables extension with the following command: sudo make install Note The kernel module (ip6t_MAP66.ko for Linux-2.6 or ip6t_MAP66.o for Linux-2.4) is not automatically installed nor loaded into the kernel. You can copy the kernel module file manually, e.g. with sudo cp ip6t_MAP66.ko /lib/modules/$ (uname -r)/. DKMS integration If the next system update needs to install a new kernel version, you also need to re-compile/re-install the MAP66 kernel module. With Debian/(EKU)buntu, this can be automated with the Dynamic Kernel Module Support Framework (DKMS). For this, the dkms.conf file is included with the MAP66 source file package. Install DKMS with the following command: sudo apt-get install dkms Move/unpack the MAP66 source files below /usr/src and adapt the directory name to the version mentioned in the dkms.conf file. For example, issue "mkdir /usr/ src/ip6t_MAP66-0.3" and "cp * /usr/src/ip6t_MAP66-0.3/". To register the MAP66 source to DKMS and compile/install, issue these commands: sudo dkms add -m ip6t_MAP66 -v 0.3 sudo dkms build -m ip6t_MAP66 -v 0.3 sudo dkms install -m ip6t_MAP66 -v 0.3 Read DKMS details here: https://wiki.kubuntu.org/Kernel/Dev/DKMSPackaging Configuration Note for me: svn propedit svn:ignore. Note: on ubuntu, you need to enable prefer-family in /etc/wgetrc. after this e.g. "wget -O /dev/null http://ftp.se.debian.org" should connect to the IPv6 addrs of that server. /etc/gai.conf for wget --prefer-family=IPv6 -O - http://6to4.nro.net/ one needs ip6tables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu Mention --nocheck for speedup (if you do not expect the outer iface in the mapping range) Fieses zeugs: ein sixxs und ein 6to4. Kommt rein via sixxs, geht raus ueber 6to4 wenn ping von einem anderen 6to4-rechner (route hat 2002::/16)! Ping geht, ssh aber nicht == boinks kann evnt. mit TOS markiert werden und mit einer policyroute aussortiert. Brrr. Idea to think about: --salt 3b5b91c5a2 XOR client addresses for some more privacy Motivation My internet access at home is realized by a wireless community mesh network not owned by me. The mesh is operated with small embedded devices (nodes aka. WLAN routers) that are interconnected via radio links (WLAN IBSS / AdHoc). Routing is done with a specialized protocol such as Batman or OLSR. The routing protocol selects the nearest out of a dozen Internet gateways and configures a default route or an ipip tunnel accordingly. Each Internet gateway is connected to a different ISP and provides the service with the help of IPv4 network address translation (NAT). Using NAT has the following effects: ● Address amplification - something not necessary with IPv6 any more ● Anonymization - nice to have as an option but not mission critical ● ISP independance - no reverse routing, no "buy-a-number-range" The last point _is_ mission critical. One can use a provider independant IPv6 address range, but you need the cooperation of an ISP to use that address range for Internet connectivity. If you e.g. move to another ISP you need that address range to be re-routed to your new location. ISP independance is also possible with some tunneling technique, such as VPN or mobile IP. Tunneling can be implemented on client PCs and Internet gateways/ servers one day. But there is no need to implement the same tunneling technique on every mesh node. Why? Because the mesh nodes can use private IP adresses (or "ULA") to transport the tunnel data between the client PC and the gateway/ server. Each tunneling technique typically needs a single instance (the "server") which forms a single point of failure. Rule-of-thumb1: avoid a SPOF for the infrastructure. Rule-of-thumb2: KISS. Using private IP addresses on the mesh nodes has a drawback: mesh node software updates e.g. via http downloads from an Internet server is not possible. This is where I start to think: "hey, some kind of address mapping may be nice to have". While opening pandoras NAT66 box, I discovered that IPv6 nerds do not like the acronym. It is always a good tactic in infowars to rename, hence the name "MAP66". // Sven-Ola