On (04/22/09 11:50), Peter Memishian wrote:
> I don't know what this has to do with my point. I will note that there is
> a lengthy discussion on IFF_UP, IFF_DUPLICATE and other trade-offs in
> Jim's excellent DAD design doc. I need to re-read it myself to ensure I
> remember all the subtleties here if we're really going to attempt to
> redesign it as part of Brussels.
I looked at the design doc. It describes the existing behavior and
mentions that we are not currently implementing a "dad in progress"
state, though we could in the future. Other than that, I did not see
any discussion of the trade-offs. Then I looked at the code to see
where we actually deal with IFF_UP in the context of DAD. There's
dad_wait(), but that just waits and returns a well-defined status
(i.e., implementation details are not exposed to the caller). Then
there was some complicated code in ifconfig.c that I don't fully
get (with all its comments)
/*
* If the user is trying to mark an interface with a
* duplicate address as "down," or convert a duplicate
* test address to a data address, then fetch the
* address and set it. This will cause IP to clear
* the IFF_DUPLICATE flag and stop the automatic
* recovery timer.
*/
(I think the comment could use some clarification- in the first
line, it's trying to mark the *logical* interface as down, not the
physical, right?)
In the case described as "convert a duplicate test
address to a data address", the data address is still going to be
duplicate until DAD succeeds, right?
A duplicate address should already be down, so why can't we just delete
that address?
it seems like too much information about the implementation has trickled
into the /sbin application in this case, and we should try to avoid that,
at least.
On (04/22/09 14:51), Erik Nordmark wrote:
> See the string "duplicated" in RFC 4293. That matches relatively closely
(the search string is "duplicate")
> what is in freebsd, but the MIB has that status for IPv4 and IPv6.
>
> But the MIB doesn't have a notion of up/down for an address, hence the
> mismatch with current Solaris behavior.
>
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.
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)
inaccessible(4), <-> ~IFF_DOWN on the interface
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)
And we could leave the IFF_UP flag on both the ill and the interface
for the moment.
--Sowmini
_______________________________________________
networking-discuss mailing list
[email protected]
