Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. =================================================================== RCS file: /ftp/cvs/cvsroot/src/sys/netinet6/Attic/IMPLEMENTATION,v retrieving revision 1.4 retrieving revision 1.5 diff -u -p -r1.4 -r1.5 --- src/sys/netinet6/Attic/IMPLEMENTATION 2000/01/06 15:48:07 1.4 +++ src/sys/netinet6/Attic/IMPLEMENTATION 2000/02/01 00:15:22 1.5 @@ -1,14 +1,14 @@ -$NetBSD: IMPLEMENTATION,v 1.4 2000/01/06 15:48:07 itojun Exp $ +$NetBSD: IMPLEMENTATION,v 1.5 2000/02/01 00:15:22 itojun Exp $ # NOTE: this is from original KAME distribution. # Some portion of this document is not applicable to the code merged into -# NetBSD-current. Check sys/netinet6/TODO as well. +# NetBSD-current (for example, section 5). Check sys/netinet6/TODO as well. Implementation Note KAME Project http://www.kame.net/ - Date: 2000/01/04 17:56:28 + Date: 2000/01/30 09:35:41 1. IPv6 @@ -20,7 +20,7 @@ below (NOTE: this is not a complete list For details please refer to specific chapter in the document, RFCs, manpages come with KAME, or comments in the source code. -Conformance tests have been performed on the KAME STABLE kit +Conformance tests have been performed on past and latest KAME STABLE kit, at TAHI project. Results can be viewed at http://www.tahi.org/report/KAME/. We also attended Univ. of New Hampshire IOL tests (http://www.iol.unh.edu/) in the past, with our past snapshots. @@ -88,6 +88,9 @@ RFC2675: IPv6 Jumbograms * See 1.7 in this document for details. RFC2710: Multicast Listener Discovery for IPv6 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-08: Router renumbering for IPv6 draft-ietf-ipngwg-icmp-namelookups-02: IPv6 Name Lookups Through ICMP draft-ietf-ipngwg-icmp-name-lookups-03: IPv6 Name Lookups Through ICMP @@ -103,6 +106,10 @@ draft-yamamoto-wideipv6-comm-model-00 * See 1.6 in this document for details. draft-ietf-ipngwg-scopedaddr-format-00.txt: An Extension of Format for IPv6 Scoped Addresses +draft-ietf-ngtrans-tcpudp-relay-00.txt: + An IPv6-to-IPv4 transport relay translator + * FAITH tcp relay translator (faithd) implements this. See 3.1 for more + details. 1.2 Neighbor Discovery @@ -112,13 +119,22 @@ are supported. In the near future we wi Advertisement support in the kernel and Unsolicited Neighbor Advertisement transmission command as admin tool. +Duplicated Address Detection (DAD) will be performed when an IPv6 address +is assigned to a network interface, or the network interface is enabled +(ifconfig up). It is documented in RFC2462 5.4. If DAD fails, the address will be marked "duplicated" and message will be generated to syslog (and usually to console). The "duplicated" mark can be checked with ifconfig. It is administrators' responsibility to check -for and recover from DAD failures. -The behavior should be improved in the near future. +for and recover from DAD failures. We may try to improve failure recovery +in future KAME code. +DAD procedure may not be effective on certain network interfaces/drivers. +If a network driver needs long initialization time (with wireless network +interfaces this situation is popular), and the driver mistakingly raises +IFF_RUNNING before the driver becomes ready, DAD code will try to transmit +DAD probes to not-really-ready network driver and the packet will not go out +from the interface. In such cases, network drivers should be corrected. -Some of the network driver loops multicast packets back to itself, +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. @@ -137,10 +153,11 @@ list. For more details, see the comment thread started from (IPng 7155), dated Feb 6 1999. IPv6 on-link determination rule (RFC2461) is quite different from assumptions -in BSD network code. At this moment, KAME does not implement on-link -determination rule when default router list is empty (RFC2461, section 5.2, -last sentence in 2nd paragraph - note that the spec misuse the word "host" -and "node" in several places in the section). +in BSD IPv4 network code. To implement behavior in RFC2461 section 5.2 +(when default router list is empty), the kernel needs to know the default +outgoing interface. To configure the default outgoing interface, use +commands like "ndp -I de0" as root. Note that the spec misuse the word +"host" and "node" in several places in the section. To avoid possible DoS attacks and infinite loops, KAME stack will accept only 10 options on ND packet. Therefore, if you have 20 prefix options @@ -151,30 +168,36 @@ provide sysctl knob for the variable. 1.3 Scope Index -IPv6 uses scoped addresses. Therefore, it is very important to +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, scoped IPv6 address is ambiguous to the kernel, and -kernel will not be able to determine the outbound interface for a -packet. - -Ordinary userland applications should use advanced API (RFC2292) to -specify scope index, or interface index. For similar purpose, -sin6_scope_id member in sockaddr_in6 structure is defined in RFC2553. -However, the semantics for sin6_scope_id is rather vague. If you -care about portability of your application, we suggest you to use -advanced API rather than sin6_scope_id. - -In the kernel, an interface index for link-local scoped address is -embedded into 2nd 16bit-word (3rd and 4th byte) in IPv6 address. +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. + +1.3.1 Kernel internal + +In the kernel, the interface 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 +in6_ifaddr). The address above is a link-local unicast address which belongs to a network interface whose interface identifier is 1. The embedded index enables us to identify IPv6 link local addresses over multiple interfaces effectively and with only a little code change. + +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) @@ -183,6 +206,26 @@ filled in. The APIs are for manipulatin 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-00.txt. +You can specify outgoing link, by using name of the outgoing interface +like "fe80::1@ne0". This way you will be able to specify link-local scoped +address without much trouble. +To use this extension in your program, you'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. + +1.3.3 Interaction with users (command line) + +Some of the userland tools support extended numeric IPv6 syntax, as +documented in draft-ietf-ipngwg-scopedaddr-format-00.txt. In this case, +you can specify outgoing link, by using name of the outgoing interface like +"fe80::1@ne0". + When you specify scoped address to the command line, NEVER write the embedded form (such as ff02:1::1 or fe80:2::fedc). This is not supposed to work. Always use standard form, like ff02::1 or fe80::fedc, with @@ -192,15 +235,14 @@ outgoing interface, that command is not This may seem to be opposite from IPv6's premise to support "dentist office" situation. We believe that specifications need some improvements for this. -Some of the userland tools support extended numeric IPv6 syntax, as -documented in draft-ietf-ipngwg-scopedaddr-format-00.txt. You can specify -outgoing link, by using name of the outgoing interface like "fe80::1@ne0". -This way you will be able to specify link-local scoped address without much -trouble. -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 specs say. +The only exception to the above rule would be when you configure routing table +manually by route(8). Gateway portion of IPv6 routing entry must be an +link-local address (otherwise ICMPv6 redirect will not work), and in this +case you'll need to configure it by putting interface index into the address: + # route add -inet6 default fe80:2::9876:5432:1234:5678 + (when interface index for outgoing interface = 2) +To avoid configuration mistakes, we suggest you to run dynamic routing instead +(like route6d(8)). 1.4 Plug and Play @@ -223,8 +265,8 @@ Here is an output of netstat command: Internet6: Destination Gateway Flags Netif Expire -fe80:1::/64 link#1 UC ed0 -fe80:2::/64 link#2 UC ep0 +fe80::@ed0/64 link#1 UC ed0 +fe80::@ep0/64 link#2 UC ep0 Interfaces that has no IEEE802 address (pseudo interfaces like tunnel interfaces, or ppp interfaces) will borrow IEEE802 address from other @@ -253,6 +295,14 @@ routers and hosts. Routers forward pack not forward the packets. net.inet6.ip6.forwarding defines whether this node is router or host (router if it is 1, host if it is 0). +It is NOT recommended to change net.inet6.ip6.forwarding while the node +is in operation. IPv6 specification defines behavior for "host" and "router" +quite differently, and switching from one to another can cause serious +troubles. It is recommended to configure the variable at bootstrap time only. + +The first step in stateless address configuration is Duplicated Address +Detection (DAD). See 1.2 for more detail on DAD. + When a host hears Router Advertisement from the router, a host may autoconfigure itself by stateless address autoconfiguration. This behavior can be controlled by net.inet6.ip6.accept_rtadv @@ -330,7 +380,7 @@ gif can be configured to be ECN-friendly of tunnels, and gif(4) manpage for how to configure. If you would like to configure an IPv4-in-IPv6 tunnel with gif interface, -read gif(4) carefully. You will need to remove IPv6 link-local address +read gif(4) carefully. You may need to remove IPv6 link-local address automatically assigned to the gif interface. 1.6 Source Address Selection @@ -643,8 +693,7 @@ not recommend you to rely upon IPv4 mapp The platforms do not support IPv4 mapped address at all (both listening side 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. +Port number space is totally separate between AF_INET and AF_INET6 sockets. 1.12.2 KAME/FreeBSD3x @@ -672,7 +721,7 @@ There's no problem with open/close order (XXX need checking) -1.12.2.1 KAME/FreeBSD3x, initiating side +1.12.2.2 KAME/FreeBSD3x, initiating side KAME/FreeBSD3x supports outgoing connetion to IPv4 mapped address (::ffff:10.1.1.1), if the node is configured to accept IPv4 connections @@ -680,14 +729,14 @@ by AF_INET6 socket. (XXX need checking) -1.12.4 KAME/NetBSD +1.12.3 KAME/NetBSD KAME/NetBSD uses shared tcp4/6 code (from sys/netinet/tcp*) and shared udp4/6 code (from sys/netinet/udp*). The implementation is made differently from KAME/FreeBSD3x. KAME/NetBSD uses separate inpcb/in6pcb structures, while KAME/FreeBSD3x uses merged inpcb structure. -1.12.4.1 KAME/NetBSD, listening side +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 @@ -712,21 +761,21 @@ conditions are satisfied: getsockopt(IPV6_BINDV6ONLY) returns 0. There's no problem with open/close ordering. -1.12.4.1 KAME/NetBSD, initiating side +1.12.3.2 KAME/NetBSD, initiating side 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. -1.12.5 KAME/BSDI4 +1.12.4 KAME/BSDI4 KAME/BSDI4 uses NRL-based TCP/UDP stack and inpcb source code, which was derived from NRL IPv6/IPsec stack. I guess it supports IPv4 mapped address and speical AF_INET6 wildcard bind. The implementation is, again, different from other KAME/*BSDs. -1.12.5.1 KAME/BSDI4, listening side +1.12.4.1 KAME/BSDI4, listening side NRL inpcb layer supports special behavior of AF_INET6 wildcard socket. It grabs IPv4 connection under certain condition. NRL inpcb layer has @@ -738,17 +787,17 @@ different behavior than KAME implementat both will success. However, all IPv4 traffic (and IPv6 traffic) will be captured by IPv6 wildcard socket. -1.12.5.2 KAME/BSDI4, initiating side +1.12.4.2 KAME/BSDI4, initiating side KAME/BSDi4 supports connection initiation to IPv4 mapped address (like ::ffff:10.1.1.1). -1.12.6 KAME/OpenBSD +1.12.5 KAME/OpenBSD KAME/OpenBSD uses NRL-based TCP/UDP stack and inpcb source code, which was derived from NRL IPv6/IPsec stack. -1.12.6.1 KAME/OpenBSD, listening side +1.12.5.1 KAME/OpenBSD, listening side KAME/OpenBSD disables special behavior on AF_INET6 wildcard bind for security reasons (if IPv4 traffic toward AF_INET6 wildcard bind is allowed, @@ -759,7 +808,7 @@ policy. As a result the behavior of KAME/OpenBSD is similar to KAME/BSDI3 and KAME/FreeBSD228 (see 1.12.1 for more detail). -1.12.6.2 KAME/OpenBSD, initiating side +1.12.5.2 KAME/OpenBSD, initiating side KAME/OpenBSD does not support connection initiation to IPv4 mapped address (like ::ffff:10.1.1.1). @@ -803,6 +852,22 @@ dealing with it is to: struct sockaddr_storage ss; family = ((struct sockaddr *)&ss)->sa_family +1.14 Invalid addresses on the wire + +IPv6 specifications reserve IPv6 address range that are used internally +in IPv6 nodes (not on the wire). They are: +- IPv4 mapped address (like ::ffff:10.1.1.1) +- IPv4 compatible address (like ::10.1.1.1) +They are defined and used to ease IPv4-to-IPv6 transition. However, +if they mistakingly appear on the wire, they can confuse IPv6 implementations. +It is also possible to use the above addresses as tools to attack IPv6 hosts, +to bypass certain security checks (like using source address of +::ffff:127.0.0.1 to bypass "reject packet from remote" filter). + +KAME code is carefully written to avoid such incidents. More specifically, +KAME kernel will reject packets if the above addresses are used in IPv6 +source/dstination address, or IPv6 routing header. + 2. Network Drivers KAME requires three items to be added into the standard drivers: @@ -899,10 +964,13 @@ The following table lists the network dr support? --- --- --- --- (Ethernet) - ne pci/i386 ok ok yes + awi pcmcia/i386 ok ok - + bah zbus/amiga NG(*) + cnw pcmcia/i386 ok ok yes ep pcmcia/i386 ok ok - le sbus/sparc ok ok yes - bah zbus/amiga NG(*) + ne pci/i386 ok ok yes + wi pcmcia/i386 ok ok yes (ATM) en pci/i386 ok ok - @@ -940,9 +1008,27 @@ Here is a list of OpenBSD 2.x drivers an support? --- --- --- --- (Ethernet) + le sbus/sparc ok ok yes + fxp pci/i386 ?(*) ne pci/i386 ok ok yes ne pcmcia/i386 ok ok yes - le sbus/sparc ok ok yes + +(*) There seem to be some problem in driver, with multicast filter +configuration. This happens with certain revision of chipset on the card. +Should be fixed by now but still not sure. + +2.6 BSD/OS 4.x + +The following lists BSD/OS 4.x device drivers and its conditions: + + driver mbuf(1) multicast(2) official + support? + --- --- --- --- + (Ethernet) + de ok ok yes + +You may want to use "@insert" directive in /etc/pccard.conf to invoke +"rtsol" command right after dynamic insertion of PCMCIA ethernet cards. 3. Translator @@ -995,78 +1081,36 @@ For more details, consult kame/kame/fait 4. IPsec -IPsec is mainly organized by three components. +IPsec is implemented as the following three components. (1) Policy Management (2) Key Management -(3) AH and ESP handling +(3) AH, ESP and IPComp handling in kernel + +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. +KAME/BSDI4 lacks IPsec at this moment (both NRL and KAME). In the near +future we will be adding KAME IPSec code support into KAME/BSDI4. 4.1 Policy Management -The policy management code is experimental, but this is almostly -conformed to RFC2401. You can manage the SPD by both the command -for administrater and the socket operation. -By the command "setkey", there are three directive as following: - - "discard" means to discard the packet. - "none" means not to do IPsec. - "ipsec" means to do IPsec. - -"ipsec" is followed by some IPsec requests like "protocol/level". - - protocol is to be either "ah" or "esp". - level is to be either "default", "use" or "require". - - "use" means that if a security association is available, use it - for outbound packet, request SA to the Key management daemon - through PF_KEY v2, and accept any inbound packets. - - "require" means that if a security association does not exist - for outbound traffic, acquire one and discard the packet untill - SA is found, and require inbound packets to use security. - - "default" is consulted to system wide default defined "sysctl" MIBs: - net.inet.ipsec.esp_trans_deflev - net.inet.ipsec.esp_net_deflev - net.inet.ipsec.ah_trans_deflev - net.inet.ipsec.ah_net_deflev - net.inet6.ipsec6.esp_trans_deflev - net.inet6.ipsec6.esp_net_deflev - net.inet6.ipsec6.ah_trans_deflev - net.inet6.ipsec6.ah_net_deflev - - They are 1:use or 2:require. - -When you need to setup IPsec tunnel mode, you use the format of -"procol/level/peer". "peer" is IP address of the tunnel end-point. - -By the socket operation, there are three directive as following: - "ipsec" means to do IPsec, see above. - "entrust" means to consult to SPD defined by the command. - "bypass" means not to do IPsec. This is for priveleged socket. - -If kernel doesn't find out policy entry, then system wide default -is applied. You can specify the system wide default as discarding -packet or not to do IPsec. - - net.inet.ipsec.def_policy - net.inet6.ipsec6.def_policy - - They are 0:discard or 1:none. - -You can see these values in netinet6/ipsec.h. - -The policy entry is not re-ordered with its -indexes, so the order of entry when you add is very significant. -But we think it should be fixed in the future. +The kernel implements experimental policy management code. There are two way +to to manage security policy. One is to configure per-socket policy using +setsockopt(3). In this cases, policy configuration is described in +ipsec_set_policy(3). The other is to configure kernel packet filter-based +policy using PF_KEY interface, via setkey(8). + +The policy entry will be matched in order. The order of entries makes +difference in behavior. 4.2 Key Management The key management code implemented in this kit (sys/netkey) is a home-brew PFKEY v2 implementation. This conforms to RFC2367. -The home-brew IKE daemon, "racoon" is included in the kit -(kame/kame/racoon). +The home-brew IKE daemon, "racoon" is included in the kit (kame/kame/racoon, +or usr.sbin/racoon). Basically you'll need to run racoon as daemon, then setup a policy to require keys (like ping -P 'out ipsec esp/transport//use'). The kernel will contact racoon daemon as necessary to exchange keys. @@ -1094,18 +1138,55 @@ transform are listed in {esp,ah}_core.c wish to add some algorithm, add wrapper function in {esp,ah}_core.c, and add your crypto algorithm code into sys/crypto. -Tunnel mode is partially supported in this release, with the following -restrictions: -- IPsec tunnel is not combined with GIF generic tunneling interface. - It needs a great care because we may create an infinite loop between - ip_output() and tunnelifp->if_output(). Opinion varies if it is better - to unify them, or not. -- MTU and Don't Fragment bit (IPv4) considerations need more checking, but - basically works fine. +Tunnel mode works basically fine, but comes with the following restrictions: +- You cannot run routing daemon across IPsec tunnel, since we do not model + 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. -4.4 Conformance to RFCs and IDs +4.4 IPComp handling + +IPComp stands for IP payload compression protocol. This is aimed for +payload compression, not the header compression like PPP VJ compression. +This may be useful when you are using slow serial link (say, cell phone) +with powerful CPU (well, recent notebook PCs are really powerful...). +The protocol design of IPComp is very similar to IPsec, though it was +defined separately from IPsec itself. + +Here are some points to be noted: +- IPComp is treated as part of IPsec protocol suite, and SPI and + CPI space is unified. Spec says that there's no relationship + between two so they are assumed to be separate in specs. +- IPComp association (IPCA) is kept in SAD. +- It is possible to use well-known CPI (CPI=2 for DEFLATE for example), + for outbound/inbound packet, but for indexing purposes one element from + SPI/CPI space will be occupied anyway. +- pfkey is modified to support IPComp. However, there's no official + SA type number assignment yet. Portability with other IPComp + stack is questionable (anyway, who else implement IPComp on UN*X?). +- Spec says that IPComp output processing must be performed before IPsec + output processing, to achieve better compression ratio and "stir" data + stream before encryption. However, with manual SPD setting, you are able to + violate the ordering requirement (KAME code is too generic, maybe). +- Though MTU can be significantly decreased by using IPComp, no special + consideration is made about path MTU (spec talks nothing about MTU + consideration). IPComp is designed for serial links, not ethernet-like + medium, it seems. +- You can change compression ratio on outbound packet, by changing + deflate_policy in sys/netinet6/ipcomp_core.c. You can also change outbound + history buffer size by changing deflate_window_out in the same source code. + (should it be sysctl accessible, or per-SAD configurable?) +- Tunnel mode IPComp is not working right. KAME box can generate tunnelled + IPComp packet, however, cannot accept tunneled IPComp packet. +- You can negotiate IPComp association with racoon IKE daemon. +- KAME code does not attach Adler32 checksum to compressed data. + see ipsec wg mailing list discussion in Jan 2000 for details. + +4.5 Conformance to RFCs and IDs The IPsec code in the kernel conforms (or, tries to conform) to the following standards: @@ -1115,6 +1196,8 @@ following standards: but you can take from ftp://ftp.kame.net/pub/internet-drafts/). (NOTE: IKE specifications, rfc241[7-9].txt are implemented in userland, as "racoon" IKE daemon) + IPComp: + RFC2393: IP Payload Compression Protocol (IPComp) Currently supported algorithms are: old IPsec AH @@ -1144,6 +1227,8 @@ Currently supported algorithms are: each of the above can be combined with: ESP authentication with HMAC-MD5(96bit) ESP authentication with HMAC-SHA1(96bit) + IPComp + RFC2394: IP Payload Compression Using DEFLATE The following algorithms are NOT supported: old IPsec AH @@ -1151,13 +1236,11 @@ The following algorithms are NOT support (rfc2085.txt) keyed SHA1 with 160bit crypto checksum + 32bit padding (rfc1852.txt) -IPsec (in kernel) and IKE (in userland as "racoon") has been tested -at several interoperability test events, and it is known to interoperate -with many other implementations well. Also, KAME IPsec has quite wide -coverage for IPsec crypto algorithms documented in RFC (we cover -algorithms without intellectual property issues only). +The key/policy management API is based on the following document, with fair +amount of extensions: + RFC2367: PF_KEY key management API -4.5 ECN consideration on IPsec tunnels +4.6 ECN consideration on IPsec tunnels KAME IPsec implements ECN-friendly IPsec tunnel, described in draft-ipsec-ecn-00.txt. @@ -1210,52 +1293,51 @@ For more information, please refer to: (Thanks goes to Kenjiro Cho for detailed analysis) -4.6 Interoperability - -Here are (some of) platforms we have tested IPsec/IKE interoperability -in the past. 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), Ericsson - ACC, FreeS/WAN, HITACHI, IBM AIX, IIJ, Intel, Microsoft WinNT, NIST - (linux IPsec + plutoplus), Netscreen, OpenBSD, RedCreek, Routerware, - SSH, Secure Computing, Soliton, Toshiba, VPNet, Yamaha RT100i - -5. IPComp +4.7 Interoperability -IPComp stands for IP payload compression protocol. This is aimed for -payload compression, not the header compression like PPP VJ compression. -This may be useful when you are using slow serial link (say, cell phone) -with powerful CPU (well, recent notebook PCs are really powerful...). -The protocol design of IPComp is very similar to IPsec. +IPsec, IPComp (in kernel) and IKE (in userland as "racoon") has been tested +at several interoperability test events, and it is known to interoperate +with many other implementations well. Also, KAME IPsec has quite wide +coverage for IPsec crypto algorithms documented in RFC (we do not cover +algorithms with intellectual property issues, though). -KAME implements the following specifications: -- RFC2393: IP Payload Compression Protocol (IPComp) -- RFC2394: IP Payload Compression Using DEFLATE +Here are (some of) platforms we have tested IPsec/IKE interoperability +in the past, in 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, NIST (linux IPsec + plutoplus), + Netscreen, OpenBSD, Radguard, RedCreek, Routerware, SSH, Secure + Computing, Soliton, Toshiba, TIS/NAI Gauntret, VPNet, Yamaha RT100i + +Here are (some of) platforms we have tested IPComp/IKE interoperability +in the past, in no particular order. + IRE + +5. ALTQ + +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 nubmer. 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 archtitectures, 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. -Here are some points to be noted: -- IPComp is treated as part of IPsec protocol suite, and SPI and - CPI space is unified. Spec says that there's no relationship - between two so they are assumed to be separate. -- IPComp association (IPCA) is kept in SAD. -- It is possible to use well-known CPI (CPI=2 for DEFLATE for example), - for outbound/inbound packet, but for indexing purposes one element from - SPI/CPI space will be occupied anyway. -- pfkey is modified to support IPComp. However, there's no official - SA type number assignment yet. Portability with other IPComp - stack is questionable (anyway, who else implement IPComp on UN*X?). -- Spec says that IPComp output processing must be performed before IPsec - output processing, to achieve better compression ratio and "stir" data - stream before encryption. However, with manual SPD setting, you are able to - violate the ordering requirement (KAME code is too generic, maybe). -- Though MTU can be significantly decreased by using IPComp, no special - consideration is made about path MTU (spec talks nothing about MTU - consideration). IPComp is designed for serial links, not ethernet-like - medium, it seems. -- You can change compression ratio on outbound packet, by changing - deflate_policy in sys/netinet6/ipcomp_core.c. You can also change history - buffer size by changing deflate_window in the same source code. - (should it be sysctl accessible? or per-SAD configurable?) -- Tunnel mode IPComp is not working right. KAME box can generate tunnelled - IPComp packet, however, cannot accept tunneled IPComp packet. +At this moment part of ALTQ code is not 64bit friendly (specifically, +libaltq). So ALTQ cannot be used on {Net,Open}BSD/alpha.