dhc Working Group S. Gandhewar
Internet-Draft Juniper Networks, Inc.
Intended status: Standards Track June 28, 2015
Expires: December 30, 2015
DHCP Relay Initiated Release
draft-gandhewar-dhc-relay-initiated-release-00
Abstract
The Dynamic Host Configuration Protocol (DHCP) is initiated by a DHCP
client. A DHCP server can force DHCP client to send DHCPRENEW by
sending a DHCPFORCERENEW message. There may be multiple DHCP network
devices connected in between a DHCP client and a server, each one
reserving resources for the DHCP client. There are no DHCP messages
that a relay can initiate in order to control the client binding.
A DHCP client may not always send a DHCPRELEASE message when it no
longer needs the IP address. This document specifies a way to
request release message to be initiated by an intermediate DHCP
network device, e.g. DHCP relay, on behalf of DHCP client. This
helps relinquish network resources sooner than the lease expiration
time.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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 December 30, 2015.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
Gandhewar Expires December 30, 2015 [Page 1]
Internet-Draft DHCP Relay Initiated Release June 2015
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. New Message and Option Value Definitions . . . . . . . . . . 4
3.1. DHCPRELEASEBYRELAY . . . . . . . . . . . . . . . . . . . 4
3.2. DHCPRELAYREPLY . . . . . . . . . . . . . . . . . . . . . 4
3.3. NoBinding . . . . . . . . . . . . . . . . . . . . . . . . 4
3.4. NotConfigured . . . . . . . . . . . . . . . . . . . . . . 4
4. Functionality . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. First DHCP Network Device Behavior . . . . . . . . . . . 5
4.1.1. Generation and Transmission of DHCPRELEASEBYRELAY
Message . . . . . . . . . . . . . . . . . . . . . . . 5
4.1.2. Receipt of DHCPRELAYREPLY Message . . . . . . . . . . 6
4.1.3. Receiving No Response . . . . . . . . . . . . . . . . 7
4.2. DHCP Server Behavior . . . . . . . . . . . . . . . . . . 7
4.2.1. Receipt of DHCPRELEASEBYRELAY Message . . . . . . . . 7
4.2.2. Generation and Transmission of DHCPRELAYREPLY Message 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
DHCP [RFC2131] provides a framework for configuring clients with
network addresses and other network parameters. It includes a relay
agent capability where DHCP server may not be directly connected to
the DHCP client. A relay agent is an intermediate node that passes
DHCP messages between DHCP clients and DHCP servers. As per
[RFC2131], a relay agent cannot generate a message on its own which
can control the client binding. Figure 1 below shows a typical
network with multiple DHCP devices.
Gandhewar Expires December 30, 2015 [Page 2]
Internet-Draft DHCP Relay Initiated Release June 2015
+---------+ +---------+ +---------+ +---------+
| DHCP |-----| DHCP |--...--| DHCP |-----| DHCP |
| Server | | Relay n | | Relay 1 | | Client |
+---------+ +---------+ +---------+ +---------+
Figure 1: Typical DHCP Network
A DHCP client may be connected to DHCP server through multiple DHCP
network devices, e.g. multiple DHCP relay and/or relay-proxy. In the
DHCP protocol it is not mandatory for the DHCP client to send a
DHCPRELEASE message while disconnecting. It is also possible that
the UDP datagram carrying a DHCPRELEASE message may get dropped due
to network issues. Network resources, including IP address, may
remain reserved for this client at all the DHCP network devices until
the lease expires.
In some situations when the DHCP client is replaced (e.g. replacing
the set-top-box) due to failure, the first DHCP client may not have
sent the DHCPRELEASE message on its failure. In this case, the IP
address and network resources for the first client will be reserved
and unused until the lease expires.
It is possible for the first DHCP network device, i.e. "DHCP Relay 1"
in Figure 1 which is closest to the DHCP client, to detect that the
DHCP client is replaced or is no longer present on the network by
health check. This health check may be done by some kind of liveness
detection mechanism or some other mechanism. In this scenario, the
relay agent doesn't have any mechanism to inform the server about
such liveness state.
In some situations, the administrator might want to clear some
clients' bindings administratively. In such cases, the administrator
may need to access every single DHCP network device (relay, relay-
proxy) and also the DHCP server, and clear the DHCP client binding.
With the relay initiated release message, when a relay detects
client's unavailability or needs to clear the client binding
administratively, it can generate the release message on behalf of
client and send it to the server. Thus, all of the DHCP network
devices can be in synchronization with respect to the client's
binding information and network resources can be relinquished earlier
than the lease expiry. The server MAY choose to integrate some
mechanism to confirm with the client, e.g. generate FORCERENEW
message before sending reply to the relay. It is outside the scope
of this document.
Gandhewar Expires December 30, 2015 [Page 3]
Internet-Draft DHCP Relay Initiated Release June 2015
2. Requirements Language
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].
3. New Message and Option Value Definitions
This document specifies 2 new DHCP message types (option 53 from
Section 9.6 of [RFC2132]):
o DHCPRELEASEBYRELAY
o DHCPRELAYREPLY
The format of these messages is same as defined in [RFC2131].
This document specifies 2 new values for the Status Code Option
(option 151 from Section 6.2.2 of [RFC6926]):
o NoBinding
o NotConfigured
3.1. DHCPRELEASEBYRELAY
This message MAY be generated by the first DHCP network device ("DHCP
Relay 1" in Figure 1), on behalf of the DHCP client. This gives an
indication to the server that the client binding can be cleared.
3.2. DHCPRELAYREPLY
This is the reply from DHCP server in response to the
DHCPRELEASEBYRELAY message. The server conveys success or failure of
the DHCPRELEASEBYRELAY.
3.3. NoBinding
When the server does not find the binding for which
DHCPRELEASEBYRELAY is received, it uses this new value in the Status
Code Option.
3.4. NotConfigured
When the server is not configured to accept DHCPRELEASEBYRELAY, it
uses this new value in the Status Code Option.
Gandhewar Expires December 30, 2015 [Page 4]
Internet-Draft DHCP Relay Initiated Release June 2015
4. Functionality
The generation of a DHCPRELEASEBYRELAY message can be a configurable
behavior at the DHCP relay. Taking action to release the binding can
also be a configurable behavior at the server and intermediate DHCP
network devices. Depending upon the configuration, the server
responds with DHCPRELAYREPLY
4.1. First DHCP Network Device Behavior
Devices MAY be configured to generate the newly defined
DHCPRELEASEBYRELAY message.
The first DHCP network device ("DHCP Relay 1" in Figure 1) can be
configured such that when it detects the client is no longer
available on the network or is replaced or the binding information
needs to be deleted administratively, the device can generate the
DHCPRELEASEBYRELAY message.
In order to generate the DHCPRELEASEBYRELAY message this network
device needs to store the information related to the client, e.g.
hardware address, client identifier, server identifier and giaddr
used while obtaining client lease.
4.1.1. Generation and Transmission of DHCPRELEASEBYRELAY Message
This new message is similar to the DHCPRELEASE generated by the
client, as explained in [RFC2131]. The construction of the
DHCPRELEASEBYRELAY is similar to the construction of any other DHCP
messages as described in Section 4.1 of [RFC2131]. Note that this
message is generated on behalf of the DHCP client hence all the
fields in the message SHOULD be with respect to the client, as if it
was generated by the client. It MUST set the giaddr in the packet as
its network address. This is similar to setting the giaddr for other
message types like DHCPDISCOVER or DHCPREQUEST.
Relay MAY also choose to add Relay Agent Information Option 82
[RFC3046] in this message. This can be a configurable behavior.
Set the following fields in the DHCPRELEASEBYRELAY message:
o op - MUST be set to BOOTREQUEST
o xid - MUST be filled as a random number
o chaddr - MUST be filled with hardware address of the client on
whose behalf the DHCPRELEASEBYRELAY is being sent
Gandhewar Expires December 30, 2015 [Page 5]
Internet-Draft DHCP Relay Initiated Release June 2015
o ciaddr - MUST be filled with client's network address
o giaddr - MUST be filled and SHOULD be same as what was used when
client obtained the lease
Include the following options in the DHCPRELEASEBYRELAY message:
o DHCP message type - MUST be included as DHCPRELEASEBYRELAY
o Client identifier - if the client had used this option while
obtaining the lease, it MUST include this option with the same
value
o Server identifier - MUST be included and SHOULD be same as what
was used when client obtained the lease
o Relay Agent Information Option 82 - if configured then SHOULD
include this option with the same value as what was used while
obtaining the lease
DHCPRELEASEBYRELAY SHOULD be sent as unicast message to the server.
4.1.2. Receipt of DHCPRELAYREPLY Message
The first DHCP network device ("DHCP Relay 1" in Figure 1), upon
receipt of a valid DHCPRELAYREPLY message from the server, considers
the completion of DHCPRELEASEBYRELAY event.
If xid of the DHCPRELAYREPLY does not match with the xid of the
DHCPRELEASEBYRELAY which was sent, DHCPRELAYREPLY MUST be silently
dropped.
The action at this device is based on the Status Code Option. In the
absence of Status Code Option or if the value is Success or
NoBinding, then this device MUST clear the binding. If the Status
Code is not Success or NoBinding, those client bindings MUST remain
until the lease expires.
If DHCPRELAYREPLY from the DHCP server is lost then the
DHCPRELEASEBYRELAY will be retransmitted, and the server MAY respond
with a DHCPRELAYREPLY indicating a Status Code as NoBinding.
Therefore, in this message exchange, the relay SHOULD NOT treat a
DHCPRELAYREPLY message with a Status Code of NoBinding as an error.
Gandhewar Expires December 30, 2015 [Page 6]
Internet-Draft DHCP Relay Initiated Release June 2015
4.1.3. Receiving No Response
The DHCP relay does not receive a response from the server if the
DHCPRELEASEBYRELAY or DHCPRELAYREPLY message is lost. In such cases,
relay SHOULD resend the DHCPRELEASEBYRELAY message to the server
using a backoff algorithm for the retry time that approximates an
exponential backoff. Depending on the network bandwidth between the
relay and the server, the relay SHOULD choose a delay. This delay
grows exponentially as retransmissions fail. The number of
retransmissions SHOULD be limited. The exponential backoff algorithm
is specified in Section 4.1 of [RFC3046].
4.2. DHCP Server Behavior
DHCP server ("DHCP Server" in Figure 1) SHOULD be configurable either
to accept or reject the newly defined DHCPRELEASEBYRELAY message.
4.2.1. Receipt of DHCPRELEASEBYRELAY Message
If the DHCP server does not support the new message type then it can
simply drop the packet.
If the server is not configured to accept this relay initiated
DHCPRELEASEBYRELAY message then it can simply drop the packet or send
DHCPRELAYREPLY with status code as NotConfigured.
The server MAY be configured to restrict itself from accepting this
message with the same giaddr which was used while obtaining the lease
(DISCOVER-OFFER_REQUEST-ACK message exchange). If server decides not
to accept the DHCPRELEASEBYRELAY message from a particular relay, it
can simply drop the packet or send DHCPRELAYREPLY with status code as
NotAllowed.
On receipt of a valid and acceptable DHCPRELEASEBYRELAY message, if
configuration allows, it MAY decide to clear the binding as explained
in Section 4.3.4 of [RFC2131].
If the server does not find the binding for which it received the
DHCPRELEASEBYRELAY message, it SHOULD send the DHCPRELAYREPLY with
status code as Nobinding.
4.2.2. Generation and Transmission of DHCPRELAYREPLY Message
Construction of the DHCPRELAYREPLY is similar to construction of any
other DHCP messages as described in Section 4.1 of [RFC2131]. This
message is similar to DHCPACK which is generated by the server, as
explained in [RFC2131].
Gandhewar Expires December 30, 2015 [Page 7]
Internet-Draft DHCP Relay Initiated Release June 2015
Set the following fields in the DHCPRELAYREPLY message:
o op - MUST be set to BOOTREPLY
o xid - MUST be copied from DHCPRELEASEBYRELAY
o chaddr - MUST be copied from DHCPRELEASEBYRELAY
o ciaddr - MUST be filled with client's network address
o giaddr - MUST be copied from DHCPRELEASEBYRELAY
Include the following options in the DHCPRELAYREPLY message:
o DHCP message type - MUST be included as DHCPRELAYREPLY
o Client identifier - MUST be copied from DHCPRELEASEBYRELAY
o Server identifier - MUST be copied from DHCPRELEASEBYRELAY
o Relay Agent Information Option 82 - if present, MUST be copied
from DHCPRELEASEBYRELAY
DHCPRELAYREPLY MUST be sent as unicast message to the address of the
relay as recorded in DHCPRELEASEBYRELAY.
5. Security Considerations
DHCP protocol as defined in [RFC2131] provides no authentication or
security mechanisms. Potential exposure to attacks are discussed in
Section 7 of the DHCP protocol specification in [RFC2131].
Unauthorized and malicious network device MAY spoof and send the
false DHCPRELEASE message. Similarly unauthorized and malicious
network device MAY spoof and send the false DHCPRELEASEBYRELAY
message.
A defense using the authentication for DHCP messages [RFC3118] SHOULD
be deployed where the networks are not secure or not directly under
the control of the server administrator. The DHCPRELEASEBYRELAY and
DHCPRELAYREPLY messages SHOULD be authenticated using the procedures
described in [RFC3118]. However, implementation of authentication is
not a MUST to support DHCPRELEASEBYRELAY and DHCPRELAYREPLY messages.
Although DHCP network devices that send the DHCPRELEASEBYRELAY
message perform the functions of a DHCP relay, essentially they are
DHCP clients for the purposes of the DHCPRELEASEBYRELAY message.
Thus, [RFC3118] is an appropriate mechanism for DHCPRELEASEBYRELAY
message authentication.
Gandhewar Expires December 30, 2015 [Page 8]
Internet-Draft DHCP Relay Initiated Release June 2015
Since [RFC3118] discusses the normal DHCP client interaction,
consisting of a DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, and DHCPACK, it
is necessary to transpose the operations described in [RFC3118] to
the DHCPRELEASEBYRELAY domain. The operations described in [RFC3118]
for DHCPDISCOVER are performed for DHCPRELEASEBYRELAY, and the
operations described for DHCPOFFER are performed for DHCPRELAYREPLY
message.
6. IANA Considerations
We request IANA to assign following new message types from the
registry of Message Types 53 Values maintained in:
http://www.iana.org/assignments/bootp-dhcp-parameters/
o DHCPRELEASEBYRELAY
o DHCPRELAYREPLY
We request IANA to assign following new Status Code values from the
registry of Status Codes Type 151 Values maintained in:
http://www.iana.org/assignments/bootp-dhcp-parameters/
o NoBinding
o NotConfigured
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2. Informative References
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC
3046, January 2001.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001.
Gandhewar Expires December 30, 2015 [Page 9]
Internet-Draft DHCP Relay Initiated Release June 2015
[RFC6926] Kinnear, K., Stapp, M., Desetti, R., Joshi, B., Russell,
N., Kurapati, P., and B. Volz, "DHCPv4 Bulk Leasequery",
RFC 6926, April 2013.
Author's Address
Sunil M. Gandhewar
Juniper Networks, Inc.
Email: sgandhewar@juniper.net
Gandhewar Expires December 30, 2015 [Page 10]