From owner-svn-doc-all@freebsd.org Sun Aug 26 14:08:20 2018 Return-Path: Delivered-To: svn-doc-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5641010777F1; Sun, 26 Aug 2018 14:08:20 +0000 (UTC) (envelope-from bcr@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EFFFF82254; Sun, 26 Aug 2018 14:08:19 +0000 (UTC) (envelope-from bcr@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id CB4F57EBF; Sun, 26 Aug 2018 14:08:19 +0000 (UTC) (envelope-from bcr@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id w7QE8JRc071637; Sun, 26 Aug 2018 14:08:19 GMT (envelope-from bcr@FreeBSD.org) Received: (from bcr@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id w7QE8JFE071636; Sun, 26 Aug 2018 14:08:19 GMT (envelope-from bcr@FreeBSD.org) Message-Id: <201808261408.w7QE8JFE071636@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: bcr set sender to bcr@FreeBSD.org using -f From: Benedict Reuschling Date: Sun, 26 Aug 2018 14:08:19 +0000 (UTC) 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 X-SVN-Group: doc-head X-SVN-Commit-Author: bcr X-SVN-Commit-Paths: head/en_US.ISO8859-1/books/developers-handbook/ipv6 X-SVN-Commit-Revision: 52175 X-SVN-Commit-Repository: doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2018 14:08:20 -0000 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 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 - IPv6/IPsec Implementation + + IPv6/IPsec Implementation + - YoshinobuInoueContributed by + + + Yoshinobu + Inoue + + Contributed by + - - + This section should explain IPv6 and IPsec related + implementation internals. These functionalities are derived + from KAME + project - This section should explain IPv6 and IPsec related implementation - internals. These functionalities are derived from KAME project - IPv6 - Conformance + Conformance - 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 (NOTE: this - is not a complete list - this is too hard to maintain...). + 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 + (NOTE: this is not a complete list - + this is too hard to maintain...). - For details please refer to specific chapter in the document, - RFCs, manual pages, or comments in the source code. + For details please refer to specific chapter in the + document, RFCs, manual pages, or comments in the source + code. - Conformance tests have been performed on the KAME STABLE kit - at TAHI project. Results can be viewed at - http://www.tahi.org/report/KAME/. - We also attended Univ. of New Hampshire IOL tests - (http://www.iol.unh.edu/) in the - past, with our past snapshots. + Conformance tests have been performed on the KAME STABLE + kit at TAHI project. Results can be viewed at http://www.tahi.org/report/KAME/. + We also attended University of New Hampshire IOL tests (http://www.iol.unh.edu/) + in the past, with our past snapshots. - - + + RFC1639: FTP Operation Over Big Address Records - (FOOBAR) + (FOOBAR) - RFC2428 is preferred over RFC1639. FTP clients will - first try RFC2428, then RFC1639 if failed. + RFC2428 is preferred over RFC1639. FTP clients + will first try RFC2428, then RFC1639 if + failed. - + - + RFC1886: DNS Extensions to support IPv6 - + RFC1933: Transition Mechanisms for IPv6 Hosts and - Routers + Routers - - IPv4 compatible address is not supported. + + IPv4 compatible address is not supported. - - automatic tunneling (described in 4.3 of this RFC) is not - supported. + + automatic tunneling (described in 4.3 of this + RFC) is not supported. - - &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 23.5.1.5 - in this document for details. + + &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 23.5.1.5 in this + document for details. - + - - RFC1981: Path MTU Discovery for IPv6 - + + RFC1981: Path MTU Discovery for IPv6 + - - RFC2080: RIPng for IPv6 + + RFC2080: RIPng for IPv6 - usr.sbin/route6d support this. - + usr.sbin/route6d support this. + - + - - RFC2292: Advanced Sockets API for IPv6 + + RFC2292: Advanced Sockets API for IPv6 For supported library functions/kernel APIs, see - sys/netinet6/ADVAPI. + sys/netinet6/ADVAPI. - + - - RFC2362: Protocol Independent Multicast-Sparse - Mode (PIM-SM) + + RFC2362: Protocol Independent Multicast-Sparse Mode + (PIM-SM) RFC2362 defines packet formats for PIM-SM. - draft-ietf-pim-ipv6-01.txt is - written based on this. + draft-ietf-pim-ipv6-01.txt is + written based on this. - + - + RFC2373: IPv6 Addressing Architecture - supports node required addresses, and conforms to - the scope requirement. + supports node required addresses, and conforms + to the scope requirement. - + - + RFC2374: An IPv6 Aggregatable Global Unicast Address - Format + Format supports 64-bit length of Interface ID. - + - + RFC2375: IPv6 Multicast Address Assignments - Userland applications use the well-known addresses - assigned in the RFC. + Userland applications use the well-known + addresses assigned in the RFC. - + - + RFC2428: FTP Extensions for IPv6 and NATs - RFC2428 is preferred over RFC1639. FTP clients will - first try RFC2428, then RFC1639 if failed. + RFC2428 is preferred over RFC1639. FTP clients + will first try RFC2428, then RFC1639 if + failed. - + - + RFC2460: IPv6 specification - + - + RFC2461: Neighbor discovery for IPv6 - See 23.5.1.2 - in this document for details. + See 23.5.1.2 in + this document for details. - + - - RFC2462: IPv6 Stateless Address Autoconfiguration + + RFC2462: IPv6 Stateless Address + Autoconfiguration - See 23.5.1.4 in this - document for details. + See 23.5.1.4 in + this document for details. - + - + RFC2463: ICMPv6 for IPv6 specification - See 23.5.1.9 in this - document for details. + See 23.5.1.9 in + this document for details. - + - + RFC2464: Transmission of IPv6 Packets over Ethernet - Networks - + Networks + - - RFC2465: MIB for IPv6: Textual Conventions and General - Group + + RFC2465: MIB for IPv6: Textual Conventions and + General Group - Necessary statistics are gathered by the kernel. Actual - IPv6 MIB support is provided as a patchkit for ucd-snmp. + Necessary statistics are gathered by the kernel. + Actual IPv6 MIB support is provided as a patchkit + for ucd-snmp. - + - + RFC2466: MIB for IPv6: ICMPv6 group - Necessary statistics are gathered by the kernel. Actual - IPv6 MIB support is provided as patchkit for ucd-snmp. + Necessary statistics are gathered by the kernel. + Actual IPv6 MIB support is provided as patchkit for + ucd-snmp. - + - + RFC2467: Transmission of IPv6 Packets over FDDI - Networks - + Networks + - + RFC2497: Transmission of IPv6 packet over ARCnet - Networks - + Networks + - - RFC2553: Basic Socket Interface Extensions for IPv6 + + RFC2553: Basic Socket Interface Extensions for + IPv6 - IPv4 mapped address (3.7) and special behavior of IPv6 - wildcard bind socket (3.8) are supported. See 23.5.1.12 - in this document for details. + IPv4 mapped address (3.7) and special behavior + of IPv6 wildcard bind socket (3.8) are supported. + See 23.5.1.12 in + this document for details. - + - + RFC2675: IPv6 Jumbograms - See 23.5.1.7 in - this document for details. + See 23.5.1.7 + in this document for details. - + - - RFC2710: Multicast Listener Discovery for IPv6 - + + RFC2710: Multicast Listener Discovery for + IPv6 + - + RFC2711: IPv6 router alert option - + - - draft-ietf-ipngwg-router-renum-08: Router - renumbering for IPv6 - + + draft-ietf-ipngwg-router-renum-08: + Router renumbering for IPv6 + - + draft-ietf-ipngwg-icmp-namelookups-02: - IPv6 Name Lookups Through ICMP - + IPv6 Name Lookups Through ICMP + - + draft-ietf-ipngwg-icmp-name-lookups-03: - IPv6 Name Lookups Through ICMP - + IPv6 Name Lookups Through ICMP + - - draft-ietf-pim-ipv6-01.txt: - PIM for IPv6 + + draft-ietf-pim-ipv6-01.txt: PIM + for IPv6 - &man.pim6dd.8; implements dense mode. &man.pim6sd.8; - implements sparse mode. + &man.pim6dd.8; implements dense mode. + &man.pim6sd.8; implements sparse mode. - + - + draft-itojun-ipv6-tcp-to-anycast-00: - Disconnecting TCP connection toward IPv6 anycast address - + Disconnecting TCP connection toward IPv6 anycast + address + - - draft-yamamoto-wideipv6-comm-model-00 - + + draft-yamamoto-wideipv6-comm-model-00 - See 23.5.1.6 in this - document for details. + See 23.5.1.6 in + this document for details. - + - - draft-ietf-ipngwg-scopedaddr-format-00.txt - : An Extension of Format for IPv6 Scoped - Addresses - - + + draft-ietf-ipngwg-scopedaddr-format-00.txt: + An Extension of Format for IPv6 Scoped Addresses + + - Neighbor Discovery + Neighbor Discovery - 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. + 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. - 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. + 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. - 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). + 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). - Neighbor Discovery specification (RFC2461) does not talk about - neighbor cache handling in the following cases: + Neighbor Discovery specification (RFC2461) does not talk + about neighbor cache handling in the following cases: - + when there was no neighbor cache entry, node - received unsolicited RS/NS/NA/redirect packet without - link-layer address - - - neighbor cache handling on medium without link-layer - address (we need a neighbor cache entry for IsRouter bit) - + received unsolicited RS/NS/NA/redirect packet without + link-layer address + + + neighbor cache handling on medium without link-layer + address (we need a neighbor cache entry for IsRouter + bit) + - 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. + 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. - 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). + 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). - 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 - sys/netinet6/nd6.c. If there are high demands - we may provide sysctl knob for the variable. + 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 sys/netinet6/nd6.c. If + there are high demands we may provide sysctl knob for the + variable. - Scope Index + Scope Index - 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. + 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. 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. + (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. - 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: - + 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: fe80:1::200:f8ff:fe01:6317 - 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. + 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. - 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. + 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. - 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 - ping6 -I ne0 ff02::1). 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. + 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 ping6 -I ne0 + ff02::1). 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. - Some of the userland tools support extended numeric IPv6 syntax, - as documented in - draft-ietf-ipngwg-scopedaddr-format-00.txt. 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. + Some of the userland tools support extended numeric IPv6 + syntax, as documented in + draft-ietf-ipngwg-scopedaddr-format-00.txt. + 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. - 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. + 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. Plug and Play - 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. + 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. - - Assignment of link-local, and special addresses + + Assignment of link-local, and special + addresses - 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. + 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. Here is an output of netstat command: -Internet6: + Internet6: Destination Gateway Flags Netif Expire fe80:1::%ed0/64 link#1 UC ed0 fe80:2::%ep0/64 link#2 UC ep0 - 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. + 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. - 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. + 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. - 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. - + 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. + - - Stateless address autoconfiguration on hosts + + Stateless address autoconfiguration on Hosts - In IPv6 specification, nodes are separated into two categories: - routers and hosts. 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). + In IPv6 specification, nodes are separated into two + categories: routers and + hosts. 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). - 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 rtsol 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. + 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 rtsol 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. - To generate Router Advertisement from a router, use the - &man.rtadvd.8; daemon. + To generate Router Advertisement from a router, use + the &man.rtadvd.8; daemon. - Note that, IPv6 specification assumes the following items, and - nonconforming cases are left unspecified: + Note that, IPv6 specification assumes the following + items, and nonconforming cases are left + unspecified: - Only hosts will listen to router advertisements + Only hosts will listen to router + advertisements - Hosts have single network interface (except loopback) + Hosts have single network interface (except + loopback) - 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). + 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). To summarize the sysctl knob: - accept_rtadv forwarding role of the node + 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) 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. + 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. - See 23.5.1.2 in - the document for relationship between DAD and - autoconfiguration. - + See 23.5.1.2 + in the document for relationship between DAD and + autoconfiguration. + - Generic tunnel interface + Generic Tunnel Interface - GIF (Generic InterFace) is a pseudo interface for configured - tunnel. Details are described in &man.gif.4;. Currently + GIF (Generic InterFace) is a pseudo interface for + configured tunnel. Details are described in &man.gif.4;. + Currently @@ -562,267 +612,286 @@ fe80:2::%ep0/64 link#2 - 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. - Please be warned. + 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. Please be + warned. - gif can be configured to be ECN-friendly. See 23.5.4.5 for ECN-friendliness of - tunnels, and &man.gif.4; for how to configure. + gif can be configured to be ECN-friendly. See 23.5.4.5 for ECN-friendliness + of tunnels, and &man.gif.4; for how to configure. - 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. + 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. Source Address Selection - 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: + 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: - If the source address is explicitly specified by - the user (e.g. via the advanced API), the specified address - is used. + If the source address is explicitly specified by the + user (e.g., via the advanced API), the specified + address is used. 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. + interface (which is usually determined by looking up the + routing table) that has the same scope as the + destination address, the address is used. This is the most typical case. If there is no address that satisfies the above - condition, choose a global address assigned to one of - the interfaces on the sending node. + condition, choose a global address assigned to one of + the interfaces on the sending node. - 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. - *** DIFF OUTPUT TRUNCATED AT 1000 LINES ***