svn commit: r52175 - head/en_US.ISO8859-1/books/developers-handbook/ipv6
Benedict Reuschling <[email protected]>
| Newsgroups | gmane.os.freebsd.devel.cvs.doc |
|---|---|
| Message-ID | <[email protected]> |
Author: bcr
Date: Sun Aug 26 14:08:19 2018
New Revision: 52175
URL: https://svnweb.freebsd.org/changeset/doc/52175
Log:
Fix errors reported by textproc/igor:
- wrap long lines
- add blank lines after <title> tags
- use tabs instead of spaces
- use two spaces at sentence start
- Capitalization in title tags (where appropriate)
Modified:
head/en_US.ISO8859-1/books/developers-handbook/ipv6/chapter.xml
Modified: head/en_US.ISO8859-1/books/developers-handbook/ipv6/chapter.xml
==============================================================================
--- head/en_US.ISO8859-1/books/developers-handbook/ipv6/chapter.xml Sun Aug 26 07:29:58 2018 (r52174)
+++ head/en_US.ISO8859-1/books/developers-handbook/ipv6/chapter.xml Sun Aug 26 14:08:19 2018 (r52175)
@@ -4,519 +4,567 @@
$FreeBSD$
-->
-<chapter xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:id="ipv6">
+<chapter xmlns="http://docbook.org/ns/docbook"
+ xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
+ xml:id="ipv6">
<title>IPv6 Internals</title>
<sect1 xml:id="ipv6-implementation">
- <info><title>IPv6/IPsec Implementation</title>
+ <info>
+ <title>IPv6/IPsec Implementation</title>
+
<authorgroup>
- <author><personname><firstname>Yoshinobu</firstname><surname>Inoue</surname></personname><contrib>Contributed by </contrib></author>
+ <author>
+ <personname>
+ <firstname>Yoshinobu</firstname>
+ <surname>Inoue</surname>
+ </personname>
+ <contrib>Contributed by </contrib>
+ </author>
</authorgroup>
-
</info>
-
+ <para>This section should explain IPv6 and IPsec related
+ implementation internals. These functionalities are derived
+ from <link xlink:href="http://www.kame.net/">KAME
+ project</link></para>
- <para>This section should explain IPv6 and IPsec related implementation
- internals. These functionalities are derived from <link xlink:href="http://www.kame.net/">KAME project</link></para>
-
<sect2 xml:id="ipv6details">
<title>IPv6</title>
<sect3>
- <title>Conformance</title>
+ <title>Conformance</title>
- <para>The IPv6 related functions conforms, or tries to conform to
- the latest set of IPv6 specifications. For future reference we list
- some of the relevant documents below (<emphasis>NOTE</emphasis>: this
- is not a complete list - this is too hard to maintain...).</para>
+ <para>The IPv6 related functions conforms, or tries to conform
+ to the latest set of IPv6 specifications. For future
+ reference we list some of the relevant documents below
+ (<emphasis>NOTE</emphasis>: this is not a complete list -
+ this is too hard to maintain...).</para>
- <para>For details please refer to specific chapter in the document,
- RFCs, manual pages, or comments in the source code.</para>
+ <para>For details please refer to specific chapter in the
+ document, RFCs, manual pages, or comments in the source
+ code.</para>
- <para>Conformance tests have been performed on the KAME STABLE kit
- at TAHI project. Results can be viewed at
- <uri xlink:href="http://www.tahi.org/report/KAME/">http://www.tahi.org/report/KAME/</uri>.
- We also attended Univ. of New Hampshire IOL tests
- (<uri xlink:href="http://www.iol.unh.edu/">http://www.iol.unh.edu/</uri>) in the
- past, with our past snapshots.</para>
+ <para>Conformance tests have been performed on the KAME STABLE
+ kit at TAHI project. Results can be viewed at <uri
+ xlink:href="http://www.tahi.org/report/KAME/">http://www.tahi.org/report/KAME/</uri>.
+ We also attended University of New Hampshire IOL tests (<uri
+ xlink:href="http://www.iol.unh.edu/">http://www.iol.unh.edu/</uri>)
+ in the past, with our past snapshots.</para>
- <itemizedlist>
- <listitem>
+ <itemizedlist>
+ <listitem>
<para>RFC1639: FTP Operation Over Big Address Records
- (FOOBAR)</para>
+ (FOOBAR)</para>
<itemizedlist>
<listitem>
- <para>RFC2428 is preferred over RFC1639. FTP clients will
- first try RFC2428, then RFC1639 if failed.</para>
+ <para>RFC2428 is preferred over RFC1639. FTP clients
+ will first try RFC2428, then RFC1639 if
+ failed.</para>
</listitem>
</itemizedlist>
- </listitem>
+ </listitem>
- <listitem>
+ <listitem>
<para>RFC1886: DNS Extensions to support IPv6</para>
</listitem>
- <listitem>
+ <listitem>
<para>RFC1933: Transition Mechanisms for IPv6 Hosts and
- Routers</para>
+ Routers</para>
<itemizedlist>
- <listitem>
- <para>IPv4 compatible address is not supported.</para>
+ <listitem>
+ <para>IPv4 compatible address is not supported.</para>
</listitem>
- <listitem>
- <para>automatic tunneling (described in 4.3 of this RFC) is not
- supported.</para>
+ <listitem>
+ <para>automatic tunneling (described in 4.3 of this
+ RFC) is not supported.</para>
</listitem>
- <listitem>
- <para>&man.gif.4; interface implements IPv[46]-over-IPv[46]
- tunnel in a generic way, and it covers "configured tunnel"
- described in the spec. See <link linkend="gif">23.5.1.5</link>
- in this document for details.</para>
+ <listitem>
+ <para>&man.gif.4; interface implements
+ IPv[46]-over-IPv[46] tunnel in a generic way, and it
+ covers "configured tunnel" described in the spec.
+ See <link linkend="gif">23.5.1.5</link> in this
+ document for details.</para>
</listitem>
</itemizedlist>
- </listitem>
+ </listitem>
- <listitem>
- <para>RFC1981: Path MTU Discovery for IPv6</para>
- </listitem>
+ <listitem>
+ <para>RFC1981: Path MTU Discovery for IPv6</para>
+ </listitem>
- <listitem>
- <para>RFC2080: RIPng for IPv6</para>
+ <listitem>
+ <para>RFC2080: RIPng for IPv6</para>
<itemizedlist>
<listitem>
- <para>usr.sbin/route6d support this.</para>
- </listitem>
+ <para>usr.sbin/route6d support this.</para>
+ </listitem>
</itemizedlist>
- </listitem>
+ </listitem>
- <listitem>
- <para>RFC2292: Advanced Sockets API for IPv6</para>
+ <listitem>
+ <para>RFC2292: Advanced Sockets API for IPv6</para>
<itemizedlist>
<listitem>
<para>For supported library functions/kernel APIs, see
- <filename>sys/netinet6/ADVAPI</filename>.</para>
+ <filename>sys/netinet6/ADVAPI</filename>.</para>
</listitem>
</itemizedlist>
- </listitem>
+ </listitem>
- <listitem>
- <para>RFC2362: Protocol Independent Multicast-Sparse
- Mode (PIM-SM)</para>
+ <listitem>
+ <para>RFC2362: Protocol Independent Multicast-Sparse Mode
+ (PIM-SM)</para>
<itemizedlist>
<listitem>
<para>RFC2362 defines packet formats for PIM-SM.
- <filename>draft-ietf-pim-ipv6-01.txt</filename> is
- written based on this.</para>
+ <filename>draft-ietf-pim-ipv6-01.txt</filename> is
+ written based on this.</para>
</listitem>
</itemizedlist>
- </listitem>
+ </listitem>
- <listitem>
+ <listitem>
<para>RFC2373: IPv6 Addressing Architecture</para>
<itemizedlist>
<listitem>
- <para>supports node required addresses, and conforms to
- the scope requirement.</para>
+ <para>supports node required addresses, and conforms
+ to the scope requirement.</para>
</listitem>
</itemizedlist>
- </listitem>
+ </listitem>
- <listitem>
+ <listitem>
<para>RFC2374: An IPv6 Aggregatable Global Unicast Address
- Format</para>
+ Format</para>
<itemizedlist>
<listitem>
<para>supports 64-bit length of Interface ID.</para>
</listitem>
</itemizedlist>
- </listitem>
+ </listitem>
- <listitem>
+ <listitem>
<para>RFC2375: IPv6 Multicast Address Assignments</para>
<itemizedlist>
<listitem>
- <para>Userland applications use the well-known addresses
- assigned in the RFC.</para>
+ <para>Userland applications use the well-known
+ addresses assigned in the RFC.</para>
</listitem>
</itemizedlist>
- </listitem>
+ </listitem>
- <listitem>
+ <listitem>
<para>RFC2428: FTP Extensions for IPv6 and NATs</para>
<itemizedlist>
<listitem>
- <para>RFC2428 is preferred over RFC1639. FTP clients will
- first try RFC2428, then RFC1639 if failed.</para>
+ <para>RFC2428 is preferred over RFC1639. FTP clients
+ will first try RFC2428, then RFC1639 if
+ failed.</para>
</listitem>
</itemizedlist>
- </listitem>
+ </listitem>
- <listitem>
+ <listitem>
<para>RFC2460: IPv6 specification</para>
- </listitem>
+ </listitem>
- <listitem>
+ <listitem>
<para>RFC2461: Neighbor discovery for IPv6</para>
<itemizedlist>
<listitem>
- <para>See <link linkend="neighbor-discovery">23.5.1.2</link>
- in this document for details.</para>
+ <para>See <link
+ linkend="neighbor-discovery">23.5.1.2</link> in
+ this document for details.</para>
</listitem>
</itemizedlist>
- </listitem>
+ </listitem>
- <listitem>
- <para>RFC2462: IPv6 Stateless Address Autoconfiguration</para>
+ <listitem>
+ <para>RFC2462: IPv6 Stateless Address
+ Autoconfiguration</para>
<itemizedlist>
<listitem>
- <para>See <link linkend="ipv6-pnp">23.5.1.4</link> in this
- document for details.</para>
+ <para>See <link linkend="ipv6-pnp">23.5.1.4</link> in
+ this document for details.</para>
</listitem>
</itemizedlist>
- </listitem>
+ </listitem>
- <listitem>
+ <listitem>
<para>RFC2463: ICMPv6 for IPv6 specification</para>
<itemizedlist>
<listitem>
- <para>See <link linkend="icmpv6">23.5.1.9</link> in this
- document for details.</para>
+ <para>See <link linkend="icmpv6">23.5.1.9</link> in
+ this document for details.</para>
</listitem>
</itemizedlist>
- </listitem>
+ </listitem>
- <listitem>
+ <listitem>
<para>RFC2464: Transmission of IPv6 Packets over Ethernet
- Networks</para>
- </listitem>
+ Networks</para>
+ </listitem>
- <listitem>
- <para>RFC2465: MIB for IPv6: Textual Conventions and General
- Group</para>
+ <listitem>
+ <para>RFC2465: MIB for IPv6: Textual Conventions and
+ General Group</para>
<itemizedlist>
<listitem>
- <para>Necessary statistics are gathered by the kernel. Actual
- IPv6 MIB support is provided as a patchkit for ucd-snmp.</para>
+ <para>Necessary statistics are gathered by the kernel.
+ Actual IPv6 MIB support is provided as a patchkit
+ for ucd-snmp.</para>
</listitem>
</itemizedlist>
- </listitem>
+ </listitem>
- <listitem>
+ <listitem>
<para>RFC2466: MIB for IPv6: ICMPv6 group</para>
<itemizedlist>
<listitem>
- <para>Necessary statistics are gathered by the kernel. Actual
- IPv6 MIB support is provided as patchkit for ucd-snmp.</para>
+ <para>Necessary statistics are gathered by the kernel.
+ Actual IPv6 MIB support is provided as patchkit for
+ ucd-snmp.</para>
</listitem>
</itemizedlist>
- </listitem>
+ </listitem>
- <listitem>
+ <listitem>
<para>RFC2467: Transmission of IPv6 Packets over FDDI
- Networks</para>
- </listitem>
+ Networks</para>
+ </listitem>
- <listitem>
+ <listitem>
<para>RFC2497: Transmission of IPv6 packet over ARCnet
- Networks</para>
- </listitem>
+ Networks</para>
+ </listitem>
- <listitem>
- <para>RFC2553: Basic Socket Interface Extensions for IPv6</para>
+ <listitem>
+ <para>RFC2553: Basic Socket Interface Extensions for
+ IPv6</para>
<itemizedlist>
<listitem>
- <para>IPv4 mapped address (3.7) and special behavior of IPv6
- wildcard bind socket (3.8) are supported. See <link linkend="ipv6-wildcard-socket">23.5.1.12</link>
- in this document for details.</para>
+ <para>IPv4 mapped address (3.7) and special behavior
+ of IPv6 wildcard bind socket (3.8) are supported.
+ See <link
+ linkend="ipv6-wildcard-socket">23.5.1.12</link> in
+ this document for details.</para>
</listitem>
</itemizedlist>
- </listitem>
+ </listitem>
- <listitem>
+ <listitem>
<para>RFC2675: IPv6 Jumbograms</para>
<itemizedlist>
<listitem>
- <para>See <link linkend="ipv6-jumbo">23.5.1.7</link> in
- this document for details.</para>
+ <para>See <link linkend="ipv6-jumbo">23.5.1.7</link>
+ in this document for details.</para>
</listitem>
</itemizedlist>
- </listitem>
+ </listitem>
- <listitem>
- <para>RFC2710: Multicast Listener Discovery for IPv6</para>
- </listitem>
+ <listitem>
+ <para>RFC2710: Multicast Listener Discovery for
+ IPv6</para>
+ </listitem>
- <listitem>
+ <listitem>
<para>RFC2711: IPv6 router alert option</para>
- </listitem>
+ </listitem>
- <listitem>
- <para><filename>draft-ietf-ipngwg-router-renum-08</filename>: Router
- renumbering for IPv6</para>
- </listitem>
+ <listitem>
+ <para><filename>draft-ietf-ipngwg-router-renum-08</filename>:
+ Router renumbering for IPv6</para>
+ </listitem>
- <listitem>
+ <listitem>
<para><filename>draft-ietf-ipngwg-icmp-namelookups-02</filename>:
- IPv6 Name Lookups Through ICMP</para>
- </listitem>
+ IPv6 Name Lookups Through ICMP</para>
+ </listitem>
- <listitem>
+ <listitem>
<para><filename>draft-ietf-ipngwg-icmp-name-lookups-03</filename>:
- IPv6 Name Lookups Through ICMP</para>
- </listitem>
+ IPv6 Name Lookups Through ICMP</para>
+ </listitem>
- <listitem>
- <para><filename>draft-ietf-pim-ipv6-01.txt</filename>:
- PIM for IPv6</para>
+ <listitem>
+ <para><filename>draft-ietf-pim-ipv6-01.txt</filename>: PIM
+ for IPv6</para>
<itemizedlist>
<listitem>
- <para>&man.pim6dd.8; implements dense mode. &man.pim6sd.8;
- implements sparse mode.</para>
+ <para>&man.pim6dd.8; implements dense mode.
+ &man.pim6sd.8; implements sparse mode.</para>
</listitem>
</itemizedlist>
- </listitem>
+ </listitem>
- <listitem>
+ <listitem>
<para><filename>draft-itojun-ipv6-tcp-to-anycast-00</filename>:
- Disconnecting TCP connection toward IPv6 anycast address</para>
- </listitem>
+ Disconnecting TCP connection toward IPv6 anycast
+ address</para>
+ </listitem>
- <listitem>
- <para><filename>draft-yamamoto-wideipv6-comm-model-00</filename>
- </para>
+ <listitem>
+ <para><filename>draft-yamamoto-wideipv6-comm-model-00</filename></para>
<itemizedlist>
<listitem>
- <para>See <link linkend="ipv6-sas">23.5.1.6</link> in this
- document for details.</para>
+ <para>See <link linkend="ipv6-sas">23.5.1.6</link> in
+ this document for details.</para>
</listitem>
</itemizedlist>
- </listitem>
+ </listitem>
- <listitem>
- <para><filename>draft-ietf-ipngwg-scopedaddr-format-00.txt
- </filename>: An Extension of Format for IPv6 Scoped
- Addresses</para>
- </listitem>
- </itemizedlist>
+ <listitem>
+ <para><filename>draft-ietf-ipngwg-scopedaddr-format-00.txt</filename>:
+ An Extension of Format for IPv6 Scoped Addresses</para>
+ </listitem>
+ </itemizedlist>
</sect3>
<sect3 xml:id="neighbor-discovery">
- <title>Neighbor Discovery</title>
+ <title>Neighbor Discovery</title>
- <para>Neighbor Discovery is fairly stable. Currently Address
- Resolution, Duplicated Address Detection, and Neighbor Unreachability
- Detection are supported. In the near future we will be adding Proxy
- Neighbor Advertisement support in the kernel and Unsolicited Neighbor
- Advertisement transmission command as admin tool.</para>
+ <para>Neighbor Discovery is fairly stable. Currently Address
+ Resolution, Duplicated Address Detection, and Neighbor
+ Unreachability Detection are supported. In the near future
+ we will be adding Proxy Neighbor Advertisement support in
+ the kernel and Unsolicited Neighbor Advertisement
+ transmission command as admin tool.</para>
- <para>If DAD fails, the address will be marked "duplicated" and
- message will be generated to syslog (and usually to console). The
- "duplicated" mark can be checked with &man.ifconfig.8;. It is
- administrators' responsibility to check for and recover from DAD
- failures. The behavior should be improved in the near future.</para>
+ <para>If DAD fails, the address will be marked "duplicated"
+ and message will be generated to syslog (and usually to
+ console). The "duplicated" mark can be checked with
+ &man.ifconfig.8;. It is administrators' responsibility to
+ check for and recover from DAD failures. The behavior
+ should be improved in the near future.</para>
- <para>Some of the network driver loops multicast packets back to itself,
- even if instructed not to do so (especially in promiscuous mode).
- In such cases DAD may fail, because DAD engine sees inbound NS packet
- (actually from the node itself) and considers it as a sign of duplicate.
- You may want to look at #if condition marked "heuristics" in
- sys/netinet6/nd6_nbr.c:nd6_dad_timer() as workaround (note that the code
- fragment in "heuristics" section is not spec conformant).</para>
+ <para>Some of the network driver loops multicast packets back
+ to itself, even if instructed not to do so (especially in
+ promiscuous mode). In such cases DAD may fail, because DAD
+ engine sees inbound NS packet (actually from the node
+ itself) and considers it as a sign of duplicate. You may
+ want to look at #if condition marked "heuristics" in
+ sys/netinet6/nd6_nbr.c:nd6_dad_timer() as workaround (note
+ that the code fragment in "heuristics" section is not spec
+ conformant).</para>
- <para>Neighbor Discovery specification (RFC2461) does not talk about
- neighbor cache handling in the following cases:</para>
+ <para>Neighbor Discovery specification (RFC2461) does not talk
+ about neighbor cache handling in the following cases:</para>
<orderedlist>
- <listitem>
+ <listitem>
<para>when there was no neighbor cache entry, node
- received unsolicited RS/NS/NA/redirect packet without
- link-layer address</para>
- </listitem>
- <listitem>
- <para>neighbor cache handling on medium without link-layer
- address (we need a neighbor cache entry for IsRouter bit)</para>
- </listitem>
+ received unsolicited RS/NS/NA/redirect packet without
+ link-layer address</para>
+ </listitem>
+ <listitem>
+ <para>neighbor cache handling on medium without link-layer
+ address (we need a neighbor cache entry for IsRouter
+ bit)</para>
+ </listitem>
</orderedlist>
- <para>For first case, we implemented workaround based on discussions
- on IETF ipngwg mailing list. For more details, see the comments in
- the source code and email thread started from (IPng 7155), dated
- Feb 6 1999.</para>
+ <para>For first case, we implemented workaround based on
+ discussions on IETF ipngwg mailing list. For more details,
+ see the comments in the source code and email thread started
+ from (IPng 7155), dated Feb 6 1999.</para>
- <para>IPv6 on-link determination rule (RFC2461) is quite different
- from assumptions in BSD network code. At this moment, no on-link
- determination rule is supported where default router list is empty
- (RFC2461, section 5.2, last sentence in 2nd paragraph - note that
- the spec misuse the word "host" and "node" in several places in
- the section).</para>
+ <para>IPv6 on-link determination rule (RFC2461) is quite
+ different from assumptions in BSD network code. At this
+ moment, no on-link determination rule is supported where
+ default router list is empty (RFC2461, section 5.2, last
+ sentence in 2nd paragraph - note that the spec misuse the
+ word "host" and "node" in several places in the
+ section).</para>
- <para>To avoid possible DoS attacks and infinite loops, only 10
- options on ND packet is accepted now. Therefore, if you have 20
- prefix options attached to RA, only the first 10 prefixes will be
- recognized. If this troubles you, please ask it on FREEBSD-CURRENT
- mailing list and/or modify nd6_maxndopt in
- <filename>sys/netinet6/nd6.c</filename>. If there are high demands
- we may provide sysctl knob for the variable.</para>
+ <para>To avoid possible DoS attacks and infinite loops, only
+ 10 options on ND packet is accepted now. Therefore, if you
+ have 20 prefix options attached to RA, only the first 10
+ prefixes will be recognized. If this troubles you, please
+ ask it on FREEBSD-CURRENT mailing list and/or modify
+ nd6_maxndopt in <filename>sys/netinet6/nd6.c</filename>. If
+ there are high demands we may provide sysctl knob for the
+ variable.</para>
</sect3>
<sect3 xml:id="ipv6-scope-index">
- <title>Scope Index</title>
+ <title>Scope Index</title>
- <para>IPv6 uses scoped addresses. Therefore, it is very important to
- specify scope index (interface index for link-local address, or
- site index for site-local address) with an IPv6 address. Without
- scope index, scoped IPv6 address is ambiguous to the kernel, and
- kernel will not be able to determine the outbound interface for a
- packet.</para>
+ <para>IPv6 uses scoped addresses. Therefore, it is very
+ important to specify scope index (interface index for
+ link-local address, or site index for site-local address)
+ with an IPv6 address. Without scope index, scoped IPv6
+ address is ambiguous to the kernel, and kernel will not be
+ able to determine the outbound interface for a
+ packet.</para>
<para>Ordinary userland applications should use advanced API
- (RFC2292) to specify scope index, or interface index. For similar
- purpose, sin6_scope_id member in sockaddr_in6 structure is defined
- in RFC2553. However, the semantics for sin6_scope_id is rather vague.
- If you care about portability of your application, we suggest you to
- use advanced API rather than sin6_scope_id.</para>
+ (RFC2292) to specify scope index, or interface index. For
+ similar purpose, sin6_scope_id member in sockaddr_in6
+ structure is defined in RFC2553. However, the semantics for
+ sin6_scope_id is rather vague. If you care about
+ portability of your application, we suggest you to use
+ advanced API rather than sin6_scope_id.</para>
- <para>In the kernel, an interface index for link-local scoped address is
- embedded into 2nd 16bit-word (3rd and 4th byte) in IPv6 address. For
- example, you may see something like:
- </para>
+ <para>In the kernel, an interface index for link-local scoped
+ address is embedded into 2nd 16bit-word (3rd and 4th byte)
+ in IPv6 address. For example, you may see something
+ like:</para>
<screen> fe80:1::200:f8ff:fe01:6317</screen>
- <para>in the routing table and interface address structure (struct
- in6_ifaddr). The address above is a link-local unicast address
- which belongs to a network interface whose interface identifier is 1.
- The embedded index enables us to identify IPv6 link local
- addresses over multiple interfaces effectively and with only a
- little code change.</para>
+ <para>in the routing table and interface address structure
+ (struct in6_ifaddr). The address above is a link-local
+ unicast address which belongs to a network interface whose
+ interface identifier is 1. The embedded index enables us to
+ identify IPv6 link local addresses over multiple interfaces
+ effectively and with only a little code change.</para>
- <para>Routing daemons and configuration programs, like &man.route6d.8;
- and &man.ifconfig.8;, will need to manipulate the "embedded" scope
- index. These programs use routing sockets and ioctls (like
- SIOCGIFADDR_IN6) and the kernel API will return IPv6 addresses with
- 2nd 16bit-word filled in. The APIs are for manipulating kernel
- internal structure. Programs that use these APIs have to be prepared
- about differences in kernels anyway.</para>
+ <para>Routing daemons and configuration programs, like
+ &man.route6d.8; and &man.ifconfig.8;, will need to
+ manipulate the "embedded" scope index. These programs use
+ routing sockets and ioctls (like SIOCGIFADDR_IN6) and the
+ kernel API will return IPv6 addresses with 2nd 16bit-word
+ filled in. The APIs are for manipulating kernel internal
+ structure. Programs that use these APIs have to be prepared
+ about differences in kernels anyway.</para>
- <para>When you specify scoped address to the command line, NEVER write
- the embedded form (such as ff02:1::1 or fe80:2::fedc). This is not
- supposed to work. Always use standard form, like ff02::1 or
- fe80::fedc, with command line option for specifying interface (like
- <command>ping6 -I ne0 ff02::1</command>). In general, if a command
- does not have command line option to specify outgoing interface, that
- command is not ready to accept scoped address. This may seem to be
- opposite from IPv6's premise to support "dentist office" situation.
- We believe that specifications need some improvements for this.</para>
+ <para>When you specify scoped address to the command line,
+ NEVER write the embedded form (such as ff02:1::1 or
+ fe80:2::fedc). This is not supposed to work. Always use
+ standard form, like ff02::1 or fe80::fedc, with command line
+ option for specifying interface (like <command>ping6 -I ne0
+ ff02::1</command>). In general, if a command does not
+ have command line option to specify outgoing interface, that
+ command is not ready to accept scoped address. This may
+ seem to be opposite from IPv6's premise to support "dentist
+ office" situation. We believe that specifications need some
+ improvements for this.</para>
- <para>Some of the userland tools support extended numeric IPv6 syntax,
- as documented in
- <filename>draft-ietf-ipngwg-scopedaddr-format-00.txt</filename>. You
- can specify outgoing link, by using name of the outgoing interface
- like "fe80::1%ne0". This way you will be able to specify link-local
- scoped address without much trouble.</para>
+ <para>Some of the userland tools support extended numeric IPv6
+ syntax, as documented in
+ <filename>draft-ietf-ipngwg-scopedaddr-format-00.txt</filename>.
+ You can specify outgoing link, by using name of the outgoing
+ interface like "fe80::1%ne0". This way you will be able to
+ specify link-local scoped address without much
+ trouble.</para>
- <para>To use this extension in your program, you will need to use
- &man.getaddrinfo.3;, and &man.getnameinfo.3; with NI_WITHSCOPEID.
- The implementation currently assumes 1-to-1 relationship between a
- link and an interface, which is stronger than what specs say.</para>
+ <para>To use this extension in your program, you will need to
+ use &man.getaddrinfo.3;, and &man.getnameinfo.3; with
+ NI_WITHSCOPEID. The implementation currently assumes 1-to-1
+ relationship between a link and an interface, which is
+ stronger than what specs say.</para>
</sect3>
<sect3 xml:id="ipv6-pnp">
<title>Plug and Play</title>
- <para>Most of the IPv6 stateless address autoconfiguration is implemented
- in the kernel. Neighbor Discovery functions are implemented in the
- kernel as a whole. Router Advertisement (RA) input for hosts is
- implemented in the kernel. Router Solicitation (RS) output for
- endhosts, RS input for routers, and RA output for routers are
- implemented in the userland.</para>
+ <para>Most of the IPv6 stateless address autoconfiguration is
+ implemented in the kernel. Neighbor Discovery functions are
+ implemented in the kernel as a whole. Router Advertisement
+ (RA) input for hosts is implemented in the kernel. Router
+ Solicitation (RS) output for endhosts, RS input for routers,
+ and RA output for routers are implemented in the
+ userland.</para>
- <sect4>
- <title>Assignment of link-local, and special addresses</title>
+ <sect4>
+ <title>Assignment of link-local, and special
+ addresses</title>
- <para>IPv6 link-local address is generated from IEEE802 address
- (Ethernet MAC address). Each of interface is assigned an IPv6
- link-local address automatically, when the interface becomes up
- (IFF_UP). Also, direct route for the link-local address is added
- to routing table.</para>
+ <para>IPv6 link-local address is generated from IEEE802
+ address (Ethernet MAC address). Each of interface is
+ assigned an IPv6 link-local address automatically, when
+ the interface becomes up (IFF_UP). Also, direct route for
+ the link-local address is added to routing table.</para>
<para>Here is an output of netstat command:</para>
-<screen>Internet6:
+ <screen>Internet6:
Destination Gateway Flags Netif Expire
fe80:1::%ed0/64 link#1 UC ed0
fe80:2::%ep0/64 link#2 UC ep0</screen>
- <para>Interfaces that has no IEEE802 address (pseudo interfaces
- like tunnel interfaces, or ppp interfaces) will borrow IEEE802
- address from other interfaces, such as Ethernet interfaces,
- whenever possible. If there is no IEEE802 hardware attached,
- a last resort pseudo-random value, MD5(hostname), will
- be used as source of link-local address. If it is not suitable
- for your usage, you will need to configure the link-local address
- manually.</para>
+ <para>Interfaces that has no IEEE802 address (pseudo
+ interfaces like tunnel interfaces, or ppp interfaces) will
+ borrow IEEE802 address from other interfaces, such as
+ Ethernet interfaces, whenever possible. If there is no
+ IEEE802 hardware attached, a last resort pseudo-random
+ value, MD5(hostname), will be used as source of link-local
+ address. If it is not suitable for your usage, you will
+ need to configure the link-local address manually.</para>
- <para>If an interface is not capable of handling IPv6 (such as
- lack of multicast support), link-local address will not be
- assigned to that interface. See section 2 for details.</para>
+ <para>If an interface is not capable of handling IPv6 (such
+ as lack of multicast support), link-local address will not
+ be assigned to that interface. See section 2 for
+ details.</para>
- <para>Each interface joins the solicited multicast address and the
- link-local all-nodes multicast addresses (e.g. fe80::1:ff01:6317
- and ff02::1, respectively, on the link the interface is attached).
- In addition to a link-local address, the loopback address (::1)
- will be assigned to the loopback interface. Also, ::1/128 and
- ff01::/32 are automatically added to routing table, and loopback
- interface joins node-local multicast group ff01::1.</para>
- </sect4>
+ <para>Each interface joins the solicited multicast address
+ and the link-local all-nodes multicast addresses (e.g.,
+ fe80::1:ff01:6317 and ff02::1, respectively, on the link
+ the interface is attached). In addition to a link-local
+ address, the loopback address (::1) will be assigned to
+ the loopback interface. Also, ::1/128 and ff01::/32 are
+ automatically added to routing table, and loopback
+ interface joins node-local multicast group ff01::1.</para>
+ </sect4>
- <sect4>
- <title>Stateless address autoconfiguration on hosts</title>
+ <sect4>
+ <title>Stateless address autoconfiguration on Hosts</title>
- <para>In IPv6 specification, nodes are separated into two categories:
- <emphasis>routers</emphasis> and <emphasis>hosts</emphasis>. Routers
- forward packets addressed to others, hosts does not forward the
- packets. net.inet6.ip6.forwarding defines whether this node is
- router or host (router if it is 1, host if it is 0).</para>
+ <para>In IPv6 specification, nodes are separated into two
+ categories: <emphasis>routers</emphasis> and
+ <emphasis>hosts</emphasis>. Routers forward packets
+ addressed to others, hosts does not forward the packets.
+ net.inet6.ip6.forwarding defines whether this node is
+ router or host (router if it is 1, host if it is
+ 0).</para>
- <para>When a host hears Router Advertisement from the router, a host
- may autoconfigure itself by stateless address autoconfiguration.
- This behavior can be controlled by net.inet6.ip6.accept_rtadv (host
- autoconfigures itself if it is set to 1). By autoconfiguration,
- network address prefix for the receiving interface (usually global
- address prefix) is added. Default route is also configured.
- Routers periodically generate Router Advertisement packets. To
- request an adjacent router to generate RA packet, a host can
- transmit Router Solicitation. To generate a RS packet at any time,
- use the <emphasis>rtsol</emphasis> command. &man.rtsold.8; daemon is
- also available. &man.rtsold.8; generates Router Solicitation whenever
- necessary, and it works great for nomadic usage (notebooks/laptops).
- If one wishes to ignore Router Advertisements, use sysctl to set
- net.inet6.ip6.accept_rtadv to 0.</para>
+ <para>When a host hears Router Advertisement from the
+ router, a host may autoconfigure itself by stateless
+ address autoconfiguration. This behavior can be
+ controlled by net.inet6.ip6.accept_rtadv (host
+ autoconfigures itself if it is set to 1). By
+ autoconfiguration, network address prefix for the
+ receiving interface (usually global address prefix) is
+ added. Default route is also configured. Routers
+ periodically generate Router Advertisement packets. To
+ request an adjacent router to generate RA packet, a host
+ can transmit Router Solicitation. To generate a RS packet
+ at any time, use the <emphasis>rtsol</emphasis> command.
+ &man.rtsold.8; daemon is also available. &man.rtsold.8;
+ generates Router Solicitation whenever necessary, and it
+ works great for nomadic usage (notebooks/laptops). If one
+ wishes to ignore Router Advertisements, use sysctl to set
+ net.inet6.ip6.accept_rtadv to 0.</para>
- <para>To generate Router Advertisement from a router, use the
- &man.rtadvd.8; daemon.</para>
+ <para>To generate Router Advertisement from a router, use
+ the &man.rtadvd.8; daemon.</para>
- <para>Note that, IPv6 specification assumes the following items, and
- nonconforming cases are left unspecified:</para>
+ <para>Note that, IPv6 specification assumes the following
+ items, and nonconforming cases are left
+ unspecified:</para>
<itemizedlist>
<listitem>
- <para>Only hosts will listen to router advertisements</para>
+ <para>Only hosts will listen to router
+ advertisements</para>
</listitem>
<listitem>
- <para>Hosts have single network interface (except loopback)</para>
+ <para>Hosts have single network interface (except
+ loopback)</para>
</listitem>
</itemizedlist>
- <para>Therefore, this is unwise to enable net.inet6.ip6.accept_rtadv
- on routers, or multi-interface host. A misconfigured node can
- behave strange (nonconforming configuration allowed for those who
- would like to do some experiments).</para>
+ <para>Therefore, this is unwise to enable
+ net.inet6.ip6.accept_rtadv on routers, or multi-interface
+ host. A misconfigured node can behave strange
+ (nonconforming configuration allowed for those who would
+ like to do some experiments).</para>
<para>To summarize the sysctl knob:</para>
- <screen> accept_rtadv forwarding role of the node
+ <screen> accept_rtadv forwarding role of the node
--- --- ---
0 0 host (to be manually configured)
0 1 router
@@ -529,23 +577,25 @@ fe80:2::%ep0/64 link#2
(out-of-scope of spec)</screen>
<para>RFC2462 has validation rule against incoming RA prefix
- information option, in 5.5.3 (e). This is to protect hosts from
- malicious (or misconfigured) routers that advertise very short
- prefix lifetime. There was an update from Jim Bound to ipngwg
- mailing list (look for "(ipng 6712)" in the archive) and it is
- implemented Jim's update.</para>
+ information option, in 5.5.3 (e). This is to protect
+ hosts from malicious (or misconfigured) routers that
+ advertise very short prefix lifetime. There was an update
+ from Jim Bound to ipngwg mailing list (look for "(ipng
+ 6712)" in the archive) and it is implemented Jim's
+ update.</para>
- <para>See <link linkend="neighbor-discovery">23.5.1.2</link> in
- the document for relationship between DAD and
- autoconfiguration.</para>
- </sect4>
+ <para>See <link linkend="neighbor-discovery">23.5.1.2</link>
+ in the document for relationship between DAD and
+ autoconfiguration.</para>
+ </sect4>
</sect3>
<sect3 xml:id="gif">
- <title>Generic tunnel interface</title>
+ <title>Generic Tunnel Interface</title>
- <para>GIF (Generic InterFace) is a pseudo interface for configured
- tunnel. Details are described in &man.gif.4;. Currently</para>
+ <para>GIF (Generic InterFace) is a pseudo interface for
+ configured tunnel. Details are described in &man.gif.4;.
+ Currently</para>
<itemizedlist>
<listitem>
@@ -562,267 +612,286 @@ fe80:2::%ep0/64 link#2
</listitem>
</itemizedlist>
- <para>are available. Use &man.gifconfig.8; to assign physical (outer)
- source and destination address to gif interfaces. Configuration that
- uses same address family for inner and outer IP header (v4 in v4, or
- v6 in v6) is dangerous. It is very easy to configure interfaces and
- routing tables to perform infinite level of tunneling.
- <emphasis>Please be warned</emphasis>.</para>
+ <para>are available. Use &man.gifconfig.8; to assign physical
+ (outer) source and destination address to gif interfaces.
+ Configuration that uses same address family for inner and
+ outer IP header (v4 in v4, or v6 in v6) is dangerous. It is
+ very easy to configure interfaces and routing tables to
+ perform infinite level of tunneling. <emphasis>Please be
+ warned</emphasis>.</para>
- <para>gif can be configured to be ECN-friendly. See <link linkend="ipsec-ecn">23.5.4.5</link> for ECN-friendliness of
- tunnels, and &man.gif.4; for how to configure.</para>
+ <para>gif can be configured to be ECN-friendly. See <link
+ linkend="ipsec-ecn">23.5.4.5</link> for ECN-friendliness
+ of tunnels, and &man.gif.4; for how to configure.</para>
- <para>If you would like to configure an IPv4-in-IPv6 tunnel with gif
- interface, read &man.gif.4; carefully. You will need to
- remove IPv6 link-local address automatically assigned to the gif
- interface.</para>
+ <para>If you would like to configure an IPv4-in-IPv6 tunnel
+ with gif interface, read &man.gif.4; carefully. You will
+ need to remove IPv6 link-local address automatically
+ assigned to the gif interface.</para>
</sect3>
<sect3 xml:id="ipv6-sas">
<title>Source Address Selection</title>
- <para>Current source selection rule is scope oriented (there are some
- exceptions - see below). For a given destination, a source IPv6
- address is selected by the following rule:</para>
+ <para>Current source selection rule is scope oriented (there
+ are some exceptions - see below). For a given destination,
+ a source IPv6 address is selected by the following
+ rule:</para>
<orderedlist>
<listitem>
- <para>If the source address is explicitly specified by
- the user (e.g. via the advanced API), the specified address
- is used.</para>
+ <para>If the source address is explicitly specified by the
+ user (e.g., via the advanced API), the specified
+ address is used.</para>
</listitem>
<listitem>
<para>If there is an address assigned to the outgoing
- interface (which is usually determined by looking up the
- routing table) that has the same scope as the destination
- address, the address is used.</para>
+ interface (which is usually determined by looking up the
+ routing table) that has the same scope as the
+ destination address, the address is used.</para>
<para>This is the most typical case.</para>
</listitem>
<listitem>
<para>If there is no address that satisfies the above
- condition, choose a global address assigned to one of
- the interfaces on the sending node.</para>
+ condition, choose a global address assigned to one of
+ the interfaces on the sending node.</para>
</listitem>
<listitem>
- <para>If there is no address that satisfies the above condition,
- and destination address is site local scope, choose a site local
- address assigned to one of the interfaces on the sending node.
- </para>
*** DIFF OUTPUT TRUNCATED AT 1000 LINES ***
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/svn-doc-all
To unsubscribe, send any mail to "[email protected]"