idnits 2.17.1 draft-ietf-dhc-dna-ipv4-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 496. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 473. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 480. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 486. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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 (23 September 2005) is 6789 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 168 -- Looks like a reference, but probably isn't: '2' on line 170 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC Working Group Bernard Aboba 3 INTERNET-DRAFT Microsoft Corporation 4 Category: Proposed Standard 5 6 23 September 2005 8 Detecting Network Attachment (DNA) in IPv4 10 By submitting this Internet-Draft, each author represents that any 11 applicable patent or other IPR claims of which he or she is aware 12 have been or will be disclosed, and any of which he or she becomes 13 aware will be disclosed, in accordance with Section 6 of BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on April 10, 2006. 33 Copyright Notice 35 Copyright (C) The Internet Society 2005. 37 Abstract 39 The time required to detect movement between networks, and to obtain 40 (or continue to use) an IPv4 configuration may be significant as a 41 fraction of the total handover latency in moving between points of 42 attachment. This document synthesizes from experience in the 43 deployment of hosts supporting ARP, DHCP, and IPv4 Link-Local 44 addresses a set of steps known as Detecting Network Attachment for 45 IPv4 (DNAv4), in order to decrease the handover latency in moving 46 between points of attachment. 48 Table of Contents 50 1. Introduction.............................................. 3 51 1.1 Requirements .................................... 3 52 1.2 Terminology ..................................... 3 53 2. Overview ................................................. 4 54 2.1 Reachability Test ............................... 5 55 2.2 IPv4 Address Acquisition ........................ 7 56 2.3 IPv4 Link-Local Addresses ....................... 8 57 3. Constants ................................................ 9 58 4. IANA Considerations ...................................... 9 59 5. Security Considerations .................................. 9 60 6. References ............................................... 10 61 6.1 Normative references ............................ 10 62 6.2 Informative references .......................... 10 63 Acknowledgments .............................................. 10 64 Authors' Addresses ........................................... 11 65 Intellectual Property Statement .............................. 11 66 Disclaimer of Validity ....................................... 11 67 Copyright Statement .......................................... 12 68 1. Introduction 70 The time required to detect movement between networks and to obtain 71 (or continue to use) an operable IPv4 configuration may be 72 significant as a fraction of the total handover latency in moving 73 between points of attachment. 75 This document synthesizes from experience in the deployment of hosts 76 supporting ARP [RFC826], DHCP [RFC2131], and IPv4 Link-Local 77 addresses [RFC3927] a set of steps known as Detecting Network 78 Attachment for IPv4 (DNAv4). DNAv4 optimizes the (common) case of 79 reattachment to a network that one has been connected to previously 80 by attempting to re-use a previous (but still valid) configuration, 81 reducing the reattachment time to a few milliseconds on LANs. Since 82 this procedure is dependent on the ARP protocol, it is not suitable 83 for use on media that do not support ARP. 85 1.1. Requirements 87 In this document, several words are used to signify the requirements 88 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 89 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 90 and "OPTIONAL" in this document are to be interpreted as described in 91 [RFC2119]. 93 1.2. Terminology 95 This document uses the following terms: 97 ar$sha 98 ARP packet field: Sender Hardware Address [RFC826]. The hardware 99 (MAC) address of the originator of an ARP packet. 101 ar$spa 102 ARP packet field: Sender Protocol Address [RFC826]. For IP Address 103 Resolution this is the IPv4 address of the sender of the ARP 104 packet. 106 ar$tha 107 ARP packet field: Target Hardware Address [RFC826]. The hardware 108 (MAC) address of the target of an ARP packet. 110 ar$tpa 111 ARP packet field: Target Protocol Address [RFC826]. For IPv4 112 Address Resolution, the IPv4 address for which one desires to know 113 the hardware address. 115 DHCP client 116 A DHCP client or "client" is an Internet host using the Dynamic 117 Host Configuration protocol (DHCP) [RFC2131] to obtain 118 configuration parameters such as a network address. 120 DHCP server 121 A DHCP server or "server" is an Internet host that returns 122 configuration parameters to DHCP clients. 124 Link A communication facility or medium over which network nodes can 125 communicate. Each link is associated with a minimum of two 126 endpoints. Each link endpoint has a unique link-layer identifier. 128 Link Down 129 An event provided by the link layer that signifies a state change 130 associated with the interface no longer being capable of 131 communicating data frames; transient periods of high frame loss are 132 not sufficient. DNAv4 does not utilize "Link Down" indications. 134 Link Layer 135 Conceptual layer of control or processing logic that is responsible 136 for maintaining control of the data link. The data link layer 137 functions provide an interface between the higher-layer logic and 138 the data link. The link layer is the layer immediately below IP. 140 Link Up 141 An event provided by the link layer that signifies a state change 142 associated with the interface becoming capable of communicating 143 data frames. 145 Point of Attachment 146 The link endpoint on the link to which the host is currently 147 connected. 149 Routable address 150 In this specification, the term "routable address" refers to any 151 IPv4 address other than an IPv4 Link-Local address. This includes 152 private addresses as specified in [RFC1918]. 154 Operable address 155 In this specification, the term "operable address" refers to either 156 a static IPv4 address, or an address assigned via DHCPv4 which has 157 not been relinquished, and whose lease has not yet expired. 159 2. Overview 161 On connecting to a new point of attachment, the host responds to a 162 "Link Up" indication from the link layer by carrying out the DNAv4 163 procedure. 165 For each network that it connects to, it is assumed that the host 166 saves to stable storage the following parameters: 168 [1] The IPv4 and MAC address of the default gateway(s) 170 [2] The IPv4 configuration parameters, including 171 the assigned address and lease expiration time 173 From the set of networks which have operable IPv4 address(es) 174 associated with them, the host selects a subset, and attempts to 175 confirm the configuration for each network, using the reachability 176 test described in Section 2.1. 178 If the reachability test is successful, verifying bi-directional 179 connectivity to the default gateway(s), the host SHOULD continue to 180 use the operable routable IPv4 address associated with the confirmed 181 network, without needing to re-acquire it, allowing the host to 182 bypass Duplicate Address Detection (DAD). 184 If a DHCPv4 client is operational, it is RECOMMENDED that the host 185 attempt to obtain IPv4 configuration via DHCPv4 in parallel with the 186 reachability tests, with the host using the first answer returned. 187 This ensures that the DNAv4 procedure will not result in additional 188 delay in the case where reachability test(s) fail, or where sending a 189 DHCPREQUEST from the INIT-REBOOT state, as described in [RFC2131] 190 Section 3.2 and 4.3.2 completes more quickly than the reachability 191 test(s). 193 DNAv4 does not increase the likelihood of an address conflict. The 194 reachability test is only carried out for a network when the host has 195 previously completed duplicate address detection and obtained an 196 operable IPv4 configuration on that network. Restrictions on sending 197 ARP Requests and Responses are described in Section 2.1.1. 199 2.1. Reachability Test 201 The host skips the reachability test for a network if any of the 202 following conditions are true: 204 [a] The host does not have an operable routable IPv4 205 address on that network. In this case, the reachability 206 test cannot confirm that the host has an operable 207 routable IPv4 address, so completing the 208 reachability test would serve no purpose. 209 A host MUST NOT use the reachability test to 210 confirm configuration of an IPv4 Link-Local 211 address or a statically assigned IPv4 address. 213 [b] The host does not know the default gateway(s) on 214 that network. In this case, insufficient information 215 is available to carry out the reachability test. 217 [c] If secure detection of network attachment is required. 218 The reachability test utilizes ARP which is insecure. 220 For a particular network, the host MAY test reachability to the 221 primary default gateway, or it MAY test reachability to both the 222 primary and secondary default gateways, in series or in parallel. In 223 order to ensure configuration validity, the host SHOULD only 224 configure default gateway(s) which pass the reachability test. 226 In situations where more than one network is available on a given 227 link, or the network configuration has changed, it is possible for 228 the host to confirm more than one configuration. For example, it is 229 possible that one or more reachability test(s) succeed, and in 230 addition, configuration is provided via DHCPv4. In this case, a 231 DNAv4 implementation SHOULD prefer the configuration provided via 232 DHCPv4. 234 2.1.1. Packet Format 236 The reachability test is performed by sending an ARP Request. The 237 host MUST set the target protocol address (ar$tpa) to the IPv4 238 address of the default gateway being tested, and the sender protocol 239 address field (ar$spa) to its own IPv4 address. The ARP Request MUST 240 use the host MAC address as the source, and the default gateway MAC 241 address as the destination. The host includes its MAC address in the 242 sender hardware address field (ar$sha), and sets the target hardware 243 address field (ar$tha) to 0. 245 If a valid ARP Reply is received, the MAC address in the sender 246 hardware address field (ar$sha) in the ARP Reply is matched against 247 the target hardware address field (ar$tpa) in the ARP Request, and 248 the IPv4 address in the sender protocol address field (ar$spa) of the 249 ARP Reply is matched against the target protocol address field 250 (ar$tpa) in the ARP Request. If a match is found, then the host 251 continues to use that IPv4 address, subject to the lease re- 252 acquisition and expiration behavior described in [RFC2131], Section 253 4.4.5. 255 The risk of an address conflict is greatest when the host moves 256 between private networks, since in this case the completion of 257 Duplicate Address Detection on the former network does not provide 258 assurance against an address conflict on the new network. Until a 259 host with a private address has confirmed the operability of its IPv4 260 configuration, it SHOULD NOT respond to ARP Requests, and SHOULD NOT 261 broadcast ARP Requests containing its address within the sender 262 protocol address field (ar$spa). However, where the host has an 263 operable routable non-private address on a network, it MAY send ARP 264 Requests using its address within the sender protocol address field 265 (ar$spa) prior to confirming its IPv4 configuration, and MAY respond 266 to ARP Requests. 268 Sending an ICMP Echo Request [RFC792] to the default gateway IPv4 269 address does not provide the same level of assurance since this may 270 require an ARP Request/Reply exchange. Where the host has moved 271 between two private networks, this could result in ARP cache 272 pollution. 274 Where a host moves from one private network to another, an ICMP Echo 275 Request can result in an ICMP Echo Response even when the default 276 gateway has changed, as long as the IPv4 address remains the same. 277 This can occur, for example, where a host moves from one home 278 network using prefix 192.168/16 to another one. In addition, if the 279 ping is sent with TTL > 1, then an ICMP Echo Response can be received 280 from an off-link gateway. As a result, if the MAC address of the 281 default gateway is not checked, the host can mistakenly confirm 282 attachment, potentially resulting in an address conflict. As a 283 result, sending of an ICMP Echo Request SHOULD NOT be used as a 284 substitute for the reachability test. 286 In order to prevent synchronization, ARP Requests are delayed by a 287 random interval uniformly distributed on 0 to JITTER_INTERVAL. If 288 the initial ARP Request does not elicit a response, the host waits 289 for REACHABILITY_TIMEOUT. The timeout value is doubled with each 290 retransmission. It is RECOMMENDED that a host retransmit no more 291 than twice. To provide damping in the case of spurious "Link Up" 292 indications, it is recommended that the DNAv4 procedure be carried 293 out no more than once a second. 295 2.2. IPv4 Address Acquisition 297 If the host has an operable routable IPv4 address on one or more 298 networks, and DHCPv4 is enabled on the interface, the host SHOULD 299 attempt to acquire an IPv4 configuration using DHCPv4, in parallel 300 with one or more reachability tests. This is accomplished by 301 entering the INIT-REBOOT state, and sending a DHCPREQUEST to the 302 broadcast address as specified in [RFC2131] Section 4.4.2. 304 If the host does not have an operable routable IPv4 address on any 305 network, the host enters the INIT state and sends a DHCPDISCOVER 306 packet to the broadcast address, as described in [RFC2131] Section 307 4.4.1. If the host supports the Rapid Commit Option [RFC4039], it is 308 possible that the exchange can be shortened from a 4-message exchange 309 to a 2-message exchange. 311 If the host does not receive a response to a DHCPREQUEST or 312 DHCPDISCOVER, then it retransmits as specified in [RFC2131] Section 313 4.1. 315 As discussed in [RFC2131], Section 4.4.4, a host in INIT or REBOOTING 316 state that knows the address of a DHCP server may use that address in 317 the DHCPDISCOVER or DHCPREQUEST rather than the IPv4 broadcast 318 address. In the INIT-REBOOT state a DHCPREQUEST is sent to the 319 broadcast address so that the host will receive a response regardless 320 of whether the previously configured IPv4 address is correct for the 321 network to which it has connected. 323 Sending a DHCPREQUEST to the unicast address in INIT-REBOOT state is 324 not appropriate, since if the DHCP client has moved to another 325 subnet, a DHCP server response cannot be routed back to the client 326 since the DHCPREQUEST will bypass the DHCP relay and will contain an 327 invalid source address. 329 2.3. IPv4 Link-Local Addresses 331 Where the host does not have an operable routable IPv4 address on any 332 network, the host MAY configure an IPv4 Link-Local address prior to 333 entering the INIT state and sending a DHCPDISCOVER packet, as 334 described in [RFC2131] Section 2.3. Where a host can confirm that it 335 remains connected to a network on which it possesses an operable 336 routable IPv4 address, that address should be used and the IPv4 Link- 337 Local address is deprecated, as noted in [RFC3927] Section 1.9. 339 Where a host has an operable routable IPv4 address on one or more 340 networks, but the reachability test cannot confirm the configuration 341 and the DHCPv4 client does not receive a response after employing the 342 retransmission algorithm, [RFC2131] Section 3.2 states that the 343 client MAY choose to use the previously allocated network address and 344 configuration parameters for the remainder of the unexpired lease. 346 As described in [RFC3927] Appendix A, once a Link-Local IPv4 address 347 is assigned, existing implementations do not query the DHCPv4 server 348 again for five minutes. This behavior violates [RFC2131] Section 349 4.1: 351 The retransmission delay SHOULD be doubled with 352 subsequent retransmissions up to a maximum of 64 seconds. 354 Instead of waiting for five minutes, a DHCP client should continue to 355 retry every 64 seconds, even after allocating a IPv4 Link-Local 356 address. If the DHCP client succeeds in obtaining a routable 357 address, then the IPv4 Link-Local address is deprecated, as noted in 358 [RFC3927] Section 1.9. 360 In order to enable communication with hosts that have assigned IPv4 361 Link-Local addresses, hosts with routable IPv4 addresses need to be 362 able to respond to peers with IPv4 Link-Local addresses, as per 363 [RFC3927] Section 1.8. For example, a host configured with a 364 routable address may receive a datagram from a link-local source 365 address. In order to respond, the host will use ARP to resolve the 366 target hardware address and send the datagram directly, not to a 367 router for forwarding. 369 3. Constants 371 The suggested default value of REACHABILITY_TIMEOUT is 200 ms. This 372 value was chosen so as to accommodate the maximum retransmission 373 timer likely to be experienced on an Ethernet network. The default 374 value of JITTER_INTERVAL is 120ms. 376 4. IANA Considerations 378 This specification does not request the creation of any new parameter 379 registries, nor does it require any other IANA assignments. 381 5. Security Considerations 383 Detecting Network Attachment for IPv4 (DNAv4) is based on ARP and 384 DHCP and inherits the security vulnerabilities of these two 385 protocols. 387 ARP [RFC826] traffic is not secured, so that an attacker gaining 388 access to the network can spoof a response to the reachability test 389 described in Section 2.2, leading the querier to falsely conclude 390 that it is attached to a network that it is not connected to. 392 Similarly, where DHCPv4 traffic is not secured, an attacker could 393 masquerade as a DHCPv4 server, in order to convince the host that it 394 was attached to a particular network. This and other threats 395 relating to DHCPv4 are described in "Authentication for DHCP 396 Messages" [RFC3118]. 398 The effect of these attacks will typically be limited to denial of 399 service, unless the host utilizes its IP configuration for other 400 purposes, such as security configuration or location determination. 401 For example, a host that disables its personal firewall based on 402 evidence that it had attached to a home network could be compromised 403 by spoofing of the DNAv4 reachability test. In general, adjustment 404 of the security configuration based on DNAv4 is NOT RECOMMENDED. 406 Hosts that depend on secure IP configuration SHOULD NOT use DNAv4, 407 but SHOULD instead utilize DHCP authentication [RFC3118], possibly in 408 combination with the Rapid Commit Option [RFC4039]. 410 6. References 412 6.1. Normative References 414 [RFC792] Postel, J., "Internet Control Message Protocol", RFC 792, 415 USC/Information Sciences Institute, September 1981. 417 [RFC826] D. Plummer, "An Ethernet Address Resolution Protocol -or- 418 Converting Network Addresses to 48-bit Ethernet Address for 419 Transmission on Ethernet Hardware", STD 37, RFC 826, November 420 1982. 422 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 423 Requirement Levels", RFC 2119, March, 1997. 425 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 426 March 1997. 428 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", 429 RFC 3118, June 2001. 431 [RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration 432 of IPv4 Link-Local Addresses", RFC 3927, May 2005. 434 6.2. Informative References 436 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and 437 E. Lear, "Address Allocation for Private Internets", RFC 1918, 438 February 1996. 440 [RFC4039] Park, S., Kim, P., and B. Volz, "Rapid Commit Option for the 441 Dynamic Host Configuration Protocol version 4 (DHCPv4)", RFC 442 4039, March 2005. 444 Acknowledgments 446 The authors would like to acknowledge Greg Daley of Monash 447 University, Erik Guttman, James Carlson and Erik Nordmark of Sun 448 Microsystems, Ralph Droms of Cisco Systems, Ted Lemon of Nominum, 449 Stuart Cheshire of Apple Computer, John Loughney of Nokia, Thomas 450 Narten of IBM and David Hankins of ISC for contributions to this 451 document. 453 Authors' Addresses 455 Bernard Aboba 456 Microsoft Corporation 457 One Microsoft Way 458 Redmond, WA 98052 460 EMail: bernarda@microsoft.com 461 Phone: +1 425 818 4011 462 Fax: +1 425 936 7329 464 Intellectual Property Statement 466 The IETF takes no position regarding the validity or scope of any 467 Intellectual Property Rights or other rights that might be claimed to 468 pertain to the implementation or use of the technology described in 469 this document or the extent to which any license under such rights 470 might or might not be available; nor does it represent that it has 471 made any independent effort to identify any such rights. Information 472 on the procedures with respect to rights in RFC documents can be 473 found in BCP 78 and BCP 79. 475 Copies of IPR disclosures made to the IETF Secretariat and any 476 assurances of licenses to be made available, or the result of an 477 attempt made to obtain a general license or permission for the use of 478 such proprietary rights by implementers or users of this 479 specification can be obtained from the IETF on-line IPR repository at 480 http://www.ietf.org/ipr. 482 The IETF invites any interested party to bring to its attention any 483 copyrights, patents or patent applications, or other proprietary 484 rights that may cover technology that may be required to implement 485 this standard. Please address the information to the IETF at 486 ietf-ipr@ietf.org. 488 Disclaimer of Validity 490 This document and the information contained herein are provided on an 491 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 492 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 493 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 494 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 495 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 496 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 498 Copyright Statement 500 Copyright (C) The Internet Society (2005). This document is subject 501 to the rights, licenses and restrictions contained in BCP 78, and 502 except as set forth therein, the authors retain all their rights. 504 Acknowledgment 506 Funding for the RFC Editor function is currently provided by the 507 Internet Society. 509 Open issues 511 Open issues relating to this specification are tracked 512 on the following web site: 514 http://www.drizzle.com/~aboba/DNA/