Pekka,
Actually, the lack of M or O bits is not as good a hint as their existence. If we wanted a _good_ hint about non-existence of DHCPv6 (for addresses or config information), we'd have to have different flag(s) like "Yes, I'm aware of what DHCPv6 is, but we don't use it in this network". That allows disambiguation from "Yes, we do have a couple of DHCPv6 servers, but we weren't aware you should configure this stuff in the RAs, because with v4 you don't".
This still seems to be to be fairly equivalent. I think the important function is if there is a DHCPv6 server and the site want the clients to use it, then they should set the "m" and "o" bits. I don't see very much value in conveying the negatives (e.g., we have a DHCPv6 server, but we don't want the clients to use it, we don't have a DHCPv6 server so don't try looking for one, we didn't set up a relay, etc., etc.).
But I'm not sure that disambiguation is worth the effort.
Agreed.
That said, I support the clarification. In a sense I agree with Thomas et al that the ra-mo-flags spec goes beyond the bare minimum what the IETF specifications must specify -- it documents the policies and behaviours which most vendors would implement in any case, but these kind of knobs have often been left out of our specs. However, as there has been so much confusion and discussion of M/O flags, I think this specification is useful, and also allows vendors (who want to) to implement the knobs in a uniform manner.
Part of me is starting to think that we might be better off waiting for there to be more operational experience with deployments of DHCPv6 to see how much confusion there really is. I agree it is good for vendors to implement similar knobs, but I wonder how much of a problem there really is.
Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
