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