1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
|
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">
<article>
<articleinfo>
<title>MAP66 (NAT from IPv6 to IPv6, NAT66) for Linux</title>
<author>
<firstname>Sven-Ola</firstname>
<surname>Tücke</surname>
<affiliation>
<orgname>Freifunk</orgname>
</affiliation>
</author>
<pubdate>06-OCT-2010</pubdate>
</articleinfo>
<para>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:</para>
<para><ulink
url="http://tools.ietf.org/html/draft-mrw-behave-nat66-02">http://tools.ietf.org/html/draft-mrw-behave-nat66-02</ulink></para>
<section>
<title>Installation</title>
<para>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:</para>
<programlisting>sudo apt-get install build-essential linux-headers iptables-dev</programlisting>
<para>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:</para>
<programlisting>sudo make install</programlisting>
<note>
<para>The kernel module (<filename>ip6t_MAP66.ko</filename> for
Linux-2.6 or <filename>ip6t_MAP66.o</filename> for Linux-2.4) is not
automatically installed nor loaded into the kernel. You can copy the
kernel module file manually, e.g. with <userinput>sudo cp ip6t_MAP66.ko
/lib/modules/$(uname -r)/</userinput>. </para>
</note>
</section>
<section>
<title>DKMS integration</title>
<para>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:</para>
<programlisting>sudo apt-get install dkms</programlisting>
<para>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:</para>
<programlisting>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</programlisting>
<para>Read DKMS details here: <ulink
url="Read DKMS details here: https://wiki.kubuntu.org/Kernel/Dev/DKMSPackaging">https://wiki.kubuntu.org/Kernel/Dev/DKMSPackaging</ulink></para>
</section>
<section>
<title>Configuration</title>
<para>Note for me: svn propedit svn:ignore.</para>
<para>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.</para>
<para>/etc/gai.conf</para>
<para>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 </para>
<para>Mention --nocheck for speedup (if you do not expect the outer iface
in the mapping range) </para>
<para>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. </para>
<para>Idea to think about: --salt 3b5b91c5a2 XOR client addresses for some
more privacy </para>
</section>
<section>
<title>Motivation</title>
<para>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:</para>
<itemizedlist>
<listitem>
<para>Address amplification - something not necessary with IPv6 any
more</para>
</listitem>
<listitem>
<para>Anonymization - nice to have as an option but not mission
critical</para>
</listitem>
<listitem>
<para>ISP independance - no reverse routing, no
"buy-a-number-range"</para>
</listitem>
</itemizedlist>
<para>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.</para>
<para>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.</para>
<para>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".</para>
<para>// Sven-Ola</para>
</section>
</article>
|
