One document matched: draft-ietf-dhc-dna-ipv4-16.txt
Differences from draft-ietf-dhc-dna-ipv4-15.txt
DHC Working Group Bernard Aboba
INTERNET-DRAFT Microsoft Corporation
Category: Proposed Standard
<draft-ietf-dhc-dna-ipv4-16.txt>
23 September 2005
Detecting Network Attachment (DNA) in IPv4
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 10, 2006.
Copyright Notice
Copyright (C) The Internet Society 2005.
Abstract
The time required to detect movement between networks, and to obtain
(or continue to use) an IPv4 configuration may be significant as a
fraction of the total handover latency in moving between points of
attachment. This document synthesizes from experience in the
deployment of hosts supporting ARP, DHCP, and IPv4 Link-Local
addresses a set of steps known as Detecting Network Attachment for
IPv4 (DNAv4), in order to decrease the handover latency in moving
between points of attachment.
Aboba Proposed Standard [Page 1]
INTERNET-DRAFT DNAv4 25 September 2005
Table of Contents
1. Introduction.............................................. 3
1.1 Requirements .................................... 3
1.2 Terminology ..................................... 3
2. Overview ................................................. 4
2.1 Reachability Test ............................... 5
2.2 IPv4 Address Acquisition ........................ 7
2.3 IPv4 Link-Local Addresses ....................... 8
3. Constants ................................................ 9
4. IANA Considerations ...................................... 9
5. Security Considerations .................................. 9
6. References ............................................... 10
6.1 Normative references ............................ 10
6.2 Informative references .......................... 10
Acknowledgments .............................................. 10
Authors' Addresses ........................................... 11
Intellectual Property Statement .............................. 11
Disclaimer of Validity ....................................... 11
Copyright Statement .......................................... 12
Aboba Proposed Standard [Page 2]
INTERNET-DRAFT DNAv4 25 September 2005
1. Introduction
The time required to detect movement between networks and to obtain
(or continue to use) an operable IPv4 configuration may be
significant as a fraction of the total handover latency in moving
between points of attachment.
This document synthesizes from experience in the deployment of hosts
supporting ARP [RFC826], DHCP [RFC2131], and IPv4 Link-Local
addresses [RFC3927] a set of steps known as Detecting Network
Attachment for IPv4 (DNAv4). DNAv4 optimizes the (common) case of
reattachment to a network that one has been connected to previously
by attempting to re-use a previous (but still valid) configuration,
reducing the reattachment time to a few milliseconds on LANs. Since
this procedure is dependent on the ARP protocol, it is not suitable
for use on media that do not support ARP.
1.1. Requirements
In this document, several words are used to signify the requirements
of the specification. The key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
1.2. Terminology
This document uses the following terms:
ar$sha
ARP packet field: Sender Hardware Address [RFC826]. The hardware
(MAC) address of the originator of an ARP packet.
ar$spa
ARP packet field: Sender Protocol Address [RFC826]. For IP Address
Resolution this is the IPv4 address of the sender of the ARP
packet.
ar$tha
ARP packet field: Target Hardware Address [RFC826]. The hardware
(MAC) address of the target of an ARP packet.
ar$tpa
ARP packet field: Target Protocol Address [RFC826]. For IPv4
Address Resolution, the IPv4 address for which one desires to know
the hardware address.
Aboba Proposed Standard [Page 3]
INTERNET-DRAFT DNAv4 25 September 2005
DHCP client
A DHCP client or "client" is an Internet host using the Dynamic
Host Configuration protocol (DHCP) [RFC2131] to obtain
configuration parameters such as a network address.
DHCP server
A DHCP server or "server" is an Internet host that returns
configuration parameters to DHCP clients.
Link A communication facility or medium over which network nodes can
communicate. Each link is associated with a minimum of two
endpoints. Each link endpoint has a unique link-layer identifier.
Link Down
An event provided by the link layer that signifies a state change
associated with the interface no longer being capable of
communicating data frames; transient periods of high frame loss are
not sufficient. DNAv4 does not utilize "Link Down" indications.
Link Layer
Conceptual layer of control or processing logic that is responsible
for maintaining control of the data link. The data link layer
functions provide an interface between the higher-layer logic and
the data link. The link layer is the layer immediately below IP.
Link Up
An event provided by the link layer that signifies a state change
associated with the interface becoming capable of communicating
data frames.
Point of Attachment
The link endpoint on the link to which the host is currently
connected.
Routable address
In this specification, the term "routable address" refers to any
IPv4 address other than an IPv4 Link-Local address. This includes
private addresses as specified in [RFC1918].
Operable address
In this specification, the term "operable address" refers to either
a static IPv4 address, or an address assigned via DHCPv4 which has
not been relinquished, and whose lease has not yet expired.
2. Overview
On connecting to a new point of attachment, the host responds to a
"Link Up" indication from the link layer by carrying out the DNAv4
Aboba Proposed Standard [Page 4]
INTERNET-DRAFT DNAv4 25 September 2005
procedure.
For each network that it connects to, it is assumed that the host
saves to stable storage the following parameters:
[1] The IPv4 and MAC address of the default gateway(s)
[2] The IPv4 configuration parameters, including
the assigned address and lease expiration time
From the set of networks which have operable IPv4 address(es)
associated with them, the host selects a subset, and attempts to
confirm the configuration for each network, using the reachability
test described in Section 2.1.
If the reachability test is successful, verifying bi-directional
connectivity to the default gateway(s), the host SHOULD continue to
use the operable routable IPv4 address associated with the confirmed
network, without needing to re-acquire it, allowing the host to
bypass Duplicate Address Detection (DAD).
If a DHCPv4 client is operational, it is RECOMMENDED that the host
attempt to obtain IPv4 configuration via DHCPv4 in parallel with the
reachability tests, with the host using the first answer returned.
This ensures that the DNAv4 procedure will not result in additional
delay in the case where reachability test(s) fail, or where sending a
DHCPREQUEST from the INIT-REBOOT state, as described in [RFC2131]
Section 3.2 and 4.3.2 completes more quickly than the reachability
test(s).
DNAv4 does not increase the likelihood of an address conflict. The
reachability test is only carried out for a network when the host has
previously completed duplicate address detection and obtained an
operable IPv4 configuration on that network. Restrictions on sending
ARP Requests and Responses are described in Section 2.1.1.
2.1. Reachability Test
The host skips the reachability test for a network if any of the
following conditions are true:
[a] The host does not have an operable routable IPv4
address on that network. In this case, the reachability
test cannot confirm that the host has an operable
routable IPv4 address, so completing the
reachability test would serve no purpose.
A host MUST NOT use the reachability test to
confirm configuration of an IPv4 Link-Local
Aboba Proposed Standard [Page 5]
INTERNET-DRAFT DNAv4 25 September 2005
address or a statically assigned IPv4 address.
[b] The host does not know the default gateway(s) on
that network. In this case, insufficient information
is available to carry out the reachability test.
[c] If secure detection of network attachment is required.
The reachability test utilizes ARP which is insecure.
For a particular network, the host MAY test reachability to the
primary default gateway, or it MAY test reachability to both the
primary and secondary default gateways, in series or in parallel. In
order to ensure configuration validity, the host SHOULD only
configure default gateway(s) which pass the reachability test.
In situations where more than one network is available on a given
link, or the network configuration has changed, it is possible for
the host to confirm more than one configuration. For example, it is
possible that one or more reachability test(s) succeed, and in
addition, configuration is provided via DHCPv4. In this case, a
DNAv4 implementation SHOULD prefer the configuration provided via
DHCPv4.
2.1.1. Packet Format
The reachability test is performed by sending an ARP Request. The
host MUST set the target protocol address (ar$tpa) to the IPv4
address of the default gateway being tested, and the sender protocol
address field (ar$spa) to its own IPv4 address. The ARP Request MUST
use the host MAC address as the source, and the default gateway MAC
address as the destination. The host includes its MAC address in the
sender hardware address field (ar$sha), and sets the target hardware
address field (ar$tha) to 0.
If a valid ARP Reply is received, the MAC address in the sender
hardware address field (ar$sha) in the ARP Reply is matched against
the target hardware address field (ar$tpa) in the ARP Request, and
the IPv4 address in the sender protocol address field (ar$spa) of the
ARP Reply is matched against the target protocol address field
(ar$tpa) in the ARP Request. If a match is found, then the host
continues to use that IPv4 address, subject to the lease re-
acquisition and expiration behavior described in [RFC2131], Section
4.4.5.
The risk of an address conflict is greatest when the host moves
between private networks, since in this case the completion of
Duplicate Address Detection on the former network does not provide
assurance against an address conflict on the new network. Until a
Aboba Proposed Standard [Page 6]
INTERNET-DRAFT DNAv4 25 September 2005
host with a private address has confirmed the operability of its IPv4
configuration, it SHOULD NOT respond to ARP Requests, and SHOULD NOT
broadcast ARP Requests containing its address within the sender
protocol address field (ar$spa). However, where the host has an
operable routable non-private address on a network, it MAY send ARP
Requests using its address within the sender protocol address field
(ar$spa) prior to confirming its IPv4 configuration, and MAY respond
to ARP Requests.
Sending an ICMP Echo Request [RFC792] to the default gateway IPv4
address does not provide the same level of assurance since this may
require an ARP Request/Reply exchange. Where the host has moved
between two private networks, this could result in ARP cache
pollution.
Where a host moves from one private network to another, an ICMP Echo
Request can result in an ICMP Echo Response even when the default
gateway has changed, as long as the IPv4 address remains the same.
This can occur, for example, where a host moves from one home
network using prefix 192.168/16 to another one. In addition, if the
ping is sent with TTL > 1, then an ICMP Echo Response can be received
from an off-link gateway. As a result, if the MAC address of the
default gateway is not checked, the host can mistakenly confirm
attachment, potentially resulting in an address conflict. As a
result, sending of an ICMP Echo Request SHOULD NOT be used as a
substitute for the reachability test.
In order to prevent synchronization, ARP Requests are delayed by a
random interval uniformly distributed on 0 to JITTER_INTERVAL. If
the initial ARP Request does not elicit a response, the host waits
for REACHABILITY_TIMEOUT. The timeout value is doubled with each
retransmission. It is RECOMMENDED that a host retransmit no more
than twice. To provide damping in the case of spurious "Link Up"
indications, it is recommended that the DNAv4 procedure be carried
out no more than once a second.
2.2. IPv4 Address Acquisition
If the host has an operable routable IPv4 address on one or more
networks, and DHCPv4 is enabled on the interface, the host SHOULD
attempt to acquire an IPv4 configuration using DHCPv4, in parallel
with one or more reachability tests. This is accomplished by
entering the INIT-REBOOT state, and sending a DHCPREQUEST to the
broadcast address as specified in [RFC2131] Section 4.4.2.
If the host does not have an operable routable IPv4 address on any
network, the host enters the INIT state and sends a DHCPDISCOVER
packet to the broadcast address, as described in [RFC2131] Section
Aboba Proposed Standard [Page 7]
INTERNET-DRAFT DNAv4 25 September 2005
4.4.1. If the host supports the Rapid Commit Option [RFC4039], it is
possible that the exchange can be shortened from a 4-message exchange
to a 2-message exchange.
If the host does not receive a response to a DHCPREQUEST or
DHCPDISCOVER, then it retransmits as specified in [RFC2131] Section
4.1.
As discussed in [RFC2131], Section 4.4.4, a host in INIT or REBOOTING
state that knows the address of a DHCP server may use that address in
the DHCPDISCOVER or DHCPREQUEST rather than the IPv4 broadcast
address. In the INIT-REBOOT state a DHCPREQUEST is sent to the
broadcast address so that the host will receive a response regardless
of whether the previously configured IPv4 address is correct for the
network to which it has connected.
Sending a DHCPREQUEST to the unicast address in INIT-REBOOT state is
not appropriate, since if the DHCP client has moved to another
subnet, a DHCP server response cannot be routed back to the client
since the DHCPREQUEST will bypass the DHCP relay and will contain an
invalid source address.
2.3. IPv4 Link-Local Addresses
Where the host does not have an operable routable IPv4 address on any
network, the host MAY configure an IPv4 Link-Local address prior to
entering the INIT state and sending a DHCPDISCOVER packet, as
described in [RFC2131] Section 2.3. Where a host can confirm that it
remains connected to a network on which it possesses an operable
routable IPv4 address, that address should be used and the IPv4 Link-
Local address is deprecated, as noted in [RFC3927] Section 1.9.
Where a host has an operable routable IPv4 address on one or more
networks, but the reachability test cannot confirm the configuration
and the DHCPv4 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.
As described in [RFC3927] Appendix A, once a Link-Local IPv4 address
is assigned, existing implementations do not query the DHCPv4 server
again for five minutes. This behavior violates [RFC2131] Section
4.1:
The retransmission delay SHOULD be doubled with
subsequent retransmissions up to a maximum of 64 seconds.
Instead of waiting for five minutes, a DHCP client should continue to
Aboba Proposed Standard [Page 8]
INTERNET-DRAFT DNAv4 25 September 2005
retry every 64 seconds, even after allocating a IPv4 Link-Local
address. If the DHCP client succeeds in obtaining a routable
address, then the IPv4 Link-Local address is deprecated, as noted in
[RFC3927] Section 1.9.
In order to enable communication with hosts that have assigned IPv4
Link-Local addresses, hosts with routable IPv4 addresses need to be
able to respond to peers with IPv4 Link-Local addresses, as per
[RFC3927] Section 1.8. 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. The default
value of JITTER_INTERVAL is 120ms.
4. IANA Considerations
This specification does not request the creation of any new parameter
registries, nor does it require any other IANA assignments.
5. Security Considerations
Detecting Network Attachment for IPv4 (DNAv4) is based on ARP and
DHCP and inherits the security vulnerabilities of these two
protocols.
ARP [RFC826] traffic is not secured, so that an attacker gaining
access to the network can spoof a response to the reachability test
described in Section 2.2, leading the querier to falsely conclude
that it is attached to a network that it is not connected to.
Similarly, where DHCPv4 traffic is not secured, an attacker could
masquerade as a DHCPv4 server, in order to convince the host that it
was attached to a particular network. This and other threats
relating to DHCPv4 are described in "Authentication for DHCP
Messages" [RFC3118].
The effect of these attacks will typically be limited to denial of
service, unless the host utilizes its IP configuration for other
purposes, such as security configuration or location determination.
For example, a host that disables its personal firewall based on
evidence that it had attached to a home network could be compromised
Aboba Proposed Standard [Page 9]
INTERNET-DRAFT DNAv4 25 September 2005
by spoofing of the DNAv4 reachability test. In general, adjustment
of the security configuration based on DNAv4 is NOT RECOMMENDED.
Hosts that depend on secure IP configuration SHOULD NOT use DNAv4,
but SHOULD instead utilize DHCP authentication [RFC3118], possibly in
combination with the Rapid Commit Option [RFC4039].
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.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March, 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages",
RFC 3118, June 2001.
[RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration
of IPv4 Link-Local Addresses", RFC 3927, May 2005.
6.2. Informative References
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and
E. Lear, "Address Allocation for Private Internets", RFC 1918,
February 1996.
[RFC4039] Park, S., Kim, P., and B. Volz, "Rapid Commit Option for the
Dynamic Host Configuration Protocol version 4 (DHCPv4)", RFC
4039, March 2005.
Acknowledgments
The authors would like to acknowledge Greg Daley of Monash
University, Erik Guttman, James Carlson and Erik Nordmark of Sun
Microsystems, Ralph Droms of Cisco Systems, Ted Lemon of Nominum,
Stuart Cheshire of Apple Computer, John Loughney of Nokia, Thomas
Narten of IBM and David Hankins of ISC for contributions to this
Aboba Proposed Standard [Page 10]
INTERNET-DRAFT DNAv4 25 September 2005
document.
Authors' Addresses
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
EMail: bernarda@microsoft.com
Phone: +1 425 818 4011
Fax: +1 425 936 7329
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Aboba Proposed Standard [Page 11]
INTERNET-DRAFT DNAv4 25 September 2005
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Open issues
Open issues relating to this specification are tracked
on the following web site:
http://www.drizzle.com/~aboba/DNA/
Aboba Proposed Standard [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-21 21:37:40 |