Re: [dhcwg] IETF-94 Follow-up - draft-ietf-dhc-rfc3315bis

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:dhcwg-bounces@ietf.org] On Behalf Of ????
Sent: Wednesday, November 18, 2015 2:10 PM
To: Bernie Volz (volz) <volz@cisco.com>
Cc: dhcwg@ietf.org
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)" <volz@cisco.com> 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

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg