Sync with recent KAME.

This work was based on kame-20010528-freebsd43-snap.tgz and some
critical problem after the snap was out were fixed.
There are many many changes since last KAME merge.

TODO:
  - The definitions of SADB_* in sys/net/pfkeyv2.h are still different
    from RFC2407/IANA assignment because of binary compatibility
    issue.  It should be fixed under 5-CURRENT.
  - ip6po_m member of struct ip6_pktopts is no longer used.  But, it
    is still there because of binary compatibility issue.  It should
    be removed under 5-CURRENT.

Reviewed by:	itojun
Obtained from:	KAME
MFC after:	3 weeks

7 files changed, 196 insertions, 207 deletions

diff --git a/share/man/man4/faith.4 b/share/man/man4/faith.4
index 4ecc609..c87563c 100644
--- a/share/man/man4/faith.4
+++ b/share/man/man4/faith.4
@@ -1,3 +1,5 @@
+.\"	$KAME: faith.4,v 1.9 2001/04/27 17:26:35 itojun Exp $
+.\"
 .\" Copyright (C) 1995, 1996, 1997, and 1998 WIDE Project.
 .\" All rights reserved.
 .\"
@@ -25,7 +27,6 @@
 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 .\" SUCH DAMAGE.
 .\"
-.\"     $Id: faith.4,v 1.1.1.1 1999/08/08 23:30:37 itojun Exp $
 .\"     $FreeBSD$
 .\"
 .Dd April 10, 1999
@@ -33,33 +34,31 @@
 .Os
 .Sh NAME
 .Nm faith
-.Nd
-.Tn IPv6-to-IPv4 TCP
-relay capturing interface
+.Nd IPv6-to-IPv4 TCP relay capturing interface
 .Sh SYNOPSIS
-.Cd "device faith 1"
+.Cd "device faith" Op Ar count
 .Sh DESCRIPTION
 The
 .Nm
-interface captures IPv6 TCP traffic
-for implementing userland IPv6-to-IPv4 TCP relays
+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 the routing table suggests to route it to the
+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 the list of IPv6 interface addresses assigned to the router.
-The packet will be captured by an IPv6 TCP socket if it has the
+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.
-As a result,
+In result,
 .Nm
-will let you divert IPv6 TCP traffic to some specific destination addresses.
+will let you capture IPv6 TCP traffic to some specific destination addresses.
 Userland programs, such as
-.Xr faithd 8 ,
+.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 2
@@ -68,33 +67,29 @@ and perform application-specific address mapping to relay IPv6 TCP to IPv4 TCP.
 .Pp
 The
 .Dv IN6P_FAITH
-flag on an IPv6 TCP socket can be set by using
+flag on IPv6 TCP socket can be set by using
 .Xr setsockopt 2 ,
-with
-.Fa level
-set to
+with level equals to
 .Dv IPPROTO_IPV6
-and
-.Fa optname
-set to
+and optname equals to
 .Dv IPv6_FAITH .
 .Pp
-To handle error reports by ICMPv6 some of the ICMPv6 packets routed to the
+To handle error reports by ICMPv6, some of ICMPv6 packets routed to
 .Nm
-interface will need be delivered to IPv6 TCP as well.
+interface will be delivered to IPv6 TCP, as well.
 .Pp
 To understand how
 .Nm
-can be used take a look at the source code of
+can be used, take a look at source code of
 .Xr faithd 8 .
 .Pp
-As the
+As
 .Nm
-interface implements potentially dangerous operations,
-great care must be taken when configuring the
+interface implements potentially dangerous operation,
+great care must be taken when configuring
 .Nm
 interface.
-To avoid possible misuse the
+To avoid possible misuse,
 .Xr sysctl 8
 variable
 .Li net.inet6.ip6.keepfaith
@@ -103,13 +98,12 @@ must be set to
 prior to the use of the interface.
 When
 .Li net.inet6.ip6.keepfaith
-is set to
+is
 .Li 0 ,
-no packets will be captured by the
+no packet will be captured by
 .Nm
 interface.
 .Pp
-The
 .Nm
 interface is intended to be used on routers, not on hosts.
 .\"
@@ -117,13 +111,14 @@ interface is intended to be used on routers, not on hosts.
 .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
