[Patch for review] Experimental NAT-T + PFKey cleanup

[Bjoern A. Zeeb]

On Wed, 21 Jan 2009, VANHULLEBUS Yvan wrote:

Hi,

> [same mail sent both on ipsec-tools-devel and freebsd-net, please use
> respective MLs for potential issues on each side]
>
> Hi all.
>
> Here is a beta patch which cleans the way PFKey exchanges NAT-T ports
> between kernel and userland, available at:
> http://people.freebsd.org/~vanhu/NAT-T/experimental/
...
>
> With those patches, NAT-T ports are now always sent via
> SADB_X_EXT_NAT_T_[S|D]PORT, and never as ports in
> SADB_EXT_ADDRESS_[SRC|DST] (which is not RFC2367 compliant)
> Both ways are more or less used actually.
...
>
> Ipsec-tools team has still not decided how such compatibility issues
> will be handled (or not...), any (good) idea is welcome !

While this seems to be a big concern and there is compat breakage with
this patchset already, could we just finish the thing and also add the
second OA to not have to go through another round of breakage at a
later time?

I checked the patch and I still can only see one NAT_T_OA which does
not work in the double NAT scenario as I have stated multiple times in
the past. See RFC3947, 5.2., Example 2.

As said before I am currently caring less that the functionality
behind this is implemented but want to make sure we do not need to
break APIs again at a later time to add this and thus giving us way
more pain then.

/bz

-- 
Bjoern A. Zeeb                      The greatest risk is not taking one.