Subject: Re: cloned route handling
To: None <sommerfeld@orchard.arlington.ma.us>
From: None <itojun@iijlab.net>
List: tech-net
Date: 01/27/2001 04:03:05
>> 	Here are proposed changes: (1), (2) should be perfectly adequate
>> 	change.  (3) needs some debate, I'm not sure at this moment.
>> 	Related to (4), we may want to put DoS prevention code for redirect
>> 	floods.
>ok.
>On 3), I would go further, and say that you should be able to
>override/replace any cloned route (even a complete ARP or ND entry)
>with an uncloned route.  (this appears to be the FreeBSD and BSD/OS
>behavior).
>
>Cloned routes are cache entries; if you delete them, they may come
>back.  There's an inherent race condition if you want to add a
>more-specific static route -- the cloned route could come back between
>when you delete the clone and add the real one.

	yup.  makese sense.

	i still wonder if there are some IPv4/6 address families which
	dislikes new behavior.  I'm no expert in sys/netatalk, or
	sys/net{iso,ccitt}.  if any of you (general you) have comment about
	non-IP families, please let me know..

>This also gets in the way of PPP configurations where a ppp server is
>allocated address space for its remote clients from a directly
>connected ethernet subnet and proxy arps for the remote addresses..

	this is exactly what PR11916 is saying.  yes, (3) will solve it.

>on (4), the inactivity timer(s) should be tunable if they aren't
>already.

	it is tunable, by variables like ip_mtudisc_timeout.

itojun