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

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/