I fully agree with the chair's decision to leave the M/O bits unchanged for now.
I would like to quickly address (comments inline) the security argument that was raised by Alain. Alain, > It is not that DHCPv6 cannot be made secure, it is that the M/O bits are > an automatic and insecure way to trigger an external configuration > mechanism. Well, but so is the whole method of sending RAs. Frankly, malicious DHCPv6 servers or RA "emitters" are easy to detect and I don't see any change in the threat level no matter if the M/O bits are there or not. An administrator needs to keep an eye on each broadcast domain where RAs are sent and where DHCPv6 is deployed anyhow to make sure that no malicious information is sent by rogue machines. If that is done, sending configuration hints to clients is a very useful feature in my eyes. > Host should not blindly believe this unless the RA are secured. That is true. But until this is achieved by some kind of additional mechanism, I don't see why having the M/O bits adds to the danger. Securing RAs is another issue. One final comment I would like to add to the implementation discussion (in parallel threads) is that NEC's DHCPv6 reference implementation also included support for M/O bits. And since this implementation was used for major DHCPv6 plug tests (e.g. by ETSI, etc.), we shouldn't neglect it. Christian -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
