[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Handling rogue RA feedback

On 24-jul-2007, at 18:07, Jun-ichiro itojun Hagino wrote:


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.
Then we fix this in a future version of the document. Obviously this is an unworkable requirement in practice, and I don't see why it should be needed anyway. 


	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?
Redirect is based on destination address, I'm talking about the source address. The number of source prefixes is so low and known by the host anyway that having router feedback for this is not necessary, the host can do this itself without help if implementing this is desired. 


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


That's again for the destination address.


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.


What were the problems or disadvantages of doing that?

Iljitsch