On 8/1/2012 5:58 PM, Alexandru Petrescu wrote:
> Le 01/08/2012 13:35, Liubing (Leo) a écrit :
>> 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.
>
> I will not oppose any initiative to improve the ambiguous situation of
> the M/O flags.
>
> The choice today is more than b/w 'if M then DHCP is available otherwise
> SLAAC'. Both DHCP and SLAAC advanced towards doing what the other does,
> and it is _still_ possible to need some features from one and some from
> the other - it's still impossible to use just one for everything. (eg
> RA doesnt PD, DHCP doesnt MTU, and more)
I've been following this discussion with interest because to be honest
I've never understood the subtleties of the M/O bits. But I think that
Alexandru just hit on the real problem here.
We need to fix DHCPv6 so that it can be a complete solution first (and
of course, keep the feature freeze on SLAAC/RA in place). Then the whole
M/O thing gets much, much simpler.
Doug
--
I am only one, but I am one. I cannot do everything, but I can do
something. And I will not let what I cannot do interfere with what
I can do.
-- Edward Everett Hale, (1822 - 1909)
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
