Hi, Karl
Thanks for your reply, now I understand your arguments clearly.
I think our common view is "ambiguity in not good". Then your way is just
deprecating them; if don't deprecate, then make it clear. But I just have the
opposite approach: since it's ambiguous, we need at least make them clear, and
beyond, we need more SLAAC/DHCPv6 interaction than the original M/O flags
semantics.
Let me explain what are "the current problems":
[1]. Renumbering problems.
In RFC5887(Renumbering still needs work), section 5.1.1 says clearly:
"Until this ambiguous behaviour is clearly resolved by the IETF,
operational problems are to be expected, since different host
operating systems have taken different approaches. This makes it
difficult for a site network manager to configure systems in such a
way that all hosts boot in a consistent way. Hosts will start SLAAC,
if so directed by appropriately configured RA messages. However, if
one operating system also starts a DHCPv6 client by default, and
another one starts it only when it receives the M bit, systematic
address management is impeded."
Our test had identified the host OSes have tanken different apporoaches. For
the above mentioned "systematic address management" , we already discussed
several instance, as I described in the draft:
- The site manager wants the host to do DHCPv6 when online. Current
practise is sending RA M=1 and don't include PIO, however, how the OSes will
behave is not controlled by the site.
- The site manager wants the SLAAC-configured hosts to do DHCPv6 (e.g.
adding a multihomed uplink who uses DHCPv6 for address configuration). For
some OSes, there's just no availeble method.
- The site manager wants the DHCPv6-configured hosts switch to SLAAC. If
you don't interprete M=0 as prescriptive, the only way is either just waiting
for the DHCPv6 lease time expires, or initial DHCPv6-reocnfiguration from the
server side. But I don't think it is an efficient way when renumbering. If
the lease time is too long, the problem is more serious. For
DHCPv6-reocnfiguration, it is only unicast, and stateful, not proper for bulk
use.
[2] Requirement from ISP
ISPs have strong requirement of strictly controlling the CPE behaving as they
expect. There's an instance I learned, an ISP deployed stateless DHCPv6 in
their IPv6 network, which means they required the CPE to
configure addresses through SLAAC and other parameters through DHCPv6. Since
the ambiguity in standard, they had to directly specify the requirements to the
CPE vendor, which means, universal CPE may not be availeble in IPv6 networks
unless we have clear definition in standard.
[3] I think Alexandru's argument of mobile nodes is another good example.
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 17:08
To: IETF IPv6; re...@ietf.org
Subject: RE: about DHCPv6/SLAAC interaction
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 (ka...@biplane.com.au)
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
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
