Internet Engineering Task Force B. Beser INTERNET DRAFT Juniper Networks DHC Working Group P. Duffy (ed.) Document: draft-ietf-dhc-packetcable-02.txt Cisco Systems June 2002 DHCP Option for CableLabs Client Configuration 1. 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. 2. Abstract This document defines a DHCP option that will be used to configure various devices deployed within CableLabs architectures. Specifically, the document describes DHCP option content that will be used to configure one class of CableLabs client device: a PacketCable Media Terminal Adapter (MTA). It is expected that the option content defined within this document will be extended as future CableLabs client devices are developed. 3. Table of Contents 1. Status of this Memo..........................................1 2. Abstract.....................................................1 3. Table of Contents............................................1 4. Conventions used in this document............................2 5. Terminology..................................................2 6. Introduction.................................................2 7. CableLabs Client Configuration Option Format.................4 8. CableLabs Client Configuration Option: Sub-Option Definitions 5 8.1. TSP's DHCP Server Address Sub-Options.......................5 Beser & Duffy 1 Internet Draft DHCP Option for CableLabs Clients June 2002 8.2. TSP's SNMP Entity Address Sub-Option........................5 8.3. TSP's Domain Name Server Address Sub-Options................7 8.4. TSP's Kerberos Realm Name Sub-Option........................7 8.5. TSP's Ticket Granting Server Utilization Sub-Option.........8 8.6. TSP's Provisioning Timer Sub-Option.........................8 8.7. TSP's AS-REQ/AS-REP Backoff and Retry.......................8 8.8. TSP's AP-REQ/AP-REP Backoff and Retry.......................9 9. Typical use of the CableLabs Client Configuration Option.....9 10. IANA Considerations..........................................9 11. Legacy Use Information......................................10 12. Procedure for Adding Additional Sub-options.................10 13. Security Considerations.....................................10 14. References..................................................10 15. Acknowledgments.............................................11 16. Author's Addresses..........................................11 17. Full Copyright Statement....................................11 4. Conventions used in this document 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 [2]. 5. Terminology Definitions of terms used throughout this document: * "Telephony Service Provider" or "TSP" The business entity from which a subscriber receives telephony service. See RFC2131[5] for additional DHCP terminology. 6. Introduction Cable Television Laboratories, Inc. (CableLabs) is a non-profit research and development consortium that serves the cable television industry via design and specification of new and emerging broadband service architectures. Several CableLabs initiatives define DHCP clients that have specific DHCP configuration requirements. One such initiative is the PacketCable project. The PacketCable project is aimed at architecting, qualifying, and supporting Internet-based multimedia services over cable-based packet networks. These new multimedia services will include telephony and videoconferencing, delivered using the basic Internet Protocol (IP) technology that is used to send data via the Internet. Beser & Duffy Expires December 2002 2 Internet Draft DHCP Option for CableLabs Clients June 2002 PacketCable 1.0 provides Voice over IP (VoIP) service delivery. The VoIP service is supported at the customer site by two key components: a Cable Modem (CM) and a Media Terminal Adapter (MTA). The CM converts the cable RF signals to/from various IP voice protocols, while the MTA converts the VoIP protocols into analog telephony compatible with a common telephone. The CM and MTA may be packaged together or separately. If packaged together, the unit is referred to as an Embedded-MTA (EMTA - depicted in Figure 1). If packaged separately, the MTA is referred to as a Standalone MTA (SMTA). |----------------------------------------------| | | | |-----------| |-------------| | | | | | | | Telephony | | Media | internal | Cable | | RF Link ---------_|---| Terminal |===========| Modem |----|------- Link | | Adapter | connection| | | | |-----------| |-------------| | | | |----------------------------------------------| Figure 1. PacketCable 1.0 Embedded-MTA The CM and MTA are distinct IP devices: each has its own MAC address and IP configuration. The CM and MTA utilize the DHCP protocol to obtain IP configuration. It is assumed that the CM and MTA may be administered by different business entities. The CM communicates with and is configured by the data access provider's DHCP servers. Likewise, the MTA communicates with and is configured by the Telephony Service Provider's (TSP's) DHCP servers. The PacketCable architecture requires that the business entity controlling configuration of the CM also determines which business entities control the configuration of the MTA. This is similar to the example found in the PSTN system: individuals can pick their long distance carriers even though the ultimate control of their telephone remains with the local carrier. Due to specific needs of the MTA configuration process (described in [7]), a new CableLabs Client Configuration (CCC) option is needed for the DHCP protocol. Both CM and MTA DHCP clients will request this option. When requested, both the CM and TSP DHCP servers will populate this option into DHCP responses. It should be noted that, although the CCC option will be initially deployed to support PacketCable VOIP applications, the CCC option will also be used to support various non VOIP applications. Use of the CCC option does not necessarily mean that the service provider is a TSP. Beser & Duffy Expires December 2002 3 Internet Draft DHCP Option for CableLabs Clients June 2002 7. CableLabs Client Configuration Option Format The option begins with a tag octet containing the option code (code TBD). A length octet follows the tag octet. The value of the length octet does not include itself or the tag octet. The length octet is followed by "length" octets of sub-option content (total length, not sub-option count). The option layout is depicted below: +------+--------+--------------+--------------+---+--------------+ | Code | Length | Sub-option 1 | Sub-option 2 |...| Sub-option n | +------+--------+--------------+--------------+---+--------------+ A sub-option begins with a tag octet containing the sub-option code. A length octet follows the tag octet. The value of the length octet does not include itself or the tag octet. The length octet is followed by "length" octets of sub-option information. The sub- option layout is depicted below: +-------------------+--------+------------------------+ | Sub-option Code | Length | Sub-option information | +-------------------+--------+------------------------+ The sub-option codes are summarized below. +---------+---------+--------------------------------------------+ | Sub- | Used by | Description | | option | | | | Code | | | +===================+============================================+ | 1 | CM | TSP's Primary DHCP Server Address | +---------+---------+--------------------------------------------+ | 2 | CM | TSP's Secondary DHCP Server Address | +---------+---------+--------------------------------------------+ | 3 | MTA | TSP's SNMP Entity Address | +---------+---------+--------------------------------------------+ | 4 | MTA | TSP's Primary Domain Name Server Address | +---------+---------+--------------------------------------------+ | 5 | MTA | TSP's Secondary Domain Name Server Address | +---------+---------+--------------------------------------------+ | 6 | MTA | TSP's Kerberos Realm Name | +---------+---------+--------------------------------------------+ | 7 | MTA | TSP's Ticket Granting Server Utilization | +---------+---------+--------------------------------------------+ | 8 | MTA | TSP's Provisioning Timer Value | +---------+---------+--------------------------------------------+ | 9 | | Reserved for future CableLabs use | +---------+---------+--------------------------------------------+ | 10 | MTA | TSP's AS-REQ/AS-REP Backoff and Retry | +---------+---------+--------------------------------------------+ | 11 | MTA | TSP's AP-REQ/AP-REP Backoff and Retry | +---------+---------+--------------------------------------------+ |12 - 255 | | Reserved for future CableLabs use | +---------+---------+--------------------------------------------+ Beser & Duffy Expires December 2002 4 Internet Draft DHCP Option for CableLabs Clients June 2002 8. CableLabs Client Configuration Option: Sub-Option Definitions The following sections provide detailed descriptions of each sub- option. There are a few general formatting rules: - Several sub-options permit specification of a port number. When specified, port numbers MUST be encoded as 16 bit unsigned integers in network byte order. If omitted, standard protocol port numbers, as defined in [4], are assumed. - FQDN's MUST be encoded per RFC 1035 section 3.1. Note that a terminating 0 is required. - IPv4 addresses MUST be encoded as 4 binary octets in network byte- order. - All multi-octet quantities MUST be encoded per network byte- ordering (high-order byte first). 8.1. TSP's DHCP Server Address Sub-Options The TSP DHCP Server Address sub-options identify the DHCP servers that will be used by an MTA to obtain IP configuration. Sub-option 1 is the address of the TSP's primary DHCP server. Sub- option 2 is the address of the TSP's secondary DHCP server. Both sub- options 1 and 2 MAY specify a DHCP server port number. The encoding syntax for sub-options 1/2 takes on two forms depending on whether a port number is included or not. 1. IPv4 address using default port. The sub-option length MUST be 4 and the sub-option MUST include the DHCP server's IPv4 address as follows: Code Len Address +-----+-----+-----+-----+-----+-----+ | 1/2 | 4 | a1 | a2 | a3 | a4 | +-----+-----+-----+-----+-----+-----+ The default DHCP port number is assumed. 2. IPv4 address with a specific port. The sub-option length MUST be 6. The sub-option MUST include and DHCP server's IPv4 address and port number as follows: Code Len Address Port +-----+-----+-----+-----+-----+-----+------+-----+ | 1/2 | 6 | a1 | a2 | a3 | a4 | p1 | p2 | +-----+-----+-----+-----+-----+-----+------+-----+ 8.2. TSP's SNMP Entity Address Sub-Option Beser & Duffy Expires December 2002 5 Internet Draft DHCP Option for CableLabs Clients June 2002 This option contains the address of the TSP's network SNMP Entity. MTAs communicate with the SNMP entity at various stages in their provisioning process. For complete details of this provisioning process, see [7]. The address can be configured as either an IPv4 address with optional port number or as an FQDN with optional port number. The encoding of sub-option 3 will adhere to one of 4 formats. 1. IPv4 address using the default port. The sub-option length MUST be 5. The length octet MUST be followed by a single octet that indicates the specific address type that follows. This type octet MUST be set to 0 to indicate an IPv4 address. The type octet MUST be followed by 4 octets of IPv4 address: Code Len Type Address +-----+-----+-----+-----+-----+-----+-----+ | 3 | 5 | 0 | a1 | a2 | a3 | a4 | +-----+-----+-----+-----+-----+-----+-----+ 2. IPv4 address using a specific port. The sub-option length MUST be 7. The length octet MUST be followed by a single octet that indicates the specific address type that follows. This type octet MUST be set to 0 to indicate an IPv4 address. The type octet MUST be followed by 4 octets of IPv4 address. A port number MUST follow the IPv4 address: Code Len Type Address Port +-----+-----+-----+-----+-----+-----+-----+-----+-----+ | 3 | 7 | 0 | a1 | a2 | a3 | a4 | p1 | p2 | +-----+-----+-----+-----+-----+-----+-----+-----+-----+ 3. FQDN using the default port. The length octet MUST be followed by a single octet that indicates the specific address type that follows. This type octet MUST be set to 1 to indicate an FQDN. The type octet MUST be followed by the encoded FQDN: Code Len Type FQDN +-----+-----+-----+-----+-----+ +-----+ | 3 | n+1 | 1 | f1 | f2 |...| fn | +-----+-----+-----+-----+-----+ +-----+ 4. FQDN with specific port. The length octet MUST be followed by a single octet that indicates the specific address type that follows. This type octet MUST be set to 1 to indicate an FQDN. The type octet MUST be followed by the encoded FQDN. A port number MUST follow the FQDN: Beser & Duffy Expires December 2002 6 Internet Draft DHCP Option for CableLabs Clients June 2002 Code Len Type FQDN Port +-----+-----+-----+-----+-----+ +-----+-----+-----+ | 3 | n+3 | 1 | f1 | f2 |...| fn | p1 | p2 | +-----+-----+-----+-----+-----+ +-----+-----+-----+ 8.3. TSP's Domain Name Server Address Sub-Options The TSP's DNS servers resolve PacketCable FQDN's into an IPv4 addresses. The MTA requires DNS capability. Sub-option 4 is the address of the TSP's primary DNS server. Sub- option 5 is the address of the TSP's secondary DNS server. Sub- option 5 MAY be specified to identify a redundant or backup DHCP server. Both sub-options 4 and 5 MAY specify a DNS server port number. The encoding syntax for sub-options 4/5 takes on two forms depending on whether a port number is included or not. 1. IPv4 address using default port. The sub-option length MUST be 4 and the sub-option MUST include the DNS server's IPv4 address as follows: Code Len Address +-----+-----+-----+-----+-----+-----+ | 4/5 | 4 | a1 | a1 | a3 | a4 | +-----+-----+-----+-----+-----+-----+ The default DNS port number is assumed. 2. IPv4 address using a specific port. The sub-option length MUST be 6. The sub-option MUST include and DNS server's IPv4 address and port number as follows: Code Len Address Port +-----+-----+-----+-----+-----+-----+------+-----+ | 4/5 | 6 | a1 | a2 | a3 | a4 | p1 | p2 | +-----+-----+-----+-----+-----+-----+------+-----+ 8.4. TSP's Kerberos Realm Name Sub-Option The PacketCable architecture requires an MTA to authenticate itself to the TSP's network via the Kerberos protocol. A Kerberos Realm name is required at the MTA to permit a DNS lookup for the address of the TSP's Kerberos Key Distribution Center (KDC) entity. The Kerberos Realm name is an FQDN. The sub-option is encoded as follows: Beser & Duffy Expires December 2002 7 Internet Draft DHCP Option for CableLabs Clients June 2002 Code Len Kerberos Realm Name +-----+-----+-----+-----+ +-----+ | 6 | n | k1 | k2 |...| kn | +-----+-----+-----+-----+ +-----+ 8.5. TSP's Ticket Granting Server Utilization Sub-Option This sub-option encodes a boolean value which indicates whether an MTA should or should not utilize a TGT (Ticket Granting Ticket) when obtaining a service ticket for one of the PacketCable application servers. The encoding is as follows: Code Len Value +-----+-----+-----+ | 7 | 1 | 1/0 | +-----+-----+-----+ The length MUST be 1. The last octet contains a Boolean value which MUST be either 0 or 1. A value of 1 MUST be interpreted as true. A value of 0 MUST be interpreted as false. 8.6. TSP's Provisioning Timer Sub-Option The provisioning timer defines the maximum time allowed for the MTA provisioning process to complete. If this timer expires before the MTA has completed the provisioning process, the MTA should reset the timer and re-start its provisioning process from the beginning. The sub-option length MUST be 1 and a value between 1 and 30 (minutes, inclusive) MUST be used. If any other value is specified, the MTA MUST treat the sub-option as non-populated. Code Len Value +-----+-----+---------+ | 8 | 1 | (1..30) | +-----+-----+---------+ 8.7. TSP's AS-REQ/AS-REP Backoff and Retry This sub-option configures an MTA's Kerberos AS-REQ/AS_REP timeout, backoff, and retry mechanism. The encoding of this sub-option is depicted below: Code Len Nom Timeout Max Timeout Max Retries +---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |10 |12 |n1 |n2 |n3 |n4 |m1 |m2 |m3 |m4 |r1 |r2 |r3 |r4 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+ The length octet of this sub-option MUST contain the value 12. Beser & Duffy Expires December 2002 8 Internet Draft DHCP Option for CableLabs Clients June 2002 The length octet MUST be followed by 4 octets containing the AS- REQ/AS-REP nominal (initial) timeout value. This value is a 32 bit unsigned quantity, in units of seconds, encoded per network byte ordering rules. The next 4 octets MUST contain the AS-REQ/AS-REP maximum timeout value. This value is a 32 bit unsigned quantity, in units of seconds, encoded per network byte ordering rules. The final 4 octets MUST contain the AS-REQ/AS-REP maximum retry count. This value is a 32 bit unsigned quantity encoded per network byte ordering rules. 8.8. TSP's AP-REQ/AP-REP Backoff and Retry This sub-option configures an MTA's Kerberos AP-REQ/AP_REP timeout, backoff, and retry mechanism. The encoding of this sub-option is depicted below: Code Len Nom Timeout Max Timeout Max Retries +---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |11 |12 |n1 |n2 |n3 |n4 |m1 |m2 |m3 |m4 |r1 |r2 |r3 |r4 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+ The length octet of this sub-option MUST contain the value 12. The length octet MUST be followed by 4 octets containing the AP- REQ/AP-REP nominal (initial) timeout value. This value is a 32 bit unsigned quantity, in units of seconds, encoded per network byte ordering rules. The next 4 octets MUST contain the AP-REQ/AP-REP maximum timeout value. This value is a 32 bit unsigned quantity, in units of seconds, encoded per network byte ordering rules. The final 4 octets MUST contain the AP-REQ/AP-REP maximum retry count. This value is a 32 bit unsigned quantity encoded per network byte ordering rules. 9. Typical use of the CableLabs Client Configuration Option Specific usage of the CableLabs Client Configuration option is described in [7]. 10. IANA Considerations IANA has assigned a value of TBD for the DHCP option code described in this document. Beser & Duffy Expires December 2002 9 Internet Draft DHCP Option for CableLabs Clients June 2002 11. Legacy Use Information The CableLabs Client Configuration option initially used the site- specific option value of 177 (0xB1). The use of the site-specific option is to be deprecated when IANA issues an official option number. 12. Procedure for Adding Additional Sub-options IANA is requested to maintain a new number space of "CableLabs Client Configuration Sub-options", located in the BOOTP-DHCP Parameters Registry. The initial sub-option codes are described in sections of this document. IANA is requested to register codes for future CableLabs Client Configuration Sub-options with an "Expert Review" approval policy as described in RFC 2434 [3]. Future proposed sub-options will be assigned a numeric code chosen by CableLabs, which will be documented in the Internet Drafts that describe the sub-options. The code assignment will be reviewed by a designated expert from the IETF prior to publication in an RFC. 13. Security Considerations This draft relies on the DHCP protocol [5] for authentication and security, i.e. it does not provide in excess of what DHCP is (or will be) providing. It does not expose any security threats beyond what is currently exposed by other DHCP options. 14. References 1. Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, September 1996. 2. Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 3. Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC-2132, March 1997. 4. Reynolds, J., Postel, J., _ASSIGNED NUMBERS_, RFC 1340, July 1992. 5. Droms, R., "Dynamic Host Configuration Protocol", RFC-2131, March 1997. 6. CableLabs, "Radio Frequency Interface Specification", SP-RFIvX.X. http://www.cablemodem.com/specifications.html 7. PacketCable, "MTA Device Provisioning Specification", PKT-SP- PROV-XXX-XXXXXX. http://www.packetcable.com/specifications.html Beser & Duffy Expires December 2002 10 Internet Draft DHCP Option for CableLabs Clients June 2002 15. Acknowledgments The authors would like to extend a heartfelt thanks to all those who contributed to the development of the PacketCable Provisioning specifications: Sumanth Channabasappa (Alopa Networks); Angela Lyda, Rick Morris, Rodney Osborne Arris Interactive); Steven Bellovin and Chris Melle (AT&T); Eugene Nechamkin Broadcom); John Berg, Maria Stachelek, Matt Osman (CableLabs); Klaus Hermanns, Azita Kia, Michael Thomas, Paul Duffy (Cisco); Deepak Patil (Com21); Jeff Ollis, Rick Vetter (General Instrument/Motorola); Roger Loots, David Walters (Lucent); Burcak Beser (Pacific Broadband); Peter Bates (Telcordia); Patrick Meehan (Tellabs); Satish Kumar, Itay Sherman, Roy Spitzer (Telogy/TI), Aviv Goren (Terayon); Prithivraj Narayanan (Wipro); and Rich Woundy (AT&T Broadband). 16. Author's Addresses Burcak Beser Juniper Networks 1194 North Matilda Avenue Sunnyvale, CA, 94089 Email: burcak@juniper.net Paul Duffy Cisco Systems 300 Apollo Drive Chelmsford, MA, 01824 Email: paduffy@cisco.com 17. Full Copyright Statement 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. Beser & Duffy Expires December 2002 11 Internet Draft DHCP Option for CableLabs Clients June 2002 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Beser & Duffy Expires December 2002 12