Date: Wed, 21 Jan 2009 10:12:32 +0000 (UTC) From: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> To: VANHULLEBUS Yvan <vanhu@FreeBSD.org> Cc: freebsd-net@FreeBSD.org Subject: Re: [Patch for review] Experimental NAT-T + PFKey cleanup Message-ID: <20090121100244.M45399@maildrop.int.zabbadoz.net> In-Reply-To: <20090121095507.GB36716@zeninc.net> References: <20090121095507.GB36716@zeninc.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090121100244.M45399>