Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

神明達哉 <> Thu, 01 June 2017 18:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8FE95129AAA for <>; Thu, 1 Jun 2017 11:53:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.3
X-Spam-Status: No, score=0.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, GUARANTEED_100_PERCENT=2.699, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iXXGciOjq5fD for <>; Thu, 1 Jun 2017 11:53:03 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 94875124BE8 for <>; Thu, 1 Jun 2017 11:53:03 -0700 (PDT)
Received: by with SMTP id 19so43895742qke.2 for <>; Thu, 01 Jun 2017 11:53:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=Z6dOLLvJKaX5XQm8kO4R9jD/GDN44Gh1mCdlksFQtdY=; b=Uw1m5WdOlgrlSOhYp/SEVDRgPbzPM5EUCR0eMKhaOggQ8GpbyJkc5+lzTzx/tr0DF+ OkfL/L79jEQSD36KEZmU2Djjkv6WdfJGoaFvGd1WvDW4/nmwdxZOZCdowT0qdoHU+qgs KOgcO923meFjOHAwBfr/ITWlphB8QfmVA/VfGdzyafxApdk2vmkT+F3ccCMGcKHAXqVN lQPRTYFDpYA6C9k9Eukg0S4ar7HMv+fpnosxYnFbt3Ndu1vYD/nkF0rZ6oqufUN2ilGi rjywAMs+luWsUvASK5CVpQR68XOuumJPKCKqNa8okFnGc9f9/VFluNyYnExzASoW2LRH kUPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=Z6dOLLvJKaX5XQm8kO4R9jD/GDN44Gh1mCdlksFQtdY=; b=SRIV25GVgcOuVrY1pWBGRKB14TdM843LzfJMnLeGV/wLfSqoi0JXJXpkgwIIYbYrS8 83hX91Gj5805Ignzz1YqcD2WpVHK5dU6qW/6pY/5t8hb68D7fnZf4KPCT2TOnDeIXk0Z Zm2Il4k+APjK8A4rN1lkWv4meHXYsApayo6M841bqmkhHVwbtpwoMrPpIsc3gMLgY81I hYmyyfddIWF7gwdMVSig672XYmEM+o79wwrAOIbFVETcf1d2APVRlCxWShp1koomL4eS ckBJYE8X3cMoU5zKR1ZmJoPyqXHRQJKU6ODGFSmKdIN1vl/u49XweiErzA3WIyPbtwGj G3RQ==
X-Gm-Message-State: AKS2vOwc3Dalz/MOu3rlaXZVN8HPGprjoJzqeE0YRFWHMSZIhmn3zJ6r FBW6RoTKno9qNsCIMkrfIGaSGPRhYA==
X-Received: by with SMTP id r123mr3593644qkf.0.1496343182544; Thu, 01 Jun 2017 11:53:02 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 1 Jun 2017 11:53:01 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <>
Date: Thu, 1 Jun 2017 11:53:01 -0700
X-Google-Sender-Auth: HGcIff1l3CP4dXk5v4yXvhamxpo
Message-ID: <>
To: "Bernie Volz (volz)" <>
Cc: "" <>, Ralph Droms <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 01 Jun 2017 18:53:05 -0000

On Fri, May 26, 2017 at 10:56 AM, Bernie Volz (volz) <> wrote:

>>> - I'm okay with deprecating the delayed authentication protocol, but
>>> I'm not sure if it's okay to ship the spec with no built-in
>>> authentication (the reconfigure key protocol is very limited and too
>>> weak).
> BV> We are working on sedhcpv6 but this has not been so simple and quick. And, DHCPv6 is in use and deployed today without an authentication protocol. There are other actions that can be taken such as stated in section 22:
>    Many of these rogue server attacks can be mitigated by making use of
>    the mechanism described in [RFC7610].

I personally wouldn't argue that it's a blocking issue, and, to be
clear, I'm not requesting sedhcpv6 be specified as *the*
authentication protocol in rfc3315bis.  But I'd suggest chairs to
explicitly leave notes about the point for security ADs when the doc
is sent to the IESG.

