Subject: IPv6/IPsec actions in 1.5
To: None <tech-net@netbsd.org, tech-kern@netbsd.org>
From: None <itojun@iijlab.net>
List: tech-kern
Date: 06/21/1999 06:51:42
(please route further discussion to tech-net)
After bunch of discussion with Perry, I think the following route
should be taken for 1.5:
- Import KAME kernel+userland so that it can be put into 1.5.
- whenever unified-ipv6 is ready (before 1.5 or after 1.5),
we'll switch the codebase to unified-ipv6.
Please note that the final goal is to sync with unified-ipv6.
If I understand correctly, 1.5 is the last chance before Y2K to
import IPv6 (perry told me so). So, I need to take the above route,
rather than waiting for unified-ipv6. As a bonus we can get KAME
IPsec into the tree sooner.
As one of unified-ipv6 worker I do feel sorry about this twist.
If unified-ipv6 was ready for consumption this was not necessary.
This is not quite ready at this moment.
KAME code is well baked for more than years, so this should cause
no much trouble.
The most affected (existing) kernel part is netinet/tcp*, as we will
use this from both IPv4 and IPv6. (struct tcpiphdr must be nuked)
I'm trying to clean up the code.
KAME used to separate tcp4 and tcp6 code for various reasons
(main reason was that, we'll have to modify *BSD's code to make them
dual stack - so, we need to modify very similar code 3 or 4 times and
KAME team will get maintenance nightmare as bonus. With separate tcp6
it is much easier for KAME to maintain).
Now I'm making them integrated, single source code with dual stack
support, for better maintenance in NetBSD project.
The dual stack tcp code is (partly) taken from unified-ipv6 tree
so that there will be less trouble switching to unified-ipv6.
For userland:
- ftp/telnet/whatever will become dual-stack. There will be several
command line options added where necessary, but basically these are
seamless (ftp v6host.netbsd.org will perform IPv6 ftp).
- libc will include several new name-server related libraries,
like those discussed in RFC2553 or RFC2292.
- We have dual-stack named (based on bind 8.1.2) ready, however,
I think we'd better supply that as pkgsrc, not the base distribution
as it is not the official distribution from ISC. If it is okay to
do I'll update /usr/sbin/bind.
NOTE: dual-stack named is required only if you are making IPv6-only
network. Most of the IPv6 node is dual-stack node at this moment,
so they can query DNS database over IPv4.
- Resolver will become dual-stack as well. There will be a
update to libc. (it needs rebuid to switch from IPv4 resolver
to IPv6 resolver so I think this should be in libc).
NOTE: bind82 distribution does not include dual-stack resolver,
nor dual-stack named. bind9 plans to ship with dual-stack resolver
and named.
As far as IPsec issues are concerned, we need some tricks in import:
- items that can be imported into base tree:
kernel AH code
crypto checksum algorithm (SHA1 for example)
key/policy management code
several IPsec hooks, like copying ipsec policy configuration
from listening tcp socket to accepted tcp socket
- items that can be imported into crypto-us/intl:
kernel ESP code
crypto algorithm (CAST128 RC5 for example)
IKE key exchange code (due to heavy use of crypto)
AH is safe and many (incl. NRL and BSDI) include AH in "export"
distribution. If this causes any problem, we can put AH into
crypto-us/intl.
I'll be able to do the actual work.
Does it sound reasonable?
itojun