Hi, all Firstly, thanks for Karl's elaborate analysis and solution proposal for the M/O issue. I think that's definitely reasonable reference if we want to fix the issue.
But as some comments showed in this morning's 6man meeting, some people thought it is not necessary to fix the M/O issue in standard, because it used to be long discussions about it, and current SLAAC standard (RFC4862) was just based on the discussion result at that time. May I venture to argue that, "had been discussed before" might not be reasonable enough to deal with current problems. I think the situation has changed since the RFC4862 published, more and more real IPv6 deployments are emerging, then people find it is quite confusing of the ambiguous M/O definition, this real-network problem may be much more sensitive than we imagined/discussed to be when writing RFC4862. We have two address autoconfiguration modes (SLAAC/DHCPv6) in IPv6, which is one of the most significant differences between IPv4, people who have really deployed IPv6 may notice more importance of SLAAC/DHCPv6 interaction than we discussed before, at least I've learned the requirements from both offline and on the mics, maybe it is not comprehensive enough, but at least it's considerable. So, my personal preference is similar with Karl's, we might need additional flags to cover the SLAAC/DHCPv6 interaction semantics. 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 think they are also considerable. Regards, Bing ________________________________________ From: ipv6-boun...@ietf.org [ipv6-boun...@ietf.org] on behalf of Karl Auer [ka...@biplane.com.au] Sent: Wednesday, August 01, 2012 03:14 To: IETF IPv6 Subject: Re: about DHCPv6/SLAAC interaction On Wed, 2012-08-01 at 01:06 +0000, Liubing (Leo) wrote: > You mentioned the ambiguous M flag in RA, indeed this is a problem, > and it has been disscussed in 6renum WG. > > So if you're still consern about the issue, looking forward to hear > some comments from you, either on the mics or in the mail. [Leo sent me the above off list, but I post my reply here with his permission] Thanks! A host should always be allowed to do DHCPv6 in the *absence* of information to the contrary; this is no different to NOT doing DHCPv6 in the absence of information. Also, a host may be in a self-contained or isolated network, i.e., one without a router, but with a DHCP server. So NOT receiving RAs is no reason NOT to do DHCPv6. Nor is it a reason to do it either, of course - i.e., it's up to the host :-) I'll preface all this my saying that I think the M and O flags as generally implemented and used are pretty much useless. The best thing to do with them would be to deprecate them altogether. If they must be retained, then I feel that the semantics should be as follows, and as far as I can tell from the RFC, this is all allowed: ...... -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
