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