idnits 2.17.1 draft-ietf-dhc-dna-ipv4-17.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 690. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 667. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 674. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 680. ** 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 291 -- Looks like a reference, but probably isn't: '2' on line 294 == 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 23 October 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 April 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 ..................................... 6 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 ...................................... 12 61 4. Security Considerations .................................. 13 62 5. References ............................................... 13 63 5.1 Normative references ............................ 13 64 5.2 Informative references .......................... 13 65 Acknowledgments .............................................. 14 66 Authors' Addresses ........................................... 14 67 Intellectual Property Statement .............................. 15 68 Disclaimer of Validity ....................................... 15 69 Copyright Statement .......................................... 15 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. For example, eliminating a candidate 192 configuration because it was obtained on a different physical 193 interface would not be wise. In the case of an Ethernet link 194 and an 802.11 wireless link bridged together, an IP address and 195 default gateway on the Ethernet link may continue to represent 196 a valid and usable configuration if the host loses its Ethernet 197 connection and switches to 802.11 wireless. 199 o Time is limited. If DNAv4 is to be effective in enabling low 200 latency handoffs, it needs to complete in less than 10 ms. 201 This implies that any heuristic used to eliminate candidate 202 configurations needs to take at most a few milliseconds to 203 compute. This does not leave much room for heuristics based 204 on observation of link layer or Internet layer traffic. 206 1.2. Requirements 208 In this document, several words are used to signify the requirements 209 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 210 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 211 and "OPTIONAL" in this document are to be interpreted as described in 212 "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. 214 1.3. Terminology 216 This document uses the following terms: 218 ar$sha 219 ARP packet field: Sender Hardware Address [RFC826]. The hardware 220 (MAC) address of the originator of an ARP packet. 222 ar$spa 223 ARP packet field: Sender Protocol Address [RFC826]. For IP Address 224 Resolution this is the IPv4 address of the sender of the ARP 225 packet. 227 ar$tha 228 ARP packet field: Target Hardware Address [RFC826]. The hardware 229 (MAC) address of the target of an ARP packet. 231 ar$tpa 232 ARP packet field: Target Protocol Address [RFC826]. For IPv4 233 Address Resolution, the IPv4 address for which one desires to know 234 the hardware address. 236 DHCP client 237 A DHCP client or "client" is an Internet host using the Dynamic 238 Host Configuration protocol (DHCP) [RFC2131] to obtain 239 configuration parameters such as a network address. 241 DHCP server 242 A DHCP server or "server" is an Internet host that returns 243 configuration parameters to DHCP clients. 245 Link A communication facility or medium over which network nodes can 246 communicate. Each link is associated with a minimum of two 247 endpoints. Each link endpoint has a unique link-layer identifier. 249 Link Down 250 An event provided by the link layer that signifies a state change 251 associated with the interface no longer being capable of 252 communicating data frames; transient periods of high frame loss are 253 not sufficient. DNAv4 does not utilize "Link Down" indications. 255 Link Layer 256 Conceptual layer of control or processing logic that is responsible 257 for maintaining control of the data link. The data link layer 258 functions provide an interface between the higher-layer logic and 259 the data link. The link layer is the layer immediately below IP. 261 Link Up 262 An event provided by the link layer that signifies a state change 263 associated with the interface becoming capable of communicating 264 data frames. 266 Point of Attachment 267 The link endpoint on the link to which the host is currently 268 connected. 270 Routable address 271 In this specification, the term "routable address" refers to any 272 IPv4 address other than an IPv4 Link-Local address. This includes 273 private addresses as specified in "Address Allocation for Private 274 Internets" [RFC1918]. 276 Operable address 277 In this specification, the term "operable address" refers to either 278 a static IPv4 address, or an address assigned via DHCPv4 which has 279 not been returned to the DHCP server via a DHCP RELEASE message, 280 and whose lease has not yet expired. 282 2. Overview 284 On connecting to a new point of attachment, the host responds to a 285 "Link Up" indication from the link layer by carrying out the DNAv4 286 procedure. 288 For each network that it connects to, it is assumed that the host 289 saves to stable storage the following parameters: 291 [1] The IPv4 and MAC address of one or more test nodes 292 on the network 294 [2] The IPv4 configuration parameters, including 295 the assigned address and lease expiration time 297 From the set of networks which have operable IPv4 address(es) 298 associated with them, the host selects a subset, and attempts to 299 confirm the configuration for each network, using the reachability 300 test described in Section 2.1. 302 For a particular network, the host SHOULD use the addresses of local 303 routers (preferably default gateways) as its test nodes. If more 304 than one address is known, those addresses may be tested in parallel. 305 In order to ensure configuration validity, the host SHOULD only 306 configure routes for which the next hop address passes the 307 reachability test. Other routes SHOULD be re-learned. 309 DNAv4 does not significantly increase the likelihood of an address 310 conflict. The reachability test is only carried out for a network 311 when the host has previously completed conflict detection as 312 recommended in Section 2.2 of the DHCP specification [RFC2131], and 313 obtained an operable IPv4 configuration on that network. 314 Restrictions on sending ARP Requests and Responses are described in 315 Section 2.1.1. 317 One case where DNAv4 does increase the likelihood of an address 318 conflict is when: 320 o a DHCP server hands out an address lease 321 o the host with that lease leaves the network 322 o the DHCP server is power-cycled, or crashes and is rebooted 323 o the DHCP server, having failed to save leases to stable 324 storage, assigns that same address to another host 325 o the first host returns, and having a still-valid lease 326 with time remaining, proceeds to use its assigned 327 address, conflicting with the new host that is now 328 using that same address 330 While Section 4 of the DHCP specification [RFC2131] assumes that DHCP 331 servers save their leases in persistent storage, almost no consumer- 332 grade NAT gateway does so. Short DHCP lease lifetimes can mitigate 333 this risk, though this also limits the operable candidate 334 configurations available for DNAv4 to try. 336 2.1. Reachability Test 338 The host skips the reachability test for a network if any of the 339 following conditions are true: 341 [a] The host does not have an operable routable IPv4 342 address on that network. In this case, the reachability 343 test cannot confirm that the host has an operable 344 routable IPv4 address, so completing the 345 reachability test would serve no purpose. 347 [b] The host does not know the addresses of any test nodes 348 on that network. In this case, insufficient information 349 is available to carry out the reachability test. 351 [c] If secure detection of network attachment is required. 352 The reachability test utilizes ARP which is insecure. 354 If the reachability test is successful, the host SHOULD continue to 355 use the operable routable IPv4 address associated with the confirmed 356 network, without needing to re-acquire it. Once a valid reachability 357 test response is received, validation is complete, and additional 358 responses should be discarded. 360 If a DHCPv4 client is operational, it is RECOMMENDED that the host 361 attempt to obtain IPv4 configuration via DHCPv4 in parallel with the 362 reachability tests, with the host using the first answer returned. 363 This ensures that the DNAv4 procedure will not result in additional 364 delay in the case where reachability test(s) fail, or where sending a 365 DHCPREQUEST from the INIT-REBOOT state, as described in Section 3.2 366 and 4.3.2 of the DHCP specification [RFC2131], completes more quickly 367 than the reachability test(s). 369 In situations where both DNAv4 and DHCP are used on the same link, it 370 is possible that the reachability test will complete successfully, 371 and then DHCP will complete later with a different result. If this 372 happens, the implementation SHOULD abandon the reachability test 373 results and use the DHCP result instead, unless the address confirmed 374 via the reachability test has been manually assigned (see Section 375 2.4). 377 Where the reachability test does not return an answer, this is 378 typically because the host is not attached to the network whose 379 configuration is being tested. In such circumstances, there is 380 typically little value in aggressively retransmitting reachability 381 tests that do not elicit a response. 383 Where DNAv4 and DHCP are tried in parallel, one strategy is to 384 forsake reachability test retransmissions, allowing only the DHCP 385 client to retransmit. In order to reduce competition between DNAv4 386 and DHCP retransmissions, a DNAv4 implementation that retransmits may 387 utilize the retransmission strategy described in Section 4.1 of the 388 DHCP specification [RFC2131], scheduling DNAv4 retransmissions 389 between DHCP retransmissions. 391 If a response is received to any reachability test or DHCP message, 392 pending retransmissions are canceled. It is RECOMMENDED that a DNAv4 393 implementation retransmit no more than twice. To provide damping in 394 the case of spurious "Link Up" indications, it is RECOMMENDED that 395 the DNAv4 procedure be carried out no more than once a second. 397 2.1.1. Packet Format 399 The reachability test is performed by sending a unicast ARP Request. 400 The host MUST set the target protocol address (ar$tpa) to the IPv4 401 address of the node being tested, and the sender protocol address 402 field (ar$spa) to its own candidate IPv4 address. The ARP Request 403 MUST use the host MAC address as the source, and the test node MAC 404 address as the destination. The host includes its MAC address in the 405 sender hardware address field (ar$sha), and sets the target hardware 406 address field (ar$tha) to 0. 408 If a valid ARP Reply is received, the MAC address in the sender 409 hardware address field (ar$sha) in the ARP Reply is matched against 410 the target hardware address field (ar$tpa) in the ARP Request, and 411 the IPv4 address in the sender protocol address field (ar$spa) of the 412 ARP Reply is matched against the target protocol address field 413 (ar$tpa) in the ARP Request. If a match is found, then the host 414 continues to use that IPv4 address, subject to the lease re- 415 acquisition and expiration behavior described in Section 4.4.5 of the 416 DHCP specification [RFC2131]. 418 The risk of an address conflict is greatest when the host moves 419 between private networks, since in this case the completion of 420 conflict detection on the former network does not provide assurance 421 against an address conflict on the new network. Until a host has 422 confirmed the operability of its IPv4 configuration by receipt of a 423 response to the reachability test, it SHOULD NOT respond to ARP 424 Requests and SHOULD NOT broadcast ARP Requests containing its address 425 within the sender protocol address field (ar$spa). 427 Sending an ICMP Echo Request [RFC792] would not be an acceptable way 428 of testing a candidate configuration since sending any IP packet 429 generally requires an ARP Request/Reply exchange, and as explained 430 above, ARP packets may not be broadcast safely until after the 431 candidate configuration has been confirmed. Also where a host moves 432 from one private network to another, an ICMP Echo Request can result 433 in an ICMP Echo Response even when the MAC address has changed, as 434 long as the IPv4 address remains the same. This can occur, for 435 example, where a host moves from one home network using prefix 436 192.168/16 to another one. In addition, if the ping is sent with TTL 437 > 1, then an ICMP Echo Response can be received from an off-link 438 router. As a result, if the MAC address of the test node is not 439 checked, the host can mistakenly confirm attachment, potentially 440 resulting in an address conflict. As a result, sending of an ICMP 441 Echo Request SHOULD NOT be used as a substitute for the reachability 442 test. 444 2.2. IPv4 Address Acquisition 446 If the host has an operable routable IPv4 address on one or more 447 networks, and DHCPv4 is enabled on the interface, the host SHOULD 448 attempt to acquire an IPv4 configuration using DHCPv4, in parallel 449 with one or more reachability tests. This is accomplished by 450 entering the INIT-REBOOT state, and sending a DHCPREQUEST to the 451 broadcast address as specified in Section 4.4.2 of the DHCP 452 specification [RFC2131]. 454 If the host does not have an operable routable IPv4 address on any 455 network, the host enters the INIT state and sends a DHCPDISCOVER 456 packet to the broadcast address, as described in Section 4.4.1 of the 457 DHCP specification [RFC2131]. If the host supports the Rapid Commit 458 Option [RFC4039], it is possible that the exchange can be shortened 459 from a 4-message exchange to a 2-message exchange. 461 If the host does not receive a response to a DHCPREQUEST or 462 DHCPDISCOVER, then it retransmits as specified in Section 4.1 of the 463 DHCP specification [RFC2131]. 465 As discussed in Section 4.4.4 of the DHCP specification [RFC2131], a 466 host in INIT or REBOOTING state that knows the address of a DHCP 467 server may use that address in the DHCPDISCOVER or DHCPREQUEST rather 468 than the IPv4 broadcast address. In the INIT-REBOOT state a 469 DHCPREQUEST is sent to the broadcast address so that the host will 470 receive a response regardless of whether the previously configured 471 IPv4 address is correct for the network to which it has connected. 473 Sending a DHCPREQUEST to the unicast address in INIT-REBOOT state is 474 not appropriate, since if the DHCP client has moved to another 475 subnet, a DHCP server response cannot be routed back to the client 476 since the DHCPREQUEST will bypass the DHCP relay and will contain an 477 invalid source address. 479 2.3. IPv4 Link-Local Addresses 481 DNAv4 applies only to previously-configured addresses that had some 482 lease lifetime associated with them, during which lifetime the 483 address may be legitimately regarded as being reserved for exclusive 484 use by the assigned host. DHCP-assigned addresses fit this 485 description, but IPv4 Link-Local address [RFC3927] do not, since IPv4 486 Link-Local addresses are not handed out by an authoritative server, 487 and do not come with any guaranteed usable lifetime. 489 A host's claim on an IPv4 Link-Local address is valid only as long as 490 that host remains connected to the link, actively defending against 491 probes for its chosen address. As soon as a host shuts down, sleeps, 492 or otherwise disconnects from a link, it immediately relinquishes any 493 claim it may have had on any IPv4 Link-Local address on that link. A 494 host wishing to reclaim a previously-used IPv4 Link-Local address 495 MUST perform the full probing and announcement process required by 496 "Dynamic Configuration of IPv4 Link-Local Addresses" [RFC3927], and 497 MUST NOT attempt to use DNAv4 as a shortcut to bypass that process. 499 Where the host does not have an operable routable IPv4 address on any 500 network, the host MAY configure an IPv4 Link-Local address prior to 501 entering the INIT state and sending a DHCPDISCOVER packet, as 502 described in Section 2.3 of the DHCP specification [RFC2131]. Where 503 a host can confirm that it remains connected to a network on which it 504 possesses an operable routable IPv4 address, that address should be 505 used and the IPv4 Link-Local address is deprecated, as noted in 506 Section 1.9 of the IPv4 Link-Local specification [RFC3927]. 508 Where a host has an operable routable IPv4 address on one or more 509 networks, but the reachability test cannot confirm the configuration 510 and the DHCPv4 client does not receive a response after employing the 511 retransmission algorithm, Section 3.2 of the DHCP specification 512 [RFC2131] states that the client MAY choose to use the previously 513 allocated network address and configuration parameters for the 514 remainder of the unexpired lease. 516 2.4. Manually Assigned Addresses 518 An implementation may use DNAv4 to confirm the configuration of 519 manually assigned addresses. However, special consideration is 520 required for this to produce reliable results, so that it SHOULD NOT 521 be enabled by default. 523 For the purposes of DNAv4, manually assigned addresses may be treated 524 as equivalent to DHCP-assigned addresses with an infinite lifetime. 525 This does not significantly increase the probability of an address 526 conflict as long as the manually assigned address is reserved by the 527 DHCP server or is outside the scope of addresses assigned by a DHCP 528 server. However, where the manually assigned address is within an 529 address scope utilized by a DHCP server, it is possible that the host 530 will be unavailable when the DHCP server checks for a conflict prior 531 to assigning the conflicting address. In this case, a host utilizing 532 DNAv4 could confirm an address that had been assigned to another 533 host. 535 Typically an address is manually assigned on a network because a 536 dynamically assigned address was not suitable for some reason. 537 Therefore where both DNAv4 and DHCP are run in parallel and DNAv4 538 confirms a manual configuration, it may be undesirable to allow this 539 configuration to be overridden by DHCP, as described in Section 2.1. 540 However, packet loss may cause the reachability test to fail while 541 DHCP completes successfully, resulting in the host obtaining a 542 dynamic address where a static address is desired. In order to 543 provide for reliable reconfirmation of manually assigned addresses, 544 reachability tests for manual configurations require a more 545 aggressive retransmission strategy than that detailed in Section 4.1 546 of the DHCP specification [RFC2131]. For example, shorter 547 retransmission intervals and more persistent retransmissions may be 548 required. 550 3. IANA Considerations 552 This specification does not request the creation of any new parameter 553 registries, nor does it require any other IANA assignments. 555 4. Security Considerations 557 Detecting Network Attachment for IPv4 (DNAv4) is based on ARP and 558 DHCP and inherits the security vulnerabilities of these two 559 protocols. 561 ARP [RFC826] traffic is not secured, so that an attacker gaining 562 access to the network can spoof a response to the reachability test 563 described in Section 2.1, leading the querier to falsely conclude 564 that it is attached to a network that it is not connected to. 566 Similarly, where DHCPv4 traffic is not secured, an attacker could 567 masquerade as a DHCPv4 server, in order to convince the host that it 568 was attached to a particular network. This and other threats 569 relating to DHCPv4 are described in "Authentication for DHCP 570 Messages" [RFC3118]. 572 The effect of these attacks will typically be limited to denial of 573 service, unless the host utilizes its IP configuration for other 574 purposes, such as security configuration or location determination. 575 For example, a host that disables its personal firewall based on 576 evidence that it had attached to a home network could be compromised 577 by spoofing of the DNAv4 reachability test. In general, adjustment 578 of the security configuration based on DNAv4 is NOT RECOMMENDED. 580 Hosts that depend on secure IP configuration SHOULD NOT use DNAv4, 581 but SHOULD instead utilize DHCP authentication [RFC3118], possibly in 582 combination with the Rapid Commit Option [RFC4039]. 584 5. References 586 5.1. Normative References 588 [RFC826] D. Plummer, "An Ethernet Address Resolution Protocol -or- 589 Converting Network Addresses to 48-bit Ethernet Address for 590 Transmission on Ethernet Hardware", STD 37, RFC 826, November 591 1982. 593 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 594 Requirement Levels", RFC 2119, March, 1997. 596 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 597 March 1997. 599 5.2. Informative References 601 [ACD] Cheshire, S., "IPv4 Address Conflict Detection", Internet 602 draft (work in progress), draft-cheshire-ipv4-acd-04.txt, July 603 2005. 605 [RFC792] Postel, J., "Internet Control Message Protocol", RFC 792, 606 USC/Information Sciences Institute, September 1981. 608 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and 609 E. Lear, "Address Allocation for Private Internets", RFC 1918, 610 February 1996. 612 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", 613 RFC 3118, June 2001. 615 [RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration 616 of IPv4 Link-Local Addresses", RFC 3927, May 2005. 618 [RFC4039] Park, S., Kim, P., and B. Volz, "Rapid Commit Option for the 619 Dynamic Host Configuration Protocol version 4 (DHCPv4)", RFC 620 4039, March 2005. 622 Acknowledgments 624 The authors would like to acknowledge Greg Daley of Monash 625 University, Erik Guttman and Erik Nordmark of Sun Microsystems, Ralph 626 Droms of Cisco Systems, Ted Lemon of Nominum, John Loughney of Nokia, 627 Thomas Narten of IBM and David Hankins of ISC for contributions to 628 this document. 630 Authors' Addresses 632 Bernard Aboba 633 Microsoft Corporation 634 One Microsoft Way 635 Redmond, WA 98052 637 EMail: bernarda@microsoft.com 638 Phone: +1 425 818 4011 639 Fax: +1 425 936 7329 641 James Carlson 642 Sun Microsystems, Inc 643 1 Network Drive 644 Burlington, MA 01803-2757 645 USA 646 Phone: +1 781 442 2084 647 Fax: +1 781 442 1677 648 EMail: james.d.carlson@sun.com 650 Stuart Cheshire 651 Apple Computer, Inc. 652 1 Infinite Loop 653 Cupertino, California 95014, USA 655 Phone: +1 408 974 3207 656 EMail: rfc@stuartcheshire.org 658 Intellectual Property Statement 660 The IETF takes no position regarding the validity or scope of any 661 Intellectual Property Rights or other rights that might be claimed to 662 pertain to the implementation or use of the technology described in 663 this document or the extent to which any license under such rights 664 might or might not be available; nor does it represent that it has 665 made any independent effort to identify any such rights. Information 666 on the procedures with respect to rights in RFC documents can be 667 found in BCP 78 and BCP 79. 669 Copies of IPR disclosures made to the IETF Secretariat and any 670 assurances of licenses to be made available, or the result of an 671 attempt made to obtain a general license or permission for the use of 672 such proprietary rights by implementers or users of this 673 specification can be obtained from the IETF on-line IPR repository at 674 http://www.ietf.org/ipr. 676 The IETF invites any interested party to bring to its attention any 677 copyrights, patents or patent applications, or other proprietary 678 rights that may cover technology that may be required to implement 679 this standard. Please address the information to the IETF at 680 ietf-ipr@ietf.org. 682 Disclaimer of Validity 684 This document and the information contained herein are provided on an 685 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 686 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 687 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 688 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 689 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 690 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 692 Copyright Statement 694 Copyright (C) The Internet Society (2005). This document is subject 695 to the rights, licenses and restrictions contained in BCP 78, and 696 except as set forth therein, the authors retain all their rights. 698 Acknowledgment 700 Funding for the RFC Editor function is currently provided by the 701 Internet Society. 703 Open issues 705 Open issues relating to this specification are tracked 706 on the following web site: 708 http://www.drizzle.com/~aboba/DNA/