Subject: question re REBIND in RFC 3315 (DHCPv6)

From: Karl Auer <[email-masked]>
Date: Thu, 27 Jun 2013 09:40:19 +1000

This sorta also relates to the ongoing efforts to redo DHCP failover for
v6. See:

http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-requirements-05

I get the feeling I've missed something obvious.

The description of how a server should respond to REBIND (RFC 3315
18.2.4) covers these three situations:
 - the IA is found and the addresses are OK
 - the IA is found and the addresses are not OK
 - the IA is NOT found and the addresses are not OK

It does NOT appear to cover the situation where the IA is not found and
the addresses *are* OK. Yet this situation is the only one where there
is any difference between RENEW and REBIND, and the only situation where
a client is likely to get to the point of sending a REBIND - i.e.,
because the server that is holding the IA for the client's addresses is
not responding to a RENEW.

I'm not sure I see the point of REBIND if no server apart from the
original one is ever going to be able to permit continued use of the
address.

Looking to DHCPv4 for a hint, the description of rebinding in RFC 2131
was:

   "The DHCPREQUEST from a REBINDING client is intended to accommodate
    sites that have multiple DHCP servers and a mechanism for
    maintaining consistency among leases managed by multiple servers.
    A DHCP server MAY extend a client's lease only if it has local
    administrative authority to do so.

In DHCPv6 (minus failover) there seems to be no "mechanism for
maintaining consistency", and there is no mention in RFC 3315 of any
additional behaviour involving "local administrative authority".

So is REBIND basically pointless in DHCPv6?

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer ([email-masked])
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A
Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017

---

From: Ralph Droms <[email-masked]>
Date: Thu, 27 Jun 2013 07:17:42 -0400

> not responding to a RENEW.

There is another difference between REBIND and RENEW: the client includes the Server Identifier of the server from which the client received the IA in the RENEW message (but not the REBIND).  In multi-server deployments, a RENEW is processed only by the relevant server, while a REBIND can be processed by any server.  The differentiation is specified up in sections 15.5 and 15.6:

15.6. Renew Message

   Clients MUST discard any received Renew messages.

   Servers MUST discard any received Renew message that meets any of the
   following conditions:

   -  the message does not include a Server Identifier option.

   -  the contents of the Server Identifier option does not match the
      server's identifier.

   -  the message does not include a Client Identifier option.

15.7. Rebind Message

   Clients MUST discard any received Rebind messages.

   Servers MUST discard any received Rebind messages that do not include
   a Client Identifier option or that do include a Server Identifier
   option.

> original one is ever going to be able to permit continued use of the

The idea is that some external data channel is used to replicate the IA binding from the responsible server to all the other servers.

> additional behaviour involving "local administrative authority".

There's no such mechanism defined in DHCPv4 (RFC 2131 and RFC 2132), either.  It may be an oversight that it is not mentioned as "out of scope" in RFC 3315.

- Ralph

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 27 Jun 2013 11:26:26 +0000

I've been trying to get the DHC WG to address this issue but there appears to be zero interest in doing anything about it - see http://www.ietf.org/mail-archive/web/dhcwg/current/msg14315.html.

- Bernie (from iPad)

On Jun 27, 2013, at 7:18 AM, "Ralph Droms" <[email-masked]<mailto:[email-masked]>> wrote:

On Jun 26, 2013, at 7:40 PM 6/26/13, Karl Auer <[email-masked]<mailto:[email-masked]>> wrote:

15.6. Renew Message

15.7. Rebind Message

- Ralph

Regards, K.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer ([email-masked]<mailto:[email-masked]>)
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Karl Auer <[email-masked]>
Date: Fri, 28 Jun 2013 00:09:04 +1000

On Thu, 2013-06-27 at 07:17 -0400, Ralph Droms wrote:
> There is another difference between REBIND and RENEW: the client
> includes the Server Identifier of the server from which the client
> received the IA in the RENEW message (but not the REBIND).

Yes. My question could be summarised I suppose as "what's the point of
REBIND?" You answer that:

> The idea is that some external data channel is used to replicate the
> IA binding from the responsible server to all the other servers.

And there is no such channel. As you say:

> There's no such mechanism defined in DHCPv4 (RFC 2131 and RFC 2132),
> either.  It may be an oversight that it is not mentioned as "out of
> scope" in RFC 3315.

The separately defined (albeit still draft) failover system is that
mechanism for DHCPv4.

So, at the moment and absent any failover for DHCPv6, there is no point
to REBIND except for the dubious benefit that addresses that are no good
any more can possibly be confirmed as duds by other servers.

Regards, K.

---

From: Karl Auer <[email-masked]>
Date: Fri, 28 Jun 2013 00:18:57 +1000

