idnits 2.17.1 draft-ietf-dhc-dna-ipv4-18.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 697. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 674. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 681. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 687. ** 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 15 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 16 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 285 -- Looks like a reference, but probably isn't: '2' on line 288 == Outdated reference: A later version (-06) exists of draft-cheshire-ipv4-acd-04 Summary: 3 errors (**), 0 flaws (~~), 5 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 James Carlson 5 Sun Microsystems 6 1 December 2005 Stuart Cheshire 7 Apple Computer 9 Detecting Network Attachment in IPv4 (DNAv4) 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on June 10, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society 2005. 38 Abstract 40 The time required to detect movement between networks, and to obtain 41 (or continue to use) an IPv4 configuration may be significant as a 42 fraction of the total handover latency in moving between points of 43 attachment. This document synthesizes from experience in the 44 deployment of hosts supporting ARP, DHCP, and IPv4 Link-Local 45 addresses a set of steps known as Detecting Network Attachment for 46 IPv4 (DNAv4), in order to decrease the handover latency in moving 47 between points of attachment. 49 Table of Contents 51 1. Introduction.............................................. 3 52 1.1 Applicability ................................... 3 53 1.2 Requirements .................................... 5 54 1.3 Terminology ..................................... 5 55 2. Overview ................................................. 7 56 2.1 Reachability Test ............................... 8 57 2.2 IPv4 Address Acquisition ........................ 10 58 2.3 IPv4 Link-Local Addresses ....................... 11 59 2.4 Manually Assigned Addresses ..................... 12 60 3. IANA Considerations ...................................... 13 61 4. Security Considerations .................................. 13 62 5. References ............................................... 13 63 5.1 Normative references ............................ 13 64 5.2 Informative references .......................... 14 65 Acknowledgments .............................................. 14 66 Authors' Addresses ........................................... 14 67 Intellectual Property Statement .............................. 15 68 Disclaimer of Validity ....................................... 15 69 Copyright Statement .......................................... 16 70 1. Introduction 72 The time required to detect movement between networks and to obtain 73 (or continue to use) an operable IPv4 configuration may be 74 significant as a fraction of the total handover latency in moving 75 between points of attachment. 77 This document synthesizes from experience in the deployment of hosts 78 supporting ARP [RFC826], DHCP [RFC2131], and IPv4 Link-Local 79 addresses [RFC3927] a set of steps known as Detecting Network 80 Attachment for IPv4 (DNAv4). DNAv4 optimizes the (common) case of 81 re-attachment to a network that one has been connected to previously 82 by attempting to re-use a previous (but still valid) configuration, 83 reducing the re-attachment time to a few milliseconds on LANs. Since 84 this procedure is dependent on the ARP protocol, it is not suitable 85 for use on media that do not support ARP. 87 1.1. Applicability 89 DHCP is an effective and widely adopted mechanism for a host to 90 obtain an IP address for use on a particular network link, or to re- 91 validate a previously obtained address via DHCP's INIT-REBOOT 92 mechanism [RFC2131]. 94 When obtaining a new address, DHCP specifies that the client SHOULD 95 use ARP to verify that the offered address is not already in use. 96 The process of address conflict detection [ACD] can take as much as 97 seven seconds. In principle this time interval could be shortened, 98 with the obvious trade-off: the less time a host spends waiting to 99 see if another host is already using its intended address, the 100 greater the risk of inadvertent address conflicts. 102 Where the client successfully re-validates a previously obtained 103 address using the INIT-REBOOT mechanism, the DHCP specification does 104 not require the client to perform address conflict detection, so this 105 seven-second delay does not apply. However, the DHCP server may be 106 slow to respond, or may be down and not responding at all, so hosts 107 could benefit from having an alternative way to quickly determine 108 that a previously obtained address is valid for use on this 109 particular link. 111 When the client moves between networks, the address re-validation 112 attempt may be unsuccessful; a DHCPNAK may be received in response 113 to a DHCPREQUEST, causing the client to restart the configuration 114 process by moving to the INIT state. If an address previously 115 obtained on the new network is still operable, DNAv4 enables the host 116 to quickly confirm the new configuration, bypassing restart of the 117 configuration process as well as conflict detection. 119 The alternative mechanism specified by this document applies when a 120 host has a previously-allocated DHCP address, which was not returned 121 to the DHCP server via a DHCPRELEASE message, and which still has 122 time remaining on its lease. In this case, the host may determine 123 whether it has re-attached to the logical link where this address is 124 valid for use, by sending a unicast ARP Request packet to a router 125 previously known for that link (or in the case of a link with more 126 than one router, by sending one or more unicast ARP Request packets 127 to one or more of those routers). 129 The use of unicast ARP has a number of benefits. One benefit is that 130 unicast packets impose less burden on the network than broadcast 131 packets, particularly on 802.11 networks where broadcast packets may 132 be sent at rates as low as 1 Mb/sec. Another benefit is that if the 133 host is not on the link it hoped to find itself on, a broadcast ARP 134 Request could pollute the ARP caches of peers on that link. When 135 using private addresses [RFC1918] another device could be 136 legitimately using the same address, and a broadcast ARP Request 137 could disrupt its communications, causing TCP connections to be 138 broken, and similar problems. By using a unicast ARP packet instead, 139 addressed to the MAC address of the router the host is expecting to 140 find, if the host is not on the expected link, then there will be no 141 device with that MAC address, and the ARP packet will harmlessly 142 disappear into the void without doing any damage. 144 These issues that define the applicability of DNAv4 lead us to a 145 number of conclusions: 147 o DNAv4 is a performance optimization. Its purpose is to speed 148 up a process that may require as much as a few hundred 149 milliseconds (DHCP INIT-REBOOT), as well as to reduce 150 multi-second conflict detection delays when a host changes 151 networks. 153 o As a performance optimization, it must not sacrifice 154 correctness. In other words, false positives are not 155 acceptable. DNAv4 must not conclude that a host that has 156 returned to a previously-visited link where it has an operable 157 IP address if this is not in fact the case. 159 o As a performance optimization, false negatives are acceptable. 160 It is not an absolute requirement that this optimization 161 correctly recognize a previously-visited link in all possible 162 cases. For example, if a router ignores unicast ARP Requests 163 then DNAv4 will not be able to detect that it has returned to 164 the same link in future. This is acceptable because the host 165 still operates correctly as it did without DNAv4, just without 166 the performance benefit. Users and network operators who 167 desire the performance improvement offered by DNAv4 can 168 upgrade their routers to support DNAv4. 170 o As a performance optimization, where DNAv4 fails to provide a 171 benefit, it should add little or no delay compared to today's 172 DHCP processing. In practice, this implies that DHCP 173 processing needs to proceed in parallel. Waiting for DNAv4 174 to fail before beginning DHCP processing can greatly increase 175 total processing time, the opposite of the desired effect. 177 o Trials are inexpensive. DNAv4 performs its checks using small 178 unicast packets. An IPv4 ARP packet on Ethernet is just 42 179 octets, including the Ethernet header. This means that the 180 cost of an unsuccessful attempt is small, whereas the cost of a 181 missed opportunity (having the right address available as a 182 candidate and choosing not to try it for some reason) is large. 183 As a result, the best strategy is often to try all available 184 candidate configurations, rather than trying to determine which 185 candidates, if any, may be correct for this link, based on 186 heuristics or hints. For a heuristic to usefully eliminate a 187 configuration from the candidate list, it has to (a) be fast 188 and inexpensive to compute, compared to sending a 42-octet 189 unicast packet, and (b) have high probability of not falsely 190 eliminating a candidate configuration that could be found to be 191 the correct one. 193 o Time is limited. If DNAv4 is to be effective in enabling low 194 latency handoffs, it needs to complete in less than 10 ms. 195 This implies that any heuristic used to eliminate candidate 196 configurations needs to take at most a few milliseconds to 197 compute. This does not leave much room for heuristics based 198 on observation of link layer or Internet layer traffic. 200 1.2. Requirements 202 In this document, several words are used to signify the requirements 203 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 204 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 205 and "OPTIONAL" in this document are to be interpreted as described in 206 "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. 208 1.3. Terminology 210 This document uses the following terms: 212 ar$sha 213 ARP packet field: Sender Hardware Address [RFC826]. The hardware 214 (MAC) address of the originator of an ARP packet. 216 ar$spa 217 ARP packet field: Sender Protocol Address [RFC826]. For IP Address 218 Resolution this is the IPv4 address of the sender of the ARP 219 packet. 221 ar$tha 222 ARP packet field: Target Hardware Address [RFC826]. The hardware 223 (MAC) address of the target of an ARP packet. 225 ar$tpa 226 ARP packet field: Target Protocol Address [RFC826]. For IPv4 227 Address Resolution, the IPv4 address for which one desires to know 228 the hardware address. 230 DHCP client 231 A DHCP client or "client" is an Internet host using the Dynamic 232 Host Configuration protocol (DHCP) [RFC2131] to obtain 233 configuration parameters such as a network address. 235 DHCP server 236 A DHCP server or "server" is an Internet host that returns 237 configuration parameters to DHCP clients. 239 Link A communication facility or medium over which network nodes can 240 communicate. Each link is associated with a minimum of two 241 endpoints. Each link endpoint has a unique link-layer identifier. 243 Link Down 244 An event provided by the link layer that signifies a state change 245 associated with the interface no longer being capable of 246 communicating data frames; transient periods of high frame loss are 247 not sufficient. DNAv4 does not utilize "Link Down" indications. 249 Link Layer 250 Conceptual layer of control or processing logic that is responsible 251 for maintaining control of the data link. The data link layer 252 functions provide an interface between the higher-layer logic and 253 the data link. The link layer is the layer immediately below IP. 255 Link Up 256 An event provided by the link layer that signifies a state change 257 associated with the interface becoming capable of communicating 258 data frames. 260 Point of Attachment 261 The link endpoint on the link to which the host is currently 262 connected. 264 Routable address 265 In this specification, the term "routable address" refers to any 266 IPv4 address other than an IPv4 Link-Local address. This includes 267 private addresses as specified in "Address Allocation for Private 268 Internets" [RFC1918]. 270 Operable address 271 In this specification, the term "operable address" refers to either 272 a static IPv4 address, or an address assigned via DHCPv4 which has 273 not been returned to the DHCP server via a DHCP RELEASE message, 274 and whose lease has not yet expired. 276 2. Overview 278 On connecting to a new point of attachment, the host responds to a 279 "Link Up" indication from the link layer by carrying out the DNAv4 280 procedure. 282 For each network that it connects to, it is assumed that the host 283 saves to stable storage the following parameters: 285 [1] The IPv4 and MAC address of one or more test nodes 286 on the network 288 [2] The IPv4 configuration parameters, including 289 the DHCP client identifier, assigned address and 290 lease expiration time 292 From the set of networks which have operable IPv4 address(es) 293 associated with them, the host selects a subset, and attempts to 294 confirm the configuration for each network, using the reachability 295 test described in Section 2.1. 297 For a particular network, the host SHOULD use the addresses of local 298 routers (preferably default gateways) as its test nodes. If more 299 than one address is known, those addresses may be tested in parallel. 300 In order to ensure configuration validity, the host SHOULD only 301 configure routes for which the next hop address passes the 302 reachability test. Other routes SHOULD be re-learned. 304 DNAv4 does not significantly increase the likelihood of an address 305 conflict. The reachability test is only carried out for a network 306 when the host has previously completed conflict detection as 307 recommended in Section 2.2 of the DHCP specification [RFC2131], and 308 obtained an operable IPv4 configuration on that network. 309 Restrictions on sending ARP Requests and Responses are described in 310 Section 2.1.1. 312 One case where DNAv4 does increase the likelihood of an address 313 conflict is when: 315 o a DHCP server hands out an address lease 316 o the host with that lease leaves the network 317 o the DHCP server is power-cycled, or crashes and is rebooted 318 o the DHCP server, having failed to save leases to stable 319 storage, assigns that same address to another host 320 o the first host returns, and having a still-valid lease 321 with time remaining, proceeds to use its assigned 322 address, conflicting with the new host that is now 323 using that same address 325 While Section 4 of the DHCP specification [RFC2131] assumes that DHCP 326 servers save their leases in persistent storage, almost no consumer- 327 grade NAT gateway does so. Short DHCP lease lifetimes can mitigate 328 this risk, though this also limits the operable candidate 329 configurations available for DNAv4 to try. 331 2.1. Reachability Test 333 The host skips the reachability test for a network if any of the 334 following conditions are true: 336 [a] The host does not have an operable routable IPv4 337 address on that network. In this case, the reachability 338 test cannot confirm that the host has an operable 339 routable IPv4 address, so completing the 340 reachability test would serve no purpose. 342 [b] The host does not know the addresses of any test nodes 343 on that network. In this case, insufficient information 344 is available to carry out the reachability test. 346 [c] If DHCP authentication [RFC3118] is configured. The 347 reachability test utilizes ARP which is insecure. 348 Hosts that have been configured to attempt DHCP 349 authentication SHOULD NOT utilize the reachability 350 test. Security issues are discussed in Section 4. 352 [d] The contents of the DHCP Client Identifier option the client 353 used to obtain the candidate configuration is different from 354 the DHCP Client Identifier option the client intends to 355 present on the interface in question. In this case, it is 356 anticipated that a DHCP server would NAK any request made 357 by the client to acquire or extend the candidate configuration, 358 since the two interfaces are presenting differing identities. 360 If the reachability test is successful, the host SHOULD continue to 361 use the operable routable IPv4 address associated with the confirmed 362 network, without needing to re-acquire it. Once a valid reachability 363 test response is received, validation is complete, and additional 364 responses should be discarded. 366 If a DHCPv4 client is operational, it is RECOMMENDED that the host 367 attempt to obtain IPv4 configuration via DHCPv4 in parallel with the 368 reachability tests, with the host using the first answer returned. 369 This ensures that the DNAv4 procedure will not result in additional 370 delay in the case where reachability test(s) fail, or where sending a 371 DHCPREQUEST from the INIT-REBOOT state, as described in Section 3.2 372 and 4.3.2 of the DHCP specification [RFC2131], completes more quickly 373 than the reachability test(s). 375 In situations where both DNAv4 and DHCP are used on the same link, it 376 is possible that the reachability test will complete successfully, 377 and then DHCP will complete later with a different result. If this 378 happens, the implementation SHOULD abandon the reachability test 379 results and use the DHCP result instead, unless the address confirmed 380 via the reachability test has been manually assigned (see Section 381 2.4). 383 Where the reachability test does not return an answer, this is 384 typically because the host is not attached to the network whose 385 configuration is being tested. In such circumstances, there is 386 typically little value in aggressively retransmitting reachability 387 tests that do not elicit a response. 389 Where DNAv4 and DHCP are tried in parallel, one strategy is to 390 forsake reachability test retransmissions, allowing only the DHCP 391 client to retransmit. In order to reduce competition between DNAv4 392 and DHCP retransmissions, a DNAv4 implementation that retransmits may 393 utilize the retransmission strategy described in Section 4.1 of the 394 DHCP specification [RFC2131], scheduling DNAv4 retransmissions 395 between DHCP retransmissions. 397 If a response is received to any reachability test or DHCP message, 398 pending retransmissions are canceled. It is RECOMMENDED that a DNAv4 399 implementation retransmit no more than twice. To provide damping in 400 the case of spurious "Link Up" indications, it is RECOMMENDED that 401 the DNAv4 procedure be carried out no more than once a second. 403 2.1.1. Packet Format 405 The reachability test is performed by sending a unicast ARP Request. 406 The host MUST set the target protocol address (ar$tpa) to the IPv4 407 address of the node being tested, and the sender protocol address 408 field (ar$spa) to its own candidate IPv4 address. The ARP Request 409 MUST use the host MAC address as the source, and the test node MAC 410 address as the destination. The host includes its MAC address in the 411 sender hardware address field (ar$sha), and sets the target hardware 412 address field (ar$tha) to 0. 414 If a valid ARP Reply is received, the MAC address in the sender 415 hardware address field (ar$sha) in the ARP Reply is matched against 416 the target hardware address field (ar$tpa) in the ARP Request, and 417 the IPv4 address in the sender protocol address field (ar$spa) of the 418 ARP Reply is matched against the target protocol address field 419 (ar$tpa) in the ARP Request. If a match is found, then the host 420 continues to use that IPv4 address, subject to the lease re- 421 acquisition and expiration behavior described in Section 4.4.5 of the 422 DHCP specification [RFC2131]. 424 The risk of an address conflict is greatest when the host moves 425 between private networks, since in this case the completion of 426 conflict detection on the former network does not provide assurance 427 against an address conflict on the new network. Until a host has 428 confirmed the operability of its IPv4 configuration by receipt of a 429 response to the reachability test, it SHOULD NOT respond to ARP 430 Requests and SHOULD NOT broadcast ARP Requests containing its address 431 within the sender protocol address field (ar$spa). 433 Sending an ICMP Echo Request [RFC792] would not be an acceptable way 434 of testing a candidate configuration since sending any IP packet 435 generally requires an ARP Request/Reply exchange, and as explained 436 above, ARP packets may not be broadcast safely until after the 437 candidate configuration has been confirmed. Also where a host moves 438 from one private network to another, an ICMP Echo Request can result 439 in an ICMP Echo Response even when the MAC address has changed, as 440 long as the IPv4 address remains the same. This can occur, for 441 example, where a host moves from one home network using prefix 442 192.168/16 to another one. In addition, if the ping is sent with TTL 443 > 1, then an ICMP Echo Response can be received from an off-link 444 router. As a result, if the MAC address of the test node is not 445 checked, the host can mistakenly confirm attachment, potentially 446 resulting in an address conflict. As a result, sending of an ICMP 447 Echo Request SHOULD NOT be used as a substitute for the reachability 448 test. 450 2.2. IPv4 Address Acquisition 452 If the host has an operable routable IPv4 address on one or more 453 networks, and DHCPv4 is enabled on the interface, the host SHOULD 454 attempt to acquire an IPv4 configuration using DHCPv4, in parallel 455 with one or more reachability tests. This is accomplished by 456 entering the INIT-REBOOT state, and sending a DHCPREQUEST to the 457 broadcast address as specified in Section 4.4.2 of the DHCP 458 specification [RFC2131]. 460 If the host does not have an operable routable IPv4 address on any 461 network, the host enters the INIT state and sends a DHCPDISCOVER 462 packet to the broadcast address, as described in Section 4.4.1 of the 463 DHCP specification [RFC2131]. If the host supports the Rapid Commit 464 Option [RFC4039], it is possible that the exchange can be shortened 465 from a 4-message exchange to a 2-message exchange. 467 If the host does not receive a response to a DHCPREQUEST or 468 DHCPDISCOVER, then it retransmits as specified in Section 4.1 of the 469 DHCP specification [RFC2131]. 471 As discussed in Section 4.4.4 of the DHCP specification [RFC2131], a 472 host in INIT or REBOOTING state that knows the address of a DHCP 473 server may use that address in the DHCPDISCOVER or DHCPREQUEST rather 474 than the IPv4 broadcast address. In the INIT-REBOOT state a 475 DHCPREQUEST is sent to the broadcast address so that the host will 476 receive a response regardless of whether the previously configured 477 IPv4 address is correct for the network to which it has connected. 479 Sending a DHCPREQUEST to the unicast address in INIT-REBOOT state is 480 not appropriate, since if the DHCP client has moved to another 481 subnet, a DHCP server response cannot be routed back to the client 482 since the DHCPREQUEST will bypass the DHCP relay and will contain an 483 invalid source address. 485 2.3. IPv4 Link-Local Addresses 487 DNAv4 applies only to previously-configured addresses that had some 488 lease lifetime associated with them, during which lifetime the 489 address may be legitimately regarded as being reserved for exclusive 490 use by the assigned host. DHCP-assigned addresses fit this 491 description, but IPv4 Link-Local address [RFC3927] do not, since IPv4 492 Link-Local addresses are not handed out by an authoritative server, 493 and do not come with any guaranteed usable lifetime. 495 A host's claim on an IPv4 Link-Local address is valid only as long as 496 that host remains connected to the link, actively defending against 497 probes for its chosen address. As soon as a host shuts down, sleeps, 498 or otherwise disconnects from a link, it immediately relinquishes any 499 claim it may have had on any IPv4 Link-Local address on that link. A 500 host wishing to reclaim a previously-used IPv4 Link-Local address 501 MUST perform the full probing and announcement process required by 502 "Dynamic Configuration of IPv4 Link-Local Addresses" [RFC3927], and 503 MUST NOT attempt to use DNAv4 as a shortcut to bypass that process. 505 Where the host does not have an operable routable IPv4 address on any 506 network, the host MAY configure an IPv4 Link-Local address prior to 507 entering the INIT state and sending a DHCPDISCOVER packet, as 508 described in Section 2.3 of the DHCP specification [RFC2131]. Where 509 a host can confirm that it remains connected to a network on which it 510 possesses an operable routable IPv4 address, that address should be 511 used and the IPv4 Link-Local address is deprecated, as noted in 512 Section 1.9 of the IPv4 Link-Local specification [RFC3927]. 514 Where a host has an operable routable IPv4 address on one or more 515 networks, but the reachability test cannot confirm the configuration 516 and the DHCPv4 client does not receive a response after employing the 517 retransmission algorithm, Section 3.2 of the DHCP specification 518 [RFC2131] states that the client MAY choose to use the previously 519 allocated network address and configuration parameters for the 520 remainder of the unexpired lease. 522 2.4. Manually Assigned Addresses 524 An implementation may use DNAv4 to confirm the configuration of 525 manually assigned addresses. However, special consideration is 526 required for this to produce reliable results, so that it SHOULD NOT 527 be enabled by default. 529 For the purposes of DNAv4, manually assigned addresses may be treated 530 as equivalent to DHCP-assigned addresses with an infinite lifetime. 531 This does not significantly increase the probability of an address 532 conflict as long as the manually assigned address is reserved by the 533 DHCP server or is outside the scope of addresses assigned by a DHCP 534 server. However, where the manually assigned address is within an 535 address scope utilized by a DHCP server, it is possible that the host 536 will be unavailable when the DHCP server checks for a conflict prior 537 to assigning the conflicting address. In this case, a host utilizing 538 DNAv4 could confirm an address that had been assigned to another 539 host. 541 Typically an address is manually assigned on a network because a 542 dynamically assigned address was not suitable for some reason. 543 Therefore where both DNAv4 and DHCP are run in parallel and DNAv4 544 confirms a manual configuration, it may be undesirable to allow this 545 configuration to be overridden by DHCP, as described in Section 2.1. 546 However, packet loss may cause the reachability test to fail while 547 DHCP completes successfully, resulting in the host obtaining a 548 dynamic address where a static address is desired. In order to 549 provide for reliable reconfirmation of manually assigned addresses, 550 reachability tests for manual configurations require a more 551 aggressive retransmission strategy than that detailed in Section 4.1 552 of the DHCP specification [RFC2131]. For example, shorter 553 retransmission intervals and more persistent retransmissions may be 554 required. 556 3. IANA Considerations 558 This specification does not request the creation of any new parameter 559 registries, nor does it require any other IANA assignments. 561 4. Security Considerations 563 Detecting Network Attachment for IPv4 (DNAv4) is based on ARP and 564 DHCP and inherits the security vulnerabilities of these two 565 protocols. 567 ARP [RFC826] traffic is not secured, so that an attacker gaining 568 access to the network can spoof a response to the reachability test 569 described in Section 2.1, leading the querier to falsely conclude 570 that it is attached to a network that it is not connected to. 572 Similarly, where DHCPv4 traffic is not secured, an attacker could 573 masquerade as a DHCPv4 server, in order to convince the host that it 574 was attached to a particular network. This and other threats 575 relating to DHCPv4 are described in "Authentication for DHCP 576 Messages" [RFC3118]. 578 The effect of these attacks will typically be limited to denial of 579 service, unless the host utilizes its IP configuration for other 580 purposes, such as security configuration or location determination. 581 For example, a host that disables its personal firewall based on 582 evidence that it had attached to a home network could be compromised 583 by spoofing of the DNAv4 reachability test. In general, adjustment 584 of the security configuration based on DNAv4 is NOT RECOMMENDED. 586 Hosts that depend on secure IP configuration SHOULD NOT use DNAv4, 587 but SHOULD instead utilize DHCP authentication [RFC3118], possibly in 588 combination with the Rapid Commit Option [RFC4039]. 590 5. References 592 5.1. Normative References 594 [RFC826] D. Plummer, "An Ethernet Address Resolution Protocol -or- 595 Converting Network Addresses to 48-bit Ethernet Address for 596 Transmission on Ethernet Hardware", STD 37, RFC 826, November 597 1982. 599 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 600 Requirement Levels", RFC 2119, March, 1997. 602 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 603 March 1997. 605 5.2. Informative References 607 [ACD] Cheshire, S., "IPv4 Address Conflict Detection", Internet 608 draft (work in progress), draft-cheshire-ipv4-acd-04.txt, July 609 2005. 611 [RFC792] Postel, J., "Internet Control Message Protocol", RFC 792, 612 USC/Information Sciences Institute, September 1981. 614 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and 615 E. Lear, "Address Allocation for Private Internets", RFC 1918, 616 February 1996. 618 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", 619 RFC 3118, June 2001. 621 [RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration 622 of IPv4 Link-Local Addresses", RFC 3927, May 2005. 624 [RFC4039] Park, S., Kim, P., and B. Volz, "Rapid Commit Option for the 625 Dynamic Host Configuration Protocol version 4 (DHCPv4)", RFC 626 4039, March 2005. 628 Acknowledgments 630 The authors would like to acknowledge Greg Daley of Monash 631 University, Erik Guttman and Erik Nordmark of Sun Microsystems, Ralph 632 Droms of Cisco Systems, Ted Lemon of Nominum, John Loughney of Nokia, 633 Thomas Narten of IBM and David Hankins of ISC for contributions to 634 this document. 636 Authors' Addresses 638 Bernard Aboba 639 Microsoft Corporation 640 One Microsoft Way 641 Redmond, WA 98052 643 EMail: bernarda@microsoft.com 644 Phone: +1 425 818 4011 645 Fax: +1 425 936 7329 647 James Carlson 648 Sun Microsystems, Inc 649 1 Network Drive 650 Burlington, MA 01803-2757 651 USA 653 Phone: +1 781 442 2084 654 Fax: +1 781 442 1677 655 EMail: james.d.carlson@sun.com 657 Stuart Cheshire 658 Apple Computer, Inc. 659 1 Infinite Loop 660 Cupertino, California 95014, USA 662 Phone: +1 408 974 3207 663 EMail: rfc@stuartcheshire.org 665 Intellectual Property Statement 667 The IETF takes no position regarding the validity or scope of any 668 Intellectual Property Rights or other rights that might be claimed to 669 pertain to the implementation or use of the technology described in 670 this document or the extent to which any license under such rights 671 might or might not be available; nor does it represent that it has 672 made any independent effort to identify any such rights. Information 673 on the procedures with respect to rights in RFC documents can be 674 found in BCP 78 and BCP 79. 676 Copies of IPR disclosures made to the IETF Secretariat and any 677 assurances of licenses to be made available, or the result of an 678 attempt made to obtain a general license or permission for the use of 679 such proprietary rights by implementers or users of this 680 specification can be obtained from the IETF on-line IPR repository at 681 http://www.ietf.org/ipr. 683 The IETF invites any interested party to bring to its attention any 684 copyrights, patents or patent applications, or other proprietary 685 rights that may cover technology that may be required to implement 686 this standard. Please address the information to the IETF at 687 ietf-ipr@ietf.org. 689 Disclaimer of Validity 691 This document and the information contained herein are provided on an 692 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 693 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 694 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 695 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 696 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 697 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 699 Copyright Statement 701 Copyright (C) The Internet Society (2005). This document is subject 702 to the rights, licenses and restrictions contained in BCP 78, and 703 except as set forth therein, the authors retain all their rights. 705 Acknowledgment 707 Funding for the RFC Editor function is currently provided by the 708 Internet Society. 710 Open issues 712 Open issues relating to this specification are tracked 713 on the following web site: 715 http://www.drizzle.com/~aboba/DNA/