-.\"
+.Rs
+.%A Jun-ichiro itojun Hagino
+.%A Kazu Yamamoto
+.%T "An IPv6-to-IPv4 transport relay translator"
+.%R internet draft
+.%N draft-ietf-ngtrans-tcpudp-relay-04.txt
+.%O work in progress material
+.Re
 .Sh HISTORY
-The FAITH IPv6-to-IPv4 TCP relay translator first appeared in
+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
index a9cba1e..2d25c69 100644
--- a/share/man/man4/gif.4
+++ b/share/man/man4/gif.4
@@ -1,5 +1,5 @@
 .\"	$FreeBSD$
-.\"	$KAME: gif.4,v 1.17 2000/06/30 18:31:27 itojun Exp $
+.\"	$KAME: gif.4,v 1.28 2001/05/18 13:15:56 itojun Exp $
 .\"
 .\" Copyright (C) 1995, 1996, 1997, and 1998 WIDE Project.
 .\" All rights reserved.
@@ -44,7 +44,11 @@ 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.
+is mainly based on RFC2893 IPv6-over-IPv4 configured tunnel.
+On
+.Nx ,
+.Nm
+can also tunnel ISO traffic over IPv[46] using EON encapsulation.
 .Pp
 To use
 .Nm ,
@@ -70,79 +74,9 @@ Finally, use routing table to route the packets toward
 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 Li 0.0.0.0
-or IPv6 unspecified address
-.Pq Li 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
-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
@@ -155,7 +89,7 @@ interface flag.
 Without
 .Dv IFF_LINK1 ,
 .Nm
-will show a normal behavior, like described in RFC1933.
+will show a normal behavior, like described in RFC2893.
 This can be summarized as follows:
 .Bl -tag -width "Ingress" -offset indent
 .It Ingress
@@ -194,7 +128,7 @@ If outer ECN CE bit is
 enable ECN CE bit on the inner.
 .El
 .Pp
-Note that the ECN friendly behavior violates RFC1933.
+Note that the ECN friendly behavior violates RFC2893.
 This should be used in mutual agreement with the peer.
 .Pp
 .Ss Security
@@ -206,10 +140,9 @@ performs martian filter and ingress filter against outer source address,
 on egress.
 Note that martian/ingress filters are no way complete.
 You may want to secure your node by using packet filters.
-.Pp
-As mentioned above, multi-destination mode
-.Pq Dv IFF_LINK0
-is far less secure than bidirectional mode.
+Ingress filter can be turned off by
+.Dv IFF_LINK2
+bit.
 .\"
 .Sh SEE ALSO
 .Xr inet 4 ,
@@ -218,10 +151,10 @@ is far less secure than bidirectional mode.
 .Rs
 .%A	R. Gilligan
 .%A	E. Nordmark
-.%B	RFC1933
+.%B	RFC2893
 .%T	Transition Mechanisms for IPv6 Hosts and Routers
-.%D	April 1996
-.%O	ftp://ftp.isi.edu/in-notes/rfc1933.txt
+.%D	August 2000
+.%O	ftp://ftp.isi.edu/in-notes/rfc2893.txt
 .Re
 .Rs
 .%A	Sally Floyd
@@ -256,7 +189,24 @@ Make sure to configure an address which belongs to your node.
 Otherwise, your node will not be able to receive packets from the peer,
 and your node will generate packets with a spoofed source address.
 .Pp
-.Xr gif 4
-is an
-.Dv IFF_POINTOPOINT
-device, however, it supports NBMA behavior in multi-destination mode.
+If the outer protocol is IPv4,
+.Nm
+does not try to perform path MTU discovery for the encapsulated packet
+.Pq DF bit is set to 0 .
+.Pp
+If the outer protocol is IPv6, path MTU discovery for encapsulated packet
+may affect communication over the interface.
+The first bigger-than-pmtu packet may be lost.
+To avoid the problem, you may want to set the interface MTU for
+.Nm
+to 1240 or smaller, when outer header is IPv6 and inner header is IPv4.
+.Pp
+.Nm
+does not translate ICMP messages for outer header into inner header.
+.Pp
+In the past,
+.Nm
+had a multi-destination behavior, configurable via
+.Dv IFF_LINK0
+flag.
+The behavior was obsoleted and is no longer supported.
diff --git a/share/man/man4/inet6.4 b/share/man/man4/inet6.4
index 3ba609e..62607ec 100644
--- a/share/man/man4/inet6.4
+++ b/share/man/man4/inet6.4
@@ -1,5 +1,5 @@
 .\"	$FreeBSD$
