[radvd-devel-l] Overriding of link-local default route?

[Pekka Savola]

On Sun, 7 Dec 2008, Kim Holviala wrote:
> First, some background info: I've have my own /64 allocated by my ISP
> and routed to my through my regular ADSL connection. My problem is that
> while the netblock and the default route work just fine, the router
> advertisements do not. It seems that one of the devices between me and
> my ISP's v6 router doesn't like RA's and messes with them, so whenever I
> connect a device to the v6 network one of three things happens: a)
> everything works, b) I get zero RA's or c) I get RA's just fine, but the
> default route in them is messed up.

Oops.  You should report this issue to your ISP so that they can get 
it fixed.  Everything else is a hack.

> But in the v6 world all goes to hell. I can't set up radvd (or any other
> RA daemon) to serve out my ISP's default gateway (global address,
> link-locals don't go through some devices properly).

What do you mean with the global address not working here?  When the 
ISP sends a RA and it works, it's sent from a link-local address.  So 
everything should still work with link-local addresses.  If it doesn't 
this is another problem that needs to be fixed.

> So the only thing I came up with is to modify radvd to be a "rogue" RA
> daemon which sends out RA packets where the router (default gw) is not
> my radvd servers own link-local but my ISP's global gw address instead.
>
> Is that even theoretically possible? [...]

No, at least no exactly like that.  The relevant spec here is RFC 
4861.  Section 6.1.2 requires that RA messages are sent from a 
link-local address, not a global address.  Hence at least this 
strategy will not work.

Hacking radvd to advertise real router's MAC address might "work", 
with some definition of "work", but would not be reliable.  The thing 
is, with AdvSourceLLAddress (default is enabled) the MAC address is 
included in RA.  This speeds up clients' address resolution process by 
caching the router's link-local address -> MAC address mapping.  The 
problem is that if the client tries to refresh the mapping, the real 
owner of the link-local address (the spoofer) would respond with a 
different MAC address.

It might be possible to also spoof the link-local source address in 
the RA to be the same as the real RA; this might have a higher 
probability of working, but would still be an ugly hack.

Probably the simplest workaround (this has its own limitations as 
well) in this case is to simply manually configure the default route 
on client systems.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings