> > > I know; I'm asking about what's intended. When DHCP starts normally, > > > the interface is "down" and DHCP marks it as "up" so that it can do > > > its thing. I'm really asking about when DHCP knows it ought to do > > > that and when it should leave the administrator's IFF_UP flag (or lack > > > thereof) alone. > > > > I see. For IPv4, we could pass a flag to open_ip_lif() telling it whether > > this is the initial bringup of the interface (due to the administrator > > issuing a "start") or a subsequent restart (due to expiration or DAD). It > > could then leave the IFF_UP flag as-is in the restart cases. For IPv6, it > > appears the code does not have any special IFF_UP handling for the > > link-local and just assumes it's IFF_UP, so I think it's unaffected. > > OK. So, the intent is that IFF_UP doesn't get molested even if DHCP > might somehow learn a new reason (other than 'dhcp start', which seems > clear-cut) for the interface to be marked "up" once again.
Yes. > > > In other words, change of lease data from the DHCP server means "apply > > > these changes now to the system." But otherwise DHCP isn't in the > > > business of trying to make sure that the interface matches what's set. > > > It's a configuration mechanism, not a nanny. > > > > Hmm, I'm not sure about this, but I also don't think this case is too > > important to the core topic at hand. > > True ... I'm thinking about the limits so I know where we could be > going and the principle behind the "don't mind that flag" change. To me, it's appropriate to abandon in cases where the interface's current configuration has been made incompatible with the configuration the DHCP client configured (and is supposedly maintaining as per IFF_DHCPRUNNING). Clearing the IFF_UP flag doesn't render the configuration incompatible, but just affects the ability for the DHCP client to renew the lease -- so it seems preferable to just let that resolve itself per the protocol. -- meem
