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