Subject: Re: [renum] about DHCPv6/SLAAC interaction

From: "Liubing (Leo)" <[email-masked]>
Date: Wed, 1 Aug 2012 20:35:48 +0000

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: [email-masked] [[email-masked]] on behalf of Karl Auer [[email-masked]]
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:

......

---

From: "Liubing (Leo)" <[email-masked]>
Date: Thu, 2 Aug 2012 04:23:09 +0000

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: [email-masked] [[email-masked]] on behalf of Karl Auer [[email-masked]]
Sent: Wednesday, August 01, 2012 17:08
To: IETF IPv6; [email-masked]
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 ([email-masked])
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-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Karl Auer <[email-masked]>
Date: Thu, 02 Aug 2012 10:08:29 +1000

Regards, K.

---

From: Tore Anderson <[email-masked]>
Date: Thu, 02 Aug 2012 10:20:41 +0200

* Karl Auer

> - 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.

RFC 4861 section 4.2 seems to me to be pretty clear about this:

«If the M flag is set, the O flag is redundant and can be ignored
because DHCPv6 will return all available configuration information.»

So the operational value of O is (M OR O), as I understand it.

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com