Re: question re REBIND in RFC 3315 (DHCPv6)

Mark ZZZ Smith <markzzzsmith@yahoo.com.au> Fri, 28 June 2013 00:13 UTC

DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=jYpRlNAjmK+gJX6MD5+4ZorDOZw+LSgT0ILXuWvSTxSPaynoXVc3OhVzH0cGOsQ9uLpkwfVTFJxv0Yyri75lwsyPsJ8CsmC3jYjDq+aP385wdtsa4RsiBcnVocGDQFUYrnHrXzRuXW/djU56VVbsd8fOcjoxKOO1ndc/dbyPVIk=;
References: <1372290019.3215.32.camel@karl> <3ED742F1-C82A-43E3-A2CD-CAD8F1E283B1@gmail.com> <1372342144.3215.106.camel@karl>
Message-ID: <1372378387.65495.YahooMailNeo@web142504.mail.bf1.yahoo.com>
Date: Thu, 27 Jun 2013 17:13:07 -0700
From: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
Subject: Re: question re REBIND in RFC 3315 (DHCPv6)
To: Karl Auer <kauer@biplane.com.au>, IETF IPv6 <ipv6@ietf.org>
In-Reply-To: <1372342144.3215.106.camel@karl>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Precedence: list
Reply-To: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>

----- Original Message -----
> From: Karl Auer <kauer@biplane.com.au>
> To: IETF IPv6 <ipv6@ietf.org>
> Cc: 
> Sent: Friday, 28 June 2013 12:09 AM
> Subject: Re: question re REBIND in RFC 3315 (DHCPv6)
> 
> On Thu, 2013-06-27 at 07:17 -0400, Ralph Droms wrote:
>>  There is another difference between REBIND and RENEW: the client
>>  includes the Server Identifier of the server from which the client
>>  received the IA in the RENEW message (but not the REBIND).
> 
> Yes. My question could be summarised I suppose as "what's the point of
> REBIND?" You answer that:
> 
>>  The idea is that some external data channel is used to replicate the
>>  IA binding from the responsible server to all the other servers.
> 
> And there is no such channel. As you say:
> 
>>  There's no such mechanism defined in DHCPv4 (RFC 2131 and RFC 2132),
>>  either.  It may be an oversight that it is not mentioned as "out of
>>  scope" in RFC 3315.
> 
> The separately defined (albeit still draft) failover system is that
> mechanism for DHCPv4.
> 
> So, at the moment and absent any failover for DHCPv6, there is no point
> to REBIND except for the dubious benefit that addresses that are no good
> any more can possibly be confirmed as duds by other servers.
> 

Perhaps a DHCPv6 server could have a "promiscuous mode" where it accepts and permits the addresses it doesn't know about in REBIND messages, with an upper total limit to prevent DoS.

One thing that is easy to forget is that the address preferred and valid lifetimes should dictate whether a host can continue to use addresses issued by stateful DHCPv6. If a host resorts to a DHCPv6 REBIND, and the server doesn't know about the addresses, the host should continue to use the addresses while they continue to have a valid lifetime. A host should only stop using addresses assigned via stateful DHCPv6 if the preferred and valid lifetimes are specifically set via a RENEW or REBIND to deprecated values (zero for preferred, 7200 for valid IIRC).

Regards,
Mark.

question re REBIND in RFC 3315 (DHCPv6) Karl Auer
Re: question re REBIND in RFC 3315 (DHCPv6) Ralph Droms
Re: question re REBIND in RFC 3315 (DHCPv6) Bernie Volz (volz)
Re: question re REBIND in RFC 3315 (DHCPv6) Karl Auer
Re: question re REBIND in RFC 3315 (DHCPv6) Karl Auer
Re: question re REBIND in RFC 3315 (DHCPv6) Ralph Droms
Re: question re REBIND in RFC 3315 (DHCPv6) Mark ZZZ Smith
Re: question re REBIND in RFC 3315 (DHCPv6) Karl Auer
Re: question re REBIND in RFC 3315 (DHCPv6) Mark ZZZ Smith
Re: question re REBIND in RFC 3315 (DHCPv6) Karl Auer
Re: question re REBIND in RFC 3315 (DHCPv6) Bernie Volz (volz)