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 three situations:
 - the IA is found and the addresses are OK
 - the IA is found and the addresses are not OK
 - the IA is NOT found and the addresses are not OK

It does NOT appear to cover the situation where the IA is not found and
the addresses *are* OK. Yet this situation is the only one where there
is any difference between RENEW and REBIND, and the only situation where
a client is likely to get to the point of sending a REBIND - i.e.,
because the server that is holding the IA for the client's addresses is
not responding to a RENEW.

I'm not sure I see the point of REBIND if no server apart from the
original one is ever going to be able to permit continued use of the
address.

Looking to DHCPv4 for a hint, the description of rebinding in RFC 2131
was:

   "The DHCPREQUEST from a REBINDING client is intended to accommodate
    sites that have multiple DHCP servers and a mechanism for
    maintaining consistency among leases managed by multiple servers.
    A DHCP server MAY extend a client's lease only if it has local
    administrative authority to do so.

In DHCPv6 (minus failover) there seems to be no "mechanism for
maintaining consistency", and there is no mention in RFC 3315 of any
additional behaviour involving "local administrative authority".

So is REBIND basically pointless in DHCPv6?

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (ka...@biplane.com.au)
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A
Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to