Subject: Re: about DHCPv6/SLAAC interaction

From: Karl Auer <[email-masked]>
Date: Wed, 01 Aug 2012 20:14:17 +1000

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:

The O and M flags are completely independent. The O flag implies nothing
about address configuration, and the M flag implies nothing about
whether ancillary information is available. Clarifying those points
alone would make the RFC much more useful.

A valid RA can contain both the O and the M flags.

The M and O flags are advisory:
   - a host MAY attempt to obtain an address via DHCPv6
     without seeing an RA at all. Rationale: The host may be in an
     isolated network, containing a DHCPv6 server, but no router.

   - a host MAY attempt to obtain an address via DHCPv6 even
     if it sees an RA with no M flag. Rationale: Not all routers are
     necessarily "authoritative"; there may be multiple routers on a
     link, not all of which are advertising an available DHCPv6 server.

   - a host MAY attempt to obtain ancillary information via DHCPv6
     without seeing a RA at all.  Rationale: The host may be in an
     isolated network, containing a DHCPv6 server, but no router.

   - a host MAY attempt to obtain ancillary information via DHCPv6
     even if it sees an RA with no M flag. Rationale: Not all routers
     are necessarily "authoritative"; there may be multiple routers on
     a link, not all of which are advertising an available DHCPv6
     server.

Once a DHCPv6 address has been configured or ancillary info obtained:
   - a host MAY deconfigure a DHCPv6 address if an RA is seen
     that does not contain an M flag. Rationale: In the absence of
     any compulsory aspect to DHCPv6, the deconfiguration of addresses
     that were "voluntarily" acquired must logically be permitted.

   - a host SHOULD deconfigure a DHCPv6 address if an RA is seen
     that does not contain an M flag IF that address was configured
     in response to an M flag. Rationale: If the reason the host
     configured the address was because it reacted to an M flag, then
     it should react to the absence of M flags by deconfiguring the
     address. That is, the host should be consistent in its approach
     to the M flag.

Once ancillary information has been obtained via DHCPv6:
   - a host MAY discard ancillary information obtained via DHCPv6
     if an RA is seen that does not contain an O flag. Rationale: In
     the absence of any compulsory aspect to DHCPv6, the disposal of
     ancillary information "voluntarily" acquired must logically be
     permitted.

   - a host SHOULD discard ancillary information obtained via DHCPv6
     if an RA is seen that does not contain an O flag IF that
     information was obtained in response to an O flag. Rationale: If
     the reason the host obtained ancillary information was because it
     reacted to an O flag, then it should react to the absence of O
     flags by discarding the information. That is, the host should be
     consistent in its approach to the O flag.

The above are the "non-strict" semantics. If a stricter approach is
needed, I suggest an additional flag that, if set, changes the M and O
flags from advisory to prescriptive. Let's call it the DHCP_STRICT flag.
The flag MUST default to FALSE. Because the *absence* of an M or O flag
is meaningful in strict mode, we also need a flag that indicates whether
the DHCP_STRICT flag itself is meaningful, let's call it
DHCP_STRICT_MODE. This flag defaults to FALSE.

If DHCP_STRICT_MODE is FALSE, then the value of the DHCP_STRICT flag is
not valid and a host should use the non-strict semantics.

If DHCP_STRICT_MODE is TRUE, then the value of the DHCP_STRICT flag is
valid, and the following semantics apply.

If DHCP_STRICT is FALSE, then a host MUST use the non-strict semantics.

If DHCP_STRICT is TRUE, then a host MUST use the following semantics.

The O and M flags are completely independent. The O flag implies nothing
about address configuration, and the M flag implies nothing about
whether ancillary information is available.

A valid RA can contain both the O and the M flags.

Once a host has seen an RA with DHCP_STRICT_MODE=TRUE and
DHCP_STRICT=FALSE, the host MUST ignore any subsequent RA with
DHCP_STRICT_MODE=TRUE and DHCP_STRICT=TRUE. A host MAY log a warning in
this case. This state MUST NOT be persistently stored. Rationale: Moving
from strict to non-strict is much less harmful than moving from
non-strict to strict, given that strict mode can require hosts to
deconfigure addresses or not acquire them in the first place. Not having
this state in persistent storage means that a reset of the network stack
or the host itself will clear the state, allowing it move from
non-strict to strict mode.

The M and O flags MUST be honoured if known:
   - a host MAY attempt to obtain an address via DHCPv6
     without seeing an RA at all. Rationale: The host may be in an
     isolated network, containing a DHCPv6 server, but no router.

   - once it has seen an RA on a link, a host MUST NOT attempt to
     obtain an address via DHCPv6 unless it sees an M flag. Rationale:
     In strict mode, the M flag is prescriptive; no M flag = no
     DHCPv6 address configuration.

   - a host MAY attempt to obtain ancillary information via DHCPv6
     without seeing a RA at all. Rationale: The host may be in an
     isolated network, containing a DHCPv6 server, but no router.

   - once it has seen an RA on a link, a host MUST NOT attempt to
     obtain ancillary information via DHCPv6 unless it sees an O flag.
     Rationale: In strict mode, the O flag is prescriptive; no O flag =
     no ancillary information via DHCPv6.

