Hi Yoshifuji,
> Well, I think the problem is to set RTF_ADDRCONF flag to all prefix routes.
I don't think we should change that, RTF_ADDRCONF should be set for all RA
routes not just the prefix route. But I agree with your other comments,
that RTF_ADDRCONF must not be used when configuring routes from user space.
The filtering should check for both the flag as well as whether it is a
prefix route entry.
I guess I will work on sending messages for both prefix list changes and to
get entire prefix list.
thanks,
- KK
YOSHIFUJI Hideaki wrote:
In article <3EEF7E09.8080608@xxxxxxxxxx> (at Tue, 17 Jun 2003 13:46:01 -0700),
Krishna Kumar <krkumar@xxxxxxxxxx> says:
I have a question about the following, which seems to be the
approach both of you prefer. I thought we need a new routing
message type called RTM_GETPLIST which will return full prefix
list. If you use RTA_RA6INFO, then should that trigger only
when the prefix list has changed (add or delete) ? Should I
have both interfaces, one for returning entire list (RTM) and
one for changes in prefix list (RTA) ?
Please let me know if my understanding is correct.
Well, I think the problem is to set RTF_ADDRCONF flag to all prefix routes.
I beleive this should be for autoconf (RA) routes only as comments says;
dad_starts and multicast add routes with such flag, but this should be wrong.
After we fix this, we can get prefix information filtering routes by
RTF_ADDRCONF flag; of course, we can get the routes using RTM_GETROUTE.
|