Menu
▾
▴
Tree [r68] / History
| File | Date | Author | Commit |
|---|---|---|---|
| LICENSE | 2010-10-01 | sven-ola | [r1] Transfer from freifunk-firmware to new SF project |
| Makefile | 2013-05-03 | sven-ola | [r61] Small change for dpkg-buildpackage |
| README.dbk | 2013-09-05 | sven-ola | [r68] Beautified ip6tables -nvL, bumped version to 1.0 |
| README.html | 2013-09-05 | sven-ola | [r68] Beautified ip6tables -nvL, bumped version to 1.0 |
| README.txt | 2013-09-05 | sven-ola | [r68] Beautified ip6tables -nvL, bumped version to 1.0 |
| TODO | 2010-10-18 | sven-ola | [r55] |
| dkms.conf | 2013-09-05 | sven-ola | [r68] Beautified ip6tables -nvL, bumped version to 1.0 |
| ip6t_MAP66.c | 2013-08-31 | sven-ola | [r66] Bumped version to 0.7, fixed error with all ker... |
| ip6t_MAP66.h | 2013-05-02 | sven-ola | [r60] |
| libip6t_MAP66.c | 2013-09-05 | sven-ola | [r68] Beautified ip6tables -nvL, bumped version to 1.0 |
Read Me
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>MAP66 (NAT from IPv6 to IPv6, NAT66) for Linux</title><meta name="generator" content="DocBook XSL Stylesheets V1.76.1" /></head><body><div class="article" title="MAP66 (NAT from IPv6 to IPv6, NAT66) for Linux"><div class="titlepage"><div><div><h2 class="title"><a id="idp61384"></a>MAP66 (NAT from IPv6 to IPv6, NAT66) for Linux</h2></div><div><div class="author"><h3 class="author"><span class="firstname">Sven-Ola</span> <span class="surname">Tuecke</span></h3><div class="affiliation"><span class="orgname">Freifunk<br /></span></div></div></div><div><p class="pubdate">05-MAY-2013</p></div></div><hr /></div><div class="toc"><p><strong>Table of Contents</strong></p><dl><dt><span class="section"><a href="#install">Installation</a></span></dt><dt><span class="section"><a href="#dkms">DKMS Integration</a></span></dt><dt><span class="section"><a href="#config">Configuration</a></span></dt><dd><dl><dt><span class="section"><a href="#config-brief">Brief Version</a></span></dt><dt><span class="section"><a href="#config-detailed">Detailed Version</a></span></dt><dt><span class="section"><a href="#idp63576">Mapping Single Address</a></span></dt><dt><span class="section"><a href="#idp65128">Swapping Prefix with Hostbits</a></span></dt></dl></dd><dt><span class="section"><a href="#precedence">IPv6/IPv4 Precedence</a></span></dt><dd><dl><dt><span class="section"><a href="#precedence-gai">Change gai.conf</a></span></dt><dt><span class="section"><a href="#precedence-addrs">Use Changed Internal Address</a></span></dt></dl></dd><dt><span class="section"><a href="#motivation">Motivation</a></span></dt></dl></div><p>These files implement a Linux netfilter target that changes the IPv6
address of packets. The address change is done checksum neutral, thus no
checksum re-calculation for the 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 implementation is based on the expired IETF
discussion paper published here:</p><p><a class="ulink" href="http://tools.ietf.org/html/draft-mrw-behave-nat66-02" target="_top">http://tools.ietf.org/html/draft-mrw-behave-nat66-02</a></p><div class="warning" title="Warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>Using MAP66 rules together with connection tracking rules such as
<strong class="userinput"><code>--ctstate</code></strong> is currently untested and may not work or
may cause dysfunctions.</p></div><div class="section" title="Installation"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="install"></a>Installation</h2></div></div></div><p>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
kernel configuration files to compile. On a Debian / Ubuntu, the following
command prepares the build environment:</p><pre class="programlisting">sudo apt-get install build-essential linux-headers iptables-dev</pre><p>Unpack the source tgz archive below <code class="filename">/usr/src</code>,
change to the new sub-directory and issue "make" to build. If this
compiles without errors, install the ip6tables extension with the
following command:</p><pre class="programlisting">sudo make install</pre><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>The kernel module (<code class="filename">ip6t_MAP66.ko</code> for
Linux-2.6 or <code class="filename">ip6t_MAP66.o</code> for Linux-2.4) is not
automatically installed nor loaded into the kernel. You can copy the
kernel module file manually, e.g. with <strong class="userinput"><code>sudo cp ip6t_MAP66.ko
/lib/modules/$(uname -r)/</code></strong>.</p></div></div><div class="section" title="DKMS Integration"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="dkms"></a>DKMS Integration</h2></div></div></div><p>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 /
Ubuntu, this can be automated with the Dynamic Kernel Module Support
Framework (DKMS). For this, the <code class="filename">dkms.conf</code> file is
included with the MAP66 source file package. Install DKMS with the
following command:</p><pre class="programlisting">sudo apt-get install dkms</pre><p>If not already in place, move/unpack the MAP66 source file archive
below <code class="filename">/usr/src/</code>. To register the MAP66 source to DKMS
and compile/install, issue these commands:</p><pre class="programlisting">sudo dkms add -m ip6t_MAP66 -v 1.0
sudo dkms build -m ip6t_MAP66 -v 1.0
sudo dkms install -m ip6t_MAP66 -v 1.0</pre><div class="tip" title="Tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3><p>Read DKMS details here: <a class="ulink" href="Read DKMS details here: https://wiki.kubuntu.org/Kernel/Dev/DKMSPackaging" target="_top">https://wiki.kubuntu.org/Kernel/Dev/DKMSPackaging</a>.
Also, there's a pre-packed binary with DKMS for Debian / Ubuntu hosted
on my packet repository: <a class="ulink" href="Read DKMS details here: https://wiki.kubuntu.org/Kernel/Dev/DKMSPackaging" target="_top">http://sven-ola.dyndns.org/repo/</a>.</p></div></div><div class="section" title="Configuration"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="config"></a>Configuration</h2></div></div></div><div class="section" title="Brief Version"><div class="titlepage"><div><div><h3 class="title"><a id="config-brief"></a>Brief Version</h3></div></div></div><p>You always need to add two ip6tables-rules to your netfilter
configuration. One rule matches outgoing packets and changes their IPv6
source address. The second rule matches incoming packets and reverts the
address change by altering their IPv6 destination address. To following
commands correspond to the <span class="quote">“<span class="quote">Address Mapping Example</span>”</span> given
in the IETF discussion paper:</p><pre class="programlisting">ip6tables -t mangle -I POSTROUTING -o eth0 -s FD01:0203:0405::/48 -j MAP66 --src-to 2001:0DB8:0001::/48
ip6tables -t mangle -I PREROUTING -i eth0 -d 2001:0DB8:0001::/48 -j MAP66 --dst-to FD01:0203:0405::/48</pre><p>This example is also printed to the screen if you issue
<strong class="userinput"><code>ip6tables -j MAP66 --help</code></strong>. By design, you cannot
use an arbitrary prefix length. Only /112, /96 .. /16 are supported,
because the MAP66 kernel module checksum re-calculation is made with
16-bit integers.</p><p>For each packet, the MAP66 kernel module also compares the
packet's source address to all IPv6 addresses assigned to the outgoing
interface. If a match is found, the packet's source address is not
mapped. The same comparison happens on the incoming packet's destination
address. The comparison requires some CPU resources, especially if the
interface has a large number of assigned IPv6 addresses. If you are sure
that the mapping cannot match the IPv6 address of the interface (e.g.
the mapping rule defines a mapping prefix that cannot result in the
interface address) you can switch off the comparison. Add the
<strong class="userinput"><code>--nocheck</code></strong> parameter to the ip6tables command
for this.</p></div><div class="section" title="Detailed Version"><div class="titlepage"><div><div><h3 class="title"><a id="config-detailed"></a>Detailed Version</h3></div></div></div><p>The following explanation details a living example from the
wireless mesh network that is mentioned under <a class="xref" href="#motivation" title="Motivation">Motivation</a> (see below).
Throughout the mesh network, a private IP address range is used. The ULA
prefix is fdca:ffee:babe::/64. All mesh nodes derive their IPv6
interface addresses by correlating the ULA prefix with the EUI48
(<span class="quote">“<span class="quote">MAC address</span>”</span>) of the respective network adapter.</p><p>There is a Debian based virtual machine that should act as one
IPv6 Internet gateway for the mesh. You can reach the virtual machine's
web service via IPv4 under <a class="ulink" href="http://bbb-vpn.freifunk.net" target="_top">http://bbb-vpn.freifunk.net</a>.
To experiment with IPv6, a <a class="ulink" href="http://www.sixxs.net/" target="_top">SIXXS</a> static tunnel setup has been
added. The following <code class="filename">/etc/network/interfaces</code> file
provides the configuration for IPv6:</p><pre class="programlisting">auto sixxs
iface sixxs inet6 v4tunnel
address 2001:4dd0:ff00:2ee::2
netmask 64
local 77.87.48.7
endpoint 78.35.24.124
ttl 64
up ip link set mtu 1280 dev $IFACE
up ip route add default via 2001:4dd0:ff00:2ee::1 dev $IFACE
up ip addr add 2001:4dd0:fe77:ffff::1/48 dev $IFACE</pre><p>As you can see, the virtual machine has an IPv6 prefix of
2001:4dd0:fe77::/48. The /48 prefix length includes 65536 /64 subnets
where this setup occupies the <span class="quote">“<span class="quote">ffff</span>”</span> subnet. The machine is
therefore reachable via <a class="ulink" href="http://[2001:4dd0:fe77::1]/" target="_top">http://[2001:4dd0:fe77:ffff:1]/</a>.
The netfilter setup of this machine is initialized with some basic
precautions. The <span class="quote">“<span class="quote">-j ACCEPT</span>”</span> rules prevents any further
matching on the POSTROUTING chain for local network packets. Most
notably, we also block packets that leave the machine on the receiving
interface so we cannot participate as a <span class="quote">“<span class="quote">reflector</span>”</span> in DDOS
with the <strong class="userinput"><code>--dst-swap</code></strong> option used below.</p><pre class="programlisting">ip6tables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
ip6tables -t mangle -A POSTROUTING -o sixxs -s 2001:4dd0:fe77::/48 -j ACCEPT
ip6tables -t mangle -A POSTROUTING -o sixxs -s 2001:4dd0:ff00:2ee::/64 -j ACCEPT
ip6tables -t filter -A FORWARD -i sixxs -o sixxs -j DROP</pre><div class="tip" title="Tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3><p>You may also stumble over the MSS-clamping rule. While IPv6
defines, that path MTU detection via ICMPv6 must be supported by any
host, sometimes path MTU detection does not work. The SIXXS tunnel
uses an MTU of 1280 byte. To get the following command working on my
PC, I needed to add the above MSS-clamping rule on the gateway:
<strong class="userinput"><code>wget --prefer-family=IPv6 -O -
http://6to4.nro.net/</code></strong>.</p></div><p>The netfilter setup then includes the following command sequence
to realize mapping from the private fdca:ffee:babe::/64 prefix to the
globally valid IPv6 addresses and vice versa. </p><pre class="programlisting">ip6tables -t mangle -A POSTROUTING -o sixxs -s fdca:ffee:babe::/64 \
-j MAP66 --src-to 2001:4dd0:fe77:100::/64 --nocheck
ip6tables -t mangle -A PREROUTING -i sixxs -d 2001:4dd0:fe77:100::/64 \
-j MAP66 --dst-to fdca:ffee:babe::/64 --nocheck</pre><p>Because for these IPv6 networks the external prefix length (/64)
is smaller than the internal prefix length (/48), we are sure that
mapped addresses cannot match the interface address. For example:
2001:4dd0:fe77:100::/64 cannot be mapped / converted to
2001:4dd0:fe77:ffff::1 in this context. For this reason, we can use the
<strong class="userinput"><code>--nocheck</code></strong> speedup here.</p></div><div class="section" title="Mapping Single Address"><div class="titlepage"><div><div><h3 class="title"><a id="idp63576"></a>Mapping Single Address</h3></div></div></div><p>As an extension, the <strong class="userinput"><code>--csum</code></strong> option
updates the packet's checksum instead of updating some of the IP address
bits. This only works for some of the transported protocols (TCP, UDP,
ICMP6, DCCP) because each protocol uses another offset for storing the
checksum.</p><p>This option can be used to map exactly one IPv6 address to
another, hence using --src-to or --dst-to with /128.</p></div><div class="section" title="Swapping Prefix with Hostbits"><div class="titlepage"><div><div><h3 class="title"><a id="idp65128"></a>Swapping Prefix with Hostbits</h3></div></div></div><p>In our mesh network, we have routers with old and new firmwares.
While the old firmware uses a single /64 ULA prefix for all nodes and
interfaces, the new firmware uses an arbitrary /64 prefix derived from
the default route address. The new firmware always use ::1 for the host
bits, e.g. 2002:abcd:efgh:xxxx::1/64 if the neighbour's default route is
via 6to4, or fdca:ffee:babe:xxxx::1/64 if the neighbour's default route
is via ULA. Anyhow, those routers <span class="quote">“<span class="quote">waste</span>”</span> 64 bits of
address space because of the fixed host bits.</p><p>To map those arbitrary prefixes to the prefix used on the Internet
gateway, we therefore can swap net bits with host bits and map the
result to the gateway's prefix. Example: if a mesh node uses
2002:1234:5678:9abc::1/64 we can map this to
2001:4dd0:fe77:1:2002:1234:5678:9abc/64 and send to / receive from the
Internet. For this, MAP66 support <strong class="userinput"><code>--src-swap</code></strong> and
<strong class="userinput"><code>--dst-swap</code></strong> options. Here's the working
example:</p><pre class="programlisting">ip6tables -t mangle -A POSTROUTING -o sixxs \
-m u32 --u32 "0x08 & 0xe0000000 = 0x20000000 && 0x10 = 0 && 0x14 & 0xffffff00 = 0" \
-j MAP66 --nocheck --src-swap --src-to 2001:4dd0:fe77::/48
ip6tables -t mangle -A POSTROUTING -o sixxs \
-m u32 --u32 "0x08 & 0xfe000000 = 0xfc000000 && 0x10 = 0 && 0x14 & 0xffffff00 = 0" \
-j MAP66 --nocheck --src-swap --src-to 2001:4dd0:fe77::/48
ip6tables -t mangle -A PREROUTING -i sixxs \
-m u32 --u32 "0x18 = 0x20014dd0 && 0x1c & 0xffffff00 = 0xfe770000 && 0x20 & 0xe0000000 = 0x20000000" \
-j MAP66 --dst-swap --dst-to 0::/48 --nocheck
ip6tables -t mangle -A PREROUTING -i sixxs \
-m u32 --u32 "0x18 = 0x20014dd0 && 0x1c & 0xffffff00 = 0xfe770000 && 0x20 & 0xfe000000 = 0xfc000000" \
-j MAP66 --dst-swap --dst-to 0::/48 --nocheck</pre><p>The above example uses the xtables u32 match to filter out packets
with IPv6 addresses that uses host bits containing ULA (fc00::/7) or
IANA Internet (2000::/3).</p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>Swapping / rotating 16 bit integers within IP packet headers is
checksum neutral by design. Also, swapping / rotating 8 bit integers
can be compensated with the following formula: <strong class="userinput"><code>addr[w] =
add16(addr[w], add16(oldpartialcsum,
~byteswap(oldpartialcsum)))</code></strong>.</p></div></div></div><div class="section" title="IPv6/IPv4 Precedence"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="precedence"></a>IPv6/IPv4 Precedence</h2></div></div></div><p>With Ubuntu and eventually with RedHat, you will notice that your
browser does not show the IPv6 version of a web site that is multi-homed
when using ULA addresses for your IPv6 Internet connection. The reason for
this is an add on to the RFC 3484 rules that is compiled into the Ubuntu
libc. The pre-installed <code class="filename">/etc/gai.conf</code> file will give
you a hint on this.</p><p>In short: the getaddrinfo() library function rates a private IPv4
address higher than the ULA IPv6 address when choosing the transport
protocol for a new Internet connection if this add on to the RFC 3484
rules is compiled in. For this reason, you may want to change the
precedence rules within <code class="filename">/etc/gai.conf</code> (see <a class="xref" href="#precedence-gai" title="Change gai.conf">Change gai.conf</a>) or use another
prefix (see <a class="xref" href="#precedence-addrs" title="Use Changed Internal Address">Use Changed Internal Address</a>).</p><div class="section" title="Change gai.conf"><div class="titlepage"><div><div><h3 class="title"><a id="precedence-gai"></a>Change gai.conf</h3></div></div></div><p>The getaddrinfo() library function manages lists of label,
precedence, and scope4 type entries. If the
<code class="filename">/etc/gai.conf</code> file does not provide a single entry
for a particular type, the compiled-in list is used. For this reason,
you cannot uncomment a single entry to overwrite the default. You need
to uncomment all entries of a particular type for this. The
<span class="quote">“<span class="quote">label</span>”</span> lines compare source addresses, the
<span class="quote">“<span class="quote">precedence</span>”</span> lines compare destination addresses.</p><div class="procedure" title="Procedure 1. Change IPv6 Precedence"><a id="idp77320"></a><p class="title"><strong>Procedure 1. Change IPv6 Precedence</strong></p><ol class="procedure" type="1"><li class="step" title="Step 1"><p>Open the <code class="filename">/etc/gai.conf</code> file as root user,
e.g. by executing <strong class="userinput"><code>sudo nano
/etc/gai.conf</code></strong>.</p></li><li class="step" title="Step 2"><p>Remove the leading hash character from the 8 lines starting
with <span class="quote">“<span class="quote">#label</span>”</span>.</p></li><li class="step" title="Step 3"><p>Re-add the hash character to the line stating <span class="quote">“<span class="quote">#label
fc00::/7 6</span>”</span>.</p></li><li class="step" title="Step 4"><p>Save the file.</p></li><li class="step" title="Step 5"><p>Restart your browser and re-try to browse to a multi-homed web
site.</p></li></ol></div><p>The above procedure removes the difference between standard IPv6
source addresses and ULA type private IPv6 source addresses. Anything
else is unchanged.</p></div><div class="section" title="Use Changed Internal Address"><div class="titlepage"><div><div><h3 class="title"><a id="precedence-addrs"></a>Use Changed Internal Address</h3></div></div></div><p>As an alternative solution, you may use an arbitrary address
prefix in your LAN that is not mentioned in the
<code class="filename">gai.conf</code> file nor compiled in. This will work but
introduces a double mapping: one map (Inet-ULA) on the Internet gateway
router and a second map (ULA-Intern) on the internal router.</p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>While the well known IPv4 addresses 10.0.0.0/8, 172.16.0.0/12,
and 192.168.0.0/16 still exist, it is unlikely that their 6to4
counterparts 2002:0a00::/24, 2002:ac10::/28, and 2002:c0a8::/32 will
be routed on the Internet. Sadly, the Ubuntu defaults penalize 6to4
addresses also.</p></div><p>If you already deployed ULA addresses in your network, you may be
interested in a solution that runs on my Freifunk router. The router
uses the IPv6 prefix that is reserved for documentation purposes on it's
LAN interface. Within the OLSR-based mesh network, any interface uses an
fdca:ffee:babe::/64 prefix. The following internal mapping is configured
for this:</p><pre class="programlisting">ip6tables -t mangle -I PREROUTING -i br0 -s 2001:0DB8::/64 -j MAP66 --src-to fdca:ffee:babe::/64 --csum
ip6tables -t mangle -I POSTROUTING -o br0 -d fdca:ffee:babe::/64 -j MAP66 --dst-to 2001:0DB8::/64 --csum</pre><p>To prevent the mapped packets to vanish via the default route and
to overcome mac address lookups during the routing process, I also added
these prefixes to the router's <code class="filename">/etc/radvd.conf</code> as
well as (host) routes pointing to the <span class="quote">“<span class="quote">br0</span>”</span> interface for
both prefixes.</p></div></div><div class="section" title="Motivation"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="motivation"></a>Motivation</h2></div></div></div><p>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:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Address amplification - something not necessary with IPv6 any
more</p></li><li class="listitem"><p>Anonymization - nice to have as an option but not mission
critical</p></li><li class="listitem"><p>ISP independence - no reverse routing, no
"buy-a-number-range"</p></li></ul></div><p>The last point <span class="bold"><strong>is</strong></span> mission critical.
One can obtain a provider independent 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 your address range to be
re-routed to your new location.</p><p>ISP independence 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 addresses (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 (keep it simple stupid).</p><p>Using private IP addresses on the mesh nodes has a drawback: mesh
node software updates e.g. a download via HTTP from an Internet server is
not possible. This is where I start to think: <span class="quote">“<span class="quote">hey, some kind of
address mapping may be nice to have</span>”</span>. While opening Pandora's NAT66
box, I discovered that IPv6 nerds do not like the acronym. It is always a
good tactic in info wars to rename, hence the name "MAP66".</p><p>// Sven-Ola</p></div></div></body></html>
