[Docs] [txt|pdf] [Tracker] [WG] [Email] [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: Best Current Practice
<draft-ietf-dhc-dna-ipv4-00.txt>
10 August 2003



             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).  All Rights Reserved.

Abstract

This specification attempts to synthesize experience garnered over the
years in the deployment of hosts supporting ARP, DHCP and IPv4 Link-
Local addresses.  Given this experience, this document suggests
optimizations for detection of network attachment in IPv4 as well as
heuristics for determining when assignment of an IPv4 Link-Local address
is appropriate.











Aboba                              BCP                          [Page 1]

INTERNET-DRAFT                    DNAv4                   10 August 2003


Table of Contents

1.  Introduction..............................................    3
      1.1    Requirements ....................................    3
      1.2    Terminology .....................................    3
2.  Framework ................................................    4
      2.1    Most Likely Point of Attachment .................    4
      2.2    Reachability test ...............................    5
      2.3    IPv4 Address Acquisition ........................    6
3.  IANA Considerations ......................................    8
4.  Security Considerations ..................................    8
5.  References ...............................................    8
      5.1    Normative references ............................    8
      5.2    Informative references ..........................    9
Acknowledgments ..............................................   10
Authors' Addresses ...........................................   10
Appendix A - Hints ...........................................   11
Intellectual Property Statement ..............................   12
Full Copyright Statement .....................................   12
































Aboba                              BCP                          [Page 2]

INTERNET-DRAFT                    DNAv4                   10 August 2003


1.  Introduction

This draft attempts to synthesize experience garnered over the years in
the deployment of hosts supporting ARP [RFC826], DHCP [RFC2131], and
Link-Local IPv4 addresses [IPv4LL].  Experience has indicated the
importance of several goals in detection of network attachment:

[a]  Avoiding inappropriate assignment of Link-Local IPv4 addresses.
     Experience has shown that in the vast majority of cases,  the
     assignment of Link-Local IPv4 addresses is inappropriate.  That is,
     the IPv4 host assigning an Link-Local IPv4  address either is not
     connected to a network at all, in which case assignment of an Link-
     Local IPv4 address does no good; or the host is in fact present on
     a network with a DHCPv4 server but for one reason or another does
     not receive a response to a DHCPREQUEST or DHCPDISCOVER.

[b]  Latency Optimization.  The time required to detect movement (or
     lack of movement) between subnets, and to obtain (or continue to
     use) a valid IPv4 address represents a significant fraction of the
     overall latency resulting from movement between points of
     attachment on the network.  As a result, optimization of detection
     of network attachment in IPv4 hosts is helpful, to the extent that
     it is achievable.

In order to achieve these goals, this document specifies procedures
conducted on connection to a network.  On disconnection from a network,
there is no need to take action until 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.

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:

DHCP client    A DHCP client or "client" is an Internet host using DHCP
               to obtain configuration parameters such as a network
               address.





Aboba                              BCP                          [Page 3]

INTERNET-DRAFT                    DNAv4                   10 August 2003


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 IPv4 Link-Local address.
               This includes private addresses as specified in
               [RFC1918].

2.  Framework

This document specifies a procedure to be performed for IPv4 network
attachment detection that depends on three phases: determination of the
"most likely" point of attachment, a reachability test phase, and an
IPv4 address acquisition phase.

The following basic principles are suggested:

[1]  Utilization of link layer hints. Link layers such as IEEE 802
     [IEEE802] provide hints about whether a host remains on the same
     subnet despite changing its point of attachment, or even whether
     the host is connected to an adhoc or infrastructure network.  Where
     available, these hints can be used to guide host behavior - with
     the understanding that they are not infallible and therefore that
     the host should be capable of making the correct determination even
     in the presence of misleading hints.  Link layer hints are
     described in more detail in Appendix A.

[2]  Link-Local IPv4 addressing as a mechanism of last resort.  In
     existing implementations of [IPv4LL], once a Link-Local IPv4
     address is assigned, the DHCPv4 server may not be queried again for
     5 minutes.  As a result, the inappropriate assignment of a Link-
     Local IPv4 address results in an extended period of limited
     connectivity.  For a host that may change its point of attachment
     more frequently than every 5 minutes, the inappropriate assignment
     of an Link-Local IPv4 address is more than just an annoyance - it
     can result in an ongoing inability to connect.  As a result, this
     document suggests that hosts behave conservatively with respect to
     assignment of Link-Local IPv4 addresses, using them only as a last
     resort.

