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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A8F5C12EC0E for <>; Fri, 16 Jun 2017 11:28:46 -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, 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 bTQUkTToNOIz for <>; Fri, 16 Jun 2017 11:28:45 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EEA2612ECBE for <>; Fri, 16 Jun 2017 11:28:44 -0700 (PDT)
Received: by with SMTP id u19so74216864qta.3 for <>; Fri, 16 Jun 2017 11:28:44 -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=gKa0e0oQ/2Fgt3JWLZ2plpKt7dJM3gizRh+lzLQreB4=; b=AEOZHJcwzBJhBudGoGUOG/cVFiKQ3ewQUKlitbxQyoz9e+awAHk0kRdcy0+bTYVlk1 IZbtLzgMkBHOq5DpM+1Y6nYwcYv+Dw6kxUHJLIYfmEQuw5P2rpPkWUcFJpsICWYdOWaM cFXyi/UGi/lGaQQ4sz1xitz0HYXXW8mC/+hrb0QNOqWBvrMkPF692N9Jbgh0clvq54S9 RlY3PEc9Yy4HKgtcoISEGQLFkbtcvl1pDpaSA13+B7F0JJ4yxejIFsLx1zQq/VWZdNKN k1x3a1IsepETj4sldN1sJa2st8LGNeefn8beOd9qo8Vnd44bVarKr2oiZj/Mt9XmyeXP Ajug==
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=gKa0e0oQ/2Fgt3JWLZ2plpKt7dJM3gizRh+lzLQreB4=; b=FX+gYfdq/h/VcfcKJvVJuTh6Lgi6BSDinDeMZP3jSfVaCmYbhj8Yf4PY5QENCMKGer zReFkR2EkJAUFwNgVcob5puKeUZrofQR/mNqFeHLnzucTHryepAKehtlaedAnYBJ+FPv VRKkz4hd3NnkiRPVd2pdj7ZuSiX/iuJP9rDa5+7uK7FuNqts7qyQSAqjhRkNmfe7NOvR 8GTEbNvQ+86IbrX+zSfQ6CJQuwhRPUBLXFU6Jyxg/1QREwBxq2KBGmAWT3L4eMGUYRtW lvusRz0uBdKo0b2NzPsAaApIc4ShZ4OvyPMxWShNbzw0OR2jNrs/pzTeosFJQaMRfbWE fh+g==
X-Gm-Message-State: AKS2vOwdSEYPIwSckKDdJV8AIxWHO9clreJuNvbpxfHF0KaHSS6ytrY6 ukXQIDVJXetfcS94oaOPz5fkruRezQ==
X-Received: by with SMTP id 103mr13784348qkp.242.1497637723926; Fri, 16 Jun 2017 11:28:43 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 16 Jun 2017 11:28:43 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <>
Date: Fri, 16 Jun 2017 11:28:43 -0700
X-Google-Sender-Auth: HRRkCZiGBOlxifZD7Sg-OGPk65g
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:28:47 -0000

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 1 week (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 6 days.  End
hosts receiving this prefix will configure their addresses, resetting
its preferred lifetime to 6 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 6 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 6
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