From owner-freebsd-net@FreeBSD.ORG Sat Mar 10 00:02:59 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 260E2106564A for ; Sat, 10 Mar 2012 00:02:59 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id E0BA414D81A; Sat, 10 Mar 2012 00:02:58 +0000 (UTC) Message-ID: <4F5A9A34.8080303@FreeBSD.org> Date: Fri, 09 Mar 2012 16:03:00 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Alex Yong References: In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Strong host model in IPv6? 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: Sat, 10 Mar 2012 00:02:59 -0000 So I guess I'll re-ask the question here: According to https://tools.ietf.org/html/rfc1122 that RFC has been updated quite a bit over the last 23 years. Have you followed that chain upwards to make sure that your concerns are still valid? Doug On 3/9/2012 3:26 PM, Alex Yong wrote: > (Originally posted on freebsd-hackers@ - sorry) > > Hi all, > > I've been playing around with IPv6 networking on FreeBSD release 8.2 and > found that there seems to be no strong incoming host model as specified in > RFC 1122. > > I've spotted that in IPv4 there is the sysctl "net.inet.ip.check_interface" > which defaults to set, but I've been unable to find any guarantees that > strong host model is enforced in v6 in the comments or internet. According > to the IPv6 Core Protocols Implementation book (3.7 "Input processing: > ip6_input() Function") the incoming network packet processing in ip6_input > should use the routing table to look up whether packets are of relevance > for an interface - but the code base has diverged significantly since then > including vnets for jails which makes me wonder if this is a bug. However > before going into the long grass and trying to fix it I thought I'd ask > here to see if there's anything I could try first, if I'm making some > horrific mistakes, or if somebody had come across this already (I had a > quick look at svn but didn't see anything of concern). > > My recipe for reproducing is thus: > > One FreeBSD 8.2 machine (the box under test), with 2 network interfaces > (interface 0 and interface 1). interface 0 is connected to a subnet with > routes to the outside world on v4 and v6. Interface 1 is connected > directly via ethernet cable to the interface of a testing machine, with v4 > disabled and a static v6 address for an unroutable subnet via the other > interface. A route is configured for this subnet out of interface 1 (to > allow for communications with the testing machine). > > The testing machine (which happens to be running FreeBSD) has 2 network > interfaces (interface A and B). Interface A is connected to the same > subnet as interface 0 (this is for my administration prodding of the > testing device), and interface B is directly connected to interface 1 on > the machine under test. Interface B has a staticly configured IPv6 address > that matches the subnet of interface 1. It has a route to allow traffic to > flow this way, *and* a route configured to route traffic for the box under > tests interface 0 IPv6 address via interface B. > > If I ping interface 0 from box 1, I get a response. To prove that the > response isn't coming in via the other links I used tcpdump on that > interface on the testing machine *and* the machine under test and showed > packets entering and responses leaving those interfaces. My expectation > here would be to see packets entering (as the bpf hook is below the IP > layer) but see no response. > > I checked sysctl net.inet6.ip6.forwarding is set to 0 (on both machines). > > Many thanks for any help > > AlexY -- This .signature sanitized for your protection