Re: [dhcwg] Adopt draft-troan-dhc-dhcpv6-stateful-issues-00 as WG item

> Also, the idea to use RENEW to get new address/prefix will not work
with conformant implementations.

Correct. Existing servers will respond as they have been. But clients
will be no worse off than they are today. This is probably a point that
should be made and clients that can't expect new servers will have to
live with the old behavior.

What would you propose? Doing a REQUEST hardly seems correct either.

We want to avoid separate 'state machines' in the clients and have one
set of request messages handle the client recovering.

Note also that I believe that the REBIND behavior as specified today is
BROKEN for failover. Consider the case Server A gives out a lease but
goes down before updating its partner, Server B. Server B now gets the
REBIND at T2. It would send back NoBinding as it has no record of the
client and/or bindings. This needs to change too for failover to work -
at least if we want to be consistent with the way we handle this in v4
failover.

I don't think the RENEW (or REBIND) is damaged by allowing new bindings.
The client is still asking to renew leases but to also get new ones. Why
is that so bad? The addresses (or prefix) can change in a
Renew/Rebinding, so why not allow new bindings?

Note that we are NEVER saying a client can send a RENEW or REBIND
without having at least one valid lease. It must at least have one
binding & lease.

- Bernie

-----Original Message-----
From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf
Of Tomek Mrugalski
Sent: Sunday, April 08, 2012 6:36 PM
To: Bernie Volz (volz)
Cc: dhcwg@ietf.org; Ole Troan
Subject: Re: [dhcwg] Adopt draft-troan-dhc-dhcpv6-stateful-issues-00 as
WG item

On 12-04-08 23:26, Bernie Volz (volz) wrote:
> Regarding 0, no. This work would be folded into 3315bis but it should 
> proceed separately. Primarily because it is needed "now" and the 
> 3315bis work will probably be at a much slower pace.
> ...
> This work is really related to 6204bis and the fact that the cable 
> market needs the router behavior to be clarified.
Sure. In that case pick only those of my comments that you think are
useful in 6204bis context and we can get back to the other ones later
during 3315bis work.

> back to Solicit, this allows the client the ability to RENEW the IA_PD

> and include the IA_NA to get a new address (that hopefully won't have 
> the DAD or other conflict). Note that in this RENEW, the IA_NA would 
> not have an IA_ADDR option (or if it does, it would be the unspecified

> address).
Ok, that is less scary than it initially looked. Nevertheless, I still
don't like it much. Using RENEW to request new addresses or prefixes is
wrong and will not work. It is true that to some extent REQUEST and
RENEW work in similar manner, but they were kept separated for a reason.
I would prefer to send a separate REQUEST for requesting new
allocations.

Also, the idea to use RENEW to get new address/prefix will not work with
conformant implementations. Servers will send back IA, but with status
code set to NoBinding. Here's appropriate part of 3315, section 18.2.3:

   If the server cannot find a client entry for the IA the server
   returns the IA containing no addresses with a Status Code option set
   to NoBinding in the Reply message.

So no, don't request anything new in RENEW. That's what REQUEST is for.

Tomek
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg