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. _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[email protected]"
