Subject: Question about REBIND message

From: Jerome Labussiere <[email-masked]>
Date: Wed, 14 Mar 2001 15:48:44 +0100

Hello

In the -18 rev, it is said that the client send the REBIND message at T2
(section 16.2) to 'any available server' in order to extend the
lifetimes of an IA, if the primary server has not responded at T1. I
guess 'any available server' means any server which can receive the
message (because it is onlink or via a relay). However, according to
section 13.4.4 the server can successfully extend the lifetimes only if
it has a binding for this client.

Does that mean that the client should follow the REQUEST/REPLY process
for a single IA with many servers ? If so, what T1 and T2 and lifetimes
should we consider ? If not, how the rebinding is possible ?

Assume a server with no binding returns an IA Empty/NoBinding REPLY
message before a server with a binding. How should we handle this ?
Should we wait for an other reply ? How much time ? Same thing for all
messages with 0 in the server-adress field.

I don't get the idea. Please, could you explain.

Thanks

Jerome Labussiere

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Wed, 14 Mar 2001 14:14:45 -0600

I think that the server should be able to send back:
- Success
- No Binding
- Bad prefixes (or some similar error status that means that the server is authoritative for the link and that the prefixes are invalid for that particular link)
- Bad binding (or some similar error status that means that the address(es) are in use by another client)

Ideally, the above could be on each individual address in an IA.

What a client would do is wait until it got back some status. The meanings would be:
- Success -> addresses are OK to use
- No binding -> this server has no record of the bindings, but the PREFIXES are valid for the link
- Bad prefixes -> the client is on a new link
- Bad binding -> the client's addresses are bad (prefixes are OK, though that may be meaningless)

If the client gets back Success, it can use the addresses.
If the client gets back Bad Prefixes or Bad Binding, it needs to go to Solicit to find a server to get addresses.
If the client gets back No Binding, it can use the addresses (unless it later receives a Bad Binding)

- Bernie

-----Original Message-----
From: Jerome Labussiere [mailto:[email-masked]]
Sent: Wednesday, March 14, 2001 12:07 PM
To: DHCPv6 discussion list
Subject: Re: Question about REBIND message

[email-masked] wrote:
> 
> > -----Original Message-----
> > From: ext Jerome Labussiere [mailto:[email-masked]]
> > Sent: Wednesday,March 14,2001 9:49 AM
> > To: DHCPv6 discussion list
> > Subject: Question about REBIND message
> >
> >
> > Hello
> >
> thats correct. the idea is if another server thru some other means can do
> this we don't want to prohibit the function for rebind.
> the client should react immediately is my view.  this is a case where we
> don't want mobile nodes hanging out.  clients can always do policing of
> packets esp mobile nodes.
> 

Ok, so the idea of REBIND is to try everything to keep a set of
addresses. 

Still one dark point: About 'reacting immediately', I've the feeling
that it works with one DHCP server in the domain. But with two ? For
instance, if the client has a binding with server A. For a good reason,
it has to send a CONFIRM message. Server A and server B receive the
CONFIRM and answer. A returns a REPLY/status 0 and B returns a
REPLY/Status NoBinding. Unfortunately, B's REPLY is received first by
the client and A's REPLY is received one or two ms after. If the client
reacts immediately, according to section 13.3.5, it has to assume that
the IA is lost and that it needs to notify the application layer and to
send a Request to reestablish an IA with B. The first REPLY is not
necessarily the best. I can't find anything in the spec about this.

Jerome Labussiere

---

From: [email-masked]
Date: Thu, 15 Mar 2001 11:00:51 -0600

Jerome,

Good catch. We should all discuss if we need a REBIND_TIME_XXX value before
the client does new Request.  Would that address this in your mind.

thanks and again good catch,
/jim

> Sent: Wednesday,March 14,2001 12:07 PM

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Mon, 19 Mar 2001 00:43:46 -0600

Ralph:

Can a server REJECT the REBIND? Suppose a server finds that one or more
of the addresses is in use by a different binding?

Can the server add more addresses to the REBIND? It could on a RENEW, so
why can't this happen on a REBIND?

The difference between the REBIND and the RENEW is simply that for the
REBIND some other server (if authoritative for the network) can respond
in the same way that the original server could have on a RENEW.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Monday, March 19, 2001 12:39 AM
To: DHCPv6 discussion list
Cc: DHCPv6 discussion list
Subject: Re: Question about REBIND message

> > this we don't want to prohibit the function for rebind.

I disagree - I think there is an error in the -18 rev of the DHCPv6 
spec.  A server should silently discard any Rebind messages to which it 
cannot respond.  DHCPv4 leaves the decision about whether to respond to a 
DHCPREQUEST from a client in REBINDING state to loca administrative control 
(section 4.3.2 of RFC2131):

>       A DHCP server MAY extend a client's lease only if it has local
>       administrative authority to do so.

Implicitly, a DHCPv4 server may create a new binding and extend the lease 
of a previously unknown client if the server is authorized to do so.

I suggest that the text in the DHCPv6 spec should be changed to read:

   If the server cannot find a client entry for this IA, the server
   MAY create a new binding for the IA and send a Reply message to
   the client with the lease on the IA.  If the server does not
   create a new binding it MUST silently discard the Rebind message.

This text may need to be extended to specify that the server may *only* 
change the lease on the IA and *may not* make any other changes to the 
addresses assigned to the IA.

- Ralph

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Mon, 19 Mar 2001 00:48:03 -0600

Ralph:

If on a CONFIRM the server knows that the addresses have prefixes that
don't exist on the link, can't the server tell that to the client? Or,
must the client wait until some timeout time elapses before it can learn
(or assume) it has moved to a new link? And, what if all of the DHCP
servers are down - how can the client tell this from having moved to a
new link?

I would like to see a "BadPrefixes" or similar status.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Monday, March 19, 2001 12:39 AM
To: DHCPv6 discussion list
Cc: DHCPv6 discussion list
Subject: Re: Question about REBIND message

Jerome,

You've identified a potential error in the DHCPv6 spec.  The following text 
in 13.4.2 of the -18:

>    If the server cannot find a client entry for this IA the server
>    SHOULD return an empty IA with status set to NoBinding.

is, IMHO, wrong.  A server should ignore a CONFIRM message for which it has 
no information.

IN DHCPv4, servers with no information about a binding do not respond to a 
request from a client to confirm the correctness of its address 
(DHCPREQUEST in INIT_REBOOT state).  Here is the related text from DHCPv4, 
RC2131, section 3.2:

>    2. Servers with knowledge of the client's configuration parameters
>       respond with a DHCPACK message to the client.  Servers SHOULD NOT
>       check that the client's network address is already in use; the
>       client may respond to ICMP Echo Request messages at this point.
>       If the client's request is invalid (e.g., the client has moved
>       to a new subnet), servers SHOULD respond with a DHCPNAK message to
>       the client. Servers SHOULD NOT respond if their information is not
>       guaranteed to be accurate.  For example, a server that identifies a
>       request for an expired binding that is owned by another server SHOULD
>       NOT respond with a DHCPNAK unless the servers are using an explicit
>       mechanism to maintain coherency among the servers.

The text in 13.4.2 of the -18 rev of the DHCPv6 spec should read:

>    If the server cannot find a client entry for this IA the server
>    MUST silently discard the Confirm message.

Ralph