[radvd-devel-l] Overriding of link-local default route?
pekkas at netcore.fi
Sun Dec 7 09:25:20 EST 2008
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
More information about the radvd-devel-l