Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 26 Aug 2018 14:08:19 +0000 (UTC)
From:      Benedict Reuschling <bcr@FreeBSD.org>
To:        doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org
Subject:   svn commit: r52175 - head/en_US.ISO8859-1/books/developers-handbook/ipv6
Message-ID:  <201808261408.w7QE8JFE071636@repo.freebsd.org>

next in thread | raw e-mail | index | archive | help
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 ***



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201808261408.w7QE8JFE071636>