From owner-freebsd-net@FreeBSD.ORG Mon Jan 26 13:45:12 2009 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A89F81065670 for ; Mon, 26 Jan 2009 13:45:12 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (smtp.zeninc.net [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id 642678FC12 for ; Mon, 26 Jan 2009 13:45:12 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from astro.zen.inc (astro.zen.inc [192.168.1.239]) by smtp.zeninc.net (smtpd) with ESMTP id 83E082798B8 for ; Mon, 26 Jan 2009 14:45:10 +0100 (CET) Received: by astro.zen.inc (Postfix, from userid 1000) id 70B8517057; Mon, 26 Jan 2009 14:53:27 +0100 (CET) Date: Mon, 26 Jan 2009 14:53:27 +0100 From: VANHULLEBUS Yvan To: freebsd-net@FreeBSD.org Message-ID: <20090126135327.GA35595@zeninc.net> References: <20090121095507.GB36716@zeninc.net> <20090121100244.M45399@maildrop.int.zabbadoz.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090121100244.M45399@maildrop.int.zabbadoz.net> User-Agent: All mail clients suck. This one just sucks less. Cc: Subject: Re: [Patch for review] Experimental NAT-T + PFKey cleanup X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2009 13:45:13 -0000 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.