Network Working Group Y. Yang Internet-Draft Q. Wu Intended status: Informational Huawei Expires: 1 January 2027 6 July 2026 DHCP New Option Extension based on LLM Capability draft-yang-dhc-dhcp-extension-00 Abstract This document specifies a DHCP option extension designed for campus networks to help client devices distinguish and connect to a master device with the LLM (Large Language Model). The mechanism extends a new DHCP option containing two specific parameters within the DHCP payload: the master device's LLM address and the master device's LLM configuration. This allows client devices to identify and register to LLM-enabled master device during the bootstrap phase. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://Yuanyuan4666.github.io/draft-yang-dhcp-extension/draft-yang- dhcp-extension.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-yang-dhc-dhcp- extension/. Source for this draft and an issue tracker can be found at https://github.com/Yuanyuan4666/draft-yang-dhcp-extension. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on 1 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction 2. Conventions and Definitions 3. Typical Deployment Topology 4. Message Formats 4.1. New DHCP Option Format (OPTION_LLM_META) 4.1.1. Field Attribute Interpretations 5. Client Behavior 6. Server Behavior 7. Security Considerations 8. IANA Considerations Acknowledgments Normative References Authors' Addresses 1. Introduction A campus network refers to a network established within a specific area, such as an enterprise, science park, school, or hospital. Network elements within a campus network are divided into master devices (such as a core switch or a gateway) and client devices (such as an access switch or an AP). Client devices must discover and register to a master device to complete networking, while the master device manages multiple registered client devices. Centralized campus Artificial Intelligence for IT Operations (AIOps) relies on cloud data centers. Local devices upload logs and alarms to the cloud for LLM analysis. This introduces two pitfalls: 1. *Data Privacy*: Regulations prohibit uploading internal network topology and business traffic data to public clouds. 2. *High Latency*: Cloud interactions over WAN (Wide Area Network) introduce high latency, failing the real-time requirements for network self- healing. To eliminate these bottlenecks, shifting LLM inference to the network edge is the current trend. Core switches and gateways are now equipped with NPU/GPU hardware. This distributed architecture keeps sensitive data within the campus and eliminates cloud latency, enabling real-time root-cause analysis and troubleshooting directly at the edge. Currently, the master device's IP configuration attributes are manually configured via CLI or hardcoded into client devices. Although standard DHCP automatically assigns basic parameters like IP addresses, subnets, and gateways, it cannot indicate whether a master device possesses LLM capabilities. This means that client devices cannot automatically identify which master devices are LLM-enabled. Consequently, they may register to a non-LLM-enabled device and cannot request or utilize the LLM capabilities of the master device for network configuration or troubleshooting, which also leads to a waste of the master device's LLM resources. To address this limitation, this document extends two distinct elements within the DHCP protocol payload through a new DHCP option, to help client devices distinguish and connect to a master device with LLM capabilities: 1. *the master device's LLM address* 2. *the master device's LLM configuration* 2. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This document defines the following roles: *Master Device*: The network element that hosts and executes the LLM to process, analyze, and store network data at or near the physical location where the data is generated, which operates as the DHCP Server. A master device could be a core switch or a gateway equipped with hardware neural processing units. *Client Device*: The network element that collect the data with limited processing and power capability, which operates as lightweight DHCP Client. Client Device could be an aggregation switch, access switch, or a Wi-Fi Access Point (distributive deployed). 3. Typical Deployment Topology The diagram below illustrates a typical smart campus network topology. +---------------------------------------+ | Upstream Master Device (Core/GW) | | [Centralized NPU or NPU / Model] | | ====== DHCP Server ====== | +---------------------------------------+ | ____________________________|___________________________ | | +----------------------+ +----------------------+ | Aggregation Switch A | | Aggregation Switch B | +----------------------+ +----------------------+ | | ______|________________ ______|________________ | | | | +------------------+ +------------------+ +------------------+ +------------------+ | Access Switch | | Wi-Fi7 AP | | Access Switch | | Wi-Fi7 AP | | [DHCP Client] | | [DHCP Client] | | [DHCP Client] | | [DHCP Client] | +------------------+ +------------------+ +------------------+ +------------------+ *Master Device*: The Upstream Master Device (Core/GW) at the root of the network acts as the centralized intelligence center, utilizing hardware acceleration to run the LLM. *Client Device*: The downstream elements, including the Access Switches and Wi-Fi7 APs at the network edge. Note: The intermediate Aggregation Switches serve as transparent layer-2 or layer-3 transport elements only for transporting traffic. 4. Message Formats DHCP extensions convey the master device's LLM address and the master device's LLM configuration. The format of the new DHCP option (OPTION_LLM_META) is defined as follows: 4.1. New DHCP Option Format (OPTION_LLM_META) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+-------------------------------+ | OPTION_LLM_META | Option-Length | +---------------+---------------+---------------+---------------+ | LLM_Cap | LLM_Scale | LLM_Role | +---------------+-------------------------------+---------------+ | API_Price | +-------------------------------+--------------+----------------+ | Dest_Port | Addr_Type | | +-------------------------------+--------------+ | | | | Address / Domain Name (Variable Length...) | | | +---------------------------------------------------------------+ 4.1.1. Field Attribute Interpretations *the master device's LLM address parameters:* Addr_Type: 1 byte. Indicates the format of the following Address/ Domain Name. 0x01 indicates IPv4 (4 bytes); 0x02 indicates IPv6 (16 bytes); 0x03 indicates fully qualified domain name (FQDN). Dest_Port: 2 bytes. Indicates the port used to access the LLM service. 0x0000 defaults to port 443 (HTTPS); otherwise specifies the active port. Address / Domain Name: Variable length. Contains the IPv4 address/ IPv6 address/FQDN of the master device. If Addr_Type is 0x01, it MUST be a 4-byte IPv4 address; If Addr_Type is 0x02, it MUST be a 16-byte IPv6 address; If Addr_Type is 0x03, it MUST be a DNS- encoded FQDN(as specified in [RFC1035]). *the master device's LLM configuration parameters:* LLM_Cap: 1 byte. 0x01 indicates Active; 0x00 indicates Baseline. LLM_Scale: 2 bytes. Unsigned integer representing the model scale size in units of Billions (B). LLM_Role: 1 byte. 0x01 indicates Primary Master; 0x02 indicates Backup Master. API_Price: 4 bytes. 0x0000000A represents the monetary cost per million tokens. 5. Client Behavior If a DHCP client requires the LLM metadata, it MUST include OPTION_LLM_META in the Parameter Request List (PRL) option, as described in [RFC2132]. When a DHCP client receives OPTION_LLM_META, it MUST perform the following validation checks: * Verify that the Option-Length matches the required structure minimums defined in this document. * If Addr_Type is 0x03 (FQDN), verify that the Address / Domain Name field does not exceed 255 octets and represents a properly formatted domain name as specified in [RFC1035]. 6. Server Behavior A DHCP server supporting this specification MUST be capable of configuring and storing the LLM metadata, including the master device's LLM address and the master device's LLM configuration parameters. This extension does not introduce any new DHCP message types. The server processing logic MUST comply with the followings: * Upon receiving a DHCP DISCOVER or DHCP REQUEST message, the server MUST inspect the PRL option. If OPTION_LLM_META is specified in the PRL, the server SHOULD append this option into its corresponding DHCP OFFER and DHCP ACK responses. * If a client does not request OPTION_LLM_META in its PRL, or if the server itself is not configured with LLM capabilities, the server MUST NOT include OPTION_LLM_META in its reply messages. 7. Security Considerations The communication between the DHCP client and the DHCP server for exchanging LLM address and configuration parameters is security sensitive and requires server authentication and integrity protection. DHCPv4 authentication mechanisms specified in [RFC3118] can be used for this purpose. 8. IANA Considerations IANA is requested to assign a new DHCP Option code for OPTION_LLM_META from the "BOOTP Vendor Extensions and DHCP Options" registry maintained at http://www.iana.org/. Acknowledgments The authors would like to thank Qin Wu for his guidance and valuable comments on this document. Normative References [RFC1035] "Domain Names - Implementation and Specification", n.d.. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2132] "DHCP Options and BOOTP Vendor Extensions", n.d.. [RFC3118] Authentication for DHCP Messages", n.d.. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Authors' Addresses Yuanyuan Yang Huawei Email: yangyuanyuan55@huawei.com Qin Wu Huawei Email: bill.wu@huawei.com