On Wed, 2 May 2001, Pekka Savola wrote:
> In net/ipv6/ndisc, ndisc_router_discovery function, where IPv6 router
> advertisements are being processed, there is no check that RA is coming
> from link-local address.
The following patch (note! untested!) should do it. Copied with small
modification to the printk from ndisc_redirect_rcv:
--- ndisc.c~ Mon Apr 30 12:12:44 2001
+++ ndisc.c Thu May 3 13:32:37 2001
@@ -587,6 +587,11 @@
return;
}
+ if (!(ipv6_addr_type(&skb->nh.ipv6h->saddr) & IPV6_ADDR_LINKLOCAL)) {
+ printk(KERN_WARNING "ICMP RA: source address is not
linklocal\n");
+ return;
+ }
+
/*
* set the RA_RECV flag in the interface
*/
>
> As far as I know, all implementions do use link-local addresses for
> sending advertisements. RFC2461, 4.2 says:
>
> ---
> 4.2. Router Advertisement Message Format
>
> [...]
> IP Fields:
>
> Source Address
> MUST be the link-local address assigned to the
> interface from which this message is sent.
> [...]
> ---
>
>
> KAME does this:
> ---
> if (!IN6_IS_ADDR_LINKLOCAL(&saddr6)) {
> log(LOG_ERR,
> "nd6_ra_input: src %s is not link-local\n",
> ip6_sprintf(&saddr6));
> goto freeit;
> }
> ---
>
> As hop limit is verified to be 255, this could only be misused by on-link
> hosts.
>
> Note that there is in net/ipv6/route.c:
>
> ---
> /* IPv6 strictly inhibits using not link-local
> addresses as nexthop address.
> Otherwise, router will not able to send redirects.
> It is very good, but in some (rare!) curcumstances
> (SIT, PtP, NBMA NOARP links) it is handy to allow
> some exceptions. --ANK
> */
> ---
>
> I wonder what these circumstances are, exactly. Sit tunnels usually do
> use global addressing, and next hop is non link-local (on KAME too), but
> that doesn't mean those wouldn't have link-local address at all.
>
> What do you think?
>
>
--
Pekka Savola "Tell me of difficulties surmounted,
Netcore Oy not those you stumble over and fall"
Systems. Networks. Security. -- Robert Jordan: A Crown of Swords
|