Aren/NetBSD
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

sync with current code. now IMPLEMENTATION doc is almost identical

Browse Source 
to the latest KAME one.
This commit is contained in:
itojun 2000-02-01 00:15:22 +00:00
parent 3b5706e2e5
commit ae788a8a43
2 changed files with 256 additions and 201 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

414
sys/netinet6/IMPLEMENTATION
View File

@ -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 - this is too hard to maintain...).
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 will be adding Proxy Neighbor
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 comments in the source code and email
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.
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.
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.
1.3.1 Kernel internal
In the kernel, an interface index for link-local scoped address is
embedded into 2nd 16bit-word (3rd and 4th byte) in IPv6 address.
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 manipulating kernel internal structure.
Programs that use these APIs have to be prepared about differences
in kernels anyway.
getaddrinfo(3) and getnameinfo(3) are modified to support extended numeric
IPv6 syntax, as documented in draft-ietf-ipngwg-scopedaddr-format-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 ready to accept scoped address.
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 packets addressed to others, hosts does
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. See 4.5 for ECN-friendliness
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 mapped address.
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 ordering.
(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 implementation, namely:
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 drivers we have tried so far.
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 and its conditions:
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/faithd/README.
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:
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).
"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 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 with wrapper functions. If you
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 supported:
(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 <kjc@csl.sony.co.jp> for detailed analysis)
4.6 Interoperability
4.7 Interoperability
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).
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
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
5. IPComp
Here are (some of) platforms we have tested IPComp/IKE interoperability
in the past, in no particular order.
IRE
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.
5. ALTQ
KAME implements the following specifications:
- RFC2393: IP Payload Compression Protocol (IPComp)
- RFC2394: IP Payload Compression Using DEFLATE
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)
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.
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.
At this moment part of ALTQ code is not 64bit friendly (specifically,
libaltq). So ALTQ cannot be used on {Net,Open}BSD/alpha.
<end of IMPLEMENTATION>

43
sys/netinet6/TODO
View File

@ -1,44 +1,15 @@
KAME/NetBSD integration TODOs
$NetBSD: TODO,v 1.8 2000/01/06 15:46:08 itojun Exp $
$NetBSD: TODO,v 1.9 2000/02/01 00:15:22 itojun Exp $
Jun-ichiro itojun Hagino <itojun@itojun.org>
This file talks about issues/TODOs in KAME/NetBSD integration.
For details about original KAME distribution, please refer to
sys/netinet6/IMPLEMENTATION, or documents in KAME distribution.
(NOTE: description in 1.12 does not apply to integrated code)
KERNEL
======
* inpcb and in6pcb
KAME kit has been designed to have less influence (bad impact) to the base
IPv4 code. For this, KAME uses separate pcb structure for IPv6 connections,
namely struct in6pcb (sys/netinet6/in6_pcb.h). In unified-ipv6 codebase
(this part is from NRL) they are merged into one, but will need bunch of
changes into netinet/in_pcb.h - which will affect stability of IPv4 tree.
Let us see which is better.
* port number issues
No IETF document talks about how tcp4/tcp6 and udp4/udp6 port number space
should be handled. The only thing defined is, in RFC2553:
AF_INET6 socket listening to wildcard IPv6 address (::) should
accept IPv4 connections.
It is very unclear how port number spaces should be treated. If they are
to be unified, what happens if, for example, you bind(2) to IPv4 wildcard
address, then IPv6 specific address on that port? There are so many
possibilities to be considered. It is much clearer and easier for me if
they are totally separate. Also, separated port number space is
compatible/safe to future addition of "TCP over IPv7" :-)
Proper userland code should not be affected by this (see RFC2553 for
how to use getaddrinfo()), so KAME userland can cope with both cases.
Current kernel code implement separate port number spaces, since it uses
separate inpcb/in6pcb.
* net/if_types.h
IFT_GIF and IFT_FAITH are not defined in IANA assignment, but we need to
@ -73,6 +44,9 @@ after stabilization.
We currently reuse m_pkthdr.rcvif for ipsec socket pointer, and ipf and
other code does not like this.
It is planned to add m->m_pkthdr.aux (pointer to mbuf chain) to carry around
extra information for IPsec and other cases.
* gre/ipip compatibility
Hope I did not break any of these... Could someone check?
@ -84,6 +58,8 @@ is local to IPv6 code so it should be M_PROTO0 or something like that.
Others (IPsec items) are used across IPv4 and IPv6 so they cannot be in
M_PROTO0 kind of thing.
When we switch to m->m_pkthdr.aux, we don't need those flags in m->m_flags.
USERLAND
========
@ -93,7 +69,7 @@ KAME codebase includes several routing daemons, like route6d or bgpd (which
does RIPng and BGP4+, respectively). Should we put these into
/usr/src/usr.sbin, or should we treat those as third-party code (pkgsrc)?
pim6dd license issue should be clarified.
pim6dd/pim6sd license issue should be clarified.
* IPv6-support in resolvers and libraries
@ -107,9 +83,6 @@ To be RFC2553 compilient, we need to supply getipnodeby{name,addr}.
However, it needs a total rewrite of gethostby{name,addr}.
It will make future upgrade to bind8x really harder.
rcmd() and iruserok() must be extended to support multiple address families.
Experiments in KAME but still unclear about API (no standard).
* -DINET6, -DIPSEC
Where should we define -DINET6? Should it be global option like
@ -124,7 +97,7 @@ by default.
* if index
Should we hide if index (s6_addr16[1] in in6_addr) from the user, on "ifconfig"
Should we hide if index (s6_addr[2-3] in in6_addr) from the user, on "ifconfig"
or "netstat -in"? Those numbers are just for kernel internal
and should never be used from standard userland applications.
(see 1.3 in sys/netinet6/IMPLEMENTATION)