From owner-freebsd-net@FreeBSD.ORG Thu May 7 14:41:26 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 0EB73106566B for ; Thu, 7 May 2009 14:41:26 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id D7D398FC1B for ; Thu, 7 May 2009 14:41:25 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 20329341376; Thu, 7 May 2009 10:41:25 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Thu, 07 May 2009 10:41:25 -0400 X-Sasl-enc: JdWSRSwRcEvkhwUJQmB4/AwDPsafsm0PbApgTwHpNvmL 1241707284 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 626C9DCB1; Thu, 7 May 2009 10:41:24 -0400 (EDT) Message-ID: <4A02F30F.5030704@incunabulum.net> Date: Thu, 07 May 2009 15:41:19 +0100 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Bob Van Zant References: In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= , "freebsd-net@freebsd.org" Subject: Re: IPv6 duplicate address detection 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: Thu, 07 May 2009 14:41:26 -0000 Bob Van Zant wrote: > Well that goes all the way back to my first email :-) > > "An alternative view on this is that I shouldn't be sending out any packets, > especially unsolicited NAs, using or referencing a tentative address." > > This makes sense. I'll stop doing bad things now :-) Thanks for your input > and clearing this up for me. > OK, I'm very glad Jinmei-san has chewed over the specifics of how this might break DAD as specified. All the same, you did find a condition in the kernel where locally-originated traffic is being interpreted as being on-wire. Ok, SOCK_RAW is going to raise the bar on malefeasant use of this behaviour, but all the same, this is an input checking issue :-) It would be great if you could go ahead and raise a PR about this condition -- the MLDv2 code in HEAD will also be affected by this, as it does an IPv6 group membership check on the icmp6 input path. Strictly speaking it should come from ip6_mloopback(), but right now I can't remember if that will set any mbuf flags; I do believe it sets m->m_pkthdr.recvif to loif and that might be the only coherent way to detect the looped back traffic w/o doing an address lookup. cheers, BMS