Subject: RE: Question about REBIND message

From: [email-masked]
Date: Wed, 14 Mar 2001 09:40:16 -0600

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

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.

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

the t1 and t2 have a default case too. so they always work.  the client will
work with a server.  but suppose that server copys all client records to
another server.  when the rebind happens the other server could respond. 

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

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.

/jim

---

From: Jerome Labussiere <[email-masked]>
Date: Wed, 14 Mar 2001 18:07:16 +0100

> 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: Ralph Droms <[email-masked]>
Date: Mon, 19 Mar 2001 00:39:01 -0500

> > 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: Ralph Droms <[email-masked]>
Date: Mon, 19 Mar 2001 00:38:55 -0500

>necessarily the best. I can't find anything in the spec about this.

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