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

"Bernie Volz (volz)" <volz@cisco.com> Sat, 24 June 2017 21:28 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 DEC64124D68 for <dhcwg@ietfa.amsl.com>; Sat, 24 Jun 2017 14:28:50 -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, 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, 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 Z6wnpwqh9kpP for <dhcwg@ietfa.amsl.com>; Sat, 24 Jun 2017 14:28:47 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 961F81205F0 for <dhcwg@ietf.org>; Sat, 24 Jun 2017 14:28:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=48548; q=dns/txt; s=iport; t=1498339727; x=1499549327; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=HoasabaT77OLpTpuNTEX1o6wXAdelwPZz0vxxoPNtd0=; b=JJH4aGC85iFvQ1SzOwXi66Vx/d8E0KYTE64iwPzYhcjRWSsyjBydeVCw nEU6e0+Y9FbTfVsysgNIwq4MGneIEc9vklipTrj1SZdUGnbQl5txZzF6U fkux5qQtWfYmnIfmqyENW3baj/hctGQILBDRkyE0n/aihxsJ79fFdAoAJ U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DcAABS2E5Z/5pdJa1eDgsBAQEBAQEBAQEBAQcBAQEBAYJvPC1igQ0Hg2WKGZFhiCyNToIRKIV8AhqCbj8YAQIBAQEBAQEBayiFGAEBAQECASMKTAULAgEGAg4DAwEBASEBBgMCAgIfERQJCAIEAQ0FCIlATAMNCAmRTZ1igiYnAocDDYQWAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYMnhSwBgySBPIEbgioJBhCCXYJhAQSXHocQOwKHModMhF6CEoVIikGLZwIniRABHziBCnQVgxuDfj92DQGIVYENAQEB
X-IronPort-AV: E=Sophos;i="5.39,386,1493683200"; d="scan'208,217";a="251669237"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Jun 2017 21:28:46 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v5OLSk1h004002 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 24 Jun 2017 21:28:46 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; Sat, 24 Jun 2017 16:28:45 -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; Sat, 24 Jun 2017 16:28:45 -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//gVIMA=
Date: Sat, 24 Jun 2017 21:28:45 +0000
Message-ID: <d64e4247d2bc4fc18a83a3f80591f95c@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>
In-Reply-To: <72E71872-9AC3-4D74-B889-B13CE05F62E4@cisco.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.86.242.115]
Content-Type: multipart/alternative; boundary="_000_d64e4247d2bc4fc18a83a3f80591f95cXCHALN003ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/SHub_Yk5aHpOh_Uqq0g6jBadgrU>
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: Sat, 24 Jun 2017 21:28:51 -0000

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, 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>; 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