From owner-freebsd-net@FreeBSD.ORG Fri Oct 17 18:28:34 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 2DE78EC0 for ; Fri, 17 Oct 2014 18:28:34 +0000 (UTC) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E58ECBC4 for ; Fri, 17 Oct 2014 18:28:33 +0000 (UTC) Received: by mail-qc0-f171.google.com with SMTP id i17so1029811qcy.2 for ; Fri, 17 Oct 2014 11:28:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=QRwDxspfMaQIGKgWho3LdBOz8jfitOAeIfSMqQvgqn4=; b=Xo3swDipjCiAMfWyxCmQ+E9lKlODlaVyPuXs2tPPA2q7E3YXxtJQggBdrW7InUF/fA ay0DNdQOGFrzpZXJ2XynxKQByrTkidPcRuF4o0xI/oTsN0e42ZL0zJcjCG5cHhwEjslT OsYDLWsxy13W2NuFUxGLJxpoi/GEfr6tVn+MwP1Y0g1fER+PnsVMoIgeB7qt10UEyCd5 c+XVR9wAPCKeisF8g7DX1NV0gsnIDvzI218NbO+zcCGFBu6ZbEf4ELauoV7Ef81wn9PV NXEWz2meswKEafH3OpAwNiTxsnFUxunWma8H+AZGsYDcSlAI3vr/c/HrcG5dWPkDqQfA kCnQ== MIME-Version: 1.0 X-Received: by 10.140.83.203 with SMTP id j69mr13953448qgd.89.1413570512987; Fri, 17 Oct 2014 11:28:32 -0700 (PDT) Received: by 10.140.48.105 with HTTP; Fri, 17 Oct 2014 11:28:32 -0700 (PDT) Date: Fri, 17 Oct 2014 11:28:32 -0700 Message-ID: Subject: IPv6 stacks responds to all node link local multicast NS From: prabhakar lakhera To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 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: Fri, 17 Oct 2014 18:28:34 -0000 This probably is more of a compliance issue (or may be not as the NS receipt section of RFC 4861 http://tools.ietf.org/html/rfc4861#page-62 does not talk about it). The neighbor solicitation message format says this: http://tools.ietf.org/html/rfc4861#page-22 Destination Address Either the solicited-node multicast address corresponding to the target address, or the target address. Is it safe to assume that this is a MUST? If yes, nd6_ns_input right now only checks if the destination is a multicast or not (the check is more strict for DAD NS packets) and therefore allows all node link local multicast address resolution NS packets and process them completely (creates neighbor cache, responds with NA etc). The fix is simple, however I wanted to know if there was some reason to have it like this in the first place?: */** ** Attaching target link-layer address to the NA?* ** (RFC 2461 7.2.4)* **** * NS IP dst is unicast/anycast MUST NOT add* ** NS IP dst is solicited-node multicast MUST add** ** ** In implementation, we add target link-layer address by default.* ** We do not add one in MUST NOT cases.** */* if (!IN6_IS_ADDR_MULTICAST (&daddr6)) tlladdr = 0; else tlladdr = 1;