Internet Engineering Task Force                          Richard Johnson
Internet Draft                                               Ralph Droms
Expiration: July 2003                                        Mark Stapp
File: draft-ietf-dhc-subscriber-id-00.txt              Theyn Palaniappan
                                                     Cisco Systems, Inc.




      DHCP Subscriber ID Suboption for the DHCP Relay Agent Option
                 <draft-ietf-dhc-subscriber-id-00.txt>

                            January 21, 2003


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

   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
      http://www.ietf.org/ietf/1id-abstracts.txt

      The list of Internet-Draft Shadow Directories can be accessed at
      http://www.ietf.org/shadow.html.

Copyright Notice

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

Abstract

   This memo defines a new DHCP Relay Suboption for passing an arbitrary
   number of bytes defining what will be called the "Subscriber ID".
   This value is simply defined as an array of bytes and can be
   interpreted in any form by the DHCP server.  Its intended purpose is
   to give additional information which the DHCP server can use in
   address allocation.



Johnson, et. al.                                                [Page 1]


Internet Draft        DHCP Subscriber ID Suboption          January 2003


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 are connected to different service providers. When the
   subscriber moves, each Service Provider has to be informed of the
   change and all the Service Providers have to change their DHCP [2]
   settings for the affected customers at the same time.

   When the service delivered has not changed, every move involves
   administrative changes in Service Providers environment causing delay
   in the customer service.

   Therefore an additional Relay Suboption for the DHCP Relay Agent
   option is being introduced, to add a configurable hexadecimal value
   to provide this 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 from 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 simply an array of bytes which
   can be interpreted by the DHCP server in whatever manner wanted.  The
   value can be a character string giving the name of the subscriber,
   four bytes interpreted as a big endian unsigned integer giving the
   number of the subscriber, a string of hex digits giving the
   subscriber ID, or whatever is needed.  The precise definition of the
   bytes is left to the implementation and field use.

1.1 Conventions

   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 [1].










Johnson, et. al.                                                [Page 2]


Internet Draft        DHCP Subscriber ID Suboption          January 2003


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


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   Subscribe ID octets
      +-----+-----+------+-----+-----+---
      | TBD |  n  |  v1  | v2  | v3  | ...
      +-----+-----+------+-----+-----+---


   The option minimum length (n) is 1.

   This option provides the DHCP server additional information upon
   which to make a determination of address to be assigned.  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 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
   suboption.




Johnson, et. al.                                                [Page 3]


Internet Draft        DHCP Subscriber ID Suboption          January 2003


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 Acknowledgements

   This document is the result of work done within Cisco Systems.
   Thanks to Ralph Droms, 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.


References

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

   [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






Johnson, et. al.                                                [Page 4]


Internet Draft        DHCP Subscriber ID Suboption          January 2003


Author Information:

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

   Phone: (408) 526-4000

   EMail: athenmoz@cisco.com
          raj@cisco.com


   Ralph Droms
   Mark Stapp
   Cisco Systems
   250 Apollo Drive
   Chelmsford, MA  01824

   Phone: (978) 244-8000

   EMail: rdroms@cisco.com
          mjs@cisco.com

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

   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
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING



Johnson, et. al.                                                [Page 5]


Internet Draft        DHCP Subscriber ID Suboption          January 2003


   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."















































Johnson, et. al.                                                [Page 6]