>>> - Section 5.2
>>>   the "stateful address autoconfiguration protocol" for IPv6 [RFC2462].
>>>  s/RFC2462/RFC4862/.
> and there are still more references to RFC2462.
> BV> This is by design. RFC4862 does not mention the M & O bits so we
> can't reference that RFC. We documented the reason for this in
> Appendix A:

I believe at least the reference to RFC2462 in Section 6.2 is not
really appropriate:

   This model of operation was the original motivation for DHCP and is
   the "stateful address autoconfiguration protocol" for IPv6 which is
   discussed in [RFC2462].

Simply because RFC4862 doesn't use the term "stateful address
autoconfiguration protocol" doesn't make this text appropriate.
RFC2462 used the term "stateful address autoconfiguration protocol"
just because DHCPv6 wasn't fully standardized at that time.  RFC4862
just replaced it with the term "DHCPv6".  If you want suggested text,
my suggestion is simply remove the second half the sentence:

   This model of operation was the original motivation for DHCP.  It
   is appropriate for situations where stateless address
   autoconfiguration alone is insufficient or impractical, e.g.,
   because of network policy, additional requirements such as dynamic
   updates to the DNS, or client-specific requirements.

As for the references to RFC2462 due to M/O RA flags, I still think it
can be rather misleading.  The sad fact is that M/O flags are dead -
all previous attempts at the 6man wg of making them workable failed,
and different implementations handle these flags very differently.
You simply cannot rely on these flags, and it doesn't make sense to me
newer protocol documents like rfc3315bis still talk about them simply
because its predecessor talked about them.

Now, if you want suggested text, this is my suggestion:

Section 18
   A client initiates a message exchange with a server or servers to
   acquire or update configuration information of interest.  A client
   has many reasons to initiate the configuration exchange:
   3.    when required by Stateless Address Autoconfiguration (as
         defined in [RFC2462] Section 5.2),
NEW1 (my preferred suggestion) remove this bullet
   3.    when Router Advertisement indicates DHCPv6 is available for
         address configuration (see [RFC4861] Section 4.2)

(unrelated) side note: there's a duplicate bullet #4 here.

Section 18
   The client has many reasons to initiate the configuration exchange:
   3.    when required by Stateless Address Autoconfiguration (as
         defined in [RFC2462])
NEW1 (my preferred suggestion) remove this bullet
   3.    when Router Advertisement indicates DHCPv6 is available for
         address configuration (see [RFC4861] Section 4.2)

Section 18.2.1
   In the case of a Solicit message transmitted when DHCP is initiated,
   the delay gives the amount of time to wait after IPv6 Neighbor
   Discovery causes the client to invoke the stateful address
   autoconfiguration protocol (see section 5.5.3 of [RFC2462]).  This
   random delay desynchronizes clients which start at the same time (for
   example, after a power outage).

NEW: I actually suggest removing this paragraph.  Especially given M&O
flags are "dead", I don't see a strong reason for retaining it in
addition to its previous paragraph (which also talks about the delay
and for the case of power outage).  If we still want to say something
about the interaction with RA, my suggestion is to revise the previous
paragraph as follows:

   The first Solicit message from the client on the interface SHOULD be
   delayed by a random amount of time between 0 and SOL_MAX_DELAY.  This
   mechanism is essential for devices that are not battery powered, as
   they may suffer from power failure.  After recovering from a power
   outage, many devices may start their transmission at the same time.
   This is much less of a concern for battery powered devices.  This
   random delay also helps descynronize clients which start DHCPv6
   session by seeing it available in Router Advertisement messages
   (see Section 4.2 of [RFC4861]).

Note that if all of the above suggestions are adopted, there will be
no reference to RFC2462.  So you can also remove it from the
Refereneces section.

>>> - Section 5.4
>>> [...] the requesting router MUST set the valid lifetime in those
>>> advertisements to be no later than the valid lifetime specified in
>>> the IA_PD Prefix option.
>>>  "no later than" sounds awkward as the lifetime is a duration, not  a
>>> particular point in time.
> This is simply open as before.
> BV> Unless you suggest some text, we will leave this be. I think the
> point of the text is rather clear.

