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

"Bernie Volz (volz)" <> Mon, 19 June 2017 18:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6F25412949E for <>; Mon, 19 Jun 2017 11:11:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mmVhkcsT4Cxj for <>; Mon, 19 Jun 2017 11:10:58 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9035412714F for <>; Mon, 19 Jun 2017 11:10:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3688; q=dns/txt; s=iport; t=1497895856; x=1499105456; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=YEqttbQQ6VNU+n1tE0pKAbYOvdEdH5AHW+dGmnyMfVM=; b=QrO99GvFlxR6h5DBgcpqi+h1vEWc6t7XMtS3X3ombxgyVFTgOUjIBzGa 4BwBiQQItO4dhVE+OqoO+PTj6zld2bXcGCrXBATmSbEBPxhsY3163Po02 j1dIqLqVvPao69sFac1nbBoZd8X9GzBkQxuXjIALa4d2RyzqbabsIDQ3R c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DUAADcEkhZ/5pdJa1cDgsBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMrLYFvB4NkihmRfIgrjUyCEYYkAhqCPj8YAQIBAQEBAQEBayi?= =?us-ascii?q?FGQEEASMRRRACAQYCGgImAgICHxEVEAIEAQ0FihQDDQiQBJ1hgiaHMg2EFgEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAR2BC4c4K4J3gTyBG4IpgnswgjEBBJ4jOwKOdoR?= =?us-ascii?q?nkg2LWIkwAR84gQp0FVsBhQaBNz92iEKBDQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.39,362,1493683200"; d="scan'208";a="437684972"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jun 2017 18:10:56 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id v5JIAuLi019646 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 19 Jun 2017 18:10:56 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 19 Jun 2017 13:10:55 -0500
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Mon, 19 Jun 2017 13:10:55 -0500
From: "Bernie Volz (volz)" <>
To: =?utf-8?B?SklOTUVJIFRhdHV5YSAvIOelnuaYjumBlOWTiQ==?= <>, Timothy Winters <>
CC: "" <>, Ralph Droms <>
Thread-Topic: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017
Thread-Index: AdLI0aZmS0Xgn7D6S1m3YZ8hZorkbQLWe7cAAIVlReABPEJZgAKF0ckgAGu0AYAACFfvgACNW58A///BWQA=
Date: Mon, 19 Jun 2017 18:10:55 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/f.22.0.170515
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
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: Mon, 19 Jun 2017 18:11:04 -0000

I’ve added Tim Winters as perhaps he can shed some light on this in terms of what is tested at the NH Interoperability Lab for PD / CPEs?

Even if a device doesn’t follow this (running down the lifetimes), what’s likely to happen when the PD expires is that the traffic will hopefully no longer be forwarded by the router (and with a ICMP destination unreachable notification) and perhaps RAs will be sent with 0 lifetimes to attempt to deprecate the prefix (and any assigned addresses) use as quickly as possible?

Ralph or Ole might also have a comment with respect to what they expected a requesting router to do based on the original RFC 3633? I don’t think this 3315bis document itself caused this potential confusion to exist?

- Bernie

On 6/19/17, 1:55 PM, "JINMEI Tatuya / 神明達哉" <> wrote:

    At Sat, 17 Jun 2017 02:27:39 +0000,
    "Bernie Volz (volz)" <> 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
    JINMEI, Tatuya