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

[神明達哉 <[e-mail]>]

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