Subject: [Dhcpv6bis] [dhcpv6bis] #151 (XML 3315): Release IA_PD information

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

#151: Release IA_PD information

 There is currently no text for if/when a client should invalidate prefix
 information that has been delegated when a DHCPv6 Release for a IA_PD is
 performed.

 Solution:
 The prefix should be invalidated once the DHCPv6 Release is performed.
 For example, RAs must be transmitted to set the preferred lifetime to
 zero.

-- 
----------------------------------+-----------------
 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/151>
dhcpv6bis <http://tools.ietf.org/group/dhcpv6bis/>

---

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Tue, 10 Nov 2015 19:53:24 -0000

Comment (by [email-masked]):

 From: [email-masked] [mailto:[email-masked]] On Behalf
 Of ????
 Sent: Tuesday, November 10, 2015 2:46 PM
 To: Bernie Volz (volz) <[email-masked]>
 Cc: [email-masked]
 Subject: Re: [dhcwg] IETF-94 Follow-up - draft-ietf-dhc-rfc3315bis -
 Release Delegated Prefix (Ticket #151)

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

 > This is to confirm on the DHC WG mailing list our proposal to resolve
 the RFC3315bis Ticket #151 (Release Delegated Prefix) by updating
 RFC3315bis as follows (see
 http://trac.tools.ietf.org/group/dhcpv6bis/ticket/151 and
 https://www.ietf.org/proceedings/94/slides/slides-94-dhc-5.pdf for more
 details):
 >
 > The problem statement is that there is currently no text for if and when
 a requesting router should invalidate prefix information that has been
 delegated to it when the requesting router issues a release for a prefix
 (or prefixes).
 >
 > The proposed solution is  that the prefix should be invalidated once the
 DHCPv6 Release is performed - the RAs must be transmitted to set the
 prefix lifetimes to zero in the PIO for the released prefixes.

 As I noted in the meeting, it's not trivial to invalidate an end hosts'
 prefix.

 To recap: First, just setting the preferred lifetime to 0 as suggested on
 the issue tracker is obviously not enough since addresses generated from
 the prefix will still be valid.  Setting the valid lifetime to 0 is also
 not enough since hosts will still use the derived address(es) for at least
 2 hours according to Section 5.5.3 of RFC4862.

 I'm not sure which level of detail should be described in rfc3315bis, but
 a graceful invalidation process would be something like this:

 1. The requesting router decides to invalidate a prefix.
 2. The requesting router starts advertising an RA with PIO for the
    prefix whose valid and preferred lifetimes are 0.  It keeps
    advertising this RA for at least 2 hours. (It should probably keep
    advertising the 0-lifetime prefix longer, in case some hosts fail
    to receive the prefix during the 2-hour window) 3. The requesting
 router sends a DHCPv6 Release for the prefix to the
    delegating router.

 If, for some reason, the requesting router finds it has to release the
 prefix immediately...it'll be tricky, but there's probably not much the
 requesting router can do in that case.  Again, I'm not sure how much
 rfc3315bis should discuss this, but some possible points are:
 - It's generally discouraged to perform such a non-graceful release
 - If it's inevitable, it's advisable for the requesting router to
   filter packets using an address generated from the now-released
   prefix
 - The requesting router should still advertise the 0-lifetime prefix
   via RAs as described in the graceful scenario

 You may also want to refer to RFC4192.

 --
 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/151#comment:1>
dhcpv6bis <http://tools.ietf.org/group/dhcpv6bis/>

---

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Tue, 10 Nov 2015 19:55:03 -0000

To JINMEI's email, I replied:

 Thanks Jinmei.

 Since this is the release case, perhaps the 3315bis text says that a PD
 Release should only be done if the PD is not already in use (i.e.
 advertised in a PIO or assigned to DHCP and addresses leased) or the
 process to deprecate the prefix must be started early enough to allow all
 this to occur (i.e., 2 hours previous).

 We likely should also add that DHCPv6 Reconfigure messages to clients
 could be used to expedite deprecating the prefix (when stateful address
 assignment is used).

 This likely has some interaction with Ticket #152 (as that represents the
 client side behavior).

 - Bernie

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