From owner-freebsd-net@FreeBSD.ORG Sat Oct 18 05:39:59 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 83615292 for ; Sat, 18 Oct 2014 05:39:59 +0000 (UTC) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.allbsd.org", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0D4551E7 for ; Sat, 18 Oct 2014 05:39:58 +0000 (UTC) Received: from alph.d.allbsd.org ([IPv6:2001:2f0:104:e010:862b:2bff:febc:8956]) (authenticated bits=56) by mail.allbsd.org (8.14.9/8.14.8) with ESMTP id s9I5dbRH006313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 18 Oct 2014 14:39:47 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.8/8.14.8) with ESMTP id s9I5dZxJ027004; Sat, 18 Oct 2014 14:39:37 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Sat, 18 Oct 2014 14:39:19 +0900 (JST) Message-Id: <20141018.143919.1930138986692891609.hrs@allbsd.org> To: prabhakar.lakhera@gmail.com Subject: Re: IPv6 stacks responds to all node link local multicast NS From: Hiroki Sato In-Reply-To: References: X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.6 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Sat_Oct_18_14_39_19_2014_503)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Sat, 18 Oct 2014 14:39:52 +0900 (JST) X-Spam-Status: No, score=-97.9 required=13.0 tests=CONTENT_TYPE_PRESENT, RDNS_NONE,SPF_SOFTFAIL,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 18 Oct 2014 05:39:59 -0000 ----Security_Multipart(Sat_Oct_18_14_39_19_2014_503)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit prabhakar lakhera wrote in : pr> This probably is more of a compliance issue (or may be not as the NS pr> receipt section of RFC 4861 http://tools.ietf.org/html/rfc4861#page-62 does pr> not talk about it). pr> pr> The neighbor solicitation message format says this: pr> pr> http://tools.ietf.org/html/rfc4861#page-22 pr> pr> pr> Destination Address pr> Either the solicited-node multicast address pr> corresponding to the target address, or the target pr> address. pr> pr> pr> Is it safe to assume that this is a MUST? pr> If yes, nd6_ns_input right now only checks if the destination is a pr> multicast or not (the check is more strict for DAD NS packets) and pr> therefore allows all node link local multicast address resolution NS pr> packets and process them completely (creates neighbor cache, responds pr> with NA etc). What is the problem when accepting NS messages to ff02::1? -- Hiroki ----Security_Multipart(Sat_Oct_18_14_39_19_2014_503)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEABECAAYFAlRB/QcACgkQTyzT2CeTzy05zgCfX7tp1YrsWIoqhmlsFh6RMWxQ Sy4AnRvygNCEvFSxPu38aPZFFBiDdNoj =cslZ -----END PGP SIGNATURE----- ----Security_Multipart(Sat_Oct_18_14_39_19_2014_503)----