summaryrefslogtreecommitdiffstats
path: root/README.dbk
diff options
context:
space:
mode:
Diffstat (limited to 'README.dbk')
-rw-r--r--README.dbk111
1 files changed, 18 insertions, 93 deletions
diff --git a/README.dbk b/README.dbk
index dadf179..37cd8d4 100644
--- a/README.dbk
+++ b/README.dbk
@@ -36,8 +36,8 @@
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:</para>
+ some sort of stateless NAT. The implementation is based on RFC 6296 published
+ here:</para>
<para><ulink
url="https://tools.ietf.org/html/rfc6296">https://tools.ietf.org/html/rfc6296</ulink></para>
@@ -57,6 +57,7 @@
and the '-j DNPTV6' target (for destination address translation) 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/(EKU)buntu,
the following command prepares the build environment:</para>
@@ -70,10 +71,10 @@
<filename>/usr/lib/iptables</filename>.</para>
<note>
- <para>The kernel module (<filename>ip6t_MAP66.ko</filename> 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>
+ <para>The kernel modules (<filename>ip6t_SNPTV6.ko</filename> and
+ <filename>ip6t_DNPTV6.ko</filename>) is not automatically installed nor loaded
+ into the kernel. You can copy the kernel module file manually, e.g. with
+ <userinput>sudo cp ip6t_SNPTV6.ko ip6t_DNPTV6.ko /lib/modules/$(uname -r)/</userinput>.</para>
</note>
</section>
@@ -81,16 +82,16 @@
<title id="dkms-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
+ also need to re-compile/re-install the NPTv6 kernel modules. With
Debian/(EKU)buntu, this can be automated with the Dynamic Kernel Module
Support Framework (DKMS). For this, the <filename>dkms.conf</filename>
- file is included with the MAP66 source file package. Install DKMS with the
+ file is included with the NPTv6 source file package. Install DKMS with the
following command:</para>
<programlisting>sudo apt-get install dkms</programlisting>
- <para>If not already in place, move/unpack the MAP66 source file archive
- below <filename>/usr/src/</filename>. To register the MAP66 source to DKMS
+ <para>If not already in place, move/unpack the NPTv6 source file archive
+ below <filename>/usr/src/</filename>. To register the NPTv6 source to DKMS
and compile/install, issue these commands:</para>
<programlisting>sudo dkms add -m ip6t_NPTV6 -v &VERSION;
@@ -111,8 +112,8 @@ sudo dkms install -m ip6t_NPTV6 -v &VERSION;</programlisting>
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 <quote>Address Mapping Example</quote> given
- in the IETF discussion paper:</para>
+ commands correspond to the <quote>/48 Prefix Mapping Example</quote> given
+ in RFC6296:</para>
<programlisting>ip6tables -t mangle -A PREROUTING -i eth0 -d 2001:0DB8:0001::/48 -j DNPTV6 --to-destination FD01:0203:0405::/48
ip6tables -t mangle -A POSTROUTING -o eth0 -s FD01:0203:0405::/48 -j SNPTV6 --to-source 2001:0DB8:0001::/48</programlisting>
@@ -129,10 +130,10 @@ ip6tables -t mangle -A POSTROUTING -o eth0 -s FD01:0203:0405::/48 -j SNPTV6 --to
This means that when an NPTv6 Translator receives a datagram on the
internal interface that has a destination address that matches the
site's external prefix, it will translate the datagram and forward it
- internally. While it is possible that the translator works correctly
- without this depending on the network configuration, it is desiarable
- to have hairpinning behaviour. The following iptables rules will enable
- this:</para>
+ internally. While it is possible that the network works correctly
+ without this depending on the configuration of the external router, it
+ is desirable to have hairpinning behaviour. The following iptables rules
+ will enable this:</para>
<programlisting>ip6tables -t mangle -A PREROUTING -d 2001:0DB8:0001::/48 -j MARK --set-mark 42
ip6tables -t mangle -A PREROUTING -d 2001:0DB8:0001::/48 -j DNPTV6 --to-destination FD01:0203:0405::/48
@@ -157,9 +158,7 @@ ip6tables -t mangle -A POSTROUTING -o eth0 -s FD01:0203:0405::/48 -j SNPTV6 --to
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 <filename>/etc/gai.conf</filename> (see <xref
- endterm="precedence-gai-title" linkend="precedence-gai" />) or use another
- prefix (see <xref endterm="precedence-addrs-title"
- linkend="precedence-addrs" />).</para>
+ endterm="precedence-gai-title" linkend="precedence-gai" />).</para>
<section id="precedence-gai">
<title id="precedence-gai-title">Change gai.conf</title>
@@ -206,79 +205,5 @@ ip6tables -t mangle -A POSTROUTING -o eth0 -s FD01:0203:0405::/48 -j SNPTV6 --to
source addresses and ULA type private IPv6 source addresses. Anything
else is unchanged.</para>
</section>
-
- <section id="precedence-addrs">
- <title id="precedence-addrs-title">Use Changed Internal Address</title>
-
- <para>As an alternative solution, you may use an arbitrary address
- prefix in your LAN that is not mentioned in the
- <filename>gai.conf</filename> 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. </para>
-
- <note>
- <para>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 (EKU)buntu defaults penalize
- 6to4 addresses also.</para>
- </note>
- </section>
- </section>
-
- <section id="motivation">
- <title id="motivation-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 independence - no reverse routing, no
- "buy-a-number-range"</para>
- </listitem>
- </itemizedlist>
-
- <para>The last point <emphasis role="bold">is</emphasis> 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.</para>
-
- <para>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).</para>
-
- <para>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: <quote>hey, some kind of
- address mapping may be nice to have</quote>. 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".</para>
-
- <para>// Sven-Ola</para>
</section>
</article>