On Jun 26, 2013, at 7:40 PM 6/26/13, Karl Auer <ka...@biplane.com.au> 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 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. 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). In multi-server deployments, a RENEW is processed only by the relevant server, while a REBIND can be processed by any server. The differentiation is specified up in sections 15.5 and 15.6: 15.6. Renew Message Clients MUST discard any received Renew messages. Servers MUST discard any received Renew message that meets any of the following conditions: - the message does not include a Server Identifier option. - the contents of the Server Identifier option does not match the server's identifier. - the message does not include a Client Identifier option. 15.7. Rebind Message Clients MUST discard any received Rebind messages. Servers MUST discard any received Rebind messages that do not include a Client Identifier option or that do include a Server Identifier option. > > 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. The idea is that some external data channel is used to replicate the IA binding from the responsible server to all the other servers. > > 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". 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. - Ralph > > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
