DHC Working Group Bernard Aboba INTERNET-DRAFT Microsoft Corporation Category: Proposed Standard 3 June 2005 Detecting Network Attachment (DNA) in IPv4 By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 10, 2005. Copyright Notice Copyright (C) The Internet Society 2005. Abstract The time required to detect movement between networks, and to obtain (or continue to use) an operable IPv4 configuration may be significant as a fraction of the total handover latency in moving between points of attachment. This document specifies a procedure for optimizing detection of network attachment in order to decrease the handover latency in moving between points of attachment. Aboba Proposed Standard [Page 1] INTERNET-DRAFT DNAv4 3 June 2005 Table of Contents 1. Introduction.............................................. 3 1.1 Requirements .................................... 3 1.2 Terminology ..................................... 3 2. Overview ................................................. 5 2.1 Most Likely Attachment Network .................. 6 2.2 Reachability Test ............................... 7 2.3 IPv4 Address Acquisition ........................ 10 2.4 IPv4 Link-Local Addresses ....................... 10 3. Constants ................................................ 12 4. IANA Considerations ...................................... 12 5. Security Considerations .................................. 12 6. References ............................................... 13 6.1 Normative references ............................ 13 6.2 Informative references .......................... 13 Acknowledgments .............................................. 14 Authors' Addresses ........................................... 14 Appendix A - Link Layer Hints ................................ 15 A.1 Introduction .................................... 15 A.2 Hints ........................................... 16 Intellectual Property Statement .............................. 17 Disclaimer of Validity ....................................... 18 Copyright Statement .......................................... 18 Aboba Proposed Standard [Page 2] INTERNET-DRAFT DNAv4 3 June 2005 1. Introduction The time required to detect movement between networks and to obtain (or continue to use) an operable IPv4 configuration may be significant as a fraction of the total handover latency in moving between points of attachment. This document synthesizes experience in the deployment of hosts supporting ARP [RFC826], DHCP [RFC2131], and IPv4 Link-Local addresses [RFC3927], specifying a procedure for detecting network attachment and optimizing continued use of an operable IPv4 configuration, in order to minimize the handover latency in moving between points of attachment. Since this procedure is dependent on the ARP protocol, it is not suitable for use on media that do not support ARP [RFC826]. 1.1. Requirements In this document, several words are used to signify the requirements of the specification. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.2. Terminology This document uses the following terms: ar$sha ARP packet field: Source Hardware Address [RFC826]. The hardware (MAC) address of the originator of an ARP packet. ar$spa ARP packet field: Source Protocol Address [RFC826]. For IP Address Resolution this is the IPv4 address of the sender of the ARP packet. ar$tha ARP packet field: Target Hardware Address [RFC826]. The hardware (MAC) address of the target of an ARP packet. ar$tpa ARP packet field: Target Protocol Address [RFC826]. For IPv4 Address Resolution, the IPv4 address for which one desires to know the hardware address. ARP Probe An ARP Request packet, broadcast on the local link, with an all- Aboba Proposed Standard [Page 3] INTERNET-DRAFT DNAv4 3 June 2005 zero 'sender IP address' (ar$spa). The 'sender hardware address' (ar$sha) MUST contain the hardware address of the interface sending the packet. The 'target hardware address' field (ar$tha) is ignored and SHOULD be set to all zeroes. The 'target IP address' (ar$tpa) field MUST be set to the address being probed. ARP Announcement An ARP Request packet, broadcast on the local link, identical to the ARP Probe described above, except that both the sender (ar$spa) and target (ar$tpa) IP address fields contain the IP address being announced. DHCP client A DHCP client or "client" is an Internet host using the Dynamic Host Configuration protocol (DHCP) [RFC2131] to obtain configuration parameters such as a network address. DHCP server A DHCP server or "server" is an Internet host that returns configuration parameters to DHCP clients. Link A communication facility or medium over which network nodes can communicate. Each link is associated with a minimum of two endpoints. Each link endpoint has a unique link-layer identifier. Link Down An event provided by the link layer that signifies a state change associated with the interface no longer being capable of communicating data frames; transient periods of high frame loss are not sufficient. DNAv4 does not utilize "Link Down" indications. Link Layer Conceptual layer of control or processing logic that is responsible for maintaining control of the data link. The data link layer functions provide an interface between the higher-layer logic and the data link. The link layer is the layer immediately below IP. Link Up An event provided by the link layer that signifies a state change associated with the interface becoming capable of communicating data frames. Most Likely Attachment Network (MLAN) The attached network heuristically determined by the host to be most likely, based on hints. Point of Attachment The link endpoint on the link to which the host is currently Aboba Proposed Standard [Page 4] INTERNET-DRAFT DNAv4 3 June 2005 connected. Routable address In this specification, the term "routable address" refers to any IPv4 address other than an IPv4 Link-Local address. This includes private addresses as specified in [RFC1918]. Operable address In this specification, the term "operable address" refers to either a static IPv4 address, or an address assigned via DHCPv4 which has not been relinquished, and whose lease has not yet expired. 2. Overview DNAv4 consists of three phases: determination of the Most Likely Attachment Network (MLAN), reachability testing, and IPv4 address acquisition. On connecting to a new point of attachment, the host responds to a "Link Up" indication from the link layer by carrying out the DNAv4 procedure. As noted in Appendix A, hints about the network to which the host has attached may be available from the link and Internet layers. Based on these hints, the host determines the "Most Likely Attachment Network" (MLAN) and whether it has an operable IPv4 configuration associated with it. If the host believes that it has attached to a network on which it has an operable IPv4 configuration, then it performs a reachability test in order to confirm that configuration. In contrast to a DHCPv4 exchange, which may be between a DHCPv4 client and an off-link DHCPv4 server, the reachability test is designed to verify bi-directional connectivity to the default gateway(s) on the MLAN. If the reachability test is successful, the host MAY continue to use an operable routable IPv4 address without having to re-acquire it. This reduces roaming latency by allowing the host to bypass DHCPv4 as well as Duplicate Address Detection (DAD). If the host believes that it has attached to a network on which it has no operable IPv4 configuration, or if the reachability test fails, then the host attempts to obtain an IPv4 configuration using DHCPv4. Since DNAv4 represents a performance optimization, it is important to avoid compromising robustness. In some circumstances, DNAv4 may result in a host successfully verifying an existing IPv4 configuration where attempting to obtain configuration via DHCPv4 would fail (such as when the DHCPv4 server is down). To improve robustness, this document suggests that hosts behave Aboba Proposed Standard [Page 5] INTERNET-DRAFT DNAv4 3 June 2005 conservatively with respect to assignment of IPv4 Link-Local addresses [RFC3927], configuring them only in situations in which they can do no harm. Experience has shown that IPv4 Link-Local addresses are often assigned inappropriately, compromising both performance and connectivity. While the performance of DNAv4 is dependent on the reliability of the hints provided to the client, the host will ultimately determine the correct IPv4 configuration even in the presence of misleading hints. Where the host mistakenly concludes that it has an operable IPv4 configuration a timeout will occur, after which the host will eventually obtain the correct configuration using DHCPv4, albeit with a performance penalty. DNAv4 does not increase the likelihood of an address conflict. The DNAv4 procedure is only carried out when the host has an operable IPv4 configuration on the MLAN, implying that duplicate address detection has previously been completed. Restrictions on sending ARP Requests and Responses are described in Section 2.2.1. 2.1. Most Likely Attachment Network (MLAN) In order to determine the MLAN, it is assumed that the host saves to stable storage parameters relating to the networks it connects to: [1] Link and Internet layer hints associated with each network. For details, see Appendix A. [2] The IPv4 and MAC address of the default gateway(s) on each network. [3] The link type, such as whether the link utilizes Ethernet, or 802.11 adhoc or infrastructure mode. Appendix A discusses hints useful for the determination of the MLAN. By matching received hints against network parameters previously stored, the host makes an an educated guess of which network it has attached to. In the absence of other information, the MLAN defaults to the network to which the host was most recently attached. Aside from utilizing link layer indications, a host may also be able to utilize Internet layer information in order to determine the MLAN. IPv4 ICMP Router Discovery messages [RFC1256] provide information relating to prefix(es) available on the link, as well as the routers that serve those prefix(es). A host may use ICMP Router Discovery to conclude that an advertised prefix is available; however it cannot conclude the converse -- that prefixes not advertised are unavailable. Aboba Proposed Standard [Page 6] INTERNET-DRAFT DNAv4 3 June 2005 However, since [RFC1256] is not widely implemented, it is NOT RECOMMENDED that hosts utilize ICMP Router Discovery messages as an alternative to the reachability test outlined in Section 2.2. Instead, ICMP Router Advertisements can be used to obtain information on available prefixes and default gateway(s). This can provide additional resilience in the case where default gateway(s) become unavailable. Similarly hosts that support routing protocols such as RIP and OSPF can use these protocols to determine the prefix(es) available on a link and the default gateway(s) that serve those prefixes. Full support is not required to glean this information. A host that passively observes routing protocol traffic may deduce this information without supporting a fully conformant routing protocol implementation. 2.2. Reachability Test If the host has an operable routable IPv4 address on the MLAN, a host conforming to this specification SHOULD perform a reachability test, in order to to confirm that it is connected to network on which it has an operable routable IPv4 address. If the reachability test is not successful, the host proceeds to the IPv4 address acquisition phase, described in Section 2.3. The host skips the reachability test and proceeds to the IPv4 address acquisition phase if any of the following conditions are true: [a] The host does not have an operable routable IPv4 address on the MLAN. In this case, the reachability test cannot confirm that the host has an operable routable IPv4 address, so that completing the reachability test would serve no purpose. A host MUST NOT use the reachability test to confirm configuration of an IPv4 Link-Local address. [b] The host does not have information on the default gateway(s) on the MLAN. In this case, insufficient information is available to carry out the reachability test. [c] Reliable hints are unavailable. Since confirming failure of the reachability test requires a timeout, mistakes are costly. In the absence of reliable hints, a host SHOULD instead send a DHCPREQUEST from the INIT-REBOOT state, as described in [RFC2131], Section 3.2 and 4.3.2. Where reliable hints are Aboba Proposed Standard [Page 7] INTERNET-DRAFT DNAv4 3 June 2005 unavailable, this will typically complete more quickly than the reachability test. [d] If secure detection of network attachment is required. The reachability test utilizes ARP which is insecure, whereas DHCPv4 can be secured via DHCPv4 authentication, described in [RFC3118]. See Section 5 for details. [e] If the default gateway address is an IPv4 Link-Local address. In this case, it is possible that the reachability test could be misinterpreted as indication of an address conflict. See [RFC3927] Section 2.2.1 for details. The host MAY test the reachability of the primary default gateway, or it MAY test reachability of the primary and secondary default gateways in series or in parallel. In order to ensure configuration validity, the host SHOULD only configure default gateway(s) which pass the reachability test. 2.2.1. Packet Format The reachability test is performed by sending an ARP Request. The ARP Request SHOULD use the host's MAC address as the source, and the broadcast MAC address as the destination. The host sets the target protocol address (ar$tpa) to the IPv4 address of the default gateway being tested, and uses its own MAC address in the sender hardware address field (ar$sha). The host sets the target hardware address field (ar$tha) to 0. If the host has an operable routable IPv4 address other than a private address on the MLAN, then it SHOULD set the sender protocol address field (ar$spa) to that address. It is assumed that the host had previously done duplicate address detection so that an address conflict is unlikely. If the host has a private address as defined in [RFC1918], then it SHOULD send an ARP Probe, setting the sender protocol address field (ar$spa) to the unspecified address (0.0.0.0). This is to avoid a potential address conflict when the host changes its attachment network from one private network to another. Note: Some routers may refuse to answer an ARP Probe, in which case the reachability test will fail. A host also may encounter a router that utilizes ARP Probes for DAD, as described in [ACD]. Such routers will not interpret ARP Probes as an indication of an address conflict, except where they are themselves doing Duplicate Address Detection (DAD). To avoid triggering conflict detection Aboba Proposed Standard [Page 8] INTERNET-DRAFT DNAv4 3 June 2005 on these routers, a host implementing DNAv4 that receives ARP Probe from a router SHOULD NOT send ARP Probes to that router as part of the DNAv4 reachability test. If a valid ARP Reply is received, the MAC address in the sender hardware address field (ar$sha) and the IPv4 address in the sender protocol address field (ar$spa) are matched against the list of networks and associated default gateway parameters. If a match is found, then if the host has an operable routable IPv4 address on the matched network, the host continues to use that IPv4 address, subject to the lease re-acquisition and expiration behavior described in [RFC2131], Section 4.4.5. Checking for a match on both the IPv4 address and MAC address of the default gateway enables the host to confirm reachability even where it has moved between two private networks. In this case the IPv4 address of the default gateway could remain the same, while the MAC address would change, so that both addresses need to be checked. The risk of an address conflict is greatest when the host moves between private networks, since in this case the completion of Duplicate Address Detection on the former network does not provide assurance against an address conflict on the new network. Until a host with a private address has confirmed the operability of its IPv4 configuration, it SHOULD NOT respond to ARP Requests, and SHOULD NOT send ARP Requests containing its address within the sender protocol address field (ar$spa). Instead it SHOULD use the unspecified address, as described above. However, where the host has an operable routable non-private address on the MLAN, it MAY send ARP Requests using its address within the sender protocol address field (ar$spa) prior to confirming its IPv4 configuration, and MAY respond to ARP Requests. Sending an ICMP Echo Request [RFC792] to the default gateway IPv4 address does not provide the same level of assurance since this may require an ARP Request/Reply exchange. Where the host has moved between two private networks, this could result in ARP cache pollution. Where a host moves from one private network to another, an ICMP Echo Request can result in an ICMP Echo Response even when the default gateway has changed, as long as the IPv4 address remains the same. This can occur, for example, where a host moves from one home network using prefix 192.168/16 to another one. In addition, if the ping is sent with TTL > 1, then an ICMP Echo Response can be received from an off-link gateway. As a result, if the MAC address of the default gateway is not checked, the host can mistakenly confirm attachment to the MLAN, potentially resulting in an address conflict. Aboba Proposed Standard [Page 9] INTERNET-DRAFT DNAv4 3 June 2005 As a result, sending of an ICMP Echo Request SHOULD NOT be used as a substitute for the DNAv4 procedure. If the initial ARP Request does not elicit a response, the host waits for REACHABILITY_TIMEOUT and proceeds to the IPv4 address acquisition phase. If a valid ARP Reply is received, but cannot be matched against known networks, the host assumes it does not have an operable IPv4 configuration and moves on to the IPv4 address acquisition phase. 2.3. IPv4 Address Acquisition If the host has an operable routable IPv4 address on the MLAN but the reachability test fails, the host SHOULD verify the configuration by entering the INIT-REBOOT state, and sending a DHCPREQUEST to the broadcast address as specified in [RFC2131] Section 4.4.2. If the host does not have an operable routable IPv4 address on the MLAN, the host enters the INIT state and sends a DHCPDISCOVER packet to the broadcast address, as described in [RFC2131] Section 4.4.1. If the host supports the Rapid Commit Option [RFC4039], it is possible that the exchange can be shortened from a 4-message exchange to a 2-message exchange. If the host does not receive a response to a DHCPREQUEST or DHCPDISCOVER, then it retransmits as specified in [RFC2131] Section 4.1. As discussed in [RFC2131], Section 4.4.4, a host in INIT or REBOOTING state that knows the address of a DHCP server may use that address in the DHCPDISCOVER or DHCPREQUEST rather than the IPv4 broadcast address. In the INIT-REBOOT state a DHCPREQUEST is sent to the broadcast address so that the host will receive a response regardless of whether the previously configured IPv4 address is correct for the network to which it has connected. Sending a DHCPREQUEST to the unicast address in INIT-REBOOT state is not appropriate, since if the DHCP client has moved to another subnet, a DHCP server response cannot be routed back to the client since the DHCPREQUEST will bypass the DHCP relay and will contain an invalid source address. 2.4. IPv4 Link-Local Addresses To avoid inappropriate assignment of IPv4 Link-Local addresses, it is recommended that hosts behave conservatively, assigning them only when they can do no harm. As described in [RFC3927] Section 1.7, use of a routable address is preferred to a IPv4 Link-Local address Aboba Proposed Standard [Page 10] INTERNET-DRAFT DNAv4 3 June 2005 whenever it is available. Where the host does not have an operable routable IPv4 address on the MLAN, the host MAY configure an IPv4 Link-Local address prior to entering the INIT state and sending a DHCPDISCOVER packet, as described in Section 2.3. However, should a routable IPv4 address be obtained, the IPv4 Link-Local address is deprecated, as noted in [RFC3927]. Where a host has an operable routable IPv4 address on the MLAN, but the DHCP client does not receive a response after employing the retransmission algorithm, [RFC2131] Section 3.2 states that the client MAY choose to use the previously allocated network address and configuration parameters for the remainder of the unexpired lease. Where a host can confirm that it remains connected to a point of attachment on which it possesses an operable routable IPv4 address, that address SHOULD be used, rather than assigning a IPv4 Link-Local address. Since a IPv4 Link-Local address is often configured because a DHCP server failed to respond to an initial query or is inoperative for some time, it is desirable to abandon the IPv4 Link-Local address assignment as soon as an IPv4 address lease can be obtained. As described in [RFC3927] Appendix A, once a Link-Local IPv4 address is assigned, existing implementations do not query the DHCPv4 server again for 5 minutes. This behavior violates [RFC2131] Section 4.1. Where a IPv4 Link-Local address is assigned, experience has shown that five minutes (see [RFC3927] Appendix A.2) is too long an interval to wait until retrying to obtain a routable IPv4 address using DHCP. According to [RFC2131] Section 4.1: The retransmission delay SHOULD be doubled with subsequent retransmissions up to a maximum of 64 seconds. As a result, a DHCP client compliant with [RFC2131] will continue to retry every 64 seconds, even after allocating a IPv4 Link-Local address. Should the DHCP client succeed in obtaining a routable address, then as noted in [RFC3927], the IPv4 Link-Local address is deprecated. Since it is inevitable that hosts will inappropriately configure IPv4 Link-Local addresses at some point, hosts with routable IPv4 addresses need to be able to respond to peers with IPv4 Link-Local addresses, as per [RFC3927]. For example, a host configured with a routable address may receive a datagram from a link-local source address. In order to respond, the host will use ARP to resolve the Aboba Proposed Standard [Page 11] INTERNET-DRAFT DNAv4 3 June 2005 target hardware address and send the datagram directly, not to a router for forwarding. 3. Constants The suggested default value of REACHABILITY_TIMEOUT is 200 ms. This value was chosen so as to accommodate the maximum retransmission timer likely to be experienced on an Ethernet network. 4. IANA Considerations This specification does not request the creation of any new parameter registries, nor does it require any other IANA assignments. 5. Security Considerations Detecting Network Attachment for IPv4 (DNAv4) is based on ARP and DHCP and inherits the security vulnerabilities of these two protocols. ARP [RFC826] traffic is not secured, so that an attacker gaining access to the network can spoof a response to the reachability test described in Section 2.2, leading the querier to falsely conclude that it is attached to a network that it is not connected to. Similarly, where DHCPv4 traffic is not secured, an attacker could masquerade as a DHCPv4 server, in order to convince the host that it was attached to a particular network. This and other threats relating to DHCPv4 are described in "Authentication for DHCP Messages" [RFC3118]. The effect of these attacks will typically be limited to denial of service, unless the host utilizes its IP configuration for other purposes, such as security configuration or location determination. For example, a host that disables its personal firewall based on evidence that it had attached to a home network could be compromised by spoofing of the DNAv4 reachability test. In general, adjustment of the security configuration based on DNAv4 is NOT RECOMMENDED. Hosts that depend on secure IP configuration SHOULD NOT use DNAv4, but SHOULD instead utilize DHCP authentication [RFC3118], possibly in combination with the Rapid Commit Option [RFC4039]. Aboba Proposed Standard [Page 12] INTERNET-DRAFT DNAv4 3 June 2005 6. References 6.1. Normative References [RFC792] Postel, J., "Internet Control Message Protocol", RFC 792, USC/Information Sciences Institute, September 1981. [RFC826] D. Plummer, "An Ethernet Address Resolution Protocol -or- Converting Network Addresses to 48-bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, November 1982. [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, Xerox PARC, September 1991. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March, 1997. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001. [RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, May 2005. 6.2. Informative References [ACD] Cheshire, S., "IPv4 Address Conflict Detection", draft- cheshire-ipv4-acd-03.txt, Internet draft (work in progress), December 2002. [RFC1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, Daydreamer, July 1994. [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E. Lear, "Address Allocation for Private Internets", RFC 1918, February 1996. [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines", RFC 3580, September 2003. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. Aboba Proposed Standard [Page 13] INTERNET-DRAFT DNAv4 3 June 2005 [RFC4039] Park, S., Kim, P., and B. Volz, "Rapid Commit Option for the Dynamic Host Configuration Protocol version 4 (DHCPv4)", RFC 4039, March 2005. [IEEE-802.1AB] IEEE Standards for Local and Metropolitan Area Networks: Station and Media Access Control - Connectivity Discovery, IEEE Std 802.1AB, March 2005. [IEEE-802.1X] IEEE Standards for Local and Metropolitan Area Networks: Port based Network Access Control, IEEE Std 802.1X-2004, December 2004. [IEEE-802] IEEE Standards for Local and Metropolitan Area Networks: Overview and Architecture, ANSI/IEEE Std 802, 1990. [IEEE-802.1Q] IEEE Standards for Local and Metropolitan Area Networks: Draft Standard for Virtual Bridged Local Area Networks, P802.1Q, January 1998. [IEEE-802.11] Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific Requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, IEEE Std. 802.11-2003, 2003. Acknowledgments The authors would like to acknowledge Greg Daley of Monash University, Erik Guttman and Erik Nordmark of Sun Microsystems, Ted Lemon of Nominum Thomas Narten of IBM, and David Hankins of ISC for contributions to this document. Authors' Addresses Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 EMail: bernarda@microsoft.com Phone: +1 425 818 4011 Fax: +1 425 936 7329 Aboba Proposed Standard [Page 14] INTERNET-DRAFT DNAv4 3 June 2005 Appendix A - Link Layer Hints A.1 Introduction In order to assist in detecting network attachment, information associated with each network may be retained by the host. Based on link-layer information, the host may be able to make an educated guess as to whether it has moved between subnets, or has remained on the same subnet, as well as whether it has connected to an infrastructure or adhoc network. If the host is likely to have moved between subnets, it may be possible to make an educated guess as to which subnet it has moved to. Since an educated guess may be incorrect, prior to concluding that the host remains on the same subnet, further tests (such as a reachability test or a DHCPREQUEST sent from the INIT-REBOOT state) are REQUIRED. In practice, it is necessary for hints to be highly reliable before they are worth considering, if the penalty paid for an incorrect hint is substantial. As an example, assume that a DHCPREQUEST requires DHCPREQUEST_TIME to determine if a host has remained on the same subnet, while a reachability test typically completes in REACH_TIME and times out in REACHABILITY_TIMEOUT, after which a DHCPREQUEST is sent. If a hint that the host has remained on the same subnet is wrong x fraction of the time, then it is only worth considering if: DHCPREQUEST_TIME > (1 - x) * REACH_TIME + x * (REACHABILITY_TIMEOUT + DHCPREQUEST_TIME) x < DHCPREQUEST_TIME - REACH_TIME ---------------------------------------------------- REACHABILITY_TIMEOUT + DHCPREQUEST_TIME - REACH_TIME If we assume that DHCPREQUEST_TIME = 50 ms, REACH_TIME = 10 ms, and REACHABILITY_TIMEOUT = 200ms, then: x < (50 - 10)/(200 + 50 - 10) = 16.67 percent In this example, if the hint is wrong more than one sixth of the time, it is not worth considering. Aboba Proposed Standard [Page 15] INTERNET-DRAFT DNAv4 3 June 2005 A.2 Hints For networks running IPv4 over PPP [RFC1661], IPv4 parameters negotiated in IPCP provide direct information on whether a previously obtained address remains operable on the link. On media supporting EAP [RFC3748], network identification information may be passed within the EAP-Request/Identity or within an EAP method exchange. For example, the EAP-Request/Identity may contain the name of the authenticator. During the EAP method exchange the authenticator may supply information that may be helpful in identifying the network to which the device is attached. However, as noted in [RFC3580], it is possible for the VLANID defined in [IEEE-802.1Q] to be assigned dynamically, so that static advertisements may not prove definitive. On IEEE 802 [IEEE-802] wired networks, hints can be obtained via the Link Layer Discovery Protocol (LLDP) defined in [IEEE-802.1AB]. LLDP advertisements can include the chassis ID, which represents the authenticator's chassis identification, enabling a host to determine if it has attached to a previously encountered device. However, since a device may support dynamic VLANs, re-attachment does not necessarily imply that the VLAN has remained the same, although this is likely. LLDP also enables advertisement of the port's VLAN identifier, as well as a VLAN name, allowing the host to determine whether it has attached to a VLAN on which it had previously obtained an operable IPv4 configuration. Since such an advertisement cannot be heard until 802.1X authentication has completed, the advertised VLAN will reflect a dynamic VLAN assignment if one has been made, so that it is likely to be definitive. In IEEE 802.11 [IEEE-802.11] stations provide information in Beacon and/or Probe Response messages, such as the SSID, BSSID, and capabilities, as well as information on whether the station is operating in Infrastructure or Ad hoc mode. As described in [RFC3580], it is possible to assign a Station to a VLAN dynamically, based on the results of IEEE 802.1X [IEEE-802.1X] authentication. This implies that a single SSID may offer access to multiple VLANs, and in practice most large WLAN deployments offer access to multiple subnets. While a Station associating to the same SSID may not remain within the same subnet, a Station associating to a different SSID is likely to have changed subnets. In IEEE 802.11, the SSID is a non-unique identifier, and SSIDs such as "default", "linksys" and "tsunami" are often configured by manufacturers by default. As a result, matching an advertised SSID Aboba Proposed Standard [Page 16] INTERNET-DRAFT DNAv4 3 June 2005 against those of previously encountered networks may be misleading. Where an SSID known to be configured by default is encountered, it is recommended that the BSSID be stored and subsequently compared against the advertised BSSID to determine whether a match exists. In order to provide additional guidance on the subnets to which a given AP offers access, additional subnet-related Information Elements (IEs) have been proposed for addition to the IEEE 802.11 Beacon and Probe Response messages. As noted earlier, VLANs may be determined dynamically so that these information elements may not be reliable. In IEEE 802.11, the presence of an IBSS can be used as a hint that a link supports adhoc networking, and therefore that assignment of a IPv4 Link-Local address is likely. When running IPv4 over PPP, if an IPv4 address is not statically configured or assigned via IPv4CP, this can also be taken as a hint that assignment of an IPv4 Link- Local address is likely. Media such as USB or IEEE 1394 may be considered inherently more likely to support adhoc operation, so that attachment to these media may by itself be considered a hint. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Aboba Proposed Standard [Page 17] INTERNET-DRAFT DNAv4 3 June 2005 Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Open issues Open issues relating to this specification are tracked on the following web site: http://www.drizzle.com/~aboba/DNA/ Aboba Proposed Standard [Page 18]