Sowmini.Varadhan at Sun.COM writes: > - Jim pointed out some issues about IFF_UP's history which were the > reasons for reusing IFF_UP as the enable/disable flag for DAD. > The ramification of this choice is that one needs to mark an interface > as "up" to retry DAD, while the kernel will keep marking it down > as long as DAD keep failing.
I'm not quite sure what you meant here, but there's no need for administrative action to recover a DAD-failed interface. The system runs a timer on all DAD-failed interfaces and periodically tries to bring them back up. This is the solution to the "closet server" problem described in the design document. Thus, I don't quite agree with the "one needs" portion of the paragraph quoted above, unless the "one" here is the kernel itself. > A possible long term solution would be > - have the 0'th address to be AF_LINK. The IFF_UP flag on this AF_LINK > is the interface flag. The IFF_UP flag on every subsequent IP Weird, but elegant. > address (starting at :1) is the "enabled"/"disabled" flag on the address. Actually, you could send up the zeroth one as "foo0:0". Then "foo0" (as seen to users of SIOCGIFCONF) would refer only to the hardware instance. It's a substantial change, but it sounds like an interesting one. > We should provide some library function that takes a sockaddr as > input and returns a logical interface name as output to help out > applications that have to muddle through GLIFCONF today. That's a subset of what BSD's if_addrlist gives you. I guess a new function could be added as well, but if nobody uses it on other platforms, why bother? > And while we are about it, we should also support getifaddrs() as Meem > suggested. I'd venture that the ifa_name returned should be the > logical interface name, since this is just a better GLIFCONF. > Note that BSD's getifaddrs is itself essentially a wrapper around > GIFCONF, and actually reports AF_LINK addresses as well (i.e., it > would be a LIFC_NEW_APP in my proposal above). Yes. The lack of AF_LINK there has been a sticking point with some BSD compatible applications. :-< -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
