idnits 2.17.00 (12 Aug 2021) /tmp/idnits13240/draft-aboba-zeroconf-multi-00.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 227 has weird spacing: '... Option to D...' == Line 228 has weird spacing: '...uration in I...' == Line 292 has weird spacing: '...imed to perta...' == Line 335 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 (6 October 1999) is 8256 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '5' is defined on line 221, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 224, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 243, but no explicit reference was found in the text == Outdated reference: draft-ietf-dhc-authentication has been published as RFC 3118 ** Obsolete normative reference: RFC 2462 (ref. '6') (Obsoleted by RFC 4862) == Outdated reference: A later version (-05) exists of draft-ietf-dhc-ipv4-autoconfig-04 == Outdated reference: draft-ietf-nat-rsip-framework has been published as RFC 3102 -- Duplicate reference: RFC2462, mentioned in '12', was also mentioned in '6'. ** Obsolete normative reference: RFC 2462 (ref. '12') (Obsoleted by RFC 4862) Summary: 5 errors (**), 0 flaws (~~), 13 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NETWORK Working Group Bernard Aboba 2 INTERNET-DRAFT Microsoft 3 Category: Informational 4 5 6 October 1999 7 Auto-Addressing in Multi-segment Networks 9 This document is an Internet-Draft and is in full conformance with all 10 provisions of Section 10 of RFC2026. 12 Internet-Drafts are working documents of the Internet Engineering Task 13 Force (IETF), its areas, and its working groups. Note that other groups 14 may also distribute working documents as Internet-Drafts. Internet- 15 Drafts are draft documents valid for a maximum of six months and may be 16 updated, replaced, or obsoleted by other documents at any time. It is 17 inappropriate to use Internet-Drafts as reference material or to cite 18 them other than as "work in progress." 20 The list of current Internet-Drafts can be accessed at 21 http://www.ietf.org/ietf/1id-abstracts.txt 23 The list of Internet-Draft Shadow Directories can be accessed at 24 http://www.ietf.org/shadow.html. 26 The distribution of this memo is unlimited. It is filed as , and expires April 1, 2000. Please send 28 comments to the authors. 30 1. Copyright Notice 32 Copyright (C) The Internet Society (1999). All Rights Reserved. 34 2. Abstract 36 Today, with the rapid rise of home networking, there is an increasing 37 need for simplified mechanisms for IPv4 address allocation within multi- 38 segment networks connected by a single router. This issue can arise, for 39 example, in the case of a home network supporting 802.11 wireless as 40 well as Ethernet. 42 In multi-segment small networks connected by a single router, it may be 43 desirable to provide for consistent IPv4 addressing in the case where 44 the small network has not been assigned a routable IPv4 address prefix. 45 This draft describes how this problem may be solved through 46 implementation of a mini-DHCP server within the router. The router may 47 either be disconnected from the Internet, in which case the hosts on the 48 multiple segments will only be able to reach other, or the router may 49 offer Internet connectivity via Network Address Translation (NAT), or 50 another suitable mechanism, such as RSIP. 52 3. Introduction 54 Today, with the rapid rise of home networking, there is an increasing 55 need for simplified mechanisms for IPv4 address allocation within multi- 56 segment networks connected by a single router. This issue can arise, for 57 example, in the case of a home network supporting 802.11 wireless as 58 well as Ethernet. 60 In multi-segment small networks connected by a single router, it may be 61 desirable to provide for consistent IPv4 addressing in the case where 62 the small network has not been assigned a routable IPv4 address prefix. 63 This draft describes how this problem may be solved through 64 implementation of a mini-DHCP server within the router. The router may 65 either be disconnected from the Internet, in which case the hosts on the 66 multiple segments will only be able to reach other, or the router may 67 offer Internet connectivity via Network Address Translation (NAT), 68 described in [10], or another suitable mechanism, such as RSIP, 69 described in [11]. 71 3.1. Terminology 73 This document uses the following terms: 75 Site Administrator 76 A Site Administrator is the person or organization responsible 77 for handing out IP addresses to client machines. 79 DHCP client 80 A DHCP client or "client" is an Internet host using DHCP to 81 obtain configuration parameters such as a network address. 83 DHCP server 84 A DHCP server or "server" is an Internet host that returns 85 configuration parameters to DHCP clients. 87 3.2. Requirements language 89 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 90 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 91 described in [1]. 93 3.3. Configuration requirements for multi-segment networks 95 In order to enable effective IPv4 address allocation in multi-segment 96 networks connected by a single router, the following requirements need 97 to be met: 99 Multi-segment adressing consistency 100 It MUST be possible to consistently assign addresses within 101 multiple segments so as to avoid address conflicts either 102 within segments or between segments. This consistency MUST be 103 maintained in the event of addition or removal of segments, or 104 in the event of interfaces going up or down. 106 Auto-config to Non-auto-config transition 107 It MUST be possible to effectively transition a series of 108 segments auto-configured as described in [8], to a consistent 109 addressing scheme as described in this document. 111 4. Addressing scheme 113 In order to provide addressing consistency in multi-segment IPv4 114 networks connected to a single router, this document proposes addition 115 of a mini-DHCP server to the router. In order to ensure consistency of 116 addressing within the multiple segments, the mini-DHCP server MUST 117 automatically allocate /24 scopes out of the 192.168/16 prefix reserved 118 for private addressing, as described in [13], with a unique /24 prefix 119 allocated to each interface. Prefixes SHOULD be allocated from the 120 bottom of the range toward the top, starting with the 192.168.1/24 121 prefix. The router MUST NOT allocate the 192.168.0/24 or 192.168.255/24 122 prefixes, as these are reserved for future use. 124 Note that in order to handle the case of interfaces coming up or down, a 125 scope MUST be allocated to each interface, whether it is functioning or 126 not. This allows a non-functioning interface to subsequently become 127 functional and to support consistent addressing. In the case where an 128 interface is added, such as by plugging in an additional card, a new 129 scope SHOULD be allocated as soon as the interface is added. 131 In order to allow for consistent numbering between router and host 132 reboots, scope assignments and address allocations should be handled as 133 required by [3] with respect to use of stable storage. Scopes MUST NOT 134 be de-allocated on interface-down or interface removal, so as to remain 135 robust against short term configuration changes. 137 To enable reclaiming of scopes in the event of permanent removal of an 138 interface, scope allocations of non-existent interfaces should timeout 139 using with an interval of three times the DHCP lease time. For example, 140 if the DHCP lease time is set to 3 days, then a scope allocated to a 141 removed interface will timeout after 9 days. 143 4.1. Compatibility with existing DHCP servers 145 A mini-DHCP server MUST NOT be active on an interface if there is 146 already another DHCP server active on that interface. Thus if the 147 router's BOOTP relay agent has already been configured on an interface, 148 the mini-DHCP server MUST NOT be active on that interface. 150 In order to detect the presence of a DHCP server on interfaces that have 151 not been configured as BOOTP relay agents, a router running a mini-DHCP 152 server MUST send out periodic DHCPDISCOVER requests on each interface 153 with the should-I-autoconfig flag set. If the DHCPDISCOVER is responded 154 to (either with a DHCPOFFER or with a never-autoconfig response), the 155 router MUST NOT provide DHCP service on that interface. Similarly, if 156 the router running a mini-DHCP server hears a DHCPOFFER, DHCPACK or 157 DHCPNAK on an interface, then it MUST NOT provide DHCP service on that 158 interface. 160 Note that a mechanism is needed to allow the mini-DHCP server to be 161 brought up again once the other DHCP servers are removed. Once the 162 router has detected another DHCP server and has shut down its own mini- 163 DHCP server, it SHOULD set a timer. Once this timer expires, the router 164 MUST once again send out a DHCPDISCOVER and listen for responses. The 165 recommended timer interval is 5 minutes. 167 4.2. Compatibility with private address spaces 169 Today there are ISPs that use private address space internally in order 170 to manage network devices. Thus it is conceivable that a router will 171 receive routing protocol announcements for 192.168/16 on one of its 172 interfaces. Were the router to listen to these announcements, it is 173 conceivable that it could become confused about the routing topology. 175 Thus routers implementing this specification MUST filter out routing 176 announcements for the 192.168/16 prefix on all interfaces. 178 4.3. Transition from auto-config to non-auto-config 180 In order to allow a series of segments, each auto-configured within the 181 169.254/16 prefix as described in [8], to transition to a consistently 182 addressed state within the 192.168/16 prefix, the mini-DHCP server will 183 need to respond to the periodic DHCPDISCOVER messages sent by the auto- 184 configured hosts. In the response, the mini-DHCP server will utilize the 185 scope allocations described previously, and will also utilize the option 186 described in [7] in order to discourage hosts from subsequently 187 utilizing auto-configuration should a segment become temporarily 188 disconnected. 190 Note that the transition from individual auto-configured segments to a 191 consistently addressed multi-segment network may take some time. As 192 described in [8], auto-configured hosts continue to send out 193 DHCPDISCOVER messages in order to be able to reconfigure themselves in 194 the event of the addition of a DHCP server. The suggested default for 195 Ethernet implementations is to check every 5 minutes. 197 Thus it is conceivable that when the previously partitioned segments are 198 first connected, addressing conflicts may result. As noted in [8], 199 there is currently no way to address this issue without causing all 200 hosts involved to re-configure IP addresses. This will occur within the 201 default reconfiguration interval. 203 In order to lessen the transition time, it may be desirable to decrease 204 the reconfiguration interval. It also may be useful for nodes detecting 205 an address conflict to send out a DHCPDISCOVER so as to detect the 206 presence of a DHCP server more quickly, or to select another address 207 within the auto-config range after detection of a conflict. 209 5. References 211 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 212 Levels", BCP 14, RFC 2119, March 1997. 214 [2] Droms, R., Arbaugh, W., "Authentication for DHCP Messages", 215 Internet draft (work in progress), draft-ietf-dhc- 216 authentication-11.txt, June 1999. 218 [3] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 219 1997. 221 [5] Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor 222 Extensions", RFC 2132, March 1997. 224 [6] Thomson, S., Narten, T., "IPv6 Stateless Address 225 Autoconfiguration", RFC 2462, December 1998. 227 [7] Troll, R., "DHCP Option to Disable Stateless Auto- 228 Configuration in IPv4 Clients", RFC 2563, May 1999. 230 [8] Troll, R., "Automatically Choosing an IP Address in an Ad-Hoc 231 IPv4 Network", Internet draft (work in progress), draft-ietf-dhc- 232 ipv4-autoconfig-04.txt, April 1999. 234 [9] IEEE 802.11 specification. 236 [10] Srisuresh, P., Holdrege, M., "IP Network Address Translator (NAT) 237 Terminology and Considerations", RFC 2663, August 1999. 239 [11] Lo, J., Borella, M., Grabelsky, D., "Realm Specific IP: A 240 Framework", Internet draft (work in progress), draft-ietf-nat-rsip- 241 framework-01.txt, November 1999. 243 [12] Thomson, S. and Narten, T., "IPv6 Stateless Address 244 Autoconfiguration", RFC 2462, December 1998. 246 [13] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., Lear, 247 E., "Address Allocation for Private Internets", RFC 1918, February, 248 1996. 250 6. Security Considerations 252 DHCP, as noted in [2], is vulnerable to a number of threats, including 253 message modification and attacks by rogue servers and unauthenticated 254 clients. While the procedure described in this document does not 255 preclude implementation of DHCP authentication, the extra configuration 256 required to set this up represents an implementation barrier in the home 257 network. As a result, it is likely that most home routers will not 258 support DHCP authentication, and that those networks will remain 259 vulnerable to the attacks described in [2]. 261 These threats are most serious in wireless networks such as 802.11, 262 since attackers on a wired network will require physical access to the 263 home network, while wireless attackers may reside outside the home. In 264 order to provide for privacy equivalent to a wired network, the 802.11 265 specification provides for RC4-based encryption. This is known as the 266 "Wired Equivalency Privacy" (WEP) specification, described in [9]. Where 267 WEP is implemented, an attacker will need to obtain the WEP key prior to 268 gaining access to the home network. 270 7. IANA Considerations 272 This draft does not create any new number spaces for IANA 273 administration. 275 8. Acknowledgements 277 This draft has been enriched by comments from Ryan Troll of @Home and 278 Peter Ford and Yaron Goland of Microsoft. 280 9. Authors' Addresses 282 Bernard Aboba 283 Microsoft Corporation 284 One Microsoft Way 285 Redmond, WA 98052 287 Phone: +1 (425) 936-6605 288 EMail: bernarda@microsoft.com 289 10. Intellectual Property Statement 291 The IETF takes no position regarding the validity or scope of any 292 intellectual property or other rights that might be claimed to pertain 293 to the implementation or use of the technology described in this 294 document or the extent to which any license under such rights might or 295 might not be available; neither does it represent that it has made any 296 effort to identify any such rights. Information on the IETF's 297 procedures with respect to rights in standards-track and standards- 298 related documentation can be found in BCP-11. Copies of claims of 299 rights made available for publication and any assurances of licenses to 300 be made available, or the result of an attempt made to obtain a general 301 license or permission for the use of such proprietary rights by 302 implementors or users of this specification can be obtained from the 303 IETF Secretariat. 305 The IETF invites any interested party to bring to its attention any 306 copyrights, patents or patent applications, or other proprietary rights 307 which may cover technology that may be required to practice this 308 standard. Please address the information to the IETF Executive 309 Director. 311 11. Full Copyright Statement 313 Copyright (C) The Internet Society (1999). All Rights Reserved. 314 This document and translations of it may be copied and furnished to 315 others, and derivative works that comment on or otherwise explain it or 316 assist in its implmentation may be prepared, copied, published and 317 distributed, in whole or in part, without restriction of any kind, 318 provided that the above copyright notice and this paragraph are included 319 on all such copies and derivative works. However, this document itself 320 may not be modified in any way, such as by removing the copyright notice 321 or references to the Internet Society or other Internet organizations, 322 except as needed for the purpose of developing Internet standards in 323 which case the procedures for copyrights defined in the Internet 324 Standards process must be followed, or as required to translate it into 325 languages other than English. The limited permissions granted above are 326 perpetual and will not be revoked by the Internet Society or its 327 successors or assigns. This document and the information contained 328 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 329 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 330 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 331 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 332 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 333 12. Expiration Date 335 This memo is filed as , and expires 336 April 1, 2000.