VANHULLEBUS Yvan wrote:
[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 <[EMAIL PROTECTED]>.
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).
With regard to changing the kernel API. First, this is HEAD and api's
can change. I intentionally have said nothing about MFC and didn't
touch user code. Getting the support into the kernel enables use and
testing which was the point of getting the logjam broken so full NAT-T
support can ship w/ 8.0.
I committed to get everything necessary in the tree in time for 8.0 but
now that you have direct access to freebsd's repo I think that's less
important.
Sam
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