If you want suggestion, this can be fixed easily:
 [...] the requesting router MUST set the valid lifetime in those
 advertisements to be no larger than the valid lifetime specified in
 the IA_PD Prefix option.

i.e., s/later/larger/

>>> - Section 8.1
> [...]
>>> site-scope unicast address has been deprecated.  Also, the phrase
>>> "global or ULA" is awkward as ULA is a global (scoped) address.
> The 08 version states:
>                            This is typically a globally unique
>                            address or unique local address (ULA)
>                            [RFC4193],
> This is still awkward to me, since in a sense ULAs are also "globally unique" (even if the uniqueness is not 100% guaranteed).  Personally I'd simply avoid mentioning ULAs unless there is a specific to reason to refer to it in the context (and I don't see such a reason here), but if we want to refer to ULAs here, I'd say, e.g., "a global address (including unique local addresses)".
> BV> Unless you suggest some text, we will leave it be. I don't see that this is necessarily in conflict - yes, ULA is in the "global address space". But I also think it adds value to explicitly mention ULAs here as otherwise someone could confuse the subtly that ULA is allowed.

I've already suggested text (I admit the point may be a bit pedantic,

>>> - Section
>>> "no later than" sounds awkward for these lifetimes (see also Sec
>>> 5.4).
> BV> See above.


>>> - Section
> [...]
>>> Specifically, the bullet description seems to lead to multiple
>>> separate state machines for different bindings.
> BV> I believe we addressed this by other text in the document - for example, see in 18.2.4 the following text:
>    The server controls the time at which the client should contact the
>    server to extend the lifetimes on assigned leases through the T1 and
>    T2 parameters assigned to an IA.  However, as the client Renews/
>    Rebinds all IAs from the server at the same time, the client MUST
>    select a T1 and T2 time from all IA options, which will guarantee
>    that the client will send Renew/Rebind messages not later than at the
>    T1/T2 times associated with any of the client's bindings (earliest
>    T1/T2).

Hmm...this is one of the things why I can't be confident about this
spec without actually trying to implement it from the text.  But I
don't have enough time to check if the concern is addressed in the
entire context, I'll simply give up with it.

>>> - Section 20.22
> [...]
>>> This choice of valid/preferred lifetime in an IA prefix and the
>>> (possible) relationship between them and those lifetimes advertised
>>> in the delegated site do not make perfect sense to me. [...]
> I don't think the revised version addresses the main point.  The new
> text simply avoids saying specifics about these lifetimes, but then
> it's even more unclear about what these lifetimes are (especially
> the preferred lifetime).
> BV> Unless you provide text, I think we'll leave this alone as
> mentioned earlier we feel that this document is not the one that
> should describe how these lifetimes are to be used.

This is not just about wording.  It's about actual protocol behavior,
and I don't even know if we have common consensus on it.  I also think
we can't simply ignore the issue by being silence, since it could
result in a bad situation like a site keeps advertising a prefix in RA
as a preferred one even when it's already "deprecated" or even
"invalidated" in terms of prefix delegation.  I'll see if I can offer
something more concrete, but I'd like to raise it as a possible
blocking issue.

>>> - Section 20.23
> [...]
>>> The expected usage is not very clear to me here.  Is it intended to
>>> be used for Advertise and apply the value to the ongoing
>>> Solicit-Advertise exchange?  Or is it mainly intended to be used for
>>> a possible subsequent restart of a DHCPv6 session?
> BV> You original question was I think about why SOL_MAX_RT MUST be
> in ORO. It MUST be as per RFC 7083 so that clients can get updated
> SOL_MAX_RT values. And, yes, the idea is that the Advertise with the
> SOL_MAX_RT value is used (even if it offers no leases) so that the
> client applies this value for any future requests. I don't see the
> need for this to be spelled out?

I'd think it's worth explaining, but I'll leave it to you.

JINMEI, Tatuya