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

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 10 Nov 2015 02:15:12 +0000

Hi:

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).
*       This covers the case when the DHCPv6 Server that gave out the address has released the Delegated pool back to the Server
-      According to Ticket #151<http://trac.tools.ietf.org/group/dhcpv6bis/ticket/151>, the Request Router should transmit RAs with a lifetime of 0
-      Triggering a DHCPv6 Renew will make sure the address is still valid or new one may be assigned

If you want to comment on this (or ask for clarification), please respond by 11/23. The RFC3315bis team will otherwise update the draft as per the above.

Thanks.

-          Bernie

---

From: 神明達哉 <[email-masked]>
Date: Wed, 18 Nov 2015 11:09:52 -0800

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

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 18 Nov 2015 21:43:01 +0000

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:[email-masked]] On Behalf Of ????
Sent: Wednesday, November 18, 2015 2:10 PM
To: Bernie Volz (volz) <[email-masked]>
Cc: [email-masked]
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)" <[email-masked]> 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

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.

--
JINMEI, Tatuya

_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: 神明達哉 <[email-masked]>
Date: Thu, 19 Nov 2015 09:35:12 -0800

At Wed, 18 Nov 2015 21:43:01 +0000,
"Bernie Volz (volz)" <[email-masked]> wrote:

> 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.
>

Either is fine for me.  If it doesn't require a protocol update (like
how to interpret a 0-lifetime PIO in the context of DHCPv6), it might
be better handled in a separate BCP-like document.

--
JINMEI, Tatuya