-.\"	$KAME: inet6.4,v 1.16 2000/07/05 08:18:42 itojun Exp $
+.\"	$KAME: inet6.4,v 1.21 2001/04/05 01:00:18 itojun Exp $
 .\"
 .\" Copyright (C) 1995, 1996, 1997, and 1998 WIDE Project.
 .\" All rights reserved.
@@ -74,7 +74,7 @@ as a discriminated union.
 .Pp
 Sockets bound to the
 .Nm
-family utilize the following addressing structure,
+family utilize the following addressing structure:
 .Bd -literal -offset indent
 struct sockaddr_in6 {
 	u_int8_t	sin6_len;
@@ -95,34 +95,21 @@ which is equal to IPv6 address
 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 specification defines scoped address,
-like link-local or site-local address.
+The IPv6 specification defines scoped addresses,
+like link-local or site-local addresses.
 A scoped address is ambiguous to the kernel,
-if it is specified without scope identifier.
+if it is specified without a scope identifier.
 To manipulate scoped addresses properly from the userland,
-programs must use advanced API defined in RFC2292.
-Compact description on the advanced API is available in
+programs must use the advanced API defined in RFC2292.
+A compact description of the advanced API is available in
 .Xr ip6 4 .
-If scoped addresses are specified without explicit scope,
-the kernel may raise error.
+If a scoped address is specified without an explicit scope,
+the kernel may raise an error.
 Note that scoped addresses are not for daily use at this moment,
-both from specification and implementation point of view.
+both from a specification and an implementation point of view.
 .Pp
-KAME implementation supports extended numeric IPv6 address notation
+The KAME implementation supports an extended numeric IPv6 address notation
 for link-local addresses,
 like
 .Dq Li fe80::1%de0
@@ -133,7 +120,7 @@ on
 .Li de0
 interface
 .Dc .
-The notation is supported by
+This notation is supported by
 .Xr getaddrinfo 3
 and
 .Xr getnameinfo 3 .
@@ -141,23 +128,23 @@ Some of normal userland programs, such as
 .Xr telnet 1
 or
 .Xr ftp 1 ,
-are able to use the notation.
+are able to use this notation.
 With special programs
 like
 .Xr ping6 8 ,
-you can specify outgoing interface by extra command line option
+you can specify the outgoing interface by an extra command line option
 to disambiguate scoped addresses.
 .Pp
 Scoped addresses are handled specially in the kernel.
-In the kernel structures like routing tables or interface structure,
-scoped addresses will have its interface index embedded into the address.
+In kernel structures like routing tables or interface structures,
+a scoped address will have its interface index embedded into the address.
 Therefore,
-the address on some of the kernel structure is not the same as that on the wire.
-The embedded index will become visible on
+the address in some kernel structures is not the same as that on the wire.
+The embedded index will become visible through a
 .Dv PF_ROUTE
 socket, kernel memory accesses via
 .Xr kvm 3
-and some other occasions.
+and on some other occasions.
 HOWEVER, users should never use the embedded form.
 For details please consult
 .Pa IMPLEMENTATION
@@ -431,20 +418,20 @@ which initiates dynamic adaptation (default 128).
 The behavior of 
 .Dv AF_INET6
 TCP/UDP socket is documented in RFC2553.
-Basically, it says as follows:
+Basically, it says this:
 .Bl -bullet -compact
 .It
-Specific bind on
+A specific bind on an
 .Dv AF_INET6
 socket
 .Po
 .Xr bind 2
-with address specified
+with an address specified
 .Pc
 should accept IPv6 traffic to that address only.
 .It
-If you perform wildcard bind
-on
+If you perform a wildcard bind
+on an
 .Dv AF_INET6
 socket
 .Po
@@ -458,33 +445,33 @@ socket on that TCP/UDP port, IPv6 traffic as well as IPv4 traffic
 should be routed to that
 .Dv AF_INET6
 socket.
-IPv4 traffic should be seen as if it came from IPv6 address like
+IPv4 traffic should be seen as if it came from an IPv6 address like
 .Li ::ffff:10.1.1.1 .
-This is called IPv4 mapped address.
+This is called an IPv4 mapped address.
 .It
-If there are both wildcard bind
+If there are both a wildcard bind
 .Dv AF_INET
-socket and wildcard bind
+socket and a wildcard bind
 .Dv AF_INET6
 socket on one TCP/UDP port, they should behave separately.
-IPv4 traffic should be routed to
+IPv4 traffic should be routed to the
 .Dv AF_INET
-socket and IPv6 should be routed to
+socket and IPv6 should be routed to the
 .Dv AF_INET6
 socket.
 .El
 .Pp
-However, RFC2553 does not define the constraint between the order of
+However, RFC2553 does not define the ordering constraint between calls to
 .Xr bind 2 ,
-nor how IPv4 TCP/UDP port number and IPv6 TCP/UDP port number
-relate each other
+nor how IPv4 TCP/UDP port numbers and IPv6 TCP/UDP port numbers
+relate to each other
 .Po
 should they be integrated or separated
 .Pc .
-Implemented behavior is very different across kernel to kernel.
+Implemented behavior is very different from kernel to kernel.
 Therefore, it is unwise to rely too much upon the behavior of
 .Dv AF_INET6
-wildcard bind socket.
+wildcard bind sockets.
 It is recommended to listen to two sockets, one for
 .Dv AF_INET
 and another for
@@ -497,7 +484,7 @@ and are able to bypass access control,
 if the target node routes IPv4 traffic to
 .Dv AF_INET6
 socket.
-Users are advised to take caution handling connections
+Users are advised to take care handling connections
 from IPv4 mapped address to
 .Dv AF_INET6
 sockets.
@@ -506,7 +493,7 @@ sockets.
 .\"KAME/NetBSD and KAME/OpenBSD
 .\"does not route IPv4 traffic to
 .\".Dv AF_INET6
-.\"socket.
+.\"sockets.
 .\"Listen to two sockets if you want to accept both IPv4 and IPv6 traffic.
 .\"On KAME/NetBSD, IPv4 traffic may be routed with certain
 .\"per-socket/per-node configuration, however, it is not recommended.
@@ -536,8 +523,8 @@ sockets.
 .Sh HISTORY
 The
 .Nm
-protocol interface are defined in RFC2553 and RFC2292.
-The implementation described herein appeared in WIDE/KAME project.
+protocol interfaces are defined in RFC2553 and RFC2292.
+The implementation described herein appeared in the WIDE/KAME project.
 .Sh BUGS
 The IPv6 support is subject to change as the Internet protocols develop.
 Users should not depend on details of the current implementation,
diff --git a/share/man/man4/ip6.4 b/share/man/man4/ip6.4
index 920753e..9cd5631 100644
--- a/share/man/man4/ip6.4
+++ b/share/man/man4/ip6.4
@@ -1,6 +1,8 @@
+.\"	$KAME: ip6.4,v 1.14 2001/02/26 09:31:39 itojun Exp $
+.\"
 .\" Copyright (C) 1999 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:
@@ -12,7 +14,7 @@
 .\" 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
@@ -56,7 +58,6 @@
 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 .\" SUCH DAMAGE.
 .\"
-.\"	KAME $Id: ip6.4,v 1.7 2000/01/06 06:00:30 itojun Exp $
 .\" $FreeBSD$
 .\"
 .Dd March 13, 2000
@@ -241,14 +242,14 @@ int range = IPV6_PORTRANGE_LOW;       /* see <netinet/in.h> */
 setsockopt(s, IPPROTO_IPV6, IPV6_PORTRANGE, &range, sizeof(range));
 .Ed
 .Pp
-.Dv IPV6_BINDV6ONLY
+.Dv IPV6_V6ONLY
 controls behavior of
 .Dv AF_INET6
 wildcard listening socket.
 The following example sets the option to 1:
 .Bd -literal -offset indent
 int on = 1;
-setsockopt(s, IPPROTO_IPV6, IPV6_BINDV6ONLY, &on, sizeof(on));
+setsockopt(s, IPPROTO_IPV6, IPV6_V6ONLY, &on, sizeof(on));
 .Ed
 .Pp
 If set to 1,
@@ -258,21 +259,20 @@ If set to 0, it will accept IPv4 traffic as well,
 as if it was from IPv4 mapped address like
 .Li ::ffff:10.1.1.1 .
 .\" RFC2553 defines the behavior when the variable is set to 0.
-Note that if you set this to 0,
-you need to care IPv4 access control also on the AF_INET6 socket.
+Note that if you set it this to 0,
+IPv4 access control gets much more complicated.
 For example, even if you have no listening
 .Dv AF_INET
 listening socket on port
 .Li X ,
-you will be accepting IPv4 traffic by
+you will end up accepting IPv4 traffic by
 .Dv AF_INET6
 listening socket on the same port.
-.\"(net.inet6.ip6.bindv6only is not implemented yet.)
-.\"The default value for this flag is copied at socket instantiation time,
-.\"from
-.\".Li net.inet6.ip6.bindv6only
-.\".Xr sysctl 3
-.\"variable.
+The default value for this flag is copied at socket instantiation time,
+from
+.Li net.inet6.ip6.v6only
+.Xr sysctl 3
+variable.
 The option affects
 .Tn TCP
 and
@@ -344,7 +344,7 @@ and
 .Dv IPV6_DSTOPTS .
 Similarly,
 .Xr inet6_rthdr_space 3
-and friends will help you parse ancillary data items for 
+and friends will help you parse ancillary data items for
 .Dv IPV6_RTHDR .
 .Pp
 .Dv IPV6_HOPOPTS
@@ -686,12 +686,14 @@ The ancillary data items were improperly formed, or option name was unknown.
 .Sh STANDARDS
 Most of the socket options are defined in
 RFC2292 and/or RFC2553.
-.Dv IPV6_PORTRANGE ,
-.Dv IPV6_BINDV6ONLY
+.Pp
+.Dv IPV6_V6ONLY
+socket option is defined in draft-ietf-ipngwg-rfc2553bis-03.
+.Dv IPV6_PORTRANGE
+socket option
 and
 conflict resolution rule
 are not defined in the RFCs and should be considered implementation dependent.
-However, KAME/NetBSD also supports them.
 .\"
 .Sh HISTORY
 The implementation is based on KAME stack
diff --git a/share/man/man4/ipsec.4 b/share/man/man4/ipsec.4
index f5a81df..d9502e6 100644
--- a/share/man/man4/ipsec.4
+++ b/share/man/man4/ipsec.4
@@ -1,5 +1,5 @@
 .\"	$FreeBSD$
-.\"	$KAME: ipsec.4,v 1.13 2000/06/15 04:08:54 itojun Exp $
+.\"	$KAME: ipsec.4,v 1.15 2001/04/05 01:00:45 itojun Exp $
 .\"
 .\" Copyright (C) 1995, 1996, 1997, and 1998 WIDE Project.
 .\" All rights reserved.
@@ -213,7 +213,7 @@ The variable configures the kernel behavior on IPv4 IPsec tunnel encapsulation.
 If set to 0, DF bit on the outer IPv4 header will be cleared.
 1 means that the outer DF bit is set regardless from the inner DF bit.
 2 means that the DF bit is copied from the inner header to the outer.
-The variable is supplied to conform to RFC2403 chapter 6.1.
+The variable is supplied to conform to RFC2401 chapter 6.1.
 .It Li ipsec.ecn
 If set to non-zero, IPv4 IPsec tunnel encapsulation/decapsulation behavior will
 be friendly to ECN
diff --git a/share/man/man4/kame.4 b/share/man/man4/kame.4
index fa68201..5493779 100644
--- a/share/man/man4/kame.4
+++ b/share/man/man4/kame.4
@@ -148,6 +148,11 @@ You also can check out the IPv6 and IPsec chapters in the
 handbook.
 Also check latest status of project at web page:
 .Pa http://www.kame.net/ .
+.Po
+Hope you can see a
+.Dq Dancing Turtle
+.Li :-)
+.Pc
 .\"
 .Ss APIs introduced or modified
 .Xr if_indextoname 3 ,
