On Wed, 2012-08-01 at 20:35 +0000, Liubing (Leo) wrote: > May I venture to argue that, "had been discussed before" might not be > reasonable enough to deal with current problems.
What exactly are "the current problems"? It seems to me there are only two: - it is not explicit whether M means a host "must", "should" or "may" use DHCPv6 to obtain an address. It is fairly clear in practice that this is a "should" - it is not explicit that the M and O flags are completely independent of each other. Common practice is to treat them as independent, and I can see no good reason to link them in the RFC or anywhere else. - there is a question about whether a host obtaining a DHCPv6 address should NOT perform SLAAC. Since the RFC certainly doesn't say it should, it is a mystery to me why people think DHCPv6 excludes SLAAC. Access to addresses via DHCPv6 can be completely controlled on a subnet by subnet basis in the DHCP server, and SLAAC can be completely controlled on a subnet by subnet basis using the autoconf flag in RAs. - if I were King of the World I would deprecate both flags. They serve no useful purpose. > this real-network problem may be much more sensitive than we > imagined/discussed to be when writing RFC4862. Again, I don't see the issue(s) here. > So, my personal preference is similar with Karl's, we might need > additional flags to cover the SLAAC/DHCPv6 interaction semantics. That is NOT my preference. My preference is to deprecate both flags. My second preference is to clarify as above. All that stuff about additional flags was thinking aloud about how M/O could be made mandatory; it was certainly NOT a suggestion that they *should* be made mandatory. > And in 6renum, we also discussed some new semantics requirements (see > in the draft, and the section 5.1 in 6renum WG item: > http://tools.ietf.org/html/draft-ietf-6renum-gap-analysis-02 ), I've just read that doc and as far as DHCP and SLAAC go, it seems to be composed mostly of questions. I really think the draft should state what the *problems* are that it seeks to solve. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer ([email protected]) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
