Date: Mon, 21 Jul 2008 16:26:57 +0200 From: VANHULLEBUS Yvan <vanhu@FreeBSD.org> To: freebsd-net@freebsd.org Cc: Larry Baird <lab@gta.com> Subject: Re: FreeBSD NAT-T patch integration [CFR/CFT] Message-ID: <20080721142657.GB24677@zen.inc> In-Reply-To: <20080721085325.B57089@maildrop.int.zabbadoz.net> References: <20080630040103.94730.qmail@mailgate.gta.com> <486A45AB.2080609@freebsd.org> <487EC62A.3070301@freebsd.org> <20080721085325.B57089@maildrop.int.zabbadoz.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[Larry, I kept you in an explicit CC, even if I guess you suscribed to the list] On Mon, Jul 21, 2008 at 09:26:15AM +0000, Bjoern A. Zeeb wrote: > On Wed, 16 Jul 2008, Sam Leffler wrote: > > Hi, Hi. [...] > My main concern at the moment is the API (pfkey stuff) to userland as > Yvan had stated in <20080626075307.GA1401@zen.inc>. It is also one of my main concerns actually. > I know that at the moment there seems to be one public (pseudo) reference > implementation this all works together but there might be/are other > people not using libipsec from ipsec-tools. Well, people who use another libipsec are expected to "just" not see NAT-T extensions. The only "real issue" is that, actually, NAT-T ports are sent though sockaddr structs, when RFC 2367 says that zeroing ports MUST be done (section 2.3.3). There is already an open ticket on ipsec-tools side to cleanup that part of the code on userland's size of PFKey interface, and I hope it will be done for 0.8.0 release (sorry, no release date for now). As soon as I'll have a working patch on userland, I'll do the work on FreeBSD's kernel side. I hope everything will be done within a few weeks, but I already know that we'll have backward compatibility issues with various kernels (ipsec-tools runs at least on FreeBSD, NetBSD, Linux and MacOSX). Yvan.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080721142657.GB24677>