diff options
Diffstat (limited to 'README.dbk')
-rw-r--r-- | README.dbk | 111 |
1 files changed, 18 insertions, 93 deletions
@@ -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> |