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

JINMEI Tatuya / 神明達哉 <jinmei.tatuya@gmail.com> Mon, 19 June 2017 17:55 UTC

Return-Path: <jinmei@wide.ad.jp>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 644E2131770 for <dhcwg@ietfa.amsl.com>; Mon, 19 Jun 2017 10:55:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.018
X-Spam-Level:
X-Spam-Status: No, score=-5.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVVPD3vQOa7K for <dhcwg@ietfa.amsl.com>; Mon, 19 Jun 2017 10:55:12 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FECD131727 for <dhcwg@ietf.org>; Mon, 19 Jun 2017 10:55:12 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id D56DB3493CF; Mon, 19 Jun 2017 17:55:09 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id BFB3D160048; Mon, 19 Jun 2017 17:55:09 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id A753A16006D; Mon, 19 Jun 2017 17:55:09 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id M5kmkqw0XEve; Mon, 19 Jun 2017 17:55:09 +0000 (UTC)
Received: from jmb.localhost (unknown [104.129.198.81]) by zmx1.isc.org (Postfix) with ESMTPSA id C6FDB160048; Mon, 19 Jun 2017 17:55:08 +0000 (UTC)
Date: Mon, 19 Jun 2017 10:55:08 -0700
Message-ID: <m2o9tjrhfn.wl%jinmei.tatuya@gmail.com>
From: JINMEI Tatuya / =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei.tatuya@gmail.com>
To: "Bernie Volz (volz)" <volz@cisco.com>
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>, Ralph Droms <rdroms.ietf@gmail.com>
In-Reply-To: <3227281E-1FC2-448F-A9D2-9E7603A24E15@cisco.com>
References: <8418750467ae490ea50e342380a565be@XCH-ALN-003.cisco.com> <CAJE_bqcMLz7JBaSA2h6_xiB3AyxQzkMGfL87WeqKzwxKoSeD-w@mail.gmail.com> <67c761541b674041ba5a2eb0b9ea41fa@XCH-ALN-003.cisco.com> <CAJE_bqeBg-va5zr=4HNrecECg_mmGpWECAc8V5UL0ckhHnJcNQ@mail.gmail.com> <7f897317e79e4576bebc772c45edb703@XCH-ALN-003.cisco.com> <CAJE_bqd72=wKwe3_i3=rArJys1eWLizVdn_q+Dz9yaHFouP_WA@mail.gmail.com> <3227281E-1FC2-448F-A9D2-9E7603A24E15@cisco.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/qk_J-LLwcjf_Wmj85qtV0H6_8tQ>
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Jun 2017 17:55:14 -0000

At Sat, 17 Jun 2017 02:27:39 +0000,
"Bernie Volz (volz)" <volz@cisco.com> wrote:

> My reaction is you are wrong – the PIO would, whenever sent, be sent
> with the preferred and valid lifetime REMAINING on the PD lease. So,
> sure a PIO sent just after the PD lease started would have (close)
> to the full values, but the values sent an hour later would be 1
> hour less than they were.

Actually I agreed.  I guess what we're different is the view on how
obvious it is.  I suspect this is not so obvious and there are
actually implementations that can cause the situation where
deprecated/invalidated addresses are used.  There may even be an
implementation that naively copies the lifetimes from PD to RA PIO.

I've monitored RAs advertised in my apartment room.  The ISP is
Comcast and the default router is Apple time capsule.  The lifetimes
advertised in RA PIO are constant and do not decrease as I monitored
it in multiple consecutive RAs.  Of course, it doesn't immediately
mean the time capsule device uses the 'naive' approach.  I actually
don't even know if PD is used or the time capsule is the PD client.
And the time capsule might actually have some safety buffer period and
use a much lower lifetimes for PIO than those provided in PD.  Still,
I think this can be a potential anecdote to suggest there might be a
problematic implementation.

So I don't think it at least doesn't harm if we say that lifetimes of
site addresses derived from the delegated prefix MUST NOT exceed the
remaining time of the lifetimes in the last-received corresponding
PD.  (I don't think we have to specify exactly how to implement this
restriction).

--
JINMEI, Tatuya