2.1.  Most Likely Point of Attachment

On connecting to a new point of attachment, the host attempts to
determine the "most likely" configuration associated with the new point
of attachment.





Aboba                              BCP                          [Page 4]

INTERNET-DRAFT                    DNAv4                   10 August 2003


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]  IP and link layer hints associated with each network. For details,
     see Appendix A.

[2]  The IP and MAC address of default gateway(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, by default
the host assumes that the "most likely" point of attachment is the
network to which it was most recently connected.

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.
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.2.  Reachability Test

The purpose of the reachability test is for the host to quickly
determine whether it is connected to a network on which it had
previously obtained a still valid routable IPv4 address.  The test is
performed by attempting to verify reachability of a previously
configured primary default gateway on a former 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.

The host skips the reachability test and proceeds to the address
acquisition phase in the following circumstances:

[a]  If the host does not have information on the default gateway on the
     network.

[b]  If the host does not have a valid routable IPv4 address on the
     network.  Since Link-Local IPv4 addresses are a last resort, these
     addresses do not count as a valid routable IPv4 address.

2.2.1.  Packet Format

To perform the reachability test, an ARP Request SHOULD be sent, using
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).  Since the host



Aboba                              BCP                          [Page 5]

INTERNET-DRAFT                    DNAv4                   10 August 2003


has not yet confirmed the subnet on which it is attached, it MUST set
the sender protocol address field (ar$spa) to 0.0.0.0.  This prevents
poisoning of the ARP cache with a (potentially invalid) sender IPv4
address.

If a valid ARP Response is received, the MAC address in the target
hardware address field (ar$tha) and the IPv4 address in the target
protocol address field (ar$tpa) are matched against the list of networks
and associated default gateway parameters.  If a match is found,  then
if the host has a valid IPv4 address lease 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 and MAC addresses 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 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
200ms 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 configuration on the "most likely" point
of attachment, but is unable to confirm reachability to the primary
default gateway, then the host seeks to verify the cached configuration
by entering the INIT-REBOOT state, and sending a DHCPREQUEST to the
broadcast address as specified in [RFC2131] Section 4.4.2.





Aboba                              BCP                          [Page 6]

INTERNET-DRAFT                    DNAv4                   10 August 2003


If the host does not have a valid cached configuration, or had not
previously obtained a routable IPv4 address on the "most likely" point
of attachment, then 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 IP broadcast address.
However, sending a DHCPREQUEST to the unicast address when in INIT-
REBOOT state is not appropriate since it is possible that the client has
moved to another subnet, and therefore the DHCPREQUEST needs to be
forwarded to and from the DHCP server by a DHCP Relay so that the
response can be broadcast.  This ensures that the host will receive a
response regardless of whether the cached IP address is correct for the
network to which it has connected.

As noted in [RFC2131] Section 3.2, if the host possesses a valid
routable IPv4 address on the "most likely" network and 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 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 "hints" that it believes to be "strong".  See Appendix A
for details.

Alternatively, 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.  This is the preferred behavior only in situations where an
adhoc network is likely to be in operation.  For example, a host might
choose to assign an IPv4 Link-Local address on an IEEE 1394 or adhoc
IEEE 802.11 network, unless a routable IPv4 address had previously been
assigned on that network.

However even in this situation, it is possible that the failure to
obtain a routable IPv4 address represents a temporary aberration, rather
than legitimate detection of an adhoc network.  It is therefore
desirable to abandon the assignment of an Link-Local IPv4 address as
soon as a valid IPv4 address lease can be obtained.  Where an IPv4 Link-
Local address is assigned, it is therefore RECOMMENDED that the host
attempt to obtain an IPv4 address at 30 second intervals.





Aboba                              BCP                          [Page 7]

INTERNET-DRAFT                    DNAv4                   10 August 2003


3.  IANA Considerations

This specification does not request the creation of any new parameter
registries, not does it require any other IANA assignments

