Subject: [Dhcpv6bis] [dhcpv6bis] #152 (XML 3315): Prefix lifetime is 0

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Tue, 03 Nov 2015 09:49:38 -0000

#152: Prefix lifetime is 0

 A DHCPv6 client should send a DHCPv6 Renew for a given address if a Router
 Advertisement is received with a lifetime of 0.

 This covers the case when the DHCPv6 Server that gave out the address has
 released the Delegated pool back to the Server.   According to Ticket
 #151, the Request Router should transmit RAs with a lifetime of 0.
 Triggering a DHCPv6 Renew will make sure the address is still valid.

-- 
----------------------------------+-----------------
 Reporter:  [email-masked]  |      Owner:
     Type:  task                  |     Status:  new
 Priority:  P1 blocker            |  Milestone:
Component:  XML 3315              |   Keywords:
 Due Date:  31/12/2015            |
----------------------------------+-----------------

Ticket URL: <http://trac.tools.ietf.org/group/dhcpv6bis/ticket/152>
dhcpv6bis <http://tools.ietf.org/group/dhcpv6bis/>

---

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Tue, 01 Dec 2015 03:47:25 -0000

Comment (by [email-masked]):

 Sent the following to the DHC WG mailing list on 11/9. Jinmei has some
 comments.

 At Wed, 18 Nov 2015 21:43:01 +0000,
 "Bernie Volz (volz)" <[email-masked]> wrote:

 > I think your suggestions are reasonable. I am also be bit
 > uncomfortable connecting DHCPv6 to the RAs (and if we did, this would
 > only be for a case when the lifetime(s) from RAs change from non-zero
 > to zero since we wouldn't want a storm of requests with each RA). I'm
 > not sure that clients would always have access to the RAs and whether
 > having them monitor these is worth it.
 >
 > We could also be mostly silent on this issue (after all, RFC 3315 was).

 Either is fine for me.  If it doesn't require a protocol update (like how
 to interpret a 0-lifetime PIO in the context of DHCPv6), it might be
 better handled in a separate BCP-like document.

 --
 JINMEI, Tatuya

 --

 Hi Jinmei:

 I think your suggestions are reasonable. I am also be bit uncomfortable
 connecting DHCPv6 to the RAs (and if we did, this would only be for a case
 when the lifetime(s) from RAs change from non-zero to zero since we
 wouldn't want a storm of requests with each RA). I'm not sure that clients
 would always have access to the RAs and whether having them monitor these
 is worth it.

 We could also be mostly silent on this issue (after all, RFC 3315 was).

 It is interesting that a network I connect to which uses DHCPv6 also sends
 out RAs with the PIO for the stateful prefix having lifetimes of 0. It
 isn't yet fully clear why this is done. Note that in this case, per my
 above statement (when lifetimes change from non-zero to zero) should not
 trigger the client to Renew.

 - Bernie

 -----Original Message-----
 From: dhcwg [mailto:[email-masked]] On Behalf Of ????
 Sent: Wednesday, November 18, 2015 2:10 PM
 To: Bernie Volz (volz) <[email-masked]>
 Cc: [email-masked]
 Subject: Re: [dhcwg] IETF-94 Follow-up - draft-ietf-dhc-rfc3315bis -
 Prefix Lifetime of 0 (Ticket #152)

 At Tue, 10 Nov 2015 02:15:12 +0000,
 "Bernie Volz (volz)" <[email-masked]> wrote:

 > This is to confirm on the DHC WG mailing list our proposal to resolve
 > the RFC3315bis Ticket #152 (RA with prefix lifetime of 0) by updating
 > RFC3315bis as follows (see
 > http://trac.tools.ietf.org/group/dhcpv6bis/ticket/152 and
 > https://www.ietf.org/proceedings/94/slides/slides-94-dhc-5.pdf for
 > more details):

 > *       A DHCPv6 client SHOULD send a DHCPv6 Renew for a DHCPv6 assigned
 address if a Router Advertisement is received with a PIO for a prefix with
 a lifetime of 0 (and the address is contained in the prefix).

 First off, I think it should be clear which lifetime (valid or
 preferred) of the prefix it means.  Since the preferred only affects
 addresses configured using SLAAC this should be quite likely the valid
 lifetime.  But I think it's still better to be clear about that.

 And, more important, I'm not sure if this is a good idea as a way to
 "invalidate" DHCPv6-configured addresses.  In terms of the neighbor
 discovery protocol as described in RFC4861 a (valid) lifetime of 0 (with L
 bit on) simply means that prefix is no longer considered on-link.  That
 could happen even if the prefix itself is still usable.
 For example, the administrator may just want to force hosts to send all
 packets to a router rather than have them communicate directly.
 With the proposed new semantics of 0-lifetime prefix, we'll see
 unnecessary renew-reply exchanges in such a host site.  It does not
 necessarily cause a disruption, but the exchanges are simply a waste, and
 doesn't seem to be very elegant as part of the standard protocol.

 After all, this seems to be a hack to force DHCPv6 clients to invoke a
 renew-reply exchange in that we actually have this exact feature in
 DHCPv6 already: Reconfigure.  Now, I know no one is actually willing to
 use it in practice, but in that case we should actually try to fix that
 situation in 3315bis rather than rely on an RA-based hack since the
 capability of "force renew" seems to be needed in general.

 I also wonder whether we can control the prefix/address invalidation
 without relying on the RA hack or Reconfigure, e.g., when this happens as
 part of scheduled renumbering.  In that case the lifetimes of the
 delegated prefix and/or its T1/T2 would first be decreased.  Then the
 requesting PD router (acting as the DHCPv6 server for end hosts) would
 decrease the lifetimes of T1/T2 of the addresses it assign to the hosts so
 the end hosts will try to renew the addresses more frequently and the
 addresses will expire relatively sooner.  Meanwhile, if this is part of
 renumbering, the DHCPv6 server would now include new addresses from the
 new prefix in subsequent Renew/Reply exchanges.  This way the hosts will
 be renumbered in a more graceful manner.

 So I guess my specific suggestion would be:

 - Don't describe the RA-based hack as proposed
 - Explain a desired renumbering event as described above (or by
   refining it if necessary)
 - Suggest using Reconfigure in case unscheduled invalidation is
   necessary provided that it can be used safely

 --
 JINMEI, Tatuya

-- 
----------------------------------+-------------------------
 Reporter:  [email-masked]  |       Owner:
     Type:  task                  |      Status:  new
 Priority:  P1 blocker            |   Milestone:
Component:  XML 3315              |  Resolution:
 Keywords:                        |    Due Date:  31/12/2015
----------------------------------+-------------------------

Ticket URL: <http://trac.tools.ietf.org/group/dhcpv6bis/ticket/152#comment:1>
dhcpv6bis <http://tools.ietf.org/group/dhcpv6bis/>

---

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Tue, 01 Dec 2015 03:49:31 -0000

Conclusion I draw from above comments on the DHC WG ML is that we do NOT
 want to do this (mix RAs and DHCPv6). It raises more questions than it
 answers and it is probably just cleaner to leave it be (DHCPv6 leases are
 handled independent of what might come from RA).

 Thus, I recommend closing the ticket without making any changes.

Ticket URL: <http://trac.tools.ietf.org/group/dhcpv6bis/ticket/152#comment:2>
dhcpv6bis <http://tools.ietf.org/group/dhcpv6bis/>