Re: [dhcwg] IETF-94 Follow-up - draft-ietf-dhc-rfc3315bis - Release Delegated Prefix (Ticket #151)

["Bernie Volz (volz)" <[e-mail]>]

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

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of ????
Sent: Tuesday, November 10, 2015 2:46 PM
To: Bernie Volz (volz) <[e-mail]>
Cc: [e-mail]
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)" <[e-mail]> 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