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

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

RFC 3315, 18.1.8 says that if the client receives a 'NoBinding' in
response to its Rebind, it should send a Request. Does anyone know the
reasoning behind that?

Does 'NoBinding' in DHCPv6 explicitly override an existing contract
for a lease? Can the client not continue to use its lease?

- Bud

> 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
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg