doc

git-svn-id: https://map66.svn.sourceforge.net/svnroot/map66@3 3484d885-4da6-438d-b19d-107d078dd756

1 files changed, 170 insertions, 0 deletions

diff --git a/README.dbk b/README.dbk
new file mode 100644
index 0000000..2a50e00
--- /dev/null
+++ b/README.dbk
@@ -0,0 +1,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>