From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4243.txt | 437 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 437 insertions(+) create mode 100644 doc/rfc/rfc4243.txt (limited to 'doc/rfc/rfc4243.txt') diff --git a/doc/rfc/rfc4243.txt b/doc/rfc/rfc4243.txt new file mode 100644 index 0000000..cd9a9ab --- /dev/null +++ b/doc/rfc/rfc4243.txt @@ -0,0 +1,437 @@ + + + + + + +Network Working Group M. Stapp +Request for Comments: 4243 R. Johnson +Category: Standards Track T. Palaniappan + Cisco Systems, Inc. + December 2005 + + + Vendor-Specific Information Suboption for the + Dynamic Host Configuration Protocol (DHCP) Relay Agent Option + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This memo defines a new Vendor-Specific Information suboption for the + Dynamic Host Configuration Protocol's (DHCP) relay agent information + option. The suboption allows a DHCP relay agent to include vendor- + specific information in the DHCP messages it forwards, as configured + by its administrator. + +Table of Contents + + 1. Introduction ....................................................2 + 2. Requirements Terminology ........................................2 + 3. The Vendor-Specific Suboption ...................................2 + 4. Relay Agent Behavior ............................................4 + 5. DHCP Server Behavior ............................................4 + 6. Security Considerations .........................................4 + 7. IANA Considerations .............................................5 + 8. Acknowledgements ................................................5 + Normative References ...............................................5 + Informative References .............................................5 + + + + + + + + + + + + + + + +Stapp, et al. Standards Track [Page 1] + +RFC 4243 Vendor-Specific Relay Suboption December 2005 + + +1. Introduction + + DHCP (RFC 2131 [2]) provides IP addresses and configuration + information for IPv4 clients. It includes a relay agent capability, + in which processes within the network infrastructure receive + broadcast messages from clients and forward them to DHCP servers as + unicast messages. In network environments like DOCSIS data-over- + cable and xDSL, for example, it has proven useful for the relay agent + to add information to the DHCP message before forwarding it, using + the relay agent information option (RFC 3046 [3]). + + Servers that recognize the relay agent option echo it back in their + replies, and some of the information that relays add may be used to + help an edge device efficiently return replies to clients. The + information that relays supply can also be used in the server's + decision making about the addresses and configuration parameters that + the client should receive. + + In many environments, it's desirable to associate some vendor- or + provider-specific information with the clients' DHCP messages. This + is often done using the relay agent information option. RFC 3046 + defines Remote-ID and Circuit-ID sub-options that are used to carry + such information. The values of those suboptions, however, are + usually based on some network resource, such as an IP address of a + network access device, an ATM Virtual Circuit identifier, or a DOCSIS + cable-modem identifier. As a result, the values carried in these + suboptions are dependent on the physical network configuration. The + Vendor-Specific suboption allows administrators to associate other + useful data with relayed DHCP messages. + +2. Requirements Terminology + + 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]. + +3. The Vendor-Specific Suboption + + This memo defines a new DHCP relay agent option suboption that + carries vendor-defined data. The suboption takes a form similar to + the Vendor-Identifying, Vendor-Specific Option [7]. + + + + + + + + + + + + + + + + +Stapp, et al. Standards Track [Page 2] + +RFC 4243 Vendor-Specific Relay Suboption December 2005 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Length | Enterprise Number1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | DataLen1 | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + \ Suboption Data1 \ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Enterprise Number2 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | DataLen2 | Suboption Data2 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + \ \ + . . + . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Code for the suboption is 9. + + The one-byte Length field is the length of the data carried in the + suboption, in bytes. The length includes the length of the first + Enterprise Number; the minimum length is 4 bytes. + + "Enterprise NumberN" is a vendor's Enterprise Number as registered + with IANA [4]. It is a four-byte integer value in network byte- + order. + + DataLenN is the length of the data associated with the Enterprise + Number. + + The Suboption Data is an opaque sequence of bytes. + + The Vendor-Specific suboption includes at least one Enterprise Number + and carries opaque data defined by the organization identified by the + Enterprise Number. A relay may include data associated with more + than one vendor's Enterprise Number within a single instance of the + Suboption. + + Of course, the Vendor-Specific data are vendor-specific. This + specification does not establish any requirements on the data in the + suboption. Vendors who make use of this suboption are encouraged to + document their usage in order to make interoperability possible. + + + + + + + + + + + + + + +Stapp, et al. Standards Track [Page 3] + +RFC 4243 Vendor-Specific Relay Suboption December 2005 + + +4. Relay Agent Behavior + + DHCP relay agents MAY be configured to include Vendor-Specific + suboptions if they include a relay agent information option in + relayed DHCP messages. The suboptions' types and data are assigned + and configured through mechanisms that are outside the scope of this + memo. + + Relay implementors are encouraged to offer their administrators a + means of configuring what data can be included in this suboption, and + to document what they are capable of. + +5. DHCP Server Behavior + + This suboption provides additional information to the DHCP server. + The DHCP server, if it is configured to support this suboption, may + use this information, in addition to other relay agent option data + and other options included in the DHCP client messages, in order to + assign an IP address and/or other configuration parameters to the + client. There is no special additional processing for this + suboption. + +6. Security Considerations + + Message authentication in DHCP for intradomain use, where the out- + of-band exchange of a shared secret is feasible, is defined in RFC + 3118 [5]. Potential exposures to attack are discussed in section 7 + of the DHCP protocol specification in RFC 2131 [2]. + + The DHCP relay agent option depends on a trusted relationship between + the DHCP relay agent and the server, as described in section 5 of RFC + 3046. Fraudulent relay agent option data could potentially lead to + theft-of-service or exhaustion of limited resources (like IP + addresses) by unauthorized clients. A host that tampered with relay + agent data associated with another host's DHCP messages could deny + service to that host, or interfere with its operation by leading the + DHCP server to assign it inappropriate configuration parameters. + + While the introduction of fraudulent relay agent options can be + prevented by a perimeter defense that blocks these options unless the + relay agent is trusted, a deeper defense using authentication for + relay agent options via the Authentication Suboption [6] SHOULD be + deployed as well. + + There are several data in a DHCP message that convey information that + may identify an individual host on the network. These include the + chaddr, the client-id option, and the hostname and client-fqdn + options. Depending on the type of data included, the Vendor-Specific + suboption may also convey information that identifies a specific host + or a specific user on the network. In practice, this information + isn't exposed outside the internal service-provider network, where + DHCP messages are usually confined. Administrators who configure + data that will be used in DHCP Vendor-Specific suboptions should be + careful to use data that are appropriate for the types of networks + + + +Stapp, et al. Standards Track [Page 4] + +RFC 4243 Vendor-Specific Relay Suboption December 2005 + + + they administer. If DHCP messages travel outside the service- + provider's own network, or if the suboption values may become visible + to other users, it may raise privacy concerns for the access provider + or service provider. + +7. IANA Considerations + + The IANA has assigned the suboption number 9 for the Vendor-Specific + Information Suboption from the DHCP Relay Agent Information Option + [3] suboption number space. + +8. Acknowledgements + + The authors are grateful to Andy Sudduth, Josh Littlefield, and Kim + Kinnear for their review and comments. + +Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, + March 1997. + + [3] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, + January 2001. + + [4] IANA, "Private Enterprise Numbers (http://www.iana.org/ + assignments/enterprise-numbers.html)". + +Informative References + + [5] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", + RFC 3118, June 2001. + + [6] Stapp, M. and T. Lemon, "The Authentication Suboption for the + Dynamic Host Configuration Protocol (DHCP) Relay Agent Option", + RFC 4030, March 2005. + + [7] Littlefield, J., "Vendor-Identifying Vendor Options for Dynamic + Host Configuration Protocol version 4 (DHCPv4)", RFC 3925, + October 2004. + + + + + + + + + + + + + + + +Stapp, et al. Standards Track [Page 5] + +RFC 4243 Vendor-Specific Relay Suboption December 2005 + + +Authors' Addresses + + Mark Stapp + Cisco Systems, Inc. + 1414 Massachusetts Ave. + Boxborough, MA 01719 + USA + + Phone: 978.936.0000 + EMail: mjs@cisco.com + + + Richard Johnson + Cisco Systems, Inc. + 170 W. Tasman Dr. + San Jose, CA 95134 + USA + + Phone: 408.526.4000 + EMail: raj@cisco.com + + + Theyn Palaniappan + Cisco Systems, Inc. + 170 W. Tasman Dr. + San Jose, CA 95134 + USA + + Phone: 408.526.4000 + EMail: athenmoz@cisco.com + + + + + + + + + + + + + + + + + + + + + + + + + + + +Stapp, et al. Standards Track [Page 6] + +RFC 4243 Vendor-Specific Relay Suboption December 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM 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. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + +Stapp, et al. Standards Track [Page 7] + -- cgit v1.2.3