[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20071001.204921.52365121.yoshfuji@linux-ipv6.org>
Date: Mon, 01 Oct 2007 20:49:21 +0900 (JST)
From: YOSHIFUJI Hideaki / 吉藤英明
<yoshfuji@...ux-ipv6.org>
To: brian.haley@...comy, dlstevens@...ibm.com
Cc: davem@...emloft.net, netdev@...r.kernel.org,
yoshfuji@...ux-ipv6.org
Subject: Re: [IPV6] Fix ICMPv6 redirect handling with target multicast
address
Hello.
In article <20070929.100448.41933886.yoshfuji@...ux-ipv6.org> (at Sat, 29 Sep 2007 10:04:48 +0900 (JST)), YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@...ux-ipv6.org> says:
> In article <OF5FC97D70.5FD0A80A-ON88257365.00025E58-88257365.00048D1E@...ibm.com> (at Fri, 28 Sep 2007 17:50:38 -0700), David Stevens <dlstevens@...ibm.com> says:
>
> > Brian,
> > A multicast address should never be the target of a neighbor
> > discovery request; the sender should use the mapping function for all
> > multicasts. So, I'm not sure that your example can ever happen, and it
> > certainly is ok to send ICMPv6 errors to multicast addresses in general.
> > But I don't see that it hurts anything. either (since it should never
> > happen :-)),
> > so I don't particularly object, either.
> > I think it'd also be better if you add the check to be:
> >
> > if (ipv6_addr_type(target) &
> > (IPV6_ADDR_LINKLOCAL|IPV6_ADDR_UNICAST))
> >
> > or something along those lines, rather than reproducing ipv6_addr_type()
> > code
> > separately in a new ipv6_addr_linklocal() function.
I'm fine with the idea of the fix itself.
Please use ipv6_addr_type() so far and convert other users as well
to ipv6_addr_linklocal() in another patch.
Regards,
--yoshfuji
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists