From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 11 19:16:37 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E784916A4CE for ; Fri, 11 Mar 2005 19:16:37 +0000 (GMT) Received: from mx2.netflix.com (mail2.netflix.com [216.35.131.152]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD96643D1D for ; Fri, 11 Mar 2005 19:16:37 +0000 (GMT) (envelope-from nsayer@kfu.com) Received: from [172.22.8.180] ([172.22.8.180]) by mx2.netflix.com (8.12.8/8.12.8) with ESMTP id j2BJGaKD027116 for ; Fri, 11 Mar 2005 11:16:37 -0800 Message-ID: <4231EE94.8050601@kfu.com> Date: Fri, 11 Mar 2005 11:16:36 -0800 From: Nick Sayer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.3) Gecko/20041111 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 12 Mar 2005 13:04:38 +0000 Subject: stf and shoebox NAT routers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2005 19:16:38 -0000 Historically, I've used FreeBSD machines as NAT routers. Call me a traitor if you must, but it's getting harder to justify not simply putting one of those little Linksys/Netgear/SMC/whatever NAT routers in place and having the FreeBSD machine be a server behind the box instead. One of the last considerations remaining is IPv6. Most boxes now have the concept of a "DMZ" host. They will, aparently, perform simple address substitution on the IP header for packets that arrive of an unknown protocol and send them to the DMZ host (living on the inside LAN - thus calling it a DMZ host is a bit of a misnomer, but that's a semantic debate for another occasion). This would be ideal for 6to4 - incoming packets would simply arrive and be processed. The trouble appears to be the outgoing side. The machine's actual IPv4 address is not the same as the *outside* IPv4 address, so one of two things is happening (I'm not sure which): Either the blanket prohibition on RFC-1918 addresses having anything to do with 6to4 is getting in the way, or stf0 having a "foreign" prefix (that is, a prefix that does not relate to a physical interface on the machine) is confusing it. 6to4 is the IPv6 connection solution I prefer. Is there any way stf can be taught to live behind an IPv4 NAT?