On Thu, 2013-06-27 at 11:26 +0000, Bernie Volz (volz) wrote:
> I've been trying to get the DHC WG to address this issue but there
> appears to be zero interest in doing anything about it -
> see http://www.ietf.org/mail-archive/web/dhcwg/current/msg14315.html.

I'm interested. Dunno what practical difference that makes :-)

I think it would be useful to have the additions you suggest. However, I
would suggest making explicit the reasoning for them, and making
explicit the potential for IAs to be updated between servers by an
out-of-scope mechanism.

Regards, K.

---

From: Ralph Droms <[email-masked]>
Date: Thu, 27 Jun 2013 11:34:58 -0400

On Jun 27, 2013, at 10:09 AM 6/27/13, Karl Auer <[email-masked]> wrote:

> And there is no such channel.

Not yet, as part of the DHCP suite of specifications.  Other channels, such as a distributed database or grad students at keyboards calling each other, can be (have been?) used.

> As you say:

I would be a little more optimistic and say that REBIND is specified, (presumably) implemented and ready to use for non-DHCP mechanisms or failover (when specified).

- Ralph

---

From: Mark ZZZ Smith <[email-masked]>
Date: Thu, 27 Jun 2013 17:13:07 -0700 (PDT)

----- Original Message -----
> From: Karl Auer <[email-masked]>
> To: IETF IPv6 <[email-masked]>
> Cc: 
> Sent: Friday, 28 June 2013 12:09 AM
> Subject: Re: question re REBIND in RFC 3315 (DHCPv6)
> 

Perhaps a DHCPv6 server could have a "promiscuous mode" where it accepts and permits the addresses it doesn't know about in REBIND messages, with an upper total limit to prevent DoS.

One thing that is easy to forget is that the address preferred and valid lifetimes should dictate whether a host can continue to use addresses issued by stateful DHCPv6. If a host resorts to a DHCPv6 REBIND, and the server doesn't know about the addresses, the host should continue to use the addresses while they continue to have a valid lifetime. A host should only stop using addresses assigned via stateful DHCPv6 if the preferred and valid lifetimes are specifically set via a RENEW or REBIND to deprecated values (zero for preferred, 7200 for valid IIRC).

Regards,
Mark.

---

From: Karl Auer <[email-masked]>
Date: Fri, 28 Jun 2013 10:32:34 +1000

On Thu, 2013-06-27 at 17:13 -0700, Mark ZZZ Smith wrote:
> Perhaps a DHCPv6 server could have a "promiscuous mode" where it
> accepts and permits the addresses it doesn't know about in REBIND
> messages, with an upper total limit to prevent DoS.

It needs to know about them at least in so far as the server is
responsible for the range, and knows that the addresses concerned are
appropriate for the client's link.

> If a host resorts to a DHCPv6 REBIND, and the server doesn't know
> about the addresses, the host should continue to use the addresses
> while they continue to have a valid lifetime.

*Stopping* using inappropriate addresses is thoroughly dealt with, both
in RENEW and REBIND, and in the eventual expiry of addresses if neither
of those mechanisms is working.

The issue that REBIND is supposed to solve, though as it turns out, only
with the addition of a moving part that no-one has actually built yet,
is the problem of allowing a client to *continue* using an address, even
if the server that originally allocated that address is not answering
the phone.

Regards, K.

---

From: Mark ZZZ Smith <[email-masked]>
Date: Thu, 27 Jun 2013 22:45:19 -0700 (PDT)

----- Original Message -----
> Sent: Friday, 28 June 2013 10:32 AM
> is the problem of allowing a client to *continue* using an address,

I think a client is allowed to continue to use an address if the address's valid lifetime is non-zero, regardless of how that address was acquired, be it stateful DHCPv6, SLAAC or static.

Stateful DHCPv6 doesn't seem to tightly bind the state of addresses it issues to the state of the DHCPv6 session, such that if the DHCPv6 session goes away the addresses go away. If it did, I think there would be would be statements in RFC3315 to set T1 and T2 timers to the values intended for prefix preferred and valid lifetimes, there would be no need for preferred and valid lifetime fields in the IAs for addresses, and there would be statements saying that if the DHCPv6 session fails for any reason then the client MUST remove the addresses acquired during that session. 

I think this means that at RENEW or REBIND time, the client is only checking to see if there are updated values for the addresses (and other options), and to register a continuing interest in using the addresses. The client is not seeking permission to continue to use the addresses, such that absence of the DHCPv6 server would mean that it doesn't have permission any more. If the client has non-zero valid lifetimes for the DHCPv6 supplied addresses, that is all the permission it needs to continue to use them.

