idnits 2.17.1 draft-ietf-dhc-dna-ipv4-09.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 3667, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 686. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 692), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(A) Disclaimer.) ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(B) IPR Disclosure Invitation.) ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 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 649 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 (14 October 2004) is 7131 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) == Missing Reference: 'IPv4LL' is mentioned on line 416, but not defined -- Looks like a reference, but probably isn't: '1' on line 180 -- Looks like a reference, but probably isn't: '2' on line 183 -- Looks like a reference, but probably isn't: '3' on line 186 == Unused Reference: 'RFC3927' is defined on line 477, but no explicit reference was found in the text Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 7 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 14 October 2004 8 Detection of Network Attachment (DNA) in IPv4 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 and any of which I become aware will be disclosed, in accordance with 13 RFC 3668. 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 April 22, 2005. 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 39 The time required to detect movement (or lack of movement) between 40 subnets, and to obtain (or continue to use) a valid IPv4 address may 41 be significant as a fraction of the total delay in moving between 42 points of attachment. This document synthesizes experience garnered 43 over the years in the deployment of hosts supporting ARP, DHCP and 44 IPv4 Link-Local addresses. A procedure is specified for detection of 45 network attachment in order to better accommodate mobile hosts. 47 Table of Contents 49 1. Introduction.............................................. 3 50 1.1 Requirements .................................... 3 51 1.2 Terminology ..................................... 3 52 2. Framework ................................................ 4 53 2.1 Most Likely Point of Attachment ................. 5 54 2.2 Reachability Test ............................... 6 55 2.3 IPv4 Address Acquisition ........................ 8 56 2.4 IPv4 Link-Local Addresses ....................... 9 57 3. Constants ................................................ 10 58 4. IANA Considerations ...................................... 10 59 5. Security Considerations .................................. 10 60 6. References ............................................... 11 61 6.1 Normative references ............................ 11 62 6.2 Informative references .......................... 11 63 Acknowledgments .............................................. 12 64 Authors' Addresses ........................................... 12 65 Appendix A - Link Layer Hints ................................ 13 66 A.1 Introduction .................................... 13 67 A.2 Hints ........................................... 14 68 Intellectual Property Statement .............................. 15 69 Disclaimer of Validity ....................................... 15 70 Copyright Statement .......................................... 16 71 1. Introduction 73 The time required to detect movement (or lack of movement) between 74 subnets, and to obtain (or continue to use) a valid IPv4 address may 75 be significant as a fraction of the total delay in moving between 76 points of attachment. As a result, optimizing detection of network 77 attachment is important for mobile hosts. 79 This document synthesizes experience in the deployment of hosts 80 supporting ARP [RFC826], DHCP [RFC2131], and IPv4 Link-Local 81 addresses [IPv4LL], specifying a procedure to be performed for IPv4 82 detection of network attachment. The procedure consists of three 83 phases: determination of the Most Likely Point of Attachment (MLPA), 84 reachability testing, and IPv4 address acquisition. 86 Since this procedure is dependent on the ARP protocol, it is not 87 suitable for use on media that do not support ARP [RFC826]. 89 1.1. Requirements 91 In this document, several words are used to signify the requirements 92 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 93 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 94 and "OPTIONAL" in this document are to be interpreted as described in 95 [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 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 Point of Attachment 130 A location within the network where a host may be connected. This 131 attachment point can be characterized by its address prefix and 132 next hop routing information. 134 Most Likely Point of Attachment (MLPA) 135 The point of attachment heuristically determined by the host to be 136 most likely, based on hints from the network. 138 Routable address 139 In this specification, the term "routable address" refers to any 140 address other than an IPv4 Link-Local address. This includes 141 private addresses as specified in [RFC1918]. 143 Valid address 144 In this specification, the term "valid address" refers to either a 145 static IPv4 address, or an address assigned via DHCPv4 which has 146 not been relinquished, and whose lease has not yet expired. 148 2. Framework 150 For Detection of Network Attachment (DNA), the following basic 151 principles are suggested: 153 [a] Utilization of hints. As described in Appendix A, 154 link layers may provide hints as to whether a 155 host remains on the same subnet, despite changing 156 its point of attachment. Based on these hints, 157 the host determines the "Most Likely Point of 158 Attachment" (MLPA), and the corresponding 159 configuration associated with it. Since 160 hints may be misleading, it is important for 161 the host to make the correct determination even 162 where hints are misleading. 164 [b] Response to "Link Up" indications. On connecting 165 to a new point of attachment, the host attempts to 166 verify the configuration associated with the MLPA. 168 [c] Handling of IPv4 Link-Local addresses. Experience has 169 shown that IPv4 Link-Local addresses are often assigned 170 inappropriately. This document suggests that hosts 171 behave conservatively with respect to assignment of 172 IPv4 Link-Local addresses, configuring them only in 173 situations in which they can do no harm. 175 2.1. Most Likely Point of Attachment 177 In order to determine the MLPA, it is assumed that the host saves to 178 stable storage parameters relating to the networks it connects to: 180 [1] Link layer hints associated with each network. 181 For details, see Appendix A. 183 [2] The IPv4 and MAC address of the default gateway(s) on 184 each network. 186 [3] The link type, such as whether the link utilizes 187 Ethernet, or 802.11 adhoc or infrastructure mode. 189 By matching received hints against network parameters previously 190 stored, the host makes an an educated guess of which network it has 191 attached to. In the absence of other information, the MLPA defaults 192 to the network to which the host was most recently attached. 194 2.1.1. Alternative Mechanisms 196 Aside from utilizing link layer indications, a host may also be able 197 to utilize Internet layer information in order to determine the MLPA. 199 IPv4 ICMP Router Discovery messages [RFC1256] provide information 200 relating to prefix(es) available on the link, as well as the routers 201 that serve those prefix(es). A host may use ICMP Router Discovery to 202 conclude that an advertised prefix is available; however it cannot 203 conclude the converse -- that prefixes not advertised are 204 unavailable. 206 However, since [RFC1256] is not widely implemented, in general, it is 207 NOT RECOMMENDED that hosts utilize ICMP Router Discovery messages as 208 an alternative to the reachability test outlined in Section 2.2. 209 Instead, ICMP Router Advertisements can be used to obtain information 210 on available prefixes and default gateway(s). This can provide 211 additional resilience in the case where default gateway(s) become 212 unavailable. 214 Similarly hosts that support routing protocols such as RIP and OSPF 215 can use these protocols to determine the prefix(es) available on a 216 link and the default gateway(s) that serve those prefixes. Full 217 support is not required to glean this information. A host that 218 passively observes routing protocol traffic may deduce this 219 information without supporting a fully conformant routing protocol 220 implementation. 222 2.2. Reachability Test 224 If the host has a valid routable IPv4 address on the MLPA, the host 225 SHOULD perform a reachability test, in order to to confirm that it is 226 connected to network on which it has a valid routable IPv4 address. 227 If the reachability test is not successful, the host proceeds to the 228 IPv4 address acquisition phase, described in Section 2.3. 230 The host skips the reachability test and proceeds to the IPv4 address 231 acquisition phase if any of the following conditions are true: 233 [a] The host does not have a valid routable IPv4 234 address on the MLPA. In this case, the reachability 235 test cannot confirm that the host has a valid 236 routable IPv4 address, so that completing the 237 reachability test would serve no purpose. 239 [b] The host does not have information on the default 240 gateway(s) on the MLPA. In this case, insufficient 241 information is available to carry out the reachability 242 test. 244 [c] Reliable hints are unavailable. Since confirming 245 failure of the reachability test requires a timeout, 246 mistakes are costly. In the absence of reliable 247 hints, a host SHOULD instead send a DHCPREQUEST from 248 the INIT-REBOOT state, as described in [RFC2131], 249 Section 3.2 and 4.3.2. Where reliable hints are 250 unavailable, this will typically complete more 251 quickly than the reachability test. 253 [d] If secure detection of network attachment is required. 254 The reachability test utilizes ARP which is insecure, 255 whereas DHCP can be secured via DHCP authentication, 256 described in [RFC3118]. See Section 5 for details. 258 In contrast to a DHCP exchange, which may be between a DHCP client 259 and an off-link DHCP server, the reachability test is designed to 260 verify bi-directional connectivity to the default gateway(s) on the 261 MLPA. 263 The host MAY probe only the primary default gateway, or it MAY probe 264 primary and secondary default gateways, in series or in parallel. If 265 the reachability test is successful, the host MAY continue to use a 266 valid routable IPv4 address without having to re-acquire it. This 267 reduces roaming latency by allowing the host to bypass DHCP as well 268 as subsequent Duplicate Address Detection (DAD). In order to ensure 269 configuration validity, the host SHOULD only configure default 270 gateway(s) which pass the reachability test. 272 2.2.1. Packet Format 274 The reachability test is performed by sending an ARP Request. The 275 ARP Request SHOULD use the host's MAC address as the source, and the 276 broadcast MAC address as the destination. The host sets the target 277 protocol address (ar$tpa) to the IPv4 address of the primary default 278 gateway, and uses its own MAC address in the sender hardware address 279 field (ar$sha). The host sets the target hardware address field 280 (ar$tha) to 0. 282 If the host has a valid routable IPv4 address on the most likely 283 point of attachment, then it SHOULD set the sender protocol address 284 field (ar$spa) to that address. It is assumed that the host had 285 previously done duplicate address detection so that an address 286 conflict is unlikely. 288 However if the host has a private address as defined in [RFC1918], 289 then it SHOULD set the sender protocol address field (ar$spa) to the 290 unspecified address (0.0.0.0). This is to avoid an address conflict 291 in the case where the host has changed its point of attachment from 292 one private network to another. 294 Note: Some routers may refuse to answer an ARP Request sent with 295 the sender protocol address field (ar$spa) set to the unspecified 296 address (0.0.0.0). In this case the reachability test will fail. 298 If a valid ARP Response is received, the MAC address in the sender 299 hardware address field (ar$sha) and the IPv4 address in the sender 300 protocol address field (ar$spa) are matched against the list of 301 networks and associated default gateway parameters. If a match is 302 found, then if the host has a valid routable IPv4 address on the 303 matched network, the host continues to use that IPv4 address, subject 304 to the lease re-acquisition and expiration behavior described in 305 [RFC2131], Section 4.4.5. 307 Checking for a match on both the IPv4 address and MAC address of the 308 default gateway enables the host to confirm reachability even where 309 it has moved between two private networks. In this case the IPv4 310 address of the default gateway could remain the same, while the MAC 311 address would change, so that both addresses need to be checked. 313 Sending an ICMP Echo Request [RFC792] to the default gateway IPv4 314 address does not provide the same level of assurance since this 315 requires an ARP Request/Response to be sent first, and typically does 316 not allow the MAC address to be checked as well. It therefore SHOULD 317 NOT be used as a substitute. 319 Where a host moves from one private network to another, an ICMP Echo 320 Request can result in an ICMP Echo Response even when the default 321 gateway has changed, as long as the IPv4 address remains the same. 322 This can occur, for example, where a host moves from one home 323 network using prefix 192.168/16 to another one. In addition, if the 324 ping is sent with TTL > 1, then an ICMP Echo Response can be received 325 from an off-link gateway. 327 If the initial ARP Request does not elicit a Response, the host waits 328 for REACHABILITY_TIMEOUT and proceeds to the IPv4 address acquisition 329 phase. If a valid ARP Response is received, but cannot be matched 330 against known networks, the host assumes it has moved subnets and 331 moves on to the IPv4 address acquisition phase. 333 2.3. IPv4 Address Acquisition 335 If the host has a valid routable IPv4 address on the MLPA but the 336 reachability test fails, the host SHOULD verify the configuration by 337 entering the INIT-REBOOT state, and sending a DHCPREQUEST to the 338 broadcast address as specified in [RFC2131] Section 4.4.2. 340 If the host does not have a valid routable IPv4 address on the MLPA, 341 the host enters the INIT state and sends a DHCPDISCOVER packet to the 342 broadcast address, as described in [RFC2131] Section 4.4.1. If the 343 host supports the Rapid Commit Option [RAPID], it is possible that 344 the exchange can be shortened from a 4-message exchange to a 345 2-message exchange. 347 If the host does not receive a response to a DHCPREQUEST or 348 DHCPDISCOVER, then it retransmits as specified in [RFC2131] Section 349 4.1. 351 As discussed in [RFC2131], Section 4.4.4, a host in INIT or REBOOTING 352 state that knows the address of a DHCP server may use that address in 353 the DHCPDISCOVER or DHCPREQUEST rather than the IPv4 broadcast 354 address. In the INIT-REBOOT state a DHCPREQUEST is sent to the 355 broadcast address so that the host will receive a response regardless 356 of whether the previously configured IPv4 address is correct for the 357 network to which it has connected. 359 Sending a DHCPREQUEST to the unicast address in INIT-REBOOT state is 360 not appropriate, since if the DHCP client has moved to another 361 subnet, a DHCP server response cannot be routed back to the client 362 since the DHCPREQUEST will bypass the DHCP relay and will contain an 363 invalid source address. 365 2.4. IPv4 Link-Local Addresses 367 To avoid inappropriate assignment of IPv4 Link-Local addresses, it is 368 recommended that hosts behave conservatively with respect to 369 assignment of IPv4 Link-Local addresses. As described in [IPv4LL] 370 Section 1.7, use of a routable address is preferred to a IPv4 Link- 371 Local address whenever it is available. 373 Where the host does not have a valid routable IPv4 address on the 374 MLPA, the host MAY configure an IPv4 Link-Local address prior to 375 entering the INIT state and sending a DHCPDISCOVER packet, as 376 described in Section 2.3. However, should a routable IPv4 address be 377 obtained, the IPv4 Link-Local address is deprecated, as noted in 378 [IPv4LL]. 380 Where a host has a valid routable IPv4 address on the MLPA, but the 381 DHCP client does not receive a response after employing the 382 retransmission algorithm, [RFC2131] Section 3.2 states that the 383 client MAY choose to use the previously allocated network address and 384 configuration parameters for the remainder of the unexpired lease. 385 Where a host can confirm that it remains connected to a point of 386 attachment on which it possesses a valid routable IPv4 address, that 387 address SHOULD be used, rather than assigning a IPv4 Link-Local 388 address. 390 Since a IPv4 Link-Local address is often configured because a DHCP 391 server failed to respond to an initial query or is inoperative for 392 some time, it is desirable to abandon the IPv4 Link-Local address 393 assignment as soon as a valid IPv4 address lease can be obtained. 395 As described in [IPv4LL] Appendix A, once a Link-Local IPv4 address 396 is assigned, existing implementations do not query the DHCPv4 server 397 again for 5 minutes. This behavior violates [RFC2131] Section 4.1. 399 Where a IPv4 Link-Local address is assigned, experience has shown 400 that five minutes (see [IPv4LL] Appendix A.2) is too long an interval 401 to wait until retrying to obtain a routable IPv4 address using DHCP. 402 According to [RFC2131] Section 4.1: 404 The retransmission delay SHOULD be doubled with 405 subsequent retransmissions up to a maximum of 64 seconds. 407 As a result, a DHCP client compliant with [RFC2131] will continue to 408 retry every 64 seconds, even after allocating a IPv4 Link-Local 409 address. Should the DHCP client succeed in obtaining a routable 410 address, then as noted in [IPv4LL], the IPv4 Link-Local address is 411 deprecated. 413 Since it is inevitable that hosts will inappropriately configure IPv4 414 Link-Local addresses at some point, hosts with routable IPv4 415 addresses SHOULD be able to respond to peers with IPv4 Link-Local 416 addresses, as per [IPv4LL]. For example, a host configured with a 417 routable address may receive a datagram from a link-local source 418 address. In order to respond, the host will use ARP to resolve the 419 target hardware address and send the datagram directly, not to a 420 router for forwarding. 422 3. Constants 424 The suggested default value of REACHABILITY_TIMEOUT is 200 ms. This 425 value was chosen so as to accommodate the maximum retransmission 426 timer likely to be experienced on an Ethernet network. 428 4. IANA Considerations 430 This specification does not request the creation of any new parameter 431 registries, nor does it require any other IANA assignments. 433 5. Security Considerations 435 Detection of Network Attachment (DNA) is based on ARP and DHCP. ARP 436 [RFC826] traffic is inherently insecure, so that the reachability 437 test described in Section 1.3 can be easily spoofed by an attacker, 438 leading a host to falsely conclude that it is attached to a network 439 that it is not connected to. Similarly, where DHCP traffic is not 440 secured, an attacker could masquerade as a DHCP server, in order to 441 convince the host that it was attached to a particular network. 443 As a result, it is inadvisable for a host to adjust its security 444 based on which network it believes it is attached to. For example, 445 it would be inappropriate for a host to disable its personal firewall 446 based on the belief that it had connected to a home network. 448 Where secure detection of network attachment is required, a host 449 SHOULD skip the reachability test since it cannot be secured, and 450 instead utilize authenticated DHCP [RFC3118], possibly in combination 451 with the Rapid Commit Option [RAPID]. 453 6. References 455 6.1. Normative References 457 [RFC792] Postel, J., "Internet Control Message Protocol", RFC 792, 458 USC/Information Sciences Institute, September 1981. 460 [RFC826] D. Plummer, "An Ethernet Address Resolution Protocol -or- 461 Converting Network Addresses to 48-bit Ethernet Address for 462 Transmission on Ethernet Hardware", STD 37, RFC 826, November 463 1982. 465 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, Xerox 466 PARC, September 1991. 468 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 469 Requirement Levels", RFC 2119, March, 1997. 471 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 472 March 1997. 474 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", 475 RFC 3118, June 2001. 477 [RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration 478 of IPv4 Link-Local Addresses", RFC 3927, October 2004. 480 6.2. Informative References 482 [RFC1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 483 51, RFC 1661, Daydreamer, July 1994. 485 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and 486 E. Lear, "Address Allocation for Private Internets", RFC 1918, 487 February 1996. 489 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, 490 "IEEE 802.1X Remote Authentication Dial In User Service 491 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 493 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 494 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 495 3748, June 2004. 497 [RAPID] Park, S., Kim, P., and B. Volz, "Rapid Commit Option for 498 DHCPv4", Internet draft (work in progress), draft-ietf-dhc- 499 rapid-commit-opt-05.txt, June 2004. 501 [IEEE8021AB] 502 IEEE Standards for Local and Metropolitan Area Networks: 503 Station and Media Access Control - Connectivity Discovery, 504 IEEE Std 802.1AB/D5, September 2003. 506 [IEEE8021X] 507 IEEE Standards for Local and Metropolitan Area Networks: Port 508 based Network Access Control, IEEE Std 802.1X-2004, November 509 2004. 511 [IEEE802] IEEE Standards for Local and Metropolitan Area Networks: 512 Overview and Architecture, ANSI/IEEE Std 802, 1990. 514 [IEEE8021Q] 515 IEEE Standards for Local and Metropolitan Area Networks: Draft 516 Standard for Virtual Bridged Local Area Networks, P802.1Q, 517 January 1998. 519 [IEEE80211] 520 Information technology - Telecommunications and information 521 exchange between systems - Local and metropolitan area 522 networks - Specific Requirements Part 11: Wireless LAN Medium 523 Access Control (MAC) and Physical Layer (PHY) Specifications, 524 IEEE Std. 802.11-2003, 2003. 526 Acknowledgments 528 The authors would like to acknowledge Greg Daley of Monash 529 University, Erik Guttman and Erik Nordmark of Sun Microsystems, Ted 530 Lemon of Nominum and Thomas Narten of IBM for contributions to this 531 document. 533 Authors' Addresses 535 Bernard Aboba 536 Microsoft Corporation 537 One Microsoft Way 538 Redmond, WA 98052 540 EMail: bernarda@microsoft.com 541 Phone: +1 425 706 6605 542 Fax: +1 425 936 7329 544 Appendix A - Link Layer Hints 546 A.1 Introduction 548 In order to assist in IPv4 network attachment detection, information 549 associated with each network may be retained by the host. Based on 550 link-layer information, the host may be able to make an educated 551 guess as to whether it has moved between subnets, or has remained on 552 the same subnet, as well as whether it has connected to an 553 infrastructure or adhoc network. 555 If the host is likely to have moved between subnets, it may be 556 possible to make an educated guess as to which subnet it has moved 557 to. Since an educated guess may be incorrect, prior to concluding 558 that the host remains on the same subnet, further tests (such as a 559 reachability test or a DHCPREQUEST sent from the INIT-REBOOT state) 560 are REQUIRED. 562 In practice, it is necessary for hints to be highly reliable before 563 they are worth considering, if the penalty paid for an incorrect hint 564 is substantial. 566 As an example, assume that a DHCPREQUEST requires DHCPREQUEST_TIME to 567 determine if a host has remained on the same subnet, while a 568 reachability test typically completes in REACH_TIME and times out in 569 REACHABILITY_TIMEOUT, after which a DHCPREQUEST is sent. 571 If a hint that the host has remained on the same subnet is wrong x 572 fraction of the time, then it is only worth considering if: 574 DHCPREQUEST_TIME = (1 - x) * REACH_TIME + 576 x * (REACHABILITY_TIMEOUT + DHCPREQUEST_TIME) 578 x = DHCPREQUEST_TIME - REACH_TIME 579 ---------------------------------------------------- 580 REACHABILITY_TIMEOUT + DHCPREQUEST_TIME - REACH_TIME 582 If we assume that DHCPREQUEST_TIME = 100 ms, REACH_TIME = 10 ms, and 583 REACHABILITY_TIMEOUT = 1000ms, then: 585 x = (100 - 10)/(1000 + 100 - 10) = 8.2 percent 587 Therefore the hint need only be wrong 8.2 percent of the time before 588 it is not worth considering. 590 A.2 Hints 592 For networks running IPv4 over PPP [RFC1661], IPv4 parameters 593 negotiated in IPCP provide direct information on whether a previously 594 obtained address remains valid on the link. 596 On IEEE 802 [IEEE802] wired networks, hints include link-layer 597 discovery traffic as well as information exchanged as part of IEEE 598 802.1X authentication [IEEE8021X]. 600 Link-layer discovery traffic includes Link Layer Discovery Protocol 601 (LLDP) [IEEE8021AB] traffic as well as network identification 602 information passed in the EAP-Request/Identity or within an EAP 603 method exchange, as defined in EAP [RFC3748]. 605 For example, LLDP advertisements can provide information on VLANs 606 supported by the device. When used with IEEE 802.1X authentication 607 [IEEE8021X], the EAP-Request/Identity exchange may contain the name 608 of the authenticator, also providing information on the potential 609 network. Similarly, during the EAP method exchange the authenticator 610 may supply information that may be helpful in identifying the network 611 to which the device is attached. However, as noted in [RFC3580], it 612 is possible for the VLANID defined in [IEEE8021Q] to be assigned 613 dynamically, so that static advertisements may not prove definitive. 615 In IEEE 802.11 [IEEE80211] stations provide information in Beacon 616 and/or Probe Response messages, such as the SSID, BSSID, and 617 capabilities, as well as information on whether the station is 618 operating in Infrastructure or Ad hoc mode. As described in 619 [RFC3580], it is possible to assign a Station to a VLAN dynamically, 620 based on the results of IEEE 802.1X [IEEE8021X] authentication. This 621 implies that a single SSID may offer access to multiple VLANs, and in 622 practice most large WLAN deployments offer access to multiple 623 subnets. 625 Thus, associating to the same SSID is a necessary, but not 626 necessarily a sufficient condition, for remaining within the same 627 subnet: while a Station associating to the same SSID may not 628 necessarily remain within the same subnet, a Station associating to a 629 different SSID is likely to have changed subnets. 631 In IEEE 802.11, the SSID is a non-unique identifier, and SSIDs such 632 as "default", "linksys" and "tsunami" are often configured by 633 manufacturers by default. As a result, matching an advertised SSID 634 against those of previously encountered networks may be misleading. 635 Where an SSID known to be configured by default is encountered, it is 636 recommended that the BSSID be stored and subsequently compared 637 against the advertised BSSID to determine whether a match exists. 639 In order to provide additional guidance on the subnets to which a 640 given AP offers access, additional subnet-related Information 641 Elements (IEs) have been proposed for addition to the IEEE 802.11 642 Beacon and Probe Response messages. As noted earlier, VLANs may be 643 determined dynamically so that these information elements may not be 644 reliable. 646 In IEEE 802.11, the presence of an IBSS can be used as a hint that a 647 point of attachment supports adhoc networking, and therefore that 648 assignment of a IPv4 Link-Local address is likely. When running IPv4 649 over PPP, if an IP address is not statically configured or assigned 650 via IPCP, this can also be taken as a hint that assignment of an IPv4 651 Link-Local address is likely. In addition, certain media such as USB 652 or IEEE 1394 may be considered inherently more likely to support 653 adhoc operation, so that connection to these networks may by itself 654 be considered a hint. 656 Intellectual Property Statement 658 The IETF takes no position regarding the validity or scope of any 659 intellectual property or other rights that might be claimed to 660 pertain to the implementation or use of the technology described in 661 this document or the extent to which any license under such rights 662 might or might not be available; neither does it represent that it 663 has made any effort to identify any such rights. Information on the 664 IETF's procedures with respect to rights in standards-track and 665 standards-related documentation can be found in BCP-11. Copies of 666 claims of rights made available for publication and any assurances of 667 licenses to be made available, or the result of an attempt made to 668 obtain a general license or permission for the use of such 669 proprietary rights by implementors or users of this specification can 670 be obtained from the IETF Secretariat. 672 The IETF invites any interested party to bring to its attention any 673 copyrights, patents or patent applications, or other proprietary 674 rights which may cover technology that may be required to practice 675 this standard. Please address the information to the IETF Executive 676 Director. 678 Disclaimer of Validity 680 This document and the information contained herein are provided on an 681 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 682 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 683 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 684 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 685 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 686 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 688 Copyright Statement 690 Copyright (C) The Internet Society (2004). This document is subject 691 to the rights, licenses and restrictions contained in BCP 78, and 692 except as set forth therein, the authors retain all their rights. 694 Open issues 696 Open issues relating to this specification are tracked on the 697 following web site: 699 http://www.drizzle.com/~aboba/DNA/dnaissues.html