DHC Working Group Bernard Aboba INTERNET-DRAFT Microsoft Corporation Category: Proposed Standard
<draft-ietf-dhc-dna-ipv4-04.txt> 21 October 2003<draft-ietf-dhc-dna-ipv4-05.txt> 26 January 2004 Detection of Network Attachment (DNA) in IPv4 This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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. Copyright Notice Copyright (C) The Internet Society (2003).(2004). All Rights Reserved. Abstract The time required to detect movement (or lack of movement) between subnets, and to obtain (or continue to use) a valid IPv4 address may be significant as a fraction of the total delay in moving between points of attachment. This specification synthesizes experience garnered over the years in the deployment of hosts supporting ARP, DHCP and IPv4 Link-Local addresses, in order to optimize detection of network attachment by mobile hosts. Table of Contents 1. Introduction.............................................. 3 1.1 Requirements .................................... 43 1.2 Terminology ..................................... 43 2. Framework ................................................ 54 2.1 Most likely point of attachment ................. 5 2.2 Reachability test ............................... 5 2.2 Packet format ................................... 62.3 IPv4 Address Acquisition ........................ 78 3. Constants ................................................ 89 4. IANA Considerations ...................................... 9 5. Security Considerations .................................. 9 6. References ............................................... 910 6.1 Normative references ............................ 910 6.2 Informative references .......................... 10 Acknowledgments .............................................. 11 Authors' Addresses ........................................... 11 Appendix A - Hints ........................................... 12 Intellectual Property Statement .............................. 13 Full Copyright Statement ..................................... 1314 1. Introduction The time required to detect movement (or lack of movement) between subnets, and to obtain (or continue to use) a valid IPv4 address may be significant as a fraction of the total delay in moving between points of attachment. As a result, optimizing detection of network attachment is important for mobile hosts. This document synthesizes experience in the deployment of hosts supporting ARP [RFC826], DHCP [RFC2131], and Link-Local IPv4 addresses [IPv4LL], specifying a procedure to be performed for IPv4 detection of network attachment. The procedure consists of three phases: determination of the "most likely" point of attachment, reachability testing, and IPv4 address acquisition. On disconnection from a network, there is no need1.1. Requirements In this document, several words are used to take action untilsignify the host is reconnected, since it is typically not possible for a host to communicate until it has obtained connectivity. Therefore, contrary to [RFC2131] Section 3.7, no action need be taken on network disconnection. For Detectionrequirements of Network attachment,the following basic principlesspecification. These words are suggested: [a] Utilization of link layer hints. Link layers suchoften capitalized. 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 IEEE 802 [IEEE802] provide hints about whether a host remains ondescribed in [RFC2119]. 1.2. Terminology This document uses the same subnet despite changing its pointfollowing terms: ar$sha ARP packet field: Source Hardware Address [RFC826]. The hardware (MAC) address of attachment, or even whetherthe host is connected tooriginator of an adhoc or infrastructure network. Where available, these hints can be used to guide host behavior - withARP packet. ar$spa ARP packet field: Source Protocol Address [RFC826]. For IP Address Resolution this is the understanding that they are not infallible and therefore thatIPv4 address of the host should be capablesender of makingthe correct determination even inARP packet. If the presencesender address is unknown, this is set to 0.0.0.0. ar$tha ARP packet field: Target Hardware Address [RFC826]. The hardware (MAC) address of misleading hints. Link layer hints are described in more detail in Appendix A. [b] Link-Local IPv4 addressing as a mechanismthe target of last resort. Experience has shown that Link-Local IPv4 addresses are often assigned inappropriately. For example,an ARP packet, or the broadcast address if the target hardware address is unknown. ar$tpa ARP packet field: Target Protocol Address [RFC826]. For IPv4 host assigning an Link-LocalAddress Resolution, the IPv4 address may not be connected to any network, infor which case assignment of a Link-Local IPv4 address does no good; orone desires to know the hardware address. DHCP client A DHCP client or "client" is an Internet host may be attachedusing DHCP to obtain configuration parameters such as a network with a DHCPv4address. DHCP server but may not receive a response to a DHCPREQUEST or DHCPDISCOVER. As described in AppendixA of [IPv4LL] once a Link-Local IPv4 address is assigned, existing implementations do not query the DHCPv4DHCP server again for 5 minutes. As noted in Section 2.3, this behavioror "server" is in violation of [RFC2131] Section 4.1. For hosts changing their point of attachment more frequently than this, inappropriate assignment of an Link-Local IPv4 address can result inan ongoing inabilityInternet host that returns configuration parameters to connect. As a result,DHCP clients. Routable address In this document suggests that hosts behave conservatively with respectspecification, the term "routable address" refers to assignment of Link-Localany address other than an IPv4 addresses, using them onlyLink-Local address. This includes private addresses as a last resort. 1.1. Requirementsspecified in [RFC1918]. Valid address In this document, several words are used to signify the requirements ofspecification, the specification. These words are often capitalized. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document areterm "valid address" refers 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)either a static IPv4 address, or an address assigned via DHCPv4 which has not been relinquished, and whose lease has not yet expired. 2. Framework For Detection of Network attachment, the originatorfollowing basic principles are suggested: [a] Treatment of an ARP packet. ar$spa ARP packet field: Source Protocol Address [RFC826]. For IP Address Resolution thislink-down/up indications. On disconnection from a network, there is no need to take action until the IP Addresshost is reconnected, since it is typically not possible for a host to communicate until it has obtained connectivity. Therefore, contrary to [RFC2131] Section 3.7, no action need be taken on network disconnection. On connecting to a new point of attachment, the senderhost attempts to determine the "most likely" configuration associated with the new point of attachment. [b] Utilization of hints. Link layers such as IEEE 802 [IEEE802] provide hints about whether a host remains on the ARP packet. Ifsame subnet despite changing its point of attachment, or even whether the sender address is unknown, thishost is setconnected to 0.0.0.0. ar$tha ARP packet field: Target Hardware Address [RFC826]. The hardware (MAC) addressan ad hoc or infrastructure network. On connecting to a new point of attachment, the targethost attempts to use available hints to determine the "most likely" configuration associated with the new point of an ARP packet, orattachment. Since hints are not infallible, the broadcast address ifhost should be capable of making the target hardware address is unknown. ar$tpa ARP packet field: Target Protocol Address [RFC826]. For IP Address Resolution,correct determination even in the IPpresence of misleading hints. For details see Appendix A. [c] Link-Local IPv4 addressing as a mechanism of last resort. Experience has shown that Link-Local IPv4 addresses are often assigned inappropriately. For example, an IPv4 host assigning an Link-Local IPv4 address for which one desiresmay not be connected to know the hardware address. DHCP client A DHCP clientany network, in which case assignment of a Link-Local IPv4 address does no good; or "client" is an Internetthe host using DHCPmay be attached to obtain configuration parameters such asa network address. DHCP server A DHCPwith a DHCPv4 server or "server" is an Internet host that returns configuration parametersbut may not receive a response to DHCP clients. Routablea DHCPREQUEST or DHCPDISCOVER. As described in [IPv4LL] Appendix A once a Link-Local IPv4 address In this specification,is assigned, existing implementations do not query the term "routable address" refers to any address otherDHCPv4 server again for 5 minutes. As noted in Section 2.3, this behavior is in violation of [RFC2131] Section 4.1. For hosts changing their point of attachment more frequently than this, inappropriate assignment of an IPv4Link-Local address. This includes private addresses as specifiedIPv4 address can result in [RFC1918]. 2. Framework On connectingan ongoing inability to connect. As a new point of attachment, the host attempts to determine the "most likely" configuration associatedresult, this document suggests that hosts behave conservatively with the newrespect to assignment of Link-Local IPv4 addresses, using them only as a last resort. 2.1. Most likely point of attachment.attachment In order to determine the "most likely" point of attachment it is assumed that the host is capable of obtaining and writing to stable storage parameters relating to networks that it connects to, including:  IP and link layer hints associated with each network. For details, see Appendix A.  The IPIPv4 and MAC address of the primarydefault gatewaygateway(s) on each network. By matching the received hints against information previously collected, the host may be able to make an educated guess of which network it has attached to. Where no additional information is available,In the absence of other information, by default the host assumes that the "most likely" point of attachment is the network to which it was most recently connected.attached. If the host has a valid routable IPv4 address on the "most likely" point of attachment, the host performs a reachability test as described below.in Section 2.2. If the reachability test is not successful, or if the host does not have a valid routable IPv4 address on the "most likely" point of attachment, the host proceeds to the IPv4 address acquisition phase. 2.1. Reachability Test The purposeattachment, the host proceeds to the IPv4 address acquisition phase, described in Section 2.3. 2.2. Reachability Test The purpose of the reachability test is to determine whether the host is connected to a network on which it has a valid routable IPv4 address. The host skips the reachability test in the following circumstances: [a] If the host does not have a valid routable IPv4 address on the "most likely" point of attachment. [b] If no hints are available. Since confirming failure of the reachability test requires considerable latency, mistakes are costly. In the absence of hints, a host SHOULD instead send a DHCPREQUEST from the INIT-REBOOT state, as described in [RFC2131], Section 3.2 and 4.3.2. [c] If the host does not have information on the default gateway(s) for the "most likely" point of attachment. [d] If secure detection of the reachability test is to determine whether the host is connected to anetwork on which it had previously obtained a still valid routable IPv4 address.attachment is required. See Section 5 for details. The reachability test is performed by attempting to verify reachability of a previously configured primarydefault gatewaygateway(s) on a formerthe "most likely" point of attachment. If the test is successful, the host may continue to use a valid routable IPv4 address without having to re-acquire it.This reduces roaming latency by allowing the host to bypass theDHCP exchangeas well as subsequent Duplicate Address Detection (DAD). In contrast to a DHCP exchange, which may be between a DHCP client and an offlink DHCP server, the reachability test occurs between a host and its next hop router. The host skipsmay probe only the reachability testprimary default gateway, or it may probe primary and proceeds to the address acquisition phasesecondary default gateways, in the following circumstances: [a]series or in parallel. If the host does not have information on the default gateway on the network. [b] Ifreachability test is successful, the host does not havemay continue to use a valid routable IPv4 address onwithout having to re-acquire it. However, in order to ensure configuration validity, the network. A Link-Local IPv4 address does not count as a valid routable IPv4 address. 2.2.host SHOULD only configure default gateway(s) which pass the reachability test. 2.2.1. Packet Format To perform theThe reachability test,test is performed by sending an ARP Request. The ARP Request SHOULD be sent, usinguse 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 primary default gateway, 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 a valid globallyroutable IPIPv4 address on the most likely point of attachment, 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. However if the host has a private address as defined in [RFC1918], then it SHOULD set the sender protocol address field (ar$spa) to the unspecified address (0.0.0.0). This is to avoid an address conflict in the case where the host has changed its point of attachment from one private network to another. Note: Some routers may refuse to answer an ARP Request sent with the sender protocol address field (ar$spa) set to the unspecified address (0.0.0.0). In this case the reachability test will fail. If a valid ARP Response 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 a valid routable IPv4 address leaseon 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 addressesaddress of the default gateway allows the host to confirm reachability even where the host moves 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. Sending an ICMP Echo Request [RFC792] to the default gateway IPv4 address does not provide the same level of assurance since this requires an ARP Request/Response to be sent first, and typically does not allow the MAC address to be checked as well. It therefore SHOULD NOT be used as a substitute. 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. If the initial ARP Request does not elicit a Response, the host waits for REACHABILITY_TIMER and then sends another ARP Request. If no ARP Response is received in response to this second Request, the host proceeds to the IPv4 address acquisition phase. If a valid ARP Response is received, but cannot be matched against known networks, the host assumes it has moved subnets and moves on to the address acquisition phase. 2.3. IPv4 Address Acquisition If the host has a valid cached configurationroutable IPv4 address on the "most likely" point of attachment, but is unable to confirm reachability tothe primary default gateway,reachability test fails, then the host seeks to verify the cachedconfiguration 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 a valid cached configuration, or had not previously obtained aroutable IPv4 address on the "most likely" point of attachment, thenthe 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 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 IPIPv4 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 cached IPpreviously 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 appropriateappropriate, 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. As described in [IPv4LL] Section 1.7, use of a routable address is preferred to a Link-Local IPv4 address whenever it is available. [RFC2131] Section 3.2 states that if the host possesses a valid routable IPv4 address on the "most likely" network andDHCP client does not receive a response after employing the retransmission algorithm, the client MAY choose to use the previously allocated network address and configuration parameters for the remainder of the unexpired lease. This is preferable to assigning a Link-Local IPv4 address if the host has good reason to believe that it remains connected to a network on which it possesses a valid IPv4 address lease. This would be the case, for example, where a host has received hintsbelieve that it believesremains connected to be "strong".a network on which it possesses a valid routable IPv4 address. See Appendix A for details. If the host does not have a valid IPv4 address lease on the "most likely" network and does not receive a response after employing the retransmission algorithm, it MAY assign a Link-Local IPv4 address. Since a Link-Local IPv4 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 Link-Local IPv4 address assignment as soon as a valid IPv4 address lease can be obtained. Where a Link-Local IPv4 address is assigned, experience has shown that five minutes (see [IPv4LL] 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 Link-Local IPv4 address. Should the DHCP client succeed in obtaining a routable address, then as noted in [IPv4LL], the Link-Local IPv4 address is deprecated. In order to avoid inappropriate assignment of an IPv4 Link-Local address, it is RECOMMENDED that such an address not be assigned until the DHCP client has retransmitted at least 3 times. 3. Constants The suggested default value of REACHABILITY_TIMER is 200 ms. This value was chosen so as to accomodateaccommodate the maximum retransmission timer likely to be experienced on an Ethernet network. 4. IANA Considerations Guidelines for IANA considerations are specified in [RFC2434]. This specification does not request the creation of any new parameter registries, nor does it require any other IANA assignments. 5. Security Considerations Detection of Network Attachment (DNA) is typically insecure, so that it is inadvisable for a host to adjust its security based on which network it believes it is attached to. For example, it would be inappropriate for a host to disable its personal firewall based on the belief that it had connected to a home network. ARP [RFC826] traffic is inherently insecure, so that the reachability test described in Section 1.3 can be easily spoofed by an attacker, leading a host to falsely conclude that it remainedis attached to a former network.network that it is not connected to. Similarly, where DHCP [RFC2131]traffic is not secured, an attacker could masquerade as a DHCP server, in order to convince the host that it was attached to a particular network. Where secure detection of network attachment is required, a host MAY wish toSHOULD skip the ARP-basedreachability test entirelysince it cannot be secured, and go immediately to the IPv4 address acquisition phase, utilizinginstead utilize authenticated DHCP [RFC3118]. 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. [IPv4LL] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", Internet draft (work in progress), draft-ietf-zeroconf-ipv4-linklocal-10.txt, October 2003.draft-ietf-zeroconf-ipv4-linklocal-12.txt, January 2004. 6.2. Informative References [RFC1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, Daydreamer, July 1994. [RFC1918] Rekhter, Y., et al., "Address Allocation for Private Internets", RFC 1918, February 1996. [RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998.[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC3580] Congdon, P., et al., "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines", RFC 3580, September 2003. [RFC2284bis] Blunk, L., et al., "Extensible Authentication Protocol (EAP)", draft-ietf-eap-rfc2284bis-08.txt, Internet draft (work in progress), February 2004. [IEEE8021AB] IEEE Standards for Local and Metropolitan Area Networks: Station and Media Access Control - Connectivity Discovery, IEEE Std 802.1AB/D5, September 2003. [IEEE8021X] IEEE Standards for Local and Metropolitan Area Networks: Port based Network Access Control, IEEE Std 802.1X-2001, June 2001. [IEEE802] IEEE Standards for Local and Metropolitan Area Networks: Overview and Architecture, ANSI/IEEE Std 802, 1990. [IEEE8021Q] IEEE Standards for Local and Metropolitan Area Networks: Draft Standard for Virtual Bridged Local Area Networks, P802.1Q, January 1998. [IEEE80211] 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-1999, 1999. Acknowledgments The authors would like to acknowledge Greg Daley of Monash University, Erik Guttman and Erik Nordmark of Sun Microsystems, Ted Lemon of Nominum and Thomas Narten of IBM for contributions to this document. Authors' Addresses Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 EMail: email@example.com Phone: +1 425 706 6605 Fax: +1 425 936 7329 Appendix A - Hints In order to assist in IPv4 network attachment detection, information associated with each network may be retained by the host. Based on IP and link-layer information, the host may be able to make an educated guess as to whether it has moved between subnets, or remained on the same subnet. If itthe host is likely to have moved between subnets, the hostit may havebe possible to make an educated guess as to which subnet it has moved to. The term "strong hint" refers to information which providesSince an unambiguous indication of the networkeducated guess may be incorrect, prior to which aconcluding that the host has connected. "Weak hints" involve information which is inconclusive.remains on the same subnet, further tests (such as a reachability test or a DHCPREQUEST sent from the INIT-REBOOT state) are REQUIRED. IPv4 ICMP Router Discovery messages [RFC1256] provide information directly relevantrelating to determiningprefix(es) available on the network to which alink. A host has connected. As such, information gleaned from Router Advertisements can be consideredmay use such a "strong" hint.message to conclude that an advertised prefix is available; however it cannot conclude the converse -- that prefixes not advertised are unavailable. For networks running over PPP [RFC1661], "weak" hints include the link characteristics negotiated in LCP, and the associated phone number. TheIP parameters negotiated in IPCP are consideredprovide direct information on whether a "strong" hint.previously obtained address remains valid on the link. On IEEE 802 [IEEE802] wired networks, hints include link-layer discovery traffic as well as information exchanged as part of IEEE 802.1X authentication [IEEE8021X]. Link-layer discovery traffic includes Link Layer Discovery Protocol (LLDP) [IEEE8021AB] traffic as well as network identification information passed in the EAP- Request/IdentityEAP-Request/Identity or within an EAP method exchange, as defined in EAP [RFC2284].[RFC2284bis]. For example, LLDP advertisements can provide information on the IP address orVLANs supported by the device. These hints, if provided, are considered "strong".When used with IEEE 802.1X authentication [IEEE8021X], the EAP-Request/Identity exchange may contain the name of the authenticator, also providing information on the potential network. Similarly, 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 [IEEE8021Q] to be assigned dynamically, so thisthat static informationadvertisements may not prove definitive. As a result, these hints are considered "weak".In IEEE 802.11 [IEEE80211] 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 AdhocAd 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 [IEEE8021X] 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. Thus, associating to the same SSID is a necessary, but not necessarily a sufficient condition, for remaining within the same subnet: while a Station associating to the same SSID may not necessarily 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 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. Such hints are considered "strong"; all other IEEE 802.11 hints are considered "weak".As noted earlier, VLANs may be determined dynamically so that these information elements may not be reliable. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003).(2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Open issues Open issues relating to this specification are tracked on the following web site: http://www.drizzle.com/~aboba/DNA/dnaissues.html Expiration Date This memo is filed as <draft-ietf-dhc-dna-ipv4-04.txt>,<draft-ietf-dhc-dna-ipv4-05.txt>, and expires AprilAugust 22, 2004.