FreeBSD NAT-T patch integration [CFR/CFT]

[Sam Leffler]

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 <20080626075307.GA1401 at 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).
>   

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