draft-ietf-dhc-dhcpv6-failover-protocol-05.txt   draft-ietf-dhc-dhcpv6-failover-protocol-06.txt 
Dynamic Host Configuration (DHC) T. Mrugalski Dynamic Host Configuration (DHC) T. Mrugalski
Internet-Draft ISC Internet-Draft ISC
Intended status: Standards Track K. Kinnear Intended status: Standards Track K. Kinnear
Expires: August 6, 2017 Cisco Expires: August 31, 2017 Cisco
February 2, 2017 February 27, 2017
DHCPv6 Failover Protocol DHCPv6 Failover Protocol
draft-ietf-dhc-dhcpv6-failover-protocol-05 draft-ietf-dhc-dhcpv6-failover-protocol-06
Abstract Abstract
DHCPv6 as defined in "Dynamic Host Configuration Protocol for IPv6 DHCPv6 as defined in "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)" (RFC3315) does not offer server redundancy. This document (DHCPv6)" (RFC3315) does not offer server redundancy. This document
defines a protocol implementation to provide DHCPv6 failover, a defines a protocol implementation to provide DHCPv6 failover, a
mechanism for running two servers with the capability for either mechanism for running two servers with the capability for either
server to take over clients' leases in case of server failure or server to take over clients' leases in case of server failure or
network partition. It meets the requirements for DHCPv6 failover network partition. It meets the requirements for DHCPv6 failover
detailed in "DHCPv6 Failover Requirements" (RFC7031). detailed in "DHCPv6 Failover Requirements" (RFC7031).
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 6, 2017. This Internet-Draft will expire on August 31, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 40, line 36 skipping to change at page 40, line 36
o OPTION_F_PROTOCOL_VERSION containing the protocol version that the o OPTION_F_PROTOCOL_VERSION containing the protocol version that the
primary server will use when sending failover messages. primary server will use when sending failover messages.
o OPTION_F_MCLT containing the configured MCLT. o OPTION_F_MCLT containing the configured MCLT.
o OPTION_F_KEEPALIVE_TIME containing the number of seconds (an o OPTION_F_KEEPALIVE_TIME containing the number of seconds (an
interval) within which the server must receive a message from its interval) within which the server must receive a message from its
partner, or it will assume that communications from the partner is partner, or it will assume that communications from the partner is
not ok. not ok.
o OPTION_F_UNACKED_BNDUPD containing the maximum number of BNDUPD o OPTION_F_MAX_UNACKED_BNDUPD containing the maximum number of
messages that this server is prepared to accept over the failover BNDUPD messages that this server is prepared to accept over the
connection without causing the connection to block. failover connection without causing the connection to block. This
is to implement application level flow control over the
connection, so that a flood of BNDUPD messages does not cause the
connection to block and thereby prevent other messages from being
transmitted over the connection and received by the failover
partner.
o OPTION_F_RELATIONSHIP_NAME containing name of the failover o OPTION_F_RELATIONSHIP_NAME containing name of the failover
relationship to which this connection applies. If there is no relationship to which this connection applies. If there is no
OPTION_F_RELATIONSHIP_NAME in the CONNECT message, it indicates OPTION_F_RELATIONSHIP_NAME in the CONNECT message, it indicates
that there is only a single relationship between this pair of that there is only a single relationship between this pair of
primary and secondary servers. primary and secondary servers.
o OPTION_F_CONNECT_FLAGS containing information about certain o OPTION_F_CONNECT_FLAGS containing information about certain
attributes of the connecting servers. attributes of the connecting servers.
skipping to change at page 41, line 29 skipping to change at page 41, line 32
OPTION_STATUS_CODE to reject the CONNECT message. OPTION_STATUS_CODE to reject the CONNECT message.
o OPTION_F_MCLT - Use this MCLT supplied by the primary server. o OPTION_F_MCLT - Use this MCLT supplied by the primary server.
Remember this MCLT and use it until a different MCLT is supplied Remember this MCLT and use it until a different MCLT is supplied
by some subsequent CONNECT message. by some subsequent CONNECT message.
o OPTION_F_KEEPALIVE_TIME - Remember the keepalive-time as the o OPTION_F_KEEPALIVE_TIME - Remember the keepalive-time as the
FO_KEEPALIVE_TIME when implementing the Unreachability Detection FO_KEEPALIVE_TIME when implementing the Unreachability Detection
algorithm described in Section 6.6. algorithm described in Section 6.6.
o OPTION_F_UNACKED_BNDUPD - Ensure that the maximum amount of o OPTION_F_MAX_UNACKED_BNDUPD - Ensure that the maximum amount of
unacked BNDUPD messages queued to the primary server never exceeds unacked BNDUPD messages queued to the primary server never exceeds
the value in the OPTION_F_UNACKED_BNDUPD option. the value in the OPTION_F_MAX_UNACKED_BNDUPD option.
o OPTION_F_CONNECT_FLAGS - Ensure that the secondary can process o OPTION_F_CONNECT_FLAGS - Ensure that the secondary can process
information from the primary as specified in the flags. For information from the primary as specified in the flags. For
example, if the secondary server cannot process prefix delegation example, if the secondary server cannot process prefix delegation
with variable sized prefixes delegated from the same delegable with variable sized prefixes delegated from the same delegable
prefix, and the primary server says that it can, the secondary prefix, and the primary server says that it can, the secondary
should reject the connection. should reject the connection.
A CONNECT message SHOULD always be followed by a CONNECTREPLY A CONNECT message SHOULD always be followed by a CONNECTREPLY
message, either to accept the connection or to reject the connection message, either to accept the connection or to reject the connection
skipping to change at page 42, line 14 skipping to change at page 42, line 14
o OPTION_F_MCLT containing the MCLT currently in use on the o OPTION_F_MCLT containing the MCLT currently in use on the
secondary server. This MUST equal the MCLT that was in the secondary server. This MUST equal the MCLT that was in the
OPTION_F_MCLT option in the CONNECT. OPTION_F_MCLT option in the CONNECT.
o OPTION_F_KEEPALIVE_TIME containing the number of seconds (an o OPTION_F_KEEPALIVE_TIME containing the number of seconds (an
interval) within which the server must receive a message from its interval) within which the server must receive a message from its
partner, or it will assume that communications from the partner is partner, or it will assume that communications from the partner is
not ok. not ok.
o OPTION_F_UNACKED_BNDUPD containing the maximum number of BNDUPD o OPTION_F_MAX_UNACKED_BNDUPD containing the maximum number of
messages that this server is prepared to accept over the failover BNDUPD messages that this server is prepared to accept over the
connection without causing the connection to block. failover connection without causing the connection to block. This
is to implement application level flow control over the
connection, so that a flood of BNDUPD messages does not cause the
connection to block and thereby prevent other messages from being
transmitted over the connection and received by the failover
partner.
o OPTION_F_CONNECT_FLAGS - Place information into this option to o OPTION_F_CONNECT_FLAGS - Place information into this option to
describe the attributes of the secondary server that the primary describe the attributes of the secondary server that the primary
needs to know about. needs to know about.
After sending a CONNECTREPLY message to accept the primary server's After sending a CONNECTREPLY message to accept the primary server's
CONNECT message, the secondary server MUST send a STATE message (see CONNECT message, the secondary server MUST send a STATE message (see
Section 6.3). Section 6.3).
6.1.3. Receiving a CONNECTREPLY message 6.1.3. Receiving a CONNECTREPLY message
skipping to change at page 43, line 5 skipping to change at page 43, line 9
implementations involved in the failover relationship. implementations involved in the failover relationship.
o OPTION_F_MCLT - Compare the MCLT received with the configured o OPTION_F_MCLT - Compare the MCLT received with the configured
MCLT, and if they are different send a DISCONNECT message and drop MCLT, and if they are different send a DISCONNECT message and drop
the connection. the connection.
o OPTION_F_KEEPALIVE_TIME - Remember the keepalive-time as the o OPTION_F_KEEPALIVE_TIME - Remember the keepalive-time as the
FO_KEEPALIVE_TIME when implementing the Unreachability Detection FO_KEEPALIVE_TIME when implementing the Unreachability Detection
algorithm described in Section 6.6. algorithm described in Section 6.6.
o OPTION_F_UNACKED_BNDUPD - Ensure that the maximum amount of o OPTION_F_MAX_UNACKED_BNDUPD - Ensure that the maximum amount of
unacked BNDUPD messages queued to the secondary server never unacked BNDUPD messages queued to the secondary server never
exceeds the value in the OPTION_F_UNACKED_BNDUPD option. exceeds the value in the OPTION_F_MAX_UNACKED_BNDUPD option.
o OPTION_F_CONNECT_FLAGS - Ensure that the primary can process o OPTION_F_CONNECT_FLAGS - Ensure that the primary can process
information from the secondary as specified in the flags. For information from the secondary as specified in the flags. For
example, if the primary server cannot process prefix delegation example, if the primary server cannot process prefix delegation
with variable sized prefixes delegated from the same delegable with variable sized prefixes delegated from the same delegable
prefix, and the secondary server says that it can, the primary prefix, and the secondary server says that it can, the primary
should drop the connection. should drop the connection.
After receiving a CONNECTREPLY message that accepted the primary After receiving a CONNECTREPLY message that accepted the primary
server's CONNECT message, the primary server MUST send a STATE server's CONNECT message, the primary server MUST send a STATE
skipping to change at page 89, line 13 skipping to change at page 89, line 13
resources can compromise the ability of legitimate partners to resources can compromise the ability of legitimate partners to
receive service. Malicious requestors who succeed in establishing receive service. Malicious requestors who succeed in establishing
connections but who then send invalid messages, partial messages, or connections but who then send invalid messages, partial messages, or
no messages at all can also exhaust a server's pool of available no messages at all can also exhaust a server's pool of available
connections. connections.
DHCPv6 failover can operate in secure or insecure mode. Secure mode DHCPv6 failover can operate in secure or insecure mode. Secure mode
(using TLS) would be indicated when the TCP connection between (using TLS) would be indicated when the TCP connection between
failover partners is open to external monitoring or interception. failover partners is open to external monitoring or interception.
Insecure mode should only be used when the TCP connection between Insecure mode should only be used when the TCP connection between
failover partners remains within set of protected systems. Details failover partners remains within a set of protected systems. Details
of such protections are beyond the scope of this document. Failover of such protections are beyond the scope of this document. Failover
servers MUST use the approach documented in Section 9.1 of [RFC7653] servers MUST use the approach documented in Section 9.1 of [RFC7653]
to decide to use or not to use TLS when connecting with the failover to decide to use or not to use TLS when connecting with the failover
partner. partner.
The threats created by using failover directly mirror those from The threats created by using failover directly mirror those from
using DHCPv6 itself: information leakage through monitoring, and using DHCPv6 itself: information leakage through monitoring, and
disruption of address assignment and configuration. Monitoring the disruption of address assignment and configuration. Monitoring the
failover TCP connection provides no additional data beyond that failover TCP connection provides no additional data beyond that
available from monitoring the interactions between DHCPv6 clients and available from monitoring the interactions between DHCPv6 clients and
 End of changes. 10 change blocks. 
15 lines changed or deleted 25 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/