Internet Engineering Task Force                          Richard Johnson
Internet Draft                                                Mark Stapp
Expiration: October 2004                               Theyn Palaniappan
File: draft-ietf-dhc-subscriber-id-03.txt            Cisco Systems, Inc.

      DHCP Subscriber ID Suboption for the DHCP Relay Agent Option

                            October 15, 2004

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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-

   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."

      The list of current Internet-Drafts can be accessed at

      The list of Internet-Draft Shadow Directories can be accessed at

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.


   This memo defines a new DHCP Relay Suboption for passing a printable
   character string defining named the "Subscriber ID".  Its intended
   purpose is to provide an unchanging description of a "subscriber"
   such that the underlying hardware and/or aggregation point for a
   particular DHCP client may change without having to change the
   configuration on the DHCP server itself.

Johnson, et. al.                                                [Page 1]

Internet Draft        DHCP Subscriber ID Suboption          October 2004

1.0 Introduction

   The Remote-ID sub-option of the relay agent information option (also
   called option-82) are calculated based on network resources like IP
   address of the NSAP, atm VP, atm VC. As a result, when moving a link
   to a different port, a different value is calculated. This holds true
   for every subscriber that is connected with the particular link and
   the links may connected to different service providers. In a
   situation where the connection to the customer is provided separately
   from the DHCP service, when the subscriber moves, each Service
   Provider must be informed of the change and all the Service Providers
   have to change their DHCP [2] settings for the affected customers.
   This results in delays and complications due to necessary
   synchronization of the changes between all parties involved.

   When the service delivered to the customer has not changed, every
   move involves administrative changes in Service Providers environment
   causing delay in the customer service.  Any change in the underlying
   hardware connecting to the customer site will involve reconfiguration
   of the Service Provider's DHCP server.

   From an administrative viewpoint there is a simple need to connect a
   customer's DHCP configuration with the customer administrative
   information.  Using a "subscriber-id" character string, which can
   uniquely identify the customer, would be preferable to maintaining a
   database relating the customer to their Option 82 information.
   Furthermore, any such database would need to be constantly updated
   whenever a customer moves or the hardware is changed, while the
   "subscriber-id" designating the customer will not change.

   An additional Relay Suboption for the DHCP Relay Agent option is
   being introduced, to add a configurable printable character string to
   provide this customer information.  This unique id will enable the
   Service Provider to identify a subscriber and to assign/activate
   subscriber specific actions, e.g. assignment of host IP address,
   subnet mask, DNS, trigger accounting, etc. This specific field is de-
   coupled from the NAS-IP, since the users could be able to move
   between NAS termination points. Thus when a subscriber moves from one
   NAS to another, this would not result in a configuration change on
   the side of the DHCP server of the Service Provider.

   This memo describes a new DHCP Relay suboption which would carry a
   "Subscriber ID" value.  The value is a printable character string
   giving the name of the subscriber.

Johnson, et. al.                                                [Page 2]

Internet Draft        DHCP Subscriber ID Suboption          October 2004

1.1 Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC-2119 [1].

1.2 Terminology

   VC         Virtual Channel.  Logical circuit created to ensure
              reliable communication between two network devices. A
              virtual circuit is defined by a VPI/VCI pair, and can be
              either permanent (PVC) or switched (SVC). Virtual circuits
              are used in Frame Relay and X.25. In ATM, a virtual
              circuit is called a virtual channel.

   VP         Virtual Path.  Logical grouping of virtual circuits that
              connect two sites.

   NAS        Network Access Server. Platform (or collection of
              platforms) that interfaces between the packet world (for
              example, the Internet) and the circuit world (for example,
              the PSTN).

   NSAP       Network Service Access Point. Network addresses, as
              specified by ISO. An NSAP is the point at which OSI
              network service is made available to a transport layer
              (Layer 4) entity.

   PSTN       Public Switched Telephone Network. General term referring
              to the variety of telephone networks and services in place

   NVT ASCII  Network Virtual Terminal American Standard Code for
              Information Interchange.  [6]

2.0 DHCP Relay Information Suboption Definition

   The Subscriber ID is a DHCP Relay Information Suboption.  The exact
   option code value is TBD.  The suboption takes the same form as other
   Relay Information Suboptions:

       Code   Len   Subscriber ID string
      | TBD |  n  |  v1  | v2  | v3  | ...

Johnson, et. al.                                                [Page 3]

Internet Draft        DHCP Subscriber ID Suboption          October 2004

   The option minimum length (n) is 1.

   The "Subscriber ID string", in NVT ASCII, MUST NOT be NULL terminated
   since the length is specified in the "len" field.

   This option provides the DHCP server additional information to the
   DHCP server.  The DHCP server, if it is configured to support this
   option, should use this information in addition to other options
   included in the DHCPDISCOVER packet in order to assign an IP address
   and/or other configuration parameters for the DHCP client.

   As per [3], the contents of the entire Relay Agent Option SHALL be
   included in all replies by DHCP servers understanding the Relay Agent
   Option.  There is no special additional processing for this

3.0 Security Considerations

   Message authentication in DHCP for intradomain use where the out-of-
   band exchange of a shared secret is feasible is defined in RFC 3118
   [5].  Potential exposures to attack are discussed in section 7 of the
   DHCP protocol specification in RFC 2131 [2].

   The DHCP Relay Agent option depends on a trusted relationship between
   the DHCP relay agent and the server, as described in section 5 of RFC
   3046.  While the introduction of fraudulent relay-agent options can
   be prevented by a perimeter defense that blocks these options unless
   the relay agent is trusted, a deeper defense using the authentication
   option for relay agent options [4] SHOULD be deployed as well.

4.0 IANA Considerations

   IANA has assigned a value of TBD for the DHCP Relay Information
   Suboption code described in this document.

5.0 Acknowledgments

   This document is the result of work done within Cisco Systems.
   Thanks to Mark Stapp and Theyn Palaniappan for their work on this
   option definition and the other related work for which this is
   necessary.  Thanks also to Andy Sudduth for his review comments.


   [1] Bradner, S., "Key words for use in RFCs to Indicate
       Requirement Levels", RFC 2119, BCP 14, March 1997.

Johnson, et. al.                                                [Page 4]

Internet Draft        DHCP Subscriber ID Suboption          October 2004

   [2] Droms, R. "Dynamic Host Configuration Protocol", RFC 2131,
       March 1997.

   [3] Patrick, M., "DHCP Relay Agent Information Option",
       RFC 3046, January 2001

   [4] Stapp, M. "The Authentication Suboption for the DHCP
       Relay Agent Option", draft-ietf-dhc-auth-suboption-00.txt,
       June 23, 2002

   [5] Droms, R. "Authentication for DHCP Messages", RFC 3118,
       June 2001

   [6] Postel, J., "Telnet Protocol Specification", RFC 854,
       May 1983

Author Information:

   Richard Johnson
   Theyn Palaniappan
   Cisco Systems
   170 W. Tasman Dr.
   San Jose, CA 95134

   Phone: (408) 526-4000


   Mark Stapp
   Cisco Systems
   250 Apollo Drive
   Chelmsford, MA  01824

   Phone: (978) 244-8000


Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published

Johnson, et. al.                                                [Page 5]

Internet Draft        DHCP Subscriber ID Suboption          October 2004

   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an

Johnson, et. al.                                                [Page 6]