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/rfc2563.txt | 507 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 507 insertions(+) create mode 100644 doc/rfc/rfc2563.txt (limited to 'doc/rfc/rfc2563.txt') diff --git a/doc/rfc/rfc2563.txt b/doc/rfc/rfc2563.txt new file mode 100644 index 0000000..f6de239 --- /dev/null +++ b/doc/rfc/rfc2563.txt @@ -0,0 +1,507 @@ + + + + + + +Network Working Group R. Troll +Request for Comments: 2563 @Home Network +Category: Standards Track May 1999 + + + DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients + +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 (1999). All Rights Reserved. + +Abstract + + Operating Systems are now attempting to support ad-hoc networks of + two or more systems, while keeping user configuration at a minimum. + To accommodate this, in the absence of a central configuration + mechanism (DHCP), some OS's are automatically choosing a link-local + IP address which will allow them to communicate only with other hosts + on the same link. This address will not allow the OS to communicate + with anything beyond a router. However, some sites depend on the + fact that a host with no DHCP response will have no IP address. This + document describes a mechanism by which DHCP servers are able to tell + clients that they do not have an IP address to offer, and that the + client should not generate an IP address it's own. + +1. Introduction + + With computers becoming a larger part of everyday life, operating + systems must be able to support a larger range of operating + environments. One aspect of this support is the selection of an IP + address. The Dynamic Host Configuration Protocol [DHCP] provides a + superb method by which site administrators may supply IP addresses + (and other network parameters) to network devices. However, some + operating environments are not centrally maintained, and operating + systems must now be able to handle this quickly and easily. + + IPv6 accounts for this, and allows an IPv6 stack to assign itself a + global address in the absence of any other mechanism for + configuration [IPv6SAC]. However, Operating System designers can't + wait for IPv6 support everywhere. They need to be able to assume + + + +Troll Standards Track [Page 1] + +RFC 2563 DHCP Auto-Configuration Option May 1999 + + + they will have IPv4 addresses, so that they may communicate with one + another even in the smallest networks. + + This document looks at three types of network nodes, and how IPv4 + address auto-configuration may be disabled on a per-subnet (or even + per-node) basis. The three types of network nodes are: + + * A node for which the site administrator will hand out configuration + information, + + * A node on a network segment for which there is no site + administrator, and + + * A node on a network segment that has a central site administrator, + and that administrator chooses not to hand out any configuration + information to the node. + + The difference between the second and third cases is the clients + behavior. + + In one case, the node may assign itself an IP address, and have full + connectivity with other nodes on the local wire. In the last case, + the node is not told what to do, and while it may assign itself a + network address in the same way as case #2, this may not be what the + central administrator wants. + + The first scenario is handled by the current DHCP standard. However, + the current DHCP specification [DHCP] says servers must silently + ignore requests from hosts they do not know. Because of this, DHCP + clients are unable to determine whether they are on a subnet with no + administration, or with administration that is choosing not to hand + out addresses. + + This document describes a method by which DHCP clients will be able + to determine whether or not the network is being centrally + administrated, allowing it to intelligently determine whether or not + it should assign itself a "link-local" address. + +1.1. Conventions Used in the 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 [KEYWORDS]. + + + + + + + + +Troll Standards Track [Page 2] + +RFC 2563 DHCP Auto-Configuration Option May 1999 + + +1.2. Terminology + + DHCP client A DHCP client is an Internet host using DHCP to obtain + configuration parameters such as a network address. + + DHCP server A DHCP server is an Internet host that returns + configuration parameters to DHCP clients. + +2. The Auto-Configure Option + + This option code is used to ask whether, and be notified if, auto- + configuration should be disabled on the local subnet. The auto- + configure option is an 8-bit number. + + Code Len Value + +-----+-----+-----+ + | 116 | 1 | a | + +-----+-----+-----+ + + The code for this option is 116, and its length is 1. + + This code, along with the IP address assignment, will allow a DHCP + client to determine whether or not it should generate a link-local IP + address. + +2.1. Auto-Configure Values + + The auto-configure option uses the following values: + + DoNotAutoConfigure 0 + AutoConfigure 1 + + When a server responds with the value "AutoConfigure", the client MAY + generate a link-local IP address if appropriate. However, if the + server responds with "DoNotAutoConfigure", the client MUST NOT + generate a link-local IP address, possibly leaving it with no IP + address. + +2.2. DHCP Client Behavior + + Clients that have auto-configuration capabilities MUST add the Auto- + Configure option to the list of options included in its initial + DHCPDISCOVER message. ([DHCP] Section 4.4.1) At this time, the + option's value should be set to "AutoConfigure". + + When a DHCPOFFER is received, it is handled as described in [DHCP], + section 4.4.1, with one exception. If the 'yiaddr' field is + 0x00000000, the Auto-Configure option must be consulted. If this + + + +Troll Standards Track [Page 3] + +RFC 2563 DHCP Auto-Configuration Option May 1999 + + + option is set to "AutoConfigure", then the DHCPOFFER MUST be ignored, + and the DHCP client MAY generate a link-local IP address. However, + if this option is set to "DoNotAutoConfigure", then the DHCPOFFER + MUST be ignored, and the client MUST NOT generate a link-local IP + address. + + If a DHCP client receives any DHCPOFFER which contains a 'yiaddr' of + 0x00000000, and the Auto-Configure flag says "DoNotAutoConfigure", in + the absence of a DHCPOFFER with a valid 'yiaddr', the DHCP client + MUST NOT generate a link-local IP address. The amount of time a DHCP + client waits to collect any other DHCPOFFERs is implementation + dependant. + + DHCPOFFERs with a 'yiaddr' of 0x00000000 will only be sent by DHCP + servers supporting the Auto-Configure option when the DHCPDISCOVER + contained the Auto-Configure option. Since the DHCPDISCOVER will + only contain the Auto-Configure option when a DHCP client knows how + to handle it, there will be no inter-operability problems. + + If the DHCP server does have an address to offer, the message states + are the same as those described in [DHCP], section 3. + + The following depicts the difference in responses for non-registered + DHCP clients that support the "Auto-Configure" option on networks + that have DHCP servers that support auto-configuration and networks + with DHCP servers that do not. + + + + + + + + + + + + + + + + + + + + + + + + + +Troll Standards Track [Page 4] + +RFC 2563 DHCP Auto-Configuration Option May 1999 + + + Network Client Network + (no auto-configure) (auto-configure) + + v v v + | | | + | Begins initialization | + | | | + | _____________/|\____________ | + |/DHCPDISCOVER | DHCPDISCOVER \| + | | | + Determines | Determines + configuration | configuration + | | | + | | ____________/| + | | /DHCPOFFER | + | |/ | + | | | + | Collects replies | + | | | + | Selects configuration | + | | | + |--AutoConfigs--|- NO IP ADDR --| + . . . + . . . + | | | + | Graceful shutdown | + | | | + | | | + v v v + + +2.3. DHCP Server Behavior + + When a DHCP server receives a DHCPDISCOVER, it MUST be processed as + described in [DHCP], section 4.3.1. However, if no address is chosen + for the host, a few additional steps MUST be taken. + + If the DHCPDISCOVER does not contain the Auto-Configure option, it is + not answered. + + If the DHCPDISCOVER contains the Auto-Configure option, and the site + administrator has specified that Auto-Configuration should be + disabled on the subnet the DHCPDISCOVER is originating from, or for + the client originating the request, then a DHCPOFFER MUST be sent to + the DHCP client. This offer MUST be for the address 0x00000000, and + the Auto-Configure option MUST be set to "DoNotAutoConfigure". + + + + + +Troll Standards Track [Page 5] + +RFC 2563 DHCP Auto-Configuration Option May 1999 + + + If the site administrator allows auto-configuration on the + originating subnet, the DHCPDISCOVER is not answered as before. + +2.4. Mixed Environments + + Environments containing a mixture of clients and servers that do and + do not support the Auto-Configure option will not be a problem. + Every DHCP transaction is between a Server and a Client, and the + possible mixed scenarios between these two are listed below. + +2.4.1. Client Supports, Server Does Not + + If a DHCP client sends a request that contains the Auto-Configure + tag, a DHCP server that does not know what this tag is will respond + normally. According to [DHCP] Section 4.3.1, the server MUST NOT + return a value for that parameter. + + In this case, the server will either respond with a valid DHCPOFFER, + or it will not respond at all. In both cases, a DHCP client that + supports this option will never care what the state of the option is, + and may auto-configure. + +2.4.2. Servers Supports, Client Does Not + + If the Auto-Configure option is not present in the DHCPDISCOVER, the + server will do nothing about it. The client will auto-configure if + it doesn't receive a response and believes that's what it should do. + + This scenario SHOULD not occur, as any stacks that implement an + auto-configuration mechanism MUST implement this option as well. + +2.5. Interaction With Other DHCP Messages + + As this option only affects the initial IP address selection, it does + not apply to subsequent DHCP messages. If the DHCP client received a + lease from a DHCP server, future DHCP messages (RENEW, INFORM, ACK, + etc.) have no need to fall over into an auto- configuration state. + + If the DHCP client's lease expires, the client falls back into the + INIT state, and the initial DHCPDISCOVER is sent as before. + +2.5.1. DHCPRELEASE Messages + + DHCPRELEASEs occur exactly as described in [DHCP], section 4.4.6. + When a DHCP client is done with a lease, it MAY notify the server + that it is finished. For this to occur, the DHCP client already + received a DHCP lease, and the state of Auto-Configuration on the + local wire does not matter. + + + +Troll Standards Track [Page 6] + +RFC 2563 DHCP Auto-Configuration Option May 1999 + + +2.5.2. DHCPDECLINE Messages + + A DHCPDECLINE is sent by the DHCP client when it determines the + network address it is attempting to use is already in use. As a + network address has been tested, it must have been offered by the + DHCP Server, and the state of Auto-Configuration on the local wire + does not matter. + +2.5.3. DHCPINFORM Messages + + DHCPINFORMs should be handled as described in [DHCP], section 4.4.3. + No changes are necessary. + +2.6. Message Option + + If the DHCP server would like to tell a client why it is not allowed + to auto-configure, it MAY add the Message option to the response. + This option is defined in [DHCPOPT], Section 9.9. + + If the DHCP client receives a response with the Message option set, + it MUST provide this information to the administrator of the DHCP + client. How this information is provided is implementation + dependant. + +3. Security Considerations + + DHCP per se currently provides no authentication or security + mechanisms. Potential exposures to attack are discussed in section 7 + of the DHCP protocol specification [DHCP]. + + This mechanism does add one other potential attack. Malicious users + on a subnet may respond to all DHCP requests with responses telling + DHCP clients that they should NOT auto-configure on the local wire. + On a network where Auto-Configuration is required, this will cause + all DHCP clients to not choose an address. + +4. Acknowledgments + + This idea started at a joint Common Solutions Group / Microsoft + meeting at Microsoft in May, 1998. The IP stacks in Win98 and NT5 + assign themselves an IP address (in a specific subnet) in the absence + of a responding DHCP server, and this is causing headaches for many + sites that actually rely on machines not getting IP addresses when + the DHCP servers do not know them. + + Walter Wong proposed a solution that would allow the DHCP servers to + tell clients not to do this. His initial solution would not work + without slight modifications to DHCP itself. This document describes + + + +Troll Standards Track [Page 7] + +RFC 2563 DHCP Auto-Configuration Option May 1999 + + + those modifications. + +5. IANA Considerations + + The IANA has assigned option number 116 for this option. + +6. References + + [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC + 2131, March 1997. + + [DHCPOPT] Alexander, S. and R. Droms, "DHCP Options and BOOTP + Vendor Extension", RFC 2132, March 1997. + + [IPv6SAC] Thomson, S. and T. Narten, "IPv6 Stateless Address + Autoconfiguration", RFC 2462, December 1998. + + [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + +7. Author's Address + + Ryan Troll + @Home Network + 425 Broadway + Redwood City, CA 94063 + + Phone: (650) 556-6031 + EMail: rtroll@corp.home.net + + + + + + + + + + + + + + + + + + + + + + +Troll Standards Track [Page 8] + +RFC 2563 DHCP Auto-Configuration Option May 1999 + + +8. Full Copyright Statement + + Copyright (C) The Internet Society (1999). 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. + + + + + + + + + + + + + + + + + + + +Troll Standards Track [Page 9] + -- cgit v1.2.3