add faith(4), gif(4) and inet6(4).

4 files changed, 648 insertions, 1 deletions

diff --git a/share/man/man4/Makefile b/share/man/man4/Makefile
index 6414bb1d3e4..921460aae61 100644
--- a/share/man/man4/Makefile
+++ b/share/man/man4/Makefile
@@ -1,4 +1,4 @@
-#	$OpenBSD: Makefile,v 1.87 1999/12/07 22:56:44 jason Exp $
+#	$OpenBSD: Makefile,v 1.88 1999/12/08 13:58:42 itojun Exp $
 #	$NetBSD: Makefile,v 1.22.4.2 1996/07/18 00:51:10 jtc Exp $
 
 MAN=	ac97.4 atalk.4 atapiscsi.4 audio.4 adv.4 ahc.4 al.4 ax.4 bpf.4 \
@@ -14,6 +14,9 @@ MAN=	ac97.4 atalk.4 atapiscsi.4 audio.4 adv.4 ahc.4 al.4 ax.4 bpf.4 \
 	tl.4 tlphy.4 tp.4 tqphy.4 tty.4 tun.4 tx.4 udp.4 ugen.4 uhid.4 uk.4 \
 	ukphy.4 unix.4 usb.4 vnd.4 vr.4 wb.4 wd.4 we.4 xl.4 ym.4 zero.4
 
+# IPv6
+MAN+=	faith.4 gif.4 inet6.4
+
 MLINKS+=fd.4 stderr.4 fd.4 stdin.4 fd.4 stdout.4
 MLINKS+=netintro.4 networking.4
 MLINKS+=random.4 srandom.4 random.4 urandom.4 random.4 prandom.4 