I think this is what allows SLAAC and stateful DHCPv6 to co-exist, which then allows a transition between one method and the other. The only arbiter of whether an address on a host is valid or deprecated is the host's own values of the preferred and valid lifetimes. Stateful DHCPv6 or RA PIOs can be used to change those values, indirectly controlling the address validity, but disappearance of the DHCPv6 server or the router issuing PIO containing RAs shouldn't cause the addresses that were configured using that method to then immediately become invalid.

Regards,
Mark.

> even

---

From: Karl Auer <[email-masked]>
Date: Fri, 28 Jun 2013 16:55:15 +1000

On Thu, 2013-06-27 at 22:45 -0700, Mark ZZZ Smith wrote:
> I think a client is allowed to continue to use an address if the
> address's valid lifetime is non-zero, regardless of how that address
> was acquired, be it stateful DHCPv6, SLAAC or static.

That's debatable according to Microsoft. Send an RA past with the M flag
unset and watch the addresses get dropped! Valid schmalid. I consider
that behaviour a bug, but opinions do apparently differ. The way you
describe it is how it should be, but sometimes isn't.

> Stateful DHCPv6 doesn't seem to tightly bind the state of addresses it
> issues to the state of the DHCPv6 session, such that if the DHCPv6
> session goes away the addresses go away. 

There is no session...? Not sure what you are saying here.

> If it did, I think there would be would be statements in RFC3315 to
> set T1 and T2 timers to the values intended for prefix preferred and
> valid lifetimes

Not to those values, but the RFC does say that they should be set with
reference to the preferred and valid lifetimes:

   The server selects the T1 and T2 times to allow the client to extend
   the lifetimes of any addresses in the IA_NA before the lifetimes
   expire, even if the server is unavailable for some short period of
   time.  Recommended values for T1 and T2 are .5 and .8 times the
   shortest preferred lifetime of the addresses in the IA that the
   server is willing to extend, respectively.  If the "shortest"
   preferred lifetime is 0xffffffff ("infinity"), the recommended T1 and
   T2 values are also 0xffffffff.

But it can be left to the client, which would then presumably choose
not-dissimilar values:

   If the time at which the addresses in an IA_NA are to be renewed
   is to be left to the discretion of the client, the server sets
   T1 and T2 to 0.

> there would be statements saying that if the DHCPv6 session fails for
> any reason then the client MUST remove the addresses acquired during
> that session. 

There is no session...? The RFC *does* say that if the client cannot
renew its addresses before they expire it must stop using them. It must
also remove them if, during RENEW or REBIND, the responding server
authoritatively rejects them (see sections 18.2.4 and 19.4.5) by setting
their lifetimes to zero.
 
> I think this means that at RENEW or REBIND time, the client is only
> checking to see if there are updated values for the addresses (and
> other options), and to register a continuing interest in using the
> addresses. The client is not seeking permission to continue to use the
> addresses, such that absence of the DHCPv6 server would mean that it
> doesn't have permission any more. If the client has non-zero valid
> lifetimes for the DHCPv6 supplied addresses, that is all the
> permission it needs to continue to use them.

well - yes - but the responding server might set them to zero. Or it
might return the same values as last time, refreshing the lease. It
could even shorten the lease without terminating it. But from the
client's perspective, the RENEW and REBIND messages are absolutely about
the client seeking to extend its use of its addresses. I'm not sure I
see the distinction in your statement above.

> The only arbiter of whether an address on a host is valid or
> deprecated is the host's own values of the preferred and valid
> lifetimes. Stateful DHCPv6 or RA PIOs can be used to change those
> values, indirectly controlling the address validity, but disappearance
> of the DHCPv6 server or the router issuing PIO containing RAs
> shouldn't cause the addresses that were configured using that method
> to then immediately become invalid.

Well, no. How does the host know they've "disappeared" anyway? There is
no "session". If the host doesn't see RAs for long enough the valid
lifetime of a SLAAC expires and the address must be dropped. If the host
doesn't get answers to RENEW and REBIND messages, the valid lifetime of
a an address acquired via DHCPv6 expires and the address must be
dropped. It's a pretty simple setup, really.

The question that started all this was whether a REBIND can ever be used
by a server to extend the lease on an address it didn't allocate. Short
answer is "no". The longer answer is "no, unless there is some kind of
sharing of IAs happening, which is not specified in RFC3315".

Regards, K.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 28 Jun 2013 12:32:49 +0000

The sharing part was out of scope for 3315. Failover might be one such mechanism (which is being worked on in the DHC wg). There are others such as a shared database.

And there is also the ability to trust clients as long as there is no conflict (known by the server). So while perhaps not directly spelled out in 3315, a server could use the client supplied information to generate the bindings and leases. With failover, there are reasons why doing this might be appropriate -- the lazy update might not have been sent before the partner that gave out the lease went down. This is done in v4 failover.

I'm not surr why this isn't on the dhc wg mailing list?

- Bernie (from iPad)