4.  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 believe 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 conclude that it remained attached to a former
network.  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 to skip the ARP-based reachability test entirely since it cannot be
secured, and go immediately to the IPv4 address acquisition phase,
utilizing authenticated DHCP [RFC3118].

5.  References

5.1.  Normative References

[RFC791]       Postel, J., "Internet Protocol", RFC 791, USC/Information
               Sciences Institute, September 1981.

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



Aboba                              BCP                          [Page 8]

INTERNET-DRAFT                    DNAv4                   10 August 2003


[RFC2132]      Alexander, S. and Droms, R., "DHCP Options and BOOTP
               Vendor Extensions", RFC 2132, Silicon Graphics, Inc.,
               Bucknell University, March 1997.

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

[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-09.txt, August 2003.

5.2.  Informative References

[RFC1034]      Mockapetris, P., "Domain Names - Concepts and
               Facilities", STD 13, RFC 1034, USC/Information Sciences
               Institute, November 1987.

[RFC1035]      Mockapetris, P., "Domain Names - Implementation and
               Specification", STD 13, RFC 1035, USC/Information
               Sciences Institute, November 1987.

[RFC1058]      Hedrick, C.L., "Routing Information Protocol", RFC 1058,
               Rutgers University, June 1, 1988.

[RFC1332]      McGregor, G., "PPP Internet Control Protocol", RFC 1332,
               Merit, May 1992.

[RFC1661]      Simpson, W., Editor, "The Point-to-Point Protocol (PPP)",
               STD 51, RFC 1661, Daydreamer, July 1994.

[RFC1877]      Cobb, S., "PPP Internet Protocol Control Protocol
               Extensions for Name Server Addresses", RFC 1877, December
               1995.

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

[IEEE8021X]    IEEE Standards for Local and Metropolitan Area Networks:
               Port based Network Access Control, IEEE Std 802.1X-2001,
               June 2001.



Aboba                              BCP                          [Page 9]

INTERNET-DRAFT                    DNAv4                   10 August 2003


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

[IEEE8023]     ISO/IEC 8802-3 Information technology -
               Telecommunications and information exchange between
               systems - Local and metropolitan area networks - Common
               specifications - Part 3:  Carrier Sense Multiple Access
               with Collision Detection (CSMA/CD) Access Method and
               Physical Layer Specifications, (also ANSI/IEEE Std 802.3-
               1996), 1996.

[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 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: bernarda@microsoft.com
Phone: +1 425 706 6605
Fax:   +1 425 936 7329













Aboba                              BCP                         [Page 10]

INTERNET-DRAFT                    DNAv4                   10 August 2003


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 it is likely to have moved between subnets, the host
may have an educated guess as to which subnet it has moved to.  The term
"strong hint" refers to information which provides an unambiguous
indication of the network to which a host has connected. "Weak hints"
involve information which is inconclusive.

IPv4 ICMP Router Discovery messages [RFC1256] provide information
directly relevant to determining the network to which a host has
connected.  As such, information gleaned from Router Advertisements can
be considered a "strong" hint.

For networks running over PPP [RFC1661], "weak" hints include the link
characteristics negotiated in LCP, and the associated phone number.  The
IP parameters negotiated in IPCP are considered a "strong" hint.

On IEEE 802 wired networks, hints include link-layer discovery traffic
as well as information exchanged as part of IEEE 802.1X authentication.
Link-layer discovery traffic includes Link Layer Discovery Protocol
[LLDP] traffic as well as network identification information passed in
the EAP-Request/Identity or within an EAP method exchange.

For example, LLDP advertisements can provide information on the IP
address or VLANs supported by the device.  These hints, if provided, are
considered "strong"; all other hints are considered "weak".  When used
with IEEE 802.1X authentication, 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.

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 Adhoc mode.  As described in [Congdon], 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



Aboba                              BCP                         [Page 11]

INTERNET-DRAFT                    DNAv4                   10 August 2003


the same subnet;  on the other hand, a Station associating to a
different SSID is likely to have changed subnets.  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".

Intellectual Property Statement

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



Aboba                              BCP                         [Page 12]

INTERNET-DRAFT                    DNAv4                   10 August 2003


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-00.txt>,  and  expires
February 22, 2004.



































Aboba                              BCP                         [Page 13]


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