diff --git a/share/man/man4/stf.4 b/share/man/man4/stf.4
index fdac049..c5f05e3 100644
--- a/share/man/man4/stf.4
+++ b/share/man/man4/stf.4
@@ -1,5 +1,5 @@
 .\"	$FreeBSD$
-.\"     $KAME: stf.4,v 1.24 2000/06/07 23:35:18 itojun Exp $
+.\"     $KAME: stf.4,v 1.35 2001/05/02 06:24:49 itojun Exp $
 .\"
 .\" Copyright (C) 1995, 1996, 1997, and 1998 WIDE Project.
 .\" All rights reserved.
@@ -28,7 +28,7 @@
 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 .\" SUCH DAMAGE.
 .\"
-.Dd March 6, 2000
+.Dd April 27, 2001
 .Dt STF 4
 .Os
 .Sh NAME
@@ -45,7 +45,7 @@ interface supports
 .Dq 6to4
 IPv6 in IPv4 encapsulation.
 It can tunnel IPv6 traffic over IPv4, as specified in
-.Li draft-ietf-ngtrans-6to4-06.txt .
+.Li RFC3056 .
 .Pp
 For ordinary nodes in 6to4 site, you do not need
 .Nm
@@ -142,6 +142,9 @@ all of the directly connected subnets.
 .It
 Packets that does not pass ingress filtering.
 Outer IPv4 source address must meet the IPv4 topology on the routing table.
