draft-ietf-dhc-dna-ipv4-14.txt   draft-ietf-dhc-dna-ipv4-15.txt 
DHC Working Group Bernard Aboba DHC Working Group Bernard Aboba
INTERNET-DRAFT Microsoft Corporation INTERNET-DRAFT Microsoft Corporation
Category: Proposed Standard Category: Proposed Standard
<draft-ietf-dhc-dna-ipv4-14.txt> <draft-ietf-dhc-dna-ipv4-15.txt>
6 August 2005 9 August 2005
Detecting Network Attachment (DNA) in IPv4 Detecting Network Attachment (DNA) in IPv4
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Copyright Notice Copyright Notice
Copyright (C) The Internet Society 2005. Copyright (C) The Internet Society 2005.
Abstract Abstract
The time required to detect movement between networks, and to obtain The time required to detect movement between networks, and to obtain
(or continue to use) an IPv4 configuration may be significant as a (or continue to use) an IPv4 configuration may be significant as a
fraction of the total handover latency in moving between points of fraction of the total handover latency in moving between points of
attachment. This document synthesizes experience in the deployment attachment. This document synthesizes from experience in the
of hosts supporting ARP, DHCP, and IPv4 Link-Local addresses to deployment of hosts supporting ARP, DHCP, and IPv4 Link-Local
define a set of steps known as Detecting Network Attachment for IPv4 addresses a set of steps known as Detecting Network Attachment for
(DNAv4), in order to decrease the handover latency in moving between IPv4 (DNAv4), in order to decrease the handover latency in moving
points of attachment. between points of attachment.
Table of Contents Table of Contents
1. Introduction.............................................. 3 1. Introduction.............................................. 3
1.1 Requirements .................................... 3 1.1 Requirements .................................... 3
1.2 Terminology ..................................... 3 1.2 Terminology ..................................... 3
2. Overview ................................................. 5 2. Overview ................................................. 5
2.1 Most Likely Network(s) .......................... 6 2.1 Most Likely Network(s) .......................... 6
2.2 Reachability Test ............................... 6 2.2 Reachability Test ............................... 6
2.3 IPv4 Address Acquisition ........................ 8 2.3 IPv4 Address Acquisition ........................ 8
skipping to change at page 3, line 12 skipping to change at page 3, line 12
Disclaimer of Validity ....................................... 17 Disclaimer of Validity ....................................... 17
Copyright Statement .......................................... 18 Copyright Statement .......................................... 18
1. Introduction 1. Introduction
The time required to detect movement between networks and to obtain The time required to detect movement between networks and to obtain
(or continue to use) an operable IPv4 configuration may be (or continue to use) an operable IPv4 configuration may be
significant as a fraction of the total handover latency in moving significant as a fraction of the total handover latency in moving
between points of attachment. between points of attachment.
This document synthesizes experience in the deployment of hosts This document synthesizes from experience in the deployment of hosts
supporting ARP [RFC826], DHCP [RFC2131], and IPv4 Link-Local supporting ARP [RFC826], DHCP [RFC2131], and IPv4 Link-Local
addresses [RFC3927] to define a set of steps known as Detecting addresses [RFC3927] a set of steps known as Detecting Network
Network Attachment for IPv4 (DNAv4). DNAv4 optimizes the (common) Attachment for IPv4 (DNAv4). DNAv4 optimizes the (common) case of
case of reattachment to a network that one has been connected to reattachment to a network that one has been connected to previously
previously by attempting to re-use a previous (but still valid) by attempting to re-use a previous (but still valid) configuration,
configuration, reducing the reattachment time to a few milliseconds reducing the reattachment time to a few milliseconds on LANs. Since
on LANs. Since this procedure is dependent on the ARP protocol, it this procedure is dependent on the ARP protocol, it is not suitable
is not suitable for use on media that do not support ARP. for use on media that do not support ARP.
1.1. Requirements 1.1. Requirements
In this document, several words are used to signify the requirements In this document, several words are used to signify the requirements
of the specification. The key words "MUST", "MUST NOT", "REQUIRED", of the specification. The key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as described in and "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
1.2. Terminology 1.2. Terminology
skipping to change at page 8, line 19 skipping to change at page 8, line 19
host with a private address has confirmed the operability of its IPv4 host with a private address has confirmed the operability of its IPv4
configuration, it SHOULD NOT respond to ARP Requests, and SHOULD NOT configuration, it SHOULD NOT respond to ARP Requests, and SHOULD NOT
broadcast ARP Requests containing its address within the sender broadcast ARP Requests containing its address within the sender
protocol address field (ar$spa). However, where the host has an protocol address field (ar$spa). However, where the host has an
operable routable non-private address on a MLN, it MAY send ARP operable routable non-private address on a MLN, it MAY send ARP
Requests using its address within the sender protocol address field Requests using its address within the sender protocol address field
(ar$spa) prior to confirming its IPv4 configuration, and MAY respond (ar$spa) prior to confirming its IPv4 configuration, and MAY respond
to ARP Requests. to ARP Requests.
Sending an ICMP Echo Request [RFC792] to the default gateway IPv4 Sending an ICMP Echo Request [RFC792] to the default gateway IPv4
address does not provide the same level of assurance since where the address does not provide the same level of assurance since this may
host has moved between two private networks, an ICMP Echo Request can require an ARP Request/Reply exchange. Where the host has moved
result in an ICMP Echo Response even when the default gateway has between two private networks, this could result in ARP cache
changed, as long as the IPv4 address remains the same. This can pollution.
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 Where a host moves from one private network to another, an ICMP Echo
with TTL > 1, then an ICMP Echo Response can be received from an off- Request can result in an ICMP Echo Response even when the default
link gateway. As a result, if the MAC address of the default gateway gateway has changed, as long as the IPv4 address remains the same.
is not checked, the host can mistakenly confirm attachment to a MLN, This can occur, for example, where a host moves from one home
potentially resulting in an address conflict. In addition, if the network using prefix 192.168/16 to another one. In addition, if the
ICMP Echo Request results in a broadcast ARP Request being sent with ping is sent with TTL > 1, then an ICMP Echo Response can be received
the host's IPv4 address in ar$spa, this can result in ARP cache from an off-link gateway. As a result, if the MAC address of the
pollution. As a result, sending an ICMP Echo Request SHOULD NOT be default gateway is not checked, the host can mistakenly confirm
used as a substitute for the DNAv4 procedure. attachment to a MLN, potentially resulting in an address conflict.
As a result, sending of an ICMP Echo Request SHOULD NOT be used as a
substitute for the DNAv4 procedure.
If the initial ARP Request does not elicit a response, the host waits If the initial ARP Request does not elicit a response, the host waits
for REACHABILITY_TIMEOUT. Where IPv4 address acquisition occurs in for REACHABILITY_TIMEOUT. Where IPv4 address acquisition occurs in
parallel, the host MAY retransmit; otherwise the host SHOULD move on parallel, the host MAY retransmit; otherwise the host SHOULD move on
to the IPv4 address acquisition phase. If a valid ARP Reply is to the IPv4 address acquisition phase. If a valid ARP Reply is
received, but cannot be matched against known networks, the host received, but cannot be matched against known networks, the host
assumes it does not have an operable IPv4 configuration. assumes it does not have an operable IPv4 configuration.
2.3. IPv4 Address Acquisition 2.3. IPv4 Address Acquisition
skipping to change at page 14, line 37 skipping to change at page 14, line 37
acquisition in parallel with one or more reachability tests. acquisition in parallel with one or more reachability tests.
In order to examine the tradeoffs in implementations that only test In order to examine the tradeoffs in implementations that only test
reachability to a single MLN, assume that a DHCPREQUEST requires reachability to a single MLN, assume that a DHCPREQUEST requires
DHCPREQUEST_TIME to determine if a host has remained on the same DHCPREQUEST_TIME to determine if a host has remained on the same
network, while a reachability test typically completes in REACH_TIME network, while a reachability test typically completes in REACH_TIME
and times out in REACHABILITY_TIMEOUT, after which a DHCPREQUEST is and times out in REACHABILITY_TIMEOUT, after which a DHCPREQUEST is
sent. sent.
If a hint that the host has remained on the same network cannot be If a hint that the host has remained on the same network cannot be
confirmed x fraction of the time, then it only worth considering if: confirmed x fraction of the time, then it is only worth considering
if:
DHCPREQUEST_TIME > (1 - x) * REACH_TIME + DHCPREQUEST_TIME > (1 - x) * REACH_TIME +
x * (REACHABILITY_TIMEOUT + DHCPREQUEST_TIME) x * (REACHABILITY_TIMEOUT + DHCPREQUEST_TIME)
x < DHCPREQUEST_TIME - REACH_TIME x < DHCPREQUEST_TIME - REACH_TIME
---------------------------------------------------- ----------------------------------------------------
REACHABILITY_TIMEOUT + DHCPREQUEST_TIME - REACH_TIME REACHABILITY_TIMEOUT + DHCPREQUEST_TIME - REACH_TIME
If we assume that DHCPREQUEST_TIME = 50 ms, REACH_TIME = 10 ms, and If we assume that DHCPREQUEST_TIME = 50 ms, REACH_TIME = 10 ms, and
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/