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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2BD031315DC for <>; Mon, 19 Jun 2017 12:27:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 yIM2jVOQaitx for <>; Mon, 19 Jun 2017 12:27:39 -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 98CE412949A for <>; Mon, 19 Jun 2017 12:27:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=31048; q=dns/txt; s=iport; t=1497900459; x=1499110059; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=JYWG46Ua+4cTPe9eVgy7WclAJcMMftGRa3VhldjH7xw=; b=FN4aEAOVaCZBh8Kk0v54CHXKnxwONHX7//0+Zr26KUq/99qBA6vEPFRE kLS7YZx4EP/bolAx4/zZ6ea4U607GOgWpJ27Z09dFCnmLfM2yfgpsy/B1 omsUFttybO2XLs8kSek645v0uaJD326Onyj0MInrq7gLKOa5QKXBuo5Of Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DrAAB8JEhZ/5BdJa1cDgsBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJvPC1igQ0Hg2SKGZF8iCuNTIIRKIV8AhqCPj8YAQIBAQEBAQE?= =?us-ascii?q?BayiFGAEBAQECASNWBQsCAQYCDgMDAQIhBwMCAgIfERQJCAIEAQ0FiUhMAw0IC?= =?us-ascii?q?Y9onWGCJigChwoNhBYBAQEBAQEBAQEBAQEBAQEBAQEBAQEdiEIBK4J3gTyBG4I?= =?us-ascii?q?pCQYQglwwgjEBBJcchwc7Aocuh0iEZ5INi1gCJokIAR84gQp0FVsBgj+CR4E3P?= =?us-ascii?q?3YNAYg0gQ0BAQE?=
X-IronPort-AV: E=Sophos;i="5.39,362,1493683200"; d="scan'208,217";a="440923369"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jun 2017 19:27:38 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id v5JJRcNr017063 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 19 Jun 2017 19:27:38 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 19 Jun 2017 14:27:37 -0500
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Mon, 19 Jun 2017 14:27:37 -0500
From: "Bernie Volz (volz)" <>
To: Timothy Winters <>, =?utf-8?B?SklOTUVJIFRhdHV5YSAvIOelnuaYjumBlOWTiQ==?= <>
CC: "" <>, Ralph Droms <>
Thread-Topic: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017
Thread-Index: AdLI0aZmS0Xgn7D6S1m3YZ8hZorkbQLWe7cAAIVlReABPEJZgAKF0ckgAGu0AYAACFfvgACNW58A///BWQCAAEkOAP//zF+A
Date: Mon, 19 Jun 2017 19:27:37 +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: multipart/alternative; boundary="_000_72E718729AC34D74B889B13CE05F62E4ciscocom_"
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 19:27:43 -0000

Thanks Tim. That’s useful, and shows that we do need to be more explicit.

There are two places in draft-ietf-dhc-rfc3315bis-08 (section 6.3 and where we have the following text:

      If the client assigns a delegated prefix to a link to which the
      router is attached, and begins to send router advertisements for
      the prefix on the link, the client MUST set the valid lifetime in
      those advertisements to be no later than the valid lifetime
      specified in the IA_PD option.  A client MAY use the preferred
      lifetime specified in the IA_PD option.

The “no later” has been changed to “no larger”. And, actually the IA_PD option is wrong (it should be IAPREFIX option, as that holds the lifetimes).

Perhaps what we really should say is something like:

      If the client assigns a delegated prefix to a link to which the
      router is attached, and begins to send router advertisements for
      the prefix on the link, the valid lifetime in those advertisements
      MUST be no larger than the remaining valid lifetime
      for the delegated prefix.  A client MAY use the preferred
      lifetime as originally received in the IAPREFIX option, provided that whatever
      value is used is less than or equal to the valid lifetime to be sent in the
      router advertisement.

That text doesn’t by itself provide any good way to specify a shorter preferred lifetime so that the prefix is marked deprecated before it becomes invalid, but at least it assures that what is send for the preferred and valid meets the basic requires: preferred <= valid in the RA, and the valid is <= what is specified in the IAPREFIX.

  *   Bernie

From: Timothy Winters <>
Date: Monday, June 19, 2017 at 2:32 PM
To: Bernie Volz <>
Cc: JINMEI Tatuya / 神明達哉 <>om>, "" <>rg>, Ralph Droms <>
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

Hi Bernie,

We have CE Routers that countdown from when the IA_PD is received, and others that always transmit the lifetime received in the IA_PD in RA (Always the same).   It's about 50/50 at the moment.   When we were working on testing for 6024/7084 this was a topic that was discussed but it wasn't clear answer on what to do with the lifetimes.

You are correct that when the prefix timeout from the IA_PD it will stop forwarding and transmit a Destination Unreachable message.


On Mon, Jun 19, 2017 at 2:10 PM, Bernie Volz (volz) <<>> wrote:
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


Now offering testing for SDN applications and controllers in our SDN switch test bed. Learn more today