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
<draft-ietf-dhc-subscriber-id-03.txt>
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-
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 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",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
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
worldwide.
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
suboption.
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.
References
[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
EMail: athenmoz@cisco.com
raj@cisco.com
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
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
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
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]