Once a DHCPv6 address has been configured:
   - a host MUST deconfigure a DHCPv6 address if an RA is seen
     that does not contain an M flag. However, deconfiguration MUST
     be done by allowing the valid lifetime of the address to expire OR
     two hours to elapse, whichever is the lesser. Rationale: If the
     network is no longer advertising a DHCPv6 server, strict mode
     requires that hosts no longer use information obtained via DHCPv6.
     The delay provides some some hysteresis and also some protection
     against rogue RAs.

Once ancillary information has been obtained via DHCPv6:
   - a host MAY discard ancillary information obtained via DHCPv6
     if an RA is seen that does not contain an O flag. If an address
     has been obtained via DHCPv6, the host MUST wait and discard
     the ancillary information only at the next renewal of that
     address or after two hours, whichever is the lesser period.
     Rationale: If the network is no longer advertising a DHCPv6
     server, strict mode requires that hosts no longer use
     information obtained via DHCPv6. This delay provides some
     hysteresis and also some protection against rogue RAs.

A variant on strict mode is semi-strict, where you can specify "MUST do
DHCPv6" via the M flag, but you can't specify "MUST NOT" through its
absence. And mutatis mutandis for the O flag.

I don't personally feel that all this is necessary. Also, I think that
the security considerations relating to strict mode (and to your very
similar suggestions) make them dangerous. A rogue router could issue RAs
that cause hosts on a compromised link to not do DHCPv6 at all,
deconfigure DHCPv6 addresses and/or discard ancillary information. For
that reason I prefer the non-strict semantics.

How does all this interact with SLAAC? It doesn't. If you want your
hosts to do SLAAC, you set the autoconf flag; otherwise you don't. If
you don't want hosts in a subnet to do DHCPv6, configure your DHCPv6
servers to not provide addresses to that subnet.

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

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 1 Aug 2012 12:21:31 +0200 (CEST)

> to do with them would be to deprecate them altogether.

I know of one vendor device (I'm trying to get them to change) who in 
presence of telling the router to advertise the M-flag, automatically 
removes the A flag and prefix from its outgoing RAs. I do not agree with 
their interpretation of the standard (that in the presence of M flag, 
clients must not do SLAAC).

-- 
Mikael Abrahamsson    email: [email-masked]

---

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

Thanks!

......

---

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

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.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 01 Aug 2012 17:58:22 -0700

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

A more complete M/O set of flags would be something like telling "use
DHCP for PD and use SLAAC for default route" or so.

But not sure whether this is the right thing to do either.

Alex

---

From: Karl Auer <[email-masked]>
Date: Thu, 02 Aug 2012 11:48:17 +1000

On Wed, 2012-08-01 at 17:58 -0700, Alexandru Petrescu wrote:
> The choice today is more than b/w 'if M then DHCP is available
> otherwise SLAAC'.

That has never been the choice. It's never been either/or, one excluding
the other. Rock solid mechanisms exist to stop hosts doing SLAAC - the
autoconf flag, which DOES impose mandatory behaviour on the host, or,
worst-case, use of a non/64. And a rock solid method exists to stop
hosts doing DHCPv6 - just don't provide service to the subnet. Neither
mechanism is onerous, neither method is complex.

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

You are talking here about what information is delivered via the two
mechanisms, not the operations of the mechanisms themselves.

Regards, K.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 01 Aug 2012 19:02:05 -0700

Le 01/08/2012 18:48, Karl Auer a écrit :
> That has never been the choice. It's never been either/or, one
> excluding the other.

Ok fair enough.  The eisting M/O are like hints - suggestions.

> Rock solid mechanisms exist to stop hosts doing SLAAC - the autoconf
> flag, which DOES impose mandatory behaviour on the host, or,
> hosts doing DHCPv6 - just don't provide service to the subnet.

Right...

> Neither mechanism is onerous, neither method is complex.
>
>> from the other - it's still impossible to use just one for
>> everything. (eg RA doesnt PD, DHCP doesnt MTU, and more)
>

Right.  Let me try to better explain.

In a static environment, where the PC always wakes up on the same desk,
this avialability of DHCP vs SLAAC is easily decided once for several
months.  This could happen easily with just M/O, or simply by the
absence of DHCP Server.

But in mobile environment, a mobile router moving aroung attaching to
other mobile router needs to be able to face quickly various ways of
delivering this configuration data.

If one considers simply the triplet address-defroute-prefixdelegated
then there are about 8 possibilities to deliver that to a Router, by
using DHCP and ND combinations.  Which of the 8 should the router try first?

One neighboring vehicle would deliver it 
address-defroute-prefixdelegated by DHCP, another one by SLAAC and yet 
another one by a combination of the two.

In order to test for the availability of which of DHCP/ND delivers which
of address-defroute-prefixdelegated, one would send several RSs and
several DHCP Requests.  This may be too much for routers which
constantly move.  Ideally, such a Router would just send an RS, receive
some capability, and subsequently executing DHCPReq depending whats in
that RA.

This would require more than just M/O flags.

And yes I agree this would be more that what a wide agreement could be
reached on M/O...

Just some thought.

Alex

---

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

Regards, K.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Doug Barton <[email-masked]>
Date: Wed, 01 Aug 2012 21:40:00 -0700

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

---

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