RFC 3256

RFC 3256 📜🎀 The DOCSIS Device Class DHCP Relay Agent Information Sub-option

📌 Title block, the tea: This is RFC 3256, a Standards Track doc from April 2002, written by Doug Jones (YAS Corporation) and Rich Woundy (AT&T Broadband). The header doesn't list any Obsoletes or Updates, so it's not replacing or changing anything else. 💅

Status of this Memo ✨

This doc is an Internet standards track protocol for the Internet community, and it's open for discussion and suggestions for improvements. 🫶 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited. 🌸

Abstract 🦋

Okay so this doc proposes a brand-new sub-option for the DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Option. 💖 It's made for DOCSIS (Data-Over-Cable Service Interface Specifications) cable modems, and it describes a "device class" that tells you what kind of cable modem it is. The cable modem signals its device class info to the Relay Agent using DOCSIS signaling. Then the Relay Agent passes that info on to the DHCP Server, which can make a policy decision based on it. It's giving smart routing, no cap. 🔥

1. Introduction 🧚

The "Relay Agent Information" Option is described in [1], and it comes with several Relay Agent Information sub-options. ✨ This RFC adds one more sub-option for DOCSIS cable modems. The Relay Agent adds this sub-option when it terminates cable modems. It encodes an identifier for the device class the modem belongs to, and DHCP servers use it to make policy decisions based on the host's device class. 💜

The reason this is a Relay Agent Information sub-option, and not a new or existing DHCP option, is CPE Controlled Cable Modems (CCCMs) [2]. 😭 In a CCCM, the modem firmware controls DOCSIS signaling, but the attached computer (the CPE) handles other protocol stuff, especially DHCP client message handling. The whole assumption here is that it's safer to trust the CCCM firmware than to trust CCCM software running on the attached computer (like a regular PC). 🙈

The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2119 [4]. 📖

2. DOCSIS Device Class Sub-option 🍓

The DOCSIS RFI specification [3] defines the Device Class encoding inside the payload of the Device Class Identification Request (DCI-REQ) message. 🎀 The relay agent MUST pass the Device Class value unchanged to the DHCP server. Some possible uses for this field are:

• host endpoint information
• host hardware capabilities
• host software capabilities
• host options information

The Device Class is a 32-bit field where each bit stands for one attribute of the CM. Bit #0 is the least significant bit of the field. You set a bit to 1 to select the attribute below. 🔥

bit #0 - CPE Controlled Cable Modem (CCCM)

bits #1-31 - Reserved and set to zero

The DOCSIS Device Class sub-option is coded like this:

    SubOpt   Len     Device Class
  +------+------+------+------+------+------+
  |  4   |   4  |  d1  |  d2  |  d3  |  d4  |
  +------+------+------+------+------+------+

The DHCP server needs to understand what this sub-option means so it can offer different policy options in its reply to the host. ✨ DHCP servers MAY use the device class for IP and other parameter assignment policies for cable modems. 💅

3. Security Considerations 🔐💀

Okay, this part is serious, bestie. 🫣 The DHCP Relay Agent Information Option works because there's an implied trusted relationship between the DHCP relay agent and the DHCP server. The security considerations for the DHCP relay agent information option in [1] apply to this sub-option too. 🛡️

The DOCSIS Device Class sub-option also relies on an implied trusted relationship, this time between the DHCP client (the cable modem) and the DHCP relay agent, through DOCSIS signaling. ⚠️ According to the DOCSIS specifications [2], the cable modem firmware always controls DOCSIS signaling, but it can't control DHCP client message handling (for example, in CCCMs). This doc assumes the cable modem firmware is trustworthy for DOCSIS signaling information. 🥺

This document introduces a new identifier, the DOCSIS Device Class sub-option, which is provided by the relay agent device and is assumed to be trusted. Cryptographic or other techniques to authenticate the device class are beyond the scope of this document.

4. IANA Considerations 📋

IANA has assigned a value of 4 from the DHCP Relay Agent Sub-options space [RFC 3046] for the DOCSIS Device Class sub-option defined in section 2. 🎉

5. References 📚

• [1] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.
• [2] "Data-Over-Cable Service Interface Specifications: Cable Modem to Customer Premise Equipment Interface Specification SP-CMCI-I07-020301", DOCSIS, March 2002, http://www.cablemodem.com.
• [3] "Data-Over-Cable Service Interface Specifications: Cable Modem Radio Frequency Interface Specification SP-RFIv1.1-I08-020301", DOCSIS, March 2002, http://www.cablemodem.com.
• [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

6. Authors' Addresses 💌

Doug Jones
YAS Corporation
300 Brickstone Square
Andover, MA 01810

Phone: (303) 661-3823
EMail: doug@yas.com


Rich Woundy
AT&T Broadband
27 Industrial Avenue
Chelmsford, MA 01824

Phone: (978) 244-4010
EMail: rwoundy@broadband.att.com

7. 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.

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. 💜✨