+Ingress filter can be turned off by
+.Dv IFF_LINK2
+bit.
 .It
 The same set of rules are appplied against the IPv4 address embedded into
 inner IPv6 address, if the IPv6 address matches 6to4 prefix.
@@ -152,6 +155,16 @@ incoming IPv4 packet with IP protocol number 41, as necessary.
 It is also recommended to filter/audit encapsulated IPv6 packets as well.
 You may also want to run normal ingress filter against inner IPv6 address
 to avoid spoofing.
+.Pp
+By setting the
+.Dv IFF_LINK0
+flag on the
+.Nm
+interface, it is possible to disable the input path,
+making the direct attacks from the outside impossible.
+Note, however, there are other security risks exist.
+If you wish to use the configuration,
+you must not advertise your 6to4 address to others.
 .\"
 .Sh EXAMPLES
 Note that
@@ -175,28 +188,65 @@ It emits 6to4 packet only for IPv6 destination 2002:0901::/32
 # ifconfig stf0 inet6 2002:0901:0203:0000:a00:5aff:fe38:6f86 \\
 	prefixlen 32 alias
 .Ed
+.Pp
+The following configuration uses the
+.Nm
+interface as an output-only device.
+You need to have alternative IPv6 connectivity
+.Pq other than 6to4
+to use this configuration.
+For outbound traffic, you can reach other 6to4 networks efficiently via
+.Nm stf .
+For inbound traffic, you will not receive any 6to4-tunneled packets
+.Pq less security drawbacks .
+Be careful not to advertise your 6to4 prefix to others
+.Pq Li 2002:8504:0506::/48 ,
+and not to use your 6to4 prefix as a source.
+.Bd -literal
+# ifconfig ne0 inet 133.4.5.6 netmask 0xffffff00
+# ifconfig stf0 inet6 2002:8504:0506:0000:a00:5aff:fe38:6f86 \\
+	prefixlen 16 alias deprecated link0
+# route add -inet6 2002:: -prefixlen 16 ::1
+# route change -inet6 2002:: -prefixlen 16 ::1 -ifp stf0
+.Ed
 .\"
 .Sh SEE ALSO
 .Xr gif 4 ,
 .Xr inet 4 ,
 .Xr inet6 4
