Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance

["Liubing (Leo)" <[e-mail]>]

Hi Lorenzo,

From: Lorenzo Colitti [mailto:[e-mail]]
Sent: Thursday, January 09, 2014 9:02 AM
To: Liubing (Leo)
Cc: [e-mail]; [e-mail]
Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance

On Wed, Jan 8, 2014 at 10:39 PM, Liubing (Leo) <[e-mail]<mailto:[e-mail]>> wrote:
Can you remove it, then? As an operational group we don't want to provide guidance on invalid use cases. :-)
[Bing] I agree with you that “DHCPv6-only without RA” should not be identified as a valid use case. But in the document, what we want to caution the reader is that some operating systems would rely RAs to trigger DHCPv6. I think “RAs are necessary for IPv6 configuration”  and “RAs are necessary to trigger DHCPv6” are two different things in concept. We just want to emphasize the latter one. Maybe it is a little redundant in wording, but at least it is not harmful? Especially considering that in real practice, admins could enable routing configuration in DHCPv6 by private/customized extension (ISC dhcpd & dibbler both provide the capability) . I think maybe the redundancy wording could be useful for the situations.

Ok, so if that's what you want to say, how about replacing section 3.2 with something like this:

===

3.2. Guidance for DHCPv6-only Deployment

Some networks prefer central management of all IP addressing. These networks may want to assign addresses only via DHCPv6.

This can be accomplished by sending an RA that indicates that DHCPv6 address assignment is available (i.e., M=1), installing DHCPv6 servers or DHCPv6 relays on all links, and setting A=0 in the Prefix Information Options of all prefixes in the RA.

Note that an RA is still necessary in order for hosts to be able to use these addresses. This is for two reasons:

  1.  Per problem #1, if there is no RA, some hosts will not attempt to obtain address configuration via DHCPv6 at all.
  2.  If there is no RA, or if the RA does not include a Prefix Information Option covering the addresses assigned via DHCPv6, then those addresses cannot be used for any communication, even on-link communication. This is because DHCPv6 does not provide a way to configure routing, and unless routing is configured by some other means, hosts will consider all destinations to be unreachable [RFC4943]. Thus, using DHCPv6 without an RA does not currently provide any functionality.
[Bing] I think this is a good way to clarify the problem. Thanks much for contributing the texts, we’ll consider to incorporate them into the next version.
Also note that unlike SLAAC, DHCPv6 is not a strict requirement for IPv6 hosts [RFC6434], and some nodes do not support DHCPv6. Thus, this model can only be used if all the hosts that need IPv6 connectivity support DHCPv6.


Per problem #2, if the administrators want to switch the DHCPv6-only configured hosts to SLAAC-only, this is not possible on some hosts without manually changing the hosts' configuration or using additional management tools.

Per problem #4, for some platforms, the A flag and O flag might not be independent, when SLAAC is off, a stand-alone stateless DHCPv6 session would not be applicable. However, this might not be a common use case.

===

(Note: I don't understand what you meant by the last paragraph about problem #4, so I just repeated it as is in the suggestion above. But it should be clarified)
[Bing] Problem #4 indicates some implicit relationship between the flags. For example, when A=0, M=0, O=1, some operating systems would start a stand-alone stateless DHCPv6 session, but some just would not. For those who would not, it is just an implication that when A is off, the stand-alone stateless DHCPv6 is also off. This is the problem #4 “Dependencies between flags”.
We need to make it clearer in the next version.

Best Regards,
Bing

Cheers,
Lorenzo