From owner-freebsd-net Thu Nov 30 8: 7:55 2000 Delivered-To: freebsd-net@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 61B2537B698 for ; Thu, 30 Nov 2000 08:07:51 -0800 (PST) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id IAA22298; Thu, 30 Nov 2000 08:06:28 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda22296; Thu Nov 30 08:06:09 2000 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.1/8.9.1) id eAUG63o08298; Thu, 30 Nov 2000 08:06:03 -0800 (PST) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdzL8290; Thu Nov 30 08:05:26 2000 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.1/8.9.1) id eAUG5PL41238; Thu, 30 Nov 2000 08:05:25 -0800 (PST) Message-Id: <200011301605.eAUG5PL41238@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdr41234; Thu Nov 30 08:05:22 2000 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 4.2-RELEASE X-Sender: cy To: itojun@iijlab.net Cc: Cy Schubert - ITSD Open Systems Group , Dominick LaTrappe , freebsd-net@freebsd.org, Gerhard Sittig Subject: Re: filtering ipsec traffic (fwd) In-reply-to: Your message of "Fri, 01 Dec 2000 00:31:12 +0900." <26650.975598272@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 30 Nov 2000 08:05:21 -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <26650.975598272@coconut.itojun.org>, itojun@iijlab.net writes: > >Could we just borrow a something from the pipsecd model? Pipsecd uses > >a tun device to present itself to system. A network that is associated > >via a pipsecd IPSec tunnel is defined in the routing table to route > >packets through the tun interface. Once packets enter the tun > >interface pipsecd encapsulates them and spits them out through the > >external interface. Packets coming back in go in reverse order. E.g., > > from IPv6 point of view (yes, I'm IPv6 centric!) we cannot add extra > interface like tun0. IPv6 has scoped address, and if we add extra > interface in IP stack we will change the address semantics. Then only solutions I can think of is to have IPF/IPFW inspect the packets before and after they are encapsulated/decapsulated or IP-IP tunnelling within the IPSec tunnel. Given your prior comments in this thread, an IP-IP tunnel which uses tun(4) will give IPv4 users some additional functionality without having to re-engineer the IPv6 stack. Of course this will once again become an issue once the whole world goes IPv6 or for current IPv6 users. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/DEC Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message