[email protected] wrote:
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 less impedance matching that needs to be done in libipadm the
better, because it is error prone and complex.
What I would like to avoid is to wed ipadm to the current notion of
flags on the ipif, and instead base the ipadm model on the MIBs notion
of status for the addresses. Hopefully we can implement something
minimalist in libipadm to make this work.
After that I think we need to evolve the kernel to be closer to that
ipadm/MIB model. For instance having AF_LINK as the address for bge0:0,
and having some way to retrieve address flags separate from interface
flags (SIOCGLIF* with both the name and the address specified?).
It might make sense to rename the current IFF_ flags that relate to
address status as IFA_ instead to make things more clear to the reader
(perhaps we need to keep their IFF_ aliases for compatibility.)
I don't think the code changes would be significant for doing that, but
they need some careful thought, and they can be done after ipadm phase 1.
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.
But my question is how would the address become invalid?
The only cases I know of is when in.ndpd (and I guess the dhcpv6 client)
times it out because the valid timer expires, and in that case the
address is removed from the kernel.
Introducing IFF_TENTATIVE and IFF_OPTIMISTIC would complete the picture.
(what would the distinction between tentative and optimistic be?
wasn't clear to me)
Different protocol - regular DAD vs. optimistic DAD. The latter might
still be an I-D and not an RFC.
Erik
_______________________________________________
networking-discuss mailing list
[email protected]
