summaryrefslogtreecommitdiffstats
path: root/share
diff options
context:
space:
mode:
authorume <ume@FreeBSD.org>2001-06-11 12:39:29 +0000
committerume <ume@FreeBSD.org>2001-06-11 12:39:29 +0000
commit832f8d224926758a9ae0b23a6b45353e44fbc87a (patch)
treea79fc7ad2b97862c4a404f352f0211ad93a7b5f1 /share
parent2693854b01a52b0395a91322aa3edf926bddff38 (diff)
downloadFreeBSD-src-832f8d224926758a9ae0b23a6b45353e44fbc87a.zip
FreeBSD-src-832f8d224926758a9ae0b23a6b45353e44fbc87a.tar.gz
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
Diffstat (limited to 'share')
-rw-r--r--share/doc/IPv6/IMPLEMENTATION659
-rw-r--r--share/examples/IPv6/USAGE526
-rw-r--r--share/man/man4/faith.475
-rw-r--r--share/man/man4/gif.4120
-rw-r--r--share/man/man4/inet6.491
-rw-r--r--share/man/man4/ip6.438
-rw-r--r--share/man/man4/ipsec.44
-rw-r--r--share/man/man4/kame.45
-rw-r--r--share/man/man4/stf.470
9 files changed, 890 insertions, 698 deletions
diff --git a/share/doc/IPv6/IMPLEMENTATION b/share/doc/IPv6/IMPLEMENTATION
index 98150d5..ea1715f 100644
--- a/share/doc/IPv6/IMPLEMENTATION
+++ b/share/doc/IPv6/IMPLEMENTATION
@@ -2,11 +2,12 @@
# Some portion of this document is not applicable to the code merged into
# FreeBSD-current (for example, section 5).
- Implementation Note
+ Implementation Note
- KAME Project
- http://www.kame.net/
- $FreeBSD$
+ KAME Project
+ http://www.kame.net/
+ $KAME: IMPLEMENTATION,v 1.216 2001/05/25 07:43:01 jinmei Exp $
+ $FreeBSD$
1. IPv6
@@ -27,12 +28,7 @@ RFC1639: FTP Operation Over Big Address Records (FOOBAR)
* 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
- * IPv4 compatible address is not supported.
- * automatic tunneling (4.3) is not supported.
- * "gif" interface implements IPv[46]-over-IPv[46] tunnel in a generic way,
- and it covers "configured tunnel" described in the spec.
- See 1.5 in this document for details.
+RFC1933: (see RFC2893)
RFC1981: Path MTU Discovery for IPv6
RFC2080: RIPng for IPv6
* KAME-supplied route6d, bgpd and hroute6d support this.
@@ -42,8 +38,7 @@ RFC2283: Multiprotocol Extensions for BGP-4
RFC2292: Advanced Sockets API for IPv6
* For supported library functions/kernel APIs, see sys/netinet6/ADVAPI.
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.
+ * RFC2362 defines the packet formats and the protcol of PIM-SM.
RFC2373: IPv6 Addressing Architecture
* KAME supports node required addresses, and conforms to the scope
requirement.
@@ -82,6 +77,13 @@ RFC2553: Basic Socket Interface Extensions for IPv6
- supported but turned off by default on KAME/NetBSD,
- not supported on KAME/FreeBSD228, KAME/OpenBSD and KAME/BSDI3.
see 1.12 in this document for details.
+RFC2671: Extension Mechanisms for DNS (EDNS0)
+ * see USAGE for how to use it.
+ * not supported on kame/freebsd4 and kame/bsdi4.
+RFC2673: Binary Labels in the Domain Name System
+ * KAME/bsdi4 supports A6, DNAME and binary label to some extent.
+ * KAME apps/bind8 repository has resolver library with partial A6, DNAME
+ and binary label support.
RFC2675: IPv6 Jumbograms
* See 1.7 in this document for details.
RFC2710: Multicast Listener Discovery for IPv6
@@ -89,35 +91,74 @@ RFC2711: IPv6 router alert option
RFC2732: Format for Literal IPv6 Addresses in URL's
* The spec is implemented in programs that handle URLs
(like freebsd ftpio(3) and fetch(1), or netbsd ftp(1))
-draft-ietf-ipngwg-router-renum-10: Router renumbering for IPv6
-draft-ietf-ipngwg-icmp-name-lookups-05: IPv6 Name Lookups Through ICMP
-draft-ietf-pim-ipv6-03.txt: PIM for IPv6
- * pim6dd implements dense mode. pim6sd implements sparse mode.
+RFC2766: Network Address Translation - Protocol Translation (NAT-PT)
+ * Section 4.2 is implemented by totd (see ports/totd, or pkgsrc/net/totd).
+RFC2874: DNS Extensions to Support IPv6 Address Aggregation and Renumbering
+ * KAME/bsdi4 supports A6, DNAME and binary label to some extent.
+ * KAME apps/bind8 repository has resolver library with partial A6, DNAME
+ and binary label support.
+RFC2893: Transition Mechanisms for IPv6 Hosts and Routers
+ * IPv4 compatible address is not supported.
+ * automatic tunneling (4.3) is not supported.
+ * "gif" interface implements IPv[46]-over-IPv[46] tunnel in a generic way,
+ and it covers "configured tunnel" described in the spec.
+ See 1.5 in this document for details.
+RFC2894: Router renumbering for IPv6
+RFC3041: Privacy Extensions for Stateless Address Autoconfiguration in IPv6
+RFC3056: Connection of IPv6 Domains via IPv4 Clouds
+ * So-called "6to4".
+ * "stf" interface implements it. Be sure to read
+ draft-itojun-ipv6-transition-abuse-01.txt
+ below before configuring it, there can be security issues.
+draft-ietf-ipngwg-icmp-name-lookups-07: IPv6 Name Lookups Through ICMP
draft-ietf-dhc-dhcpv6-15.txt: DHCPv6
draft-ietf-dhc-dhcpv6exts-12.txt: Extensions for DHCPv6
* kame/dhcp6 has test implementation, which will not be compiled in
default compilation.
+ * 15/12 drafts are not explicit about padding and string termination.
+ at IETF48, the author confirmed that there's no padding/termination
+ (and extensions can appear unaligned). our code follows the comment.
draft-itojun-ipv6-tcp-to-anycast-00.txt:
Disconnecting TCP connection toward IPv6 anycast address
-draft-ietf-ipngwg-scopedaddr-format-02.txt:
- An Extension of Format for IPv6 Scoped Addresses
-draft-ietf-ngtrans-tcpudp-relay-01.txt:
+draft-ietf-ipngwg-rfc2553bis-03.txt:
+ Basic Socket Interface Extensions for IPv6 (revised)
+draft-ietf-ipngwg-rfc2292bis-02.txt:
+ Advanced Sockets API for IPv6 (revised)
+ * Some of the updates in the draft are not implemented yet. See
+ TODO.2292bis for more details.
+draft-ietf-mobileip-ipv6-13.txt: Mobility Support in IPv6
+ * See section 6.
+draft-ietf-ngtrans-tcpudp-relay-04.txt:
An IPv6-to-IPv4 transport relay translator
* FAITH tcp relay translator (faithd) implements this. See 3.1 for more
details.
-draft-ietf-ngtrans-6to4-06.txt:
- Connection of IPv6 Domains via IPv4 Clouds without Explicit Tunnels
- * "stf" interface implements it. Be sure to read the next item before
- configuring it, there are security issues.
-http://playground.iijlab.net/i-d/draft-itojun-ipv6-transition-abuse-00.txt:
- Possible abuse against IPv6 transition technologies
- * KAME does not implement RFC1933 automatic tunnel.
+draft-ietf-ipngwg-router-selection-01.txt:
+ Default Router Preferences and More-Specific Routes
+ * router-side only.
+draft-ietf-ipngwg-scoping-arch-02.txt:
+ The architecture, text representation, and usage of IPv6
+ scoped addresses.
+ * some part of the documentation (especially about the routing
+ model) is not supported yet.
+draft-ietf-pim-sm-v2-new-02.txt
+ A revised version of RFC2362, which includes the IPv6 specific
+ packet format and protocol descriptions.
+draft-ietf-dnsext-mdns-00.txt: Multicast DNS
+ * kame/mdnsd has test implementation, which will not be built in
+ default compilation. The draft will experience a major change in the
+ near future, so don't rely upon it.
+draft-itojun-ipv6-transition-abuse-02.txt:
+ Possible abuse against IPv6 transition technologies (expired)
+ * KAME does not implement RFC1933/2893 automatic tunnel.
* "stf" interface implements some address filters. Refer to stf(4)
for details. Since there's no way to make 6to4 interface 100% secure,
we do not include "stf" interface into GENERIC.v6 compilation.
* kame/openbsd completely disables IPv4 mapped address support.
* kame/netbsd makes IPv4 mapped address support off by default.
- * See section 12.6 and 14 for more details.
+ * See section 1.12.6 and 1.14 for more details.
+draft-itojun-ipv6-tclass-api-02.txt: Socket API for IPv6 traffic class field
+draft-itojun-ipv6-flowlabel-api-01.txt: Socket API for IPv6 flow label field
+ * no consideration is made against the use of routing headers and such.
1.2 Neighbor Discovery
@@ -145,7 +186,10 @@ Some of network drivers loop multicast packets back to themselves,
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
+In this case, drivers should be corrected to honor IFF_SIMPLEX behavior.
+For example, you may need to check source MAC address on a inbound packet,
+and reject it if it is from the node itself.
+You may also 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).
@@ -218,84 +262,157 @@ upper-layer hints to be accepted.
non-root process - after local discussion, it looks that hints are not
that trustworthy even if they are from privileged processes)
-1.3 Scope Index
+If inbound ND packets carry invalid values, the KAME kernel will
+drop these packet and increment statistics variable. See
+"netstat -sn", icmp6 section. For detailed debugging session, you can
+turn on syslog output from the kernel on errors, by turning on sysctl MIB
+net.inet6.icmp6.nd6_debug. nd6_debug can be turned on at bootstrap
+time, by defining ND6_DEBUG kernel compilation option (so you can
+debug behavior during bootstrap). nd6_debug configuration should
+only be used for test/debug purposes - for production environment,
+nd6_debug must be set to 0. If you leave it to 1, malicious parties
+can inject broken packet and fill up /var/log partition.
+
+1.3 Scope Zone Index
IPv6 uses scoped addresses. It is therefore 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, a scoped IPv6 address is ambiguous to the kernel, and
-the kernel will not be able to determine the outbound interface for a
-packet. KAME code tries to address the issue in several ways.
-
-Site-local address is very vaguely defined in the specs, and both specification
-and KAME code need tons of improvements to enable its actual use.
-For example, it is still very unclear how we define a site, or how we resolve
-hostnames in a site. There are work underway to define behavior of routers
-at site border, however, we have almost no code for site boundary node support
-(both forwarding nor routing) and we bet almost noone has.
-We recommend, at this moment, you to use global addresses for experiments -
-there are way too many pitfalls if you use site-local addresses.
+specify the scope zone index (link index for a link-local address, or
+site index for a site-local address) with an IPv6 address. Without a
+zone index, a scoped IPv6 address is ambiguous to the kernel, and
+the kernel would not be able to determine the outbound link for a
+packet to the scoped address. KAME code tries to address the issue in
+several ways.
+
+The entire architecture of scoped addresses is documented in
+draft-ietf-ipngwg-scoping-arch-xx.txt. One non-trivial point of the
+architecture is that the link scope is (theoretically) larger than the
+interface scope. That is, two different interfaces can belong to a
+same single link. However, in a normal operation, we can assume that
+there is 1-to-1 relationship between links and interfaces. In
+other words, we can usually put links and interfaces in the same scope
+type. The current KAME implementation assumes the 1-to-1
+relationship. In particular, we use interface names such as "ne1" as
+unique link identifiers. This would be much more human-readable and
+intuitive than numeric identifiers, but please keep your mind on the
+theoretical difference between links and interfaces.
+
+Site-local addresses are very vaguely defined in the specs, and both
+the specification and the KAME code need tons of improvements to
+enable its actual use. For example, it is still very unclear how we
+define a site, or how we resolve host names in a site. There is work
+underway to define behavior of routers at site border, but, we have
+almost no code for site boundary node support (both forwarding nor
+routing) and we bet almost noone has. We recommend, at this moment,
+you to use global addresses for experiments - there are way too many
+pitfalls if you use site-local addresses.
1.3.1 Kernel internal
-In the kernel, the interface index for a link-local scope address is
+In the kernel, the link index for a link-local scope address is
embedded into the 2nd 16bit-word (the 3rd and 4th bytes) in the 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
+in the routing table and the interface address structure (struct
+in6_ifaddr). The address above is a link-local unicast address which
+belongs to a network link whose link identifier is 1 (note that it
+eqauls to the interface index by the assumption of our
+implementation). The embedded index enables us to identify IPv6
+link-local addresses over multiple links effectively and with only a
little code change.
1.3.2 Interaction with API
-Ordinary userland applications should use the advanced API (RFC2292)
-to specify scope index, or interface index. For the similar purpose,
-the sin6_scope_id member in the 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 the advanced API rather than sin6_scope_id.
-
-Routing daemons and configuration programs, like route6d and
-ifconfig, 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.
-
-getaddrinfo(3) and getnameinfo(3) are modified to support extended numeric
-IPv6 syntax, as documented in draft-ietf-ipngwg-scopedaddr-format-xx.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'll need to use getaddrinfo(3),
-and getnameinfo(3) with NI_WITHSCOPEID.
-The implementation currently assumes 1-to-1 relationship between a link and an
-interface, which is stronger than what IPv6 specs say.
-Other APIs like inet_pton(3) or getipnodebyname(3) are inherently unfriendly
-with scoped addresses, since they are unable to annotate addresses with
-scope identifier.
+There are several candidates of API to deal with scoped addresses
+without ambiguity.
+
+The IPV6_PKTINFO ancillary data type or socket option defined in the
+advanced API (RFC2292 or draft-ietf-ipngwg-rfc2292bis-xx) can specify
+the outgoing interface of a packet. Similarly, the IPV6_PKTINFO or
+IPV6_RECVPKTINFO socket options tell kernel to pass the incoming
+interface to user applications.
+
+These options are enough to disambiguate scoped addresses of an
+incoming packet, because we can uniquely identify the corresponding
+zone of the scoped address(es) by the incoming interface. However,
+they are too strong for outgoing packets. For example, consider a
+multi-sited node and suppose that more than one interface of the node
+belongs to a same site. When we want to send a packet to the site,
+we can only specify one of the interfaces for the outgoing packet with
+these options; we cannot just say "send the packet to (one of the
+interfaces of) the site."
+
+Another kind of candidates is to use the sin6_scope_id member in the
+sockaddr_in6 structure, defined in RFC2553 and
+draft-ietf-ipngwg-rfc2553bis-xx.txt. The KAME kernel interprets the
+sin6_scope_id field properly in order to disambiguate scoped
+addresses. For example, if an application passes a sockaddr_in6
+structure that has a non-zero sin6_scope_id value to the sendto(2)
+system call, the kernel should send the packet to the appropriate zone
+according to the sin6_scope_id field. Similarly, when the source or
+the destination address of an incoming packet is a scoped one, the
+kernel should detect the correct zone identifier based on the address
+and the receiving interface, fill the identifier in the sin6_scope_id
+field of a sockaddr_in6 structure, and then pass the packet to an
+application via the recvfrom(2) system call, etc.
+
+However, the semantics of the sin6_scope_id is still vague and on the
+way to standardization. Additionally, not so many operating systems
+support the behavior above at this moment.
+
+In summary,
+- If your target system is limited to KAME based ones (i.e. BSD
+ variants and KAME snaps), use the sin6_scope_id field assuming the
+ kernel behavior described above.
+- Otherwise, (i.e. if your program should be portable on other systems
+ than BSDs)
+ + Use the advanced API to disambiguate scoped addresses of incoming
+ packets.
+ + To disambiguate scoped addresses of outgoing packets,
+ * if it is okay to just specify the outgoing interface, use the
+ advanced API. This would be the case, for example, when you
+ should only consider link-local addresses and your system
+ assumes 1-to-1 relationship between links and interfaces.
+ * otherwise, sorry but you lose. Please rush the IETF IPv6
+ community into standardizing the semantics of the sin6_scope_id
+ field.
+
+Routing daemons and configuration programs, like route6d and ifconfig,
+will need to manipulate the "embedded" zone index. These programs use
+routing sockets and ioctls (like SIOCGIFADDR_IN6) and the kernel API
+will return IPv6 addresses with the 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.
+
+getaddrinfo(3) and getnameinfo(3) support an extended numeric IPv6
+syntax, as documented in draft-ietf-ipngwg-rfc2553bis-xx.txt. You can
+specify the outgoing link, by using the name of the outgoing interface
+as the link, like "fe80::1%ne0" (again, note that we assume there is
+1-to-1 relationship between links and interfaces.) This way you will
+be able to specify a link-local scoped address without much trouble.
+
+Other APIs like inet_pton(3) and inet_ntop(3) are inherently
+unfriendly with scoped addresses, since they are unable to annotate
+addresses with zone identifier.
1.3.3 Interaction with users (command line)
-Most of user applications now support an extended numeric IPv6 syntax,
-as documented in draft-ietf-ipngwg-scopedaddr-format-xx.txt. In this
-case, you can specify outgoing link, by using the name of the outgoing
-interface like "fe80::1%ne0". This is the case for some management
-tools such as route(8) or ndp(8). For example, to install the IPv6
-default route by hand, you can type like
+Most of user applications now support the extended numeric IPv6
+syntax. In this case, you can specify outgoing link, by using the name
+of the outgoing interface like "fe80::1%ne0" (sorry for the duplicated
+notice, but please recall again that we assume 1-to-1 relationship
+between links and interfaces). This is even the case for some
+management tools such as route(8) or ndp(8). For example, to install
+the IPv6 default route by hand, you can type like
# route add -inet6 default fe80::9876:5432:1234:abcd%ne0
(Although we suggest you to run dynamic routing instead of static
routes, in order to avoid configuration mistakes.)
Some applications have command line options for specifying an
appropriate zone of a scoped address (like "ping6 -I ne0 ff02::1" to
-specify the outgoing interface). However, you can't always expect such
-options. Thus, we recommend you to use the extended format described
+specify the outgoing interface). However, you can't always expect such
+options. Thus, we recommend you to use the extended format described
above.
In any case, when you specify a scoped address to the command line,
@@ -401,12 +518,6 @@ To summarize the sysctl knob:
1 1 invalid, or experimental
(out-of-scope of spec)
-RFC2462 has validation rules 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 KAME implements Jim's update.
-
See 1.2 in the document for relationship between DAD and autoconfiguration.
1.4.3 DHCPv6
@@ -450,22 +561,25 @@ automatically assigned to the gif interface.
KAME's source address selection takes care of the following
conditions:
- address scope
-- prefix matching against the destination
- outgoing interface
- whether an address is deprecated
+- whether an address is temporary (in terms of RFC 3041)
+- prefix matching against the destination
Roughly speaking, the selection policy is as follows:
- always use an address that belongs to the same scope zone as the
destination.
- addresses that have equal or larger scope than the scope of the
destination are preferred.
-- if multiple addresses have the equal scope, one which is longest
- prefix matching against the destination is preferred.
- a deprecated address is not used in new communications if an
alternate (non-deprecated) address is available and has sufficient
scope.
+- a temporary address (in terms of RFC 3041 privacy extension) are
+ preferred to a public address.
- if none of above conditions tie-breaks, addresses assigned on the
outgoing interface are preferred.
+- if none of above conditions tie-breaks, one which is longest prefix
+ matching against the destination is preferred as the last resort.
For instance, ::1 is selected for ff01::1,
fe80::200:f8ff:fe01:6317%ne0 for fe80::2a0:24ff:feab:839b%ne0.
@@ -484,47 +598,68 @@ The precise desripction of the algorithm is quite complicated. To
describe the algorithm, we introduce the following notation:
For a given destination D,
- samescope(D): A set of addresses that have the same scope as D.
- largerscope(D): A set of addresses that have a larger scope than D.
- smallerscope(D): A set of addresses that have a smaller scope than D.
+ samescope(D): The set of addresses that have the same scope as D.
+ largerscope(D): The set of addresses that have a larger scope than D.
+ smallerscope(D): The set of addresses that have a smaller scope than D.
For a given set of addresses A,
- DEP(A): a set of deprecated addresses in A.
+ DEP(A): the set of deprecated addresses in A.
nonDEP(A): A - DEP(A).
+For a given set of addresses A,
+ tmp(A): the set of preferred temporary-autoconfigured or
+ manually-configure addresses in A.
+
Also, the algorithm assumes that the outgoing interface for the
destination D is determined. We call the interface "I".
The algorithm is as follows. Selection proceeds step by step as
-described; For example, if an address is selected by item 1, item 2 or
+described; For example, if an address is selected by item 1, item 2 and
later are not considered at all.
0. If there is no address in the same scope zone as D, just give up;
the packet will not be sent.
- 1. If nonDEP(samescope(D)) is not empty,
- choose a longest matching address against D. If more than one
- address is longest matching, choose arbitrary one provided that
- an address on I is always preferred.
- 2. If nonDEP(largerscope(D)) is not empty,
- choose an address that has the smallest scope. If more than one
- address has the smallest scope, choose arbitrary one provided
+ 1. If we do not prefer temporary addresses, go to 3.
+ Otherwise, and if tmp(samescope(D)) is not empty,
+ then choose an address that is on the interface I. If every
+ address is on I, or every address is on a different interface
+ from I, choose an arbitrary one provided that an address longest
+ matching against D is always preferred.
+ 2. If tmp(largerscope(D)) is not empty,
+ then choose an address that has the smallest scope. If more than one
+ address has the smallest scope, choose an arbitrary one provided
+ that addresses on I are always preferred.
+ 3. If nonDEP(samescope(D)) is not empty,
+ then apply the same logic as of 1.
+ 4. If nonDEP(largerscope(D)) is not empty,
+ then apply the same logic as of 2.
+ 5. If we do not prefer temporary addresses, go to 7.
+ Otherwise, and if tmp(DEP(samescope(D))) is not empty,
+ then choose an address that is on the interface I. If every
+ address is on I, or every address is on a different interface
+ from I, choose an arbitrary one provided that an address longest
+ matching against D is always preferred.
+ 6. If tmp(DEP(largerscope(D))) is not empty,
+ then choose an address that has the smallest scope. If more than
+ one address has the smallest scope, choose an arbitrary one provided
that an address on I is always preferred.
- 3. If DEP(samescope(D)) is not empty,
- choose a longest matching address against D. If more than one
- address is longest matching, choose arbitrary one provided that
- an address on I is always preferred.
- 4. If DEP(largerscope(D)) is not empty,
- choose an address that has the smallest scope. If more than one
- address has the smallest scope, choose arbitrary one provided
+ 7. If DEP(samescope(D)) is not empty,
+ then apply the same logic as of 5.
+ 8. If DEP(largerscope(D)) is not empty,
+ then apply the same logic as of 6.
+ 9. If we do not prefer temporary addresses, go to 11.
+ Otherwise, and if tmp(nonDEP(smallerscope(D))) is not empty,
+ then choose an address that has the largest scope. If more than
+ one address has the largest scope, choose an arbitrary one provided
that an address on I is always preferred.
- 5. if nonDEP(smallerscope(D)) is not empty,
- choose an address that has the largest scope. If more than one
- address has the largest scope, choose arbitrary one provided
- that an address on I is always preferred.
- 6. if DEP(smallerscope(D)) is not empty,
- choose an address that has the largest scope. If more than one
- address has the largest scope, choose arbitrary one provided
+ 10. If tmp(DEP(smallerscope(D))) is not empty,
+ then choose an address that has the largest scope. If more than
+ one address has the largest scope, choose an arbitrary one provided
that an address on I is always preferred.
+ 11. If nonDEP(smallerscope(D)) is not empty,
+ then apply the same logic as of 9.
+ 12. If DEP(smallerscope(D)) is not empty,
+ then apply the same logic as of 10.
There exists a document about source address selection
(draft-ietf-ipngwg-default-addr-select-xx.txt). KAME's algorithm
@@ -622,6 +757,15 @@ overflow due to long function call chain. KAME sys/netinet6 code
is carefully designed to avoid kernel stack overflow. Because of
this, KAME sys/netinet6 code defines its own protocol switch
structure, as "struct ip6protosw" (see netinet6/ip6protosw.h).
+
+In addition to this, we restrict the number of extension headers
+(including the IPv6 header) in each incoming packet, in order to
+prevent a DoS attack that tries to send packets with a massive number
+of extension headers. The upper limit can be configured by the sysctl
+value net.inet6.ip6.hdrnestlimit. In particular, if the value is 0,
+the node will allow an arbitrary number of headers. As of writing this
+document, the default value is 50.
+
IPv4 part (sys/netinet) remains untouched for compatibility.
Because of this, if you receive IPsec-over-IPv4 packet with massive
number of IPsec headers, kernel stack may blow up. IPsec-over-IPv6 is okay.
@@ -823,6 +967,9 @@ and initiating side). AF_INET6 and AF_INET sockets are totally separated.
Port number space is totally separate between AF_INET and AF_INET6 sockets.
+It should be noted that KAME/BSDI3 and KAME/FreeBSD228 are not conformant
+to RFC2553 section 3.7 and 3.8. It is due to code sharing reasons.
+
1.12.2 KAME/FreeBSD[34]x
KAME/FreeBSD3x and KAME/FreeBSD4x use shared tcp4/6 code (from
@@ -840,7 +987,7 @@ Wildcard AF_INET6 socket grabs IPv4 connection if and only if the following
conditions are satisfied:
- there's no AF_INET socket that matches the IPv4 connection
- the AF_INET6 socket is configured to accept IPv4 traffic, i.e.
- getsockopt(IPV6_BINDV6ONLY) returns 0.
+ getsockopt(IPV6_V6ONLY) returns 0.
(XXX need checking)
@@ -859,15 +1006,19 @@ udp4/6 code (from sys/netinet/udp*). The implementation is made differently
from KAME/FreeBSD[34]x. KAME/NetBSD uses separate inpcb/in6pcb structures,
while KAME/FreeBSD[34]x uses merged inpcb structure.
+It should be noted that the default configuration of KAME/NetBSD is not
+conformant to RFC2553 section 3.8. It is intentionally turned off by default
+for security reasons.
+
1.12.3.1 KAME/NetBSD, listening side
The platform can be configured to support IPv4 mapped address/special AF_INET6
wildcard bind (disabled by default). Kernel behavior can be summarized as
follows:
- default: special support code will be compiled in, but is disabled by
- default. It can be controlled by sysctl (net.inet6.ip6.bindv6only),
- or setsockopt(IPV6_BINDV6ONLY).
-- add "INET6_BINDV6ONLY": No special support code for AF_INET6 wildcard socket
+ default. It can be controlled by sysctl (net.inet6.ip6.v6only),
+ or setsockopt(IPV6_V6ONLY).
+- add "INET6_V6ONLY": No special support code for AF_INET6 wildcard socket
will be compiled in. AF_INET6 sockets and AF_INET sockets are totally
separate. The behavior is similar to what described in 1.12.1.
@@ -881,7 +1032,7 @@ Wildcard AF_INET6 socket grabs IPv4 connection if and only if the following
conditions are satisfied:
- there's no AF_INET socket that matches the IPv4 connection
- the AF_INET6 socket is configured to accept IPv4 traffic, i.e.
- getsockopt(IPV6_BINDV6ONLY) returns 0.
+ getsockopt(IPV6_V6ONLY) returns 0.
You cannot bind(2) with IPv4 mapped address. This is a workaround for port
number duplicate and other twists.
@@ -919,6 +1070,9 @@ KAME/BSDi4 supports connection initiation to IPv4 mapped address
KAME/OpenBSD uses NRL-based TCP/UDP stack and inpcb source code,
which was derived from NRL IPv6/IPsec stack.
+It should be noted that KAME/OpenBSD is not conformant to RFC2553 section 3.7
+and 3.8. It is intentionally omitted for security reasons.
+
1.12.5.1 KAME/OpenBSD, listening side
KAME/OpenBSD disables special behavior on AF_INET6 wildcard bind for
@@ -955,7 +1109,7 @@ mapped address or not. This adds many twists:
use EPSV/EPRT or LPSV/LPRT; /*IPv6*/
else
error;
- Under SIIT environment, the correct code would be:
+ The correct code, with consideration to IPv4 mapped address, would be:
if (sa_family == AF_INET)
use EPSV/EPRT or PASV/PORT; /*IPv4*/
else if (sa_family == AF_INET6 && IPv4 mapped address)
@@ -970,17 +1124,40 @@ mapped address or not. This adds many twists:
- By enabling kernel support for IPv4 mapped address (outgoing direction),
servers on the kernel can be hosed by IPv6 native packet that has IPv4
mapped address in IPv6 header source, and can generate unwanted IPv4 packets.
- http://playground.iijlab.net/i-d/draft-itojun-ipv6-transition-abuse-00.txt
- talks more about this scenario.
+ draft-itojun-ipv6-transition-abuse-01.txt talks more about this scenario.
Due to the above twists, some of KAME userland programs has restrictions on
the use of IPv4 mapped addresses:
- rshd/rlogind do not accept connections from IPv4 mapped address.
This is to avoid malicious use of IPv4 mapped address in IPv6 native
packet, to bypass source-address based authentication.
-- ftp/ftpd does not support SIIT environment. IPv4 mapped address will be
- decoded in userland, and will be passed to AF_INET sockets
- (SIIT client should pass IPv4 mapped address as is, to AF_INET6 sockets).
+- ftp/ftpd assume that you are on dual stack network. IPv4 mapped address
+ will be decoded in userland, and will be passed to AF_INET sockets
+ (in other words, ftp/ftpd do not support SIIT environment).
+
+1.12.7 Interaction with SIIT translator
+
+SIIT translator is specified in RFC2765. KAME node cannot become a SIIT
+translator box, nor SIIT end node (a node in SIIT cloud).
+
+To become a SIIT translator box, we need to put additional code for that.
+We do not have the code in our tree at this moment.
+
+There are multiple reasons that we are unable to become SIIT end node.
+(1) SIIT translators require end nodes in the SIIT cloud to be IPv6-only.
+Since we are unable to compile INET-less kernel, we are unable to become
+SIIT end node. (2) As presented in 1.12.6, some of our userland code assumes
+dual stack network. (3) KAME stack filters out IPv6 packets with IPv4
+mapped address in the header, to secure non-SIIT case (which is much more
+common). Effectively KAME node will reject any packets via SIIT translator
+box. See section 1.14 for more detail about the last item.
+
+There are documentation issues too - SIIT document requires very strange
+things. For example, SIIT document asks IPv6-only (meaning no IPv4 code)
+node to be able to construct IPv4 IPsec headers. If a node knows how to
+construct IPv4 IPsec headers, that is not an IPv6-only node, it is a dual-stack
+node. The requirements imposed in SIIT document contradict with the other
+part of the document itself.
1.13 sockaddr_storage
@@ -1036,22 +1213,45 @@ or bypass security controls:
IPv4 address (if they are in IPv6 native packet header, they are malicious)
::ffff:0.0.0.0/104 ::ffff:127.0.0.0/104
::ffff:224.0.0.0/100 ::ffff:255.0.0.0/104
-- 6to4 prefix generated from unspecified/multicast/loopback/broadcast/private
- IPv4 address
+- 6to4 (RFC3056) prefix generated from unspecified/multicast/loopback/
+ broadcast/private IPv4 address
2002:0000::/24 2002:7f00::/24 2002:e000::/24
2002:ff00::/24 2002:0a00::/24 2002:ac10::/28
2002:c0a8::/32
-
-Also, since KAME does not support RFC1933 auto tunnels, seeing IPv4 compatible
-is very rare. You should take caution if you see those on the wire.
+- IPv4 compatible address that embeds unspecified/multicast/loopback/broadcast
+ IPv4 address (if they are in IPv6 native packet header, they are malicious).
+ Note that, since KAME doe snot support RFC1933/2893 auto tunnels, KAME nodes
+ are not vulnerable to these packets.
+ ::0.0.0.0/104 ::127.0.0.0/104 ::224.0.0.0/100 ::255.0.0.0/104
+
+Also, since KAME does not support RFC1933/2893 auto tunnels, seeing IPv4
+compatible is very rare. You should take caution if you see those on the wire.
+
+If we see IPv6 packets with IPv4 mapped address (::ffff:0.0.0.0/96) in the
+header in dual-stack environment (not in SIIT environment), they indicate
+that someone is trying to inpersonate IPv4 peer. The packet should be dropped.
+
+IPv6 specifications do not talk very much about IPv6 unspecified address (::)
+in the IPv6 source address field. Clarification is in progress.
+Here are couple of comments:
+- IPv6 unspecified address can be used in IPv6 source address field, if and
+ only if we have no legal source address for the node. The legal situations
+ include, but may not be limited to, (1) MLD while no IPv6 address is assigned
+ to the node and (2) DAD.
+- If IPv6 TCP packet has IPv6 unspecified address, it is an attack attempt.
+ The form can be used as a trigger for TCP DoS attack. KAME code already
+ filters them out.
+- The following examples are seemingly illegal. It seems that there's general
+ consensus among ipngwg for those. (1) mobile-ip6 home address option,
+ (2) offlink packets (so routers should not forward them).
+ KAME implmements (2) already.
KAME code is carefully written to avoid such incidents. More specifically,
KAME kernel will reject packets with certain source/dstination address in IPv6
base header, or IPv6 routing header. Also, KAME default configuration file
is written carefully, to avoid those attacks.
-http://playground.iijlab.net/i-d/draft-itojun-ipv6-transition-abuse-00.txt
-talks about more about this.
+draft-itojun-ipv6-transition-abuse-01.txt talks about more about this.
1.15 Node's required addresses
@@ -1098,6 +1298,38 @@ like ff02::9 for RIPng.
Users can join groups by using appropriate system calls like setsockopt(2).
+1.16 Advanced API
+
+Current KAME kernel implements 2292bis API, documented in
+draft-ietf-ipngwg-rfc2292bis-xx.txt. It also implements RFC2292 API,
+for backward compatibility purposes with *BSD-integrated codebase.
+KAME tree ships with 2292bis headers.
+*BSD-integrated codebase implements either RFC2292, or 2292bis, API.
+see "COVERAGE" document for detailed implementation status.
+
+Here are couple of issues to mention:
+- *BSD-integrated binaries, compiled for RFC2292, will work on KAME kernel.
+ For example, OpenBSD 2.7 /sbin/rtsol will work on KAME/openbsd kernel.
+- KAME binaries, compiled using 2292bis, will not work on *BSD-integrated
+ kenrel. For example, KAME /usr/local/v6/sbin/rtsol will not work on
+ OpenBSD 2.7 kernel.
+- 2292bis API is not compatible with RFC2292 API. 2292bis #define symbols
+ conflict with RFC2292 symbols. Therefore, if you compile programs that
+ assume RFC2292 API, the compilation itself goes fine, however, the compiled
+ binary will not work correctly. The problem is not KAME issue, but API
+ issue. For example, Solaris 8 implements 2292bis API. If you compile
+ RFC2292-based code on Solaris 8, the binary can behave strange.
+
+There are few (or couple of) incompatible behavior in RFC2292 binary backward
+compatibility support in KAME tree. To enumerate:
+- Type 0 routing header lacks support for strict/loose bitmap.
+ Even if we see packets with "strict" bit set, those bits will not be made
+ visible to the userland.
+ Background: RFC2292 document is based on RFC1883 IPv6, and it uses
+ strict/loose bitmap. 2292bis document is based on RFC2460 IPv6, and it has
+ no strict/loose bitmap (it was removed from RFC2460). KAME tree obeys
+ RFC2460 IPv6, and lacks support for strict/loose bitmap.
+
2. Network Drivers
KAME requires three items to be added into the standard drivers:
@@ -1228,7 +1460,16 @@ Here is a list of FreeBSD 3.x-RELEASE drivers and its conditions:
More drivers will just simply work on KAME FreeBSD 3.x-RELEASE but have not
been checked yet.
-2.5 OpenBSD 2.x
+2.5 FreeBSD 4.x-RELEASE
+
+Here is a list of FreeBSD 4.x-RELEASE drivers and its conditions:
+
+ driver multicast
+ --- ---
+ (Ethernet)
+ lnc/vmware ok
+
+2.6 OpenBSD 2.x
Here is a list of OpenBSD 2.x drivers and its conditions:
@@ -1246,7 +1487,7 @@ Here is a list of OpenBSD 2.x drivers and its conditions:
configuration. This happens with certain revision of chipset on the card.
Should be fixed by now by workaround in sys/net/if.c, but still not sure.
-2.6 BSD/OS 4.x
+2.7 BSD/OS 4.x
The following lists BSD/OS 4.x device drivers and its conditions:
@@ -1306,11 +1547,11 @@ the connection will be relayed toward IPv4 destination 163.221.202.12.
faithd must be invoked on FAITH-relay dual stack node.
For more details, consult kame/kame/faithd/README and
-draft-ietf-ngtrans-tcpudp-relay-01.txt.
+draft-ietf-ngtrans-tcpudp-relay-04.txt.
3.2 IPv6-to-IPv4 header translator
-# removed since it is not imported to FreeBSD-current
+(to be written)
4. IPsec
@@ -1324,6 +1565,9 @@ Note that KAME/OpenBSD does NOT include support for KAME IPsec code,
as OpenBSD team has their home-brew IPsec stack and they have no plan
to replace it. IPv6 support for IPsec is, therefore, lacking on KAME/OpenBSD.
+http://www.netbsd.org/Documentation/network/ipsec/ has more information
+including usage examples.
+
4.1 Policy Management
The kernel implements experimental policy management code. There are two way
@@ -1383,10 +1627,8 @@ Tunnel mode works basically fine, but comes with the following restrictions:
IPsec tunnel as pseudo interfaces.
- Authentication model for AH tunnel must be revisited. We'll need to
improve the policy management engine, eventually.
-- Tunnelling for IPv6 IPsec is still incomplete. This is disabled by default.
- If you need to perform experiments, add "options IPSEC_IPV6FWD" into
- the kernel configuration file. Note that path MTU discovery does not work
- across IPv6 IPsec tunnel gateway due to insufficient code.
+- Path MTU discovery does not work across IPv6 IPsec tunnel gateway due to
+ insufficient code.
AH specificaton does not talk much about "multiple AH on a packet" case.
We incrementally compute AH checksum, from inside to outside. Also, we
@@ -1401,6 +1643,16 @@ we do it incrementally. As a result, we get crypto checksums like below:
Also note that AH3 has the smallest sequence number, and AH1 has the largest
sequence number.
+To avoid traffic analysis on shorter packets, ESP output logic supports
+random length padding. By setting net.inet.ipsec.esp_randpad (or
+net.inet6.ipsec6.esp_randpad) to positive value N, you can ask the kernel
+to randomly pad packets shorter than N bytes, to random length smaller than
+or equal to N. Note that N does not include ESP authentication data length.
+Also note that the random padding is not included in TCP segment
+size computation. Negative value will turn off the functionality.
+Recommeded value for N is like 128, or 256. If you use a too big number
+as N, you may experience inefficiency due to fragmented packtes.
+
4.4 IPComp handling
IPComp stands for IP payload compression protocol. This is aimed for
@@ -1448,13 +1700,15 @@ Here are some points to be noted:
The IPsec code in the kernel conforms (or, tries to conform) to the
following standards:
"old IPsec" specification documented in rfc182[5-9].txt
- "new IPsec" specification documented in rfc240[1-6].txt, rfc241[01].txt,
- rfc2451.txt and draft-mcdonald-simple-ipsec-api-01.txt (draft expired,
- but you can take from ftp://ftp.kame.net/pub/internet-drafts/).
- (NOTE: IKE specifications, rfc240[7-9].txt are implemented in userland,
- as "racoon" IKE daemon)
+ "new IPsec" specification documented in:
+ rfc240[1-6].txt rfc241[01].txt rfc2451.txt
+ draft-mcdonald-simple-ipsec-api-01.txt
+ (expired, available in ftp://ftp.kame.net/pub/internet-drafts/)
+ draft-ietf-ipsec-ciph-aes-cbc-00.txt
IPComp:
RFC2393: IP Payload Compression Protocol (IPComp)
+IKE specifications (rfc240[7-9].txt) are implemented in userland
+as "racoon" IKE daemon.
Currently supported algorithms are:
old IPsec AH
@@ -1472,6 +1726,9 @@ Currently supported algorithms are:
keyed SHA1 with 96bit crypto checksum (no document)
HMAC MD5 with 96bit crypto checksum (rfc2403.txt
HMAC SHA1 with 96bit crypto checksum (rfc2404.txt)
+ HMAC SHA2-256 with 96bit crypto checksum (no document)
+ HMAC SHA2-384 with 96bit crypto checksum (no document)
+ HMAC SHA2-512 with 96bit crypto checksum (no document)
new IPsec ESP
null encryption (rfc2410.txt)
DES-CBC with derived IV
@@ -1480,7 +1737,9 @@ Currently supported algorithms are:
3DES-CBC with explicit IV (rfc2451.txt)
BLOWFISH CBC (rfc2451.txt)
CAST128 CBC (rfc2451.txt)
- RC5 CBC (rfc2451.txt)
+ RIJNDAEL/AES CBC (draft-ietf-ipsec-ciph-aes-cbc-00.txt,
+ uses IANA-assigned protocol number)
+ TWOFISH CBC (draft-ietf-ipsec-ciph-aes-cbc-00.txt)
each of the above can be combined with:
ESP authentication with HMAC-MD5(96bit)
ESP authentication with HMAC-SHA1(96bit)
@@ -1560,26 +1819,104 @@ coverage for IPsec crypto algorithms documented in RFC (we do not cover
algorithms with intellectual property issues, though).
Here are (some of) platforms we have tested IPsec/IKE interoperability
-in the past, in no particular order. Note that both ends (KAME and
+in the past, no particular order. Note that both ends (KAME and
others) may have modified their implementation, so use the following
list just for reference purposes.
- Altiga, Ashley-laurent (vpcom.com), Data Fellows (F-Secure),
- BlueSteel, CISCO, Ericsson, ACC, Fitel, FreeS/WAN, HITACHI, IBM
- AIX, IIJ, Intel, Microsoft WinNT, NAI PGPnet,
- NIST (linux IPsec + plutoplus), Netscreen, OpenBSD isakmpd, Radguard,
- RedCreek, Routerware, SSH, Secure Computing, Soliton, Toshiba,
- TIS/NAI Gauntret, VPNet, Yamaha RT100i
+ ACC, allied-telesis, Altiga, Ashley-laurent (vpcom.com), BlueSteel,
+ CISCO IOS, Cryptek, Checkpoint FW-1, Data Fellows (F-Secure),
+ Ericsson, Fitel, FreeS/WAN, HiFn, HITACHI, IBM AIX, IIJ, Intel Canada,
+ Intel Packet Protect, MEW NetCocoon, MGCS, Microsoft WinNT/2000,
+ NAI PGPnet, NetLock, NIST (linux IPsec + plutoplus), NEC IX5000,
+ Netscreen, NxNetworks, OpenBSD isakmpd, Pivotal, Radguard, RapidStream,
+ RedCreek, Routerware, RSA, SSH (both IPv4/IPv6), Secure Computing,
+ Soliton, Sun Solaris8, TIS/NAI Gauntret, Toshiba, VPNet,
+ Yamaha RT series
Here are (some of) platforms we have tested IPComp/IKE interoperability
in the past, in no particular order.
- IRE
+ IRE, SSH (both IPv4/IPv6), NetLock
+
+VPNC (vpnc.org) provides IPsec conformance tests, using KAME and OpenBSD
+IPsec/IKE implementations. Their test results are available at
+http://www.vpnc.org/conformance.html, and it may give you more idea
+about which implementation interoperates with KAME IPsec/IKE implementation.
5. ALTQ
-# removed since it is not imported to FreeBSD-current
+KAME kit includes ALTQ 2.1 code, which supports FreeBSD2, FreeBSD3,
+NetBSD and OpenBSD. For BSD/OS, ALTQ does not work.
+ALTQ in KAME supports (or tries to support) IPv6.
+(actually, ALTQ is developed on KAME repository since ALTQ 2.1 - Jan 2000)
+
+ALTQ occupies single character device number. For FreeBSD, it is officially
+allocated. For OpenBSD and NetBSD, we use the number which is not
+currently allocated (will eventually get an official number).
+The character device is enabled for i386 architecture only. To enable and
+compile ALTQ-ready kernel for other archititectures, take the following steps:
+- assume that your architecture is FOOBAA.
+- modify sys/arch/FOOBAA/FOOBAA/conf.c (or somewhere that defines cdevsw),
+ to include a line for ALTQ. look at sys/arch/i386/i386/conf.c for
+ example. The major number must be same as i386 case.
+- copy kernel configuration file (like ALTQ.v6 or GENERIC.v6) from i386,
+ and modify accordingly.
+- build a kernel.
+- before building userland, change netbsd/{lib,usr.sbin,usr.bin}/Makefile
+ (or openbsd/foobaa) so that it will visit altq-related sub directories.
6. mobile-ip6
-# removed since it is not imported to FreeBSD-current
+6.1 KAME node as correspondent node
+
+Default installation recognizes home address option (in destination
+options header). No sub-options are supported. interaction with
+IPsec, and/or 2292bis API, needs further study.
+
+6.2 KAME node as home agent/mobile node
+
+KAME kit includes Ericsson mobile-ip6 code. The integration is just started
+(in Feb 2000), and we will need some more time to integrate it better.
+
+See kame/mip6config/{QUICKSTART,README_MIP6.txt} for more details.
+
+The Ericsson code implements revision 09 of the mobile-ip6 draft. There
+are other implementations available:
+ NEC: http://www.6bone.nec.co.jp/mipv6/internal-dist/ (-13 draft)
+ SFC: http://neo.sfc.wide.ad.jp/~mip6/ (-13 draft)
+
+7. Coding style
+
+The KAME developers basically do not make a bother about coding
+style. However, there is still some agreement on the style, in order
+to make the distributed develoment smooth.
+
+- the tab character should be 8 columns wide (tabstops are at 8, 16, 24, ...
+ column). With vi, use ":set ts=8 sw=8".
+- each line should be within 80 characters.
+- keep a single open/close bracket in a comment such as in the following
+ line:
+ putchar('('); /* ) */
+ without this, some vi users would have a hard time to match a pair of
+ brackets. Although this type of bracket seems clumsy and is even
+ harmful for some other type of vi users and Emacs users, the
+ agreement in the KAME developers is to allow it.
+- add the following line to the head of every KAME-derived file:
+ /* (dollar)KAME(dollar) */
+ where "(dollar)" is the dollar character ($), and around "$" are tabs.
+ (this is for C. For other language, you should use its own comment
+ line.)
+ Once commited to the CVS repository, this line will contain its
+ version number (see, for example, at the top of this file). This
+ would make it easy to report a bug.
+- when creating a new file with the WIDE copyright, tap "make copyright.c" at
+ the top-level, and use copyright.c as a template. KAME RCS tag will be
+ included automatically.
+- when editting a third-party package, keep its own coding style as
+ much as possible, even if the style does not follow the items above.
+
+When you want to contribute something to the KAME project, and if *you
+do not mind* the agreement, it would be helpful for the project to
+keep these rules. Note, however, that we would never intend to force
+you to adopt our rules. We would rather regard your own style,
+especially when you have a policy about the style.
<end of IMPLEMENTATION>
diff --git a/share/examples/IPv6/USAGE b/share/examples/IPv6/USAGE
index 5a02037..d9191899 100644
--- a/share/examples/IPv6/USAGE
+++ b/share/examples/IPv6/USAGE
@@ -1,12 +1,12 @@
- USAGE
-
- KAME Project
- http://www.kame.net/newsletter/
- $FreeBSD$
+ USAGE
+ KAME Project
+ $KAME: USAGE,v 1.33 2000/11/22 10:22:57 itojun Exp $
+ $FreeBSD$
This is a introduction of how to use the commands provided in the KAME
kit. For more information, please refer to each man page.
+
<<<ifconfig>>>
A link-local address is automatically assigned to each interface, when
@@ -14,6 +14,11 @@ the interface becomes up for the first time. Even if you find an interface
without a link-local address, do not panic. The link-local address will be
assigned when it becomes up (with "ifconfig IF up").
+If you do not see a link-local address assigned to an interface on "ifconfig
+up", the interface does not support IPv6 for some reasons - for example,
+if the interface does not support link-layer multicast (IFF_MULTICAST is not
+set), the interface cannot be used for IPv6.
+
Some network drivers allow an interface to become up even without a
hardware address (for example, PCMCIA network cards). In such cases, it is
possible that an interface has no link-local address even if the
@@ -21,190 +26,187 @@ interface is up. If you see such situation, please disable the
interface once and then re-enable it (i.e. do `ifconfig IF down;
ifconfig IF up').
-Pseudo interfaces (like "gif" tunnel device) will borrow IPv6 interface
-identifier (lowermost 64bit of the address) from EUI64/IEEE802 sources,
-like ethernet cards. Pseudo interfaces will be able to get IPv6 link-local
-address, if you have other "real" interface configured beforehand.
-If you have no EUI64/IEEE802 sources on the node, you may need to configure
-link-local address manually. Though we have last-resort code in the kernel,
-which generates interface identifier from MD5(hostname), it may not suitable
-for your usage (for example, if you configure same hostname on both sides
-of gif tunnel, you will be doomed).
+Pseudo interfaces (like "gif" tunnel device) will borrow IPv6
+interface identifier (lowermost 64bit of the address) from
+EUI64/IEEE802 sources, like ethernet cards. Pseudo interfaces will be
+able to get an IPv6 link-local address, if you have other "real"
+interface configured beforehand. If you have no EUI64/IEEE802 sources
+on the node, we have last-resort code in the kernel, which generates
+interface identifier from MD5(hostname). MD5(hostname) may not be suitable
+for your usage (for example, if you configure same hostname on both sides of
+gif tunnel, you will be doomed), and if so, you may need to configure
+link-local address manually.
+See RFC2472 for more discussion on how to generate an interface ID for
+pseudo interfaces.
If you have a router announcing Router Advertisement,
-global addresses will be assigned automatically. So, "ifconfig" is not
-necessary for your *host*. (Please refer to "sysctl" section for configuring
-a host to accept Router Advertisement.)
+global addresses will be assigned automatically. So, neither
+"ifconfig" nor "prefix" is necessary for your *host* (non-router node).
+(Please refer to "sysctl" section for configuring a host to accept
+Router Advertisement.)
If you want to set up a router, you need to assign global addresses
-for two or more interfaces by "ifconfig" or "prefix". (prefix command
-is described at next section)
+for two or more interfaces by "ifconfig" or "prefix" (prefix command
+is described at next section).
If you want to assign a global address by "ifconfig", don't forget to
specify the "alias" argument to keep the link-local address.
-# ifconfig de0 inet6 fec0:0:0:1000:200:f8ff:fe01:6317 alias
+# ifconfig de0 inet6 3ffe:501:808:1:200:f8ff:fe01:6317 prefixlen 64 alias
# ifconfig de0
de0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
- inet 172.16.202.12 netmask 0xffffff00 broadcast 172.16.202.255
- inet6 fe80::200:f8ff:fe01:6317%de0 prefixlen 64
- inet6 fec0:0:0:1000:200:f8ff:fe01:6317 prefixlen 64
- inet6 fec0:0:0:1000:: prefixlen 64 anycast
- ether 00:00:f8:01:63:17
- media: autoselect (10baseT/UTP) status: active
- supported media: autoselect 100baseTX <full-duplex> 100baseTX 10baseT/UTP <full-duplex> 10baseT/UTP
+ inet6 fe80::200:f8ff:fe01:6317%de0 prefixlen 64 scopeid 0x1
+ inet 163.221.202.12 netmask 0xffffff00 broadcast 163.221.202.255
+ inet6 3ffe:501:808:1:200:f8ff:fe01:6317 prefixlen 64
+ ether 00:00:f8:01:63:17
+ media: 100baseTX status: active
See also "/etc/rc.network6" for actual examples.
<<prefix>>
-In IPv6 architecture, an IPv6 address of an interface can be generated
-from a prefix assigned to it, and a link-dependent identifier for the
-interface. Assigning a full IPv6 address by ifconfig is not
-necessary anymore, because, user can only take care of prefix, by letting
-system take care of interface identifier.
+In the IPv6 architecture, an IPv6 address of an interface can be
+generated from a prefix assigned to the interface, and a
+link-dependent identifier for the interface. So assigning a full IPv6
+address by ifconfig is not necessary anymore, because user can only
+take care of prefix, by letting system take care of interface
+identifier.
The newly added "prefix" command enables user to just assign prefixes
for interfaces, and let your system automatically generate IPv6
addresses. Prefixes added by the "prefix" command is maintained in
the kernel consistently with prefixes assigned by Router
-Renumbering(in case of routers).
-
-But "prefix" command can only be used on router, because host should be
-able to configure its addr automatically. Prefixes added by the "prefix"
-command are maintained independently from prefixes assigned by
-Router Advertisement. Those two type of prefixes should not coexist on
-a machine at the same time, and when it happens, it is considered to be
-miss configuration.
+Advertisement (in case of hosts) and with prefixes assigned by Router
+Renumbering (in case of routers). Manual assignment of prefixes or
+change of prefix properties take precedence over ones assigned by
+Router Advertisement or Router Renumbering.
-Manual assignment of prefixes or change of prefix properties take
-precedence over ones assigned by Router Renumbering.
+prefix command works only on routers.
-If you want to assign a prefix(and consequently an address) manually, do
+If you want to assign a prefix (and consequently address) manually, do
as follows:
-# prefix de0 fec0:0:0:1000::
# ifconfig de0
de0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
- inet 172.16.202.12 netmask 0xffffff00 broadcast 172.16.202.255
- inet6 fe80:1::200:f8ff:fe01:6317 prefixlen 64
- inet6 fec0:0:0:1000:200:f8ff:fe01:6317 prefixlen 64
- inet6 fec0:0:0:1000:: prefixlen 64 anycast
- ether 00:00:f8:01:63:17
- media: autoselect (10baseT/UTP) status: active
- supported media: autoselect 100baseTX <full-duplex> 100baseTX 10baseT/UTP <full-duplex> 10baseT/UTP
+ inet6 fe80::200:f8ff:fe01:6317%de0 prefixlen 64 scopeid 0x1
+ inet 163.221.202.12 netmask 0xffffff00 broadcast 163.221.202.255
+ ether 00:00:f8:01:63:17
+ media: 100baseTX status: active
+# prefix de0 3ffe:501:808:1::
+# ifconfig de0
+de0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
+ inet6 fe80::200:f8ff:fe01:6317%de0 prefixlen 64 scopeid 0x1
+ inet 163.221.202.12 netmask 0xffffff00 broadcast 163.221.202.255
+ inet6 3ffe:501:808:1:200:f8ff:fe01:6317 prefixlen 64
+ ether 00:00:f8:01:63:17
+ media: 100baseTX status: active
-To check assigned prefix, use the "ndp" command. (See description of
-ndp command about its usage)
+To check assigned prefix, use the "ndp" command (See description of
+ndp command about its usage).
# ndp -p
-fec0:0:0:1000::/64 if=de0
- flags=LA, vltime=2592000, pltime=604800, expire=Never
+3ffe:501:808:1::/64 if=de0
+ flags=LA, vltime=2592000, pltime=604800, expire=Never, origin=RR
No advertising router
The "prefix" command also has node internal prefix renumbering
ability.
-If you have multiple prefixes which have fec0:0:0:1000:/56 at the top,
-and would like to renumber them to fec0:0:0:2000:/56, then use the
+If you have multiple prefixes which have 3ffe:501:808:/48 at the top,
+and would like to renumber them to 3ffe:501:4819:/48, then use the
"prefix" command with the "matchpr" argument and the "usepr" argument.
Suppose that current state of before renumbering as follows:
# ifconfig de0
de0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
- inet 172.16.202.12 netmask 0xffffff00 broadcast 172.16.202.255
- inet6 fe80:1::200:f8ff:fe01:6317 prefixlen 64
- inet6 fec0:0:0:1000:200:f8ff:fe01:6317 prefixlen 64
- inet6 fec0:0:0:1000:: prefixlen 64 anycast
- ether 00:00:f8:01:63:17
- media: autoselect (10baseT/UTP) status: active
- supported media: autoselect 100baseTX <full-duplex> 100baseTX 10baseT/UTP <full-duplex> 10baseT/UTP
-
+ inet6 fe80::200:f8ff:fe01:6317%de0 prefixlen 64 scopeid 0x1
+ inet 163.221.202.12 netmask 0xffffff00 broadcast 163.221.202.255
+ inet6 3ffe:501:808:1:200:f8ff:fe01:6317 prefixlen 64
+ ether 00:00:f8:01:63:17
+ media: 100baseTX status: active
# ifconfig de1
de1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
- inet 172.16.203.12 netmask 0xffffff00 broadcast 172.16.203.255
- inet6 fe80:1::200:f8ff:fe55:7011 prefixlen 64
- inet6 fec0:0:0:1001:200:f8ff:fe55:7011 prefixlen 64
- inet6 fec0:0:0:1001:: prefixlen 64 anycast
+ inet6 fe80::200:f8ff:fe55:7011%de1 prefixlen 64 scopeid 0x2
+ inet 163.221.203.12 netmask 0xffffff00 broadcast 163.221.203.255
+ inet6 3ffe:501:808:2:200:f8ff:fe55:7011 prefixlen 64
ether 00:00:f8:55:70:11
- media: autoselect (10baseT/UTP) status: active
- supported media: autoselect 100baseTX <full-duplex> 100baseTX 10baseT/UTP <full-duplex> 10baseT/UTP
-
+ media: 100baseTX status: active
# ndp -p
-fec0:0:0:1000::/64 if=de0
- flags=LA, vltime=2592000, pltime=604800, expire=Never
+3ffe:501:808:1::/64 if=de0
+ flags=LA, vltime=2592000, pltime=604800, expire=Never, origin=RR
No advertising router
-fec0:0:0:1001::/64 if=de1
- flags=LA, vltime=2592000, pltime=604800, expire=Never
+3ffe:501:808:2::/64 if=de1
+ flags=LA, vltime=2592000, pltime=604800, expire=Never, origin=RR
No advertising router
Then do as follows:
-# prefix -a matchpr fec0:0:0:1000:: mp_len 56 usepr fec0:0:0:2000:: up_uselen 56 change
+# prefix -a matchpr 3ffe:501:808:: mp_len 48 usepr 3ffe:501:4819:: up_uselen 48 change
If command is successful, prefixes and addresses will be renumbered as
follows.
# ifconfig de0
de0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
- inet 172.16.202.12 netmask 0xffffff00 broadcast 172.16.202.255
- inet6 fe80:1::200:f8ff:fe01:6317 prefixlen 64
- inet6 fec0:0:0:2000:200:f8ff:fe01:6317 prefixlen 64
- inet6 fec0:0:0:2000:: prefixlen 64 anycast
- ether 00:00:f8:01:63:17
- media: autoselect (10baseT/UTP) status: active
- supported media: autoselect 100baseTX <full-duplex> 100baseTX 10baseT/UTP <full-duplex> 10baseT/UTP
+ inet6 fe80::200:f8ff:fe01:6317%de0 prefixlen 64 scopeid 0x1
+ inet 163.221.202.12 netmask 0xffffff00 broadcast 163.221.202.255
+ inet6 3ffe:501:4819:1:200:f8ff:fe01:6317 prefixlen 64
+ ether 00:00:f8:01:63:17
+ media: 100baseTX status: active
# ifconfig de1
de1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
- inet 172.16.203.12 netmask 0xffffff00 broadcast 172.16.203.255
- inet6 fe80:1::200:f8ff:fe55:7011 prefixlen 64
- inet6 fec0:0:0:2001:200:f8ff:fe55:7011 prefixlen 64
- inet6 fec0:0:0:2001:: prefixlen 64 anycast
+ inet6 fe80::200:f8ff:fe55:7011%de0 prefixlen 64 scopeid 0x2
+ inet 163.221.203.12 netmask 0xffffff00 broadcast 163.221.203.255
+ inet6 3ffe:501:4819:2:200:f8ff:fe55:7011 prefixlen 64
ether 00:00:f8:55:70:11
- media: autoselect (10baseT/UTP) status: active
- supported media: autoselect 100baseTX <full-duplex> 100baseTX 10baseT/UTP <full-duplex> 10baseT/UTP
+ media: 100baseTX status: active
# ndp -p
-fec0:0:0:2000::/64 if=de0
- flags=LA, vltime=2592000, pltime=604800, expire=Never
+3ffe:501:4819:1::/64 if=de0
+ flags=LA, vltime=2592000, pltime=604800, expire=Never, origin=RR
No advertising router
-fec0:0:0:2001::/64 if=de1
- flags=LA, vltime=2592000, pltime=604800, expire=Never
+3ffe:501:4819:2::/64 if=de1
+ flags=LA, vltime=2592000, pltime=604800, expire=Never, origin=RR
No advertising router
See also "/etc/rc.network6" for actual examples.
+
<<<route>>>
-If there is a router announcing Router Advertisement on the subnet,
-you don't need to add a default route for your host by yourself.
-(Please refer to "sysctl" section to accept Router Advertisement.)
+If there is a router announcing Router Advertisement on a subnet,
+you need not to add a default route for your host by hand
+(Please refer to "sysctl" section to accept Router Advertisement).
+
+If you want to add a default route manually, do like:
-If you want to add a default route manually, do as follows:
+# route add -inet6 default fe80::200:a2ff:fe0e:7543%ed0
-# route add -inet6 default fe80::200:a2ff:fe0e:7543%de0
+"default" means ::/0. In other cases, if "prefixlen" is omitted, 64
+is assumed for "prefixlen" to get along with the aggregatable address.
-"default" means ::/0.
+Note that, in IPv6, a link-local address should be used as gateway
+("fe80::200:a2ff:fe0e:7543%ed0" in the above). If you use global addresses,
+ICMPv6 redirect will not work properly. Also note that we use a special form
+of link-local address as gateway. See Section 1.3 of IMPLEMENTATION for
+more details.
+For ease of configuration we recommend you to avoid static routes and run
+a routing daemon (route6d for example) instead.
-Note that, in IPv6, link-local address should be used as gateway
-("fe80::200:a2ff:fe0e:7543%de1" in the above). If you use global addresses,
-icmp6 redirect may not work properly. For ease of configuration we recommend
-you to avoid static routes and run a routing daemon (route6d for example)
-instead.
-<<<ping6>>> (This might be integrated into "ping" as "ping -6" in the future.)
+<<<ping6>>>
Reachability can be checked by "ping6". This "ping6" allows multicast
for its argument.
-% ping6 -I xl0 ff02::1
-or
-% ping6 ff02::1%xl0
+% ping6 -n -I ed0 ff02::1
+
+PING6(56=40+8+8 bytes) fe80::5254:ff:feda:cb7d --> ff02::1%ed0
+56 bytes from fe80::5254:ff:feda:cb7d%lo0, icmp_seq=0 hlim=64 time=0.25 ms
+56 bytes from fe80::2a0:c9ff:fe84:ed6c%ed0, icmp_seq=0 hlim=64 time=1.333 ms(DUP!)
+56 bytes from fe80::5254:ff:feda:d161%ed0, icmp_seq=0 hlim=64 time=1.459 ms(DUP!)
+56 bytes from fe80::260:97ff:fec2:80bf%ed0, icmp_seq=0 hlim=64 time=1.538 ms(DUP!)
+56 bytes from 3ffe:501:4819:2000:5054:ff:fedb:aa46, icmp_seq=0 hlim=255 time=1.615 ms(DUP!)
-PING6(56=40+8+8 bytes) fe80::5254:ff:feda:cb7d --> ff02::1
-56 bytes from fe80::5254:ff:feda:cb7d, icmp_seq=0 hlim=64 time=0.25 ms
-56 bytes from fe80::2a0:c9ff:fe84:ed6c, icmp_seq=0 hlim=64 time=1.333 ms(DUP!)
-56 bytes from fe80::5254:ff:feda:d161, icmp_seq=0 hlim=64 time=1.459 ms(DUP!)
-56 bytes from fe80::260:97ff:fec2:80bf, icmp_seq=0 hlim=64 time=1.538 ms(DUP!)
<<<ping6 -w>>>
@@ -212,13 +214,14 @@ Name resolution is possible by ICMPv6 node information query message.
This is very convenient for link-local addresses whose host name cannot be
resolved by DNS. Specify the "-w" option to "ping6".
-% ping6 -I xl0 -w ff02::1
+% ping6 -n -I ed0 -w ff02::1
-64 bytes from fe80::5254:ff:feda:cb7d: fto.kame.net
-67 bytes from fe80::5254:ff:feda:d161: banana.kame.net
-69 bytes from fe80::2a0:c9ff:fe84:ebd9: paradise.kame.net
-66 bytes from fe80::260:8ff:fe8b:447f: taroh.kame.net
-66 bytes from fe80::2a0:c9ff:fe84:ed6c: ayame.kame.net
+64 bytes from fe80::5254:ff:feda:cb7d%lo0: fto.kame.net
+67 bytes from fe80::5254:ff:feda:d161%ed0: banana.kame.net
+69 bytes from fe80::2a0:c9ff:fe84:ebd9%ed0: paradise.kame.net
+66 bytes from fe80::260:8ff:fe8b:447f%ed0: taroh.kame.net
+66 bytes from fe80::2a0:c9ff:fe84:ed6c%ed0: ayame.kame.net
+
<<<traceroute6>>>
@@ -239,60 +242,59 @@ traceroute to tokyo.v6.wide.ad.jp (3ffe:501:0:401:200:e8ff:fed5:8923), 30 hops m
2 otemachi.v6.wide.ad.jp (3ffe:501:0:1802:260:97ff:feb6:7ff0) 27.345 ms 26.706 ms 26.563 ms
3 tokyo.v6.wide.ad.jp (3ffe:501:0:401:200:e8ff:fed5:8923) 26.329 ms 26.36 ms 28.63 ms
+
<<<ndp>>>
To display the current Neighbor cache, use "ndp":
% ndp -a
Neighbor Linklayer Address Netif Expire St Flgs Prbs
-nr60.v6.kame.net 0:60:97:c2:80:bf xl0 expired S R
-fec0:0:0:1000:2c0:cff:fe10 0:c0:c:10:3a:53 xl0 permanent R
-paradise.v6.kame.net 52:54:0:dc:52:17 xl0 expired S R
-fe80:1::200:eff:fe49:f929 0:0:e:49:f9:29 xl0 expired S R
-fe80:1::200:86ff:fe05:80da 0:0:86:5:80:da xl0 expired S
-fe80:1::200:86ff:fe05:c2d8 0:0:86:5:c2:d8 xl0 9s R
+nr60.v6.kame.net 0:60:97:c2:80:bf ed0 expired S R
+3ffe:501:4819:2000:2c0:cff:fe 0:c0:c:10:3a:53 ed0 permanent R
+paradise.v6.kame.net 52:54:0:dc:52:17 ed0 expired S R
+fe80::200:eff:fe49:f929%ed0 0:0:e:49:f9:29 ed0 expired S R
+fe80::200:86ff:fe05:80da%ed0 0:0:86:5:80:da ed0 expired S
+fe80::200:86ff:fe05:c2d8%ed0 0:0:86:5:c2:d8 ed0 9s R
-To flush the all NDP cache, execute the following by root.
+To flush all of the NDP cache entries, execute the following as root.
# ndp -c
-To display the prefix list.
+To display the prefix list:
% ndp -p
-fec0:0:0::1000::/64 if=xl0
- flags=LA, vltime=2592000, pltime=604800, expire=29d23h59m58s
+3ffe:501:4819:2000::/64 if=ed0
+ flags=LA, vltime=2592000, pltime=604800, expire=29d23h59m58s, origin=RA
advertised by
- fe80::5254:ff:fedc:5217
- fe80::260:97ff:fec2:80bf
- fe80::200:eff:fe49:f929
+ fe80::5254:ff:fedc:5217%ed0 (reachable)
+ fe80::260:97ff:fec2:80bf%ed0 (reachable)
+ fe80::200:eff:fe49:f929%ed0 (no neighbor state)
-To display the default router list.
+To display the default router list:
% ndp -r
-fe80::260:97ff:fec2:80bf if=xl0, flags=, expire=29m55s
-fe80::5254:ff:fedc:5217 if=xl0, flags=, expire=29m7s
-fe80::200:eff:fe49:f929 if=xl0, flags=, expire=28m47s
+fe80::260:97ff:fec2:80bf if=ed0, flags=, expire=29m55s
+fe80::5254:ff:fedc:5217 if=ed0, flags=, expire=29m7s
+fe80::200:eff:fe49:f929 if=ed0, flags=, expire=28m47s
+
<<<rtsol>>>
To generate a Router Solicitation message right now to get global
addresses, use "rtsol".
-# ifconfig xl0
-xl0: flags=8a43<UP,BROADCAST,RUNNING,ALLMULTI,SIMPLEX,MULTICAST> mtu 1500
- inet6 fe80:2::2a0:24ff:feab:839b%xl0 prefixlen 64
- ether 0:a0:24:ab:83:9b
- media: autoselect (10baseT/UTP) status: active
- supported media: autoselect 100baseTX <full-duplex> 100baseTX 10baseT/UTP <full-duplex> 10baseT/UTP 100baseTX <hw-loopback>
-
-# rtsol xl0
-# ifconfig xl0
-xl0: flags=8a43<UP,BROADCAST,RUNNING,ALLMULTI,SIMPLEX,MULTICAST> mtu 1500
- inet6 fe80:2::2a0:24ff:feab:839b%xl0 prefixlen 64
- inet6 fec0:0:0:1000:2a0:24ff:feab:839b prefixlen 64
- ether 0:a0:24:ab:83:9b
- media: autoselect (10baseT/UTP) status: active
- supported media: autoselect 100baseTX <full-duplex> 100baseTX 10baseT/UTP <full-duplex> 10baseT/UTP 100baseTX <hw-loopback>
+# ifconfig ef0
+ef0: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST>
+ link type ether 0:a0:24:ab:83:9b mtu 1500 speed 10Mbps
+ media 10baseT status active
+ inet6 fe80::2a0:24ff:feab:839b%ef0 prefixlen 64 scopeid 0x2
+# rtsol ef0
+# ifconfig ef0
+ef0: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST>
+ link type ether 0:a0:24:ab:83:9b mtu 1500 speed 10Mbps
+ media 10baseT status active
+ inet6 fe80::2a0:24ff:feab:839b%ef0 prefixlen 64 scopeid 0x2
+ inet6 3ffe:501:4819:2000:2a0:24ff:feab:839b prefixlen 64
<<<rtsold>>>
@@ -301,18 +303,23 @@ rtsold is a daemon version of rtsol. If you run KAME IPv6 on a laptop
computer and frequently move with it, the daemon is useful since it watches
the interface and sends router solicitations when the status of the interface
changes. Note, however, that the feature is disabled by default. Please
-add -m option at invocation of rtsold.
+add -m option when invocation of rtsold.
rtsold also supports multiple interfaces. For example, you can
invoke the daemon as follows:
+
# rtsold -m ep0 cnw0
+
<<<netstat>>>
To see routing table:
-
+
# netstat -nr
-# netstat -nrl (long format with Ref and Use)
+# netstat -nrl
+ long format with Ref and Use. Note that bsdi4 does not support the
+ -l option. You should use the -O option instead.
+
<<<sysctl>>>
@@ -324,13 +331,14 @@ as follows:
# sysctl -w net.inet6.ip6.accept_rtadv=1
+
<<<gifconfig>>>
"gif" interface enables you to perform IPv{4,6} over IPv{4,6}
protocol tunneling. To use this interface, you must specify the
outer IPv{4,6} address by using gifconfig, like:
-# gifconfig gif0 172.16.198.61 172.16.11.21
+# gifconfig gif0 163.221.198.61 163.221.11.21
"ifconfig gif0" will configure the address pair used for inner
IPv{4,6} header.
@@ -345,15 +353,14 @@ The following example configures un-numbered IPv6-over-IPv4 tunnel:
The following example configures numbered IPv6-over-IPv4 tunnel:
# gifconfig gif0 10.0.0.1 10.0.0.1 netmask 255.255.255.0
-# ifconfig gif0 inet6 fec0:0:0:3000::1 fec0:0:0:3000::2 prefixlen 64 alias
+# ifconfig gif0 inet6 3ffe:501:808:5::1 3ffe:501:808:5::2 prefixlen 64 alias
IPv6 spec allows you to use point-to-point link without global IPv6
address assigned to the interface. Routing protocol (such as RIPng)
uses link-local addresses only. If you are to configure IPv6-over-IPv4
tunnel, you need not to configure an address pair for inner IPv6
header. We suggest you to use the former example (un-numbered
-IPv6-over-IPv4 tunnel) to connect to 6bone for simplicity,
-for router to router connection.
+IPv6-over-IPv4 tunnel) to connect to 6bone for simplicity.
Note that it is so easy to make an infinite routing loop using gif
interface, if you configure a tunnel using the same protocol family
@@ -361,6 +368,16 @@ for inner and outer header (i.e. IPv4-over-IPv4).
Refer to gifconfig(8) for more details.
+
+<<<6to4>>>
+
+WARNING: malicious party can abuse 6to4 relay routers/sites, read through
+internet draft draft-itojun-ipv6-transition-abuse-xx.txt before configuring it.
+
+"stf" interface enables you to perform 6to4 IPv6-over-IPv4 encapsulation,
+as documented in draft-ietf-ngtrans-6to4-06.txt. See stf(4) for details.
+
+
<<<inetd>>>
Inetd supports AF_INET and AF_INET6 sockets, with IPsec policy
@@ -368,17 +385,18 @@ configuration support.
Refer to inetd(8) for more details.
+
<<<IPsec>>>
-The current KAME supports both transport mode and tunnel mode.
-However, tunnel mode comes with some restrictions.
-http://www.kame.net/newsletter/ has more comprehensive examples.
+IPsec requires fairly complex configuration, so here we show transport
+mode only. http://www.kame.net/newsletter/ has more comprehensive
+examples.
-Let's setup security association to deploy a secure channel between
+Let us setup security association to deploy a secure channel between
HOST A (10.2.3.4) and HOST B (10.6.7.8). Here we show a little
complicated example. From HOST A to HOST B, only old AH is used.
From HOST B to HOST A, new AH and new ESP are combined.
-
+
Now we should choose algorithm to be used corresponding to "AH"/"new
AH"/"ESP"/"new ESP". Please refer to the "setkey" man page to know
algorithm names. Our choice is MD5 for AH, new-HMAC-SHA1 for new AH,
@@ -389,7 +407,7 @@ length must be equal to 16 bytes for MD5, 20 for new-HMAC-SHA1,
and 8 for new-DES-expIV. Now we choose "MYSECRETMYSECRET",
"KAMEKAMEKAMEKAMEKAME", "PASSWORD", respectively.
-OK, let's assign SPI (Security Parameter Index) for each protocol.
+OK, let us assign SPI (Security Parameter Index) for each protocol.
Please note that we need 3 SPIs for this secure channel since three
security headers are produced (one for from HOST A to HOST B, two for
from HOST B to HOST A). Please also note that SPI MUST be greater
@@ -407,7 +425,7 @@ than or equal to 256. We choose, 1000, 2000, and 3000, respectively.
(2.1)
HOST A <------ HOST B
<------
- (2.2)
+ (2.2)
(2.1)
PROTO=AH
@@ -422,7 +440,7 @@ than or equal to 256. We choose, 1000, 2000, and 3000, respectively.
KEY=PASSWORD
SPI=3000
-Now, let's setup security association. Execute "setkey" on both HOST
+Now, let us setup security association. Execute "setkey" on both HOST
A and B:
# setkey -c
@@ -442,9 +460,8 @@ spdadd 10.2.3.4 10.6.7.8 any -P out ipsec
At B:
spdadd 10.6.7.8 10.2.3.4 any -P out ipsec
- esp/transport/10.6.7.8-10.2.3.4/require ;
-spdadd 10.6.7.8 10.2.3.4 any -P out ipsec
- ah/transport/10.6.7.8-10.2.3.4/require ;
+ esp/transport//require
+ ah/transport//require ;
^D
To utilize the security associations installed into the kernel, you
@@ -454,7 +471,7 @@ the "ping" command has the -P option with parameter to enable AH and/or ESP.
For example:
% ping -P "out ipsec \
- ah/transport/10.0.1.1-10.0.2.2/use \
+ ah/transport//use \
esp/tunnel/10.0.1.1-10.0.1.2/require" 10.0.2.2
If there are proper SAs, this policy specification causes ICMP packet
@@ -467,165 +484,6 @@ to be AH transport mode inner ESP tunnel mode like below.
==================== AH ==================
-
-Another example using IPv6.
-
-ESP transport mode is recommended for TCP port number 110 between Host-A and
-Host-B.
-
- ============ ESP ============
- | |
- Host-A Host-B
- fec0::10 -------------------- fec0::11
-
-Encryption algorithm is blowfish-cbc whose key is "kamekame", and
-authentication algorithm is hmac-sha1 whose key is "this is the test key".
-Configuration at Host-A:
-
- # setkey -c <<EOF
- spdadd fec0::10[any] fec0::11[110] tcp -P out ipsec
- esp/transport/fec0::10-fec0::11/use ;
- spdadd fec0::11[110] fec0::10[any] tcp -P in ipsec
- esp/transport/fec0::11-fec0::10/use ;
- add fec0::10 fec0::11 esp 0x10001
- -m transport
- -E blowfish-cbc "kamekame"
- -A hmac-sha1 "this is the test key" ;
- add fec0::11 fec0::10 esp 0x10002
- -m transport
- -E blowfish-cbc "kamekame"
- -A hmac-sha1 "this is the test key" ;
- EOF
-
-and at Host-B:
-
- # setkey -c <<EOF
- spdadd fec0::11[110] fec0::10[any] tcp -P out ipsec
- esp/transport/fec0::11-fec0::10/use ;
- spdadd fec0::10[any] fec0::11[110] tcp -P in ipsec
- esp/transport/fec0::10-fec0::11/use ;
- add fec0::10 fec0::11 esp 0x10001 -m transport
- -E blowfish-cbc "kamekame"
- -A hmac-sha1 "this is the test key" ;
- add fec0::11 fec0::10 esp 0x10002 -m transport
- -E blowfish-cbc "kamekame"
- -A hmac-sha1 "this is the test key" ;
- EOF
-
-Note the direction of SP.
-
-
-Tunnel mode between two security gateways
-
-Security protocol is old AH tunnel mode, i.e. specified by RFC1826, with
-keyed-md5 whose key is "this is the test" as authentication algorithm.
-
- ======= AH =======
- | |
- Network-A Gateway-A Gateway-B Network-B
- 10.0.1.0/24 ---- 172.16.0.1 ----- 172.16.0.2 ---- 10.0.2.0/24
-
-Configuration at Gateway-A:
-
- # setkey -c <<EOF
- spdadd 10.0.1.0/24 10.0.2.0/24 any -P out ipsec
- ah/tunnel/172.16.0.1-172.16.0.2/require ;
- spdadd 10.0.2.0/24 10.0.1.0/24 any -P in ipsec
- ah/tunnel/172.16.0.2-172.16.0.1/require ;
- add 172.16.0.1 172.16.0.2 ah-old 0x10003 -m any
- -A keyed-md5 "this is the test" ;
- add 172.16.0.2 172.16.0.1 ah-old 0x10004 -m any
- -A keyed-md5 "this is the test" ;
-
-If port number field is omitted such above then "[any]" is employed. `-m'
-specifies the mode of SA to be used. "-m any" means wild-card of mode of
-security protocol. You can use this SA for both tunnel and transport mode.
-
-and at Gateway-B:
-
- # setkey -c <<EOF
- spdadd 10.0.2.0/24 10.0.1.0/24 any -P out ipsec
- ah/tunnel/172.16.0.2-172.16.0.1/require ;
- spdadd 10.0.1.0/24 10.0.2.0/24 any -P in ipsec
- ah/tunnel/172.16.0.1-172.16.0.2/require ;
- add 172.16.0.1 172.16.0.2 ah-old 0x10003 -m any
- -A keyed-md5 "this is the test" ;
- add 172.16.0.2 172.16.0.1 ah-old 0x10004 -m any
- -A keyed-md5 "this is the test" ;
-
-
-Making SA bundle between two security gateways
-
-AH transport mode and ESP tunnel mode is required between Gateway-A and
-Gateway-B. In this case, ESP tunnel mode is applied first, and AH transport
-mode is next.
-
- ========== AH =========
- | ======= ESP ===== |
- | | | |
- Network-A Gateway-A Gateway-B Network-B
- fec0:0:0:1::/64 --- fec0:0:0:1::1 ---- fec0:0:0:2::1 --- fec0:0:0:2::/64
-
-Encryption algorithm is 3des-cbc, and authentication algorithm for ESP is
-hmac-sha1. Authentication algorithm for AH is hmac-md5.
-Configuration at Gateway-A:
-
- # setkey -c <<EOF
- spdadd fec0:0:0:1::/64 fec0:0:0:2::/64 any -P out ipsec
- esp/tunnel/fec0:0:0:1::1-fec0:0:0:2::1/require
- ah/transport/fec0:0:0:1::1-fec0:0:0:2::1/require ;
- spdadd fec0:0:0:2::/64 fec0:0:0:1::/64 any -P in ipsec
- esp/tunnel/fec0:0:0:2::1-fec0:0:0:1::1/require
- ah/transport/fec0:0:0:2::1-fec0:0:0:1::1/require ;
- add fec0:0:0:1::1 fec0:0:0:2::1 esp 0x10001 -m tunnel
- -E 3des-cbc "kamekame12341234kame1234"
- -A hmac-sha1 "this is the test key" ;
- add fec0:0:0:1::1 fec0:0:0:2::1 ah 0x10001 -m transport
- -A hmac-md5 "this is the test" ;
- add fec0:0:0:2::1 fec0:0:0:1::1 esp 0x10001 -m tunnel
- -E 3des-cbc "kamekame12341234kame1234"
- -A hmac-sha1 "this is the test key" ;
- add fec0:0:0:2::1 fec0:0:0:1::1 ah 0x10001 -m transport
- -A hmac-md5 "this is the test" ;
-
-
-Making SAs with the different end
-
-ESP tunnel mode is required between Host-A and Gateway-A. Encryption
-algorithm is cast128-cbc, and authentication algorithm for ESP is hmac-sha1.
-ESP transport mode is recommended between Host-A and Host-B. Encryption
-algorithm is rc5-cbc, and authentication algorithm for ESP is hmac-md5.
-
- ================== ESP =================
- | ======= ESP ======= |
- | | | |
- Host-A Gateway-A Host-B
- fec0:0:0:1::1 ---- fec0:0:0:2::1 ---- fec0:0:0:2::2
-
-Configuration at Host-A:
-
- # setkey -c <<EOF
- spdadd fec0:0:0:1::1[any] fec0:0:0:2::2[80] tcp -P out ipsec
- esp/transport/fec0:0:0:1::1-fec0:0:0:2::2/use
- esp/tunnel/fec0:0:0:1::1-fec0:0:0:2::1/require ;
- spdadd fec0:0:0:2::1[80] fec0:0:0:1::1[any] tcp -P in ipsec
- esp/transport/fec0:0:0:2::2-fec0:0:0:l::1/use
- esp/tunnel/fec0:0:0:2::1-fec0:0:0:1::1/require ;
- add fec0:0:0:1::1 fec0:0:0:2::2 esp 0x10001
- -m transport
- -E cast128-cbc "12341234"
- -A hmac-sha1 "this is the test key" ;
- add fec0:0:0:1::1 fec0:0:0:2::1 esp 0x10002
- -E rc5-cbc "kamekame"
- -A hmac-md5 "this is the test" ;
- add fec0:0:0:2::2 fec0:0:0:1::1 esp 0x10003
- -m transport
- -E cast128-cbc "12341234"
- -A hmac-sha1 "this is the test key" ;
- add fec0:0:0:2::1 fec0:0:0:1::1 esp 0x10004
- -E rc5-cbc "kamekame"
- -A hmac-md5 "this is the test" ;
-
<<<EDNS0>>>
EDNS0 is defined in RFC2671. With EDNS0, the resolver library can tell DNS
@@ -660,4 +518,12 @@ Caveats:
- Some of our platforms do not use our extended resolver code in libinet6.
See COVERAGE for detail.
+
+<<Further readings>>
+
+http://www.netbsd.org/Documentation/network/ipv6/
+ Even if you are on non-netbsd operating system, the URL should be
+ useful.
+http://www.kame.net/
+
<end of USAGE>
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.
OpenPOWER on IntegriCloud