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

神明達哉 <> Fri, 16 June 2017 18:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EAD6A1200C1 for <>; Fri, 16 Jun 2017 11:35:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Status: No, score=-1.7 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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 q4EeA2jxDt6Y for <>; Fri, 16 Jun 2017 11:35:36 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 666AA12ECBE for <>; Fri, 16 Jun 2017 11:35:36 -0700 (PDT)
Received: by with SMTP id u12so74584722qth.0 for <>; Fri, 16 Jun 2017 11:35:36 -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; bh=BuRoOtTTgNT/o9JfjTgQrOsXpgoNxarUdq5Ud7oOCLs=; b=E0lqaonfT+27lE5trvf1fnu8BZyfrFiCm067DwLEEsc8JLE28iH8sYgtvTAlmUOffL lHvCI4DNsRnhsociXZf8a186U/vYTe20Pw3b3927cZNOqVITiVPE5eXNyRFawLfz20W6 6KwI05BFYpIJB+hrcWkp/GBr5+SXKzvv5zsB11bz5W/Dm6ZsyBSF9K42e/H5bkWJ7ONO 6vXYAUI3b/m+7XErRCH3Rkh+vKNHVyAPk51J6V0NEVuiYQe0l37sYtTw9kXwKQDqd71y JP4GijbKNp0aIZWrN2OhFwm6RgpKX+md+xagszp1V8Bz/z22EwjHEljp9c3wSK90rLRR fLOQ==
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; bh=BuRoOtTTgNT/o9JfjTgQrOsXpgoNxarUdq5Ud7oOCLs=; b=fjVtM/zvdXmqFZalpSjsBBXSs4aZEg0zzbiXS7ZMiO5rJBeZ43gF1Mlg17mjF5MKQn u5zwbtJkQIVMHDHltCS/wtGZY+xMMu6K370gDT2pyB0kzk7wGMXzqXnBwEVzDTzPKEFs VHLt3+a+pUWgXLNCNE2ZTowWEqRRmeH2lrfN88IRVNZGKw/SI3qS8+4/UX8E6inkYwO7 bRN7sG+F8lde78nC5+FQO+L7n0tFJ+xWIqEdux90OGBaavwB4a6HiyjuVgB2TFXw84eI /PgN2QkMTeESPxEBDC/ZeGA2BEcU75ZuP+izkYcOfdMRunyhytlW/2jq/Vo6u4iO5VGL IJlQ==
X-Gm-Message-State: AKS2vOzy3qIzKfeJHhNAI/hYhgVzEe3qhL8bMUyDkx630i3PE+yxuwl7 fAWL/Azw3bBsJvyBcXzw55j1GQWyOw==
X-Received: by with SMTP id h199mr13988596qke.254.1497638135448; Fri, 16 Jun 2017 11:35:35 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 16 Jun 2017 11:35:34 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <>
Date: Fri, 16 Jun 2017 11:35:34 -0700
X-Google-Sender-Auth: OVlQDFAZjbrrMNL7O2-g32qZ_xA
Message-ID: <>
To: "Bernie Volz (volz)" <>
Cc: "" <>, Ralph Droms <>
Content-Type: text/plain; charset="UTF-8"
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: Fri, 16 Jun 2017 18:35:39 -0000

(Sorry, I've noticed a minor but possibly very confusing typo in my
previous message.  I'm replacing the whole text with correcting it
below.  Please ignore the previous one)

At Wed, 14 Jun 2017 20:13:56 +0000,
"Bernie Volz (volz)" <> wrote:

> We are working to get the -09 version out before the July 3rd
> IETF-99 cutoff. And, I think we're waiting on text for you regarding
> one item:

I don't think I promised I would offer text :-) but I admit I should
have provided some followup much earlier.

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

As I said before (in the quoted text) I actually suspect it's
premature to talk about specific text before discussion.  So let me
talk about what I think is an issue more specifically.

First off, what's this preferred lifetime in the first place?  Section
21.22 simply says:

      preferred-lifetime   The recommended preferred lifetime for the
                           prefix in the option, expressed in units of
                           seconds.  A value of 0xFFFFFFFF represents

What does this "recommended" mean?  As far as I can see it's not
explained anywhere else in the draft.  But one possible, or likely,
interpretation would be that it's a recommendation for addresses
configured from this prefix.  More specifically, it would be to use it
as the preferred lifetime of a prefix information option (PIO) of RA
for the delegated prefix (or prefixes derived from the delegated
prefix).  Assuming that, consider some more concrete issue:

Assume a PD client gets an /64 IA_PD prefix with preferred lifetime
being 7 days (an arbitrary choice).  If T1/T2 of the IA_PD follows the
recommended value of Section 21.21, the client will try to renew it in
3.5 days.

Meanwhile, this prefix is typically advertised in the downstream link
in the prefix information option (PIO) of RA.  Assuming the above
interpretation of "recommendation", a straightforward implementation
of it is to set the preferred lifetime of the PIO to 7 days.  End
hosts receiving this prefix will configure their addresses, resetting
its preferred lifetime to 7 days every time it receives the PIO (which
is periodically advertised, usually every several minutes).

In 3.5 days the PD client starts renewing the prefix.  But, now suppose
this exchange doesn't succeed (even after the client switches to
REBOUND).  Then what should happen in 7 days?  Should the delegated
prefix now be considered "deprecated"?  And what would that mean?
Should the preferred lifetime value of the corresponding RA PIO be
reset to 0 from this point?

And, what if the PD client can't even RENEW/REBOUND until the valid
lifetime expires?  If, like above, the valid lifetime value is copied
from IA_PD prefix to RA PIO, end hosts will have an address with a
pretty large valid lifetime (in this example scenario, at least 7
days) at the time of expiration due to the periodic RA advertisements.
And, even if the advertised PIO valid lifetime is set to 0 at that
point, end clients will still keep using the address for two hours
(see RFC4862).

I actually don't know whether/how existing implementations deal with
cases like this, but I wouldn't be surprised if there are naive
implementation that simply copies the preferred/valid lifetimes from
PD to RA, potentially having the problems described above.  I suspect
we've not heard problem reports in the actual deployment simply
because the lifetimes are sufficiently long compared to possible
network outage periods, and also perhaps because if this problem
happens because the upstream becomes unreachable, then it doesn't
matter much anyway if the end clients keep using "expired" addresses.
Still, as a protocol design I think it's a kind of defect and we
cannot just rely on the operational conditions.

So, can we agree there's a potential problem as some of the
definitions and the usage are not clear enough, aside from whether
that should be addressed in rfc3315bis?

JINMEI, Tatuya