At Tue, 14 Oct 2008 07:48:32 +0300 (EEST), Pekka Savola <[EMAIL PROTECTED]> wrote:
> I don't see why M/O bits would need to be completely deprecated (they > could still be hints about what should be available in the network). > > I've yet to see a DHCPv6 client implementation that would listen to > the flags in RA and conditionally start or stop the service depending > of the presence of flags there. It's more complex to implement and to > operate reliably. But granted I haven't done an extensive survey; I'd > be interested in knowing how existing implementations operate. Just FYI, KAME's "router solicitation daemon" has an ability to invoke a specified program (which is expected to be a DHCPv6 client) when it sees the O flag of RA change from false to true. It's incorporated into (at least) FreeBSD. It doesn't support the M flag, though. I generally agree with your other points, specifically, - implementors will tend to ignore these flags even if a new spec prohibits DHCPv6 invocation more strongly when M/O bits because that *may* help if a DHCPv6 server happens to be there (they'd rather avoid the situation where configuration fails simply because the M/O bits are off) - 802.11 airtime issue is not convincing enough, at least without concrete numbers to prove its severity, to discourage such tendency of implementors. --- JINMEI, Tatuya Internet Systems Consortium, Inc. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
