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

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 7 Jul 2017 09:05:48 +0200

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 <[email-masked]>; JINMEI Tatuya / 神明達哉 
> <[email-masked]> *Cc:* [email-masked]; Ralph Droms
> <[email-masked]> *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 <[email-masked]
> <mailto:[email-masked]>> *Date: *Monday, June 19, 2017 at 2:32
> PM *To: *Bernie Volz <[email-masked] <mailto:[email-masked]>> *Cc:
> *JINMEI Tatuya / 神明達哉<[email-masked] 
> <mailto:[email-masked]>>, "[email-masked] 
> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>,
> Ralph Droms <[email-masked] <mailto:[email-masked]>> 
> *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) <[email-masked] 
> <mailto:[email-masked]>> 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 / 神明達哉" <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> At Sat, 17 Jun 2017 02:27:39 +0000, "Bernie Volz (volz)"
> <[email-masked] <mailto:[email-masked]>> 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 
> [email-masked] https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: Ralph Droms <[email-masked]>
Date: Wed, 12 Jul 2017 17:08:32 -0400

I've reviewed the discussion of draft-ietf-dhc-rfc3315bis-08 during the (extended) WG last call.  Several thorough reviews were posted, and no negative responses were received.  I note Jinmei-san's abstention: https://www.ietf.org/mail-archive/web/dhcwg/current/msg17577.html

In my opinion, the WG has expressed consensus to forward the document to the IESG, after the issues raised in the WG last call are addressed.

- Ralph

> On May 9, 2017, at 10:52 AM, Bernie Volz (volz) <[email-masked]> wrote:
> 
> Hello:
>  
> The co-authors believe that all of the issues reported for the last August WGLC on draft-ietf-dhc-rfc3315bis-05 have now been resolved. But, because of the large number of changes, the DHC WG co-chairs feel another “WGLC” is appropriate.
>  
> Please review this document and provide your comments and whether you support the document moving forward by May 30th, 2017. The DHC WG co-chairs will again ask Ralph to evaluate the responses. We are doing a 3 week WGLC as the document is rather large and important to get right!
>  
> Please see https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-08.
>  
> If you’d like to see the differences from the 05 version, use the diff tool at https://tools.ietf.org/rfcdiff:
>  
> https://tools.ietf.org//rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-dhc-rfc3315bis-08.txt&url2=https://tools.ietf.org/id/draft-ietf-dhc-rfc3315bis-05.txt
>  
> The list of issues we recorded and action/assignee details are athttps://docs.google.com/spreadsheets/d/1c3obOwmRQDldw0u_kv85B5Q4LnjnmvUp2MmsHDGmW98 (some additional issues are in https://trac.tools.ietf.org/group/dhcpv6bis/report).
>  
> One very recent change to highlight is https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-08#section-18.2.12 – this was to address a criticism that DHCPv6 is not responsive enough for some network configuration changes.
>  
> The co-authors thank those that reviewed this document during the previous WGLC and hope that those same reviewers (and hopefully more) will endeavor to do one more thorough review of the document.
>  
> -          Tomek & Bernie

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 13 Jul 2017 18:08:20 +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:[email-masked]] 
Sent: Friday, July 07, 2017 3:06 AM
To: Bernie Volz (volz) <[email-masked]>; Timothy Winters <[email-masked]>; JINMEI Tatuya / 神明達哉 <[email-masked]>
Cc: [email-masked]; Ralph Droms <[email-masked]>
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

Bernie,

Le 24/06/2017 à 23:28, Bernie Volz (volz) a écrit :
> If the client assigns a delegated prefix to a link to which the router 
> is attached,

Alex

> for the delegated prefix at the time the router advertisement is sent.
> 
> IA_PD option is wrong (it should be IAPREFIX option, as that holds the 
> lifetimes).
> 
> *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
> discussed but it wasn't clear answer on what to do with the lifetimes.
> 
> terms of what is tested at the NH Interoperability Lab for PD / CPEs?
> 
>> to the full values, but the values sent an hour later would be 1 hour 
>> less than they were.
> 
> 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
> 
> 
> 
> --
>

---

From: 神明達哉 <[email-masked]>
Date: Thu, 13 Jul 2017 11:13:27 -0700

At Thu, 13 Jul 2017 18:08:20 +0000,

> 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.

Looks good to me.

--
JINMEI, Tatuya

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 13 Jul 2017 22:06:09 +0200

Le 13/07/2017 à 20:08, Bernie Volz (volz) a écrit :
> 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?

YEs, looks good.

(and I hope there is a command in the CLI, or a setsockopt, on the
client to add a preferred and valid lifetimes to an address that it
assigns on an interface).

Alex