Skip to main content

Generalize Client UDP Port Number of DHCP Relay
draft-shen-dhc-client-port-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Naiming Shen , Enke Chen
Last updated 2016-06-20
Replaced by draft-ietf-dhc-relay-port, draft-ietf-dhc-relay-port, RFC 8357
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-shen-dhc-client-port-00
Networking Working Group                                         N. Shen
Internet-Draft                                                   E. Chen
Intended status: Standards Track                           Cisco Systems
Expires: December 22, 2016                                 June 20, 2016

            Generalize Client UDP Port Number of DHCP Relay
                     draft-shen-dhc-client-port-00

Abstract

   This document extends the DHCP and DHCPv6 protocols for the UDP
   transport from server to client and allows the port to be any valid
   number on the DHCP relay system.

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 22, 2016.

Copyright Notice

   Copyright (c) 2016 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.

Shen & Chen             Expires December 22, 2016               [Page 1]
Internet-Draft           DHCP Relay Client Port                June 2016

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Changes to DHCP and DHCPv6 Specifications . . . . . . . . . .   3
     2.1.  Changes to DHCP in RFC 2131 . . . . . . . . . . . . . . .   3
     2.2.  Changes to DHCPv6 in RFC 3315 . . . . . . . . . . . . . .   3
   3.  Compatibility . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   4
   7.  Document Change Log . . . . . . . . . . . . . . . . . . . . .   4
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .   4
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   RFC 2131 [RFC2131] and RFC 3315 [RFC3315] specify the DHCP transport
   protocol as UDP.  They also define both the server side and client
   side port numbers.  The DHCP server port is UDP number (67) and the
   client port is UDP number (68); for DHCPv6 the server port is (546)
   and the client port is (547).

   This client and server port definition is unusual in the normal
   Internet client/server protocols, as most of the protocols only have
   the server transport port number definition and leave the client port
   range to vary.  The main reason for the fixed DHCP client port number
   is due to the fact that the client may not have an IP address, so the
   client needs to listen on the well-known port for the DHCP server
   reply messages.

   Some implementations, including some open source DHCP
   implementations, do not allow this client port behavior to be changed
   by user configuration.  Some implementations allow the port number to
   be changed, but the client port is always the next number to the
   server port.

   This fixed client port number of DHCP protocol scheme creates
   problems in certain DHCP relay environments.  For instance, in a
   large scale DHCP relay implementation on a single switch node, the
   DHCP relay functionality may be distributed among multiple processes
   running under different CPUs.  All those DHCP relay processes share
   the same IP address of the switch node.  If the UDP source port has
   to be a fixed number, the transport socket operation of DHCP packets
   needs to go through a central location or process which defeats the
   purpose of distributed DHCP relay functionality.

Shen & Chen             Expires December 22, 2016               [Page 2]
Internet-Draft           DHCP Relay Client Port                June 2016

   This document proposes to relax the fixed client port requirement for
   the DHCP client or relay.  This extension requires the DHCP server or
   relay agent to remember the inbound packet's UDP port number along
   with the IP/IPv6 address and the MAC address.  The DHCP server MUST
   use the UDP port number the client or relay agent uses instead of
   blindly setting the port number to (68/546).

1.1.  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 RFC 2119 [RFC2119].

2.  Changes to DHCP and DHCPv6 Specifications

2.1.  Changes to DHCP in RFC 2131

   Section 4.1 of RFC 2131 [RFC2131] asserts that: DHCP uses UDP as its
   transport protocol.  DHCP messages from a client to a server are sent
   to the 'DHCP server' port (67), and DHCP messages from a server to a
   client are sent to the 'DHCP client' port (68).

   This specification updates the above paragraph text in the below
   paragraph.

   DHCP uses UDP as its transport protocol.  DHCP messages from a client
   to a server are sent to the 'DHCP server' port (67), and the client
   can use any UDP port available on the client system, including the
   well-known UDP port (68).  The destination UDP port of the DHCP
   message from a server to a client simply reflects back the source UDP
   port the client uses in the inbound UDP packet.

2.2.  Changes to DHCPv6 in RFC 3315

   Section 5.2 of RFC 3315 [RFC3315] asserts that: Clients listen for
   DHCP messages on UDP port 546.  Servers and relay agents listen for
   DHCP messages on UDP port 547.

   This specification updates the above paragraph text in the below
   paragraph.

   Servers and relay agents listen for DHCP messages on UDP port 547.
   Clients listen for DHCP message on the port which has the UDP socket
   opened for the server, and it can be any port on the system,
   including the well-known UDP port (546).

Shen & Chen             Expires December 22, 2016               [Page 3]
Internet-Draft           DHCP Relay Client Port                June 2016

3.  Compatibility

   With this extension of DHCP client number generalization, the server
   behavior is compatible with the client that does not have an IP
   address.  The DHCP server will reflect back the UDP well-known port
   number (68/546) the client uses when broadcasting the request.

   When the DHCP server is implemented with this extension, it will be
   compatible with the previous DHCP behavior, and the server will use
   the port of (68/546) to send back to the client.  When upgrading DHCP
   software in the network, it is recommended to upgrade the server side
   first.

   The implementation is advised to allow the configuration for
   specifying a fixed DHCP client port number.  This is for the case
   where the DHCP client is upgraded with this extension before the
   server side upgrade.

4.  IANA Considerations

   There is no IANA consideration for this draft.

5.  Security Considerations

   If the network uses firewall to block or allow DHCP packets with both
   static UDP source and destination port numbers, that may no longer
   match the packets from new DHCP client and server software.  The
   firewall rules need to be modified only to match the DHCP server side
   of UDP port number, and if necessary, IP addresses and other
   attributes.

6.  Acknowledgments

   TBD.

7.  Document Change Log

   o  Initial version of the draft is published in June 2016.

8.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

Shen & Chen             Expires December 22, 2016               [Page 4]
Internet-Draft           DHCP Relay Client Port                June 2016

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, DOI 10.17487/RFC2131, March 1997,
              <http://www.rfc-editor.org/info/rfc2131>.

   [RFC3315]  Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
              C., and M. Carney, "Dynamic Host Configuration Protocol
              for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
              2003, <http://www.rfc-editor.org/info/rfc3315>.

Authors' Addresses

   Naiming Shen
   Cisco Systems
   560 McCarthy Blvd.
   Milpitas, CA  95035
   US

   Email: naiming@cisco.com

   Enke Chen
   Cisco Systems
   560 McCarthy Blvd.
   Milpitas, CA  95035
   US

   Email: enkechen@cisco.com

Shen & Chen             Expires December 22, 2016               [Page 5]