Date: Fri, 17 Oct 2014 11:28:32 -0700 From: prabhakar lakhera <prabhakar.lakhera@gmail.com> To: freebsd-net@freebsd.org Subject: IPv6 stacks responds to all node link local multicast NS Message-ID: <CALg%2BrhVZFc=vE%2BnZS-hsm%2BUc54kZwzO6N8qThG9uv%2Be-e2uh5w@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
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 <http://fxr.watson.org/fxr/source/netinet6/ident?v=FREEBSD10;im=bigexcerpts;i=IN6_IS_ADDR_MULTICAST>(&daddr6)) tlladdr = 0; else tlladdr = 1;
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CALg%2BrhVZFc=vE%2BnZS-hsm%2BUc54kZwzO6N8qThG9uv%2Be-e2uh5w>