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

[Andrew 👽 Yourtchenko <[e-mail]>]

Hi Bing,

thanks for the comments! my replies inline...

On 10/23/14, Liubing (Leo) <[e-mail]> wrote:
> 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.

This looks like good idea to me.

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

To clarify - you mean link-local addresses, rather than ULAs, right ?
(since to configure ULAs, the host would somehow need to know the
prefix being serviced by the router, which sounds awfully close to
autoconf to me)

If we speak about a specialized environments like sensors, they
probably will try the stateless DHCPv6 regardless of the flags in RA,
since that will be their only way to configure themselves, what do you
think ?

The use-case I was after was something involving the common off the
shelf OSes, i.e. the part of the "every day network administration"
theme of the document.

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

Ahh, then - while the flash-renumbering-with-M-flag is a very worthy
problem to mention, it is not clear that this is the "takeaway" from
this part of the document.

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

ah okay, thanks for clarifying!

--a

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