prabhakar lakhera <prabhakar.lakh...@gmail.com> wrote in <CALg+rhVZFc=ve+nzs-hsm+uc54kzwzo6n8qthg9uv+e-e2u...@mail.gmail.com>:
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
pgpRaT37EprkC.pgp
Description: PGP signature
