Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017
"Bernie Volz (volz)" <volz@cisco.com> Mon, 19 June 2017 19:27 UTC
Return-Path: <volz@cisco.com>
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 2BD031315DC for <dhcwg@ietfa.amsl.com>; Mon, 19 Jun 2017 12:27:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 yIM2jVOQaitx for <dhcwg@ietfa.amsl.com>; Mon, 19 Jun 2017 12:27:39 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98CE412949A for <dhcwg@ietf.org>; Mon, 19 Jun 2017 12:27:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; 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: A0DrAAB8JEhZ/5BdJa1cDgsBAQEBAQEBAQEBAQcBAQEBAYJvPC1igQ0Hg2SKGZF8iCuNTIIRKIV8AhqCPj8YAQIBAQEBAQEBayiFGAEBAQECASNWBQsCAQYCDgMDAQIhBwMCAgIfERQJCAIEAQ0FiUhMAw0ICY9onWGCJigChwoNhBYBAQEBAQEBAQEBAQEBAQEBAQEBAQEdiEIBK4J3gTyBG4IpCQYQglwwgjEBBJcchwc7Aocuh0iEZ5INi1gCJokIAR84gQp0FVsBgj+CR4E3P3YNAYg0gQ0BAQE
X-IronPort-AV: E=Sophos;i="5.39,362,1493683200"; d="scan'208,217";a="440923369"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jun 2017 19:27:38 +0000
Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-8.cisco.com (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 xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 19 Jun 2017 14:27:37 -0500
Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Mon, 19 Jun 2017 14:27:37 -0500
From: "Bernie Volz (volz)" <volz@cisco.com>
To: Timothy Winters <twinters@iol.unh.edu>, JINMEI Tatuya / 神明達哉 <jinmei.tatuya@gmail.com>
CC: "dhcwg@ietf.org" <dhcwg@ietf.org>, Ralph Droms <rdroms.ietf@gmail.com>
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: <72E71872-9AC3-4D74-B889-B13CE05F62E4@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> <m2o9tjrhfn.wl%jinmei.tatuya@gmail.com> <F0056821-DF5B-400E-ABAC-88BCA0EF68C7@cisco.com> <CAOSSMjWMJt1-qJM35kk3Eut=UHSPp-hizR0_nDE87ZMPJaf1vg@mail.gmail.com>
In-Reply-To: <CAOSSMjWMJt1-qJM35kk3Eut=UHSPp-hizR0_nDE87ZMPJaf1vg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.22.0.170515
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.98.1.195]
Content-Type: multipart/alternative; boundary="_000_72E718729AC34D74B889B13CE05F62E4ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/wHDO351jm1K9a0Fl_iTX-eVHKe8>
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 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 18.2.10.1) 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 <twinters@iol.unh.edu> Date: Monday, June 19, 2017 at 2:32 PM To: Bernie Volz <volz@cisco.com> Cc: JINMEI Tatuya / 神明達哉 <jinmei.tatuya@gmail.com>, "dhcwg@ietf.org" <dhcwg@ietf.org>, Ralph Droms <rdroms.ietf@gmail.com> 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. Regards, Tim On Mon, Jun 19, 2017 at 2:10 PM, Bernie Volz (volz) <volz@cisco.com<mailto:volz@cisco.com>> 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 / 神明達哉" <jinmei.tatuya@gmail.com<mailto:jinmei.tatuya@gmail.com>> wrote: At Sat, 17 Jun 2017 02:27:39 +0000, "Bernie Volz (volz)" <volz@cisco.com<mailto: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 -- Now offering testing for SDN applications and controllers in our SDN switch test bed. Learn more today http://bit.ly/SDN_IOLPR
- [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - R… Bernie Volz (volz)
- Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08… kkinnear
- Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08… 神明達哉
- Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08… Bernie Volz (volz)
- Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08… Bernie Volz (volz)
- Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08… 神明達哉
- Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08… Shawn Routhier
- Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08… Shawn Routhier
- Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08… Bernie Volz (volz)
- Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08… Bernie Volz (volz)
- Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08… 神明達哉
- Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08… 神明達哉
- Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08… Bernie Volz (volz)
- Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08… JINMEI Tatuya / 神明達哉
- Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08… Bernie Volz (volz)
- Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08… Timothy Winters
- Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08… Bernie Volz (volz)
- Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08… Bernie Volz (volz)
- Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08… Bernie Volz (volz)
- Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08… 神明達哉
- Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08… Bernie Volz (volz)
- Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08… Bernie Volz (volz)
- Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08… 神明達哉
- Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08… Alexandre Petrescu
- Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08… Ralph Droms
- Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08… Bernie Volz (volz)
- Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08… 神明達哉
- Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08… Alexandre Petrescu