DHC B. Volz
Internet-Draft Cisco Systems, Inc.
Expires: October 9, 2005 April 07, 2005
DHCPv6 Relay Agent Subscriber-ID Option
draft-ietf-dhc-dhcpv6-subid-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on October 9, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This memo defines a new Relay Agent Subscriber-ID option for the
Dynamic Host Configuration Protocol for IPv6 (DHCPv6). The option
allows a DHCPv6 relay agent to associate a stable "Subscriber-ID"
with DHCPv6 client messages in a way that is independent of the
client and of the underlying physical network infrastructure.
Volz Expires October 9, 2005 [Page 1]
Internet-Draft Relay Agent Subscriber-ID April 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 3
3. The Relay Agent Subscriber-ID Option . . . . . . . . . . . . . 3
4. DHCPv6 Relay Agent Behavior . . . . . . . . . . . . . . . . . 4
5. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 4
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
9.1 Normative References . . . . . . . . . . . . . . . . . . . 5
9.2 Informative References . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 5
Intellectual Property and Copyright Statements . . . . . . . . 6
Volz Expires October 9, 2005 [Page 2]
Internet-Draft Relay Agent Subscriber-ID April 2005
1. Introduction
DHCPv6 [1] provides IP addresses and configuration information for
IPv6 clients. It includes a relay agent capability, in which
processes within the network infrastructure receive multicast
messages from clients and relay them to DHCPv6 servers. In some
network environments, it will be useful for the relay agent to add
information to the DHCPv6 message before relaying it.
The information that relay agents supply can also be used in the
server's decision making about the addresses, delegated prefixes [3],
and configuration parameters that the client is to receive.
In many service provider environments, it is believed to be desirable
to associate some provider-specific information with clients' DHCPv6
messages that is independent of the physical network configuration
and which the relay agent has learned through some means which is
outside the scope of this memo.
2. Requirements Terminology
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 [2].
3. The Relay Agent Subscriber-ID Option
In complex service provider environments, there is a need to connect
a customer's DHCPv6 configuration with the customer's administrative
information. The Relay Agent Subscriber-ID option carries a value
that can be independent of the physical network configuration through
which the subscriber is connected. This value complements, and might
well be used in addition to, the network-based information. The
"subscriber-id" assigned by the provider is intended to be stable as
customers connect through different paths, and as network changes
occur.
The subscriber-id information allows the service provider to assign/
activate subscriber-specific actions, e.g. assignment of specific IP
addresses, prefixes, DNS configuration, trigger accounting, etc.
This option is de-coupled from the access network's physical
structure, so subscriber moves from one access-point to another, for
example, would not require reconfiguration at the service provider's
DHCPv6 servers.
The subscriber-id is an NVT ASCII [4] string. The semantic contents
of the subscriber-id field are of course provider-specific. This
specification does not establish any semantic requirements on the
Volz Expires October 9, 2005 [Page 3]
Internet-Draft Relay Agent Subscriber-ID April 2005
data in the string.
The format of the DHCPv6 Relay Agent Subscriber-ID option is shown
below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_SUBSCRIBER_ID | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. subscriber-id .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_SUBSCRIBER_ID (TBD)
option-len length, in octets, of the subscriber-id field.
The minimum length is 1 octet.
subscriber-id A NVT ASCII string. It MUST NOT be null
terminated.
4. DHCPv6 Relay Agent Behavior
DHCPv6 relay agents MAY be configured to include a Subscriber-ID
option in relayed (RELAY-FORW) DHCPv6 messages. The subscriber-id
strings themselves are assigned and configured through mechanisms
that are outside the scope of this memo.
5. DHCPv6 Server Behavior
This option provides additional information to the DHCPv6 server.
The DHCPv6 server, if it is configured to support this option, MAY
use this information in addition to other relay agent option data,
other options included in the DHCPv6 client messages, and physical
network topology information in order to assign IP addresses,
delegate prefixes, and/or other configuration parameters to the
client. There is no special additional processing for this option.
There is no requirement that a server return this option and its data
in a RELAY-REPLY message.
6. Security Considerations
See [1] section 21.1, on securing DHCPv6 messages sent between
servers and relay agents, and section 23, on general DHCPv6 security
Volz Expires October 9, 2005 [Page 4]
Internet-Draft Relay Agent Subscriber-ID April 2005
considerations.
7. IANA Considerations
IANA is requested to assign a DHCPv6 option code for the Relay Agent
Subscriber-ID Option.
8. Acknowledgements
Thanks to Richard Johnson, Theyn Palaniappan, and Mark Stapp as this
document is essentially an edited verison of their memo [5].
9. References
9.1 Normative References
[1] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 3315, July 2003.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
9.2 Informative References
[3] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host
Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
[4] Postel, J. and J. Reynolds, "Telnet Protocol Specification",
STD 8, RFC 854, May 1983.
[5] Johnson, R., Palaniappan, T., and M. Stapp, "Subscriber-ID
Suboption for the Dynamic Host Configuration Protocol (DHCP)
Relay Agent Option", RFC 3993, March 2005.
Author's Address
Bernard Volz
Cisco Systems, Inc.
1414 Massachusetts Ave.
Boxborough, MA 01719
USA
Phone: +1 978 936 0382
Email: volz@cisco.com
Volz Expires October 9, 2005 [Page 5]
Internet-Draft Relay Agent Subscriber-ID April 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Volz Expires October 9, 2005 [Page 6]
