Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC

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

Hi Andrew,

Really appreciate your careful review and the comments.
Please find replies inline.

> -----Original Message-----
> From: v6ops [mailto:[e-mail]] On Behalf Of Andrew ??
> Yourtchenko
> Sent: Wednesday, October 22, 2014 9:57 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC
> 
> Below goes my review of this document.
> 
> General impressions:
> 
> The information about the differences in the behavior of the OSes is
> operationally useful and is worth publishing.  Some of the questions that
> this document raises do look like valid concerns to me, and should be
> brought further (i.e. the DHCPv6 address behavior on flag change), some of
> them (A=0,O=1,M=0), in the absence of supporting reasons "why", look
> more like a curiosity - interesting to point out in case this corner case
> happens as a transient, but not worth spending the cycles trying to agree
> what the implementations should be doing in that case.

[Bing] I'll consider this together with Lorenzo's comment. Maybe another big revision is needed. 


> More specific comments:
> 
> 2.1.  M (Managed) Flag
> 
> "The M flag indicates that addresses are available from IPv6."
> 
> s/IPv6/DHCPv6/ ?
[Bing] My fault. Sorry.
 
> "the O flag is redundant and can be ignored"
> 
> Could be good to have an explicit reference to section
> 
> "4.2.Router Advertisement Message Format" of RFC4861 where this text is
> coming from.
[Bing] Ok, will do.

 
> 2.3.  A (Autonomous) Flag
> 
> "The A flag indicates that the prefix that is also carried by the PI
>    option can be used for SLAAC.  A flag semantics are independent of M
>    and O flag semantics.  The A flag indicates that the prefix can be
>    used by SLAAC, regardless of the M and O flag settings."
> 
> What about rephrasing this as:
> 
> "The A flag, carried within the Prefix Information option, indicates that the
> prefix in this option can be used for stateless autoconfiguration. Flag
> semantics are independent of M and O flags, and their values do not affect
> whether this prefix can be used or not."
[Bing] It's better, thank you.

> "3.2.1.  Inappropriate Sources"
> 
> interesting finding. Why is it a problem worth solving ?
[Bing] A host who self-configuring the IP address will not be able to do a stateless configuration. 
Say, a sensor self-configures ULA address and needs to get other information from DHCPv6 server. In this scenario, stateful DHCPv6 might be too heavy for the system.

> "3.2.2.  Renumbering"
> 
> The three steps described read as a sequence, whereas they are alternative
> renumbering strategies. This should be rephrased to make it clearer.
> 
> Also, the renumbering discusses flash renumbering process. Should it also
> make a reference to rfc4192 which is aiming to perform a renumbering
> without a flag day, and look at the issues accordingly ?
[Bing] The intended meaning is actually to caution that a flash renumbering might happen on some operating systems when the M flag is turned off. 
The wording needs to be revised.

> Appendix A:
> 
> A.1:
> 
> "Host 1: Window 7 / Window 8.1 Virtual Host" - Windows should be in plural.
> "Host 2: Ubuntu 14.04" - is it Ubuntu Desktop in default configuration ? I
> presume so, but it should be mentioned explicitly.
[Bing] Yes, they're all in default configuration. Will revise accordingly.
 
> A.3:
> 
> "reveiving A transitiong" => needs spellcheck and potentially rephrase for the
> sentence.
[Bing] Will do.

> Appendix B:
[Bing] This appendix is an analysis in theory that what ambiguities are existing in current standards. It is a hint, might not necessarily means operational problems.
I think your following questions are useful for the DHCPv6/SLAAC Interaction Guidance draft. I'll consider them in that draft.

Many thanks.

Best regards,
Bing

> "More specifically, is RA (with M=1) required to trigger DHCPv6?  If there
> are no RAs at all, should hosts initiate DHCPv6 by themselves?"
> 
> RFC4862, 5.5.2.  Absence of Router Advertisements mentions:
>    Even if a link has no routers, the DHCPv6 service to obtain addresses
>    may still be available, and hosts may want to use the service.  From
>    the perspective of autoconfiguration, a link has no routers if no
>    Router Advertisements are received after having sent a small number
>    of Router Solicitations as described in [RFC4861].
> 
>    Note that it is possible that there is no router on the link in this
>    sense, but there is a node that has the ability to forward packets.
>    In this case, the forwarding node's address must be manually
>    configured in hosts to be able to send packets off-link, since the
>    only mechanism to configure the default router's address
>    automatically is the one using Router Advertisements.
> 
> Does this wording answer the question ?
> "it is not
>       clear whether the host should start DHCPv6 or not; or vise versa,
>       the host is already both SLAAC/DHCPv6 configured, then M flag
>       change from TRUE to FALSE, it is also not clear whether the host
>       should turn DHCPv6 off or not."
> 
> What is desired from the operational standpoint and why ? (Also, taking into
> the account the effects on the DHCPv6 server caused by a crowd of hosts
> receiving an RA and simultaneously (re)starting up the
> DHCPv6 process).
> 
> "For example, when both M and
>       O flags are TRUE, it is not clear whether the host should initiate
>       one stateful DHCPv6 session to get both address and info-
>       configuration or initiate two independent sessions of which one is
>       dedicated for address provisioning and the other is for
>       information provision. "
> 
> The end result of doing either of the two behaviors should be the same,
> shouldn’t it ?
> If so - then why going through the effort of specifying one or another
> behavior ?
> 
> " When A and M flags are FALSE and O flag is
>       TRUE, it is not clear whether the host should initiate a stand-
>       alone stateless DHCPv6 session."
> 
> Again, same question as in 3.2.1: what is the practical use case scenario for
> this ? i.e. is this problem worth solving and why ?
> 
> --a
> 
> On 10/19/14, [e-mail] <[e-mail]> wrote:
> > This is to initiate a two week working group last call of
> > http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem.
> > Please read it now. If you find nits (spelling errors, minor suggested
> > wording changes, etc), comment to the authors; if you find greater
> > issues, such as disagreeing with a statement or finding additional
> > issues that need to be addressed, please post your comments to the
> > list.
> >
> > We are looking specifically for comments on the importance of the
> > document as well as its content. If you have read the document and
> > believe it to be of operational utility, that is also an important
> > comment to make.
> >
> > _______________________________________________
> > v6ops mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/v6ops
> >
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops