On (04/23/09 20:55), Erik Nordmark wrote: > > Thus we might need new IFF_ values the same way that BSD has new > IN6_IFF_ values for these.
One basic question: when we talk about all the flags here, are we considering rehauling the kernel to handle these flags, or having libipadm do the needed mangling (that quagga struggles to do today) to produce consistent results to a caller requesting addr flags status and interface flags status? I was thinking of the latter. >> The MIB also specifies tentative(6) and duplicate(7) as distinct >> values. So one solution (if we want to strictly adhere to rfc 4293) >> is to have libipadm return >> preferred(1), <-> default value (see CR 6832315) >> deprecated(2), <-> IFF_DEPRECATED >> invalid(3), <-> ~IFF_UP on the address (also covers DAD >> failed) > > I think either we need a new IFF_INVALID or we rely on in.ndpd deleting > an address when it becomes invalid so we never return 3. In my model, INVALID would be returned for an address-state flag. >> inaccessible(4), <-> ~IFF_DOWN on the interface > > But it would be good to have a separate flag for this, since it allows > the case when the IP interface goes missing but we want to keep the > address objects around. Thus IFF_INACCESSIBLE. > Note that it might make sense to have an IFF_MISSING for the IP > interface, and in that case we could have IFF_MISSING on the addresses > to mean inaccessible. > >> unknown(5), >> tentative(6), <-> DAD initiated >> duplicate(7), <-> DAD failed >> optimistic(8) > > Introducing IFF_TENTATIVE and IFF_OPTIMISTIC would complete the picture. (what would the distinction between tentative and optimistic be? wasn't clear to me) >> And we could leave the IFF_UP flag on both the ill and the interface >> for the moment. > > ill == interface. Did you mean address and interface? yes. --Sowmini _______________________________________________ networking-discuss mailing list [email protected]
