LDP
/
LDP
mirror of https://github.com/tLDP/LDP
0
1
Fork 0
Code Releases Activity

Modified Files: 

Linux+IPv6-HOWTO.sgml : Fix broken RFC URLs
This commit is contained in:
pbldp 2002-11-18 19:28:36 +00:00
parent b2c6eb3a6b
commit 394db6d671
1 changed files with 20 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

39
LDP/howto/docbook/Linux+IPv6-HOWTO.sgml
View File

@ -8,12 +8,12 @@
<firstname>Peter </firstname><surname>Bieringer</surname><affiliation><address> <email>pb (at) bieringer.de</email> </address> </affiliation>
</author>
<revhistory>
<revision> <revnumber>Release 0.33</revnumber> <date>2002-11-18</date> <authorinitials>PB</authorinitials> <revremark>See <link linkend="revision-history">revision history</link> for more</revremark></revision>
<revision> <revnumber>Release 0.32</revnumber> <date>2002-11-03</date> <authorinitials>PB</authorinitials> <revremark>See <link linkend="revision-history">revision history</link> for more</revremark></revision>
<revision> <revnumber>Release 0.31</revnumber> <date>2002-09-29</date> <authorinitials>PB</authorinitials> <revremark>See <link linkend="revision-history">revision history</link> for more</revremark></revision>
<revision> <revnumber>Release 0.30</revnumber> <date>2002-09-27</date> <authorinitials>PB</authorinitials> <revremark>See <link linkend="revision-history">revision history</link> for more</revremark></revision>
</revhistory>
<abstract><para>The goal of the Linux IPv6 HOWTO is to answer both basic and advanced questions about IPv6 on the Linux operating system. This HOWTO will provide the reader with enough information to install, configure, and use IPv6 applications on Linux machines.</para></abstract></bookinfo>
<chapter id="chapter-general"><title>General</title><remark>CVS-ID: &dollar;Id: Linux+IPv6-HOWTO.lyx,v 1.35 2002/10/06 12:09:31 pbldp Exp &dollar;</remark><para>Information about available translations you will find in section <link linkend="general-translations">Translations</link>.</para><sect1 id="general-copright"><title>Copyright, license and others</title><sect2><title>Copyright</title><para>Written and Copyright (C) 2001-2002 by Peter Bieringer</para></sect2>
<chapter id="chapter-general"><title>General</title><remark>CVS-ID: &dollar;Id: Linux+IPv6-HOWTO.lyx,v 1.37 2002/11/18 19:01:55 pbldp Exp &dollar;</remark><para>Information about available translations you will find in section <link linkend="general-translations">Translations</link>.</para><sect1 id="general-copright"><title>Copyright, license and others</title><sect2><title>Copyright</title><para>Written and Copyright (C) 2001-2002 by Peter Bieringer</para></sect2>
<sect2><title>License</title><para>This Linux IPv6 HOWTO is published under GNU GPL version 2:
@ -75,7 +75,7 @@
<sect2><title>Linux operating system compatible hardware</title><para>Surely you wish to experiment with real hardware, and not only read this HOWTO to fall asleep here and there. :)</para></sect2>
</sect1>
</chapter>
<chapter id="chapter-basics"><title>Basics</title><sect1><title>What is IPv6?</title><para>IPv6 is a new layer 3 transport protocol (see <ulink url="http://www.linuxports.com/howto/intro_to_networking/c4412.htm#PAGE103HTML">linuxports/howto/intro_to_networking/ISO - OSI Model</ulink>) which will supersede IPv4 (also known as IP). IPv4 was designed long time ago (<ulink url="http://rfc.net/rfc760.html">RFC 760</ulink> from January 1980) and since its inception, there have been many requests for more addresses and enhanced capabilities. Major changes in IPv6 are the redesign of the header, including the increase of address size from 32 bits to 128 bits. Because layer 3 is responsible for end-to-end packet transport using packet routing based on addresses, it must include the new IPv6 addresses (source and destination), like IPv4.</para><para>For more information about the IPv6 history take a look at older IPv6 related RFCs listed e.g. at <ulink url="http://www.switch.ch/lan/ipv6/references.html">SWITCH IPv6 Pilot / References</ulink>.</para></sect1>
<chapter id="chapter-basics"><title>Basics</title><sect1><title>What is IPv6?</title><para>IPv6 is a new layer 3 transport protocol (see <ulink url="http://www.linuxports.com/howto/intro_to_networking/c4412.htm#PAGE103HTML">linuxports/howto/intro_to_networking/ISO - OSI Model</ulink>) which will supersede IPv4 (also known as IP). IPv4 was designed long time ago (<ulink url="http://www.faqs.org/rfcs/rfc760.html">RFC 760 / Internet Protocol</ulink> from January 1980) and since its inception, there have been many requests for more addresses and enhanced capabilities. Major changes in IPv6 are the redesign of the header, including the increase of address size from 32 bits to 128 bits. Because layer 3 is responsible for end-to-end packet transport using packet routing based on addresses, it must include the new IPv6 addresses (source and destination), like IPv4.</para><para>For more information about the IPv6 history take a look at older IPv6 related RFCs listed e.g. at <ulink url="http://www.switch.ch/lan/ipv6/references.html">SWITCH IPv6 Pilot / References</ulink>.</para></sect1>
<sect1 id="basic-history-IPv6-Linux"><title>History of IPv6 in Linux</title><para>To-do: better time-line, more content...</para><sect2><title>Beginning</title><para>The first IPv6 related network code was added to the Linux kernel 2.1.8 in November 1996 by Pedro Roque. It was based on the BSD API:</para><programlisting><![CDATA[diff -u --recursive --new-file v2.1.7/linux/include/linux/in6.h
]]><![CDATA[¬ linux/include/linux/in6.h
]]><![CDATA[--- v2.1.7/linux/include/linux/in6.h Thu Jan 1 02:00:00 1970
@ -103,10 +103,10 @@
]]><![CDATA[¬ 3ffe:ffff:100:f101:210:a4ff:fee3:9566
]]></programlisting><para>One sequence of 16 bit blocks containing only zeroes can be replaced with &quot;::&quot;. But not more than one at a time, otherwise it is no longer a unique representation. </para><programlisting><![CDATA[3ffe:ffff:100:f101:0:0:0:1 -> 3ffe:ffff:100:f101::1
]]></programlisting><para>The biggest reduction is seen by the IPv6 localhost address: </para><programlisting><![CDATA[0000:0000:0000:0000:0000:0000:0000:0001 -> ::1
]]></programlisting><para>There is also a so-called <emphasis>compact</emphasis> (base85 coded) representation defined <ulink url="http://rfc.net/rfc1924.html">RFC 1924 / A Compact Representation of IPv6 Addresses</ulink> (written 1996), never seen in the wild, but here is an example: </para><programlisting><![CDATA[# ipv6calc --addr_to_base85 3ffe:ffff:0100:f101:0210:a4ff:fee3:9566
]]></programlisting><para>There is also a so-called <emphasis>compact</emphasis> (base85 coded) representation defined <ulink url="http://www.faqs.org/rfcs/rfc1924.html">RFC 1924 / A Compact Representation of IPv6 Addresses</ulink> (written 1996), never seen in the wild, but here is an example: </para><programlisting><![CDATA[# ipv6calc --addr_to_base85 3ffe:ffff:0100:f101:0210:a4ff:fee3:9566
]]><![CDATA[Itu&-ZQ82s>J%s99FJXT
]]></programlisting><blockquote><para>Info: <emphasis>ipv6calc</emphasis> is an IPv6 address format calculator and converter program and can be found here: <ulink url="http://www.bieringer.de/linux/IPv6/ipv6calc/">ipv6calc</ulink></para></blockquote></sect1>
<sect1><title>FAQ (Basics)</title><sect2><title>Why is the name IPv6 and not IPv5 as successor for IPv4?</title><para>On any IP header, the first 4 bits are reserved for protocol version. So theoretically a protocol number between 0 and 15 is possible:</para><itemizedlist><listitem><para>4: is already used for IPv4</para></listitem><listitem><para>5: is reserved for the Stream Protocol (STP, <ulink url="http://rfc.net/rfc1819.html">RFC 1819</ulink>) (which never really made it to the public)</para></listitem></itemizedlist><para>The next free number was 6. Hence IPv6 was born!</para></sect2>
<sect1><title>FAQ (Basics)</title><sect2><title>Why is the name IPv6 and not IPv5 as successor for IPv4?</title><para>On any IP header, the first 4 bits are reserved for protocol version. So theoretically a protocol number between 0 and 15 is possible:</para><itemizedlist><listitem><para>4: is already used for IPv4</para></listitem><listitem><para>5: is reserved for the Stream Protocol (STP, <ulink url="http://www.faqs.org/rfcs/rfc1819.html">RFC 1819 / Internet Stream Protocol Version 2</ulink>) (which never really made it to the public)</para></listitem></itemizedlist><para>The next free number was 6. Hence IPv6 was born!</para></sect2>
<sect2><title>IPv6 addresses: why such a high number of bits?</title><para>During the design of IPv4, people thought that 32 bits were enough for the world. Looking back into the past, 32 bits were enough until now and will perhaps be enough for another few years. However, 32 bits are not enough to provide each network device with a global address in the future. Think about mobile phones, cars (including electronic devices on its CAN-bus), toasters, refrigerators, light switches, and so on...</para><para>So designers have chosen 128 bits, 4 times more in length and 2^96 greater in size than in IPv4 today.</para><para>The usable size is smaller than it may appear however. This is because in the currently defined address schema, 64 bits are used for interface identifiers. The other 64 bits are used for routing. Assuming the current strict levels of aggregation (/48, /35, ...), it is still possible to &quot;run out&quot; of space, but hopefully not in the near future.</para></sect2>
<sect2><title>IPv6 addresses: why so small a number of bits on a new design?</title><para>While, there are (possibly) some people on the Internet who are thinking about IPv8 and IPv16, their design is far away from acceptance and implementation. In the meantime 128 bits was the best choice regarding header overhead and data transport. Consider the minimum Maximum Transfer Unit (MTU) in IPv4 (576 octets) and in IPv6 (1280 octets), the header length in IPv4 is 20 octets (minimum, can increase to 60 octets with IPv4 options) and in IPv6 is 48 octets (fixed). This is 3.4 &percnt; of MTU in IPv4 and 3.8 &percnt; of MTU in IPv6. This means the header overhead is almost equal. More bits for addresses would require bigger headers and therefore more overhead. Also, consider the maximum MTU on normal links (like Ethernet today): it's 1500 octets (in special cases: 9k octets using Jumbo frames). Ultimately, it wouldn't be a proper design if 10 &percnt; or 20 &percnt; of transported data in a Layer-3 packet were used for addresses and not for payload.</para></sect2>
</sect1>
@ -127,18 +127,18 @@ BTW: a good URL for displaying a given IPv6 address in detail is the <ulink url=
]]></programlisting><para>These addresses are also used by automatic tunneling, which is being replaced by <link linkend="tunneling-6to4">6to4 tunneling</link>.</para></sect3>
</sect2>
</sect1>
<sect1><title>Network part, also known as prefix</title><para>Designers defined some address types and left a lot of scope for future definitions as currently unknown requirements arise. <ulink url="http://rfc.net/rfc2373.html">RFC 2373 [July 1998] / IP Version 6 Addressing Architecture</ulink> defines the current addressing scheme but there is already a new draft available: <ulink url="ftp://ftp.ietf.org/internet-drafts/">draft-ietf-ipngwg-addr-arch-*.txt</ulink>.</para><para>Now lets take a look at the different types of prefixes (and therefore address types):</para><sect2><title>Link local address type</title><para>These are special addresses which will only be valid on a link of an interface. Using this address as destination the packet would never pass through a router. It's used for link communications such as:</para><itemizedlist><listitem><para>anyone else here on this link?</para></listitem><listitem><para>anyone here with a special address (e.g. looking for a router)?</para></listitem></itemizedlist><para>They begin with ( where <emphasis>&quot;x&quot;</emphasis> is any hex character, normally <emphasis>&quot;0</emphasis>&quot;)</para><programlisting><![CDATA[fe8]]><emphasis><![CDATA[x: <- currently the only one in use.]]></emphasis><![CDATA[
<sect1><title>Network part, also known as prefix</title><para>Designers defined some address types and left a lot of scope for future definitions as currently unknown requirements arise. <ulink url="http://www.faqs.org/rfcs/rfc2373.html">RFC 2373 [July 1998] / IP Version 6 Addressing Architecture</ulink> defines the current addressing scheme but there is already a new draft available: <ulink url="ftp://ftp.ietf.org/internet-drafts/">draft-ietf-ipngwg-addr-arch-*.txt</ulink>.</para><para>Now lets take a look at the different types of prefixes (and therefore address types):</para><sect2><title>Link local address type</title><para>These are special addresses which will only be valid on a link of an interface. Using this address as destination the packet would never pass through a router. It's used for link communications such as:</para><itemizedlist><listitem><para>anyone else here on this link?</para></listitem><listitem><para>anyone here with a special address (e.g. looking for a router)?</para></listitem></itemizedlist><para>They begin with ( where <emphasis>&quot;x&quot;</emphasis> is any hex character, normally <emphasis>&quot;0</emphasis>&quot;)</para><programlisting><![CDATA[fe8]]><emphasis><![CDATA[x: <- currently the only one in use.]]></emphasis><![CDATA[
]]><![CDATA[fe9]]><emphasis><![CDATA[x:]]></emphasis><![CDATA[
]]><![CDATA[fea]]><emphasis><![CDATA[x:]]></emphasis><![CDATA[
]]><![CDATA[feb]]><emphasis><![CDATA[x:]]></emphasis><![CDATA[
]]></programlisting><para>An address with this prefix is found on each IPv6-enabled interface after stateless auto-configuration (which is normally always the case).</para><para>Note: only fe80 is currently in use.</para></sect2>
<sect2><title>Site local address type</title><para>These are addresses similar to the <ulink url="http://rfc.net/rfc1918.html">RFC 1918 / Address Allocation for Private Internets</ulink> in IPv4 today, with the added advantage that everyone who use this address type has the capability to use the given 16 bits for a maximum number of 65536 subnets. Comparable with the 10.0.0.0/8 in IPv4 today.</para><para>Another advantage: because it's possible to assign more than one address to an interface with IPv6, you can also assign such a site local address in addition to a global one.</para><para>It begins with: </para><programlisting><![CDATA[fec]]><emphasis><![CDATA[x: <- most commonly used.]]></emphasis><![CDATA[
<sect2><title>Site local address type</title><para>These are addresses similar to the <ulink url="http://www.faqs.org/rfcs/rfc1918.html">RFC 1918 / Address Allocation for Private Internets</ulink> in IPv4 today, with the added advantage that everyone who use this address type has the capability to use the given 16 bits for a maximum number of 65536 subnets. Comparable with the 10.0.0.0/8 in IPv4 today.</para><para>Another advantage: because it's possible to assign more than one address to an interface with IPv6, you can also assign such a site local address in addition to a global one.</para><para>It begins with: </para><programlisting><![CDATA[fec]]><emphasis><![CDATA[x: <- most commonly used.]]></emphasis><![CDATA[
]]><![CDATA[fed]]><emphasis><![CDATA[x:]]></emphasis><![CDATA[
]]><![CDATA[fee]]><emphasis><![CDATA[x:]]></emphasis><![CDATA[
]]><![CDATA[fef]]><emphasis><![CDATA[x:]]></emphasis><![CDATA[
]]><![CDATA[
]]></programlisting><para>(where<emphasis> &quot;x&quot;</emphasis> is any hex character, normally <emphasis>&quot;0</emphasis>&quot;) </para></sect2>
<sect2><title>Global address type &quot;(Aggregatable) global unicast&quot;</title><para>Today, there is one global address type defined (the first design, called &quot;provider based,&quot; was thrown away some years ago <ulink url="http://rfc.net/rfc1884.html">RFC 1884 / IP Version 6 Addressing Architecture [obsolete]</ulink>, you will find some remains in older Linux kernel sources).</para><para>It begins with (<emphasis>x</emphasis> are hex characters)</para><programlisting><![CDATA[2]]><emphasis><![CDATA[xxx]]></emphasis><![CDATA[:
<sect2><title>Global address type &quot;(Aggregatable) global unicast&quot;</title><para>Today, there is one global address type defined (the first design, called &quot;provider based,&quot; was thrown away some years ago <ulink url="http://www.faqs.org/rfcs/rfc1884.html">RFC 1884 / IP Version 6 Addressing Architecture [obsolete]</ulink>, you will find some remains in older Linux kernel sources).</para><para>It begins with (<emphasis>x</emphasis> are hex characters)</para><programlisting><![CDATA[2]]><emphasis><![CDATA[xxx]]></emphasis><![CDATA[:
]]><![CDATA[3]]><emphasis><![CDATA[xxx]]></emphasis><![CDATA[:
]]></programlisting><para>Note: the prefix &quot;aggregatable&quot; is thrown away in current drafts.
There are some further subtypes defined, see below:</para><sect3><title>6bone test addresses</title><para>These were the first global addresses which were defined and in use. They all start with </para><programlisting><![CDATA[3ffe:
@ -147,7 +147,7 @@ There are some further subtypes defined, see below:</para><sect3><title>6bone te
]]></programlisting><para>and is mostly shown in examples, because if real addresses are shown, its possible for someone to do a copy &amp; paste to their configuration files. Thus inadvertently causing duplicates on a globally unique address. This would cause serious problems for the original host (e.g. getting answer packets for request that were never sent).
You can still apply for one of these prefixes, see here <ulink url="http://www.6bone.net/6bone_hookup.html">How to join 6bone</ulink>. Also some <link linkend="information-joinipv6-tunnelbrokers">tunnel brokers</link> still distribute 6bone test address prefixes.</para></sect3>
<sect3><title>6to4 addresses</title><para>These addresses, designed for a special tunneling mechanism &lsqb;<ulink url="http://rfc.net/rfc3056.html">RFC 3056 / Connection of IPv6 Domains via IPv4 Clouds</ulink> and <ulink url="http://rfc.net/rfc2893.html">RFC 2893 / Transition Mechanisms for IPv6 Hosts and Routers</ulink>&rsqb;, encode a given IPv4 address and a possible subnet and begin with </para><programlisting><![CDATA[2002:
<sect3><title>6to4 addresses</title><para>These addresses, designed for a special tunneling mechanism &lsqb;<ulink url="http://www.faqs.org/rfcs/rfc3056.html">RFC 3056 / Connection of IPv6 Domains via IPv4 Clouds</ulink> and <ulink url="http://www.faqs.org/rfcs/rfc2893.html">RFC 2893 / Transition Mechanisms for IPv6 Hosts and Routers</ulink>&rsqb;, encode a given IPv4 address and a possible subnet and begin with </para><programlisting><![CDATA[2002:
]]></programlisting><para>For example, representing 192.168.1.1/5:</para><programlisting><![CDATA[2002:c0a8:0101:5::1
]]></programlisting><para>A small shell command line can help you generating such address out of a given IPv4 one:</para><programlisting><![CDATA[ipv4="1.2.3.4"; sla="5"; printf "2002:%02x%02x:%02x%02x:%04x::1" `echo $ipv4 | tr "." " "` $sla
]]></programlisting><para>See also <link linkend="tunneling-6to4">tunneling using 6to4</link> and <link linkend="information-joinipv6-6to4-tunneling">information about 6to4 relay routers</link>.</para></sect3>
@ -156,7 +156,7 @@ You can still apply for one of these prefixes, see here <ulink url="http://www.6
</sect2>
<sect2><title>Multicast addresses</title><para>Multicast addresses are used for related services. </para><para>They alway start with (<emphasis>xx</emphasis> is the scope value)</para><programlisting><![CDATA[ff]]><emphasis><![CDATA[x]]></emphasis><![CDATA[y:
]]></programlisting><para>They are split into scopes and types:</para><sect3><title>Multicast scopes</title><para>Multicast scope is a parameter to specify the maximum distance a multicast packet can travel from the sending entity.</para><para>Currently, the following regions (scopes) are defined:</para><itemizedlist><listitem><para>ffx1: node-local, packets never leave the node.</para></listitem><listitem><para>ffx2: link-local, packets are never forwarded by routers, so they never leave the specified link.</para></listitem><listitem><para>ffx5: site-local, packets never leave the site.</para></listitem><listitem><para>ffx8: organization-local, packets never leave the organization (not so easy to implement, must be covered by routing protocol).</para></listitem><listitem><para>ffxe: global scope.</para></listitem><listitem><para>others are reserved</para></listitem></itemizedlist></sect3>
<sect3><title>Multicast types</title><para>There are many types already defined/reserved (see <ulink url="http://rfc.net/rfc2373.html">RFC 2373 / IP Version 6 Addressing Architecture</ulink> for details). Some examples are:</para><itemizedlist><listitem><para>All Nodes Address: ID = 1h, addresses all hosts on the local node (ff01:0:0:0:0:0:0:1) or the connected link (ff02:0:0:0:0:0:0:1).</para></listitem><listitem><para>All Routers Address: ID = 2h, addresses all routers on the local node (ff01:0:0:0:0:0:0:2), on the connected link (ff02:0:0:0:0:0:0:2), or on the local site (ff05:0:0:0:0:0:0:2)</para></listitem></itemizedlist></sect3>
<sect3><title>Multicast types</title><para>There are many types already defined/reserved (see <ulink url="http://www.faqs.org/rfcs/rfc2373.html">RFC 2373 / IP Version 6 Addressing Architecture</ulink> for details). Some examples are:</para><itemizedlist><listitem><para>All Nodes Address: ID = 1h, addresses all hosts on the local node (ff01:0:0:0:0:0:0:1) or the connected link (ff02:0:0:0:0:0:0:1).</para></listitem><listitem><para>All Routers Address: ID = 2h, addresses all routers on the local node (ff01:0:0:0:0:0:0:2), on the connected link (ff02:0:0:0:0:0:0:2), or on the local site (ff05:0:0:0:0:0:0:2)</para></listitem></itemizedlist></sect3>
<sect3><title>Solicited node link-local multicast address</title><para>Special multicast address used as destination address in neighborhood discovery, because unlike in IPv4, ARP no longer exists in IPv6.</para><para>An example of this address looks like</para><programlisting><![CDATA[ff02::1:ff00:1234
]]></programlisting><para>Used prefix shows that this is a link-local multicast address. The suffix is generated from the destination address. In this example, a packet should be sent to address &quot;fe80::1234&quot;, but the network stack doesn't know the current layer 2 MAC address. It replaces the upper 104 bits with &quot;ff02:0:0:0:0:1:ff00::/104&quot; and leaves the lower 24 bits untouched. This address is now used `on-link' to find the corresponding node which has to send a reply containing its layer 2 MAC address.</para></sect3>
</sect2>
@ -168,12 +168,12 @@ You can still apply for one of these prefixes, see here <ulink url="http://www.6
<sect1><title>Address types (host part)</title><para>For auto-configuration and mobility issues, it was decided to use the lower 64 bits as host part of the address in most of the current address types. Therefore each single subnet can hold a large amount of addresses.</para><para>This host part can be inspected differently: </para><sect2><title>Automatically computed (also known as stateless)</title><para>With auto-configuration, the host part of the address is computed by converting the MAC address of an interface (if available), with the EUI-64 method, to a unique IPv6 address. If no MAC address is available (happens e.g. on virtual devices), something else (like the IPv4 addresses or the MAC address of a physical interface) is used instead.</para><para>Consider again the first example </para><programlisting><![CDATA[3ffe:ffff:100:f101:210:a4ff:fee3:9566
]]></programlisting><para>here, </para><programlisting><![CDATA[210:a4ff:fee3:9566
]]></programlisting><para>is the host part and computed from the NIC's MAC address </para><programlisting><![CDATA[00:10:A4:E3:95:66
]]></programlisting><para>using the <ulink url="http://standards.ieee.org/regauth/oui/tutorials/EUI64.html">IEEE-Tutorial EUI-64</ulink> design for EUI-48 identifiers.</para><sect3><title>Privacy problem with automatically computed and solution</title><para>Because the &quot;automatically computed&quot; host part is globally unique (except when a vendor of a NIC uses the same MAC address on more than one NIC), client tracking is possible on the host when not using a proxy of any kind.</para><para>This is a known problem, and a solution was defined: privacy extension, defined in <ulink url="http://rfc.net/rfc3041.html">RFC 3041 / Privacy Extensions for Stateless Address Autoconfiguration in IPv6</ulink> (there is also already a newer draft available: <ulink url="ftp://ftp.ietf.org/internet-drafts/">draft-ietf-ipngwg-temp-addresses-*.txt</ulink>). Using a random and a static value a new suffix is generated from time to time. Note: this is only reasonable for outgoing client connections and isn't really useful for well-known servers.</para></sect3>
]]></programlisting><para>using the <ulink url="http://standards.ieee.org/regauth/oui/tutorials/EUI64.html">IEEE-Tutorial EUI-64</ulink> design for EUI-48 identifiers.</para><sect3><title>Privacy problem with automatically computed and solution</title><para>Because the &quot;automatically computed&quot; host part is globally unique (except when a vendor of a NIC uses the same MAC address on more than one NIC), client tracking is possible on the host when not using a proxy of any kind.</para><para>This is a known problem, and a solution was defined: privacy extension, defined in <ulink url="http://www.faqs.org/rfcs/rfc3041.html">RFC 3041 / Privacy Extensions for Stateless Address Autoconfiguration in IPv6</ulink> (there is also already a newer draft available: <ulink url="ftp://ftp.ietf.org/internet-drafts/">draft-ietf-ipngwg-temp-addresses-*.txt</ulink>). Using a random and a static value a new suffix is generated from time to time. Note: this is only reasonable for outgoing client connections and isn't really useful for well-known servers.</para></sect3>
</sect2>
<sect2><title>Manually set</title><para>For servers it's probably easier to remember simpler addresses, this can also be accommodated. It is possible to assign an additional IPv6 address to an interface, e.g. </para><programlisting><![CDATA[3ffe:ffff:100:f101::1
]]></programlisting><para>For manual suffixes like &quot;::1&quot; shown in the above example it's required that the 6th most significant bit is set to 0 (the universal/local bit of the automatically generated identifier). Also some other (otherwise unchosen ) bit combinations are reserved for anycast addresses, too.</para></sect2>
</sect1>
<sect1><title>Prefix lengths for routing</title><para>In the early design phase it was planned to use a fully hierarchical routing approach to reduce the size of the routing tables maximally. The reasoning behind this approach were the number of current IPv4 routing entries in core routers (&gt; 104 thousand in May 2001), reducing the need of memory in hardware routers (ASIC driven) to hold the routing table and increase speed (fewer entries hopefully result in faster lookups).</para><para>Todays view is that routing will be mostly hierarchically designed for networks with only one service provider. With more than one ISP connections, this is not possible, and subject to an issue named multi-homing.</para><sect2><title>Prefix lengths (also known as &quot;netmasks&quot;)</title><para>Similar to IPv4, the routable network path for routing to take place. Because standard netmask notation for 128 bits doesn't look nice, designers employed the IPv4 Classless Inter Domain Routing (CIDR, <ulink url="http://rfc.net/rfc1519.html">RFC 1519 / Classless Inter-Domain Routing</ulink>) scheme, which specifies the number of bits of the IP address to be used for routing. It is also called the &quot;slash&quot; notation.</para><para>An example: </para><programlisting><![CDATA[3ffe:ffff:100:1:2:3:4:5/48
<sect1><title>Prefix lengths for routing</title><para>In the early design phase it was planned to use a fully hierarchical routing approach to reduce the size of the routing tables maximally. The reasoning behind this approach were the number of current IPv4 routing entries in core routers (&gt; 104 thousand in May 2001), reducing the need of memory in hardware routers (ASIC driven) to hold the routing table and increase speed (fewer entries hopefully result in faster lookups).</para><para>Todays view is that routing will be mostly hierarchically designed for networks with only one service provider. With more than one ISP connections, this is not possible, and subject to an issue named multi-homing.</para><sect2><title>Prefix lengths (also known as &quot;netmasks&quot;)</title><para>Similar to IPv4, the routable network path for routing to take place. Because standard netmask notation for 128 bits doesn't look nice, designers employed the IPv4 Classless Inter Domain Routing (CIDR, <ulink url="http://www.faqs.org/rfcs/rfc1519.html">RFC 1519 / Classless Inter-Domain Routing</ulink>) scheme, which specifies the number of bits of the IP address to be used for routing. It is also called the &quot;slash&quot; notation.</para><para>An example: </para><programlisting><![CDATA[3ffe:ffff:100:1:2:3:4:5/48
]]></programlisting><para>This notation will be expanded:</para><itemizedlist><listitem><para>Network: </para></listitem></itemizedlist><programlisting><![CDATA[3ffe:ffff:0100:0000:0000:0000:0000:0000
]]></programlisting><itemizedlist><listitem><para>Net-mask: </para></listitem></itemizedlist><programlisting><![CDATA[ffff:ffff:ffff:0000:0000:0000:0000:0000
]]></programlisting></sect2>
@ -196,7 +196,7 @@ You can still apply for one of these prefixes, see here <ulink url="http://www.6
<sect2><title>Compile kernel with IPv6 capabilities</title><para>If both above shown results were negative and your kernel has no IP6 support, than you have the following options:</para><itemizedlist><listitem><para>Update your distribution to a current one which supports IPv6 out-of-the-box (recommended for newbies), see here again: <ulink url="http://www.bieringer.de/linux/IPv6/status/IPv6+Linux-status-distributions.html">IPv6+Linux-Status-Distribution</ulink></para></listitem><listitem><para>Compile a new vanilla kernel (easy, if you know which options you needed)</para></listitem><listitem><para>Recompile kernel sources given by your Linux distribution (sometimes not so easy)</para></listitem><listitem><para>Compile a kernel with USAGI extensions</para></listitem></itemizedlist><para>If you decide to compile a kernel, you should have previous experience in kernel compiling and read the <ulink url="http://www.linuxdoc.org/HOWTO/Kernel-HOWTO.html">Linux Kernel HOWTO</ulink>.</para><para>A mostly up-to-time comparison between vanilla and USAGI extended kernels is available on <ulink url="http://www.bieringer.de/linux/IPv6/status/IPv6+Linux-status-kernel.html">IPv6+Linux-Status-Kernel</ulink>.</para><sect3><title>Compiling a vanilla kernel</title><para>More detailed hints about compiling an IPv6-enabled kernel can be found e.g. on <ulink url="http://www.bieringer.de/linux/IPv6/IPv6-HOWTO/IPv6-HOWTO-2.html#kernel">IPv6-HOWTO-2#kernel</ulink>.</para><para>Note: you should use whenever possible kernel series 2.4.x or above, because the IPv6 support in series 2.2.x is not so in current state and needs some patches for ICMPv6 and 6to4 support (can be found on <ulink url="ftp://ftp.bieringer.de/pub/linux/IPv6/kernel">kernel series 2.2.x IPv6 patches</ulink>).</para></sect3>
<sect3><title>Compiling a kernel with USAGI extensions</title><para>Same as for vanilla kernel, only recommend for advanced users, which are already familiar with IPv6 and kernel compilation. See also <ulink url="http://www.linux-ipv6.org/faq.html">USAGI project / FAQ</ulink>.</para></sect3>
</sect2>
<sect2><title>IPv6-ready network devices</title><para>Not all existing network devices have already (or ever) the capability to transport IPv6 packets. A current status can be found at <ulink url="http://www.bieringer.de/linux/IPv6/status/IPv6+Linux-status-kernel.html#transport">IPv6+Linux-status-kernel.html#transport</ulink>.</para><para>A major issue is that because of the network layer structure of kernel implementation an IPv6 packet isn't really recognized by it's IP header number (6 instead of 4). It's recognized by the protocol number of the Layer 2 transport protocol. Therefore any transport protocol which doesn't use such protocol number cannot dispatch IPv6 packets. Note: the packet is still transported over the link, but on receivers side, the dispatching won't work (you can see this e.g. using tcpdump).</para><sect3><title>Currently known never &quot;IPv6 capable links&quot;</title><itemizedlist><listitem><para>Serial Line IP (SLIP, <ulink url="http://rfc.net/rfc1055.html">RFC 1055</ulink>), should be better called now to SLIPv4, device named: slX</para></listitem><listitem><para>Parallel Line IP (PLIP), same like SLIP, device names: plipX</para></listitem><listitem><para>ISDN with encapsulation <emphasis>rawip</emphasis>, device names: isdnX</para></listitem></itemizedlist></sect3>
<sect2><title>IPv6-ready network devices</title><para>Not all existing network devices have already (or ever) the capability to transport IPv6 packets. A current status can be found at <ulink url="http://www.bieringer.de/linux/IPv6/status/IPv6+Linux-status-kernel.html#transport">IPv6+Linux-status-kernel.html#transport</ulink>.</para><para>A major issue is that because of the network layer structure of kernel implementation an IPv6 packet isn't really recognized by it's IP header number (6 instead of 4). It's recognized by the protocol number of the Layer 2 transport protocol. Therefore any transport protocol which doesn't use such protocol number cannot dispatch IPv6 packets. Note: the packet is still transported over the link, but on receivers side, the dispatching won't work (you can see this e.g. using tcpdump).</para><sect3><title>Currently known never &quot;IPv6 capable links&quot;</title><itemizedlist><listitem><para>Serial Line IP (SLIP, <ulink url="http://www.faqs.org/rfcs/rfc1055.html">RFC 1055 / SLIP</ulink>), should be better called now to SLIPv4, device named: slX</para></listitem><listitem><para>Parallel Line IP (PLIP), same like SLIP, device names: plipX</para></listitem><listitem><para>ISDN with encapsulation <emphasis>rawip</emphasis>, device names: isdnX</para></listitem></itemizedlist></sect3>
<sect3><title>Currently known &quot;not supported IPv6 capable links&quot;</title><itemizedlist><listitem><para>ISDN with encapsulation <emphasis>syncppp</emphasis>, device names: ipppX (design issue of the ipppd, will be merged into more general PPP layer in kernel series 2.5.x)</para></listitem></itemizedlist></sect3>
</sect2>
</sect1>
@ -450,9 +450,9 @@ You can still apply for one of these prefixes, see here <ulink url="http://www.6
]]></programlisting><para>Looks like some options are only for IPv4...if you can contribute information about flags and advanced usage, pls. send.</para></sect2>
</sect1>
</chapter>
<chapter id="chapter-configuring-ipv6-in-ipv4-tunnels"><title>Configuring IPv6-in-IPv4 tunnels</title><para>If you want to leave your link you have no IPv6 capable network around you, you need IPv6-in-IPv4 tunneling to reach the World Wide IPv6-Internet.</para><para>There are some kind of tunnel mechanism and also some possibilities to setup tunnels.</para><sect1><title>Types of tunnels</title><para>There are more than one possibility to tunnel IPv6 packets over IPv4-only links.</para><sect2><title>Static point-to-point tunneling: 6bone</title><para>A point-to-point tunnel is a dedicated tunnel to an endpoint, which knows about your IPv6 network (for backward routing) and the IPv4 address of your tunnel endpoint and defined in <ulink url="http://rfc.net/rfc2893.html">RFC 2893 / Transition Mechanisms for IPv6 Hosts and Routers</ulink>. Requirements:</para><itemizedlist><listitem><para>IPv4 address of your local tunnel endpoint must be static, global unique and reachable from the foreign tunnel endpoint</para></listitem><listitem><para>A global IPv6 prefix assigned to you (see 6bone registry)</para></listitem><listitem><para>A foreign tunnel endpoint which is capable to route your IPv6 prefix to your local tunnel endpoint (mostly remote manual configuration required)</para></listitem></itemizedlist></sect2>
<chapter id="chapter-configuring-ipv6-in-ipv4-tunnels"><title>Configuring IPv6-in-IPv4 tunnels</title><para>If you want to leave your link you have no IPv6 capable network around you, you need IPv6-in-IPv4 tunneling to reach the World Wide IPv6-Internet.</para><para>There are some kind of tunnel mechanism and also some possibilities to setup tunnels.</para><sect1><title>Types of tunnels</title><para>There are more than one possibility to tunnel IPv6 packets over IPv4-only links.</para><sect2><title>Static point-to-point tunneling: 6bone</title><para>A point-to-point tunnel is a dedicated tunnel to an endpoint, which knows about your IPv6 network (for backward routing) and the IPv4 address of your tunnel endpoint and defined in <ulink url="http://www.faqs.org/rfcs/rfc2893.html">RFC 2893 / Transition Mechanisms for IPv6 Hosts and Routers</ulink>. Requirements:</para><itemizedlist><listitem><para>IPv4 address of your local tunnel endpoint must be static, global unique and reachable from the foreign tunnel endpoint</para></listitem><listitem><para>A global IPv6 prefix assigned to you (see 6bone registry)</para></listitem><listitem><para>A foreign tunnel endpoint which is capable to route your IPv6 prefix to your local tunnel endpoint (mostly remote manual configuration required)</para></listitem></itemizedlist></sect2>
<sect2><title>Automatically tunneling</title><para>Automatic tunneling occurs, when a node directly connects another node gotten the IPv4 address of the other node before.</para></sect2>
<sect2 id="tunneling-6to4"><title>6to4-Tunneling</title><para>6to4 tunneling (<ulink url="http://rfc.net/rfc3056.html">RFC 3056 / Connection of IPv6 Domains via IPv4 Clouds</ulink>) uses a simple mechanism to create automatic tunnels. Each node with a global unique IPv4 address is able to be a 6to4 tunnel endpoint (if no IPv4 firewall prohibits traffic). 6to4 tunneling is mostly not a one-to-one tunnel. This case of tunneling can be divided into upstream and downstream tunneling. Also, a special IPv6 address indicates that this node will use 6to4 tunneling for connecting the world-wide IPv6 network</para><sect3><title>Generation of 6to4 prefix</title><para>The 6to4 address is defined like following (schema is taken from <ulink url="http://rfc.net/rfc3056.html">RFC 3056 / Connection of IPv6 Domains via IPv4 Clouds</ulink>):</para><programlisting><![CDATA[| 3+13 | 32 | 16 | 64 bits |
<sect2 id="tunneling-6to4"><title>6to4-Tunneling</title><para>6to4 tunneling (<ulink url="http://www.faqs.org/rfcs/rfc3056.html">RFC 3056 / Connection of IPv6 Domains via IPv4 Clouds</ulink>) uses a simple mechanism to create automatic tunnels. Each node with a global unique IPv4 address is able to be a 6to4 tunnel endpoint (if no IPv4 firewall prohibits traffic). 6to4 tunneling is mostly not a one-to-one tunnel. This case of tunneling can be divided into upstream and downstream tunneling. Also, a special IPv6 address indicates that this node will use 6to4 tunneling for connecting the world-wide IPv6 network</para><sect3><title>Generation of 6to4 prefix</title><para>The 6to4 address is defined like following (schema is taken from <ulink url="http://www.faqs.org/rfcs/rfc3056.html">RFC 3056 / Connection of IPv6 Domains via IPv4 Clouds</ulink>):</para><programlisting><![CDATA[| 3+13 | 32 | 16 | 64 bits |
]]><![CDATA[+---+------+-----------+--------+--------------------------------+
]]><![CDATA[| FP+TLA | V4ADDR | SLA ID | Interface ID |
]]><![CDATA[| 0x2002 | | | |
@ -580,7 +580,7 @@ You can still apply for one of these prefixes, see here <ulink url="http://www.6
</sect2>
</sect1>
</chapter>
<chapter id="chapter-configuring-ipv4-in-ipv6-tunnels"><title>Configuring IPv4-in-IPv6 tunnels</title><para>This will be filled in the future. At the moment, such tunnels are more used in test environments.</para><para>More information in the meantime: <ulink url="http://rfc.net/rfc2473.html">RFC 2473 / Generic Packet Tunneling in IPv6 Specification</ulink></para></chapter>
<chapter id="chapter-configuring-ipv4-in-ipv6-tunnels"><title>Configuring IPv4-in-IPv6 tunnels</title><para>This will be filled in the future. At the moment, such tunnels are more used in test environments.</para><para>More information in the meantime: <ulink url="http://www.faqs.org/rfcs/rfc2473.html">RFC 2473 / Generic Packet Tunneling in IPv6 Specification</ulink></para></chapter>
<chapter id="chapter-kernel-settings"><title><anchor id="proc-filesystem">Kernel settings in /proc-filesystem</title><para>Note: the source of this section is mostly the file &quot;ip-sysctl.txt&quot; which is included in current kernel sources in directory &quot;Documentation/networking&quot;. Credits to Pekka Savola for maintaining the IPv6-related part in this file. Also some text is more or less copied &amp; pasted into this document.</para><sect1><title>How to access the /proc-filesystem</title><sect2><title>Using &quot;cat&quot; and &quot;echo&quot;</title><para>Using &quot;cat&quot; and &quot;echo&quot; is the simplest way to access the /proc filesystem, but two requirements are needed for that</para><itemizedlist><listitem><para>The /proc-filesystem had to be enabled in kernel, means on compiling following switch has to be set</para></listitem></itemizedlist><programlisting><![CDATA[CONFIG_PROC_FS=y
]]></programlisting><itemizedlist><listitem><para>The /proc-filesystem was mounted before, which can be tested using</para></listitem></itemizedlist><programlisting><![CDATA[# mount | grep "type proc"
]]><![CDATA[none on /proc type proc (rw)
@ -813,7 +813,7 @@ In versions 8.x they completly change their configuration setup. </para><sect2><
<sect1><title>Dynamic Host Configuration Protocol v6 (DHCPv6)</title><para>to be filled.</para></sect1>
<sect1><title>Mobility</title><para>to be filled.</para><para>For the moment, see <ulink url="http://www.mipl.mediapoli.com/">Mobile IPv6 for Linux(MIPL) homepage</ulink> for more details</para></sect1>
</chapter>
<chapter id="chapter-firewalling-security"><title>Firewalling</title><para>IPv6 firewalling is important, especially if using IPv6 on internal networks with global IPv6 addresses. Because unlike at IPv4 networks where in common internal hosts are protected automatically using private IPv4 addresses like <ulink url="http://rfc.net/rfc1918.html">RFC 1918 / Address Allocation for Private Internets</ulink> or <ulink url="http://www.glossary-tech.com/apipa.htm">APIPA / Automatic Private IP Addressing</ulink>, in IPv6 normally global addresses are used and someone with IPv6 connectivity can reach all internal IPv6 enabled nodes.</para><sect1 id="firewalling-netfilter6"><title>Firewalling using netfilter6 </title><para>Native IPv6 firewalling is only supported in kernel versions 2.4+. In older 2.2- you can only filter IPv6-in-IPv4 by protocol 41. </para><para>Attention: no warranty that described rules or examples are really protect your system! </para><para>Audit your ruleset after installation, see <xref linkend="IPv6-security-auditing"> for more.</para><sect2><title>More information</title><itemizedlist><listitem><para><ulink url="http://www.netfilter.org/">Netfilter project</ulink></para></listitem><listitem><para><ulink url="http://lists.samba.org/pipermail/netfilter/">maillist archive of netfilter users</ulink></para></listitem><listitem><para><ulink url="http://lists.samba.org/pipermail/netfilter-devel/">maillist archive of netfilter developers</ulink></para></listitem><listitem><para><ulink url="http://www.bieringer.de/linux/IPv6/status/IPv6+Linux-status-kernel.html#netfilter6 ">Unofficial status informations</ulink></para></listitem></itemizedlist></sect2>
<chapter id="chapter-firewalling-security"><title>Firewalling</title><para>IPv6 firewalling is important, especially if using IPv6 on internal networks with global IPv6 addresses. Because unlike at IPv4 networks where in common internal hosts are protected automatically using private IPv4 addresses like <ulink url="http://www.faqs.org/rfcs/rfc1918.html">RFC 1918 / Address Allocation for Private Internets</ulink> or <ulink url="http://www.glossary-tech.com/apipa.htm">APIPA / Automatic Private IP Addressing</ulink>, in IPv6 normally global addresses are used and someone with IPv6 connectivity can reach all internal IPv6 enabled nodes.</para><sect1 id="firewalling-netfilter6"><title>Firewalling using netfilter6 </title><para>Native IPv6 firewalling is only supported in kernel versions 2.4+. In older 2.2- you can only filter IPv6-in-IPv4 by protocol 41. </para><para>Attention: no warranty that described rules or examples are really protect your system! </para><para>Audit your ruleset after installation, see <xref linkend="IPv6-security-auditing"> for more.</para><sect2><title>More information</title><itemizedlist><listitem><para><ulink url="http://www.netfilter.org/">Netfilter project</ulink></para></listitem><listitem><para><ulink url="http://lists.samba.org/pipermail/netfilter/">maillist archive of netfilter users</ulink></para></listitem><listitem><para><ulink url="http://lists.samba.org/pipermail/netfilter-devel/">maillist archive of netfilter developers</ulink></para></listitem><listitem><para><ulink url="http://www.bieringer.de/linux/IPv6/status/IPv6+Linux-status-kernel.html#netfilter6 ">Unofficial status informations</ulink></para></listitem></itemizedlist></sect2>
</sect1>
<sect1><title>Preparation</title><sect2><title>Get sources</title><para>Get the latest kernel source: <ulink url="http://www.kernel.org/">http://www.kernel.org/</ulink></para><para>Get the latest iptables package: </para><itemizedlist><listitem><para>Source tarball (for kernel patches): <ulink url="http://www.netfilter.org/">http://www.netfilter.org/</ulink></para></listitem><listitem><para>Source RPM for rebuild of binary (for RedHat systems): <ulink url="ftp://ftp.redhat.com/redhat/linux/rawhide/SRPMS/SRPMS/">ftp://ftp.redhat.com/redhat/linux/rawhide/SRPMS/SRPMS/</ulink> or perhaps also at <ulink url="http://www.netcore.fi/pekkas/linux/ipv6/ ">http://www.netcore.fi/pekkas/linux/ipv6/ </ulink></para></listitem></itemizedlist></sect2>
<sect2><title>Extract sources</title><para>Change to source directory: </para><programlisting><![CDATA[# cd /path/to/src
@ -1086,7 +1086,7 @@ CHECK destination IPv6 addresses TWICE before starting a scan.</para></sect2>
<sect3><title>Notify source address </title><para>Notify source address is used for outgoing notify messages:</para><programlisting><![CDATA[notify-source-v6 <ipv6addr|*> [port port];
]]></programlisting></sect3>
</sect2>
<sect2><title>Serving IPv6 related DNS data</title><para>For IPv6 new types and root zones for reverse lookups are defined:</para><itemizedlist><listitem><para>AAAA and reverse IP6.INT: specified in <ulink url="http://rfc.net/rfc1886.html">RFC 1886 / DNS Extensions to support IP version 6</ulink>, usable since BIND version 4.9.6</para></listitem><listitem><para>A6, DNAME (DEPRICATED NOW!) and reverse IP6.ARPA: specified in <ulink url="http://rfc.net/rfc2874.html">RFC 2874 / DNS Extensions to Support IPv6 Address Aggregation and Renumbering</ulink>, usable since BIND 9, but see also an information about the current state at <ulink url="http://www.ietf.org/internet-drafts/">draft-ietf-dnsext-ipv6-addresses-00.txt</ulink></para></listitem></itemizedlist><para>Perhaps filled later more content, for the meantime take a look at given RFCs and</para><itemizedlist><listitem><para>AAAA and reverse IP6.INT: <ulink url="http://www.isi.edu/~bmanning/v6DNS.html">IPv6 DNS Setup Information</ulink></para></listitem><listitem><para>A6, DNAME (DEPRICATED NOW!) and reverse IP6.ARPA: take a look into chapter 4 and 6 of the BIND 9 Administrator Reference Manual (ARM) distributed which the bind-package or get this here: <ulink url="http://www.nominum.com/resources/documentation/Bv9ARM.pdf">BIND version 9 ARM (PDF)</ulink></para></listitem></itemizedlist><para>Because IP6.INT is deprecated (but still in use), a DNS server which will support IPv6 information has to serve both reverse zones.</para><sect3><title>Current best practice</title><para>Because there are some troubles around using the new formats, current best practice is:</para><para>Forward lookup support:</para><itemizedlist><listitem><para>AAAA</para></listitem></itemizedlist><para>Reverse lookup support:</para><itemizedlist><listitem><para>Reverse nibble format for zone ip6.int (FOR BACKWARD COMPATIBILITY)</para></listitem><listitem><para>Reverse nibble format for zone ip6.arpa (RECOMMENDED)</para></listitem></itemizedlist></sect3>
<sect2><title>Serving IPv6 related DNS data</title><para>For IPv6 new types and root zones for reverse lookups are defined:</para><itemizedlist><listitem><para>AAAA and reverse IP6.INT: specified in <ulink url="http://www.faqs.org/rfcs/rfc1886.html">RFC 1886 / DNS Extensions to support IP version 6</ulink>, usable since BIND version 4.9.6</para></listitem><listitem><para>A6, DNAME (DEPRICATED NOW!) and reverse IP6.ARPA: specified in <ulink url="http://www.faqs.org/rfcs/rfc2874.html">RFC 2874 / DNS Extensions to Support IPv6 Address Aggregation and Renumbering</ulink>, usable since BIND 9, but see also an information about the current state at <ulink url="http://www.ietf.org/internet-drafts/">draft-ietf-dnsext-ipv6-addresses-00.txt</ulink></para></listitem></itemizedlist><para>Perhaps filled later more content, for the meantime take a look at given RFCs and</para><itemizedlist><listitem><para>AAAA and reverse IP6.INT: <ulink url="http://www.isi.edu/~bmanning/v6DNS.html">IPv6 DNS Setup Information</ulink></para></listitem><listitem><para>A6, DNAME (DEPRICATED NOW!) and reverse IP6.ARPA: take a look into chapter 4 and 6 of the BIND 9 Administrator Reference Manual (ARM) distributed which the bind-package or get this here: <ulink url="http://www.nominum.com/resources/documentation/Bv9ARM.pdf">BIND version 9 ARM (PDF)</ulink></para></listitem></itemizedlist><para>Because IP6.INT is deprecated (but still in use), a DNS server which will support IPv6 information has to serve both reverse zones.</para><sect3><title>Current best practice</title><para>Because there are some troubles around using the new formats, current best practice is:</para><para>Forward lookup support:</para><itemizedlist><listitem><para>AAAA</para></listitem></itemizedlist><para>Reverse lookup support:</para><itemizedlist><listitem><para>Reverse nibble format for zone ip6.int (FOR BACKWARD COMPATIBILITY)</para></listitem><listitem><para>Reverse nibble format for zone ip6.arpa (RECOMMENDED)</para></listitem></itemizedlist></sect3>
</sect2>
<sect2><title>Checking IPv6-enabled connect</title><para>To check, whether BIND is listening on an IPv6 socket and serving data see following examples.</para><sect3><title>IPv6 connect, but denied by ACL</title><para>Specifying a dedicated server for the query, an IPv6 connect can be forced:</para><programlisting><![CDATA[$ host -t aaaa www.6bone.net 3ffe:ffff:200:f101::1
]]><![CDATA[Using domain server:
@ -1424,7 +1424,8 @@ Kurz angerissen werden: RFC1825 - Security Association Konzept RFC1826 - IP auth
</tgroup></informaltable>
</para><para>(1) recommended for common Linux &amp; IPv6 issues.</para><para>(2) very recommended if you provide server applications.</para><para>Something missing? Suggestions are welcome!</para><para>Another list is available at <ulink url="http://www.join.uni-muenster.de/JOIN/ipv6/texte-englisch/ipv6.infoquellen.html">JOIN Project / List of IPv6-related maillists</ulink>.</para></sect1>
</chapter>
<chapter><title>Revision history / Credits / The End</title><sect1 id="revision-history"><title>Revision history</title><para>Versions x.y are published on the Internet.</para><para>Versions x.y.z are work-in-progress and only published as LyX file on CVS.</para><sect2><title>Releases 0.x</title><variablelist><varlistentry><term>0.32
<chapter><title>Revision history / Credits / The End</title><sect1 id="revision-history"><title>Revision history</title><para>Versions x.y are published on the Internet.</para><para>Versions x.y.z are work-in-progress and only published as LyX file on CVS.</para><sect2><title>Releases 0.x</title><variablelist><varlistentry><term>0.33
</term><listitem><para>2002-11-18/PB: Fix broken RFC-URLs</para></listitem></varlistentry><varlistentry><term>0.32
</term><listitem><para>2002-11-03/PB: Add information about Chinese translation</para></listitem></varlistentry><varlistentry><term>0.31.1
</term><listitem><para>2002-10-06/PB: Add another maillist</para></listitem></varlistentry><varlistentry><term>0.31
</term><listitem><para>2002-09-29/PB: Extend information in proc-filesystem entries</para></listitem></varlistentry><varlistentry><term>0.30