1,4d0
< # NOTE: this is from original KAME distribution.
< # Some portion of this document is not applicable to the code merged into
< # FreeBSD-current (for example, section 5).
<
10c6
< $FreeBSD: head/share/doc/IPv6/IMPLEMENTATION 121071 2003-10-13 14:57:41Z ume $
---
> $FreeBSD: head/share/doc/IPv6/IMPLEMENTATION 122115 2003-11-05 12:00:32Z ume $
11a8,91
> NOTE: The document tries to describe behaviors/implementation choices
> of the latest KAME/*BSD stack (like KAME/NetBSD 1.5.1). The description
> here may not be applicable to KAME-integrated *BSD releases (like stock
> NetBSD 1.5.1), as we have certain amount of changes between them. Still,
> some of the content can be useful for KAME-integrated *BSD releases.
>
> Table of Contents
>
> 1. IPv6
> 1.1 Conformance
> 1.2 Neighbor Discovery
> 1.3 Scope Zone Index
> 1.3.1 Kernel internal
> 1.3.2 Interaction with API
> 1.3.3 Interaction with users (command line)
> 1.4 Plug and Play
> 1.4.1 Assignment of link-local, and special addresses
> 1.4.2 Stateless address autoconfiguration on hosts
> 1.4.3 DHCPv6
> 1.5 Generic tunnel interface
> 1.6 Address Selection
> 1.6.1 Source Address Selection
> 1.6.2 Destination Address Ordering
> 1.7 Jumbo Payload
> 1.8 Loop prevention in header processing
> 1.9 ICMPv6
> 1.10 Applications
> 1.11 Kernel Internals
> 1.12 IPv4 mapped address and IPv6 wildcard socket
> 1.12.1 KAME/BSDI3 and KAME/FreeBSD228
> 1.12.2 KAME/FreeBSD[34]x
> 1.12.2.1 KAME/FreeBSD[34]x, listening side
> 1.12.2.2 KAME/FreeBSD[34]x, initiating side
> 1.12.3 KAME/NetBSD
> 1.12.3.1 KAME/NetBSD, listening side
> 1.12.3.2 KAME/NetBSD, initiating side
> 1.12.4 KAME/BSDI4
> 1.12.4.1 KAME/BSDI4, listening side
> 1.12.4.2 KAME/BSDI4, initiating side
> 1.12.5 KAME/OpenBSD
> 1.12.5.1 KAME/OpenBSD, listening side
> 1.12.5.2 KAME/OpenBSD, initiating side
> 1.12.6 More issues
> 1.12.7 Interaction with SIIT translator
> 1.13 sockaddr_storage
> 1.14 Invalid addresses on the wire
> 1.15 Node's required addresses
> 1.15.1 Host case
> 1.15.2 Router case
> 1.16 Advanced API
> 1.17 DNS resolver
> 2. Network Drivers
> 2.1 FreeBSD 2.2.x-RELEASE
> 2.2 BSD/OS 3.x
> 2.3 NetBSD
> 2.4 FreeBSD 3.x-RELEASE
> 2.5 FreeBSD 4.x-RELEASE
> 2.6 OpenBSD 2.x
> 2.7 BSD/OS 4.x
> 3. Translator
> 3.1 FAITH TCP relay translator
> 3.2 IPv6-to-IPv4 header translator
> 4. IPsec
> 4.1 Policy Management
> 4.2 Key Management
> 4.3 AH and ESP handling
> 4.4 IPComp handling
> 4.5 Conformance to RFCs and IDs
> 4.6 ECN consideration on IPsec tunnels
> 4.7 Interoperability
> 4.8 Operations with IPsec tunnel mode
> 4.8.1 RFC2401 IPsec tunnel mode approach
> 4.8.2 draft-touch-ipsec-vpn approach
> 5. ALTQ
> 6. Mobile IPv6
> 6.1 KAME node as correspondent node
> 6.2 KAME node as home agent/mobile node
> 6.3 Old Mobile IPv6 code
> 7. Routing table extensions
> 7.1 ART routing table lookup algorithm
> 7.2 Multipath routing support
> 8. Coding style
> 9. Policy on technology with intellectual property right restriction
>
39c119
< * For supported library functions/kernel APIs, see sys/netinet6/ADVAPI.
---
> * see RFC3542
58c138
< * See 1.8 in this document for details.
---
> * See 1.9 in this document for details.
72,79c152
< RFC2553: Basic Socket Interface Extensions for IPv6
< * IPv4 mapped address (3.7) and special behavior of IPv6 wildcard bind
< socket (3.8) are,
< - supported and turned on by default on KAME/FreeBSD[34]x
< and KAME/BSDI4,
< - 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.
---
> RFC2553: (see RFC3493)
113,126c186,202
< 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-rfc2553bis-03.txt:
< Basic Socket Interface Extensions for IPv6 (revised)
< draft-ietf-ipngwg-rfc2292bis-02.txt:
< Advanced Sockets API for IPv6 (revised)
---
> RFC3152: Delegation of IP6.ARPA
> * libinet6 resolvers contained in the KAME snaps support to use
> the ip6.arpa domain (with the nibble format) for IPv6 reverse
> lookups.
> RFC3484: Default Address Selection for IPv6
> * the selection algorithm for both source and destination addresses
> is implemented based on the RFC, though some rules are still omitted.
> RFC3493: Basic Socket Interface Extensions for IPv6
> * IPv4 mapped address (3.7) and special behavior of IPv6 wildcard bind
> socket (3.8) are,
> - supported and turned on by default on KAME/FreeBSD[34]
> and KAME/BSDI4,
> - supported but turned off by default on KAME/NetBSD and KAME/FreeBSD5,
> - not supported on KAME/FreeBSD228, KAME/OpenBSD and KAME/BSDI3.
> see 1.12 in this document for details.
> RFC3542: Advanced Sockets API for IPv6 (revised)
> * For supported library functions/kernel APIs, see sys/netinet6/ADVAPI.
129,130c205
< draft-ietf-mobileip-ipv6-13.txt: Mobility Support in IPv6
< * See section 6.
---
> draft-ietf-ipngwg-icmp-name-lookups-09: IPv6 Name Lookups Through ICMP
150c225,227
< draft-itojun-ipv6-transition-abuse-02.txt:
---
> draft-itojun-ipv6-tcp-to-anycast-01.txt:
> Disconnecting TCP connection toward IPv6 anycast address
> draft-itojun-ipv6-transition-abuse-01.txt:
159d235
< draft-itojun-ipv6-tclass-api-02.txt: Socket API for IPv6 traffic class field
330c406
< advanced API (RFC2292 or draft-ietf-ipngwg-rfc2292bis-xx) can specify
---
> advanced API (RFC2292 or RFC3542) can specify
346,348c422,423
< 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
---
> sockaddr_in6 structure, defined in RFC2553. The KAME kernel
> interprets the sin6_scope_id field properly in order to disambiguate scoped
389c464
< syntax, as documented in draft-ietf-ipngwg-rfc2553bis-xx.txt. You can
---
> syntax, as documented in draft-ietf-ipv6-scoping-arch-xx.txt. You can
415,416c490,494
< options. Thus, we recommend you to use the extended format described
< above.
---
> options. Additionally, specifying the outgoing "interface" is in
> theory an overspecification as a way to specify the outgoing "link"
> (see above). Thus, we recommend you to use the extended format
> described above. This should apply to the case where the outgoing
> interface is specified.
559c637
< 1.6 Source Address Selection
---
> 1.6 Address Selection
561,567c639
< KAME's source address selection takes care of the following
< conditions:
< - address scope
< - outgoing interface
< - whether an address is deprecated
< - whether an address is temporary (in terms of RFC 3041)
< - prefix matching against the destination
---
> 1.6.1 Source Address Selection
569,582c641,642
< 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.
< - 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.
---
> The KAME kernel chooses the source address for an outgoing packet
> sent from a user application as follows:
584,595c644,647
< For instance, ::1 is selected for ff01::1,
< fe80::200:f8ff:fe01:6317%ne0 for fe80::2a0:24ff:feab:839b%ne0.
< To see how longest-matching works, suppose that
< 3ffe:501:808:1:200:f8ff:fe01:6317 and 3ffe:2001:9:124:200:f8ff:fe01:6317
< are given on the outgoing interface. Then the former is chosen as the
< source for the destination 3ffe:501:800::1. Note that even if all
< available addresses have smaller scope than the scope of the
< destination, we choose one anyway. For example, if we have link-local
< and site-local addresses only, we choose a site-local addresses for a
< global destination. If the packet is going to break a site boundary,
< the boundary router will return an ICMPv6 destination unreachable
< error with code 2 - beyond scope of source address.
---
> 1. if the source address is explicitly specified via an IPV6_PKTINFO
> ancillary data item or the socket option of that name, just use it.
> Note that this item/option overrides the bound address of the
> corresponding (datagram) socket.
597,598c649
< The precise desripction of the algorithm is quite complicated. To
< describe the algorithm, we introduce the following notation:
---
> 2. if the corresponding socket is bound, use the bound address.
600,603c651,654
< For a given destination 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.
---
> 3. otherwise, the kernel first tries to find the outgoing interface of
> the packet. If it fails, the source address selection also fails.
> If the kernel can find an interface, choose the most appropriate
> address based on the algorithm described in RFC3484.
605,607c656,660
< For a given set of addresses A,
< DEP(A): the set of deprecated addresses in A.
< nonDEP(A): A - DEP(A).
---
> The policy table used in this algorithm is stored in the kernel.
> To install or view the policy, use the ip6addrctl(8) command. The
> kernel does not have pre-installed policy. It is expected that the
> default policy described in the draft should be installed at the
> bootstrap time using this command.
609,611c662,665
< For a given set of addresses A,
< tmp(A): the set of preferred temporary-autoconfigured or
< manually-configure addresses in A.
---
> This draft allows an implementation to add implementation-specific
> rules with higher precedence than the rule "Use longest matching
> prefix." KAME's implementation has the following additional rules
> (that apply in the appeared order):
613,614c667,670
< Also, the algorithm assumes that the outgoing interface for the
< destination D is determined. We call the interface "I".
---
> - prefer addresses on alive interfaces, that is, interfaces with
> the UP flag being on. This rule is particularly useful for
> routers, since some routing daemons stop advertising prefixes
> (addresses) on interfaces that have become down.
616,618c672,674
< The algorithm is as follows. Selection proceeds step by step as
< described; For example, if an address is selected by item 1, item 2 and
< later are not considered at all.
---
> In any case, addresses that break the scope zone of the
> destination, or addresses whose zone do not contain the outgoing
> interface are never chosen.
620,662c676,677
< 0. If there is no address in the same scope zone as D, just give up;
< the packet will not be sent.
< 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.
< 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.
< 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.
---
> When the procedure above fails, the kernel usually returns
> EADDRNOTAVAIL to the application.
664,672c679,681
< There exists a document about source address selection
< (draft-ietf-ipngwg-default-addr-select-xx.txt). KAME's algorithm
< described above takes a similar approach to the document, but there
< are some differences. See the document for more details.
<
< There are some cases where we do not use the above rule. One
< example is connected TCP session, and we use the address kept in TCP
< protocol control block (tcb) as the source.
< Another example is source address for Neighbor Advertisement.
---
> In some cases, the specification explicitly requires the
> implementation to choose a particular source address. The source
> address for a Neighbor Advertisement (NA) message is an example.
674,675c683,684
< address of the corresponding NS's target. In this case we follow
< the spec rather than the above longest-match rule.
---
> address of the corresponding NS's target. In this case we follow the
> spec rather than the above rule.
682a692,709
> As documented in the source address selection document, temporary
> addresses for privacy extension are less preferred to public addresses
> by default. However, for administrators who are particularly aware of
> the privacy, there is a system-wide sysctl(3) variable
> "net.inet6.ip6.prefer_tempaddr". When the variable is set to
> non-zero, the kernel will rather prefer temporary addresses. The
> default value of this variable is 0.
>
> 1.6.2 Destination Address Ordering
>
> KAME's getaddrinfo(3) supports the destination address ordering
> algorithm described in RFC3484. Getaddrinfo(3) needs to know the
> source address for each destination address and policy entries
> (described in the previous section) for the source and destination
> addresses. To get the source address, the library function opens a
> UDP socket and tries to connect(2) for the destination. To get the
> policy entry, the function issues sysctl(3).
>
870c897
< RFC2553 describes IPv4 mapped address (3.7) and special behavior
---
> RFC2553/3493 describes IPv4 mapped address (3.7) and special behavior
907c934
< It looks that RFC2553 talks too little on wildcard bind issue,
---
> It looks that RFC2553/3493 talks too little on wildcard bind issue,
952c979
< as documented in RFC2553 6.1. KAME libinet6 includes the tweak in
---
> as documented in RFC2553/3493 6.1. KAME libinet6 includes the tweak in
971c998
< to RFC2553 section 3.7 and 3.8. It is due to code sharing reasons.
---
> to RFC2553/3493 section 3.7 and 3.8. It is due to code sharing reasons.
1010,1011c1037,1038
< conformant to RFC2553 section 3.8. It is intentionally turned off by default
< for security reasons.
---
> conformant to RFC2553/3493 section 3.8. It is intentionally turned off by
> default for security reasons.
1013,1014d1039
< 1.12.3.1 KAME/NetBSD, listening side
<
1021c1046
< - add "INET6_V6ONLY": No special support code for AF_INET6 wildcard socket
---
> - add "INET6_BINDV6ONLY": No special support code for AF_INET6 wildcard socket
1030a1056,1057
> 1.12.3.1 KAME/NetBSD, listening side
>
1042,1045c1069,1071
< When you initiate a connection, you can always connect to IPv4 destination
< over AF_INET6 socket, usin IPv4 mapped address destination (::ffff:10.1.1.1).
< This is enabled independently from the configuration for listening side, and
< always enabled.
---
> When getsockopt(IPV6_V6ONLY) is 0 for a socket, you can make an outgoing
> traffic to IPv4 destination over AF_INET6 socket, using IPv4 mapped
> address destination (::ffff:10.1.1.1).
1046a1073,1075
> When getsockopt(IPV6_V6ONLY) is 1 for a socket, you cannot use IPv4 mapped
> address for outgoing traffic.
>
1073,1074c1102,1103
< 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.
---
> It should be noted that KAME/OpenBSD is not conformant to RFC2553/3493 section
> 3.7 and 3.8. It is intentionally omitted for security reasons.
1127c1156,1158
< draft-itojun-ipv6-transition-abuse-01.txt talks more about this scenario.
---
> draft-itojun-ipv6-transition-abuse-01.txt, draft-cmetz-v6ops-v4mapped-api-
> harmful-00.txt, and draft-itojun-v6ops-v4mapped-harmful-01.txt
> has more on this scenario.
1183,1184c1214,1215
< In December 1999, it was agreed that RFC2553bis should pick the latter (XNET)
< definition.
---
> In December 1999, it was agreed that RFC2553bis (RFC3493) should pick the
> latter (XNET) definition.
1188c1219
< based on RFC2553bis discussion.
---
> based on RFC3493 discussion.
1254c1285,1287
< draft-itojun-ipv6-transition-abuse-01.txt talks about more about this.
---
> draft-itojun-ipv6-transition-abuse-01.txt, draft-cmetz-v6ops-v4mapped-api-
> harmful-00.txt and draft-itojun-v6ops-v4mapped-harmful-01.txt has more on
> this issue.
1303,1304c1336
< Current KAME kernel implements 2292bis API, documented in
< draft-ietf-ipngwg-rfc2292bis-xx.txt. It also implements RFC2292 API,
---
> Current KAME kernel implements RFC3542 API. It also implements RFC2292 API,
1306,1307c1338,1339
< KAME tree ships with 2292bis headers.
< *BSD-integrated codebase implements either RFC2292, or 2292bis, API.
---
> KAME tree ships with RFC3542 headers.
> *BSD-integrated codebase implements either RFC2292, or RFC3542, API.
1313c1345
< - KAME binaries, compiled using 2292bis, will not work on *BSD-integrated
---
> - KAME binaries, compiled using RFC3542, will not work on *BSD-integrated
1316c1348
< - 2292bis API is not compatible with RFC2292 API. 2292bis #define symbols
---
> - RFC3542 API is not compatible with RFC2292 API. RFC3542 #define symbols
1320c1352
< issue. For example, Solaris 8 implements 2292bis API. If you compile
---
> issue. For example, Solaris 8 implements RFC3542 API. If you compile
1329c1361
< strict/loose bitmap. 2292bis document is based on RFC2460 IPv6, and it has
---
> strict/loose bitmap. RFC3542 document is based on RFC2460 IPv6, and it has
1332a1365,1383
> The RFC3542 documents leave some particular cases unspecified. The
> KAME implementation treats them as follows:
> - The IPV6_DONTFRAG and IPV6_RECVPATHMTU socket options for TCP
> sockets are ignored. That is, the setsocktopt() call will succeed
> but the specified value will have no effect.
>
> 1.17 DNS resolver
>
> KAME ships with modified DNS resolver, in libinet6.a.
> libinet6.a has a comple of extensions against libc DNS resolver:
> - Can take "options insecure1" and "options insecure2" in /etc/resolv.conf,
> which toggles RES_INSECURE[12] option flag bit.
> - EDNS0 receive buffer size notification support. It can be enabled by
> "options edns0" in /etc/resolv.conf. See USAGE for details.
> - IPv6 transport support (queries/responses over IPv6). Most of BSD official
> releases now has it already.
> - Partial A6 chain chasing/DNAME/bit string label support (KAME/BSDI4).
>
>
1337,1339c1388,1390
< (1) mbuf clustering requirement. In this stable release, we changed
< MINCLSIZE into MHLEN+1 for all the operating systems in order to make
< all the drivers behave as we expect.
---
> (1) (freebsd[234] and bsdi[34] only) mbuf clustering requirement.
> In this stable release, we changed MINCLSIZE into MHLEN+1 for all the
> operating systems in order to make all the drivers behave as we expect.
1573c1624
< The kernel implements experimental policy management code. There are two way
---
> The kernel implements experimental policy management code. There are two ways
1599c1650,1651
< Racoon follows the former route.
---
> Racoon follows the latter route (previously it followed the former, and
> the latter interpretation seems to be popular/consensus).
1601a1654,1656
> racoon does not implement byte lifetime for both phase 1 and phase 2
> (RFC2409 page 35, Life Type = kilobytes).
>
1704,1707c1759
< 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
---
> rfc240[1-6].txt rfc241[01].txt rfc2451.txt rfc3602.txt
1846a1899,2024
> 4.8 Operations with IPsec tunnel mode
>
> First of all, IPsec tunnel is a very hairy thing. It seems to do a neat thing
> like VPN configuration or secure remote accesses, however, it comes with lots
> of architectural twists.
>
> RFC2401 defines IPsec tunnel mode, within the context of IPsec. RFC2401
> defines tunnel mode packet encapsulation/decapsulation on its own, and
> does not refer other tunnelling specifications. Since RFC2401 advocates
> filter-based SPD database matches, it would be natural for us to implement
> IPsec IPsec tunnel mode as filters - not as pseudo interfaces.
>
> There are some people who are trying to separate IPsec "tunnel mode" from
> the IPsec itself. They would like to implement IPsec transport mode only,
> and combine it with tunneling pseudo devices. The prime example is found
> in draft-touch-ipsec-vpn-01.txt. However, if you really define pseudo
> interfaces separately from IPsec, IKE daemons would need to negotiate
> transport mode SAs, instead of tunnel mode SAs. Therefore, we cannot
> really mix RFC2401-based interpretation and draft-touch-ipsec-vpn-01.txt
> interpretation.
>
> The KAME stack implements can be configured in two ways. You may need
> to recompile your kernel to switch the behavior.
> - RFC2401 IPsec tunnel mode appraoch (4.8.1)
> - draft-touch-ipsec-vpn approach (4.8.2)
> Works in all kernel configuration, but racoon(8) may not interoperate.
>
> There are pros and cons on these approaches:
>
> RFC2401 IPsec tunnel mode (filter-like) approach
> PRO: SPD lookup fits nicely with packet filters (if you integrate them)
> CON: cannot run routing daemons across IPsec tunnels
> CON: it is very hard to control source address selection on originating
> cases
> ???: IPv6 scope zone is kept the same
> draft-touch-ipsec-vpn (transportmode + Pseudo-interface) approach
> PRO: run routing daemons across IPsec tunnels
> PRO: source address selection can be done normally, by looking at
> IPsec tunnel pseudo devices
> CON: on outbound, possibility of infinite loops if routing setup
> is wrong
> CON: due to differences in encap/decap logic from RFC2401, it may not
> interoperate with very picky RFC2401 implementations
> (those who check TOS bits, for example)
> CON: cannot negotiate IKE with other IPsec tunnel-mode devices
> (the other end has to implement
> ???: IPv6 scope zone is likely to be different from the real ethernet
> interface
>
> The recommendation is different depending on the situation you have:
> - use draft-touch-ipsec-vpn if you have the control over the other end.
> this one is the best in terms of simplicity.
> - if the other end is normal IPsec device with RFC2401 implementation,
> you need to use RFC2401, otherwise you won't be able to run IKE.
> - use RFC2401 approach if you just want to forward packets back and forth
> and there's no plan to use IPsec gateway itself as an originating device.
>
> 4.8.1 RFC2401 IPsec tunnel mode approach
>
> To configure your device as RFC2401 IPsec tunnel mode endpoint, you will
> use "tunnel" keyword in setkey(8) "spdadd" directives. Let us assume the
> following topology (A and B could be a network, like prefix/length):
>
> ((((((((((((The internet))))))))))))
> | |
> |C (global) |D
> your device peer's device
> |A (private) |B
> ==+===== VPN net ==+===== VPN net
>
> The policy configuration directive is like this. You will need manual
> SAs, or IKE daemon, for actual encryption:
>
> # setkey -c <<EOF
> spdadd A B any -P out ipsec esp/tunnel/C-D/use;
> spdadd B A any -P in ipsec esp/tunnel/D-C/use;
> ^D
>
> The inbound/outbound traffic is monitored/captured by SPD engine, which works
> just like packet filters.
>
> With this, forwarding case should work flawlessly. However, troubles arise
> when you have one of the following requirements:
> - When you originate traffic from your VPN gateway device to VPN net on the
> other end (like B), you want your source address to be A (private side)
> so that the traffic would be protected by the policy.
> With this approach, however, the source address selection logic follows
> normal routing table, and C (global side) will be picked for any outgoing
> traffic, even if the destination is B. The resulting packet will be like
> this:
> IP[C -> B] payload
> and will not match the policy (= sent in clear).
> - When you want to run routing protocols on top of the IPsec tunnel, it is
> not possible. As there is no pseudo device that identifies the IPsec tunnel,
> you cannot identify where the routing information came from. As a result,
> you can't run routing daemons.
>
> 4.8.2 draft-touch-ipsec-vpn approach
>
> With this approach, you will configure gif(4) tunnel interfaces, as well as
> IPsec transport mode SAs.
>
> # gifconfig gif0 C D
> # ifconfig gif0 A B
> # setkey -c <<EOF
> spdadd C D any -P out ipsec esp/transport//use;
> spdadd D C any -P in ipsec esp/transport//use;
> ^D
>
> Since we have a pseudo-interface "gif0", and it affects the routes and
> the source address selection logic, we can have source address A, for
> packets originated by the VPN gateway to B (and the VPN cloud).
> We can also exchange routing information over the tunnel (gif0), as the tunnel
> is represented as a pseudo interface (dynamic routes points to the
> pseudo interface).
>
> There is a big drawbacks, however; with this, you can use IKE if and only if
> the other end is using draft-touch-ipsec-vpn approach too. Since racoon(8)
> grabs phase 2 IKE proposals from the kernel SPD database, you will be
> negotiating IPsec transport-mode SAs with the other end, not tunnel-mode SAs.
> Also, since the encapsulation mechanism is different from RFC2401, you may not
> be able to interoperate with a picky RFC2401 implementations - if the other
> end checks certain outer IP header fields (like TOS), you will not be able to
> interoperate.
>
>
1894a2073
> - follow *BSD KNF where possible. note: there are multiple KNF standards.
1896a2076,2086
> With GNU Emacs 20 and later, the easiest way is to use the "bsd" style of
> cc-mode with the variable "c-basic-offset" being 8;
> (add-hook 'c-mode-common-hook
> (function
> (lambda ()
> (c-set-style "bsd")
> (setq c-basic-offset 8) ; XXX for Emacs 20 only
> )))
> The "bsd" style in GNU Emacs 21 sets the variable to 8 by default,
> so the line marked by "XXX" is not necessary if you only use GNU
> Emacs 21.
1908c2098
< (this is for C. For other language, you should use its own comment
---
> (this is for C. For other language, you should use its own comment
1917a2108,2137
> - it is recommended to always wrap an expression containing
> bitwise operators by parentheses, especially when the expression is
> combined with relational operators, in order to avoid unintentional
> mismatch of operators. Thus, we should write
> if ((a & b) == 0) /* (A) */
> or
> if (a & (b == 0)) /* (B) */
> instead of
> if (a & b == 0) /* (C) */
> even if the programmer's intention was (C), which is equivalent to
> (B) according to the grammar of the language C.
> Thus, we should write a code to test if a bit-flag is set for a
> given variable as follows:
> if ((flag & FLAG_A) == 0) /* (D) the FLAG_A is NOT set */
> if ((flag & FLAG_A) != 0) /* (E) the FLAG_A is set */
> Some developers in the KAME project rather prefer the following style:
> if (!(flag & FLAG_A)) /* (F) the FLAG_A is NOT set */
> if ((flag & FLAG_A)) /* (G) the FLAG_A is set */
> because it would be more intuitive in terms of the relationship
> between the negation operator (!) and the semantics of the
> condition. The KAME developers have discussed the style, and have
> agreed that all the styles from (D) to (G) are valid. So, when you
> see styles like (D) and (E) in the KAME code and feel a bit strange,
> please just keep them. They are intentional.
> - When inserting a separate block just to define some intra-block
> variables, add the level of indentation as if the block was in a
> control statement such as if-else, for, or while. For example,
> foo ()
> {
> int a;
1918a2139,2163
> {
> int internal_a;
> ...
> }
> }
> should be used, instead of
> foo ()
> {
> int a;
>
> {
> int internal_a;
> ...
> }
> }
> - Do not use printf() or log() in the packet input path of the kernel code.
> They can make the system vulnerable to packet flooding attacks (results in
> /var overflow).
> - (not a style issue)
> To disable a module that is mistakenly imported (by CVS), just
> remove the source tree in the repository. Note, however, that the
> removal might annoy other developers who have already checked the
> module out, so you should announce the removal as soon as possible.
> Also, be 100% sure not to remove other modules.
>
1924a2170,2197
>
> 9. Policy on technology with intellectual property right restriction
>
> There are quite a few IETF documents/whatever which has intellectual property
> right (IPR) restriction. KAME's stance is stated below.
>
> The goal of KAME is to provide freely redistributable, BSD-licensed,
> implementation of Internet protocol technologies.
> For this purpose, we implement protocols that (1) do not need license
> contract with IPR holder, and (2) are royalty-free.
> The reason for (1) is, even if KAME contracts with the IPR holder in
> question, the users of KAME stack (usually implementers of some other
> codebase) would need to make a license contract with the IPR holder.
> It would damage the "freely redistributable" status of KAME codebase.
>
> By doing so KAME is (implicitly) trying to advocate no-license-contract,
> royalty-free, release of IPRs.
>
> Note however, as documented in README, we do not guarantee that KAME code
> is free of IPR infringement, you MUST check it if you are to integrate
> KAME into your product (or whatever):
> READ CAREFULLY: Several countries have legal enforcement for
> export/import/use of cryptographic software. Check it before playing
> with the kit. We do not intend to be your legalease clearing house
> (NO WARRANTY). If you intend to include KAME stack into your product,
> you'll need to check if the licenses on each file fit your situations,
> and/or possible intellectual property right issues.
>
< # NOTE: this is from original KAME distribution.
< # Some portion of this document is not applicable to the code merged into
< # FreeBSD-current (for example, section 5).
<
10c6
< $FreeBSD: head/share/doc/IPv6/IMPLEMENTATION 121071 2003-10-13 14:57:41Z ume $
---
> $FreeBSD: head/share/doc/IPv6/IMPLEMENTATION 122115 2003-11-05 12:00:32Z ume $
11a8,91
> NOTE: The document tries to describe behaviors/implementation choices
> of the latest KAME/*BSD stack (like KAME/NetBSD 1.5.1). The description
> here may not be applicable to KAME-integrated *BSD releases (like stock
> NetBSD 1.5.1), as we have certain amount of changes between them. Still,
> some of the content can be useful for KAME-integrated *BSD releases.
>
> Table of Contents
>
> 1. IPv6
> 1.1 Conformance
> 1.2 Neighbor Discovery
> 1.3 Scope Zone Index
> 1.3.1 Kernel internal
> 1.3.2 Interaction with API
> 1.3.3 Interaction with users (command line)
> 1.4 Plug and Play
> 1.4.1 Assignment of link-local, and special addresses
> 1.4.2 Stateless address autoconfiguration on hosts
> 1.4.3 DHCPv6
> 1.5 Generic tunnel interface
> 1.6 Address Selection
> 1.6.1 Source Address Selection
> 1.6.2 Destination Address Ordering
> 1.7 Jumbo Payload
> 1.8 Loop prevention in header processing
> 1.9 ICMPv6
> 1.10 Applications
> 1.11 Kernel Internals
> 1.12 IPv4 mapped address and IPv6 wildcard socket
> 1.12.1 KAME/BSDI3 and KAME/FreeBSD228
> 1.12.2 KAME/FreeBSD[34]x
> 1.12.2.1 KAME/FreeBSD[34]x, listening side
> 1.12.2.2 KAME/FreeBSD[34]x, initiating side
> 1.12.3 KAME/NetBSD
> 1.12.3.1 KAME/NetBSD, listening side
> 1.12.3.2 KAME/NetBSD, initiating side
> 1.12.4 KAME/BSDI4
> 1.12.4.1 KAME/BSDI4, listening side
> 1.12.4.2 KAME/BSDI4, initiating side
> 1.12.5 KAME/OpenBSD
> 1.12.5.1 KAME/OpenBSD, listening side
> 1.12.5.2 KAME/OpenBSD, initiating side
> 1.12.6 More issues
> 1.12.7 Interaction with SIIT translator
> 1.13 sockaddr_storage
> 1.14 Invalid addresses on the wire
> 1.15 Node's required addresses
> 1.15.1 Host case
> 1.15.2 Router case
> 1.16 Advanced API
> 1.17 DNS resolver
> 2. Network Drivers
> 2.1 FreeBSD 2.2.x-RELEASE
> 2.2 BSD/OS 3.x
> 2.3 NetBSD
> 2.4 FreeBSD 3.x-RELEASE
> 2.5 FreeBSD 4.x-RELEASE
> 2.6 OpenBSD 2.x
> 2.7 BSD/OS 4.x
> 3. Translator
> 3.1 FAITH TCP relay translator
> 3.2 IPv6-to-IPv4 header translator
> 4. IPsec
> 4.1 Policy Management
> 4.2 Key Management
> 4.3 AH and ESP handling
> 4.4 IPComp handling
> 4.5 Conformance to RFCs and IDs
> 4.6 ECN consideration on IPsec tunnels
> 4.7 Interoperability
> 4.8 Operations with IPsec tunnel mode
> 4.8.1 RFC2401 IPsec tunnel mode approach
> 4.8.2 draft-touch-ipsec-vpn approach
> 5. ALTQ
> 6. Mobile IPv6
> 6.1 KAME node as correspondent node
> 6.2 KAME node as home agent/mobile node
> 6.3 Old Mobile IPv6 code
> 7. Routing table extensions
> 7.1 ART routing table lookup algorithm
> 7.2 Multipath routing support
> 8. Coding style
> 9. Policy on technology with intellectual property right restriction
>
39c119
< * For supported library functions/kernel APIs, see sys/netinet6/ADVAPI.
---
> * see RFC3542
58c138
< * See 1.8 in this document for details.
---
> * See 1.9 in this document for details.
72,79c152
< RFC2553: Basic Socket Interface Extensions for IPv6
< * IPv4 mapped address (3.7) and special behavior of IPv6 wildcard bind
< socket (3.8) are,
< - supported and turned on by default on KAME/FreeBSD[34]x
< and KAME/BSDI4,
< - 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.
---
> RFC2553: (see RFC3493)
113,126c186,202
< 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-rfc2553bis-03.txt:
< Basic Socket Interface Extensions for IPv6 (revised)
< draft-ietf-ipngwg-rfc2292bis-02.txt:
< Advanced Sockets API for IPv6 (revised)
---
> RFC3152: Delegation of IP6.ARPA
> * libinet6 resolvers contained in the KAME snaps support to use
> the ip6.arpa domain (with the nibble format) for IPv6 reverse
> lookups.
> RFC3484: Default Address Selection for IPv6
> * the selection algorithm for both source and destination addresses
> is implemented based on the RFC, though some rules are still omitted.
> RFC3493: Basic Socket Interface Extensions for IPv6
> * IPv4 mapped address (3.7) and special behavior of IPv6 wildcard bind
> socket (3.8) are,
> - supported and turned on by default on KAME/FreeBSD[34]
> and KAME/BSDI4,
> - supported but turned off by default on KAME/NetBSD and KAME/FreeBSD5,
> - not supported on KAME/FreeBSD228, KAME/OpenBSD and KAME/BSDI3.
> see 1.12 in this document for details.
> RFC3542: Advanced Sockets API for IPv6 (revised)
> * For supported library functions/kernel APIs, see sys/netinet6/ADVAPI.
129,130c205
< draft-ietf-mobileip-ipv6-13.txt: Mobility Support in IPv6
< * See section 6.
---
> draft-ietf-ipngwg-icmp-name-lookups-09: IPv6 Name Lookups Through ICMP
150c225,227
< draft-itojun-ipv6-transition-abuse-02.txt:
---
> draft-itojun-ipv6-tcp-to-anycast-01.txt:
> Disconnecting TCP connection toward IPv6 anycast address
> draft-itojun-ipv6-transition-abuse-01.txt:
159d235
< draft-itojun-ipv6-tclass-api-02.txt: Socket API for IPv6 traffic class field
330c406
< advanced API (RFC2292 or draft-ietf-ipngwg-rfc2292bis-xx) can specify
---
> advanced API (RFC2292 or RFC3542) can specify
346,348c422,423
< 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
---
> sockaddr_in6 structure, defined in RFC2553. The KAME kernel
> interprets the sin6_scope_id field properly in order to disambiguate scoped
389c464
< syntax, as documented in draft-ietf-ipngwg-rfc2553bis-xx.txt. You can
---
> syntax, as documented in draft-ietf-ipv6-scoping-arch-xx.txt. You can
415,416c490,494
< options. Thus, we recommend you to use the extended format described
< above.
---
> options. Additionally, specifying the outgoing "interface" is in
> theory an overspecification as a way to specify the outgoing "link"
> (see above). Thus, we recommend you to use the extended format
> described above. This should apply to the case where the outgoing
> interface is specified.
559c637
< 1.6 Source Address Selection
---
> 1.6 Address Selection
561,567c639
< KAME's source address selection takes care of the following
< conditions:
< - address scope
< - outgoing interface
< - whether an address is deprecated
< - whether an address is temporary (in terms of RFC 3041)
< - prefix matching against the destination
---
> 1.6.1 Source Address Selection
569,582c641,642
< 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.
< - 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.
---
> The KAME kernel chooses the source address for an outgoing packet
> sent from a user application as follows:
584,595c644,647
< For instance, ::1 is selected for ff01::1,
< fe80::200:f8ff:fe01:6317%ne0 for fe80::2a0:24ff:feab:839b%ne0.
< To see how longest-matching works, suppose that
< 3ffe:501:808:1:200:f8ff:fe01:6317 and 3ffe:2001:9:124:200:f8ff:fe01:6317
< are given on the outgoing interface. Then the former is chosen as the
< source for the destination 3ffe:501:800::1. Note that even if all
< available addresses have smaller scope than the scope of the
< destination, we choose one anyway. For example, if we have link-local
< and site-local addresses only, we choose a site-local addresses for a
< global destination. If the packet is going to break a site boundary,
< the boundary router will return an ICMPv6 destination unreachable
< error with code 2 - beyond scope of source address.
---
> 1. if the source address is explicitly specified via an IPV6_PKTINFO
> ancillary data item or the socket option of that name, just use it.
> Note that this item/option overrides the bound address of the
> corresponding (datagram) socket.
597,598c649
< The precise desripction of the algorithm is quite complicated. To
< describe the algorithm, we introduce the following notation:
---
> 2. if the corresponding socket is bound, use the bound address.
600,603c651,654
< For a given destination 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.
---
> 3. otherwise, the kernel first tries to find the outgoing interface of
> the packet. If it fails, the source address selection also fails.
> If the kernel can find an interface, choose the most appropriate
> address based on the algorithm described in RFC3484.
605,607c656,660
< For a given set of addresses A,
< DEP(A): the set of deprecated addresses in A.
< nonDEP(A): A - DEP(A).
---
> The policy table used in this algorithm is stored in the kernel.
> To install or view the policy, use the ip6addrctl(8) command. The
> kernel does not have pre-installed policy. It is expected that the
> default policy described in the draft should be installed at the
> bootstrap time using this command.
609,611c662,665
< For a given set of addresses A,
< tmp(A): the set of preferred temporary-autoconfigured or
< manually-configure addresses in A.
---
> This draft allows an implementation to add implementation-specific
> rules with higher precedence than the rule "Use longest matching
> prefix." KAME's implementation has the following additional rules
> (that apply in the appeared order):
613,614c667,670
< Also, the algorithm assumes that the outgoing interface for the
< destination D is determined. We call the interface "I".
---
> - prefer addresses on alive interfaces, that is, interfaces with
> the UP flag being on. This rule is particularly useful for
> routers, since some routing daemons stop advertising prefixes
> (addresses) on interfaces that have become down.
616,618c672,674
< The algorithm is as follows. Selection proceeds step by step as
< described; For example, if an address is selected by item 1, item 2 and
< later are not considered at all.
---
> In any case, addresses that break the scope zone of the
> destination, or addresses whose zone do not contain the outgoing
> interface are never chosen.
620,662c676,677
< 0. If there is no address in the same scope zone as D, just give up;
< the packet will not be sent.
< 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.
< 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.
< 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.
---
> When the procedure above fails, the kernel usually returns
> EADDRNOTAVAIL to the application.
664,672c679,681
< There exists a document about source address selection
< (draft-ietf-ipngwg-default-addr-select-xx.txt). KAME's algorithm
< described above takes a similar approach to the document, but there
< are some differences. See the document for more details.
<
< There are some cases where we do not use the above rule. One
< example is connected TCP session, and we use the address kept in TCP
< protocol control block (tcb) as the source.
< Another example is source address for Neighbor Advertisement.
---
> In some cases, the specification explicitly requires the
> implementation to choose a particular source address. The source
> address for a Neighbor Advertisement (NA) message is an example.
674,675c683,684
< address of the corresponding NS's target. In this case we follow
< the spec rather than the above longest-match rule.
---
> address of the corresponding NS's target. In this case we follow the
> spec rather than the above rule.
682a692,709
> As documented in the source address selection document, temporary
> addresses for privacy extension are less preferred to public addresses
> by default. However, for administrators who are particularly aware of
> the privacy, there is a system-wide sysctl(3) variable
> "net.inet6.ip6.prefer_tempaddr". When the variable is set to
> non-zero, the kernel will rather prefer temporary addresses. The
> default value of this variable is 0.
>
> 1.6.2 Destination Address Ordering
>
> KAME's getaddrinfo(3) supports the destination address ordering
> algorithm described in RFC3484. Getaddrinfo(3) needs to know the
> source address for each destination address and policy entries
> (described in the previous section) for the source and destination
> addresses. To get the source address, the library function opens a
> UDP socket and tries to connect(2) for the destination. To get the
> policy entry, the function issues sysctl(3).
>
870c897
< RFC2553 describes IPv4 mapped address (3.7) and special behavior
---
> RFC2553/3493 describes IPv4 mapped address (3.7) and special behavior
907c934
< It looks that RFC2553 talks too little on wildcard bind issue,
---
> It looks that RFC2553/3493 talks too little on wildcard bind issue,
952c979
< as documented in RFC2553 6.1. KAME libinet6 includes the tweak in
---
> as documented in RFC2553/3493 6.1. KAME libinet6 includes the tweak in
971c998
< to RFC2553 section 3.7 and 3.8. It is due to code sharing reasons.
---
> to RFC2553/3493 section 3.7 and 3.8. It is due to code sharing reasons.
1010,1011c1037,1038
< conformant to RFC2553 section 3.8. It is intentionally turned off by default
< for security reasons.
---
> conformant to RFC2553/3493 section 3.8. It is intentionally turned off by
> default for security reasons.
1013,1014d1039
< 1.12.3.1 KAME/NetBSD, listening side
<
1021c1046
< - add "INET6_V6ONLY": No special support code for AF_INET6 wildcard socket
---
> - add "INET6_BINDV6ONLY": No special support code for AF_INET6 wildcard socket
1030a1056,1057
> 1.12.3.1 KAME/NetBSD, listening side
>
1042,1045c1069,1071
< When you initiate a connection, you can always connect to IPv4 destination
< over AF_INET6 socket, usin IPv4 mapped address destination (::ffff:10.1.1.1).
< This is enabled independently from the configuration for listening side, and
< always enabled.
---
> When getsockopt(IPV6_V6ONLY) is 0 for a socket, you can make an outgoing
> traffic to IPv4 destination over AF_INET6 socket, using IPv4 mapped
> address destination (::ffff:10.1.1.1).
1046a1073,1075
> When getsockopt(IPV6_V6ONLY) is 1 for a socket, you cannot use IPv4 mapped
> address for outgoing traffic.
>
1073,1074c1102,1103
< 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.
---
> It should be noted that KAME/OpenBSD is not conformant to RFC2553/3493 section
> 3.7 and 3.8. It is intentionally omitted for security reasons.
1127c1156,1158
< draft-itojun-ipv6-transition-abuse-01.txt talks more about this scenario.
---
> draft-itojun-ipv6-transition-abuse-01.txt, draft-cmetz-v6ops-v4mapped-api-
> harmful-00.txt, and draft-itojun-v6ops-v4mapped-harmful-01.txt
> has more on this scenario.
1183,1184c1214,1215
< In December 1999, it was agreed that RFC2553bis should pick the latter (XNET)
< definition.
---
> In December 1999, it was agreed that RFC2553bis (RFC3493) should pick the
> latter (XNET) definition.
1188c1219
< based on RFC2553bis discussion.
---
> based on RFC3493 discussion.
1254c1285,1287
< draft-itojun-ipv6-transition-abuse-01.txt talks about more about this.
---
> draft-itojun-ipv6-transition-abuse-01.txt, draft-cmetz-v6ops-v4mapped-api-
> harmful-00.txt and draft-itojun-v6ops-v4mapped-harmful-01.txt has more on
> this issue.
1303,1304c1336
< Current KAME kernel implements 2292bis API, documented in
< draft-ietf-ipngwg-rfc2292bis-xx.txt. It also implements RFC2292 API,
---
> Current KAME kernel implements RFC3542 API. It also implements RFC2292 API,
1306,1307c1338,1339
< KAME tree ships with 2292bis headers.
< *BSD-integrated codebase implements either RFC2292, or 2292bis, API.
---
> KAME tree ships with RFC3542 headers.
> *BSD-integrated codebase implements either RFC2292, or RFC3542, API.
1313c1345
< - KAME binaries, compiled using 2292bis, will not work on *BSD-integrated
---
> - KAME binaries, compiled using RFC3542, will not work on *BSD-integrated
1316c1348
< - 2292bis API is not compatible with RFC2292 API. 2292bis #define symbols
---
> - RFC3542 API is not compatible with RFC2292 API. RFC3542 #define symbols
1320c1352
< issue. For example, Solaris 8 implements 2292bis API. If you compile
---
> issue. For example, Solaris 8 implements RFC3542 API. If you compile
1329c1361
< strict/loose bitmap. 2292bis document is based on RFC2460 IPv6, and it has
---
> strict/loose bitmap. RFC3542 document is based on RFC2460 IPv6, and it has
1332a1365,1383
> The RFC3542 documents leave some particular cases unspecified. The
> KAME implementation treats them as follows:
> - The IPV6_DONTFRAG and IPV6_RECVPATHMTU socket options for TCP
> sockets are ignored. That is, the setsocktopt() call will succeed
> but the specified value will have no effect.
>
> 1.17 DNS resolver
>
> KAME ships with modified DNS resolver, in libinet6.a.
> libinet6.a has a comple of extensions against libc DNS resolver:
> - Can take "options insecure1" and "options insecure2" in /etc/resolv.conf,
> which toggles RES_INSECURE[12] option flag bit.
> - EDNS0 receive buffer size notification support. It can be enabled by
> "options edns0" in /etc/resolv.conf. See USAGE for details.
> - IPv6 transport support (queries/responses over IPv6). Most of BSD official
> releases now has it already.
> - Partial A6 chain chasing/DNAME/bit string label support (KAME/BSDI4).
>
>
1337,1339c1388,1390
< (1) mbuf clustering requirement. In this stable release, we changed
< MINCLSIZE into MHLEN+1 for all the operating systems in order to make
< all the drivers behave as we expect.
---
> (1) (freebsd[234] and bsdi[34] only) mbuf clustering requirement.
> In this stable release, we changed MINCLSIZE into MHLEN+1 for all the
> operating systems in order to make all the drivers behave as we expect.
1573c1624
< The kernel implements experimental policy management code. There are two way
---
> The kernel implements experimental policy management code. There are two ways
1599c1650,1651
< Racoon follows the former route.
---
> Racoon follows the latter route (previously it followed the former, and
> the latter interpretation seems to be popular/consensus).
1601a1654,1656
> racoon does not implement byte lifetime for both phase 1 and phase 2
> (RFC2409 page 35, Life Type = kilobytes).
>
1704,1707c1759
< 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
---
> rfc240[1-6].txt rfc241[01].txt rfc2451.txt rfc3602.txt
1846a1899,2024
> 4.8 Operations with IPsec tunnel mode
>
> First of all, IPsec tunnel is a very hairy thing. It seems to do a neat thing
> like VPN configuration or secure remote accesses, however, it comes with lots
> of architectural twists.
>
> RFC2401 defines IPsec tunnel mode, within the context of IPsec. RFC2401
> defines tunnel mode packet encapsulation/decapsulation on its own, and
> does not refer other tunnelling specifications. Since RFC2401 advocates
> filter-based SPD database matches, it would be natural for us to implement
> IPsec IPsec tunnel mode as filters - not as pseudo interfaces.
>
> There are some people who are trying to separate IPsec "tunnel mode" from
> the IPsec itself. They would like to implement IPsec transport mode only,
> and combine it with tunneling pseudo devices. The prime example is found
> in draft-touch-ipsec-vpn-01.txt. However, if you really define pseudo
> interfaces separately from IPsec, IKE daemons would need to negotiate
> transport mode SAs, instead of tunnel mode SAs. Therefore, we cannot
> really mix RFC2401-based interpretation and draft-touch-ipsec-vpn-01.txt
> interpretation.
>
> The KAME stack implements can be configured in two ways. You may need
> to recompile your kernel to switch the behavior.
> - RFC2401 IPsec tunnel mode appraoch (4.8.1)
> - draft-touch-ipsec-vpn approach (4.8.2)
> Works in all kernel configuration, but racoon(8) may not interoperate.
>
> There are pros and cons on these approaches:
>
> RFC2401 IPsec tunnel mode (filter-like) approach
> PRO: SPD lookup fits nicely with packet filters (if you integrate them)
> CON: cannot run routing daemons across IPsec tunnels
> CON: it is very hard to control source address selection on originating
> cases
> ???: IPv6 scope zone is kept the same
> draft-touch-ipsec-vpn (transportmode + Pseudo-interface) approach
> PRO: run routing daemons across IPsec tunnels
> PRO: source address selection can be done normally, by looking at
> IPsec tunnel pseudo devices
> CON: on outbound, possibility of infinite loops if routing setup
> is wrong
> CON: due to differences in encap/decap logic from RFC2401, it may not
> interoperate with very picky RFC2401 implementations
> (those who check TOS bits, for example)
> CON: cannot negotiate IKE with other IPsec tunnel-mode devices
> (the other end has to implement
> ???: IPv6 scope zone is likely to be different from the real ethernet
> interface
>
> The recommendation is different depending on the situation you have:
> - use draft-touch-ipsec-vpn if you have the control over the other end.
> this one is the best in terms of simplicity.
> - if the other end is normal IPsec device with RFC2401 implementation,
> you need to use RFC2401, otherwise you won't be able to run IKE.
> - use RFC2401 approach if you just want to forward packets back and forth
> and there's no plan to use IPsec gateway itself as an originating device.
>
> 4.8.1 RFC2401 IPsec tunnel mode approach
>
> To configure your device as RFC2401 IPsec tunnel mode endpoint, you will
> use "tunnel" keyword in setkey(8) "spdadd" directives. Let us assume the
> following topology (A and B could be a network, like prefix/length):
>
> ((((((((((((The internet))))))))))))
> | |
> |C (global) |D
> your device peer's device
> |A (private) |B
> ==+===== VPN net ==+===== VPN net
>
> The policy configuration directive is like this. You will need manual
> SAs, or IKE daemon, for actual encryption:
>
> # setkey -c <<EOF
> spdadd A B any -P out ipsec esp/tunnel/C-D/use;
> spdadd B A any -P in ipsec esp/tunnel/D-C/use;
> ^D
>
> The inbound/outbound traffic is monitored/captured by SPD engine, which works
> just like packet filters.
>
> With this, forwarding case should work flawlessly. However, troubles arise
> when you have one of the following requirements:
> - When you originate traffic from your VPN gateway device to VPN net on the
> other end (like B), you want your source address to be A (private side)
> so that the traffic would be protected by the policy.
> With this approach, however, the source address selection logic follows
> normal routing table, and C (global side) will be picked for any outgoing
> traffic, even if the destination is B. The resulting packet will be like
> this:
> IP[C -> B] payload
> and will not match the policy (= sent in clear).
> - When you want to run routing protocols on top of the IPsec tunnel, it is
> not possible. As there is no pseudo device that identifies the IPsec tunnel,
> you cannot identify where the routing information came from. As a result,
> you can't run routing daemons.
>
> 4.8.2 draft-touch-ipsec-vpn approach
>
> With this approach, you will configure gif(4) tunnel interfaces, as well as
> IPsec transport mode SAs.
>
> # gifconfig gif0 C D
> # ifconfig gif0 A B
> # setkey -c <<EOF
> spdadd C D any -P out ipsec esp/transport//use;
> spdadd D C any -P in ipsec esp/transport//use;
> ^D
>
> Since we have a pseudo-interface "gif0", and it affects the routes and
> the source address selection logic, we can have source address A, for
> packets originated by the VPN gateway to B (and the VPN cloud).
> We can also exchange routing information over the tunnel (gif0), as the tunnel
> is represented as a pseudo interface (dynamic routes points to the
> pseudo interface).
>
> There is a big drawbacks, however; with this, you can use IKE if and only if
> the other end is using draft-touch-ipsec-vpn approach too. Since racoon(8)
> grabs phase 2 IKE proposals from the kernel SPD database, you will be
> negotiating IPsec transport-mode SAs with the other end, not tunnel-mode SAs.
> Also, since the encapsulation mechanism is different from RFC2401, you may not
> be able to interoperate with a picky RFC2401 implementations - if the other
> end checks certain outer IP header fields (like TOS), you will not be able to
> interoperate.
>
>
1894a2073
> - follow *BSD KNF where possible. note: there are multiple KNF standards.
1896a2076,2086
> With GNU Emacs 20 and later, the easiest way is to use the "bsd" style of
> cc-mode with the variable "c-basic-offset" being 8;
> (add-hook 'c-mode-common-hook
> (function
> (lambda ()
> (c-set-style "bsd")
> (setq c-basic-offset 8) ; XXX for Emacs 20 only
> )))
> The "bsd" style in GNU Emacs 21 sets the variable to 8 by default,
> so the line marked by "XXX" is not necessary if you only use GNU
> Emacs 21.
1908c2098
< (this is for C. For other language, you should use its own comment
---
> (this is for C. For other language, you should use its own comment
1917a2108,2137
> - it is recommended to always wrap an expression containing
> bitwise operators by parentheses, especially when the expression is
> combined with relational operators, in order to avoid unintentional
> mismatch of operators. Thus, we should write
> if ((a & b) == 0) /* (A) */
> or
> if (a & (b == 0)) /* (B) */
> instead of
> if (a & b == 0) /* (C) */
> even if the programmer's intention was (C), which is equivalent to
> (B) according to the grammar of the language C.
> Thus, we should write a code to test if a bit-flag is set for a
> given variable as follows:
> if ((flag & FLAG_A) == 0) /* (D) the FLAG_A is NOT set */
> if ((flag & FLAG_A) != 0) /* (E) the FLAG_A is set */
> Some developers in the KAME project rather prefer the following style:
> if (!(flag & FLAG_A)) /* (F) the FLAG_A is NOT set */
> if ((flag & FLAG_A)) /* (G) the FLAG_A is set */
> because it would be more intuitive in terms of the relationship
> between the negation operator (!) and the semantics of the
> condition. The KAME developers have discussed the style, and have
> agreed that all the styles from (D) to (G) are valid. So, when you
> see styles like (D) and (E) in the KAME code and feel a bit strange,
> please just keep them. They are intentional.
> - When inserting a separate block just to define some intra-block
> variables, add the level of indentation as if the block was in a
> control statement such as if-else, for, or while. For example,
> foo ()
> {
> int a;
1918a2139,2163
> {
> int internal_a;
> ...
> }
> }
> should be used, instead of
> foo ()
> {
> int a;
>
> {
> int internal_a;
> ...
> }
> }
> - Do not use printf() or log() in the packet input path of the kernel code.
> They can make the system vulnerable to packet flooding attacks (results in
> /var overflow).
> - (not a style issue)
> To disable a module that is mistakenly imported (by CVS), just
> remove the source tree in the repository. Note, however, that the
> removal might annoy other developers who have already checked the
> module out, so you should announce the removal as soon as possible.
> Also, be 100% sure not to remove other modules.
>
1924a2170,2197
>
> 9. Policy on technology with intellectual property right restriction
>
> There are quite a few IETF documents/whatever which has intellectual property
> right (IPR) restriction. KAME's stance is stated below.
>
> The goal of KAME is to provide freely redistributable, BSD-licensed,
> implementation of Internet protocol technologies.
> For this purpose, we implement protocols that (1) do not need license
> contract with IPR holder, and (2) are royalty-free.
> The reason for (1) is, even if KAME contracts with the IPR holder in
> question, the users of KAME stack (usually implementers of some other
> codebase) would need to make a license contract with the IPR holder.
> It would damage the "freely redistributable" status of KAME codebase.
>
> By doing so KAME is (implicitly) trying to advocate no-license-contract,
> royalty-free, release of IPRs.
>
> Note however, as documented in README, we do not guarantee that KAME code
> is free of IPR infringement, you MUST check it if you are to integrate
> KAME into your product (or whatever):
> READ CAREFULLY: Several countries have legal enforcement for
> export/import/use of cryptographic software. Check it before playing
> with the kit. We do not intend to be your legalease clearing house
> (NO WARRANTY). If you intend to include KAME stack into your product,
> you'll need to check if the licenses on each file fit your situations,
> and/or possible intellectual property right issues.
>