Re: [dhcwg] IETF-94 Follow-up - draft-ietf-dhc-rfc3315bis - Prefix Lifetime of 0 (Ticket #152)

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

At Tue, 10 Nov 2015 02:15:12 +0000,
"Bernie Volz (volz)" <[e-mail]> 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