idnits 2.17.00 (12 Aug 2021) /tmp/idnits25603/draft-aboba-dhc-mini-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 11 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 291 has weird spacing: '...sue can arise...' == Line 451 has weird spacing: '...imed to perta...' == Line 495 has weird spacing: '...>, and expir...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (29 September 2001) is 7532 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '7' is defined on line 361, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 364, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 367, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 377, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 383, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 386, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 389, but no explicit reference was found in the text == Outdated reference: draft-ietf-dhc-ddns-resolution has been published as RFC 4703 == Outdated reference: draft-ietf-dhc-fqdn-option has been published as RFC 4702 ** Obsolete normative reference: RFC 2462 (ref. '7') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2535 (ref. '16') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) == Outdated reference: draft-ietf-dnsext-mdns has been published as RFC 4795 == Outdated reference: A later version (-04) exists of draft-akinlar-zeroconf-minidhcp-option-00 Summary: 6 errors (**), 0 flaws (~~), 19 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETWORK Working Group Bernard Aboba 3 INTERNET-DRAFT Microsoft 4 Category: Informational 5 6 29 September 2001 8 The Mini-DHCP Server 10 This document is an Internet-Draft and is in full conformance with all 11 provisions of Section 10 of RFC 2026. 13 Internet-Drafts are working documents of the Internet Engineering Task 14 Force (IETF), its areas, and its working groups. Note that other groups 15 may also distribute working documents as Internet-Drafts. Internet- 16 Drafts are draft documents valid for a maximum of six months and may be 17 updated, replaced, or obsoleted by other documents at any time. It is 18 inappropriate to use Internet-Drafts as reference material or to cite 19 them other than as "work in progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt. 24 To view the list Internet-Draft Shadow Directories, see 25 http://www.ietf.org/shadow.html. 27 Copyright Notice 29 Copyright (C) The Internet Society (2001). All Rights Reserved. 31 Abstract 33 Today, with the rapid rise of home networking, there is a need for 34 simple mechanisms of IPv4 address allocation and name resolution. This 35 document describes the behavior of the mini-DHCP server, a small scale 36 DHCP server that is typically implemented as part of a home gateway. 38 As described in this document, the mini-DHCP server is capable of 39 allocating addresses either in single or multi-segment networks. It 40 supports dynamic DNS, and is capable of automatically detecting the 41 presence of a full-fledged DHCP server, or other mini-DHCP servers, and 42 shutting down as required. 44 Table of Contents 46 1. Introduction .......................................... 3 47 1.1 Terminology ..................................... 3 48 1.2 Requirements language ........................... 3 49 2. Overview .............................................. 4 50 2.1 Resilience ...................................... 4 51 2.2 Dynamic DNS support ............................. 4 52 2.3 Compatibility with existing DHCP servers ........ 4 53 2.4 Bridged networks ................................ 5 54 3. Addressing ............................................ 6 55 3.1 Address allocation .............................. 6 56 3.2 Address selection ............................... 7 57 3.3 Multi-segment address allocation ................ 7 58 4. References ............................................ 9 59 5. Security considerations ............................... 10 60 6. IANA considerations ................................... 10 61 Acknowledgments .............................................. 11 62 Author's addresses ........................................... 11 63 Intellectual Property Statement .............................. 11 64 Full Copyright Statement ..................................... 11 65 1. Introduction 67 Today, home gateways frequently include functionality beyond that of a 68 router, as defined in RFC 1812 [10]. For example, home gateways 69 frequently support Network Address Translation (NAT), described in 70 [8]-[10], as well as acting as a DHCP server as described in RFC 2131 71 [3], and a DNS server as described in [13]. These small scale DHCP and 72 DNS servers will be described as "mini-DHCP" and "mini-DNS" servers 73 within this document. 75 While initial offerings were relatively simple devices, today's home 76 gateways are increasingly sophisticated. For example, home gateways may 77 include support for multiple Internet or home interfaces, including 78 support for both 802.11 wireless [18], and wired networks. This implies 79 that the mini-DHCP server may need to allocate addresses on multiple 80 segments, instead of just one. 82 In some cases, multiple home gateways may exist within the home, or a 83 home gateway may be brought into an enterprise environment, causing 84 potential conflicts between the mini-DHCP server and an existing DHCP 85 server. 87 The purpose of this document is to provide guidance on how a mini-DHCP 88 server can behave so as to minimize the potential for conflict, and 89 maximize the services provided to users of the home network. 91 1.1. Terminology 93 This document uses the following terms: 95 Site Administrator 96 A Site Administrator is the person or organization responsible 97 for handing out IP addresses to client machines. 99 DHCP client 100 A DHCP client or "client" is an Internet host using DHCP to 101 obtain configuration parameters such as a network address. 103 DHCP server 104 A DHCP server or "server" is an Internet host that returns 105 configuration parameters to DHCP clients. 107 1.2. Requirements language 109 In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", 110 "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as 111 described in [1]. 113 2. Overview 115 The mini-DHCP server provides DHCP server functionality, as described in 116 RFC 2131 [3], allocating IP addresses as well as providing for host 117 configuration. Among the host configuration information typically 118 provided by the mini-DHCP server is the address of the residential 119 gateway as well as the address of the mini-DNS server. 121 2.1. Resilience 123 Since the mini-DHCP server will typically reside on a residential 124 gateway along with a mini-DNS server, it will typically provide its own 125 address in the default gateway and DNS server options, described in RFC 126 2132 [4]. However, in order to provide additional resilience, the 127 residential gateway can provide the addresses of secondary servers as 128 well. For example, the residential gateway can obtain the addresses of 129 additional gateways (learned by listening to routing protocol 130 announcements on the home network interfaces) or DNS servers (learned 131 via PPP IPCP extensions [19] or DHCP [3] on the Internet interface). In 132 the event that the home gateway is brought down (such as by a virus 133 attack), this additional configuration information can enable hosts to 134 continue accessing the Internet until the problem is resolved. 136 2.2. Dynamic DNS support 138 The mini-DHCP server SHOULD support the functionality described in 139 "Resolution of DNS Name Conflicts Among DHCP Clients" [5], enabling 140 dynamic registration of the PTR and (if configured to do so) A records 141 for the hosts to whom it allocates addresses. Mini-DNS servers typically 142 do not support dynamic DNS update, so that the mini-DHCP server will 143 typically register both A and PTR records. The host provides its fully 144 qualified domain names to the mini-DHCP server via the DHCP Client FQDN 145 option, described in [6]. 147 This allows the mini-DNS server to resolve DNS queries relating to hosts 148 on the internal network. Queries relating to Internet hosts are handled 149 by proxying the DNS query to the DNS server configured on the external 150 interface. This functionality is important, since multicast DNS, defined 151 in [17], is disabled by default when a DHCP server is available on the 152 network, and provides DNS server configuration. Thus, multicast DNS 153 cannot be relied upon to provide for name resolution in situations where 154 a mini-DHCP server is present. 156 2.3. Compatibility with existing DHCP servers 158 In order to avoid conflicts with full-fledged DHCP servers, or other 159 mini-DHCP servers, it is necessary for the mini-DHCP server to 160 automatically determine whether it should be operating on an interface. 162 A mini-DHCP server MUST NOT be active on an interface if there is 163 already a DHCP server active on that interface. Thus if the home 164 gateway's BOOTP relay agent has already been configured on an interface, 165 the mini-DHCP server MUST NOT be active on that interface. 167 In order to detect the presence of a DHCP server on interfaces that have 168 not been configured as BOOTP relay agents, a mini-DHCP server MUST 169 operate in promiscuous mode and send out periodic DHCPDISCOVER requests. 170 If a response is received, the mini-DHCP server MUST NOT provide DHCP 171 service on that interface. Similarly, if the mini-DHCP server hears a 172 DHCPOFFER, DHCPACK or DHCPNAK on an interface, then it MUST NOT provide 173 DHCP service on that interface. 175 In the case where there is more than one mini-DHCP server active on a 176 segment, it is possible that the mini-DHCP servers will send 177 DHCPDISCOVER queries simultaneously, and thus without an election 178 mechanism, all of them might be shut down on an interface. As a result, 179 it is desirable to provide a deterministic method for deciding which 180 mini-DHCP servers shut down. As described in [20], the mini-DHCP 181 election option can be utilized for this purpose. 183 Note that a mechanism is needed to allow the mini-DHCP server to be 184 brought up again once the other DHCP servers are removed. Once the 185 mini-DHCP server has detected another DHCP server and has stopped 186 offering service on an interface, it SHOULD set a timer. Once this timer 187 expires, the mini-DHCP server MUST once again send out a DHCPDISCOVER 188 and listen for responses. The recommended timer interval is 5 minutes. 190 Note that if one or more DHCP servers are found on other interfaces, it 191 may not be desirable to run a mini-DHCP server on those interfaces 192 lacking a DHCP server. Instead, it may make more sense to operate those 193 interfaces in bridging mode as discussed in the next section. 195 2.4. Bridged networks 197 Today mini-DHCP servers are typically included as part of home gateways 198 supporting Network Address Translation. However, the mini-DHCP server 199 can also improve ease of use in situations where routable address space 200 is available. 202 For example, the home gateway may be connected to an Intranet via a VPN, 203 or it may be attached via a dialup or broadband connection to an ISP 204 that operates its own DHCP server providing routable address space to 205 customers with attached LANs. 207 In these situations, it is possible for hosts on the home network to 208 obtain routable addresses from the ISP or Intranet DHCP server. Rather 209 than acting as a mini-DHCP server and doing Network Address Translation, 210 the home gateway can act as a bridge. In this role the home gateway 211 forwards DHCPDISCOVER broadcasts down the link, but does not act as a a 212 BOOTP relay agent. 214 In order to enable automated detection of bridged versus NATed 215 operation, on bootup, the home gateway obtains an IP address on its 216 external interface and then sends a DHCPDISCOVER on that interface. If 217 the external interface is a LAN link, and the original address was 218 obtained via DHCP, then a different client-identifier option must be 219 used in the subsequent DHCPDISCOVER. If the external interface is a PPP 220 link, then the home gateway an use the hardware address of its LAN 221 interface in the htype and chaddr fields. 223 On receiving one or more DHCPOFFERS, the home gateway configures itself 224 in bridging mode, and does not start the mini-DHCP or BOOTP relay 225 service on the external interface. It should be noted that in order to 226 properly route packets back to the attached home LANs, the upstream 227 router needs to keep track of the IP addresses assigned to the customer 228 hosts, and plumb corresponding static host routes on its interfaces. 230 Since ISPs operating in bridging mode typically do not provide unlimited 231 addresses, it is possible that the upstream DHCP server may stop 232 responding after a certain number of addresses have been allocated. In 233 this case it may be desirable for the home gateway to be able to act as 234 a bridge for those hosts that have obtained routable addresses, and a 235 router and mini-DHCP server for those hosts that are not able to do so. 236 However, doing this is tricky because it implies that two address 237 prefixes will co-exist on the home network segment. The home gateway 238 will need to act as a brouter, bridging traffic from the routable 239 addresses, while NAT'ing traffic from the private addresses allocated by 240 the mini-DHCP server. The home gateway will also need to forward traffic 241 from one prefix to the other on the home segment. 243 3. Addressing 245 3.1. Address allocation 247 By default, the mini-DHCP server configures itself to serve addresses 248 out of the 192.168/16 scope with /24 prefixes allocated to each 249 interface. 251 There are ISPs that use private address space internally in order to 252 manage network devices. Thus it is conceivable that a home gateway will 253 receive routing protocol announcements for a subnet of 192.168/16 on one 254 of its interfaces. Were the home gateway to listen to these 255 announcements, it is conceivable that it could become confused about the 256 routing topology. 258 Thus home gateways implementing this specification MUST filter out 259 routing announcements for the 192.168/16 prefix on the Internet-facing 260 interface. 262 3.2. Address selection 264 Since DHCP servers typically use static addresses, it is desirable for 265 the mini-DHCP server to have its IP addresses be per persistent between 266 reboots. In order to choose an IP address on each interface, the mini- 267 DHCP server will operate as follows: 269 [a] The mini-DHCP server will initially claim the .1 address on each 270 interface (e.g. 192.168.1.1, 192.168.2.1, etc.), and then will 271 attempt to determine whether the address is already allocated. This 272 is accomplished by ARPing for the claimed address. If there is no 273 response to the ARP, the mini-DHCP server will utilize the claimed 274 address. 276 [b] If the initially claimed address is taken, then the mini-DHCP 277 server will derive the host portion of the address on each 278 interface from the interface MAC address, and will claim and defend 279 that address. The formula for the computation of the host portion 280 of the IPv4 address is as follows: 282 host address = (0x'FFFF' XOR netmask) && (CRC32 (MACAddr | 283 hostname | interface-name )) 285 [c] If both the initially chosen address and the computed address are 286 taken, then the mini-DHCP server will choose a random address. 288 3.3. Multi-segment address allocation 290 It is possible for home networks to include multiple segments. This 291 issue can arise, for example, in the case of a home network supporting 292 802.11 wireless as well as IEEE 1394 and Ethernet. 294 In multi-segment small networks connected by a single router, it may be 295 desirable to provide for consistent IPv4 addressing in the case where 296 the small network has not been assigned a routable IPv4 address prefix. 297 The router may either be disconnected from the Internet, in which case 298 the hosts on the multiple segments will only be able to reach other, or 299 the router may offer Internet connectivity via Network Address 300 Translation (NAT), described in [8]-[10]. 302 In order to enable effective IPv4 address allocation in multi-segment 303 networks connected by a single router it MUST be possible to 304 consistently assign addresses within multiple segments. Consistent 305 addressing implies avoidance of address conflicts either within segments 306 or between segments. This consistency MUST be maintained in the event of 307 addition or removal of segments, or in the event of interfaces going up 308 or down. 310 In order to ensure consistency of addressing within multiple segments 311 connected to a single router, the mini-DHCP server MUST automatically 312 allocate /24 scopes out of the 192.168/16 prefix reserved for private 313 addressing, as described in [11], with a unique /24 prefix allocated to 314 each interface. Prefixes SHOULD be allocated from the bottom of the 315 range toward the top, starting with the 192.168.1/24 prefix. The router 316 MUST NOT allocate the 192.168.0/24 or 192.168.255/24 prefixes, as these 317 are reserved for future use. 319 Note that in order to handle the case of interfaces coming up or down, a 320 scope MUST be allocated to each interface, whether it is functioning or 321 not. This allows a non-functioning interface to subsequently become 322 functional and to support consistent addressing. In the case where an 323 interface is added, such as by plugging in an additional card, a new 324 scope SHOULD be allocated as soon as the interface is added. 326 In order to allow for consistent numbering between router and host 327 reboots, scope assignments and address allocations should be handled as 328 required by RFC 2131 [3] with respect to use of stable storage. Scopes 329 MUST NOT be de-allocated on interface-down or interface removal, so as 330 to remain robust against short term configuration changes. 332 To enable reclaiming of scopes in the event of permanent removal of an 333 interface, scope allocations of non-existent interfaces should timeout 334 using with an interval of three times the DHCP lease time. For example, 335 if the DHCP lease time is set to 3 days, then a scope allocated to a 336 removed interface will timeout (using an interval of three times) after 337 9 days. 339 4. References 341 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 342 Levels", BCP 14, RFC 2119, March 1997. 344 [2] Droms, R., Arbaugh, W., "Authentication for DHCP Messages", RFC 345 3118, June 2001. July 2000. 347 [3] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 348 1997. 350 [4] Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor 351 Extensions", RFC 2132, March 1997. 353 [5] Stapp, M., "Resolution of DNS Name Conflicts Among DHCP Clients", 354 Internet draft (work in progress), draft-ietf-dhc-ddns- 355 resolution-02.txt, July 2001. 357 [6] Stapp, M., Rekhter, Y., "The DHCP Client FQDN Option", Internet 358 draft (work in progress), draft-ietf-dhc-fqdn-option-02.txt, July 359 2001. 361 [7] Thomson, S., Narten, T., "IPv6 Stateless Address 362 Autoconfiguration", RFC 2462, December 1998. 364 [8] Srisuresh, P., Holdrege, M., "IP Network Address Translator (NAT) 365 Terminology and Considerations", RFC 2663, August 1999. 367 [9] Srisuresh, P., Egevang, K., "Traditional IP Network Address 368 Translator (Traditional NAT)", RFC 3022, January 2001. 370 [10] Holdrege, M., Srisuresh, P., "Protocol Complications with the IP 371 Network Address Translator", RFC 3027, January 2001. 373 [11] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., Lear, 374 E., "Address Allocation for Private Internets", RFC 1918, February, 375 1996. 377 [12] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 378 1995. 380 [13] Mockapetris, P., "Domain Names - Implementation and Specification", 381 RFC 1035, November 1987. 383 [14] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC 384 1034, November, 1987. 386 [15] Vixie, P., Thomson, S., Rekhter, Y., Bound, J., "Dynamic Updates in 387 the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. 389 [16] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, 390 March 1999. 392 [17] Esibov, L., Aboba., B., Thaler, D., "Multicast DNS", Internet draft 393 (work in progress), draft-ietf-dnsext-mdns-07.txt, October 2001. 395 [18] Information technology - Telecommunications and information 396 exchange between systems - Local and metropolitan area networks - 397 Specific Requirements Part 11: Wireless LAN Medium Access Control 398 (MAC) and Physical Layer (PHY) Specifications, IEEE Std. 399 802.11-1997, 1997. 401 [19] Cobb, S., "PPP Internet Protocol Control Protocol Extensions for 402 Name Server Addresses", RFC 1877, December 1995. 404 [20] Akinlar, C., Braun, D., Mukherjee, S., "Mini-DHCP Election Option 405 For DHCP", Internet draft (work in progress), draft-akinlar- 406 zeroconf-minidhcp-option-00.txt, March 2000. 408 5. Security Considerations 410 As noted in [2], DHCP is vulnerable to a number of threats, including 411 message modification and attacks by rogue servers and unauthenticated 412 clients. While the procedure described in this document does not 413 preclude implementation of DHCP authentication, the extra configuration 414 required to set this up represents an implementation barrier in the home 415 network. As a result, it is likely that most home routers will not 416 support DHCP authentication, and that those networks will remain 417 vulnerable to the attacks described in [2]. 419 These threats are most serious in wireless networks such as 802.11, 420 since attackers on a wired network will require physical access to the 421 home network, while wireless attackers may reside outside the home. In 422 order to provide for privacy equivalent to a wired network, the 802.11 423 specification provides for RC4-based encryption. This is known as the 424 "Wired Equivalency Privacy" (WEP) specification, described in [18]. 425 Where WEP is implemented, an attacker will need to obtain the WEP key 426 prior to gaining access to the home network. 428 6. IANA Considerations 430 This draft does not create any new number spaces for IANA 431 administration. 433 Acknowledgments 435 This draft has been enriched by comments from Ryan Troll of @Home and 436 Peter Ford and Yaron Goland of Microsoft. 438 Authors' Addresses 440 Bernard Aboba 441 Microsoft Corporation 442 One Microsoft Way 443 Redmond, WA 98052 445 Phone: +1 (425) 936-6605 446 EMail: bernarda@microsoft.com 448 Intellectual Property Statement 450 The IETF takes no position regarding the validity or scope of any 451 intellectual property or other rights that might be claimed to pertain 452 to the implementation or use of the technology described in this 453 document or the extent to which any license under such rights might or 454 might not be available; neither does it represent that it has made any 455 effort to identify any such rights. Information on the IETF's 456 procedures with respect to rights in standards-track and standards- 457 related documentation can be found in BCP-11. Copies of claims of 458 rights made available for publication and any assurances of licenses to 459 be made available, or the result of an attempt made to obtain a general 460 license or permission for the use of such proprietary rights by 461 implementors or users of this specification can be obtained from the 462 IETF Secretariat. 464 The IETF invites any interested party to bring to its attention any 465 copyrights, patents or patent applications, or other proprietary rights 466 which may cover technology that may be required to practice this 467 standard. Please address the information to the IETF Executive 468 Director. 470 Full Copyright Statement 472 Copyright (C) The Internet Society (2001). All Rights Reserved. 473 This document and translations of it may be copied and furnished to 474 others, and derivative works that comment on or otherwise explain it or 475 assist in its implementation may be prepared, copied, published and 476 distributed, in whole or in part, without restriction of any kind, 477 provided that the above copyright notice and this paragraph are included 478 on all such copies and derivative works. However, this document itself 479 may not be modified in any way, such as by removing the copyright notice 480 or references to the Internet Society or other Internet organizations, 481 except as needed for the purpose of developing Internet standards in 482 which case the procedures for copyrights defined in the Internet 483 Standards process must be followed, or as required to translate it into 484 languages other than English. The limited permissions granted above are 485 perpetual and will not be revoked by the Internet Society or its 486 successors or assigns. This document and the information contained 487 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 488 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 489 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 490 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 491 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 493 Expiration Date 495 This memo is filed as , and expires April 496 15, 2002.