idnits 2.17.1 draft-ietf-dhc-dna-ipv4-12.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 790. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 767. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 774. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 780. ** 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 17 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 18 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 == Line 752 has weird spacing: '...ured or assig...' == 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 (3 June 2005) is 6907 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 239 -- Looks like a reference, but probably isn't: '2' on line 242 -- Looks like a reference, but probably isn't: '3' on line 245 == Outdated reference: A later version (-06) exists of draft-cheshire-ipv4-acd-03 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 10 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 3 June 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 December 10, 2005. 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 operable IPv4 configuration may be 41 significant as a fraction of the total handover latency in moving 42 between points of attachment. This document specifies a procedure 43 for optimizing detection of network attachment in order to decrease 44 the handover latency in moving between points of attachment. 46 Table of Contents 48 1. Introduction.............................................. 3 49 1.1 Requirements .................................... 3 50 1.2 Terminology ..................................... 3 51 2. Overview ................................................. 5 52 2.1 Most Likely Attachment Network .................. 6 53 2.2 Reachability Test ............................... 7 54 2.3 IPv4 Address Acquisition ........................ 10 55 2.4 IPv4 Link-Local Addresses ....................... 10 56 3. Constants ................................................ 12 57 4. IANA Considerations ...................................... 12 58 5. Security Considerations .................................. 12 59 6. References ............................................... 13 60 6.1 Normative references ............................ 13 61 6.2 Informative references .......................... 13 62 Acknowledgments .............................................. 14 63 Authors' Addresses ........................................... 14 64 Appendix A - Link Layer Hints ................................ 15 65 A.1 Introduction .................................... 15 66 A.2 Hints ........................................... 16 67 Intellectual Property Statement .............................. 17 68 Disclaimer of Validity ....................................... 18 69 Copyright Statement .......................................... 18 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 experience in the deployment of hosts 78 supporting ARP [RFC826], DHCP [RFC2131], and IPv4 Link-Local 79 addresses [RFC3927], specifying a procedure for detecting network 80 attachment and optimizing continued use of an operable IPv4 81 configuration, in order to minimize the handover latency in moving 82 between points of attachment. Since this procedure is dependent on 83 the ARP protocol, it is not suitable for use on media that do not 84 support ARP [RFC826]. 86 1.1. Requirements 88 In this document, several words are used to signify the requirements 89 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 90 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 91 and "OPTIONAL" in this document are to be interpreted as described in 92 [RFC2119]. 94 1.2. Terminology 96 This document uses the following terms: 98 ar$sha 99 ARP packet field: Source Hardware Address [RFC826]. The hardware 100 (MAC) address of the originator of an ARP packet. 102 ar$spa 103 ARP packet field: Source Protocol Address [RFC826]. For IP Address 104 Resolution this is the IPv4 address of the sender of the ARP 105 packet. 107 ar$tha 108 ARP packet field: Target Hardware Address [RFC826]. The hardware 109 (MAC) address of the target of an ARP packet. 111 ar$tpa 112 ARP packet field: Target Protocol Address [RFC826]. For IPv4 113 Address Resolution, the IPv4 address for which one desires to know 114 the hardware address. 116 ARP Probe 117 An ARP Request packet, broadcast on the local link, with an all- 118 zero 'sender IP address' (ar$spa). The 'sender hardware address' 119 (ar$sha) MUST contain the hardware address of the interface sending 120 the packet. The 'target hardware address' field (ar$tha) is 121 ignored and SHOULD be set to all zeroes. The 'target IP address' 122 (ar$tpa) field MUST be set to the address being probed. 124 ARP Announcement 125 An ARP Request packet, broadcast on the local link, identical to 126 the ARP Probe described above, except that both the sender (ar$spa) 127 and target (ar$tpa) IP address fields contain the IP address being 128 announced. 130 DHCP client 131 A DHCP client or "client" is an Internet host using the Dynamic 132 Host Configuration protocol (DHCP) [RFC2131] to obtain 133 configuration parameters such as a network address. 135 DHCP server 136 A DHCP server or "server" is an Internet host that returns 137 configuration parameters to DHCP clients. 139 Link A communication facility or medium over which network nodes can 140 communicate. Each link is associated with a minimum of two 141 endpoints. Each link endpoint has a unique link-layer identifier. 143 Link Down 144 An event provided by the link layer that signifies a state change 145 associated with the interface no longer being capable of 146 communicating data frames; transient periods of high frame loss are 147 not sufficient. DNAv4 does not utilize "Link Down" indications. 149 Link Layer 150 Conceptual layer of control or processing logic that is responsible 151 for maintaining control of the data link. The data link layer 152 functions provide an interface between the higher-layer logic and 153 the data link. The link layer is the layer immediately below IP. 155 Link Up 156 An event provided by the link layer that signifies a state change 157 associated with the interface becoming capable of communicating 158 data frames. 160 Most Likely Attachment Network (MLAN) 161 The attached network heuristically determined by the host to be 162 most likely, based on hints. 164 Point of Attachment 165 The link endpoint on the link to which the host is currently 166 connected. 168 Routable address 169 In this specification, the term "routable address" refers to any 170 IPv4 address other than an IPv4 Link-Local address. This includes 171 private addresses as specified in [RFC1918]. 173 Operable address 174 In this specification, the term "operable address" refers to either 175 a static IPv4 address, or an address assigned via DHCPv4 which has 176 not been relinquished, and whose lease has not yet expired. 178 2. Overview 180 DNAv4 consists of three phases: determination of the Most Likely 181 Attachment Network (MLAN), reachability testing, and IPv4 address 182 acquisition. 184 On connecting to a new point of attachment, the host responds to a 185 "Link Up" indication from the link layer by carrying out the DNAv4 186 procedure. As noted in Appendix A, hints about the network to which 187 the host has attached may be available from the link and Internet 188 layers. Based on these hints, the host determines the "Most Likely 189 Attachment Network" (MLAN) and whether it has an operable IPv4 190 configuration associated with it. 192 If the host believes that it has attached to a network on which it 193 has an operable IPv4 configuration, then it performs a reachability 194 test in order to confirm that configuration. In contrast to a DHCPv4 195 exchange, which may be between a DHCPv4 client and an off-link DHCPv4 196 server, the reachability test is designed to verify bi-directional 197 connectivity to the default gateway(s) on the MLAN. 199 If the reachability test is successful, the host MAY continue to use 200 an operable routable IPv4 address without having to re-acquire it. 201 This reduces roaming latency by allowing the host to bypass DHCPv4 as 202 well as Duplicate Address Detection (DAD). If the host believes that 203 it has attached to a network on which it has no operable IPv4 204 configuration, or if the reachability test fails, then the host 205 attempts to obtain an IPv4 configuration using DHCPv4. 207 Since DNAv4 represents a performance optimization, it is important to 208 avoid compromising robustness. In some circumstances, DNAv4 may 209 result in a host successfully verifying an existing IPv4 210 configuration where attempting to obtain configuration via DHCPv4 211 would fail (such as when the DHCPv4 server is down). 213 To improve robustness, this document suggests that hosts behave 214 conservatively with respect to assignment of IPv4 Link-Local 215 addresses [RFC3927], configuring them only in situations in which 216 they can do no harm. Experience has shown that IPv4 Link-Local 217 addresses are often assigned inappropriately, compromising both 218 performance and connectivity. 220 While the performance of DNAv4 is dependent on the reliability of the 221 hints provided to the client, the host will ultimately determine the 222 correct IPv4 configuration even in the presence of misleading hints. 223 Where the host mistakenly concludes that it has an operable IPv4 224 configuration a timeout will occur, after which the host will 225 eventually obtain the correct configuration using DHCPv4, albeit with 226 a performance penalty. 228 DNAv4 does not increase the likelihood of an address conflict. The 229 DNAv4 procedure is only carried out when the host has an operable 230 IPv4 configuration on the MLAN, implying that duplicate address 231 detection has previously been completed. Restrictions on sending ARP 232 Requests and Responses are described in Section 2.2.1. 234 2.1. Most Likely Attachment Network (MLAN) 236 In order to determine the MLAN, it is assumed that the host saves to 237 stable storage parameters relating to the networks it connects to: 239 [1] Link and Internet layer hints associated with each 240 network. For details, see Appendix A. 242 [2] The IPv4 and MAC address of the default gateway(s) on 243 each network. 245 [3] The link type, such as whether the link utilizes 246 Ethernet, or 802.11 adhoc or infrastructure mode. 248 Appendix A discusses hints useful for the determination of the MLAN. 249 By matching received hints against network parameters previously 250 stored, the host makes an an educated guess of which network it has 251 attached to. In the absence of other information, the MLAN defaults 252 to the network to which the host was most recently attached. 254 Aside from utilizing link layer indications, a host may also be able 255 to utilize Internet layer information in order to determine the MLAN. 256 IPv4 ICMP Router Discovery messages [RFC1256] provide information 257 relating to prefix(es) available on the link, as well as the routers 258 that serve those prefix(es). A host may use ICMP Router Discovery to 259 conclude that an advertised prefix is available; however it cannot 260 conclude the converse -- that prefixes not advertised are 261 unavailable. 263 However, since [RFC1256] is not widely implemented, it is NOT 264 RECOMMENDED that hosts utilize ICMP Router Discovery messages as an 265 alternative to the reachability test outlined in Section 2.2. 266 Instead, ICMP Router Advertisements can be used to obtain information 267 on available prefixes and default gateway(s). This can provide 268 additional resilience in the case where default gateway(s) become 269 unavailable. 271 Similarly hosts that support routing protocols such as RIP and OSPF 272 can use these protocols to determine the prefix(es) available on a 273 link and the default gateway(s) that serve those prefixes. Full 274 support is not required to glean this information. A host that 275 passively observes routing protocol traffic may deduce this 276 information without supporting a fully conformant routing protocol 277 implementation. 279 2.2. Reachability Test 281 If the host has an operable routable IPv4 address on the MLAN, a host 282 conforming to this specification SHOULD perform a reachability test, 283 in order to to confirm that it is connected to network on which it 284 has an operable routable IPv4 address. If the reachability test is 285 not successful, the host proceeds to the IPv4 address acquisition 286 phase, described in Section 2.3. 288 The host skips the reachability test and proceeds to the IPv4 address 289 acquisition phase if any of the following conditions are true: 291 [a] The host does not have an operable routable IPv4 292 address on the MLAN. In this case, the reachability 293 test cannot confirm that the host has an operable 294 routable IPv4 address, so that completing the 295 reachability test would serve no purpose. 296 A host MUST NOT use the reachability test to 297 confirm configuration of an IPv4 Link-Local 298 address. 300 [b] The host does not have information on the default 301 gateway(s) on the MLAN. In this case, insufficient 302 information is available to carry out the reachability 303 test. 305 [c] Reliable hints are unavailable. Since confirming 306 failure of the reachability test requires a timeout, 307 mistakes are costly. In the absence of reliable 308 hints, a host SHOULD instead send a DHCPREQUEST from 309 the INIT-REBOOT state, as described in [RFC2131], 310 Section 3.2 and 4.3.2. Where reliable hints are 311 unavailable, this will typically complete more 312 quickly than the reachability test. 314 [d] If secure detection of network attachment is required. 315 The reachability test utilizes ARP which is insecure, 316 whereas DHCPv4 can be secured via DHCPv4 authentication, 317 described in [RFC3118]. See Section 5 for details. 319 [e] If the default gateway address is an IPv4 Link-Local 320 address. In this case, it is possible that the 321 reachability test could be misinterpreted as 322 indication of an address conflict. See [RFC3927] 323 Section 2.2.1 for details. 325 The host MAY test the reachability of the primary default gateway, or 326 it MAY test reachability of the primary and secondary default 327 gateways in series or in parallel. In order to ensure configuration 328 validity, the host SHOULD only configure default gateway(s) which 329 pass the reachability test. 331 2.2.1. Packet Format 333 The reachability test is performed by sending an ARP Request. The 334 ARP Request SHOULD use the host's MAC address as the source, and the 335 broadcast MAC address as the destination. The host sets the target 336 protocol address (ar$tpa) to the IPv4 address of the default gateway 337 being tested, and uses its own MAC address in the sender hardware 338 address field (ar$sha). The host sets the target hardware address 339 field (ar$tha) to 0. 341 If the host has an operable routable IPv4 address other than a 342 private address on the MLAN, then it SHOULD set the sender protocol 343 address field (ar$spa) to that address. It is assumed that the host 344 had previously done duplicate address detection so that an address 345 conflict is unlikely. 347 If the host has a private address as defined in [RFC1918], then it 348 SHOULD send an ARP Probe, setting the sender protocol address field 349 (ar$spa) to the unspecified address (0.0.0.0). This is to avoid a 350 potential address conflict when the host changes its attachment 351 network from one private network to another. 353 Note: Some routers may refuse to answer an ARP Probe, in which 354 case the reachability test will fail. A host also may encounter a 355 router that utilizes ARP Probes for DAD, as described in [ACD]. 356 Such routers will not interpret ARP Probes as an indication of an 357 address conflict, except where they are themselves doing Duplicate 358 Address Detection (DAD). To avoid triggering conflict detection 359 on these routers, a host implementing DNAv4 that receives ARP 360 Probe from a router SHOULD NOT send ARP Probes to that router as 361 part of the DNAv4 reachability test. 363 If a valid ARP Reply is received, the MAC address in the sender 364 hardware address field (ar$sha) and the IPv4 address in the sender 365 protocol address field (ar$spa) are matched against the list of 366 networks and associated default gateway parameters. If a match is 367 found, then if the host has an operable routable IPv4 address on the 368 matched network, the host continues to use that IPv4 address, subject 369 to the lease re-acquisition and expiration behavior described in 370 [RFC2131], Section 4.4.5. 372 Checking for a match on both the IPv4 address and MAC address of the 373 default gateway enables the host to confirm reachability even where 374 it has moved between two private networks. In this case the IPv4 375 address of the default gateway could remain the same, while the MAC 376 address would change, so that both addresses need to be checked. 378 The risk of an address conflict is greatest when the host moves 379 between private networks, since in this case the completion of 380 Duplicate Address Detection on the former network does not provide 381 assurance against an address conflict on the new network. Until a 382 host with a private address has confirmed the operability of its IPv4 383 configuration, it SHOULD NOT respond to ARP Requests, and SHOULD NOT 384 send ARP Requests containing its address within the sender protocol 385 address field (ar$spa). Instead it SHOULD use the unspecified 386 address, as described above. However, where the host has an operable 387 routable non-private address on the MLAN, it MAY send ARP Requests 388 using its address within the sender protocol address field (ar$spa) 389 prior to confirming its IPv4 configuration, and MAY respond to ARP 390 Requests. 392 Sending an ICMP Echo Request [RFC792] to the default gateway IPv4 393 address does not provide the same level of assurance since this may 394 require an ARP Request/Reply exchange. Where the host has moved 395 between two private networks, this could result in ARP cache 396 pollution. 398 Where a host moves from one private network to another, an ICMP Echo 399 Request can result in an ICMP Echo Response even when the default 400 gateway has changed, as long as the IPv4 address remains the same. 401 This can occur, for example, where a host moves from one home 402 network using prefix 192.168/16 to another one. In addition, if the 403 ping is sent with TTL > 1, then an ICMP Echo Response can be received 404 from an off-link gateway. As a result, if the MAC address of the 405 default gateway is not checked, the host can mistakenly confirm 406 attachment to the MLAN, potentially resulting in an address conflict. 408 As a result, sending of an ICMP Echo Request SHOULD NOT be used as a 409 substitute for the DNAv4 procedure. 411 If the initial ARP Request does not elicit a response, the host waits 412 for REACHABILITY_TIMEOUT and proceeds to the IPv4 address acquisition 413 phase. If a valid ARP Reply is received, but cannot be matched 414 against known networks, the host assumes it does not have an operable 415 IPv4 configuration and moves on to the IPv4 address acquisition 416 phase. 418 2.3. IPv4 Address Acquisition 420 If the host has an operable routable IPv4 address on the MLAN but the 421 reachability test fails, the host SHOULD verify the configuration by 422 entering the INIT-REBOOT state, and sending a DHCPREQUEST to the 423 broadcast address as specified in [RFC2131] Section 4.4.2. 425 If the host does not have an operable routable IPv4 address on the 426 MLAN, the host enters the INIT state and sends a DHCPDISCOVER packet 427 to the broadcast address, as described in [RFC2131] Section 4.4.1. 428 If the host supports the Rapid Commit Option [RFC4039], it is 429 possible that the exchange can be shortened from a 4-message exchange 430 to a 2-message exchange. 432 If the host does not receive a response to a DHCPREQUEST or 433 DHCPDISCOVER, then it retransmits as specified in [RFC2131] Section 434 4.1. 436 As discussed in [RFC2131], Section 4.4.4, a host in INIT or REBOOTING 437 state that knows the address of a DHCP server may use that address in 438 the DHCPDISCOVER or DHCPREQUEST rather than the IPv4 broadcast 439 address. In the INIT-REBOOT state a DHCPREQUEST is sent to the 440 broadcast address so that the host will receive a response regardless 441 of whether the previously configured IPv4 address is correct for the 442 network to which it has connected. 444 Sending a DHCPREQUEST to the unicast address in INIT-REBOOT state is 445 not appropriate, since if the DHCP client has moved to another 446 subnet, a DHCP server response cannot be routed back to the client 447 since the DHCPREQUEST will bypass the DHCP relay and will contain an 448 invalid source address. 450 2.4. IPv4 Link-Local Addresses 452 To avoid inappropriate assignment of IPv4 Link-Local addresses, it is 453 recommended that hosts behave conservatively, assigning them only 454 when they can do no harm. As described in [RFC3927] Section 1.7, use 455 of a routable address is preferred to a IPv4 Link-Local address 456 whenever it is available. 458 Where the host does not have an operable routable IPv4 address on the 459 MLAN, the host MAY configure an IPv4 Link-Local address prior to 460 entering the INIT state and sending a DHCPDISCOVER packet, as 461 described in Section 2.3. However, should a routable IPv4 address be 462 obtained, the IPv4 Link-Local address is deprecated, as noted in 463 [RFC3927]. 465 Where a host has an operable routable IPv4 address on the MLAN, but 466 the DHCP client does not receive a response after employing the 467 retransmission algorithm, [RFC2131] Section 3.2 states that the 468 client MAY choose to use the previously allocated network address and 469 configuration parameters for the remainder of the unexpired lease. 470 Where a host can confirm that it remains connected to a point of 471 attachment on which it possesses an operable routable IPv4 address, 472 that address SHOULD be used, rather than assigning a IPv4 Link-Local 473 address. 475 Since a IPv4 Link-Local address is often configured because a DHCP 476 server failed to respond to an initial query or is inoperative for 477 some time, it is desirable to abandon the IPv4 Link-Local address 478 assignment as soon as an IPv4 address lease can be obtained. 480 As described in [RFC3927] Appendix A, once a Link-Local IPv4 address 481 is assigned, existing implementations do not query the DHCPv4 server 482 again for 5 minutes. This behavior violates [RFC2131] Section 4.1. 484 Where a IPv4 Link-Local address is assigned, experience has shown 485 that five minutes (see [RFC3927] Appendix A.2) is too long an 486 interval to wait until retrying to obtain a routable IPv4 address 487 using DHCP. According to [RFC2131] Section 4.1: 489 The retransmission delay SHOULD be doubled with 490 subsequent retransmissions up to a maximum of 64 seconds. 492 As a result, a DHCP client compliant with [RFC2131] will continue to 493 retry every 64 seconds, even after allocating a IPv4 Link-Local 494 address. Should the DHCP client succeed in obtaining a routable 495 address, then as noted in [RFC3927], the IPv4 Link-Local address is 496 deprecated. 498 Since it is inevitable that hosts will inappropriately configure IPv4 499 Link-Local addresses at some point, hosts with routable IPv4 500 addresses need to be able to respond to peers with IPv4 Link-Local 501 addresses, as per [RFC3927]. For example, a host configured with a 502 routable address may receive a datagram from a link-local source 503 address. In order to respond, the host will use ARP to resolve the 504 target hardware address and send the datagram directly, not to a 505 router for forwarding. 507 3. Constants 509 The suggested default value of REACHABILITY_TIMEOUT is 200 ms. This 510 value was chosen so as to accommodate the maximum retransmission 511 timer likely to be experienced on an Ethernet network. 513 4. IANA Considerations 515 This specification does not request the creation of any new parameter 516 registries, nor does it require any other IANA assignments. 518 5. Security Considerations 520 Detecting Network Attachment for IPv4 (DNAv4) is based on ARP and 521 DHCP and inherits the security vulnerabilities of these two 522 protocols. 524 ARP [RFC826] traffic is not secured, so that an attacker gaining 525 access to the network can spoof a response to the reachability test 526 described in Section 2.2, leading the querier to falsely conclude 527 that it is attached to a network that it is not connected to. 529 Similarly, where DHCPv4 traffic is not secured, an attacker could 530 masquerade as a DHCPv4 server, in order to convince the host that it 531 was attached to a particular network. This and other threats 532 relating to DHCPv4 are described in "Authentication for DHCP 533 Messages" [RFC3118]. 535 The effect of these attacks will typically be limited to denial of 536 service, unless the host utilizes its IP configuration for other 537 purposes, such as security configuration or location determination. 538 For example, a host that disables its personal firewall based on 539 evidence that it had attached to a home network could be compromised 540 by spoofing of the DNAv4 reachability test. In general, adjustment 541 of the security configuration based on DNAv4 is NOT RECOMMENDED. 543 Hosts that depend on secure IP configuration SHOULD NOT use DNAv4, 544 but SHOULD instead utilize DHCP authentication [RFC3118], possibly in 545 combination with the Rapid Commit Option [RFC4039]. 547 6. References 549 6.1. Normative References 551 [RFC792] Postel, J., "Internet Control Message Protocol", RFC 792, 552 USC/Information Sciences Institute, September 1981. 554 [RFC826] D. Plummer, "An Ethernet Address Resolution Protocol -or- 555 Converting Network Addresses to 48-bit Ethernet Address for 556 Transmission on Ethernet Hardware", STD 37, RFC 826, November 557 1982. 559 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, Xerox 560 PARC, September 1991. 562 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 563 Requirement Levels", RFC 2119, March, 1997. 565 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 566 March 1997. 568 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", 569 RFC 3118, June 2001. 571 [RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration 572 of IPv4 Link-Local Addresses", RFC 3927, May 2005. 574 6.2. Informative References 576 [ACD] Cheshire, S., "IPv4 Address Conflict Detection", draft- 577 cheshire-ipv4-acd-03.txt, Internet draft (work in progress), 578 December 2002. 580 [RFC1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 581 51, RFC 1661, Daydreamer, July 1994. 583 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and 584 E. Lear, "Address Allocation for Private Internets", RFC 1918, 585 February 1996. 587 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, 588 "IEEE 802.1X Remote Authentication Dial In User Service 589 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 591 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 592 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 593 3748, June 2004. 595 [RFC4039] Park, S., Kim, P., and B. Volz, "Rapid Commit Option for the 596 Dynamic Host Configuration Protocol version 4 (DHCPv4)", RFC 597 4039, March 2005. 599 [IEEE-802.1AB] 600 IEEE Standards for Local and Metropolitan Area Networks: 601 Station and Media Access Control - Connectivity Discovery, 602 IEEE Std 802.1AB, March 2005. 604 [IEEE-802.1X] 605 IEEE Standards for Local and Metropolitan Area Networks: Port 606 based Network Access Control, IEEE Std 802.1X-2004, December 607 2004. 609 [IEEE-802] 610 IEEE Standards for Local and Metropolitan Area Networks: 611 Overview and Architecture, ANSI/IEEE Std 802, 1990. 613 [IEEE-802.1Q] 614 IEEE Standards for Local and Metropolitan Area Networks: Draft 615 Standard for Virtual Bridged Local Area Networks, P802.1Q, 616 January 1998. 618 [IEEE-802.11] 619 Information technology - Telecommunications and information 620 exchange between systems - Local and metropolitan area 621 networks - Specific Requirements Part 11: Wireless LAN Medium 622 Access Control (MAC) and Physical Layer (PHY) Specifications, 623 IEEE Std. 802.11-2003, 2003. 625 Acknowledgments 627 The authors would like to acknowledge Greg Daley of Monash 628 University, Erik Guttman and Erik Nordmark of Sun Microsystems, Ted 629 Lemon of Nominum Thomas Narten of IBM, and David Hankins of ISC for 630 contributions to this document. 632 Authors' Addresses 634 Bernard Aboba 635 Microsoft Corporation 636 One Microsoft Way 637 Redmond, WA 98052 639 EMail: bernarda@microsoft.com 640 Phone: +1 425 818 4011 641 Fax: +1 425 936 7329 643 Appendix A - Link Layer Hints 645 A.1 Introduction 647 In order to assist in detecting network attachment, information 648 associated with each network may be retained by the host. Based on 649 link-layer information, the host may be able to make an educated 650 guess as to whether it has moved between subnets, or has remained on 651 the same subnet, as well as whether it has connected to an 652 infrastructure or adhoc network. 654 If the host is likely to have moved between subnets, it may be 655 possible to make an educated guess as to which subnet it has moved 656 to. Since an educated guess may be incorrect, prior to concluding 657 that the host remains on the same subnet, further tests (such as a 658 reachability test or a DHCPREQUEST sent from the INIT-REBOOT state) 659 are REQUIRED. 661 In practice, it is necessary for hints to be highly reliable before 662 they are worth considering, if the penalty paid for an incorrect hint 663 is substantial. 665 As an example, assume that a DHCPREQUEST requires DHCPREQUEST_TIME to 666 determine if a host has remained on the same subnet, while a 667 reachability test typically completes in REACH_TIME and times out in 668 REACHABILITY_TIMEOUT, after which a DHCPREQUEST is sent. 670 If a hint that the host has remained on the same subnet is wrong x 671 fraction of the time, then it is only worth considering if: 673 DHCPREQUEST_TIME > (1 - x) * REACH_TIME + 675 x * (REACHABILITY_TIMEOUT + DHCPREQUEST_TIME) 677 x < DHCPREQUEST_TIME - REACH_TIME 678 ---------------------------------------------------- 679 REACHABILITY_TIMEOUT + DHCPREQUEST_TIME - REACH_TIME 681 If we assume that DHCPREQUEST_TIME = 50 ms, REACH_TIME = 10 ms, and 682 REACHABILITY_TIMEOUT = 200ms, then: 684 x < (50 - 10)/(200 + 50 - 10) = 16.67 percent 686 In this example, if the hint is wrong more than one sixth of the 687 time, it is not worth considering. 689 A.2 Hints 691 For networks running IPv4 over PPP [RFC1661], IPv4 parameters 692 negotiated in IPCP provide direct information on whether a previously 693 obtained address remains operable on the link. 695 On media supporting EAP [RFC3748], network identification information 696 may be passed within the EAP-Request/Identity or within an EAP method 697 exchange. For example, the EAP-Request/Identity may contain the name 698 of the authenticator. During the EAP method exchange the 699 authenticator may supply information that may be helpful in 700 identifying the network to which the device is attached. However, 701 as noted in [RFC3580], it is possible for the VLANID defined in 702 [IEEE-802.1Q] to be assigned dynamically, so that static 703 advertisements may not prove definitive. 705 On IEEE 802 [IEEE-802] wired networks, hints can be obtained via the 706 Link Layer Discovery Protocol (LLDP) defined in [IEEE-802.1AB]. LLDP 707 advertisements can include the chassis ID, which represents the 708 authenticator's chassis identification, enabling a host to determine 709 if it has attached to a previously encountered device. However, 710 since a device may support dynamic VLANs, re-attachment does not 711 necessarily imply that the VLAN has remained the same, although this 712 is likely. 714 LLDP also enables advertisement of the port's VLAN identifier, as 715 well as a VLAN name, allowing the host to determine whether it has 716 attached to a VLAN on which it had previously obtained an operable 717 IPv4 configuration. Since such an advertisement cannot be heard 718 until 802.1X authentication has completed, the advertised VLAN will 719 reflect a dynamic VLAN assignment if one has been made, so that it is 720 likely to be definitive. 722 In IEEE 802.11 [IEEE-802.11] stations provide information in Beacon 723 and/or Probe Response messages, such as the SSID, BSSID, and 724 capabilities, as well as information on whether the station is 725 operating in Infrastructure or Ad hoc mode. As described in 726 [RFC3580], it is possible to assign a Station to a VLAN dynamically, 727 based on the results of IEEE 802.1X [IEEE-802.1X] authentication. 728 This implies that a single SSID may offer access to multiple VLANs, 729 and in practice most large WLAN deployments offer access to multiple 730 subnets. While a Station associating to the same SSID may not remain 731 within the same subnet, a Station associating to a different SSID is 732 likely to have changed subnets. 734 In IEEE 802.11, the SSID is a non-unique identifier, and SSIDs such 735 as "default", "linksys" and "tsunami" are often configured by 736 manufacturers by default. As a result, matching an advertised SSID 737 against those of previously encountered networks may be misleading. 738 Where an SSID known to be configured by default is encountered, it is 739 recommended that the BSSID be stored and subsequently compared 740 against the advertised BSSID to determine whether a match exists. 742 In order to provide additional guidance on the subnets to which a 743 given AP offers access, additional subnet-related Information 744 Elements (IEs) have been proposed for addition to the IEEE 802.11 745 Beacon and Probe Response messages. As noted earlier, VLANs may be 746 determined dynamically so that these information elements may not be 747 reliable. 749 In IEEE 802.11, the presence of an IBSS can be used as a hint that a 750 link supports adhoc networking, and therefore that assignment of a 751 IPv4 Link-Local address is likely. When running IPv4 over PPP, if an 752 IPv4 address is not statically configured or assigned via IPv4CP, 753 this can also be taken as a hint that assignment of an IPv4 Link- 754 Local address is likely. Media such as USB or IEEE 1394 may be 755 considered inherently more likely to support adhoc operation, so that 756 attachment to these media may by itself be considered a hint. 758 Intellectual Property Statement 760 The IETF takes no position regarding the validity or scope of any 761 Intellectual Property Rights or other rights that might be claimed to 762 pertain to the implementation or use of the technology described in 763 this document or the extent to which any license under such rights 764 might or might not be available; nor does it represent that it has 765 made any independent effort to identify any such rights. Information 766 on the procedures with respect to rights in RFC documents can be 767 found in BCP 78 and BCP 79. 769 Copies of IPR disclosures made to the IETF Secretariat and any 770 assurances of licenses to be made available, or the result of an 771 attempt made to obtain a general license or permission for the use of 772 such proprietary rights by implementers or users of this 773 specification can be obtained from the IETF on-line IPR repository at 774 http://www.ietf.org/ipr. 776 The IETF invites any interested party to bring to its attention any 777 copyrights, patents or patent applications, or other proprietary 778 rights that may cover technology that may be required to implement 779 this standard. Please address the information to the IETF at ietf- 780 ipr@ietf.org. 782 Disclaimer of Validity 784 This document and the information contained herein are provided on an 785 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 786 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 787 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 788 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 789 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 790 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 792 Copyright Statement 794 Copyright (C) The Internet Society (2005). This document is subject 795 to the rights, licenses and restrictions contained in BCP 78, and 796 except as set forth therein, the authors retain all their rights. 798 Acknowledgment 800 Funding for the RFC Editor function is currently provided by the 801 Internet Society. 803 Open issues 805 Open issues relating to this specification are tracked on the 806 following web site: 808 http://www.drizzle.com/~aboba/DNA/