idnits 2.17.1 draft-ietf-dhc-dna-ipv4-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 11) being 77 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 17 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 652 has weird spacing: '...ured or assig...' == Line 715 has weird spacing: '...>, and expir...' == 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 (14 April 2004) is 7316 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 181 -- Looks like a reference, but probably isn't: '2' on line 184 -- Looks like a reference, but probably isn't: '3' on line 187 == Outdated reference: A later version (-17) exists of draft-ietf-zeroconf-ipv4-linklocal-15 -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 2461 (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 2462 (Obsoleted by RFC 4862) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DHC Working Group Bernard Aboba 2 INTERNET-DRAFT Microsoft Corporation 3 Category: Proposed Standard 4 5 14 April 2004 7 Detection of Network Attachment (DNA) in IPv4 9 By submitting this Internet-Draft, I certify that any applicable 10 patent or other IPR claims of which I am aware have been disclosed, 11 and any of which I become aware will be disclosed, in accordance with 12 RFC 3667. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at http:// 24 www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on October 22, 2004. 31 Copyright Notice 33 Copyright (C) The Internet Society (2004). All Rights Reserved. 35 Abstract 37 The time required to detect movement (or lack of movement) between 38 subnets, and to obtain (or continue to use) a valid IPv4 address may 39 be significant as a fraction of the total delay in moving between 40 points of attachment. This document synthesizes experience garnered 41 over the years in the deployment of hosts supporting ARP, DHCP and 42 Link-Local IPv4 addresses. A procedure is specified for detection of 43 network attachment in order to better accommodate mobile hosts. 45 Table of Contents 47 1. Introduction.............................................. 3 48 1.1 Requirements .................................... 3 49 1.2 Terminology ..................................... 3 50 2. Framework ................................................ 4 51 2.1 Most Likely Point of Attachment ................. 5 52 2.2 Reachability Test ............................... 6 53 2.3 IPv4 Address Acquisition ........................ 8 54 2.4 Link-Local IPv4 Addresses ....................... 9 55 3. Constants ................................................ 10 56 4. IANA Considerations ...................................... 10 57 5. Security Considerations .................................. 10 58 6. References ............................................... 11 59 6.1 Normative references ............................ 11 60 6.2 Informative references .......................... 11 61 Acknowledgments .............................................. 12 62 Authors' Addresses ........................................... 13 63 Appendix A - Link Layer Hints ................................ 14 64 A.1 Introduction .................................... 14 65 A.2 Hints ........................................... 15 66 Intellectual Property Statement .............................. 16 67 Full Copyright Statement ..................................... 17 68 1. Introduction 70 The time required to detect movement (or lack of movement) between 71 subnets, and to obtain (or continue to use) a valid IPv4 address may 72 be significant as a fraction of the total delay in moving between 73 points of attachment. As a result, optimizing detection of network 74 attachment is important for mobile hosts. 76 This document synthesizes experience in the deployment of hosts 77 supporting ARP [RFC826], DHCP [RFC2131], and Link-Local IPv4 78 addresses [IPv4LL], specifying a procedure to be performed for IPv4 79 detection of network attachment. The procedure consists of three 80 phases: determination of the "most likely" point of attachment, 81 reachability testing, and IPv4 address acquisition. 83 This document concerns the interaction of mechanisms used by IPv4 84 protocol stacks. Network attachment detection and its interaction 85 with interface configuration is considered elsewhere, for example in 86 Neighbor Discovery for IPv6 [RFC2461], IPv6 Stateless Address 87 Autoconfiguration [RFC2462] and Mobility Support in IPv6 [MIPv6]. 89 1.1. Requirements 91 In this document, several words are used to signify the requirements 92 of the specification. These words are often capitalized. The key 93 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 94 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 95 are to be interpreted as described in [RFC2119]. 97 1.2. Terminology 99 This document uses the following terms: 101 ar$sha 102 ARP packet field: Source Hardware Address [RFC826]. The hardware 103 (MAC) address of the originator of an ARP packet. 105 ar$spa 106 ARP packet field: Source Protocol Address [RFC826]. For IP Address 107 Resolution this is the IPv4 address of the sender of the ARP 108 packet. If the sender address is unknown, this is set to 0.0.0.0. 110 ar$tha 111 ARP packet field: Target Hardware Address [RFC826]. The hardware 112 (MAC) address of the target of an ARP packet, or the broadcast 113 address if the target hardware address is unknown. 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 DHCP to obtain 122 configuration parameters such as a network address. 124 DHCP server 125 A DHCP server or "server" is an Internet host that returns 126 configuration parameters to DHCP clients. 128 Routable address 129 In this specification, the term "routable address" refers to any 130 address other than an Link-Local IPv4 address. This includes 131 private addresses as specified in [RFC1918]. 133 Valid address 134 In this specification, the term "valid address" refers to either a 135 static IPv4 address, or an address assigned via DHCPv4 which has 136 not been relinquished, and whose lease has not yet expired. 138 2. Framework 140 For Detection of Network attachment, the following basic principles 141 are suggested: 143 [a] Utilization of hints. Link layers such as IEEE 802 144 [IEEE802] provide hints whether a host remains 145 on the same subnet despite changing its point of 146 attachment, or whether a host is connected to an 147 ad hoc or infrastructure network. Prior to connecting 148 to a new point of attachment, the host uses available 149 hints to determine the "most likely" configuration 150 associated with the new point of attachment. Since 151 hints are not infallible, the host should be capable of 152 making the correct determination even in the presence of 153 misleading hints. For details see Appendix A. 155 [b] Treatment of link-up indications. On connecting 156 to a new point of attachment, the host attempts to 157 verify the "most likely" configuration associated 158 with the new point of attachment. 160 [c] Treatment of link-down indications. On disconnection 161 from a network, there is no need to take action until the 162 host is reconnected, since it is typically not possible 163 for a host to communicate until it has obtained connectivity. 164 Therefore, contrary to [RFC2131] Section 3.7, no action 165 need be taken on network disconnection. 167 [d] Handling of Link-Local IPv4 addresses. Experience has 168 shown that Link-Local IPv4 addresses are often assigned 169 inappropriately. This document suggests that hosts 170 behave conservatively with respect to assignment of 171 Link-Local IPv4 addresses, configuring them only in 172 situations in which they can do no harm. 174 2.1. Most Likely Point of Attachment 176 In order to determine the "most likely" point of attachment it is 177 assumed that the host is capable of obtaining and writing to stable 178 storage parameters relating to networks that it connects to, 179 including: 181 [1] Link layer hints associated with each network. 182 For details, see Appendix A. 184 [2] The IPv4 and MAC address of the default gateway(s) on 185 each network. 187 [3] Whether a network is an infrastructure or adhoc network. 189 By matching the received hints against information previously 190 collected, the host may be able to make an educated guess of which 191 network it has attached to. In the absence of other information, by 192 default the host may assume that the "most likely" point of 193 attachment is the network to which it was most recently attached. 195 2.1.1. Alternative Mechanisms 197 Aside from utilizing link layer hints, a host may also be able to 198 utilize Internet layer information in order to determine the "most 199 likely" point of attachment. 201 IPv4 ICMP Router Discovery messages [RFC1256] provide information 202 relating to prefix(es) available on the link, as well as the routers 203 that serve those prefix(es). A host may use ICMP Router Discovery to 204 conclude that an advertised prefix is available; however it cannot 205 conclude the converse -- that prefixes not advertised are 206 unavailable. 208 However, since [RFC1256] is not widely implemented, in general, it is 209 NOT RECOMMENDED that hosts utilize ICMP Router Discovery messages as 210 an alternative to the reachability test outlined in Section 2.2. 212 Instead, ICMP Router Advertisements can be used to obtain information 213 on available prefixes and default gateway(s). This can provide 214 additional resilience in the case where default gateway(s) become 215 unavailable. 217 Similarly, hosts that support routing protocols such as RIP and OSPF 218 can use these protocols to determine the prefix(es) available on a 219 link and the default gateway(s) that serve those prefixes. 221 2.2. Reachability Test 223 If the host has a valid routable IPv4 address on the "most likely" 224 point of attachment, the host will typically perform a reachability 225 test, as described in this section. The purpose of the reachability 226 test is to confirm whether the host is connected to a network on 227 which it has a valid routable IPv4 address. 229 If the reachability test is not successful, or if the host does not 230 have a valid routable IPv4 address on the "most likely" point of 231 attachment, the host proceeds to the IPv4 address acquisition phase, 232 described in Section 2.3. 234 The host skips the reachability test in the following circumstances: 236 [a] If the host does not have a valid routable IPv4 237 address on the "most likely" point of attachment. 239 [b] If reliable hints are unavailable. Since confirming 240 failure of the reachability test requires a timeout, 241 mistakes are costly. In the absence of reliable 242 hints, a host SHOULD instead send a DHCPREQUEST from 243 the INIT-REBOOT state, as described in [RFC2131], 244 Section 3.2 and 4.3.2. 246 [c] If the host does not have information on the default 247 gateway(s) for the "most likely" point of attachment. 249 [d] If secure detection of network attachment is required. 250 See Section 5 for details. 252 The reachability test is performed by attempting to verify 253 reachability of default gateway(s) on the "most likely" point of 254 attachment. This reduces roaming latency by allowing the host to 255 bypass DHCP as well as subsequent Duplicate Address Detection (DAD). 256 In contrast to a DHCP exchange, which may be between a DHCP client 257 and an off-link DHCP server, the reachability test occurs between a 258 host and its next hop router. 260 The host may probe only the primary default gateway, or it may probe 261 primary and secondary default gateways, in series or in parallel. If 262 the reachability test is successful, the host may continue to use a 263 valid routable IPv4 address without having to re-acquire it. 264 However, in order to ensure configuration validity, the host SHOULD 265 only configure default gateway(s) which pass the reachability test. 267 2.2.1. Packet Format 269 The reachability test is performed by sending an ARP Request. The 270 ARP Request SHOULD use the host's MAC address as the source, and the 271 broadcast MAC address as the destination. The host sets the target 272 protocol address (ar$tpa) to the IPv4 address of the primary default 273 gateway, and uses its own MAC address in the sender hardware address 274 field (ar$sha). The host sets the target hardware address field 275 (ar$tha) to 0. 277 If the host has a valid routable IPv4 address on the most likely 278 point of attachment, then it SHOULD set the sender protocol address 279 field (ar$spa) to that address. It is assumed that the host had 280 previously done duplicate address detection so that an address 281 conflict is unlikely. 283 However if the host has a private address as defined in [RFC1918], 284 then it SHOULD set the sender protocol address field (ar$spa) to the 285 unspecified address (0.0.0.0). This is to avoid an address conflict 286 in the case where the host has changed its point of attachment from 287 one private network to another. 289 Note: Some routers may refuse to answer an ARP Request sent with 290 the sender protocol address field (ar$spa) set to the unspecified 291 address (0.0.0.0). In this case the reachability test will fail. 293 If a valid ARP Response is received, the MAC address in the sender 294 hardware address field (ar$sha) and the IPv4 address in the sender 295 protocol address field (ar$spa) are matched against the list of 296 networks and associated default gateway parameters. If a match is 297 found, then if the host has a valid routable IPv4 address on the 298 matched network, the host continues to use that IPv4 address, subject 299 to the lease re-acquisition and expiration behavior described in 300 [RFC2131], Section 4.4.5. 302 Checking for a match on both the IPv4 address and MAC address of the 303 default gateway allows the host to confirm reachability even where 304 the host moves between two private networks. In this case the IPv4 305 address of the default gateway could remain the same, while the MAC 306 address would change, so that both addresses need to be checked. 308 Sending an ICMP Echo Request [RFC792] to the default gateway IPv4 309 address does not provide the same level of assurance since this 310 requires an ARP Request/Response to be sent first, and typically does 311 not allow the MAC address to be checked as well. It therefore SHOULD 312 NOT be used as a substitute. 314 Where a host moves from one private network to another, an ICMP Echo 315 Request can result in an ICMP Echo Response even when the default 316 gateway has changed, as long as the IPv4 address remains the same. 317 This can occur, for example, where a host moves from one home 318 network using prefix 192.168/16 to another one. In addition, if the 319 ping is sent with TTL > 1, then an ICMP Echo Response can be received 320 from an off-link gateway. 322 If the initial ARP Request does not elicit a Response, the host waits 323 for REACHABILITY_TIMEOUT and proceeds to the IPv4 address acquisition 324 phase. If a valid ARP Response is received, but cannot be matched 325 against known networks, the host assumes it has moved subnets and 326 moves on to the address acquisition phase. 328 2.3. IPv4 Address Acquisition 330 If the host has a valid routable IPv4 address on the "most likely" 331 point of attachment, but the reachability test fails, then the host 332 SHOULD verify the configuration by entering the INIT-REBOOT state, 333 and sending a DHCPREQUEST to the broadcast address as specified in 334 [RFC2131] Section 4.4.2. 336 If the host does not have a valid routable IPv4 address on the "most 337 likely" point of attachment, the host enters the INIT state and sends 338 a DHCPDISCOVER packet to the broadcast address, as described in 339 [RFC2131] Section 4.4.1. 341 If the host does not receive a response to a DHCPREQUEST or 342 DHCPDISCOVER, then it retransmits as specified in [RFC2131] Section 343 4.1. 345 As discussed in [RFC2131], Section 4.4.4, a host in INIT or REBOOTING 346 state that knows the address of a DHCP server may use that address in 347 the DHCPDISCOVER or DHCPREQUEST rather than the IPv4 broadcast 348 address. In the INIT-REBOOT state a DHCPREQUEST is sent to the 349 broadcast address so that the host will receive a response regardless 350 of whether the previously configured IPv4 address is correct for the 351 network to which it has connected. 353 Sending a DHCPREQUEST to the unicast address in INIT-REBOOT state is 354 not appropriate, since if the DHCP client has moved to another 355 subnet, a DHCP server response cannot be routed back to the client 356 since the DHCPREQUEST will bypass the DHCP relay and will contain an 357 invalid source address. 359 2.4. Link-Local IPv4 Addresses 361 To avoid inappropriate assignment of Link-Local IPv4 addresses, it is 362 recommended that hosts behave conservatively with respect to 363 assignment of Link-Local IPv4 addresses. As described in [IPv4LL] 364 Section 1.7, use of a routable address is preferred to a Link-Local 365 IPv4 address whenever it is available. 367 Where the host does not have a valid routable IPv4 address on the 368 "most likely" point of attachment, the host MAY configure an Link- 369 Local IPv4 address prior to entering the INIT state and sending a 370 DHCPDISCOVER packet, as described in Section 2.3. However, should a 371 routable IPv4 address be obtained, the Link-Local IPv4 address is 372 deprecated, as noted in [IPv4LL]. 374 Where a host has a valid routable IPv4 address on the "most likely" 375 point of attachment, but the DHCP client does not receive a response 376 after employing the retransmission algorithm, [RFC2131] Section 3.2 377 states that the client MAY choose to use the previously allocated 378 network address and configuration parameters for the remainder of the 379 unexpired lease. Where a host can confirm that it remains connected 380 to a point of attachment on which it possesses a valid routable IPv4 381 address, that address SHOULD be used, rather than assigning a Link- 382 Local IPv4 address. 384 Since a Link-Local IPv4 address is often configured because a DHCP 385 server failed to respond to an initial query or is inoperative for 386 some time, it is desirable to abandon the Link-Local IPv4 address 387 assignment as soon as a valid IPv4 address lease can be obtained. 389 As described in [IPv4LL] Appendix A, once a Link-Local IPv4 address 390 is assigned, existing implementations do not query the DHCPv4 server 391 again for 5 minutes. This behavior is in violation of [RFC2131] 392 Section 4.1. 394 Where a Link-Local IPv4 address is assigned, experience has shown 395 that five minutes (see [IPv4LL] Appendix A.2) is too long an interval 396 to wait until retrying to obtain a routable IPv4 address using DHCP. 397 According to [RFC2131] Section 4.1: 399 The retransmission delay SHOULD be doubled with 400 subsequent retransmissions up to a maximum of 64 seconds. 402 As a result, a DHCP client compliant with [RFC2131] will continue to 403 retry every 64 seconds, even after allocating a Link-Local IPv4 404 address. Should the DHCP client succeed in obtaining a routable 405 address, then as noted in [IPv4LL], the Link-Local IPv4 address is 406 deprecated. 408 Since it is inevitable that hosts will inappropriately configure 409 Link-Local IPv4 addresses at some point, hosts with routable IPv4 410 addresses SHOULD be able to respond to peers with Link-Local IPv4 411 addresses, as per [IPv4LL]. For example, a host configured with a 412 routable address may receive a datagram from a link-local source 413 address. In order to respond, the host will use ARP to resolve the 414 target hardware address and send the datagram directly, not to a 415 router for forwarding. 417 3. Constants 419 The suggested default value of REACHABILITY_TIMEOUT is 200 ms. This 420 value was chosen so as to accommodate the maximum retransmission 421 timer likely to be experienced on an Ethernet network. 423 4. IANA Considerations 425 Guidelines for IANA considerations are specified in [RFC2434]. This 426 specification does not request the creation of any new parameter 427 registries, nor does it require any other IANA assignments. 429 5. Security Considerations 431 Detection of Network Attachment (DNA) is typically insecure, so that 432 it is inadvisable for a host to adjust its security based on which 433 network it believes it is attached to. For example, it would be 434 inappropriate for a host to disable its personal firewall based on 435 the belief that it had connected to a home network. 437 ARP [RFC826] traffic is inherently insecure, so that the reachability 438 test described in Section 1.3 can be easily spoofed by an attacker, 439 leading a host to falsely conclude that it is attached to a network 440 that it is not connected to. Similarly, where DHCP traffic is not 441 secured, an attacker could masquerade as a DHCP server, in order to 442 convince the host that it was attached to a particular network. 444 Where secure detection of network attachment is required, a host 445 SHOULD skip the reachability test since it cannot be secured, and 446 instead utilize authenticated DHCP [RFC3118]. 448 6. References 450 6.1. Normative References 452 [RFC792] Postel, J., "Internet Control Message Protocol", RFC 792, 453 USC/Information Sciences Institute, September 1981. 455 [RFC826] D. Plummer, "An Ethernet Address Resolution Protocol -or- 456 Converting Network Addresses to 48-bit Ethernet Address for 457 Transmission on Ethernet Hardware", STD 37, RFC 826, November 458 1982. 460 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, Xerox 461 PARC, September 1991. 463 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 464 Requirement Levels", RFC 2119, March, 1997. 466 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 467 March 1997. 469 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", 470 RFC 3118, June 2001. 472 [IPv4LL] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration 473 of Link-Local IPv4 Addresses", Internet draft (work in 474 progress), draft-ietf-zeroconf-ipv4-linklocal-15.txt, April 475 2004. 477 6.2. Informative References 479 [RFC1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 480 51, RFC 1661, Daydreamer, July 1994. 482 [RFC1918] Rekhter, Y., et al., "Address Allocation for Private 483 Internets", RFC 1918, February 1996. 485 [RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA 486 Considerations Section in RFCs", BCP 26, RFC 2434, October 487 1998. 489 [RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 490 for IP Version 6 (IPv6)", RFC 2461, December 1998. 492 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 493 Autoconfiguration", RFC 2462, December 1998. 495 [MIPv6] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 496 IPv6", draft-ietf-mobileip-ipv6-24.txt, June 2003. 498 [RFC3580] Congdon, P., et al., "IEEE 802.1X Remote Authentication Dial 499 In User Service (RADIUS) Usage Guidelines", RFC 3580, 500 September 2003. 502 [RFC3748] Blunk, L., et al., "Extensible Authentication Protocol (EAP)", 503 RFC 3748, March 2004. 505 [IEEE8021AB] 506 IEEE Standards for Local and Metropolitan Area Networks: 507 Station and Media Access Control - Connectivity Discovery, 508 IEEE Std 802.1AB/D5, September 2003. 510 [IEEE8021X] 511 IEEE Standards for Local and Metropolitan Area Networks: Port 512 based Network Access Control, IEEE Std 802.1X-2004, June 2004. 514 [IEEE802] IEEE Standards for Local and Metropolitan Area Networks: 515 Overview and Architecture, ANSI/IEEE Std 802, 1990. 517 [IEEE8021Q] 518 IEEE Standards for Local and Metropolitan Area Networks: Draft 519 Standard for Virtual Bridged Local Area Networks, P802.1Q, 520 January 1998. 522 [IEEE80211] 523 Information technology - Telecommunications and information 524 exchange between systems - Local and metropolitan area 525 networks - Specific Requirements Part 11: Wireless LAN Medium 526 Access Control (MAC) and Physical Layer (PHY) Specifications, 527 IEEE Std. 802.11-1999, 1999. 529 Acknowledgments 531 The authors would like to acknowledge Greg Daley of Monash 532 University, Erik Guttman and Erik Nordmark of Sun Microsystems, Ted 533 Lemon of Nominum and Thomas Narten of IBM for contributions to this 534 document. 536 Authors' Addresses 538 Bernard Aboba 539 Microsoft Corporation 540 One Microsoft Way 541 Redmond, WA 98052 543 EMail: bernarda@microsoft.com 544 Phone: +1 425 706 6605 545 Fax: +1 425 936 7329 547 Appendix A - Link Layer Hints 549 A.1 Introduction 551 In order to assist in IPv4 network attachment detection, information 552 associated with each network may be retained by the host. Based on 553 link-layer information, the host may be able to make an educated 554 guess as to whether it has moved between subnets, or has remained on 555 the same subnet, as well as whether it has connected to an 556 infrastructure or adhoc network. 558 If the host is likely to have moved between subnets, it may be 559 possible to make an educated guess as to which subnet it has moved 560 to. Since an educated guess may be incorrect, prior to concluding 561 that the host remains on the same subnet, further tests (such as a 562 reachability test or a DHCPREQUEST sent from the INIT-REBOOT state) 563 are REQUIRED. 565 In practice, it is necessary for hints to be highly reliable before 566 they are worth considering, if the penalty paid for an incorrect hint 567 is substantial. 569 As an example, assume that a DHCPREQUEST requires DHCPREQUEST_TIME to 570 determine if a host has remained on the same subnet, while a 571 reachability test typically completes in REACH_TIME and times out in 572 REACHABILITY_TIMEOUT, after which a DHCPREQUEST is sent. 574 If a hint that the host has remained on the same subnet is wrong x 575 fraction of the time, then it is only worth considering if: 577 DHCPREQUEST_TIME = (1 - x) * REACH_TIME + 579 x * (REACHABILITY_TIMEOUT + DHCPREQUEST_TIME) 581 x = DHCPREQUEST_TIME - REACH_TIME 582 ---------------------------------------------------- 583 REACHABILITY_TIMEOUT + DHCPREQUEST_TIME - REACH_TIME 585 If we assume that DHCPREQUEST_TIME = 100 ms, REACH_TIME = 10 ms, and 586 REACHABILITY_TIMEOUT = 1000ms, then: 588 x = (100 - 10)/(1000 + 100 - 10) = 8.2 percent 590 Therefore the hint need only be wrong 8.2 percent of the time before 591 it is not worth considering. 593 A.2 Hints 595 For networks running IPv4 over PPP [RFC1661], IPv4 parameters 596 negotiated in IPCP provide direct information on whether a previously 597 obtained address remains valid on the link. 599 On IEEE 802 [IEEE802] wired networks, hints include link-layer 600 discovery traffic as well as information exchanged as part of IEEE 601 802.1X authentication [IEEE8021X]. 603 Link-layer discovery traffic includes Link Layer Discovery Protocol 604 (LLDP) [IEEE8021AB] traffic as well as network identification 605 information passed in the EAP-Request/Identity or within an EAP 606 method exchange, as defined in EAP [RFC3748]. 608 For example, LLDP advertisements can provide information on VLANs 609 supported by the device. When used with IEEE 802.1X authentication 610 [IEEE8021X], the EAP-Request/Identity exchange may contain the name 611 of the authenticator, also providing information on the potential 612 network. Similarly, during the EAP method exchange the authenticator 613 may supply information that may be helpful in identifying the network 614 to which the device is attached. However, as noted in [RFC3580], it 615 is possible for the VLANID defined in [IEEE8021Q] to be assigned 616 dynamically, so that static advertisements may not prove definitive. 618 In IEEE 802.11 [IEEE80211] stations provide information in Beacon 619 and/or Probe Response messages, such as the SSID, BSSID, and 620 capabilities, as well as information on whether the station is 621 operating in Infrastructure or Ad hoc mode. As described in 622 [RFC3580], it is possible to assign a Station to a VLAN dynamically, 623 based on the results of IEEE 802.1X [IEEE8021X] authentication. This 624 implies that a single SSID may offer access to multiple VLANs, and in 625 practice most large WLAN deployments offer access to multiple 626 subnets. 628 Thus, associating to the same SSID is a necessary, but not 629 necessarily a sufficient condition, for remaining within the same 630 subnet: while a Station associating to the same SSID may not 631 necessarily remain within the same subnet, a Station associating to a 632 different SSID is likely to have changed subnets. 634 In IEEE 802.11, the SSID is a non-unique identifier, and SSIDs such 635 as "default", "linksys" and "tsunami" are often configured by 636 manufacturers by default. As a result, matching an advertised SSID 637 against those of previously encountered networks may be misleading. 638 Where an SSID known to be configured by default is encountered, it is 639 recommended that the BSSID be stored and subsequently compared 640 against the advertised BSSID to determine whether a match exists. 642 In order to provide additional guidance on the subnets to which a 643 given AP offers access, additional subnet-related Information 644 Elements (IEs) have been proposed for addition to the IEEE 802.11 645 Beacon and Probe Response messages. As noted earlier, VLANs may be 646 determined dynamically so that these information elements may not be 647 reliable. 649 In IEEE 802.11, the presence of an IBSS can be used as a hint that a 650 point of attachment supports adhoc networking, and therefore that 651 assignment of a Link-Local IPv4 address is likely. When running IPv4 652 over PPP, if an IP address is not statically configured or assigned 653 via IPCP, this can also be taken as a hint that assignment of a Link- 654 Local IPv4 address is likely. In addition, certain media such as USB 655 or IEEE 1394 may be considered inherently more likely to support 656 adhoc operation, so that connection to these networks may by itself 657 be considered a hint. 659 Intellectual Property 661 The IETF takes no position regarding the validity or scope of any 662 intellectual property or other rights that might be claimed to 663 pertain to the implementation or use of the technology described in 664 this document or the extent to which any license under such rights 665 might or might not be available; neither does it represent that it 666 has made any effort to identify any such rights. Information on the 667 IETF's procedures with respect to rights in standards-track and 668 standards-related documentation can be found in BCP-11. Copies of 669 claims of rights made available for publication and any assurances of 670 licenses to be made available, or the result of an attempt made to 671 obtain a general license or permission for the use of such 672 proprietary rights by implementors or users of this specification can 673 be obtained from the IETF Secretariat. 675 The IETF invites any interested party to bring to its attention any 676 copyrights, patents or patent applications, or other proprietary 677 rights which may cover technology that may be required to practice 678 this standard. Please address the information to the IETF Executive 679 Director. 681 Full Copyright Statement 683 Copyright (C) The Internet Society (2004). All Rights Reserved. 685 This document and translations of it may be copied and furnished to 686 others, and derivative works that comment on or otherwise explain it 687 or assist in its implementation may be prepared, copied, published 688 and distributed, in whole or in part, without restriction of any 689 kind, provided that the above copyright notice and this paragraph are 690 included on all such copies and derivative works. However, this 691 document itself may not be modified in any way, such as by removing 692 the copyright notice or references to the Internet Society or other 693 Internet organizations, except as needed for the purpose of 694 developing Internet standards in which case the procedures for 695 copyrights defined in the Internet Standards process must be 696 followed, or as required to translate it into languages other than 697 English. The limited permissions granted above are perpetual and 698 will not be revoked by the Internet Society or its successors or 699 assigns. This document and the information contained herein is 700 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 701 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 702 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 703 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 704 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 706 Open issues 708 Open issues relating to this specification are tracked on the 709 following web site: 711 http://www.drizzle.com/~aboba/DNA/dnaissues.html 713 Expiration Date 715 This memo is filed as , and expires 716 October 22, 2004.