diff --git a/share/man/man4/faith.4 b/share/man/man4/faith.4
new file mode 100644
index 00000000000..c3fdddcd475
--- /dev/null
+++ b/share/man/man4/faith.4
@@ -0,0 +1,123 @@
+.\"	$OpenBSD: faith.4,v 1.1 1999/12/08 13:58:42 itojun Exp $
+.\"
+.\" Copyright (C) 1995, 1996, 1997, and 1998 WIDE Project.
+.\" All rights reserved.
+.\" 
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"    notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"    notice, this list of conditions and the following disclaimer in the
+.\"    documentation and/or other materials provided with the distribution.
+.\" 3. Neither the name of the project nor the names of its contributors
+.\"    may be used to endorse or promote products derived from this software
+.\"    without specific prior written permission.
+.\" 
+.\" THIS SOFTWARE IS PROVIDED BY THE PROJECT AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE PROJECT OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\"
+.\"     KAME Id: faith.4,v 1.1.1.1 1999/08/08 23:30:37 itojun Exp
+.\"
+.Dd April 10, 1999
+.Dt FAITH 4
+.Os
+.Sh NAME
+.Nm faith
+.Nd
+.Tn IPv6-to-IPv4 TCP relay capturing interface
+.Sh SYNOPSIS
+.Cd "pseudo-device faith 1"
+.Sh DESCRIPTION
+The
+.Nm
+interface captures IPv6 TCP traffic,
+for implementing userland IPv6-to-IPv4 TCP relay
+like
+.Xr faithd 8 .
+.Pp
+Special action will be taken when IPv6 TCP traffic is seen on a router,
+and routing table suggests to route it to
+.Nm
+interface.
+In this case, the packet will be accepted by the router,
+regardless of list of IPv6 interface addresses assigned to the router.
+The packet will be captured by an IPv6 TCP socket, if it has
+.Dv IN6P_FAITH
+flag turned on and it has matching address/port pairs.
+In result,
+.Nm
+will let you capture IPv6 TCP traffic to some specific destination addresses.
+Userland programs, such as
+.Xr faithd 8
+can use this behavior to relay IPv6 TCP traffic to IPv4 TCP traffic.
+The program can accept some specific IPv6 TCP traffic, perform
+.Xr getsockname 3
+to get the IPv6 destination address specified by the client,
+and perform application-specific address mapping to relay IPv6 TCP to IPv4 TCP.
+.Pp
+.Dv IN6P_FAITH
+flag on IPv6 TCP socket can be set by using
+.Xr setsockopt 2 ,
+with level equals to
+.Dv IPPROTO_IPV6
+and optname equals to
+.Dv IPv6_FAITH .
+.Pp
+To handle error reports by ICMPv6, some of ICMPv6 packets routed to
+.Nm
+interface will be delivered to IPv6 TCP, as well.
+.Pp
+To understand how
+.Nm
+can be used, take a look at source code of
+.Xr faithd 8 .
+.Pp
+As
+.Nm
+interface implements potentially dangerous operation,
+great care must be taken when configuring
+.Nm
+interface.
+To avoid possible misuse,
+.Xr sysctl 8
+variable
+.Li net.inet6.ip6.keepfaith
+must be set to
+.Li 1
+prior to the use of the interface.
+When
+.Li net.inet6.ip6.keepfaith
+is
+.Li 0 ,
+no packet will be captured by
+.Nm
+interface.
+.Pp
+.Nm
+interface is intended to be used on routers, not on hosts.
+.\"
+.Sh SEE ALSO
+.Xr inet 4 ,
+.Xr inet6 4 ,
+.Xr faithd 8 .
+.\" .Rs
+.\" .%A	Jun-ichiro itojun Hagino
+.\" .%A	Kazu Yamamoto
+.\" .%T	``FAITH'' IPv6-to-IPv4 TCP relay translator
+.\" .%D	July 1999
+.\" .Re
+.\"
+.Sh HISTORY
+The FAITH IPv6-to-IPv4 TCP relay translator was first appeared in
+WIDE hydrangea IPv6 stack.
diff --git a/share/man/man4/gif.4 b/share/man/man4/gif.4
new file mode 100644
index 00000000000..415325b0e69
--- /dev/null
+++ b/share/man/man4/gif.4
@@ -0,0 +1,233 @@
+.\"	$OpenBSD: gif.4,v 1.1 1999/12/08 13:58:42 itojun Exp $
+.\"
+.\" Copyright (C) 1995, 1996, 1997, and 1998 WIDE Project.
+.\" All rights reserved.
+.\" 
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"    notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"    notice, this list of conditions and the following disclaimer in the
+.\"    documentation and/or other materials provided with the distribution.
+.\" 3. Neither the name of the project nor the names of its contributors
+.\"    may be used to endorse or promote products derived from this software
+.\"    without specific prior written permission.
+.\" 
+.\" THIS SOFTWARE IS PROVIDED BY THE PROJECT AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE PROJECT OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\"
+.\"     KAME Id: gif.4,v 1.2 1999/09/29 15:36:17 itojun Exp
+.\"
+.Dd April 10, 1999
+.Dt GIF 4
+.Os
+.Sh NAME
+.Nm gif
+.Nd
+.Tn Generic tunnel interface
+.Sh SYNOPSIS
+.Cd "pseudo-device gif 4"
+.Sh DESCRIPTION
+The
+.Nm
+interface is a generic tunnelling pseudo device for IPv4 and IPv6.
+It can tunnel IPv[46] traffic over IPv[46].
+Therefore, there can be four possible configurations.
+The behavior of
+.Nm
+is mainly based on RFC1933 IPv6-over-IPv4 configured tunnel.
+.Pp
+To use
+.Nm gif ,
+administrator needs to configure protocol and addresses used for the outer 
+header.
+This can be done by using
+.Xr gifconfig 8 ,
+or
+.Dv SIOCSIFPHYADDR
+ioctl.
+Also, administrator needs to configure protocol and addresses used for the
+inner header, by using
+.Xr ifconfig 8 .
+Note that IPv6 link-local address
+.Pq those start with Li fe80::
+will be automatically configured whenever possible.
+You may need to remove IPv6 link-local address manually using
+.Xr ifconfig 8 ,
+when you would like to disable the use of IPv6 as inner header
+.Pq like when you need pure IPv4-over-IPv6 tunnel .
+Finally, use routing table to route the packets toward
+.Nm
+interface.
+.Pp
+.Nm
+interface can be configued to perform bidirectional tunnel, or
+multi-destination tunnel.
+This is controlled by
+.Dv IFF_LINK0
+interface flag.
+Also,
+.Nm
+can be configured to be ECN friendly.
+This can be configured by
+.Dv IFF_LINK1 .
+.\"
+.Ss Bidirectional and multi-destination mode
+Usually,
+.Nm
+implements bidirectional tunnel.
+.Xr gifconfig 8
+should configure a tunnel ingress point
+.Pq this node
+and an egress point
+.Pq tunnel endpoint ,
+and
+one
+.Nm
+interface will tunnel to only a single tunnel endpoint,
+and accept from only a single tunnel endpoint.
+Source and destination address for outer IP header is always the
+ingress and the egress point configued by
+.Xr gifconfig 8 .
+.Pp
+With
+.Dv IFF_LINK0
+interface flag,
+.Nm
+can be configured to implement multi-destination tunnel.
+With
+.Dv IFF_LINK0 ,
+it is able to configure egress point to IPv4 wildcard address
+.Pq Nm 0.0.0.0
+or IPv6 unspecified address
+.Pq Nm 0::0 .
+In this case, destination address for the outer IP header is
+determined based on the routing table setup.
+Therefore, one
+.Nm
+interface can tunnel to multiple destinations.
+Also,
+.Nm
+will accept tunneled traffic from any outer source address.
+.Pp
+When finding a
+.Nm gif
+interface from the inbound tunneled traffic,
+bidirectional mode interface is preferred than multi-destination mode interface.
+For example, if you have the following three
+.Nm
+interfaces on node A, tunneled traffic from C to A will match the second
+.Nm
+interface, not the third one.
+.Bl -bullet -compact -offset indent
+.It
+bidirectional, A to B
+.It
+bidirectional, A to C
+.It
+multi-destination, A to any
+.El
+.Pp
+Please note that multi-destination mode is far less secure
+than bidirectional mode.
+Multi-destination mode
+.Nm
+can accept tunneled packet from anybody,
+and can be attacked from a malicious node.
+.Pp
+.Ss ECN friendly behavior
+.Nm
+can be configured to be ECN friendly, as described in
+.Dv draft-ipsec-ecn-00.txt .
+This is turned off by default, and can be turned on by
+.Dv IFF_LINK1
+interface flag.
+.Pp
+Without
+.Dv IFF_LINK1 ,
+.Nm
+will show a normal behavior, like described in RFC1933.
+This can be summarized as follows:
+.Bl -tag -width "Ingress" -offset indent
+.It Ingress
+Set outer TOS bit to
+.Dv 0 .
+.It Egress
+Drop outer TOS bit.
+.El
+.Pp
+With
+.Dv IFF_LINK1 ,
+.Nm
+will copy ECN bits
+.Po
+.Dv 0x02
+and
+.Dv 0x01
+on IPv4 TOS byte or IPv6 traffic class byte
+.Pc
+on egress and ingress, as follows:
+.Bl -tag -width "Ingress" -offset indent
+.It Ingress
+Copy TOS bits except for ECN CE
+.Po
+masked with
+.Dv 0xfe
+.Pc
+from
+inner to outer.
+set ECN CE bit to
+.Dv 0 .
+.It Egress
+Use inner TOS bits with some change.
+If outer ECN CE bit is
+.Dv 1 ,
+enable ECN CE bit on the inner.
+.El
+.Pp
+Note that the ECN friendly behavior violates RFC1933.
+This should be used in mutual agreement with the tunnel endpoint.
+.Pp
+.Ss Backward compatibility
+.Nm
+interface will capture packets toward IPv4-in-IPv4 tunnel,
+which has been used by
+.Xr vif 4 
+multicast tunnel device
+.Pq used in MBone community .
+For compatibility, IPv4-in-IPv4 traffic will be matched to
+.Nm
+interfaces first, and then sent to
+.Xr vif 4
+if no match is found.
+.\"
+.Sh SEE ALSO
+.Xr inet 4 ,
+.Xr inet6 4 ,
+.Xr vif 4 ,
+.Xr gifconfig 8 ,
+RFC1933
+.Rs
+.%A	Sally Floyd
+.%A	David L. Black
+.%A	K. K. Ramakrishnan
+.%T	"IPsec Interactions with ECN"
+.%D	February 1999
+.%O	http://www.aciri.org/floyd/papers/draft-ipsec-ecn-00.txt
+.Re
+.\"
+.Sh HISTORY
+The
+.Nm
+device first appeared in WIDE hydrangea IPv6 kit.
diff --git a/share/man/man4/inet6.4 b/share/man/man4/inet6.4
new file mode 100644
index 00000000000..7328dfae2f0
--- /dev/null
+++ b/share/man/man4/inet6.4
@@ -0,0 +1,288 @@
+.\"	$OpenBSD: inet6.4,v 1.1 1999/12/08 13:58:42 itojun Exp $
+.\"
+.\" Copyright (C) 1995, 1996, 1997, and 1998 WIDE Project.
+.\" All rights reserved.
+.\" 
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"    notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"    notice, this list of conditions and the following disclaimer in the
+.\"    documentation and/or other materials provided with the distribution.
+.\" 3. Neither the name of the project nor the names of its contributors
+.\"    may be used to endorse or promote products derived from this software
+.\"    without specific prior written permission.
+.\" 
+.\" THIS SOFTWARE IS PROVIDED BY THE PROJECT AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE PROJECT OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\"
+.\"	KAME Id: inet6.4,v 1.1.1.1 1999/08/08 23:30:37 itojun Exp
+.\"
+.Dd January 29, 1999
+.Dt INET6 4
+.Os
+.Sh NAME
+.Nm inet6
+.Nd Internet protocol version 6 family
+.Sh SYNOPSIS
+.Fd #include <sys/types.h>
+.Fd #include <netinet/in.h>
+.Sh DESCRIPTION
+The
+.Nm
+family is an updated version of
+.Xr inet 4
+family.
+While
+.Xr inet 4
+implements Internet Protocol version 4,
+.Nm
+implements Internet Protocol version 6.
+.Pp
+.Nm
+is a collection of protocols layered atop the
+.Em Internet Protocol version 6
+.Pq Tn IPv6
+transport layer, and utilizing the IPv6 address format.
+The
+.Nm
+family provides protocol support for the
+.Dv SOCK_STREAM , SOCK_DGRAM ,
+and
+.Dv SOCK_RAW
+socket types; the
+.Dv SOCK_RAW
+interface provides access to the
+.Tn IPv6
+protocol.
+.Sh ADDRESSING
+IPv6 addresses are 16 byte quantities, stored in network standard format
+The include file
+.Aq Pa netinet/in.h
+defines this address
+as a discriminated union.
+.Pp
+Sockets bound to the
+.Nm
+family utilize the following addressing structure,
+.Bd -literal -offset indent
+struct sockaddr_in6 {
+	u_char		sin6_len;
+	u_char		sin6_family;
+	u_int16_t	sin6_port;
+	u_int32_t	sin6_flowinfo;
+	struct in6_addr	sin6_addr;
+	u_int32_t	sin6_scope_id;
+};
+.Ed
+.Pp
+Sockets may be created with the local address
+.Dq Dv ::
+.Po
+which is equal to IPv6 address
+.Dv 0:0:0:0:0:0:0:0
+.Pc
+to effect
+.Dq wildcard
+matching on incoming messages. 
+The address in a
+.Xr connect 2
+or
+.Xr sendto 2
+call may be given as
+.Dq Dv ::
+to mean
+.Dq this host .
+.Dq Dv ::
+can be obtained by setting
+.Dv sin6_addr
+field into 0, or by using the address contained in variable
+.Dv in6addr_any .
+.Pp
+IPv6 defines scoped address such as link-local or site-local address.
+To manipulate link-local addresses properly from the userland,
+programs must use advanced API defined in RFC2292.
+Otherwise, the address is ambiguous to the kernel and error will be generated.
+Scoped address is not for daily use at this moment both from specification
+and implementation point of view.
+Most of normal userland program
+like
+.Xr telnet 1
+or
+.Xr telnetd 8
+cannot handle scoped address properly.
+Only special programs,
+like
+.Xr ping6 8 ,
+supports scoped address.
+For example,
+.Xr ping6 8
+has special option for specifying outgoing interface
+to disambiguate scoped addresses.
+.Pp
+Scoped addresses are handled specially in the kernel.
+Scoped addresses will have its interface index embedded into the address,
+in routing table or interface structure.
+Therefore,
+the address on some of the kernel structure is not the same as that on the wire.
+The embedded index will be visible on
+.Dv PF_ROUTE
+socket and results from
+.Xr ifconfig 8 ,
+HOWEVER, users should never use the embedded form.
+For details please consult
+.Pa IMPLEMENTATION
+supplied with KAME kit.
+.Sh PROTOCOLS
+The
+.Nm
+family is comprised of the
+.Tn IPv6
+network protocol, Internet Control
+Message Protocol version 6
+.Pq Tn ICMPv6 ,
+Transmission Control Protocol
+.Pq Tn TCP ,
+and User Datagram Protocol
+.Pq Tn UDP .
+.Tn TCP
+is used to support the
+.Dv SOCK_STREAM
+abstraction while
+.Tn UDP
+is used to support the
+.Dv SOCK_DGRAM
+abstraction.
+Note that
+.Tn TCP
+and
+.Tn UDP
+are common to
+.Xr inet 4
+and
+.Nm inet6 .
+A raw interface to
+.Tn IPv6
+is available
+by creating an Internet socket of type
+.Dv SOCK_RAW .
+The
+.Tn ICMPv6
+message protocol is accessible from a raw socket.
+.\" .Pp
+.\" The 128-bit IPv6 address contains both network and host parts.
+.\" However, direct examination of addresses is discouraged.
+.\" For those programs which absolutely need to break addresses
+.\" into their component parts, the following
+.\" .Xr ioctl 2
+.\" commands are provided for a datagram socket in the
+.\" .Nm
+.\" domain; they have the same form as the
+.\" .Dv SIOCIFADDR
+.\" command (see
+.\" .Xr intro 4 ) .
+.\" .Pp
+.\" .Bl -tag -width SIOCSIFNETMASK
+.\" .It Dv SIOCSIFNETMASK
+.\" Set interface network mask.
+.\" The network mask defines the network part of the address;
+.\" if it contains more of the address than the address type would indicate,
+.\" then subnets are in use.
+.\" .It Dv SIOCGIFNETMASK
+.\" Get interface network mask.
+.\" .El
+.\" .Sh ROUTING
+.\" The current implementation of Internet protocols includes some routing-table
+.\" adaptations to provide enhanced caching of certain end-to-end
+.\" information necessary for Transaction TCP and Path MTU Discovery.  The
+.\" following changes are the most significant:
+.\" .Bl -enum
+.\" .It
+.\" All IP routes, except those with the
+.\" .Dv RTF_CLONING
+.\" flag and those to multicast destinations, have the
+.\" .Dv RTF_PRCLONING
+.\" flag forcibly enabled (they are thus said to be
+.\" .Dq "protocol cloning" ).
+.\" .It
+.\" When the last reference to an IP route is dropped, the route is
+.\" examined to determine if it was created by cloning such a route.  If
+.\" this is the case, the
+.\" .Dv RTF_PROTO3
+.\" flag is turned on, and the expiration timer is initialized to go off
+.\" in net.inet.ip.rtexpire seconds.  If such a route is re-referenced,
+.\" the flag and expiration timer are reset.
+.\" .It
+.\" A kernel timeout runs once every ten minutes, or sooner if there are
+.\" soon-to-expire routes in the kernel routing table, and deletes the
+.\" expired routes.
+.\" .El
+.\" .Pp
+.\" A dynamic process is in place to modify the value of
+.\" net.inet.ip.rtexpire if the number of cached routes grows too large.
+.\" If after an expiration run there are still more than
+.\" net.inet.ip.rtmaxcache unreferenced routes remaining, the rtexpire
+.\" value is multiplied by 3/4, and any routes which have longer
+.\" expiration times have those times adjusted.  This process is damped
+.\" somewhat by specification of a minimum rtexpire value
+.\" (net.inet.ip.rtminexpire), and by restricting the reduction to once in
+.\" a ten-minute period.
+.\" .Pp
+.\" If some external process deletes the original route from which a
+.\" protocol-cloned route was generated, the ``child route'' is deleted.
+.\" (This is actually a generic mechanism in the routing code support for
+.\" protocol-requested cloning.)
+.\" .Pp
+.\" No attempt is made to manage routes which were not created by protocol
+.\" cloning; these are assumed to be static, under the management of an
+.\" external routing process, or under the management of a link layer
+.\" (e.g.,
+.\" .Tn ARP
+.\" for Ethernets).
+.\" .Pp
+.\" Only certain types of network activity will result in the cloning of a
+.\" route using this mechanism.  Specifically, those protocols (such as
+.\" .Tn TCP
+.\" and
+.\" .Tn UDP )
+.\" which themselves cache a long-lasting reference to route for a destination
+.\" will trigger the mechanism; whereas raw
+.\" .Tn IP
+.\" packets, whether locally-generated or forwarded, will not.
+.Sh SEE ALSO
+.Xr ioctl 2 ,
+.Xr socket 2 ,
+.Xr sysctl 3 ,
+.Xr icmp6 4 ,
+.Xr intro 4 ,
+.\" .Xr ip6 4 ,
+.Xr tcp 4 ,
+.Xr ttcp 4 ,
+.Xr udp 4
+.Sh CAVEAT
+The IPv6 support is subject to change as the Internet protocols develop.
+Users should not depend on details of the current implementation,
+but rather the services exported.
+.Pp
+Users are suggested to implement
+.Dq version independent
+code as much as possible, as you will need to support both
+.Xr inet 4
+and
+.Nm inet6 .
+.Sh HISTORY
+The
+.Nm
+protocol interface are defined in RFC2553 and RFC2292.
+The implementation described herein appeared in WIDE/KAME project.