Internet Engineering Task Force                    B. Beser 
   INTERNET DRAFT                                     Juniper Networks 
   DHC Working Group                                  P. Duffy (ed.) 
   Document: draft-ietf-dhc-packetcable-05.txt        Cisco Systems 
                                                      December 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 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).  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     December 2002 
 
   8.2.   TSP's Provisioning Server Address Sub-Option................5 
   8.3.   TSP's AS-REQ/AS-REP Backoff and Retry.......................6 
   8.4.   TSP's AP-REQ/AP-REP Backoff and Retry.......................7 
   8.5.   TSP's Kerberos Realm Name Sub-Option........................7 
   8.6.   TSP's Ticket Granting Server Utilization Sub-Option.........8 
   8.7.   TSP's Provisioning Timer Sub-Option.........................8 
   9.   Informational Description of CCC Option Usage................8 
   10.  IANA Considerations..........................................9 
   11.  Legacy Use Information.......................................9 
   12.  Procedure for Adding Additional Sub-options..................9 
   13.  Security Considerations......................................9 
   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 [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 RFC 2131[6] 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 June 2003                         2 
  Internet Draft  DHCP Option for CableLabs Clients     December 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. See section 9 for further 
   operational details. 
    
   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 June 2003                         3 
  Internet Draft  DHCP Option for CableLabs Clients     December 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 |  
      +------+--------+--------------+--------------+---+--------------+  
        
   When the total length of a CCC option exceeds 255 octets, the 
   procedure outlined in [4] SHOULD be employed to split the option into 
   multiple, smaller options. 
    
   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-   | 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 Provisioning Server Address          |  
      +---------+---------+--------------------------------------------+  
      |    4    |  MTA    | TSP's AS-REQ/AS-REP Backoff and Retry      |  
      +---------+---------+--------------------------------------------+  
      |    5    |  MTA    | TSP's 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 - 255 |         | Reserved for future extensions             | 
      +---------+---------+--------------------------------------------+  
    
 
  Beser & Duffy           Expires June 2003                         4 
  Internet Draft  DHCP Option for CableLabs Clients     December 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: 
    
   - Fully Qualified Domain Names (FQDNs) MUST be encoded per RFC 1035 
     [3] section 3.1. Note that a terminating 0 is required.  Also note 
     that compression, as described in RFC 1035 [3] section 4.1.4, MUST 
     NOT be applied. 
   - IPv4 addresses MUST be encoded as 4 binary octets in network byte-
     order (high order byte first). 
   - All multi-octet quantities MUST be encoded per network byte-
     ordering. 
    
   8.1. TSP's DHCP Server Address Sub-Options 
        
   The TSP DHCP Server Address sub-options identify the DHCP servers 
   from which an MTA is permitted to accept a DHCP OFFER.  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. 
      
   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 |    
      +-----+-----+-----+-----+-----+-----+  
    
        
                                         
   8.2. TSP's Provisioning Server Address Sub-Option 
        
   This option contains the address of the TSP's Provisioning server.  
   MTAs communicate with the Provisioning server at various stages in 
   their provisioning process.   
        
   The address can be configured as either an IPv4 address or as an 
   FQDN. The encoding of sub-option 3 will adhere to one of 2 formats. 
        
   1. IPv4 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 1 to 
   indicate an IPv4 address.  The type octet MUST be followed by 4 
   octets of IPv4 address:   
    
    
       Code   Len   Type        Address 
      +-----+-----+-----+-----+-----+-----+-----+  
      |  3  |  5  |  1  |  a1 |  a2 |  a3 |  a4 |    
      +-----+-----+-----+-----+-----+-----+-----+  
    
 
  Beser & Duffy           Expires June 2003                         5 
  Internet Draft  DHCP Option for CableLabs Clients     December 2002 
 
        
    
        
   2. 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 0 to indicate an FQDN.  The type octet MUST be 
   followed by the encoded FQDN: 
    
    
       Code   Len   Type            FQDN 
      +-----+-----+-----+-----+-----+   +-----+ 
      |  3  | n+1 |  0  |  f1 |  f2 |...|  fn | 
      +-----+-----+-----+-----+-----+   +-----+ 
        
 
 
   It is not anticipated that additional type codes, beyond IPv4 (1) and 
   FQDN (0), will be required.  Thus, IANA will not be required to 
   maintain a registry of type codes. 
      
   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.   
    
   RFC-1510 [5] does not define a backoff/retry mechanism to be 
   employed when an AS-REQ/AS-REP message exchange fails. This sub-
   option contains parameters required by the backoff/retry mechanism 
   outlined in [8]. 
    
    
   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 contain the value 12.   
    
   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. 
    
   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 
    
   The final 4 octets MUST contain the AS-REQ/AS-REP maximum retry 
   count.  This value is a 32 bit unsigned quantity. 
    
    
 
  Beser & Duffy           Expires June 2003                         6 
  Internet Draft  DHCP Option for CableLabs Clients     December 2002 
 
   8.4. 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. 
    
   RFC-1510 [5] does not define a backoff/retry mechanism to be 
   employed when an AP-REQ/AP-REP message exchange fails. This sub-
   option contains parameters required by the backoff/retry mechanism 
   outlined in [8]. 
    
    
   The encoding of this sub-option is 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.   
    
   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 
   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 MUST be encoded per the domain style realm 
   name described in RFC 1510 [5].  This realm name MUST be all capital 
   letters and conform to the syntax described in RFC 1035 [3] section 
   3.1. The sub-option is encoded as follows: 
    
    
    
       Code   Len   Kerberos Realm Name     
      +-----+-----+-----+-----+   +-----+ 
      |  6  |  n  |  k1 |  k2 |...|  kn | 
      +-----+-----+-----+-----+   +-----+ 
    
       
      
 
  Beser & Duffy           Expires June 2003                         7 
  Internet Draft  DHCP Option for CableLabs Clients     December 2002 
 
   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.7. 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) |  
      +-----+-----+---------+  
        
    
    
   9.   Informational Description of CCC Option Usage.  
    
   Cablelabs client devices issue DHCP requests that include DHCP 
   options 55 (Parameter Request List) and 60 (Vendor Class 
   Identifier).  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 CCC option for the PacketCable project is described in 
   [7].  
    
   Note that client devices never populate the CCC option in their DHCP 
   requests.   
 
  Beser & Duffy           Expires June 2003                         8 
  Internet Draft  DHCP Option for CableLabs Clients     December 2002 
 
 
    
   10.  IANA Considerations 
 
   IANA has assigned a value of TBD for the DHCP option code described 
   in this document. 
 
   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 [2]. 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  
        
    
   Potential exposures to attack in the DHCP protocol are discussed in 
   section 7 of the DHCP protocol specification [6] and in 
   Authentication for DHCP Messages [9]. 
    
   The CCC option can be used to misdirect network traffic by providing 
   incorrect DHCP server addresses, incorrect provisioning server 
   addresses, and incorrect Kerberos realm names to a Cablelabs client 
   device.  This misdirection can lead to several threat scenarios.  A 
   Denial of Service (DoS) attack can result from address information 
   being simply invalid.  A man-in-the-middle attack can be mounted by 
   providing addresses to a potential snooper.  A malicious TSP can 
   steal customers from the customer selected TSP, by altering the 
   Kerberos realm designation. 
    
   These threats are mitigated by several factors.   
    
   Within the cable delivery architecture required by PacketCable, the 
   DHCP client is connected to a network through a cable modem and the 
   CMTS (head-end). The CMTS is explicitly configured with a set of 
 
  Beser & Duffy           Expires June 2003                         9 
  Internet Draft  DHCP Option for CableLabs Clients     December 2002 
 
   DHCP servers to which DHCP requests are forwarded.  Further, a 
   correctly configured CMTS will only allow downstream traffic from 
   specific IP addresses/ranges.  
    
   Assuming that server addresses and Kerberos realm name were 
   successfully spoofed to the point that a malicious client device was 
   able to contact a KDC, the client device must still present valid 
   certificates to the KDC before being service enabled.  Given the 
   computational overhead of the certificate validation process, this 
   situation could present a DoS opportunity. 
    
   Finally, it is possible for a malicious (although certified) TSP to 
   redirect a customer from the customer's selected TSP.  It is assumed 
   that all TSP's permitted onto an access providers network are 
   trusted entities that will cooperate to insure peaceful coexistence.  
   If a TSP is found to be redirecting customers, this should be 
   handled as an administrative matter between the access provider and 
   the TSP. 
    
    
   14.  References  
        
   14.1. Normative 
       
   1. S. Bradner, "Key words for use in RFCs to Indicate Requirement 
   Levels", BCP 14, RFC 2119, March 1997.  
        
   2. T. Narten and H. Alvestrand, "Guidelines for Writing an IANA 
   Considerations Section in RFCs", RFC 2434, October 1998. 
     
   3. P. Mockapetris, "Domain Names - Implementation and Specification 
   ", RFC 1035, November 1987 
    
   4. T. Lemon and S. Cheshire, "Encoding Long Options in the Dynamic 
   Host Configuration Protocol (DHCPv4)", RFC 3396, November 2002. 
    
   5. J. Kohl and C. Neuman, "The Kerberos Network Authentication 
   Service (V5)", RFC 1510, September 1993. 
    
   6. R. Droms, "Dynamic Host Configuration Protocol", RFC 2131, March 
   1997.  
               
       
   14.2. Informational 
    
   7. "PacketCable MTA Device Provisioning Specification", PKT-SP-PROV-
   I05-021127.  http://www.packetcable.com/specifications.html 
    
    
   8. "PacketCable Security Specification", PKT-SP-SEC-I07-021127, 
   http://www.packetcable.com/specifications.html  
    
 
  Beser & Duffy           Expires June 2003                        10 
  Internet Draft  DHCP Option for CableLabs Clients     December 2002 
 
   9. R. Droms and W. Arbaugh, "Authentication for DHCP Messages", RFC 
   3118, June 2001 
    
   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); 
   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 June 2003                        11 
  Internet Draft  DHCP Option for CableLabs Clients     December 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 June 2003                        12