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

"Bernie Volz (volz)" <volz@cisco.com> Thu, 13 July 2017 18:08 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 00368129AD7 for <dhcwg@ietfa.amsl.com>; Thu, 13 Jul 2017 11:08:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level:
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: 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 VSkUKkwUhV_1 for <dhcwg@ietfa.amsl.com>; Thu, 13 Jul 2017 11:08:23 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 330ED12942F for <dhcwg@ietf.org>; Thu, 13 Jul 2017 11:08:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12636; q=dns/txt; s=iport; t=1499969303; x=1501178903; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=pZiqyrRnLOtNci+tXyqt1dXfzmGrSHwSxuQYnIzsY9s=; b=mHcxkijInGr9C76F1h+MooBqSLYxvXqXokvoAO0B1vFn+piZIqZNUU/B 1/Rl2HvtblI9Vzboy9vV/9e5iNzivdDtRR29lflj/pSpjzRp005WhiQ4Y Ubqcaf2YQN0j8oFg7KmbgySskBWR5Ha/9YNCq755YPEKEZcCequWGoUxo s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DDAAA+tmdZ/4sNJK1eDgsBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNaZIEUB44CkXaILo1VghEhC4VKAhqDTz8YAQIBAQEBAQEBayh?= =?us-ascii?q?CDoRIAQEBAQIBAQEhEToLDAQCAQYCEQMBAQEBAgIjAwICAh8GCxQBCAgCBAENB?= =?us-ascii?q?QiKDwMNCAkHkTOdZIImJYcODYNkAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYELgh2?= =?us-ascii?q?FLQGDJIE8gRuCKg+CbYJhAQSXQIc1OwKHSIdbhGaCFYVMiQ2BRIwIAimJIQEfO?= =?us-ascii?q?IEKdRVJgleEAD92DQGENYM9gQ0BAQE?=
X-IronPort-AV: E=Sophos;i="5.40,354,1496102400"; d="scan'208";a="267797292"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Jul 2017 18:08:21 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v6DI8Llf031701 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 13 Jul 2017 18:08:21 GMT
Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 13 Jul 2017 13:08:21 -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; Thu, 13 Jul 2017 13:08:20 -0500
From: "Bernie Volz (volz)" <volz@cisco.com>
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>, Timothy Winters <twinters@iol.unh.edu>, =?utf-8?B?SklOTUVJIFRhdHV5YSAvIOelnuaYjumBlOWTiQ==?= <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//gVIMCAI6ikAP/2Lj5w
Date: Thu, 13 Jul 2017 18:08:20 +0000
Message-ID: <5573951f86ce44e59d78e2a7214c3546@XCH-ALN-003.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> <72E71872-9AC3-4D74-B889-B13CE05F62E4@cisco.com> <d64e4247d2bc4fc18a83a3f80591f95c@XCH-ALN-003.cisco.com> <6f7fc559-d6c7-9479-2086-c68dac2e0d64@gmail.com>
In-Reply-To: <6f7fc559-d6c7-9479-2086-c68dac2e0d64@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.131.32.175]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/1QX-AoIAPed-qxuZmhCXG0skECE>
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: Thu, 13 Jul 2017 18:08:27 -0000

Hi:

The text is now (in 18.2.10.1 and similar in 6.3):

      If the client uses a delegated prefix to configure addresses on
      interfaces on itself or other nodes behind it, the preferred and
      valid lifetimes of those addresses MUST be no larger than the
      remaining preferred and valid lifetimes, respectively, for the
      delegated prefix at any time.  In particular, if the delegated
      prefix or a prefix derived from it is advertised for stateless
      address autoconfiguration [RFC4862], the advertised valid and
      preferred lifetimes MUST NOT exceed the corresponding remaining
      lifetimes of the delegated prefix.

So, hopefully your comments are resolved? (Please also look at the paragraphs before this, as that details some of the restrictions - i.e., it is NOT "the ff02 link on which it issued a Solicit".)

Please review the -09 draft (https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-09) and let us know if this does not resolve your concerns.

Thanks!

- Bernie

-----Original Message-----
From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com] 
Sent: Friday, July 07, 2017 3:06 AM
To: Bernie Volz (volz) <volz@cisco.com>om>; Timothy Winters <twinters@iol.unh.edu>du>; JINMEI Tatuya / 神明達哉 <jinmei.tatuya@gmail.com>
Cc: dhcwg@ietf.org; Ralph Droms <rdroms.ietf@gmail.com>
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

Bernie,

This activity look scomplex to me, but here is my two cents.

Le 24/06/2017 à 23:28, Bernie Volz (volz) a écrit :
> Hi:
> 
> Any feedback on this proposed text?
> 
> It would be nice to be able to publish an -09 before the 7/3 deadline  
> for IETF-99, and perhaps even send this document on to the IESG 
> (assuming Ralph believes there is consensus to do so).
> 
> An alternative, which in retrospect I think I would prefer, would be 
> for the PIO to use the remaining preferred and valid lifetime on the 
> lease and just say that explicitly. That may be cleanest? So, that 
> proposed text would be:
> 
> If the client assigns a delegated prefix to a link to which the router 
> is attached,

What do you mean by the link to which the router is attached?

Is there a link to which the router is not attached?

Is there a link to which the router attaches instead of being attached?

Is it the ff02 link on which it issued a Solicit?

Alex

and begins to send router advertisements for
> 
> the prefix on the link, the preferred and valid lifetime in those 
> advertisements
> 
> MUST be no larger than the remaining preferred and valid lifetimes, 
> respectively,
> 
> for the delegated prefix at the time the router advertisement is sent.
> 
> Please let me know which of the two versions you’d prefer, or suggest 
> an alternative.
> 
> -Bernie
> 
> *From:*Bernie Volz (volz) *Sent:* Monday, June 19, 2017 3:28 PM *To:* 
> Timothy Winters <twinters@iol.unh.edu>du>; JINMEI Tatuya / 神明達哉
> <jinmei.tatuya@gmail.com> *Cc:* dhcwg@ietf.org; Ralph Droms 
> <rdroms.ietf@gmail.com> *Subject:* Re: [dhcwg] WGLC for
> draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017
> 
> 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 
> <mailto:twinters@iol.unh.edu>> *Date: *Monday, June 19, 2017 at 2:32 
> PM *To: *Bernie Volz <volz@cisco.com <mailto:volz@cisco.com>> *Cc:
> *JINMEI Tatuya / 神明達哉<jinmei.tatuya@gmail.com
> <mailto:jinmei.tatuya@gmail.com>>, "dhcwg@ietf.org 
> <mailto:dhcwg@ietf.org>" <dhcwg@ietf.org <mailto:dhcwg@ietf.org>>, 
> Ralph Droms <rdroms.ietf@gmail.com <mailto: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 mailing list 
> dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg
>