Network Working Group Srinivasa Rao Nalluri Internet Draft Lakshmisha G Intended status: Standards Track Amit Gupta Expires: April 30, 2016 Ericsson October 10, 2015 Status monitoring extensions to DHCP draft-snalluri-dhcp-status-monitoring-00 Abstract This draft introduces bidirectional framework and protocol to monitor reachability and status of IP clients in subnet. This draft is based on Dynamic Host Configuration Protocol and MAY be considered as an extension of RFC 2131. Status of This Memo Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 30, 2016. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Table of Contents 1. Terminology 2. Introduction and motivations 3. Reference Network topology 4. Protocol summary 4.1. Capability negotiation 4.1.2. DHCP client's monitor capability option 4.1.3. DHCP server's monitor capability option 4.2. DHCP client's monitor function 4.3. DHCP server's or relay agent's monitor function 5. Administrative objects and default values 5.1. Client monitor request interval 5.2. Client monitor threshold 5.3. Server monitor threshold 6. Message definitions 6.1. DHCP client monitor request 6.2. DHCP client monitor response 7. Constructing and sending DHCP client monitor request 8. Constructing and sending DHCP client monitor response 9. Processing DHCP client monitor request 10. Processing DHCP client monitor response 11. IPv6 considerations 12. Backward compatibility 13. Acknowledgements 14. References 14.1. Informative References 14.2. Normative References 1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD","SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [1]. - DHCP client's monitor function A function that is active on DHCP client device to monitor reachability of DHCP server or DHCP relay agent that is active on intermediate Layer3 node. In specific scenarios considered in this draft, intermediate node MAY be Access device or Edge router. - DHCP server's monitor function - A function that is active on DHCP server to monitor reachability of all its DHCP clients. DHCP server's monitor function is active only for clients which are in DHCP server's broadcast domain. - DHCP relay agent's monitor function A function that is active on DHCP relay agent to monitor DHCP clients which are in different broadcast domain from DHCP server. In specific scenarios discussed in this draft, DHCP relay agent's monitor function MAY be active on Layer3 access device or on edge router. 2. Introduction and motivations In IP networks, DHCP is the protocol used to assign IP address dynamically. Though DHCP assigns network layer address on need basis, it cannot dynamically track the client's status and reachability. Once the address is assigned, it is assumed that client is reachable and active. Resources assigned to client are not released until service lease time expires or until client initiate DHCP RELEASE message. The resources might include IP address, FIB entries, bandwidth, and allocated internal buffers. In congested networks it is possible that DHCP release MAY not reach DHCP server. DHCP client MAY leave network without sending DHCP RELEASE message. In service provider IP networks it is important to optimize resource utilization based on actual status of DHCP client. To achieve resource overbooking and reduce capital investments it is required to release network resources dynamically even when IP clients leaves network silently. Accounting is another area where dynamic client status monitoring is required. There are services where time based accounting is required rather than volume based. In such scenarios it is important to have client status tracking close to accuracy. The problem becomes severe as industry is moving towards Internet of Things and new generation of mobile technologies which are boosting growth of number of IP devices and their dynamic nature. There are several ways by which service providers are trying to solve this issue. - Periodic Layer2 address resolution to determine client status. - Periodic Layer3 reachability test. - Subscriber resources clean up based on subscriber idle time. None of these approaches are clean and standardized. These approaches are unidirectional and do not provide ability to client to initiate negotiation upon detecting an IP connectivity failure. Client's renegotiation capability is particularly important in broadband scenarios to increase service availability. 3. Reference Network topology IP client Monitoring function SHOULD be combined with - DHCP server function if DHCP client exists in same broadcast domain as DHCP server. - DHCP relay agent If client and server are in different broadcast domain. Following network topologies are specific to broadband access scenarios but SHOULD be used as reference network topologies. +----------+ |IP client |-------------| +----------+ | | +------+ +------+ +----------+ | | | | | |IP client |-------------| | | | | +----------+ | | | | BRAS/| : | | L2 | | EDGE | : | |ACCESS| |ROUTER| : |------------| NODE |------------| + | : | | | | DHCP | : | | | |SERVER| +----------+ | | | | | |IP client |-------------| +------+ +------+ +----------+ | | +----------+ | |IP client |-------------| +----------+ <-------------------- Monitor function -------------------> Figure 1. Broadband network design with DHCP server and client in same broadcast domain. +----------+ |IP client |-------------| +----------+ | | +------+ +------+ +----------+ | | | | | |IP client |-------------| | L3 | | | +----------+ | |ACCESS| | BRAS/| : | | NODE | | EDGE | : | | + | |ROUTER| : |------------| DHCP |------------| + | : | | RELAY| | DHCP | : | | AGENT| |SERVER| +----------+ | | | | | |IP client |-------------| +------+ +------+ +----------+ | | +----------+ | |IP client |-------------| +----------+ <--------- Monitor function ---------> Figure 2. Broadband network design with DHCP server and client in different broadcast domain +----------+ |IP client |--------| +----------+ | | +------+ +------+ +----------+ | | | | | |IP client |--------| | | | | +------+ +----------+ | | | | BRAS/| | | : | | L2 | | EDGE | | DHCP | : | |ACCESS| |ROUTER| |SERVER| : |---------| NODE |---------| + |----| | : | | | | DHCP | | | : | | | |RELAY | +------+ +----------+ | | | |AGENT | |IP client |--------| +------+ +------+ +----------+ | | +----------+ | |IP client |--------| +----------+ <-------------- Monitor function --------------> Figure 3. Broadband network design with L2 access device, where DHCP server and client are in different broadcast domain 4.Protocol summary Note that defaults for timer values are described later in this document. Timer and counter names appear in square brackets. 4.1. Capability negotiation DHCP server's monitor function and DHCP client's monitor function detects monitoring capability of peer through DHCP options exchanged during DHCP discovery phase. DHCP client sends DISCOVER and REQUEST messages with new option to indicate client is capable of responding to monitor request received from server. DHCP server or relay agent responds to monitor capable clients with DHCP OFFER that carries an option indicating server's capability to broadcast periodic monitoring messages in broadcast domain. 4.1.2. DHCP client's monitor capability option A zero length option with code 214 in DHCP DISCOVER and REQUEST messages indicates DHCP client's capability to responds to periodic monitoring messages received from DHCP Server or DHCP relay agent. Code Len +-----+-----+ | 214 | 0 | +-----+-----+ 4.1.3. DHCP server's monitor capability option A new option with code 215 and length 2 in DHCP OFFER and DHCP ACK messages indicates router's monitoring function's capability to generate periodic broadcast monitor messages in subnet. code Len Interval +-----+-----+-----+-----+ | 215 | 2 | | +-----+-----+-----+-----+ Interval is the time taken in seconds by DHCP server's or relay agent's monitor function between generating two periodic broadcast client monitor messages 4.2. DHCP client's monitor function Once DHCP discovery phase completed between DHCP client and server, DHCP client expects periodic [DHCP client monitor request] messages from server at intervals advertised by server in Option 215. DHCP client responds with [DHCP client monitor response] message only if DHCP server from which the [DHCP client monitor request] is received is same as the DHCP server from which its own IP address is assigned. DHCP client uses DHCP client monitor request to monitor reachability of DHCP server or DHCP relay agent. DHCP client considers DHCP server or DHCP relay agent is unreachable if [DHCP client monitor request] message is not received for given number of intervals. If DHCP server or relay agent is considered as unreachable, DHCP client MAY clean existing configuration and initiate new DHCP DISCOVER to obtain configuration from any other reachable DHCP server. 4.3. DHCP server's or relay agent's monitor function Existence of DHCP Server's or DHCP relay agent's function in network depends on topology. Once DHCP DISCOVER phase is completed and at least one DHCP client is assigned with IP address, DHCP server's or relay agent's monitor function starts broadcasting [DHCP client monitor request] in subnet. DHCP server's or relay agent's monitor function expects response for each [DHCP client monitor request] message from each of its clients. DHCP server's or relay agent's monitor function considers client is not reachable if DHCP client monitor response is not received for a sequence of DHCP client monitor request. If DHCP server's monitor function detects an unreachable client, it releases all resources allocated for unreachable client. If DHCP relay agent's monitor function detects an un-reachable client, it releases all local resources and informs DHCP server to release resources by sending DHCP RELEASE message. 5. Administrative objects and default values 5.1. Client monitor request interval The [client monitor request interval] is the interval between [DHCP client monitor request] messages sent by DHCP server's or relay agent's monitor function. This is administratively configurable on DHCP server's or relay agent's monitor function. Default: 120 seconds. Value of [client monitor request interval] is advertised by DHCP server or relay agent during session discovery phase through DHCP server's monitor capability option. DHCP client's monitor function uses [client monitor request interval] value advertised by server or relay agent to monitor server or relay agent reachability. By varying the value of [client monitor request interval], an administrator may tune the number of DHCP messages on the subnet. Larger values cause [client monitor request] to be sent less often. An administrator may also tune the burstiness of [DHCP client monitor response] messages on the subnet; larger values make the [DHCP client monitor response] messages less bursty, as DHCP client's monitor functions can send responses spread out over a larger interval. 5.2. Client monitor threshold [Client monitor threshold] is the number of [client monitor requests] sent by DHCP server's or relay agent's monitor function without receiving response from a DHCP client, before deciding DHCP client as unreachable Administratively configurable on DHCP server's or relay agent's monitor function, Default: 3 By varying the Client monitor threshold, an administrator may adjust monitor functions to network conditions. Larger value allows DHCP client and server to avoid resource release due to bad network conditions. 5.3. Server monitor threshold [Server monitor threshold] is the number of [Client monitor request intervals] that client monitor function wait without receiving [DHCP client monitor request]. Once [Server monitor threshold] is reached client monitor function decides server or relay agent as unreachable. Administratively configurable on DHCP client's monitor function, Default: 3 To avoid frequent session re-negotiations from DHCP client, Server monitor threshold of client's monitor function MUST be in line with Server monitor threshold of server's or relay agent's monitor function. 6. Message definitions 6.1. DHCP client monitor request A client monitor request is a bootp broadcast message sent from a DHCP server/relay agent to a DHCP client, to detect the client's reachability 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | op (1) | Reserved(3) | +---------------+---------------+---------------+---------------+ | Server or Relay agent Ip Addres (4) | +-------------------------------+-------------------------------+ FIELD OCTETS DESCRIPTION ----- ------ ----------- Op 1 Message op code / message type. 3 = MONITORREQUEST Reserved 3 Reserved and MUST be filled with zero. Server or Relay agent 4 DHCP server/relay agent's IP address IP address 6.2. DHCP client monitor response [DHCP client monitor response] message is a BOOTP unicast message sent from a DHCP client to dhcp server/relay agent in response to the client monitor request to indicate its reachability to server. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | op (1) | htype (1)| hlen (1) | Reserved (1) | +---------------+---------------+---------------+---------------+ | Ciaddr (4) | +---------------------------------------------------------------+ | | | chaddr (16) | | | | | +---------------------------------------------------------------+ FIELD OCTETS DESCRIPTION ----- ------ ----------- Op 1 Message op code / message type. 4 = MONITORRESPONSE htype 1 Hardware address type, see ARP section in "Assigned Numbers" RFC; e.g., '1' = 10mb ethernet. hlen 1 Hardware address length (e.g. '6' for 10mb ethernet). Reserved 1 Reserved and MUST be filled with zero. Ciaddr 4 Client Ip Address chaddr 16 Client hardware address The 'htype', 'hlen', and 'chaddr' fields supply the link-layer hardware type, hardware address length, and hardware address of the client as defined in the ARP protocol [2] and the Assigned Numbers document [3]. 7. Constructing and sending DHCP client monitor request [DHCP client monitor request] is always sent by DHCP server's or relay agent's monitor function at [Client monitor request interval] on 'DHCP client' udp port(68). DHCP client monitor request is a broadcast message that will be reached all layer2 devices in broadcast domain. Server or relay agent broadcasts DHCP client monitor request to IP header destination address 0xffffffff and must have the source address field in the IP header set to - DHCP server IP address if message is generated by DHCP server. - DHCP relay agent IP address if message is generated by DHCP relay agent. Server's or relay agent's monitor function MUST set - 'op' as MONITORREQUEST(3) - 'reserved' as zero - 'Server or relay agent IP address' as local IP address of server or relay agent. 8. Constructing and sending DHCP client monitor response [DHCP client monitor response] is always sent by DHCP client's monitor function as response to [DHCP client monitor request] on 'DHCP server' udp port(67). [DHCP client monitor response] is unicast message that will be reached to DHCP server or relay agent from which DHCP client received IP address DHCP client sends [DHCP client monitor response] to IP header destination address that is same as DHCP server IP address received in 'server identifier' option during DHCP discovery phase. Source IP address field in the IP header MUST be set to client's IP address DHCP client SHOULD respond to [DHCP client monitor request] messages only if received 'Server or Relay agent Ip Address' is same as Server IP address mentioned in server identifier option that was received during DHCP discovery phase. DHCP client should silently ignore all other [DHCP client monitor request] messages Client's monitor function MUST set - 'op' as MONITORRESPONSE(4) - 'reserved' as zero - 'htype' as defined in assigned numbers RFC - 'hlen' as defined in assigned numbers RFC - 'ciaddr' as IP address of client's monitor function. - 'chaddr' as client's hardware address. To reduce the burstiness of[DHCP client monitor response] messages DHCP client SHOULD delay response to [DHCP client monitor request]. Delay time SHOULD be set to a random value selected from the range 0 and half of [Client monitor request interval] 9. Processing DHCP client monitor request Reception of [DHCP client monitor request] indicate that DHCP server or relay agent is still active. In deployment scenario this indicate the active status of default gateway. Source IP address of IP header in received [DHCP client monitor request] SHOULD NOT be trusted as a sole key in identifying DHCP server or relay agent. 'Server or relay agent Ip address' received in [DHCP client monitor request] SHOULD be considered in validating [DHCP client monitor request]. DHCP client responds with [DHCP client monitor response] If the 'Server or relay agent Ip address' in received [DHCP client monitor request] is same as server IP address received in server identifier option during DHCP DISCOVERY phase. DHCP client waits for [Server monitor threshold] iterations without receiving [DHCP client monitor request] before deciding unreachability of DHCP server or relay agent. 10. Processing DHCP client monitor response Reception of [DHCP client monitor response] indicate that DHCP server or relay agent is still reachable from DHCP client and also indicates active status of DHCP client. 'ciaddr' field in received [DHCP client monitor response] SHOULD NOT be trusted as a sole key in identifying a client; the contents of the 'ciaddr', 'chaddr', 'htype', and 'hlen' fields SHOULD all be considered together in validating [DHCP client monitor response] DHCP server or relay agent waits for [Client monitor threshold] iterations without receiving [DHCP client monitor response] before deciding unreachability of DHCP client. 11. IPv6 considerations 12. Backward compatibility - DHCP client compatibility with legacy DHCP server or relay agent: DHCP client should fallback to legacy behavior If DHCP client is monitor capable but not the server or relay agent. DHCP server that is not capable of monitoring ignores option 214 in received DHCPDISCOVER messages and responds with DHCPOFFER without adding option 215. If monitor capable DHCP client receives DHCPOFFER without option 215, client MAY accept the DHCPOFFER and send DHCPREQUEST without option 214 or, client can ignore DHCPOFFER and wait for DHCPOFFER with option 215 from another monitor capable DHCP server. [DHCP client monitor response] received by legacy DHCP server SHOULD be silently ignored. - DHCP server or relay agent compatibility with legacy DHCP client: Monitor capable DHCP server responds with option 215 included DHCPOFFER only for those DHCPDISCOVER messages which include option 214. For all other DHCPDISCOVER messages, server responds with DHCPOFFER without option 215. DHCP server's monitor function should monitor only those clients for which monitor capability is exchanged during DHCP discovery phase. Legacy DHCP clients ignores all [DHCP client monitor request] messages from known or unknown servers. 13. Acknowledgements This document is based on concepts and broadband service provider network deployment modes described in several forums, including IETF and Broadband forum. 14. References 14.1. Informative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 14.2. Normative References [2] Plummer, D., "An Ethernet Address Resolution Protocol", STD 37, RFC 826, MIT, November 1982. [3] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340, USC/Information Sciences Institute, July, 1992. This RFC is periodically reissued with a new number. Please be sure to consult the latest version. [4] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [5] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997 [6] Wimer, W., "Clarifications and Extensions for the Bootstrap Protocol", RFC 1542, Carnegie Mellon University, October 1993 Author's Addresses Srinivasa Rao Nalluri Ericsson Level-5 Ferns Icon, Outer Ring Road, Doddanakundi Marathahalli, Bangalore India-560037 Email: srinivasa.rao.nalluri@ericsson.com Lakshmisha G Ericsson Level-5 Ferns Icon, Outer Ring Road, Doddanakundi Marathahalli, Bangalore India-560037 Email: lakshmisha.g@ericsson.com Amit Gupta Ericsson Level-5 Ferns Icon, Outer Ring Road, Doddanakundi Marathahalli, Bangalore India-560037 Email: amit.x.gupta@ericsson.com