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