[email protected] wrote:
the MIB specifies
The invalid(3) state indicates that this isn't a valid
address and it shouldn't appear as the destination or source
address of a packet.
The inaccessible(4) state indicates that the address is not
accessible because the interface to which this address is
assigned is not operational.
I suppose you could treat (3) as ~IFA_UP, and (4) as ~IFF_UP.
I don't think we have a easy mapping to existing IFF flags for all of
these, especially due to over bge0 and bge0:0 being the names of an ill
and ipif.
Thus we might need new IFF_ values the same way that BSD has new
IN6_IFF_ values for these.
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.
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 has been initiated. Note that we can't actually display this today, as Jim describes
in Section 5.1 of his design doc.
duplicate(7), <-> DAD failed
optimistic(8)
Introducing IFF_TENTATIVE and IFF_OPTIMISTIC would complete the picture.
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?
Erik
_______________________________________________
networking-discuss mailing list
[email protected]
