mirror of https://github.com/tLDP/LDP
1692 lines
56 KiB
XML
1692 lines
56 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
|
|
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
|
|
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" []>
|
|
<!-- "DTD/docbookx.dtd" []> -->
|
|
|
|
<article>
|
|
<articleinfo>
|
|
|
|
<!-- Article Title -->
|
|
<title>Linux Mobile IPv6 HOWTO</title>
|
|
<titleabbrev>mipv6</titleabbrev>
|
|
|
|
<author>
|
|
<firstname>Lars</firstname>
|
|
<surname>Strand</surname>
|
|
<affiliation>
|
|
<!-- Valid email -->
|
|
<address><email>lars (at) unik no</email></address>
|
|
</affiliation>
|
|
</author>
|
|
<authorinitials>LKS</authorinitials>
|
|
|
|
<!-- All dates specified in ISO "YYYY-MM-DD" format -->
|
|
<pubdate>2004-02-04</pubdate>
|
|
|
|
<!-- Most recent revision goes at the top; list in descending order -->
|
|
<revhistory>
|
|
<revision>
|
|
<revnumber>1.1</revnumber>
|
|
<date>2004-02-04</date>
|
|
<authorinitials>LKS</authorinitials>
|
|
<revremark>Added "Travelling through several foregin LAN's"
|
|
and "Returning home". Some cleanup and restructuring.</revremark>
|
|
</revision>
|
|
<revision>
|
|
<revnumber>1.0</revnumber>
|
|
<date>2003-12-02</date>
|
|
<authorinitials>TMM</authorinitials>
|
|
<revremark>Reviewed by LDP</revremark>
|
|
</revision>
|
|
<revision>
|
|
<revnumber>0.5.2</revnumber>
|
|
<date>2003-11-26</date>
|
|
<authorinitials>LKS</authorinitials>
|
|
<revremark>A lot of cleanup. Thanks to John Levon levon [at]
|
|
movementarian.org</revremark>
|
|
</revision>
|
|
<revision>
|
|
<revnumber>0.5.1</revnumber>
|
|
<date>2003-11-22</date>
|
|
<authorinitials>LKS</authorinitials>
|
|
<revremark>Changed the license from <ulink
|
|
url="http://www.gnu.org/copyleft/fdl.html"> GFDL </ulink> to
|
|
<ulink url="http://www.opencontent.org/openpub/"> OPL
|
|
</ulink> due to some GFDL <ulink
|
|
url="http://people.debian.org/~srivasta/Position_Statement.xhtml">
|
|
problems.</ulink></revremark>
|
|
</revision>
|
|
<revision>
|
|
<revnumber>0.5</revnumber>
|
|
<date>2003-11-18</date>
|
|
<authorinitials>LKS</authorinitials>
|
|
<revremark>Converted to XML Docbook. Some cleanup.</revremark>
|
|
</revision>
|
|
<revision>
|
|
<revnumber>0.4</revnumber>
|
|
<date>2002-11-07</date>
|
|
<authorinitials>LKS</authorinitials>
|
|
<revremark>Fixed some errors + update. Thanks to Henrik Petander
|
|
petander (at) tcs hut fi.</revremark>
|
|
</revision>
|
|
<revision>
|
|
<revnumber>0.3.1</revnumber>
|
|
<date>2003-11-03</date>
|
|
<authorinitials>LKS</authorinitials>
|
|
<revremark>Updated to MIPL relase 1.0 (kernel 2.4.22).</revremark>
|
|
</revision>
|
|
<revision>
|
|
<revnumber>0.3</revnumber>
|
|
<date>2003-08-05</date>
|
|
<authorinitials>LKS</authorinitials>
|
|
<revremark>Initial release.</revremark>
|
|
</revision>
|
|
</revhistory>
|
|
|
|
<!-- Provide a good abstract; a couple of sentences is sufficient -->
|
|
<abstract>
|
|
<para>
|
|
This document describes the software and procedures to set up
|
|
and use mobile IPv6 for Linux. </para>
|
|
</abstract>
|
|
|
|
</articleinfo>
|
|
|
|
|
|
<!-- ##################################################### -->
|
|
|
|
<sect1 id="intro">
|
|
<title>Introduction</title>
|
|
|
|
<para>
|
|
This document describes the software and procedures to set up and
|
|
use mobile IPv6 for Linux. The <ulink
|
|
url="http://www.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-24.txt">
|
|
"Mobility Support in IPv6" draft </ulink> answers the
|
|
<emphasis>what</emphasis> and <emphasis>why</emphasis> of mobile IP:
|
|
</para>
|
|
|
|
<!-- ################## -->
|
|
|
|
<sect2 id="WhatisMIPv6">
|
|
<title>What is Mobile IP?</title>
|
|
|
|
<para>
|
|
<quote>Each mobile node is always identified by its home
|
|
address, regardless of its current point of attachment to the
|
|
Internet. While situated away from its home, a mobile node is also
|
|
associated with a care-of address, which provides information
|
|
about the mobile node's current location. IPv6 packets addressed
|
|
to a mobile node's home address are transparently routed to its
|
|
care-of address via the mobile nodes Home Agent (HA). The
|
|
protocol enables IPv6 nodes to cache the binding of a mobile
|
|
node's home address with its care-of address, and then to send any
|
|
packets destined for the mobile node directly to it at this
|
|
care-of address.</quote> --- draft-ietf-mipv6-24, page 1-2.
|
|
</para>
|
|
</sect2>
|
|
|
|
<!-- ################## -->
|
|
|
|
<sect2 id="WhyMIPv6">
|
|
<title>Why Mobile IP?</title>
|
|
<para>
|
|
<quote>Without specific support for mobility in IPv6, packets destined to a
|
|
mobile node (host or router) would not be able to reach it while the
|
|
mobile node is away from its home link (the link on which its home
|
|
IPv6 subnet prefix is in use), since routing is based on the subnet
|
|
prefix in a packet's destination IP address. In order to continue
|
|
communication in spite of its movement, a mobile node could change its
|
|
IP address each time it moves to a new link, but the mobile node would
|
|
then not be able to maintain transport and higher-layer connections
|
|
when it changes location. Mobility support in IPv6 is particularly
|
|
important, as mobile computers are likely to account for a majority or
|
|
at least a substantial fraction of the population of the Internet
|
|
during the lifetime of IPv6.</quote> --- draft-ietf-mipv6-24, page 6.
|
|
</para>
|
|
|
|
<para>
|
|
For all the details, read the <ulink
|
|
url="http://www.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-24.txt">
|
|
"Mobility Support in IPv6" draft</ulink>
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<!-- ################## -->
|
|
|
|
<sect2 id="HowWork">
|
|
<title>How does it work?</title>
|
|
|
|
<mediaobject id="mobileIP">
|
|
<imageobject>
|
|
<imagedata fileref="images/Mobile-IP.png" format="PNG"
|
|
width="520" align="center" scalefit="1"/>
|
|
</imageobject>
|
|
<textobject>
|
|
<phrase>Mobile IP</phrase>
|
|
</textobject>
|
|
<caption>
|
|
<para>Mobile IP</para>
|
|
</caption>
|
|
</mediaobject>
|
|
|
|
<para>
|
|
<orderedlist>
|
|
<listitem>
|
|
<para> The Mobile Node (MN) travels to a foreign network and gets a
|
|
new care-of-address.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para> The MN performs a binding update to its Home Agent (HA) (the
|
|
new care-of-address gets registered at HA). HA sends a binding
|
|
acknowledgement to MN.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>A Correspondent Node (CN) wants to contact the MN. The HA
|
|
intercepts packets destined to the MN.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>The HA then tunnels all packets to the MN from the CN using
|
|
MN's care-of-address.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>When the MN answers the CN, it may use its current
|
|
care-of-address (and perform a binding to the CN) and communicate
|
|
with the CN directly (optimized routing) or it can tunnel all its
|
|
packets through the HA.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</para>
|
|
|
|
<para>See figure <link linkend="mobileIP">"Mobile IP"</link> for
|
|
an explanation.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
</sect1>
|
|
|
|
<!-- ##################################################### -->
|
|
<sect1 id="IPv6">
|
|
<title>IPv6</title>
|
|
|
|
<para>IP version 6 (IPv6) is a new version of the Internet Protocol,
|
|
designed as the successor to IP version 4 (IPv4) <ulink
|
|
url="http://www.ietf.org/rfc/rfc791.txt">[RFC-791]</ulink>. The
|
|
changes from IPv4 to IPv6 fall primarily into the following
|
|
categories:
|
|
</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Expanded addressing capabilities </para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Header format simplification</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Improved support for extensions and options</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Flow labeling capability</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Authentication and privacy capabilities</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para><emphasis>You should have basic knowledge of IPv6 stateless
|
|
auto-configuring to fully understand how 'mobile IPv6' (MIPv6)
|
|
works. You can read up on IPv6 Stateless Address Autoconfiguration
|
|
in <ulink
|
|
url="http://www.ietf.org/rfc/rfc2462.txt">[RFC2462]</ulink>.
|
|
</emphasis>
|
|
</para>
|
|
|
|
<para>For more information on IPv6 in general, visit the <ulink
|
|
url="http://www.ietf.org/html.charters/ipv6-charter.html">IETF's IPv6
|
|
Working Group</ulink>.
|
|
</para>
|
|
|
|
</sect1>
|
|
|
|
<!-- ##################################################### -->
|
|
|
|
<sect1 id="MIPv6">
|
|
<title>Mobile IPv6 for Linux</title>
|
|
|
|
<para>There are currently two Mobile IPv6 Linux implementations
|
|
available. The Lancaster University in the UK has the oldest(?)
|
|
implementation (<ulink url="http://www.cs-ipv6.lancs.ac.uk/MobileIP/">
|
|
http://www.cs-ipv6.lancs.ac.uk/MobileIP/</ulink>). The latest kernel
|
|
supported is 2.1.90, and is compatible with IETF mobile IPv6 draft-v5
|
|
(the current revision is v24). The code and website has not been
|
|
updated since 1998, so it is considered obsolete. </para>
|
|
|
|
<para>The other implementation, which is up-to-date, is Helsinki
|
|
University of Technology's MIPL project. The latest supported
|
|
kernel is 2.4.22, and they have patches for the upcoming 2.6
|
|
kernel (see the FAQ). Visit <ulink
|
|
url="http://www.mipl.mediapoli.com/">
|
|
http://www.mipl.mediapoli.com/</ulink> for papers, software or to
|
|
browse the mail archive. </para>
|
|
|
|
<!-- ################## -->
|
|
|
|
<sect2 id="patch">
|
|
<title>Patching the kernel</title>
|
|
|
|
<para>The MIPL MIPv6 implementation requires a kernel patch. The
|
|
implementation modifies the IPv6 kernel stack, so a kernel recompile
|
|
is necessary. The installation process is well documented, but I
|
|
will give a brief step-by-step howto. </para>
|
|
|
|
<para><emphasis>Please note! The need for two different kernels, one for MN and
|
|
one for HA, is obsolete. Just compile support for MN and HA in the
|
|
same kernel. It is not possible to run as both an MN and an HA at
|
|
the same time; which mode is chosen depends on which of the modules
|
|
are loaded.</emphasis>
|
|
</para>
|
|
|
|
<para>
|
|
<orderedlist>
|
|
|
|
<listitem>
|
|
<para> Download the latest Linux MIPv6 source code from
|
|
<ulink url="http://www.mipl.mediapoli.com/">
|
|
http://www.mipl.mediapoli.com</ulink>. The latest release today is:
|
|
<emphasis>mipv6-1.0-v2.4.22</emphasis>. The last four numbers
|
|
corresponds to the Linux kernel the patch should be applied to:
|
|
</para>
|
|
|
|
<screen>
|
|
# cd /usr/local/src
|
|
# wget http://www.mipl.mediapoli.com/download/mipv6-1.0-v2.4.22.tar.gz
|
|
# tar zxfv mipv6-1.0-v2.4.22.tar.gz
|
|
</screen>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para> Download and unpack the correspondent Linux kernel version
|
|
from <ulink url="ftp://ftp.kernel.org">ftp.kernel.org</ulink>:
|
|
</para>
|
|
|
|
<screen>
|
|
# cd /usr/src
|
|
# wget ftp://ftp.kernel.org/pub/linux/kernel/v2.4/linux-2.4.22.tar.bz2
|
|
# tar jxvf linux-2.4.22.tar.bz2
|
|
# ln -s linux-2.4.22 linux
|
|
# cd linux
|
|
</screen>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Apply the MIPv6 patch:</para>
|
|
|
|
<screen>
|
|
# patch -p1 --dry-run < /usr/local/src/mipv6-1.0-v2.4.22/mipv6-1.0-v2.4.22.patch
|
|
</screen>
|
|
|
|
<para>The --dry-run option checks that the patch will apply
|
|
correctly. If you get any failed hunks, you should
|
|
<emphasis>not</emphasis> proceed. If everything went fine do:
|
|
</para>
|
|
|
|
<screen>
|
|
# patch -p1 < /usr/local/src/mipv6-1.0-v2.4.22/mipv6-1.0-v2.4.22.patch
|
|
</screen>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para> Now your kernel tree is ready for configuration. Run your
|
|
favorite <command>make *config</command>. The MIPv6 options are under
|
|
<quote>Networking Options</quote>. The following options should be present in
|
|
<emphasis><quote>.config</quote></emphasis>:</para>
|
|
|
|
<screen>
|
|
CONFIG_EXPERIMENTAL=y
|
|
CONFIG_SYSCTL=y
|
|
CONFIG_PROC_FS=y
|
|
CONFIG_MODULES=y
|
|
CONFIG_NET=y
|
|
CONFIG_NETFILTER=y
|
|
CONFIG_UNIX=y
|
|
CONFIG_INET=y
|
|
CONFIG_IPV6=m
|
|
CONFIG_IPV6_SUBTREES=y
|
|
CONFIG_IPV6_IPV6_TUNNEL=m
|
|
CONFIG_IPV6_MOBILITY=m
|
|
CONFIG_IPV6_MOBILITY_MN=m
|
|
CONFIG_IPV6_MOBILITY_HA=m
|
|
</screen>
|
|
|
|
<para> Since MIPL is still a work-in-progress you might want to
|
|
enable:</para>
|
|
|
|
<screen>
|
|
CONFIG_IPV6_MOBILITY_DEBUG=y
|
|
</screen>
|
|
|
|
<para> With debug messages it is easier to figure out what
|
|
happened when something goes wrong. Also, when reporting a bug,
|
|
debug messages are very helpful.</para>
|
|
|
|
<para>To be sure you have all the correct options, you can run
|
|
<userinput>chkconf_kernel.sh</userinput>, which is a small shell
|
|
script included in the MIPL tarball.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para> Next you should compile and install your kernel.</para>
|
|
|
|
<para> Hint: To easily distinguish this kernel from other
|
|
kernels, you can change the <quote>EXTRAVERSION</quote> variable
|
|
in the <userinput>/usr/src/linux/Makefile</userinput> to for
|
|
example <quote>-MIPv6-1</quote>.</para>
|
|
|
|
</listitem>
|
|
|
|
</orderedlist>
|
|
</para>
|
|
|
|
<para>Read the <ulink
|
|
url="http://tldp.org/HOWTO/Kernel-HOWTO/">Linux Kernel
|
|
HOWTO</ulink> for detailed instruction on how to patch, compile and
|
|
install your new kernel.</para>
|
|
|
|
</sect2>
|
|
|
|
<!-- ################## -->
|
|
|
|
<sect2 id="userspace">
|
|
<title>Userspace tools</title>
|
|
<para>The userspace tool <userinput>mipdiag</userinput>, config
|
|
files and init scripts must be installed for the module to work
|
|
correctly:</para>
|
|
|
|
<screen>
|
|
# cd /usr/local/src/mipv6-1.0-v2.4.22
|
|
# ./configure
|
|
# make && make install
|
|
</screen>
|
|
|
|
</sect2>
|
|
|
|
<!-- ################## -->
|
|
|
|
<sect2 id="dev">
|
|
<title>MIPv6 device node</title>
|
|
<para>The MIPv6 module also needs a new device node entry. Issue
|
|
the command:</para>
|
|
|
|
<screen>
|
|
# mknod /dev/mipv6_dev c 0xf9 0
|
|
</screen>
|
|
</sect2>
|
|
|
|
<!-- ################## -->
|
|
|
|
<sect2 id="startup">
|
|
<title>Automatic startup</title>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para><emphasis>Red Hat:</emphasis></para>
|
|
<para>All init scripts are located in <filename>/etc/init.d/</filename>,
|
|
which are sym-linked to the correct runlevel
|
|
(<filename>/etc/rcX.d/</filename>). You can issue the command:</para>
|
|
|
|
<screen>
|
|
# chkconfig --add mobile-ip6
|
|
</screen>
|
|
|
|
<para>to enable MIPv6 at startup, or</para>
|
|
|
|
<screen>
|
|
# chkconfig --del mobile-ip6
|
|
</screen>
|
|
|
|
<para>to remove MIPv6 from startup.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis>Debian:</emphasis></para>
|
|
|
|
<para>If you are so lucky to be running Debian, you can issue
|
|
the command:</para>
|
|
|
|
<screen>
|
|
# update-rc.d -n mobile-ip6 start 75 3 4 5 . stop 05 1 2 6 .
|
|
</screen>
|
|
|
|
<para>to set up all the necessary links.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis>Slackware:</emphasis></para>
|
|
|
|
<para>Slackware users have all their startup/runlevel scripts in
|
|
<filename>/etc/rc.d</filename>. Since 'configure' doesn't check for
|
|
<quote>/etc/rc.d</quote>,
|
|
you can add <emphasis>INIT_SLACK="/etc/rc.d"</emphasis>, and then
|
|
INIT_SLACK to INITDIRS in 'configure' (search for INITDIR in
|
|
configure). Since you are running Slackware, you probably know
|
|
this already. The following command should then do the
|
|
trick:</para>
|
|
|
|
<screen>
|
|
# echo '/etc/rc.d/mobile-ip6 start' >> /etc/rc.d/rc.local
|
|
</screen>
|
|
|
|
<para>If you don't hack the Makefile, the
|
|
<filename>mobile-ip6</filename> script is installed at '/' (you
|
|
may then move it to /etc/rc.d/).</para>
|
|
</listitem>
|
|
|
|
</orderedlist>
|
|
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<!-- ##################################################### -->
|
|
|
|
<sect1 id="testbed">
|
|
<title>Test bed</title>
|
|
<para>Now you should have a working MIPL patched kernel, installed
|
|
userlevel tools and enabled automatic startup at boot. If anything
|
|
went wrong, go through the above sections carefully.</para>
|
|
|
|
<!-- ################## -->
|
|
|
|
<sect2 id="testcase">
|
|
<title>Testcase</title>
|
|
<para>The addresses we are using in our test-bed are
|
|
site-local. You may as well use global addresses, but do
|
|
<emphasis>note that link local addresses won't work!</emphasis>
|
|
Our test-bed consist of four nodes; see figure
|
|
<link linkend="mipv6testbed">"Mobile IPv6 testbed"</link>.</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para><emphasis>HA - Home Agent:</emphasis> The HA is located at the home
|
|
network with address <userinput>fec0:106:2700::2</userinput>,
|
|
with one wireless interface.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis>MN - Mobile Node:</emphasis> When MN is on the
|
|
<quote>home network</quote>, it has address
|
|
<userinput>fec0:106:2700::4</userinput>. When MN travels to
|
|
another network, it generates a new <quote>care-of</quote> address.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis>R - Router:</emphasis> This is the router from
|
|
the home network to the internet. It has one wireless interface with
|
|
address <userinput>fec0:106:2700::1</userinput> and a wired
|
|
interface with address <userinput>fec0:106:2300::2</userinput>.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis>AR - Access Router:</emphasis> The link
|
|
between AR and R is our <quote>internet</quote> - but in this
|
|
testcase only a cross-cable (can be any network). The AR has
|
|
two interfaces; the wired interface to R has address
|
|
<userinput>fec0:106:2300::1</userinput>, the wireless has
|
|
address <userinput>fec0:106:1100::1</userinput>.</para>
|
|
</listitem>
|
|
|
|
</orderedlist>
|
|
|
|
<mediaobject id="mipv6testbed">
|
|
<imageobject>
|
|
<imagedata fileref="images/mipv6-testbed.png" format="PNG"
|
|
width="550px" align="center" scalefit="1"/>
|
|
</imageobject>
|
|
<textobject>
|
|
<phrase>Mobile IPv6 testbed</phrase>
|
|
</textobject>
|
|
<caption>
|
|
<para>Mobile IPv6 testbed</para>
|
|
</caption>
|
|
</mediaobject>
|
|
</sect2>
|
|
|
|
<!-- ################## -->
|
|
<sect2 id="stepbystep">
|
|
<title>Step-by-step configuration</title>
|
|
|
|
<!-- ############ -->
|
|
<sect3 id="fullyipv6">
|
|
<title>Setting up a fully functional IPv6 network</title>
|
|
<para>Before we can start testing mobile IP, we need a fully
|
|
functional IPv6 network. All the nodes should be able to ping
|
|
each other. <emphasis>This is a crucial part.</emphasis> If, for
|
|
example, AR is not able to ping HA, then there will be no binding
|
|
update.</para>
|
|
|
|
<para>I will give a brief instruction to get our network up and
|
|
running using IPv6. For more info on setting up an IPv6 network,
|
|
you can read Peter Bieringer's excellent <ulink
|
|
url="http://ldp.linux.no/HOWTO/Linux+IPv6-HOWTO/">Linux IPv6
|
|
HOWTO</ulink>.</para>
|
|
|
|
<para>I've turned off encryption for simplicity - <emphasis>NOTE that you
|
|
should ALWAYS use encryption when dealing with wireless
|
|
networks!</emphasis></para>
|
|
|
|
<para><emphasis>Also note that the different wireless networks
|
|
have different ESSIDs!</emphasis></para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para><emphasis>MN:</emphasis> The Mobile Node has one wireless
|
|
interface. Forwarding should be turned off, but should accept
|
|
autoconf and ra's:</para>
|
|
|
|
<screen>
|
|
# iwconfig eth0 mode ad-hoc essid homenet enc off
|
|
# ifconfig eth0 inet6 add fec0:106:2700::4/64
|
|
# echo "0" > /proc/sys/net/ipv6/conf/eth0/forwarding
|
|
# echo "1" > /proc/sys/net/ipv6/conf/eth0/autoconf
|
|
# echo "1" > /proc/sys/net/ipv6/conf/eth0/accept_ra
|
|
# echo "1" > /proc/sys/net/ipv6/conf/eth0/accept_redirects
|
|
# /etc/init.d/mobile-ip6 start
|
|
</screen>
|
|
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis>HA:</emphasis> The Home Agent has one
|
|
wireless interface. It should have forwarding turned on
|
|
because it uses normal routing to deliver packets captured
|
|
from a physical interface to the virtual tunnel
|
|
interface. <emphasis>Note: You must add a default route or else
|
|
HA will have problem contacting the MN on visited LAN's. One
|
|
possible solution is to use HA as the default router of the
|
|
home network.</emphasis></para>
|
|
|
|
<screen>
|
|
# iwconfig eth0 mode ad-hoc essid homenet enc off
|
|
# ifconfig eth0 inet6 add fec0:106:2700::2/64
|
|
# echo "1" > /proc/sys/net/ipv6/conf/eth0/forwarding
|
|
# echo "0" > /proc/sys/net/ipv6/conf/eth0/autoconf
|
|
# echo "0" > /proc/sys/net/ipv6/conf/eth0/accept_ra
|
|
# echo "0" > /proc/sys/net/ipv6/conf/eth0/accept_redirects
|
|
# ip route add ::/0 via fec0:106:2700::1
|
|
# /etc/init.d/mobile-ip6 start
|
|
</screen>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis>R:</emphasis> The (home) Router has two
|
|
interfaces; one wireless and one line. The Router must have
|
|
forwarding turned on. </para>
|
|
|
|
<screen>
|
|
# ifconfig eth0 inet6 add fec0:106:2300::2/64
|
|
# iwconfig eth1 mode ad-hoc essid homenet enc off
|
|
# ifconfig eth1 inet6 add fec0:106:2700::1/64
|
|
# echo "1" > /proc/sys/net/ipv6/conf/all/forwarding
|
|
# echo "0" > /proc/sys/net/ipv6/conf/all/autoconf
|
|
# echo "0" > /proc/sys/net/ipv6/conf/all/accept_ra
|
|
# echo "0" > /proc/sys/net/ipv6/conf/all/accept_redirects
|
|
# ip route add fec0:106:1100::/64 via fec0:106:2300::1
|
|
</screen>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis>AR:</emphasis> The Access Router (on a foreign
|
|
network) also has two interfaces; one wireless and one
|
|
line. Forwarding must be turned on.</para>
|
|
|
|
<screen>
|
|
# ifconfig eth0 inet6 add fec0:106:2300::1/64
|
|
# iwconfig eth1 mode ad-hoc essid visitnet enc off
|
|
# ifconfig eth1 inet6 add fec0:106:1100::1/64
|
|
# echo "1" > /proc/sys/net/ipv6/conf/all/forwarding
|
|
# echo "0" > /proc/sys/net/ipv6/conf/all/autoconf
|
|
# echo "0" > /proc/sys/net/ipv6/conf/all/accept_ra
|
|
# echo "0" > /proc/sys/net/ipv6/conf/all/accept_redirects
|
|
# ip route add fec0:106:2700::/64 via fec0:106:2300::2
|
|
</screen>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>Instead of modifying proc variables, you can use
|
|
<emphasis>sysctl</emphasis>.</para>
|
|
|
|
<para>Note: We are setting static routes on our test-bed. You
|
|
should now be able to ping all the hosts from every host.</para>
|
|
</sect3>
|
|
|
|
<!-- ############ -->
|
|
<sect3 id="confmipv6">
|
|
<title>Configuring Mobile IPv6</title>
|
|
<para>The last configuration is MIPv6 settings in
|
|
<filename>network-mip6.conf</filename>. In Debian/Slackware the
|
|
file is found under <filename>/etc/</filename>. (RedHat the file
|
|
is found under <filename>/etc/sysconfig/</filename>.) The file
|
|
should be pretty self-explanatory. </para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para><emphasis>HA:</emphasis> The HA config file should
|
|
contain these settings:</para>
|
|
<screen>
|
|
# cat /etc/network-mip6.conf
|
|
|
|
# Home Agent configuration file
|
|
FUNCTIONALITY=ha
|
|
DEBUGLEVEL=1
|
|
MIN_TUNNEL_NR=1
|
|
MAX_TUNNEL_NR=5
|
|
TUNNEL_SITELOCAL=yes
|
|
</screen>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis>MN:</emphasis> The MN config file should
|
|
look like this:</para>
|
|
<screen>
|
|
# cat /etc/network-mip6.conf
|
|
|
|
# Mobile Node configuration file
|
|
FUNCTIONALITY=mn
|
|
DEBUGLEVEL=1
|
|
TUNNEL_SITELOCAL=yes
|
|
MIN_TUNNEL_NR=1
|
|
MAX_TUNNEL_NR=3
|
|
HOMEDEV=mip6mnha1
|
|
HOMEADDRESS=fec0:106:2700::4/64 # MN's home adress
|
|
HOMEAGENT=fec0:106:2700::2/64 # HA's address
|
|
</screen>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Next, start mobile-IP:</para>
|
|
<screen>
|
|
# /etc/init.d/mobile-ip6 start
|
|
Starting Mobile IPv6: OK
|
|
</screen>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>You can verify that it started by doing a
|
|
<userinput>ifconfig</userinput> on HA. If the tunnel(s) comes up,
|
|
<varname>ip6tnl1</varname>, mobile-ip6 is started:</para>
|
|
|
|
<screen>
|
|
# ifconfig
|
|
eth1 Link encap:Ethernet HWaddr 00:02:2D:2D:DE:79
|
|
inet6 addr: fec0:106:2700::2/64 Scope:Site
|
|
inet6 addr: fe80::202:2dff:fe2d:de79/64 Scope:Link
|
|
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
|
|
RX packets:618 errors:6 dropped:6 overruns:0 frame:6
|
|
TX packets:1485 errors:22 dropped:0 overruns:0 carrier:0
|
|
collisions:0 txqueuelen:100
|
|
RX bytes:87914 (85.8 KiB) TX bytes:252596 (246.6 KiB)
|
|
Interrupt:3 Base address:0x100
|
|
|
|
ip6tnl1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 <co id="tunnel1"/>
|
|
UP POINTOPOINT RUNNING NOARP MTU:1460 Metric:1
|
|
RX packets:6 errors:0 dropped:0 overruns:0 frame:0
|
|
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
|
|
collisions:0 txqueuelen:0
|
|
RX bytes:576 (576.0 b) TX bytes:624 (624.0 b)
|
|
|
|
ip6tnl2 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 <co id="tunnel2"/>
|
|
UP RUNNING NOARP MTU:1460 Metric:1
|
|
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
|
|
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
|
|
collisions:0 txqueuelen:0
|
|
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
|
|
|
|
lo Link encap:Local Loopback
|
|
inet addr:127.0.0.1 Mask:255.0.0.0
|
|
inet6 addr: ::1/128 Scope:Host
|
|
UP LOOPBACK RUNNING MTU:16436 Metric:1
|
|
RX packets:8 errors:0 dropped:0 overruns:0 frame:0
|
|
TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
|
|
collisions:0 txqueuelen:0
|
|
RX bytes:560 (560.0 b) TX bytes:560 (560.0 b)
|
|
</screen>
|
|
|
|
<calloutlist>
|
|
<callout arearefs="tunnel1">
|
|
<para>The tunnel is up and ready for connections.</para>
|
|
</callout>
|
|
<callout arearefs="tunnel2">
|
|
<para>Another tunnel ready.</para>
|
|
</callout>
|
|
</calloutlist>
|
|
|
|
<para>You will also see the mipv6 kernel modules are loaded (MN):</para>
|
|
|
|
<screen>
|
|
# lsmod
|
|
Module Size Used by Not tainted
|
|
mip6_mn 59888 0 (unused)
|
|
ipv6_tunnel 11448 1 [mip6_mn]
|
|
mip6_base 40728 0 [mip6_mn]
|
|
ipv6 179764 -1 [mip6_mn ipv6_tunnel mip6_base]
|
|
...
|
|
</screen>
|
|
|
|
</sect3>
|
|
|
|
|
|
<!-- ############ -->
|
|
<sect3 id="ARradvd">
|
|
<title>Configuring radvd on AR</title>
|
|
|
|
<para>When MN comes to a new network, it does a link-local address
|
|
configuration, going to the next phase if that succeeds. I'll let
|
|
<ulink
|
|
url="http://www.ietf.org/rfc/rfc2462.txt">[RFC2462]</ulink>
|
|
(IPv6 Stateless Address Autoconfiguration) describe the next
|
|
phase:</para>
|
|
|
|
<para>
|
|
<quote>The next phase of autoconfiguration involves obtaining a Router
|
|
Advertisement or determining that no routers are present. If routers
|
|
are present, they will send Router Advertisements that specify what
|
|
sort of autoconfiguration a host should do. If no routers are
|
|
present, stateful autoconfiguration should be invoked.</quote></para>
|
|
|
|
<para>
|
|
<quote>Routers send Router Advertisements periodically, but the delay
|
|
between successive advertisements will generally be longer than a
|
|
host performing autoconfiguration will want to wait. To
|
|
obtain an advertisement quickly, a host sends one or more Router
|
|
Solicitations to the all-routers multicast group.</quote> --- page 8</para>
|
|
|
|
<para>This is where we use
|
|
<ulink url="http://v6web.litech.org/radvd/">RADVD</ulink>.</para>
|
|
|
|
<para>Read <ulink
|
|
url="http://www.ietf.org/rfc/rfc2462.txt">[RFC2462]</ulink>
|
|
more more details concerning IPv6 Stateless Address
|
|
Autoconfiguration.</para>
|
|
|
|
<para>We'll configure RADVD on AR's wireless interface. The
|
|
<filename>radvd.conf</filename> file should contain this:</para>
|
|
|
|
<screen>
|
|
# cat /etc/radvd.conf
|
|
interface eth1
|
|
{
|
|
AdvSendAdvert on;
|
|
AdvIntervalOpt on;
|
|
|
|
MinRtrAdvInterval 3;
|
|
MaxRtrAdvInterval 10;
|
|
AdvHomeAgentFlag off;
|
|
|
|
prefix fec0:106:1100::/64
|
|
{
|
|
AdvOnLink on;
|
|
AdvAutonomous on;
|
|
AdvRouterAddr on;
|
|
};
|
|
};
|
|
</screen>
|
|
|
|
<para>We then start it:</para>
|
|
|
|
<screen>
|
|
# /etc/init.d/radvd start
|
|
</screen>
|
|
|
|
<para>You should now be able to use <userinput>radvdump</userinput> to
|
|
see that the radvd messages really are being sent periodically:</para>
|
|
|
|
<screen>
|
|
# radvdump
|
|
Router advertisement from fe80::202:2dff:fe54:d1b2 (hoplimit 255)
|
|
Received by interface eth1
|
|
# Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump
|
|
AdvCurHopLimit: 64
|
|
AdvManagedFlag: off
|
|
AdvOtherConfigFlag: off
|
|
AdvHomeAgentFlag: off
|
|
AdvReachableTime: 0
|
|
AdvRetransTimer: 0
|
|
Prefix fec0:106:1100::/64
|
|
AdvValidLifetime: 2592000
|
|
AdvPreferredLifetime: 604800
|
|
AdvOnLink: on
|
|
AdvAutonomous: on
|
|
AdvRouterAddr: off
|
|
AdvSourceLLAddress: 00 02 2D 54 D1 B2
|
|
</screen>
|
|
|
|
<para><emphasis>Note! When using radvd on HA and enabling
|
|
<quote>autoconf</quote> (in proc), you will also get an
|
|
autogenerated IPv6 address on MN (which is superfluous) in
|
|
addition to your static address:</emphasis></para>
|
|
|
|
</sect3>
|
|
|
|
<!-- ############ -->
|
|
<sect3 id="radvdar">
|
|
<title>Configuring radvd on HA</title>
|
|
|
|
<para>
|
|
To enable the MN to know when it's home, HA should also be sending
|
|
out RAs. We should therefore enable RADVD on the HA as well. The
|
|
<filename>/etc/radvd.conf</filename> file should contain:
|
|
</para>
|
|
|
|
<screen>
|
|
# cat /etc/radvd.conf
|
|
interface eth0
|
|
{
|
|
AdvSendAdvert on;
|
|
MaxRtrAdvInterval 3;
|
|
MinRtrAdvInterval 1;
|
|
AdvIntervalOpt off;
|
|
AdvHomeAgentFlag on;
|
|
HomeAgentLifetime 10000;
|
|
HomeAgentPreference 20;
|
|
AdvHomeAgentInfo on;
|
|
prefix fec0:106:2700::2/64
|
|
{
|
|
AdvRouterAddr on;
|
|
AdvOnLink on;
|
|
AdvAutonomous on;
|
|
AdvPreferredLifetime 10000;
|
|
AdvValidLifetime 12000;
|
|
};
|
|
};
|
|
</screen>
|
|
|
|
<para>Also do a <userinput>radvdump</userinput> on HA to check
|
|
whether radvd messages are beeing sent:</para>
|
|
|
|
<screen>
|
|
# radvdump
|
|
Router advertisement from fe80::202:2dff:fe54:d11e (hoplimit 255)
|
|
Received by interface eth0
|
|
# Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump
|
|
AdvCurHopLimit: 64
|
|
AdvManagedFlag: off
|
|
AdvOtherConfigFlag: off
|
|
AdvHomeAgentFlag: on
|
|
AdvReachableTime: 0
|
|
AdvRetransTimer: 0
|
|
Prefix fec0:106:2700::2/64
|
|
AdvValidLifetime: 12000
|
|
AdvPreferredLifetime: 10000
|
|
AdvOnLink: on
|
|
AdvAutonomous: on
|
|
AdvRouterAddr: on
|
|
AdvSourceLLAddress: 00 02 2D 54 D1 1E
|
|
AdvHomeAgentInfo:
|
|
HomeAgentPreference: 20
|
|
HomeAgentLifetime: 1000
|
|
</screen>
|
|
|
|
<screen>
|
|
# ifconfig eth0
|
|
eth0 Link encap:Ethernet HWaddr 00:90:7D:F3:03:1A
|
|
inet6 addr: fec0:106:2700:0:290:7dff:fef3:31a/64 Scope:Site <co id="newaddress"/>
|
|
inet6 addr: fec0:106:2700::4/64 Scope:Site <co id="staticadr"/>
|
|
inet6 addr: fe80::290:7dff:fef3:31a/64 Scope:Link <co id="linkaddrs"/>
|
|
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
|
|
RX packets:513 errors:89 dropped:89 overruns:0 frame:85
|
|
TX packets:140 errors:41 dropped:0 overruns:0 carrier:0
|
|
collisions:0 txqueuelen:100
|
|
RX bytes:56084 (54.7 Kb) TX bytes:19212 (18.7 Kb)
|
|
Interrupt:3 Base address:0x100
|
|
</screen>
|
|
|
|
<calloutlist>
|
|
<callout arearefs="newaddress">
|
|
<para>A new (superfluous) autogenerated address. Since we are
|
|
setting <userinput>autoconf</userinput> in
|
|
<userinput>/proc/sys/net/ipv6/conf/eth0/autoconf</userinput>
|
|
to <userinput>1</userinput>, MN will generate a new adress
|
|
combined with HA's prefix and it's own MAC address. I do not
|
|
think is it possible to avoid having this address generated.</para>
|
|
</callout>
|
|
<callout arearefs="staticadr">
|
|
<para>Our original static IPv6 address</para>
|
|
</callout>
|
|
<callout arearefs="linkaddrs">
|
|
<para>The link-local address generated at boot.</para>
|
|
</callout>
|
|
</calloutlist>
|
|
|
|
</sect3>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<!-- ##################################################### -->
|
|
|
|
<sect1 id="dotest">
|
|
<title>Doing some tests</title>
|
|
|
|
<sect2 id="pretest">
|
|
<title>Pre-test</title>
|
|
<para>Do every configuration as shown above; it's especially important
|
|
to have a different ESSID on the home net and visited network. </para>
|
|
|
|
<para>When you start mobile-IPv6 on MN, you will see
|
|
multicasting router solicitations messages:</para>
|
|
|
|
<screen>
|
|
# tcpdump -i eth0 -vv ip6 or proto ipv6
|
|
|
|
...
|
|
13:32:54.681763 fe80::202:a5ff:fe6f:a08a > ff02::2: icmp6: router solicitation \
|
|
(src lladdr: 0:2:a5:6f:a0:8a) (len 16, hlim 255)
|
|
|
|
13:32:55.681763 fe80::202:a5ff:fe6f:a08a > ff02::2: icmp6: router solicitation \
|
|
(src lladdr: 0:2:a5:6f:a0:8a) (len 16, hlim 255)
|
|
|
|
13:32:57.681765 fe80::202:a5ff:fe6f:a08a > ff02::2: icmp6: router solicitation \
|
|
(src lladdr: 0:2:a5:6f:a0:8a) (len 16, hlim 255)
|
|
...
|
|
|
|
</screen>
|
|
</sect2>
|
|
|
|
<!-- ################## -->
|
|
|
|
<sect2 id="MovDet">
|
|
<title>Movement detection</title>
|
|
<para>Generic movement detection uses Neighbor Unreachability
|
|
Detection to detect when the default router is no longer
|
|
bi-directionally reachable, in which case the mobile node must
|
|
discover a new default router (usually on a new link).</para>
|
|
|
|
<para> To easily see whats going on, you should have one xterm
|
|
window for each of these commands: </para>
|
|
|
|
<screen>
|
|
# watch ifconfig eth0
|
|
# watch route -A inet6
|
|
# tcpdump -i eth0 -vv ip6 or proto ipv6
|
|
</screen>
|
|
|
|
<para>To <quote>travel</quote> to another net, you can issue the
|
|
command on MN:</para>
|
|
|
|
<screen>
|
|
# iwconfig eth1 essid visitnet
|
|
</screen>
|
|
|
|
<para>The MN is then on the other wireless network, and since it is
|
|
sending out <quote>router solicitation</quote> (multicast), our AR will
|
|
respond with it's prefix. MN will then configure itself with at new
|
|
IPv6 address with the received prefix and it's own MAC address. If
|
|
you type <command>ifconfig eth0</command> you will see the new IPv6
|
|
address:</para>
|
|
|
|
<screen>
|
|
# ifconfig eth0
|
|
eth0 Link encap:Ethernet HWaddr 00:90:7D:F3:03:1A
|
|
inet6 addr: fec0:106:1100:0:290:7dff:fef3:31a/64 Scope:Site <co id="newaddr"/>
|
|
inet6 addr: fec0:106:2700:0:290:7dff:fef3:31a/64 Scope:Site <co id="superadr"/>
|
|
inet6 addr: fec0:106:2700::4/64 Scope:Site <co id="oldaddr"/>
|
|
inet6 addr: fe80::290:7dff:fef3:31a/64 Scope:Link <co id="linkaddr"/>
|
|
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
|
|
RX packets:854 errors:154 dropped:154 overruns:0 frame:148
|
|
TX packets:293 errors:58 dropped:0 overruns:0 carrier:0
|
|
collisions:0 txqueuelen:100
|
|
RX bytes:96536 (94.2 Kb) TX bytes:44664 (43.6 Kb)
|
|
Interrupt:3 Base address:0x100
|
|
|
|
</screen>
|
|
<calloutlist>
|
|
<callout arearefs="newaddr">
|
|
<para>The new <quote>foreign</quote> address, generated by
|
|
combining AR's prefix and MAC-address</para>
|
|
</callout>
|
|
<callout arearefs="superadr">
|
|
<para>The superfluous home network address (because of HA
|
|
radvd messages and MN autoconf set to
|
|
<quote>true</quote>).</para>
|
|
</callout>
|
|
<callout arearefs="oldaddr">
|
|
<para>The <quote>original</quote> (home) address</para>
|
|
</callout>
|
|
<callout arearefs="linkaddr">
|
|
<para>The link-local address generated at boot</para>
|
|
</callout>
|
|
</calloutlist>
|
|
|
|
<para>Almost at the same time, the MN will perform a binding update
|
|
to HA. In your tcpdump window, you will see several packets
|
|
destined to HA. To verify that the binding update has been sent and
|
|
acknowledged from MN:</para>
|
|
|
|
<screen>
|
|
# mipdiag -s
|
|
Mobile IPv6 Statistics
|
|
NEncapsulations : 0
|
|
NDecapsulations : 0
|
|
NBindUpdatesRcvd : 0
|
|
NBindAcksRcvd : 1 <co id="back"/>
|
|
NBindNAcksRcvd : 0
|
|
NBindRqsRcvd : 0
|
|
NBindUpdatesSent : 1 <co id="bupdate"/>
|
|
NBindAcksSent : 0
|
|
NBindNAcksSent : 0
|
|
NBindRqsSent : 0
|
|
NBindUpdatesDropAuth : 0
|
|
NBindUpdatesDropInvalid : 0
|
|
NBindUpdatesDropMisc : 0
|
|
NBindAcksDropAuth : 0
|
|
NBindAcksDropInvalid : 0
|
|
NBindAcksDropMisc : 0
|
|
NBindRqsDropAuth : 0
|
|
NBindRqsDropInvalid : 0
|
|
NBindRqsDropMisc : 0
|
|
</screen>
|
|
<calloutlist>
|
|
<callout arearefs="back">
|
|
<para>One binding ACK received.</para>
|
|
</callout>
|
|
<callout arearefs="bupdate">
|
|
<para>One binding UPDATE sent.</para>
|
|
</callout>
|
|
</calloutlist>
|
|
|
|
<para>You can also verify the binding with the following command
|
|
(on MN):</para>
|
|
|
|
<screen>
|
|
# mipdiag -l
|
|
Mobile IPv6 Binding update list
|
|
Recipient CN: fec0:106:2700::2
|
|
BINDING home address: fec0:106:2700::4 care-of address: fec0:106:1100:0:290:7dff:fef3:31a
|
|
expires: 936 sequence: 0 state: 1
|
|
delay: 3 max delay 32 callback time: 736
|
|
</screen>
|
|
|
|
<para>You can also verify it on HA with the statistics option
|
|
(-s) and with the <quote>binding cache</quote> (-c) option:</para>
|
|
|
|
<screen>
|
|
# mipdiag -c
|
|
Mobile IPv6 Binding cache
|
|
Home Address Care-of Address Lifetime Type
|
|
fec0:106:2700::4 fec0:106:1100:0:290:7dff:fef3:31a 971 2
|
|
</screen>
|
|
</sect2>
|
|
|
|
<!-- ################## -->
|
|
|
|
<sect2 id="ping6">
|
|
<title>ping6</title>
|
|
|
|
<para>From the MN, you can try to ping AR's eth1
|
|
(fec0:106:1100::1):</para>
|
|
|
|
<screen>
|
|
# ping6 fec0:106:1100::1
|
|
PING fec0:106:1100::1(fec0:106:1100::1) from fec0:106:2700::4 : 56 data bytes
|
|
64 bytes from fec0:106:1100::1: icmp_seq=1 ttl=62 time=8.01 ms
|
|
64 bytes from fec0:106:1100::1: icmp_seq=2 ttl=62 time=8.02 ms
|
|
...
|
|
</screen>
|
|
|
|
<para>By using tcpdump, you can see how the packets travel:</para>
|
|
|
|
<screen>
|
|
12:13:51.789688 fec0:106:1100:0:202:a5ff:fe6f:a08a > fec0:106:2700::2: \ <co id="mntoha"/>
|
|
fec0:106:2700::4 > fec0:106:1100::1: icmp6: echo request \ <co id="hatocr"/>
|
|
(len 64, hlim 64) (len 104, hlim 255)
|
|
|
|
12:13:51.797675 fec0:106:2700::2 > fec0:106:1100:0:202:a5ff:fe6f:a08a: \ <co id="artomn"/>
|
|
fec0:106:1100::1 > fec0:106:2700::4: icmp6: echo reply \
|
|
(len 64, hlim 62) (len 104, hlim 253)
|
|
</screen>
|
|
|
|
<calloutlist>
|
|
<callout arearefs="mntoha">
|
|
<para>The packet first goes from MN to the HA using MN new
|
|
IPv6 address.</para>
|
|
</callout>
|
|
<callout arearefs="hatocr">
|
|
<para>Then from HA to AR.</para>
|
|
</callout>
|
|
<callout arearefs="artomn">
|
|
<para>The AR then responds to HA and tunnels the packets to
|
|
MN.</para>
|
|
</callout>
|
|
</calloutlist>
|
|
|
|
<para>You can now see the statistics have been updated (on MN):</para>
|
|
|
|
<screen>
|
|
# mipdiag -s
|
|
Mobile IPv6 Statistics
|
|
NEncapsulations : 56
|
|
NDecapsulations : 25
|
|
...
|
|
</screen>
|
|
</sect2>
|
|
|
|
<!-- ################## -->
|
|
|
|
<sect2 id="routeTable">
|
|
<title>Kernel IP routing table</title>
|
|
<para>One interesting thing MIPv6 does is change the default route to
|
|
a tunnel. The new default route becomes:</para>
|
|
|
|
<screen>
|
|
# route -A inet6
|
|
Kernel IPv6 routing table
|
|
Destination Next Hop Flags Metric Ref Use Iface
|
|
::/0 :: UD 64 0 0 ip6tnl1
|
|
....
|
|
</screen>
|
|
|
|
<para>If it doesn't add a default route, you may add it manually:</para>
|
|
|
|
<screen>
|
|
# ip route ::/0 via dev ip6tnl
|
|
</screen>
|
|
</sect2>
|
|
|
|
<!-- ################## -->
|
|
|
|
<sect2 id="movement">
|
|
<title>Travelling through several foregin LAN's</title>
|
|
|
|
<para>To travel to several visited networks, is no different than
|
|
travel to <emphasis>one</emphasis> network. The only thing you
|
|
must have in mind is that you will generate a new address for each
|
|
visited network.
|
|
</para>
|
|
|
|
<mediaobject id="LANvisits">
|
|
<imageobject>
|
|
<imagedata fileref="images/lanvisits.png" format="PNG"
|
|
width="550px" align="center" scalefit="1"/>
|
|
</imageobject>
|
|
<textobject>
|
|
<phrase></phrase>
|
|
</textobject>
|
|
<caption>
|
|
<para>MN travelling through severeal different LANs.</para>
|
|
</caption>
|
|
</mediaobject>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>MN first visits 'visitnet', as we have been through above.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>MN is then travelling from 'visitnet' to
|
|
'visitnet2'.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>When at 'visitnet2', MN generates a new IPv6 address and
|
|
do a new binding update to HA.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>MN then travels back home. (Se next section.)</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>The AR at <quote>visitnet2</quote>, is configured exactly
|
|
as the other AR (at <quote>visitnet</quote>), except using address
|
|
<userinput>fec0:106:1000::/64</userinput> instead of
|
|
<userinput>fec0:106:1100::/64</userinput>.</para>
|
|
|
|
<para>To make the mobile node travel from 'visitnet' to
|
|
'visitnet2', issue the command (on MN):</para>
|
|
|
|
<screen>
|
|
# iwconfig eth0 essid visitnet2
|
|
</screen>
|
|
|
|
<para>You will then see the MN configures itself to the new network:</para>
|
|
|
|
<screen>
|
|
# ifconfig eth0
|
|
eth1 Link encap:Ethernet HWaddr 00:90:7D:F3:03:1A
|
|
inet6 addr: fec0:106:1000:0:290:7dff:fef3:31a/64 Scope:Site <co id="net2"/>
|
|
inet6 addr: fec0:106:1100:0:290:7dff:fef3:31a/64 Scope:Site
|
|
inet6 addr: fec0:106:2700:0:290:7dff:fef3:31a/64 Scope:Site
|
|
inet6 addr: fec0:106:2700::4/64 Scope:Site
|
|
inet6 addr: fe80::290:7dff:fef3:31a/64 Scope:Link
|
|
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
|
|
RX packets:1073 errors:212 dropped:212 overruns:0 frame:204
|
|
TX packets:371 errors:72 dropped:0 overruns:0 carrier:0
|
|
collisions:0 txqueuelen:100
|
|
RX bytes:120340 (117.5 Kb) TX bytes:56912 (55.5 Kb)
|
|
Interrupt:3 Base address:0x100
|
|
</screen>
|
|
|
|
<calloutlist>
|
|
<callout arearefs="net2">
|
|
<para>The new autoconfigured address at 'visitnet2'.</para>
|
|
</callout>
|
|
</calloutlist>
|
|
|
|
<para><emphasis>Note! You may have to restart mobile-ipv6 on MN
|
|
when coming to a new network!</emphasis></para>
|
|
|
|
<screen>
|
|
# /etc/init.d/mobile-ip6 restart
|
|
Stopping Mobile IPv6: OK
|
|
Starting Mobile IPv6: OK
|
|
</screen>
|
|
|
|
<para>The MN will then perform a new binding update to HA. Notice
|
|
the new <quote>care-of address</quote>:</para>
|
|
<screen>
|
|
# mipdiag -l
|
|
Mobile IPv6 Binding update list
|
|
Recipient CN: fec0:106:2700::2
|
|
BINDING home address: fec0:106:2700::4 care-of address: fec0:106:1000:0:290:7dff:fef3:31a
|
|
expires: 973 sequence: 14 state: 1
|
|
delay: 3 max delay 32 callback time: 773
|
|
</screen>
|
|
|
|
<para>You can also see the <quote>binding cache</quote> on HA has
|
|
been updated:</para>
|
|
|
|
<screen>
|
|
# mipdiag -c
|
|
Mobile IPv6 Binding cache
|
|
Home Address Care-of Address Lifetime Type
|
|
fec0:106:2700::4 fec0:106:1000:0:290:7dff:fef3:31a 943 2
|
|
</screen>
|
|
|
|
</sect2>
|
|
|
|
<!-- ################## -->
|
|
|
|
<sect2 id="home">
|
|
<title>Returning home</title>
|
|
|
|
<para>To make the MN return home, you can just issue the
|
|
command:</para>
|
|
|
|
<screen>
|
|
# iwconfig eth0 essid homenet
|
|
</screen>
|
|
|
|
<para>The MN will know it is back home, since HA is sending out
|
|
radvd messages with the HA-bit set (AdvHomeAgentFlag), see <xref
|
|
linkend="radvdar"/></para>
|
|
|
|
<para>You can see the MN <quote>is back home</quote>, since the
|
|
binding cache information at HA is flushed (empty):</para>
|
|
|
|
<screen>
|
|
Mobile IPv6 Binding cache
|
|
Home Address Care-of Address Lifetime Type
|
|
</screen>
|
|
|
|
</sect2>
|
|
|
|
<!-- ################## -->
|
|
|
|
<sect2 id="realLife">
|
|
<title>Real life testing - smooth handover</title>
|
|
<para>To really get the feel on how mobile IP works, fire up GnomeMeeting
|
|
(See the figure GnomeMeeting and start a netmeeting. Note! You must use
|
|
the latest GnomeMeeting to get support for IPv6! Then do a <quote>travel</quote>
|
|
and you can see an almost smooth handover.</para>
|
|
|
|
<mediaobject id="gnomemeeting">
|
|
<imageobject>
|
|
<imagedata fileref="images/gnomemeeting1.png" format="PNG"
|
|
width="250px" align="center" scalefit="1"/>
|
|
</imageobject>
|
|
<textobject>
|
|
<phrase>GnomeMeeting</phrase>
|
|
</textobject>
|
|
<caption>
|
|
<para>Using GnomeMeeting with IPv6 to test roaming between two
|
|
wireless networks</para>
|
|
</caption>
|
|
</mediaobject>
|
|
</sect2>
|
|
|
|
</sect1>
|
|
|
|
<!-- ##################################################### -->
|
|
|
|
<sect1 id="faq">
|
|
<title>FAQ</title>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para><emphasis>Q: Why do we have to create the
|
|
<filename>/dev/mipv6_dev</filename> entry?</emphasis></para>
|
|
|
|
<para>A: The dev file is mainly so that the userspace tool,
|
|
mipdiag, can make modifications to the kernel parameters using
|
|
ioctl calls through the device file. <command>mknod</command> creates the special
|
|
device file with paramters recognizable by the mobile-ip6
|
|
module.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis>Q: Is there any support for kernel 2.6.x?</emphasis></para>
|
|
|
|
<para>A: Here is the <ulink
|
|
url="http://www.mipl.mediapoli.com/pipermail/mipl/2003-December/001871.html">answer
|
|
from Henrik Petander</ulink> on the MIPL mailinglist:</para>
|
|
|
|
<para><quote>Here is a short overview of the status of MIPL for
|
|
2.6 kernel series:</quote></para>
|
|
|
|
<para><quote>We have finished the kernel infrastructure for
|
|
Mobile IPv6 in cooperation with the USAGI project. The
|
|
infrastructure does route optimization, tunneling and policy
|
|
routing.</quote></para>
|
|
|
|
<para><quote>We are now working on the userspace daemon which
|
|
handles the MIPv6 signaling and controls the operation of the
|
|
kernel part. The userspace part is also progressing
|
|
nicely. However, the protocol logic is still missing, so there
|
|
isn't really anything for users to test yet. We should have a
|
|
well working and tested prototype ready and by the end of
|
|
March.</quote></para>
|
|
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis>Q: Does MIPL support
|
|
IPSec?</emphasis></para>
|
|
|
|
<para>A: There is no support IPSec on 2.4.x. MIPL for 2.6 series will
|
|
have IPSec support from the start. You may use a third-party IPSec
|
|
implementation.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis>Q: How can I control the type of routing used for
|
|
communication between the MN and a CN (through HA tunnel or by
|
|
direct communication using binding update/acks)?</emphasis></para>
|
|
|
|
<para>A: You can control this through:</para>
|
|
|
|
<para>
|
|
<userinput>/proc/sys/conf/net/ipv6/mobility/accept_return_routability</userinput>
|
|
</para>
|
|
|
|
<para>If you do not want to use return routability and route optimization,
|
|
set it to 0 with:</para>
|
|
|
|
<para>
|
|
<userinput># echo 0 >
|
|
/proc/sys/..../accept_return_routability</userinput>
|
|
</para>
|
|
|
|
<para> Then MN will communicate with CNs only through the
|
|
home tunnel.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis>Q: Can different wireless networks
|
|
have different ESSIDs/WEP keys?</emphasis></para>
|
|
|
|
<para>A: Yes, but you must change this upon arrival to the new
|
|
network. MIPv6 from MIPL can't do this automatically.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis>Q: If MN has travelled through several visited
|
|
LAN, and then returning home; the interface still has all the
|
|
autogenerated IPv6 addresses from all the visited networks! Is
|
|
there any way to <quote>flush/delete</quote> these
|
|
addresses?</emphasis></para>
|
|
|
|
<para>A: No, I do not know of any automatic way these adresses
|
|
can be removed, but you can delete them manually:</para>
|
|
|
|
<para><userinput>
|
|
# ifconfig eth0 inet6 del <ipv6-address>
|
|
</userinput></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis>Q: Host B has two interfaces with two
|
|
different subnets assigned. When I ping B from host A, it does
|
|
not answer! Why not? Host A knows where host B
|
|
(subnets) are!</emphasis></para>
|
|
|
|
<para>A: The host B doesn't know where host A is (B doesn't
|
|
know where A's net is), so you must add a route
|
|
entry:</para>
|
|
|
|
<para><userinput>
|
|
# ip route add fec0:106:2700::/64 via fec0:106:2300::1
|
|
</userinput></para>
|
|
|
|
<para>or</para>
|
|
|
|
<para><userinput>
|
|
# route -A inet6 add fec0:106:2700::/64 gw fec0:106:2300::1 dev eth0
|
|
</userinput></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis>Q: How do I set a default gateway in
|
|
IPv6?</emphasis></para>
|
|
|
|
<para>A: You do that using the traditional <quote>route</quote>:</para>
|
|
|
|
<para><userinput>
|
|
# route -A inet6 add default gw <ipv6-host>
|
|
</userinput></para>
|
|
|
|
<para>or the newer <quote>ip</quote> command:</para>
|
|
|
|
<para><userinput>
|
|
# ip route ::/0 via <ipv6-host>
|
|
</userinput></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis>Q: Why does the host send a multicast
|
|
address rather than an anycast address, requesting for router
|
|
solicitation?</emphasis></para>
|
|
|
|
<para>A: Because the host wants an answer from every router, not from just any
|
|
router. The idea is to be able to get all parameters and to choose
|
|
the <quote>best</quote> default router.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis>Q: Why doesn't MN notice that it has
|
|
moved?</emphasis></para>
|
|
|
|
<para>A: It thinks that it's previous router is still reachable. This may
|
|
result from very large lifetimes in router advertisements. Check the
|
|
configuration of the program sending router advertisements in the
|
|
router. If the program supports router advertisement intervals, you
|
|
can use this to help MN in movement detection by setting the use of
|
|
interval to <option>on</option>. See <command>man radvd.conf</command> for
|
|
details.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
</sect1>
|
|
|
|
<!-- ##################################################### -->
|
|
|
|
<sect1 id="resources">
|
|
<title>Useful Resources</title>
|
|
|
|
<para>
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Mobile IPv6 for Linux <ulink
|
|
url="http://www.mipl.mediapoli.com/">
|
|
http://www.mipl.mediapoli.com/</ulink></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Mobile IP Working Group (IETF) <ulink
|
|
url="http://www.ietf.org/html.charters/mobileip-charter.html">
|
|
http://www.ietf.org/html.charters/mobileip-charter.html </ulink></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Mobile IPv6 draft <ulink
|
|
url="http://www.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-24.txt">
|
|
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-24.txt</ulink>
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>IPv6 Working Group (IETF) <ulink
|
|
url="http://www.ietf.org/html.charters/ipv6-charter.html">
|
|
http://www.ietf.org/html.charters/ipv6-charter.html </ulink></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>RFC2460 Internet Protocol, Version 6 (IPv6) Specification
|
|
<ulink url="http://www.ietf.org/rfc/rfc2460.txt">
|
|
http://www.ietf.org/rfc/rfc2460.txt </ulink></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>RFC2461 Neighbor Discovery for IP Version 6 (IPv6) <ulink
|
|
url="http://www.ietf.org/rfc/rfc2461.txt">
|
|
http://www.ietf.org/rfc/rfc2461.txt </ulink></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>RFC2462 IPv6 Stateless Address Autoconfiguration <ulink
|
|
url="http://www.ietf.org/rfc/rfc2462.txt">
|
|
http://www.ietf.org/rfc/rfc2462.txt </ulink></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Peter Bieringer's Linux IPv6 HOWTO (en) <ulink
|
|
url="http://ldp.linux.no/HOWTO/Linux+IPv6-HOWTO/">
|
|
http://ldp.linux.no/HOWTO/Linux+IPv6-HOWTO/ </ulink></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Current Status of IPv6 Support for Networking Applications
|
|
<ulink url="http://www.deepspace6.net/docs/ipv6_status_page_apps.html">
|
|
http://www.deepspace6.net/docs/ipv6_status_page_apps.html</ulink></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Linux Kernel HOWTO <ulink
|
|
url="http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html_single/Kernel-HOWTO.html">
|
|
http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html_single/Kernel-HOWTO.html
|
|
</ulink></para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</para>
|
|
</sect1>
|
|
|
|
<!-- ##################################################### -->
|
|
|
|
<sect1 id="copyack">
|
|
<title>Copyright, acknowledgments and miscellaneous</title>
|
|
|
|
<!-- ################## -->
|
|
|
|
<sect2 id="copyright">
|
|
<title>Copyright and License</title>
|
|
<para>
|
|
Copyright © 2003,2004 by Lars Strand. This material may
|
|
be distributed only subject to the terms and conditions set forth
|
|
in the Open Publication License, v1.0 or later (the latest version
|
|
is presently available at <ulink
|
|
url="http://www.opencontent.org/openpub/">
|
|
http://www.opencontent.org/openpub/ </ulink>).
|
|
</para>
|
|
|
|
<para>
|
|
Linux is a registered trademark of Linus Torvalds.
|
|
</para>
|
|
</sect2>
|
|
|
|
<!-- ################## -->
|
|
|
|
<sect2 id="disclaimer">
|
|
<title>Disclaimer</title>
|
|
|
|
<para>
|
|
No liability for the contents of this document can be accepted.
|
|
Use the concepts, examples and information at your own risk.
|
|
There may be errors and inaccuracies, that could be damaging to
|
|
your system. Proceed with caution, and although this is highly
|
|
unlikely, the author(s) do not take any responsibility.
|
|
</para>
|
|
|
|
<para>
|
|
All copyrights are held by their by their respective owners,
|
|
unless specifically noted otherwise. Use of a term in this
|
|
document should not be regarded as affecting the validity of any
|
|
trademark or service mark. Naming of particular products or
|
|
brands should not be seen as endorsements.
|
|
</para>
|
|
</sect2>
|
|
|
|
<!-- ################## -->
|
|
|
|
<sect2 id="produced">
|
|
<title>How this document was produced</title>
|
|
<para>This document was originally written in LaTeX using
|
|
Emacs. HTML version created with latex2html. Later it was
|
|
converted to DocBook XML.</para>
|
|
|
|
<para>An up-to-date version of this document can be found at:</para>
|
|
|
|
<para> HTML: <ulink url="http://www.tldp.org/HOWTO/Mobile-IPv6-HOWTO/">
|
|
http://www.tldp.org/HOWTO/Mobile-IPv6-HOWTO/</ulink> </para>
|
|
</sect2>
|
|
|
|
<!-- ################## -->
|
|
|
|
<sect2 id="feedback">
|
|
<title>Feedback</title>
|
|
<para>Suggestions, corrections, additions wanted. Contributors
|
|
wanted and acknowledged. Flames not wanted.</para>
|
|
|
|
<para>I can always be reached at <email>lars at unik
|
|
no</email></para>
|
|
|
|
<para>Homepage: <ulink url="http://www.gnist.org/~lars">
|
|
http://www.gnist.org/~lars</ulink></para>
|
|
</sect2>
|
|
|
|
<!-- ################## -->
|
|
|
|
<sect2 id="ack">
|
|
<title>Acknowledgments</title>
|
|
<para>This document was produced as a part of Interoperable
|
|
Networks for Secure Communications <ulink
|
|
url="http://insc.nodeca.mil.no/">(INSC task 6)</ulink></para>
|
|
|
|
<para>Thanks to Andreas Hafslund (andreha [at] unik.no) for
|
|
initial support. Also thanks to UniK (University Graduate Center)
|
|
<ulink url="http://www.unik.no">http://www.unik.no</ulink> and FFI
|
|
(Norwegian Defence Research Establishment) <ulink
|
|
url="http://www.ffi.mil.no">http://www.ffi.mil.no</ulink> for
|
|
hardware support.</para>
|
|
|
|
<para>Thanks also to the other HOWTO authors whose works I have
|
|
referenced: </para>
|
|
|
|
<para><emphasis>Linux IPv6 HOWTO (en)</emphasis> by Peter
|
|
Bieringer</para>
|
|
</sect2>
|
|
|
|
</sect1>
|
|
|
|
</article>
|
|
|
|
|