[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 RFC 4436

DHC Working Group                                          Bernard Aboba
INTERNET-DRAFT                                     Microsoft Corporation
Category: Proposed Standard
<draft-ietf-dhc-dna-ipv4-07.txt>
14 April 2004




             Detection of Network Attachment (DNA) in IPv4


   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3667.


   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 October 22, 2004.


Copyright Notice


   Copyright (C) The Internet Society (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 document synthesizes experience garnered
   over the years in the deployment of hosts supporting ARP, DHCP and
   Link-Local IPv4 addresses.  A procedure is specified for detection of
   network attachment in order to better accommodate mobile hosts.







Aboba                       Proposed Standard                   [Page 1]

INTERNET-DRAFT                    DNAv4                    14 April 2004



Table of Contents


1.  Introduction..............................................    3
      1.1    Requirements ....................................    3
      1.2    Terminology .....................................    3
2.  Framework ................................................    4
      2.1    Most Likely Point of Attachment .................    5
      2.2    Reachability Test ...............................    6
      2.3    IPv4 Address Acquisition ........................    8
      2.4    Link-Local IPv4 Addresses .......................    9
3.  Constants ................................................   10
4.  IANA Considerations ......................................   10
5.  Security Considerations ..................................   10
6.  References ...............................................   11
      6.1    Normative references ............................   11
      6.2    Informative references ..........................   11
Acknowledgments ..............................................   12
Authors' Addresses ...........................................   13
Appendix A - Link Layer Hints ................................   14
      A.1    Introduction ....................................   14
      A.2    Hints ...........................................   15
Intellectual Property Statement ..............................   16
Full Copyright Statement .....................................   17





























Aboba                       Proposed Standard                   [Page 2]

INTERNET-DRAFT                    DNAv4                    14 April 2004



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.


   This document concerns the interaction of mechanisms used by IPv4
   protocol stacks.  Network attachment detection and its interaction
   with interface configuration is considered elsewhere, for example in
   Neighbor Discovery for IPv6 [RFC2461], IPv6 Stateless Address
   Autoconfiguration [RFC2462] and Mobility Support in IPv6 [MIPv6].


1.1.  Requirements


   In this document, several words are used to signify the requirements
   of 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
   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. If the sender 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 the target of an ARP packet, or the broadcast
     address if the target hardware address is unknown.






Aboba                       Proposed Standard                   [Page 3]

INTERNET-DRAFT                    DNAv4                    14 April 2004



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.


DHCP client
     A DHCP client or "client" is an Internet host using DHCP 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.


Routable address
     In this specification, the term "routable address" refers to any
     address other than an Link-Local IPv4 address.  This includes
     private addresses as specified in [RFC1918].


Valid address
     In this specification, the term "valid 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.  Framework


   For Detection of Network attachment, the following basic principles
   are suggested:


   [a] Utilization of hints. Link layers such as IEEE 802
       [IEEE802] provide hints whether a host remains
       on the same subnet despite changing its point of
       attachment, or whether a host is connected to an
       ad hoc or infrastructure network.  Prior to connecting
       to a new point of attachment, the host uses available
       hints to determine the "most likely" configuration
       associated with the new point of attachment.  Since
       hints are not infallible, the host should be capable of
       making the correct determination even in the presence of
       misleading hints.  For details see Appendix A.


   [b] Treatment of link-up indications.  On connecting
       to a new point of attachment, the host attempts to
       verify the "most likely" configuration associated
       with the new point of attachment.


   [c] Treatment of link-down indications.  On disconnection
       from a network, there is no need to take action until the
       host is reconnected, since it is typically not possible




Aboba                       Proposed Standard                   [Page 4]

INTERNET-DRAFT                    DNAv4                    14 April 2004



       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.


   [d] Handling of Link-Local IPv4 addresses.  Experience has
       shown that Link-Local IPv4 addresses are often assigned
       inappropriately.  This document suggests that hosts
       behave conservatively with respect to assignment of
       Link-Local IPv4 addresses, configuring them only in
       situations in which they can do no harm.


2.1.  Most Likely Point of 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:


    [1] Link 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] Whether a network is an infrastructure or adhoc 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.  In the absence of other information, by
   default the host may assume that the "most likely" point of
   attachment is the network to which it was most recently attached.


2.1.1.  Alternative Mechanisms


   Aside from utilizing link layer hints, a host may also be able to
   utilize Internet layer information in order to determine the "most
   likely" point of attachment.


   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.


   However, since [RFC1256] is not widely implemented, in general, it is
   NOT RECOMMENDED that hosts utilize ICMP Router Discovery messages as
   an alternative to the reachability test outlined in Section 2.2.




Aboba                       Proposed Standard                   [Page 5]

INTERNET-DRAFT                    DNAv4                    14 April 2004



   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.


2.2.  Reachability Test


   If the host has a valid routable IPv4 address on the "most likely"
   point of attachment, the host will typically perform a reachability
   test, as described in this section.  The purpose of the reachability
   test is to confirm whether the host is connected to a network on
   which it has a valid routable IPv4 address.


   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,
   described in Section 2.3.


   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 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.


   [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 network attachment is required.
       See Section 5 for details.


   The reachability test is performed by attempting to verify
   reachability of default gateway(s) on the "most likely" point of
   attachment.  This reduces roaming latency by allowing the host to
   bypass DHCP as well as subsequent Duplicate Address Detection (DAD).
   In contrast to a DHCP exchange, which may be between a DHCP client
   and an off-link DHCP server, the reachability test occurs between a
   host and its next hop router.





Aboba                       Proposed Standard                   [Page 6]

INTERNET-DRAFT                    DNAv4                    14 April 2004



   The host may probe only the primary default gateway, or it may probe
   primary and secondary default gateways, in series or in parallel.  If
   the reachability test is successful, the host may continue to use a
   valid routable IPv4 address without having to re-acquire it.
   However, 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 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 routable IPv4 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 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 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.





Aboba                       Proposed Standard                   [Page 7]

INTERNET-DRAFT                    DNAv4                    14 April 2004



   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_TIMEOUT and 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 routable IPv4 address on the "most likely"
   point of attachment, but the reachability test fails, then 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 a valid routable IPv4 address on the "most
   likely" point of attachment, 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 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




Aboba                       Proposed Standard                   [Page 8]

INTERNET-DRAFT                    DNAv4                    14 April 2004



   since the DHCPREQUEST will bypass the DHCP relay and will contain an
   invalid source address.


2.4.  Link-Local IPv4 Addresses


   To avoid inappropriate assignment of Link-Local IPv4 addresses, it is
   recommended that hosts behave conservatively with respect to
   assignment of Link-Local IPv4 addresses.  As described in [IPv4LL]
   Section 1.7, use of a routable address is preferred to a Link-Local
   IPv4 address whenever it is available.


   Where the host does not have a valid routable IPv4 address on the
   "most likely" point of attachment, the host MAY configure an Link-
   Local IPv4 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 Link-Local IPv4 address is
   deprecated, as noted in [IPv4LL].


   Where a host has a valid routable IPv4 address on the "most likely"
   point of attachment, 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 a valid routable IPv4
   address, that address SHOULD be used, rather than assigning 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.


   As described in [IPv4LL] Appendix A, once a Link-Local IPv4 address
   is assigned, existing implementations do not query the DHCPv4 server
   again for 5 minutes.  This behavior is in violation of [RFC2131]
   Section 4.1.


   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




Aboba                       Proposed Standard                   [Page 9]

INTERNET-DRAFT                    DNAv4                    14 April 2004



   address.  Should the DHCP client succeed in obtaining a routable
   address, then as noted in [IPv4LL], the Link-Local IPv4 address is
   deprecated.


   Since it is inevitable that hosts will inappropriately configure
   Link-Local IPv4 addresses at some point, hosts with routable IPv4
   addresses SHOULD be able to respond to peers with Link-Local IPv4
   addresses, as per [IPv4LL].  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
   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


   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 is attached to a network
   that it is not connected to.  Similarly, where DHCP 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
   SHOULD skip the reachability test since it cannot be secured, and
   instead utilize authenticated DHCP [RFC3118].









Aboba                       Proposed Standard                  [Page 10]

INTERNET-DRAFT                    DNAv4                    14 April 2004



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 Link-Local IPv4 Addresses", Internet draft (work in
          progress), draft-ietf-zeroconf-ipv4-linklocal-15.txt, April
          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.


[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
          Considerations Section in RFCs", BCP 26, RFC 2434, October
          1998.


[RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery
          for IP Version 6 (IPv6)", RFC 2461, December 1998.


[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
          Autoconfiguration", RFC 2462, December 1998.






Aboba                       Proposed Standard                  [Page 11]

INTERNET-DRAFT                    DNAv4                    14 April 2004



[MIPv6]   Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
          IPv6", draft-ietf-mobileip-ipv6-24.txt, June 2003.


[RFC3580] Congdon, P., et al., "IEEE 802.1X Remote Authentication Dial
          In User Service (RADIUS) Usage Guidelines", RFC 3580,
          September 2003.


[RFC3748] Blunk, L., et al., "Extensible Authentication Protocol (EAP)",
          RFC 3748, March 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-2004, June 2004.


[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.












Aboba                       Proposed Standard                  [Page 12]

INTERNET-DRAFT                    DNAv4                    14 April 2004



Authors' Addresses


   Bernard Aboba
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052


   EMail: bernarda@microsoft.com
   Phone: +1 425 706 6605
   Fax:   +1 425 936 7329










































Aboba                       Proposed Standard                  [Page 13]

INTERNET-DRAFT                    DNAv4                    14 April 2004



Appendix A - Link Layer Hints


A.1  Introduction


   In order to assist in IPv4 network attachment detection, 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 = 100 ms, REACH_TIME = 10 ms, and
   REACHABILITY_TIMEOUT = 1000ms, then:


   x = (100 - 10)/(1000 + 100 - 10) = 8.2 percent


   Therefore the hint need only be wrong 8.2 percent of the time before
   it is not worth considering.







Aboba                       Proposed Standard                  [Page 14]

INTERNET-DRAFT                    DNAv4                    14 April 2004



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 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/Identity or within an EAP
   method exchange, as defined in EAP [RFC3748].


   For example, LLDP advertisements can provide information on VLANs
   supported by the device.  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 that static advertisements may not prove definitive.


   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 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 [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.




Aboba                       Proposed Standard                  [Page 15]

INTERNET-DRAFT                    DNAv4                    14 April 2004



   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
   point of attachment supports adhoc networking, and therefore that
   assignment of a Link-Local IPv4 address is likely.  When running IPv4
   over PPP, if an IP address is not statically configured or  assigned
   via IPCP, this can also be taken as a hint that assignment of a Link-
   Local IPv4 address is likely.  In addition, certain media such as USB
   or IEEE 1394 may be considered inherently more likely to support
   adhoc operation, so that connection to these networks may by itself
   be considered a hint.


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.














Aboba                       Proposed Standard                  [Page 16]

INTERNET-DRAFT                    DNAv4                    14 April 2004



Full Copyright Statement


   Copyright (C) The Internet Society (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-07.txt>,  and  expires
   October 22, 2004.
















Aboba                       Proposed Standard                  [Page 17]

Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/