Subject: RE: [dhcwg] questions about dhcpv6-28

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Wed, 5 Feb 2003 12:40:13 -0600

I think we need to think this through a bit more ...

If the other servers don't respond, at which point does the client do something
differently than continue to Rebind. From 18.1.4, we have:

      MRD   Remaining time until valid lifetimes of all addresses have
            expired

It clearly stops when the valid lifetimes of all addresses expire, however at that
point it no longer has any addresses (whereas it could long ago have obtained new
addresses from another server and Reply's from other servers with NoBinding would
tell the client that other servers exist).

Also, for the Rebind case, there is no Server Identifier. So, if the server that
originally had the binding crashed and losts its stable storage and comes back on
line after the T2 time has started, how does that server even know to respond? It
would not since it has no memory. (If the server restarts before T2, it would
properly respond to the Renew with NoBinding and all would be well.) In a failover
configuration and assuming concepts from the DHCPv4 failover protocol, the lazy
update to the peer may also never have occurred.

This is why I believe option 2 (having the client make the determination) is much
better. The client has the memory of which server gave it the binding. I agree
that this has failings in a failover type arrangement [though there are other
potential tricks that could be played in this configuration - such as the
remaining server responding as if it were the first server, ie, with that server's
server identifier that could be played].

Also, if the client receives NO responses to the Rebind, it can conclude there are
no other servers so even going to Solicit would do it no good. Yet, if the client
does receive NoBindings, perhaps we should allow it (once the PREFERRED LIFETIMES
expire), to try a Request or Solicit instead of contining to Rebind?

So, we could have the client handle it this way:
- If the server that assigned the binding responds with NoBinding, do a Request
(or Solicit).
- If there are no Replies to the Rebind, continue to Rebind until the valid
lifetimes expire.
- If there are Replies with NoBinding, the client can make a decision as to
whether to Solicit or Request based on the remaining PREFERRED lifetimes.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Wednesday, February 05, 2003 9:26 AM
To: [email-masked]
Subject: Re: [dhcwg] questions about dhcpv6-28

I agree that we should consider the issue of an inter-server protocol to be 
out of scope for now.  We have experience in designing DHCPv4 so that the 
client-server protocol is independent of the server-server protocol.

I would prefer option 1 - the server ignores a Rebind message for which it 
has no explicit information.

- Ralph

At 07:20 PM 2/4/2003 +0900, JINMEI Tatuya / 
=?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote:
>(In the followings, I folded some long lines)
>
> >>>>> On Tue, 28 Jan 2003 12:42:33 -0600,
> >>>>> "Bernie Volz (EUD)" <[email-masked]> said:
>
> >> Ralph pointed out to me the possibility of some "magic" between a
> >> primary server and a backup server, which allows those servers to be
> >> synchronized in real time.  I'm not sure how this is realistic,
> >> either, but I'd personally prefer to keep the possibility.
>
> > For DHCPv6 there seems to me a better way to handle things like failover?
>
> > The two standard mechanisms would be:
> > 1. Failover like protocol between the two servers
> > 2. Redundant backend database
>
> > But, with the large IPv6 addresses, there is another way which I
> > think is even better and requires no communication between
> > "redundant" servers (well, there is the configuration issues but
> > there is no need or minimal need for ongoing communication). The
> > idea is as follows:
>
>(snip)
>
> > I wonder whether the DHC WG might take this on - to specify how
> > redundant DHCPv6 services could or should be built? I think it will
> > be easier than the DHCPv4 failover work and may not require any
> > protocol - just a way of working? But, then perhaps this is simply
> > left to the server implementers to decide how best to work and
> > interoperability between several vendors is not required?
>
>Thanks for the detailed analysis.  I, for one, think the mechanism to
>provide the redundancy among multiple servers can be out of scope for
>the dhc wg (at least for now).
>
>Going back to the original question, what should the server do when it
>receives a Rebind containing an IA for which the receiving server does
>not have a binding?
>
>Option 1 (from Ralph): the server should ignore the Rebind unless it
>has an "explicit" knowledge that the binding has been invalidated.
>
>Option 2 (from Bernie): the server should return a Reply with
>NoBinding anyway, and let the client choose the reaction based on the
>Server Identifier that provided the IA.
>
>As I said before, I prefer Option 1.
>
>                                         JINMEI, Tatuya
>                                         Communication Platform Lab.
>                                         Corporate R&D Center, Toshiba Corp.
>                                         [email-masked]
>_______________________________________________
>dhcwg mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/dhcwg

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