Internet Engineering Task Force                    B. Beser
   INTERNET DRAFT                                     Juniper Networks
   DHC Working Group                                  P. Duffy (ed.)
   Document: draft-ietf-dhc-packetcable-02.txt draft-ietf-dhc-packetcable-03.txt        Cisco Systems
                                                      June
                                                      August 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. RFC 2026.

   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  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 4
   8.1.   TSP's DHCP Server Address Sub-Options.......................5

  Beser & Duffy                                                     1 
   8.2.   TSP's SNMP Entity Provisioning Server Address Sub-Option........................5 Sub-Option................5
   8.3.   TSP's Domain Name Server Address Sub-Options................7 AS-REQ/AS-REP Backoff and Retry.......................6
   8.4.   TSP's AP-REQ/AP-REP Backoff and Retry.......................6
   8.5.   TSP's Kerberos Realm Name Sub-Option........................7
   8.5.
   8.6.   TSP's Ticket Granting Server Utilization Sub-Option.........8
   8.6. Sub-Option.........7
   8.7.   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 Sub-Option.........................7
   9.   Typical use   Informational Description of the CableLabs Client Configuration Option.....9 CCC Option Usage................8
   10.  IANA Considerations..........................................9 Considerations..........................................8
   11.  Legacy Use Information......................................10 Information.......................................8
   12.  Procedure for Adding Additional Sub-options.................10 Sub-options..................8
   13.  Security Considerations.....................................10 Considerations......................................9
   14.  References..................................................10  References...................................................9
   15.  Acknowledgments.............................................11  Acknowledgments..............................................9
   16.  Author's Addresses..........................................11 Addresses..........................................10
   17.  Full Copyright Statement....................................11 Statement....................................10

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

   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] RFC 2131[4] 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 February 2003                       2 
   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]),
   [5]), 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 February 2003                       3 
   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 Sent to | 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 Provisioning Server Address          |
      +---------+---------+--------------------------------------------+
      |    4    |  MTA    | TSP's Primary Domain Name Server Address AS-REQ/AS-REP Backoff and Retry      |
      +---------+---------+--------------------------------------------+
      |    5    |  MTA    | TSP's Secondary Domain Name Server Address AP-REQ/AP-REP Backoff and Retry      |
      +---------+---------+--------------------------------------------+
      |    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

   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:

  Beser & Duffy         Expires February 2003                       4 
   - 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 Fully Qualified Domain Names (FQDNs) MUST be encoded per RFC 1035
     [7] section 3.1. Note that a terminating 0 is required.
   - 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-
     ordering (high-order byte first).
     ordering.

   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 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 Provisioning Server Address Sub-Option

  Beser & Duffy         Expires December 2002                       5

   This option contains the address of the TSP's network SNMP Entity. Provisioning server.
   MTAs communicate with the SNMP entity Provisioning server 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.
   FQDN. The encoding of sub-option 3 will adhere to one of 4 2 formats.

   1. IPv4 address using the default port. address. 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. FQDN.  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
      +-----+-----+-----+-----+-----+   +-----+
      |  3  | n+1 |  1  |  f1 |  f2 |...|  fn |
      +-----+-----+-----+-----+-----+   +-----+

   4. FQDN with specific port.

   8.3. 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
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+
      | 4 |12 |n1 |n2 |n3 |n4 |m1 |m2 |m3 |m4 |r1 |r2 |r3 |r4 |
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   The length octet of this sub-option MUST be followed by a
   single octet that indicates contain the specific address type that follows.
   This type octet MUST be set to 1 to indicate an FQDN. value 12.

   The type length octet MUST be followed by 4 octets containing the encoded FQDN.  A port number AS-
   REQ/AS-REP nominal (initial) timeout value.  This value is a 32 bit
   unsigned quantity in units of seconds.

   The next 4 octets MUST follow contain the
   FQDN:

  Beser & Duffy         Expires December 2002                       6 
       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 AS-REQ/AS-REP maximum timeout
   value.  This value is the address a 32 bit unsigned quantity in units of seconds

   The final 4 octets MUST contain the TSP's primary DNS server. Sub-
   option 5 AS-REQ/AS-REP maximum retry
   count.  This value 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 32 bit unsigned quantity.

   8.4. TSP's AP-REQ/AP-REP Backoff and 5 MAY specify a DNS server port
   number. Retry

   This sub-option configures an MTA's Kerberos AP-REQ/AP_REP timeout,
   backoff, and retry mechanism.

   The encoding syntax for sub-options 4/5 takes on two forms depending
   on whether a port number of this sub-option is included or not.

   1. IPv4 address using default port. depicted below:

      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
   and the sub-option MUST include octets containing the DNS server's IPv4 address as
   follows:

        Code  Len          Address
      +-----+-----+-----+-----+-----+-----+
      | 4/5 |  4  |  a1 |  a1 |  a3 |  a4 |
      +-----+-----+-----+-----+-----+-----+

   The default DNS port number AP-
   REQ/AP-REP nominal (initial) timeout value.  This value is assumed.

   2. IPv4 address using a specific port. 32 bit
   unsigned quantity in units of seconds.

   The sub-option length next 4 octets MUST be
   6. contain the AP-REQ/AP-REP maximum timeout
   value.  This value is a 32 bit unsigned quantity in units of seconds.

   The sub-option final 4 octets 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. 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
   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. MUST be encoded per the domain style realm
   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
      +-----+-----+-----+-----+   +-----+
      |  6  |  n  |  k1 |  k2 |...|  kn |
      +-----+-----+-----+-----+   +-----+

   8.5.

   8.6. 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 PacketCable application
   servers. The encoding is as non-populated. follows:

       Code   Len   Value
      +-----+-----+---------+
      +-----+-----+-----+
      |  8  7  |  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 1/0 |
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+
      +-----+-----+-----+

   The length octet of this sub-option MUST contain the value 12.

  Beser & Duffy         Expires December 2002                       8 be 1.  The length last octet contains a Boolean value which
   MUST be followed by 4 octets containing the AS-
   REQ/AS-REP nominal (initial) timeout value.  This either 0 or 1.  A value is a 32 bit
   unsigned quantity, in units of seconds, encoded per network byte
   ordering rules.

   The next 4 octets 1 MUST contain the AS-REQ/AS-REP maximum timeout
   value.  This be interpreted as true.  A
   value is a 32 bit unsigned quantity, in units of
   seconds, encoded per network byte ordering rules.

   The final 4 octets 0 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. be interpreted as false.

   8.7. 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 |
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+ Provisioning Timer Sub-Option

  Beser & Duffy         Expires February 2003                       7 
   The length octet of provisioning timer defines the maximum time allowed for the MTA
   provisioning process to complete. If this sub-option MUST contain timer expires before the
   MTA has completed the value 12. provisioning process, the MTA should reset the
   timer and re-start its provisioning process from the beginning.

   The sub-option length octet MUST be followed by 4 octets containing the AP-
   REQ/AP-REP nominal (initial) timeout value.  This value is 1 and a 32 bit
   unsigned quantity, in units of seconds, encoded per network byte
   ordering rules.

   The next 4 octets value between 1 and 30
   (minutes, inclusive) MUST contain the AP-REQ/AP-REP maximum timeout
   value.  This be used. If any other value is a 32 bit unsigned quantity, in units of
   seconds, encoded per network byte ordering rules.

   The final 4 octets specified,
   the MTA MUST contain treat the AP-REQ/AP-REP maximum retry
   count.  This value is a 32 bit unsigned quantity encoded per network
   byte ordering rules. sub-option as non-populated.

       Code   Len    Value
      +-----+-----+---------+
      |  8  |  1  | (1..30) |
      +-----+-----+---------+

   9.   Typical use   Informational Description of CCC Option Usage.

   Cablelabs client devices issue DHCP requests that include DHCP
   options 55 and 60.  Option 55 will request the CableLabs Client Configuration CCC option from the
   DHCP server.  Option

   Specific 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 [7]. [5].

   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

   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]. [2]. Future proposed sub-options will be

  Beser & Duffy         Expires February 2003                       8 
   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] [4] 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. S. 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,

   2. S. Alexander and R. Droms, "DHCP Options and BOOTP Vendor
   Extensions", RFC-2132, RFC 2132, March 1997.

   4. Reynolds, J.,

   3. J. Reynolds and J. Postel, J., _ASSIGNED NUMBERS_, RFC 1340, July
   1992.

   5.

   4. R. Droms, R., "Dynamic Host Configuration Protocol", RFC-2131, RFC 2131, March
   1997.

   6.  CableLabs, "Radio Frequency Interface Specification", SP-RFIvX.X.
   http://www.cablemodem.com/specifications.html

   7.  PacketCable, "MTA

   5. "PacketCable MTA Device Provisioning Specification", PKT-SP-
   PROV-XXX-XXXXXX. PKT-SP-PROV-
   XXX-XXXXXX.  http://www.packetcable.com/specifications.html

  Beser & Duffy         Expires December 2002                      10

   6. J. Kohl and C. Neuman, "The Kerberos Network Authentication
   Service (V5)", RFC 1510, September 1993.

   7. P. Mockapetris, "Domain Names - Implementation and Specification
   ", RFC 1035, November 1987

   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 (Arris Interactive); Steven Bellovin and Chris Melle
   (AT&T); Eugene Nechamkin Broadcom); (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).

  Beser & Duffy         Expires February 2003                       9 
   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

   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 February 2003                      10