--=_ORCL_16117862_0_0
Content-Transfer-Encoding:quoted-printable
Content-Type:text/plain; charset="iso-8859-1"

 
I will not be accessing my mails from 06/12/99 to 06/25/99. For any official=
 
communications please contact my manager Gopal (glakshmi@in.oracle.com). For=
 
personal communication you can contact me at +91 (5946) 23256. 
 
Thanks, 
Harish 
----------------------------------------------------------------------------=
-

Harish  Rawat			           E-Mail : harawat@in.oracle.com 
Oracle Software India. Ltd.                Voice  : +91 (80) 228 3004/5 
Indian Development Center ( IDC )          Fax    : +91 (80) 225 - 6207/1591=
 
Sona Towers 
No 71 Miller Road 
Bangalore-52 
 

----------------------------------------------------------------------------=
---
----- 
The statements and opinions expressed here are my own and do not necessarily=
 
represent those of Oracle Corporation 

----------------------------------------------------------------------------=
---
----

--=_ORCL_16117862_0_0
Content-Type:message/rfc822

Date: 21 Jun 99 03:21:42
From:itojun@iijlab.net
To:tech-net@netbsd.org, tech-kern@netbsd.org
Subject:IPv6/IPsec actions in 1.5
Reply-to:INUNIX2.IN.ORACLE.COM:tech-net@netbsd.org 
Message-ID:<21732.929915502@coconut.itojun.org>
Sender:tech-net-owner@netbsd.org
MIME-Version: 1.0
Content-Transfer-Encoding:quoted-printable
Content-Type:text/plain; charset="iso-8859-1"

	(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

--=_ORCL_16117862_0_0--