Date: Mon, 26 Jan 2009 14:53:27 +0100 From: VANHULLEBUS Yvan <vanhu@FreeBSD.org> To: freebsd-net@FreeBSD.org Subject: Re: [Patch for review] Experimental NAT-T + PFKey cleanup Message-ID: <20090126135327.GA35595@zeninc.net> In-Reply-To: <20090121100244.M45399@maildrop.int.zabbadoz.net> References: <20090121095507.GB36716@zeninc.net> <20090121100244.M45399@maildrop.int.zabbadoz.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jan 21, 2009 at 10:12:32AM +0000, Bjoern A. Zeeb wrote: [....] > >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. I guess that part didn't changed because quite no one (including myself) really worked on providing a full and working patch (on userland and on at least one kernel implementation) for NAT-OA. But yes, reading RFC3947 is enough to see that we do need TWO NAT-OA sent from userland to kernel, so we can at least have an API ready to carry them. > 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. I agree. Breaking a probably unused part of the API is probably not as important as breaking a widely used other part of the API, but as we do already known the issue, we can at least fix the API part, even if there is still no code which uses it. And this may have a side effect: helping us detect NAT-T code at comile time: if (for example) SADB_X_EXT_NAT_T_OAI and SADB_X_EXT_NAT_T_OAR do exist, we do have an "up to date" NAT-T kernel code, and if they don't exist we do know that we are using an older version of the code (well, may not be so easy on Linux, as none of ipsec-tools devs has commit bit on Linux). Yvan.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090126135327.GA35595>