+.Pp
+.Pa http://www.6bone.net/6bone_6to4.html
 .Rs
 .%A Brian Carpenter
 .%A Keith Moore
-.%T "Connection of IPv6 Domains via IPv4 Clouds without Explicit Tunnels"
-.%D June 2000
-.%N draft-ietf-ngtrans-6to4-06.txt
-.%O work in progress
+.%T "Connection of IPv6 Domains via IPv4 Clouds"
+.%D February 2001
+.%R RFC
+.%N 3056
 .Re
 .Rs
 .%A Jun-ichiro itojun Hagino
 .%T "Possible abuse against IPv6 transition technologies"
-.%D March 2000
-.%N draft-itojun-ipv6-transition-abuse-00.txt
-.%O work in progress, http://playground.iijlab.net/i-d/draft-itojun-ipv6-transition-abuse-00.txt
+.%D July 2000
+.%N draft-itojun-ipv6-transition-abuse-01.txt
+.%O work in progress
 .Re
 .\"
 .Sh HISTORY
 The
 .Nm
 device first appeared in WIDE/KAME IPv6 stack.
+.\"
+.Sh BUGS
+No more than one
+.Nm
+interface is allowed for a node,
+and no more than one IPv6 interface address is allowed for an
+.Nm
+interface.
+It is to avoid source address selection conflicts
+between IPv6 layer and IPv4 layer,
+and to cope with ingress filtering rule on the other side.
+This is a feature to make
+.Nm
+work right for all occasions.