As part of improving our course materials, I was refreshing my understanding of DHCPv6 a couple of days ago, and found myself thinking about the REBIND message. After close consideration of the relevant RFC (RFC 3315), and even posting a question about it to the IETF mailing list, I came to the conclusion that REBIND, as it now stands, is a pretty pointless message.
Check out section 18.2.4 of the RFC, which details how a server should respond to a REBIND message. 18.2.4 covers 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
Conspicuously absent is the situation where the server does not find the IA, but the addresses are OK. Yet this situation is exactly the situation that REBIND is supposed to address – the situation where the client has already tried to RENEW its addresses, would like to extend the leases, but the server which originally allocated the addresses is no longer contactable.
Looking to DHCPv4 for a hint, the description of rebinding in RFC 2131, section 4.3.2, as:
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 there seems to be no “mechanism for maintaining consistency among leases managed by multiple servers”, and there is no mention in RFC 3315 of any additional behaviour involving “local administrative authority”.
In DHCPv4, there is a “mechanism for maintaining consistency among leases managed by multiple servers” – it is the failover protocol, which although widely implemented has never made it out of draft status – see draft-ietf-dhc-failover.
Moves are afoot to standardise a failover protocol for DHCPv6 too – see the draft efforts at http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-requirements. This would provide the mechanism whereby servers other than the original allocating servers would have IAs for addresses, so that they could extend leases for rebinding clients.
There has been some discussion of the idea that DHCPv6 servers should be able to respond to REBIND even without such a mechanism. See, for example, http://www.ietf.org/mail-archive/web/dhcwg/current/msg14315.html.
At the moment, though, REBIND is indeed pretty pointless in DHCPv6. It does lessen the wait before a host that is using a dud address finds out about it – other servers can respond to a REBIND if they know the address should not be used. In that case the host can start again with a SOLICIT without having to wait out the whole lease period. But REBIND will only be really useful when servers can share information about IAs.