Re: Handling rogue RA feedback

[itojun@itojun.org (Jun-ichiro itojun Hagino)]

> On 24-jul-2007, at 17:11, Jun-ichiro itojun Hagino wrote:
> 
> > 	i'll try to summarize what i know of about handling rogue RAs.
> 
> [...]
> 
> Another option would be for hosts to do something similar to neighbor  
> unreachability detection for their default gateway.
> 
> One thing that annoys me to no end is that if router X sends out  
> prefix A::/64 and router Y sends out B::/64, then node 1 will happily  
> configure addresses A::1 and B::1, and then send out packets with  
> source address A::1 over router Y. This is really a bad thing for  
> efforts like shim6.

	first of all, the above configuration violates RFC.  all routers has
	to be configured with consistent RA parameters iirc.  i know it is not
	practiced in reality.

	however, ICMPv6 redirect should take care of it if there's any issue
	with that.  anything wrong with redirects, other than getting
	(potentially tons of) /128 routes?

	also, "RAs with more specific route" (RFC4191) may help you assuming
	router Y is not a rogue router.

> So trying to use the router that gave you the prefix for the source  
> address you're using is a good start. The next one would be to avoid  
> routers that announce obviously tunneled reachability such as 6to4 or  
> Teredo.

	we've been there with KAME, and we conclued it is a bad idea to
	tie prefixes/source address selection to routers/RAs.

itojun