idnits 2.17.1 draft-ietf-dhc-dna-ipv4-10.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 12. -- Found old boilerplate from RFC 3978, Section 5.5 on line 723. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 729), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 34. ** 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 16 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 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 686 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 (25 March 2005) is 6973 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 453, but not defined -- Looks like a reference, but probably isn't: '1' on line 208 -- Looks like a reference, but probably isn't: '2' on line 211 -- Looks like a reference, but probably isn't: '3' on line 214 == Unused Reference: 'RFC3927' is defined on line 514, 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. -------------------------------------------------------------------------------- 1 DHC Working Group Bernard Aboba 2 INTERNET-DRAFT Microsoft Corporation 3 Category: Proposed Standard 4 5 25 March 2005 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 3668. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on October 22, 2005. 32 Copyright Notice 34 Copyright (C) The Internet Society (2005). All Rights Reserved. 36 Abstract 38 The time required to detect movement (or lack of movement) between 39 subnets, and to obtain (or continue to use) a valid IPv4 40 configuration may be significant as a fraction of the total delay in 41 moving between points of attachment. This document specifies a 42 procedure for optimizing the detection of network attachment and IP 43 configuration in order to decrease the delay in moving between points 44 of attachment. 46 Table of Contents 48 1. Introduction.............................................. 3 49 1.1 Requirements .................................... 3 50 1.2 Terminology ..................................... 3 51 2. Overview ................................................. 4 52 2.1 Most Likely Point of Attachment ................. 5 53 2.2 Reachability Test ............................... 6 54 2.3 IPv4 Address Acquisition ........................ 9 55 2.4 IPv4 Link-Local Addresses ....................... 9 56 3. Constants ................................................ 11 57 4. IANA Considerations ...................................... 11 58 5. Security Considerations .................................. 11 59 6. References ............................................... 11 60 6.1 Normative references ............................ 11 61 6.2 Informative references .......................... 12 62 Acknowledgments .............................................. 13 63 Authors' Addresses ........................................... 13 64 Appendix A - Link Layer Hints ................................ 14 65 A.1 Introduction .................................... 14 66 A.2 Hints ........................................... 15 67 Intellectual Property Statement .............................. 16 68 Disclaimer of Validity ....................................... 16 69 Copyright Statement .......................................... 17 70 1. Introduction 72 The time required to detect movement (or lack of movement) between 73 subnets, and to obtain (or continue to use) a valid IPv4 address may 74 be significant as a fraction of the total delay in moving between 75 points of attachment. As a result, optimizing detection of network 76 attachment is important for mobile hosts. 78 This document synthesizes experience in the deployment of hosts 79 supporting ARP [RFC826], DHCP [RFC2131], and IPv4 Link-Local 80 addresses [IPv4LL], specifying a procedure for optimizing detection 81 of network attachment and IPv4 configuration, in order to minimize 82 the latency in moving between points of attachment. Since this 83 procedure is dependent on the ARP protocol, it is not suitable for 84 use on media that do not support ARP [RFC826]. 86 1.1. Requirements 88 In this document, several words are used to signify the requirements 89 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 90 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 91 and "OPTIONAL" in this document are to be interpreted as described in 92 [RFC2119]. 94 1.2. Terminology 96 This document uses the following terms: 98 ar$sha 99 ARP packet field: Source Hardware Address [RFC826]. The hardware 100 (MAC) address of the originator of an ARP packet. 102 ar$spa 103 ARP packet field: Source Protocol Address [RFC826]. For IP Address 104 Resolution this is the IPv4 address of the sender of the ARP 105 packet. If the sender address is unknown, this is set to 0.0.0.0. 107 ar$tha 108 ARP packet field: Target Hardware Address [RFC826]. The hardware 109 (MAC) address of the target of an ARP packet, or the broadcast 110 address if the target hardware address is unknown. 112 ar$tpa 113 ARP packet field: Target Protocol Address [RFC826]. For IPv4 114 Address Resolution, the IPv4 address for which one desires to know 115 the hardware address. 117 DHCP client 118 A DHCP client or "client" is an Internet host using the Dynamic 119 Host Configuration protocol (DHCP) [RFC2131] to obtain 120 configuration parameters such as a network address. 122 DHCP server 123 A DHCP server or "server" is an Internet host that returns 124 configuration parameters to DHCP clients. 126 Point of Attachment 127 A location within the network where a host may be connected. This 128 attachment point can be characterized by its address prefix and 129 next hop routing information. 131 Most Likely Point of Attachment (MLPA) 132 The point of attachment heuristically determined by the host to be 133 most likely, based on hints from the network. 135 Routable address 136 In this specification, the term "routable address" refers to any 137 address other than an IPv4 Link-Local address. This includes 138 private addresses as specified in [RFC1918]. 140 Valid address 141 In this specification, the term "valid address" refers to either a 142 static IPv4 address, or an address assigned via DHCPv4 which has 143 not been relinquished, and whose lease has not yet expired. 145 2. Overview 147 DNAv4 consists of three phases: determination of the Most Likely 148 Point of Attachment (MLPA), reachability testing, and IPv4 address 149 acquisition. 151 On connecting to a new point of attachment, the host responds to 152 "Link Up" indications from the link layer by carrying out the DNAv4 153 procedure. As noted in Appendix A, hints about the point of 154 attachment may be available from the link and Internet layers. Based 155 on these hints, the host determines the "Most Likely Point of 156 Attachment" (MLPA) and determines whether it has a valid IP 157 configuration associated with it. 159 If the host believes that it has attached to a network on which it 160 has a valid IP configuration, then it performs a reachability test in 161 order to confirm that configuration. In contrast to a DHCP exchange, 162 which may be between a DHCP client and an off-link DHCP server, the 163 reachability test is designed to verify bi-directional connectivity 164 to the default gateway(s) on the MLPA. 166 If the reachability test is successful, the host MAY continue to use 167 a valid routable IPv4 address without having to re-acquire it. This 168 reduces roaming latency by allowing the host to bypass DHCP as well 169 as subsequent Duplicate Address Detection (DAD). If the host 170 believes that it has attached to a network on which it has no valid 171 IPv4 configuration, or if the reachability test fails, then the host 172 attempts to obtain an IPv4 configuration using DHCPv4. 174 Since DNAv4 represents a performance optimization, it is important to 175 avoid compromising robustness. In some circumstances, DNAv4 may 176 result in a host successfully verifying an existing IPv4 177 configuration where attempting to obtain configuration via DHCPv4 178 would fail (such as when the DHCP server is down). 180 To improve robustness, this document suggests that hosts behave 181 conservatively with respect to assignment of IPv4 Link-Local 182 addresses, configuring them only in situations in which they can do 183 no harm. Experience has shown that IPv4 Link-Local addresses are 184 often assigned inappropriately, and that inappropriate assignment can 185 compromise both performance and connectivity. 187 While the performance of DNAv4 is dependent on the reliability of the 188 hints provided to the client, the host will ultimately determine the 189 correct IPv4 configuration even in the presence of misleading hints. 190 Where the host mistakenly concludes that it has attached to a network 191 on which it has a valid configuration a timeout will occur, providing 192 poorer performance than would be experienced by initially attempting 193 to obtain IPv4 configuration using DHCPv4. However, after timing 194 out, the host will obtain its configuration using DHCPv4, so that 195 the correct configuration will eventually be obtained. 197 DNAv4 does not increase the likelihood of an address conflict. The 198 DNAv4 procedure is only carried out when the host has a valid IPv4 199 configuration on the MLPA, implying that duplicate address detection 200 has previously been completed. Restrictions on sending ARP requests 201 and replies are described in Section 2.2.1. 203 2.1. Most Likely Point of Attachment 205 In order to determine the MLPA, it is assumed that the host saves to 206 stable storage parameters relating to the networks it connects to: 208 [1] Link and Internet layer hints associated with each 209 network. For details, see Appendix A. 211 [2] The IPv4 and MAC address of the default gateway(s) on 212 each network. 214 [3] The link type, such as whether the link utilizes 215 Ethernet, or 802.11 adhoc or infrastructure mode. 217 Appendix A discusses hints useful for the determination of the MLPA. 218 By matching received hints against network parameters previously 219 stored, the host makes an an educated guess of which network it has 220 attached to. In the absence of other information, the MLPA defaults 221 to the network to which the host was most recently attached. 223 Aside from utilizing link layer indications, a host may also be able 224 to utilize Internet layer information in order to determine the MLPA. 225 IPv4 ICMP Router Discovery messages [RFC1256] provide information 226 relating to prefix(es) available on the link, as well as the routers 227 that serve those prefix(es). A host may use ICMP Router Discovery to 228 conclude that an advertised prefix is available; however it cannot 229 conclude the converse -- that prefixes not advertised are 230 unavailable. 232 However, since [RFC1256] is not widely implemented, it is NOT 233 RECOMMENDED that hosts utilize ICMP Router Discovery messages as an 234 alternative to the reachability test outlined in Section 2.2. 235 Instead, ICMP Router Advertisements can be used to obtain information 236 on available prefixes and default gateway(s). This can provide 237 additional resilience in the case where default gateway(s) become 238 unavailable. 240 Similarly hosts that support routing protocols such as RIP and OSPF 241 can use these protocols to determine the prefix(es) available on a 242 link and the default gateway(s) that serve those prefixes. Full 243 support is not required to glean this information. A host that 244 passively observes routing protocol traffic may deduce this 245 information without supporting a fully conformant routing protocol 246 implementation. 248 2.2. Reachability Test 250 If the host has a valid routable IPv4 address on the MLPA, a host 251 conforming to this specification SHOULD perform a reachability test, 252 in order to to confirm that it is connected to network on which it 253 has a valid routable IPv4 address. If the reachability test is not 254 successful, the host proceeds to the IPv4 address acquisition phase, 255 described in Section 2.3. 257 The host skips the reachability test and proceeds to the IPv4 address 258 acquisition phase if any of the following conditions are true: 260 [a] The host does not have a valid routable IPv4 261 address on the MLPA. In this case, the reachability 262 test cannot confirm that the host has a valid 263 routable IPv4 address, so that completing the 264 reachability test would serve no purpose. 266 [b] The host does not have information on the default 267 gateway(s) on the MLPA. In this case, insufficient 268 information is available to carry out the reachability 269 test. 271 [c] Reliable hints are unavailable. Since confirming 272 failure of the reachability test requires a timeout, 273 mistakes are costly. In the absence of reliable 274 hints, a host SHOULD instead send a DHCPREQUEST from 275 the INIT-REBOOT state, as described in [RFC2131], 276 Section 3.2 and 4.3.2. Where reliable hints are 277 unavailable, this will typically complete more 278 quickly than the reachability test. 280 [d] If secure detection of network attachment is required. 281 The reachability test utilizes ARP which is insecure, 282 whereas DHCP can be secured via DHCP authentication, 283 described in [RFC3118]. See Section 5 for details. 285 The host MAY probe only the primary default gateway, or it MAY probe 286 primary and secondary default gateways in series or in parallel. In 287 order to ensure configuration validity, the host SHOULD only 288 configure default gateway(s) which pass the reachability test. 290 2.2.1. Packet Format 292 The reachability test is performed by sending an ARP Request. The 293 ARP Request SHOULD use the host's MAC address as the source, and the 294 broadcast MAC address as the destination. The host sets the target 295 protocol address (ar$tpa) to the IPv4 address of the primary default 296 gateway, and uses its own MAC address in the sender hardware address 297 field (ar$sha). The host sets the target hardware address field 298 (ar$tha) to 0. 300 If the host has a private address as defined in [RFC1918], then it 301 SHOULD set the sender protocol address field (ar$spa) to the 302 unspecified address (0.0.0.0). This is to avoid a potential address 303 conflict when the host changes its point of attachment from one 304 private network to another. 306 Note: Some routers may refuse to answer an ARP Request sent with 307 the sender protocol address field (ar$spa) set to the unspecified 308 address (0.0.0.0). In this case the reachability test will fail. 310 If the host has a valid routable IPv4 address other than a private 311 address on the MLPA, then it SHOULD set the sender protocol address 312 field (ar$spa) to that address. It is assumed that the host had 313 previously done duplicate address detection so that an address 314 conflict is unlikely. 316 If a valid ARP Response is received, the MAC address in the sender 317 hardware address field (ar$sha) and the IPv4 address in the sender 318 protocol address field (ar$spa) are matched against the list of 319 networks and associated default gateway parameters. If a match is 320 found, then if the host has a valid routable IPv4 address on the 321 matched network, the host continues to use that IPv4 address, subject 322 to the lease re-acquisition and expiration behavior described in 323 [RFC2131], Section 4.4.5. 325 Checking for a match on both the IPv4 address and MAC address of the 326 default gateway enables the host to confirm reachability even where 327 it has moved between two private networks. In this case the IPv4 328 address of the default gateway could remain the same, while the MAC 329 address would change, so that both addresses need to be checked. 331 The risk of an address conflict is greatest when the host moves 332 between private networks, since in this case the completion of 333 Duplicate Address Detection on the former network does not provide 334 assurance against an address conflict on the new network. Until a 335 host has conformed the validity of its IPv4 configuration, it SHOULD 336 NOT respond to ARP requests. In addition, prior to confirming its 337 IPv4 configuration, a host with a private address SHOULD NOT send ARP 338 requests containing its address within the sender protocol address 339 field (ar$spa); instead it SHOULD use the unspecified address, as 340 described above. However, where the host has a valid routable non- 341 private address on the MLPA, it MAY send ARP requests using its 342 address within the sender protocol address field (ar$spa) prior to 343 confirming its IPv4 configuration. 345 Sending an ICMP Echo Request [RFC792] to the default gateway IPv4 346 address does not provide the same level of assurance since this may 347 require an ARP Request/Response exchange. Where the host has moved 348 between two private networks, this could result in ARP cache 349 pollution. 351 Where a host moves from one private network to another, an ICMP Echo 352 Request can result in an ICMP Echo Response even when the default 353 gateway has changed, as long as the IPv4 address remains the same. 354 This can occur, for example, where a host moves from one home 355 network using prefix 192.168/16 to another one. In addition, if the 356 ping is sent with TTL > 1, then an ICMP Echo Response can be received 357 from an off-link gateway. As a result, if the MAC address of the 358 default gateway is not checked, the host can mistakenly confirm 359 attachment to the MLPA, potentially resulting in an address conflict. 360 As a result, sending of an ICMP Echo Request SHOULD NOT be used as a 361 substitute for the DNAv4 procedure. 363 If the initial ARP Request does not elicit a Response, the host waits 364 for REACHABILITY_TIMEOUT and proceeds to the IPv4 address acquisition 365 phase. If a valid ARP Response is received, but cannot be matched 366 against known networks, the host assumes it does not have a valid 367 IPv4 configuration and moves on to the IPv4 address acquisition 368 phase. 370 2.3. IPv4 Address Acquisition 372 If the host has a valid routable IPv4 address on the MLPA but the 373 reachability test fails, the host SHOULD verify the configuration by 374 entering the INIT-REBOOT state, and sending a DHCPREQUEST to the 375 broadcast address as specified in [RFC2131] Section 4.4.2. 377 If the host does not have a valid routable IPv4 address on the MLPA, 378 the host enters the INIT state and sends a DHCPDISCOVER packet to the 379 broadcast address, as described in [RFC2131] Section 4.4.1. If the 380 host supports the Rapid Commit Option [RAPID], it is possible that 381 the exchange can be shortened from a 4-message exchange to a 382 2-message exchange. 384 If the host does not receive a response to a DHCPREQUEST or 385 DHCPDISCOVER, then it retransmits as specified in [RFC2131] Section 386 4.1. 388 As discussed in [RFC2131], Section 4.4.4, a host in INIT or REBOOTING 389 state that knows the address of a DHCP server may use that address in 390 the DHCPDISCOVER or DHCPREQUEST rather than the IPv4 broadcast 391 address. In the INIT-REBOOT state a DHCPREQUEST is sent to the 392 broadcast address so that the host will receive a response regardless 393 of whether the previously configured IPv4 address is correct for the 394 network to which it has connected. 396 Sending a DHCPREQUEST to the unicast address in INIT-REBOOT state is 397 not appropriate, since if the DHCP client has moved to another 398 subnet, a DHCP server response cannot be routed back to the client 399 since the DHCPREQUEST will bypass the DHCP relay and will contain an 400 invalid source address. 402 2.4. IPv4 Link-Local Addresses 404 To avoid inappropriate assignment of IPv4 Link-Local addresses, it is 405 recommended that hosts behave conservatively with respect to 406 assignment of IPv4 Link-Local addresses. As described in [IPv4LL] 407 Section 1.7, use of a routable address is preferred to a IPv4 Link- 408 Local address whenever it is available. 410 Where the host does not have a valid routable IPv4 address on the 411 MLPA, the host MAY configure an IPv4 Link-Local address prior to 412 entering the INIT state and sending a DHCPDISCOVER packet, as 413 described in Section 2.3. However, should a routable IPv4 address be 414 obtained, the IPv4 Link-Local address is deprecated, as noted in 415 [IPv4LL]. 417 Where a host has a valid routable IPv4 address on the MLPA, but the 418 DHCP client does not receive a response after employing the 419 retransmission algorithm, [RFC2131] Section 3.2 states that the 420 client MAY choose to use the previously allocated network address and 421 configuration parameters for the remainder of the unexpired lease. 422 Where a host can confirm that it remains connected to a point of 423 attachment on which it possesses a valid routable IPv4 address, that 424 address SHOULD be used, rather than assigning a IPv4 Link-Local 425 address. 427 Since a IPv4 Link-Local address is often configured because a DHCP 428 server failed to respond to an initial query or is inoperative for 429 some time, it is desirable to abandon the IPv4 Link-Local address 430 assignment as soon as a valid IPv4 address lease can be obtained. 432 As described in [IPv4LL] Appendix A, once a Link-Local IPv4 address 433 is assigned, existing implementations do not query the DHCPv4 server 434 again for 5 minutes. This behavior violates [RFC2131] Section 4.1. 436 Where a IPv4 Link-Local address is assigned, experience has shown 437 that five minutes (see [IPv4LL] Appendix A.2) is too long an interval 438 to wait until retrying to obtain a routable IPv4 address using DHCP. 439 According to [RFC2131] Section 4.1: 441 The retransmission delay SHOULD be doubled with 442 subsequent retransmissions up to a maximum of 64 seconds. 444 As a result, a DHCP client compliant with [RFC2131] will continue to 445 retry every 64 seconds, even after allocating a IPv4 Link-Local 446 address. Should the DHCP client succeed in obtaining a routable 447 address, then as noted in [IPv4LL], the IPv4 Link-Local address is 448 deprecated. 450 Since it is inevitable that hosts will inappropriately configure IPv4 451 Link-Local addresses at some point, hosts with routable IPv4 452 addresses need to be able to respond to peers with IPv4 Link-Local 453 addresses, as per [IPv4LL]. For example, a host configured with a 454 routable address may receive a datagram from a link-local source 455 address. In order to respond, the host will use ARP to resolve the 456 target hardware address and send the datagram directly, not to a 457 router for forwarding. 459 3. Constants 461 The suggested default value of REACHABILITY_TIMEOUT is 200 ms. This 462 value was chosen so as to accommodate the maximum retransmission 463 timer likely to be experienced on an Ethernet network. 465 4. IANA Considerations 467 This specification does not request the creation of any new parameter 468 registries, nor does it require any other IANA assignments. 470 5. Security Considerations 472 Detection of Network Attachment (DNA) is based on ARP and DHCP. ARP 473 [RFC826] traffic is inherently insecure, so that the reachability 474 test described in Section 1.3 can be easily spoofed by an attacker, 475 leading a host to falsely conclude that it is attached to a network 476 that it is not connected to. Similarly, where DHCP traffic is not 477 secured, an attacker could masquerade as a DHCP server, in order to 478 convince the host that it was attached to a particular network. 480 As a result, it is inadvisable for a host to adjust its security 481 based on which network it believes it is attached to. For example, 482 it would be inappropriate for a host to disable its personal firewall 483 based on the belief that it had connected to a home network. 485 Where secure detection of network attachment is required, a host 486 SHOULD skip the reachability test since it cannot be secured, and 487 instead utilize authenticated DHCP [RFC3118], possibly in combination 488 with the Rapid Commit Option [RAPID]. 490 6. References 492 6.1. Normative References 494 [RFC792] Postel, J., "Internet Control Message Protocol", RFC 792, 495 USC/Information Sciences Institute, September 1981. 497 [RFC826] D. Plummer, "An Ethernet Address Resolution Protocol -or- 498 Converting Network Addresses to 48-bit Ethernet Address for 499 Transmission on Ethernet Hardware", STD 37, RFC 826, November 500 1982. 502 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, Xerox 503 PARC, September 1991. 505 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 506 Requirement Levels", RFC 2119, March, 1997. 508 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 509 March 1997. 511 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", 512 RFC 3118, June 2001. 514 [RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration 515 of IPv4 Link-Local Addresses", RFC 3927, March 2005. 517 6.2. Informative References 519 [RFC1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 520 51, RFC 1661, Daydreamer, July 1994. 522 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and 523 E. Lear, "Address Allocation for Private Internets", RFC 1918, 524 February 1996. 526 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, 527 "IEEE 802.1X Remote Authentication Dial In User Service 528 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 530 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 531 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 532 3748, June 2004. 534 [RAPID] Park, S., Kim, P., and B. Volz, "Rapid Commit Option for 535 DHCPv4", Internet draft (work in progress), draft-ietf-dhc- 536 rapid-commit-opt-05.txt, June 2004. 538 [IEEE8021AB] 539 IEEE Standards for Local and Metropolitan Area Networks: 540 Station and Media Access Control - Connectivity Discovery, 541 IEEE Std 802.1AB/D5, September 2003. 543 [IEEE8021X] 544 IEEE Standards for Local and Metropolitan Area Networks: Port 545 based Network Access Control, IEEE Std 802.1X-2004, December 546 2004. 548 [IEEE802] IEEE Standards for Local and Metropolitan Area Networks: 549 Overview and Architecture, ANSI/IEEE Std 802, 1990. 551 [IEEE8021Q] 552 IEEE Standards for Local and Metropolitan Area Networks: Draft 553 Standard for Virtual Bridged Local Area Networks, P802.1Q, 554 January 1998. 556 [IEEE80211] 557 Information technology - Telecommunications and information 558 exchange between systems - Local and metropolitan area 559 networks - Specific Requirements Part 11: Wireless LAN Medium 560 Access Control (MAC) and Physical Layer (PHY) Specifications, 561 IEEE Std. 802.11-2003, 2003. 563 Acknowledgments 565 The authors would like to acknowledge Greg Daley of Monash 566 University, Erik Guttman and Erik Nordmark of Sun Microsystems, Ted 567 Lemon of Nominum Thomas Narten of IBM, and David Hankins of ISC for 568 contributions to this document. 570 Authors' Addresses 572 Bernard Aboba 573 Microsoft Corporation 574 One Microsoft Way 575 Redmond, WA 98052 577 EMail: bernarda@microsoft.com 578 Phone: +1 425 706 6605 579 Fax: +1 425 936 7329 581 Appendix A - Link Layer Hints 583 A.1 Introduction 585 In order to assist in IPv4 network attachment detection, information 586 associated with each network may be retained by the host. Based on 587 link-layer information, the host may be able to make an educated 588 guess as to whether it has moved between subnets, or has remained on 589 the same subnet, as well as whether it has connected to an 590 infrastructure or adhoc network. 592 If the host is likely to have moved between subnets, it may be 593 possible to make an educated guess as to which subnet it has moved 594 to. Since an educated guess may be incorrect, prior to concluding 595 that the host remains on the same subnet, further tests (such as a 596 reachability test or a DHCPREQUEST sent from the INIT-REBOOT state) 597 are REQUIRED. 599 In practice, it is necessary for hints to be highly reliable before 600 they are worth considering, if the penalty paid for an incorrect hint 601 is substantial. 603 As an example, assume that a DHCPREQUEST requires DHCPREQUEST_TIME to 604 determine if a host has remained on the same subnet, while a 605 reachability test typically completes in REACH_TIME and times out in 606 REACHABILITY_TIMEOUT, after which a DHCPREQUEST is sent. 608 If a hint that the host has remained on the same subnet is wrong x 609 fraction of the time, then it is only worth considering if: 611 DHCPREQUEST_TIME = (1 - x) * REACH_TIME + 613 x * (REACHABILITY_TIMEOUT + DHCPREQUEST_TIME) 615 x = DHCPREQUEST_TIME - REACH_TIME 616 ---------------------------------------------------- 617 REACHABILITY_TIMEOUT + DHCPREQUEST_TIME - REACH_TIME 619 If we assume that DHCPREQUEST_TIME = 100 ms, REACH_TIME = 10 ms, and 620 REACHABILITY_TIMEOUT = 1000ms, then: 622 x = (100 - 10)/(1000 + 100 - 10) = 8.2 percent 624 Therefore the hint need only be wrong 8.2 percent of the time before 625 it is not worth considering. 627 A.2 Hints 629 For networks running IPv4 over PPP [RFC1661], IPv4 parameters 630 negotiated in IPCP provide direct information on whether a previously 631 obtained address remains valid on the link. 633 On IEEE 802 [IEEE802] wired networks, hints include link-layer 634 discovery traffic as well as information exchanged as part of IEEE 635 802.1X authentication [IEEE8021X]. 637 Link-layer discovery traffic includes Link Layer Discovery Protocol 638 (LLDP) [IEEE8021AB] traffic as well as network identification 639 information passed in the EAP-Request/Identity or within an EAP 640 method exchange, as defined in EAP [RFC3748]. 642 For example, LLDP advertisements can provide information on VLANs 643 supported by the device. When used with IEEE 802.1X authentication 644 [IEEE8021X], the EAP-Request/Identity exchange may contain the name 645 of the authenticator, also providing information on the potential 646 network. Similarly, during the EAP method exchange the authenticator 647 may supply information that may be helpful in identifying the network 648 to which the device is attached. However, as noted in [RFC3580], it 649 is possible for the VLANID defined in [IEEE8021Q] to be assigned 650 dynamically, so that static advertisements may not prove definitive. 652 In IEEE 802.11 [IEEE80211] stations provide information in Beacon 653 and/or Probe Response messages, such as the SSID, BSSID, and 654 capabilities, as well as information on whether the station is 655 operating in Infrastructure or Ad hoc mode. As described in 656 [RFC3580], it is possible to assign a Station to a VLAN dynamically, 657 based on the results of IEEE 802.1X [IEEE8021X] authentication. This 658 implies that a single SSID may offer access to multiple VLANs, and in 659 practice most large WLAN deployments offer access to multiple 660 subnets. 662 Thus, associating to the same SSID is a necessary, but not 663 necessarily a sufficient condition, for remaining within the same 664 subnet: while a Station associating to the same SSID may not 665 necessarily remain within the same subnet, a Station associating to a 666 different SSID is likely to have changed subnets. 668 In IEEE 802.11, the SSID is a non-unique identifier, and SSIDs such 669 as "default", "linksys" and "tsunami" are often configured by 670 manufacturers by default. As a result, matching an advertised SSID 671 against those of previously encountered networks may be misleading. 672 Where an SSID known to be configured by default is encountered, it is 673 recommended that the BSSID be stored and subsequently compared 674 against the advertised BSSID to determine whether a match exists. 676 In order to provide additional guidance on the subnets to which a 677 given AP offers access, additional subnet-related Information 678 Elements (IEs) have been proposed for addition to the IEEE 802.11 679 Beacon and Probe Response messages. As noted earlier, VLANs may be 680 determined dynamically so that these information elements may not be 681 reliable. 683 In IEEE 802.11, the presence of an IBSS can be used as a hint that a 684 point of attachment supports adhoc networking, and therefore that 685 assignment of a IPv4 Link-Local address is likely. When running IPv4 686 over PPP, if an IP address is not statically configured or assigned 687 via IPCP, this can also be taken as a hint that assignment of an IPv4 688 Link-Local address is likely. In addition, certain media such as USB 689 or IEEE 1394 may be considered inherently more likely to support 690 adhoc operation, so that connection to these networks may by itself 691 be considered a hint. 693 Intellectual Property Statement 695 The IETF takes no position regarding the validity or scope of any 696 intellectual property or other rights that might be claimed to 697 pertain to the implementation or use of the technology described in 698 this document or the extent to which any license under such rights 699 might or might not be available; neither does it represent that it 700 has made any effort to identify any such rights. Information on the 701 IETF's procedures with respect to rights in standards-track and 702 standards-related documentation can be found in BCP-11. Copies of 703 claims of rights made available for publication and any assurances of 704 licenses to be made available, or the result of an attempt made to 705 obtain a general license or permission for the use of such 706 proprietary rights by implementors or users of this specification can 707 be obtained from the IETF Secretariat. 709 The IETF invites any interested party to bring to its attention any 710 copyrights, patents or patent applications, or other proprietary 711 rights which may cover technology that may be required to practice 712 this standard. Please address the information to the IETF Executive 713 Director. 715 Disclaimer of Validity 717 This document and the information contained herein are provided on an 718 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 719 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 720 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 721 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 722 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 723 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 725 Copyright Statement 727 Copyright (C) The Internet Society (2005). This document is subject 728 to the rights, licenses and restrictions contained in BCP 78, and 729 except as set forth therein, the authors retain all their rights. 731 Open issues 733 Open issues relating to this specification are tracked on the 734 following web site: 736 http://www.drizzle.com/~aboba/DNA/dnaissues.html