The question that started all this was whether a REBIND can ever be used
by a server to extend the lease on an address it didn't allocate. Short
answer is "no". The longer answer is "no, unless there is some kind of
sharing of IAs happening, which is not specified in RFC3315".
The s
On Thu, 2013-06-27 at 22:45 -0700, Mark ZZZ Smith wrote:
> I think a client is allowed to continue to use an address if the
> address's valid lifetime is non-zero, regardless of how that address
> was acquired, be it stateful DHCPv6, SLAAC or static.
That's debatable according to Microsoft. Send a
- Original Message -
> From: Karl Auer
> To: IETF IPv6
> Cc:
> Sent: Friday, 28 June 2013 10:32 AM
> Subject: Re: question re REBIND in RFC 3315 (DHCPv6)
>
> On Thu, 2013-06-27 at 17:13 -0700, Mark ZZZ Smith wrote:
>> Perhaps a DHCPv6 server could have
On Thu, 2013-06-27 at 17:13 -0700, Mark ZZZ Smith wrote:
> 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.
It needs to know about them at least in so far as th
- Original Message -
> From: Karl Auer
> To: IETF IPv6
> 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 R
On Jun 27, 2013, at 10:09 AM 6/27/13, Karl Auer wrote:
> 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 no
On Thu, 2013-06-27 at 11:26 +, Bernie Volz (volz) wrote:
> I've been trying to get the DHC WG to address this issue but there
> appears to be zero interest in doing anything about it -
> see http://www.ietf.org/mail-archive/web/dhcwg/current/msg14315.html.
I'm interested. Dunno what practical
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
I've been trying to get the DHC WG to address this issue but there appears to
be zero interest in doing anything about it - see
http://www.ietf.org/mail-archive/web/dhcwg/current/msg14315.html.
- Bernie (from iPad)
On Jun 27, 2013, at 7:18 AM, "Ralph Droms"
mailto:rdroms.i...@gmail.com>> wrote
On Jun 26, 2013, at 7:40 PM 6/26/13, Karl Auer wrote:
> This sorta also relates to the ongoing efforts to redo DHCP failover for
> v6. See:
>
>
> http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-requirements-05
>
> I get the feeling I've missed something obvious.
>
> The description
This sorta also relates to the ongoing efforts to redo DHCP failover for
v6. See:
http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-requirements-05
I get the feeling I've missed something obvious.
The description of how a server should respond to REBIND (RFC 3315
18.2.4) covers these th
11 matches
Mail list logo