Subject: [dhcwg] Proposed Resolution of DNA Issue 23: AD Review

From: Bernard Aboba <[email-masked]>
Date: Fri, 25 Mar 2005 08:24:09 -0800 (PST)

The DNA Issues List is available at:
http://www.drizzle.com/~aboba/DNA/

The text of Issue 23 is enclosed below.  A version of the document with
the changes applied is found at:
http://www.drizzle.com/~aboba/DNA/draft-ietf-dhc-dna-ipv4-10.txt

The proposed resolution is as follows:

Change the Abstract to the following:

Abstract

   The time required to detect movement (or lack of movement) between
   subnets, and to obtain (or continue to use) a valid IPv4
   configuration may be significant as a fraction of the total delay in
   moving between points of attachment.  This document specifies a
   procedure for optimizing the detection of network attachment and IP
   configuration in order to decrease the delay in moving between points
   of attachment.

Change the Section 1 to the following:

"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 IPv4 Link-Local
   addresses [IPv4LL], specifying a procedure for optimizing detection
   of network attachment and IPv4 configuration.  Since this procedure
   is dependent on the ARP protocol, it is not suitable for use on media
   that do not support ARP [RFC826]."

Change Section 2 to the following:

"2.  Overview

   DNAv4 consists of three phases: determination of the Most Likely
   Point of Attachment (MLPA), reachability testing, and IPv4 address
   acquisition.

   On connecting to a new point of attachment, the host responds to
   "Link Up" indications from the link layer by carrying out the DNAv4
   procedure.  As noted in Appendix A, hints about the point of
   attachment may be available from the link and Internet layers.  Based
   on these hints, the host determines the "Most Likely Point of
   Attachment" (MLPA) and determines whether it has a valid
   configuration associated with it.

   If the host believes that it has attached to a network on which it
   has a valid configuration, then it performs a reachability test in
   order to confirm that configuration.  In contrast to a DHCP exchange,
   which may be between a DHCP client and an off-link DHCP server, the
   reachability test is designed to verify bi-directional connectivity
   to the default gateway(s) on the MLPA.

   If the reachability test is successful, the host MAY continue to use
   a valid routable IPv4 address without having to re-acquire it.  This
   reduces roaming latency by allowing the host to bypass DHCP as well
   as subsequent Duplicate Address Detection (DAD).  If the host
   believes that it has attached to a network on which it has no valid
   configuration, or if the reachability test fails, then the host
   attempts to obtain an IPv4 configuration using DHCP.

   Since DNAv4 represents a performance optimization, it is important to
   avoid compromising robustness.  In some circumstances, DNAv4 may
   result in a host successfully verifying an existing IP configuration
   where attempting to obtain configuration via DHCP would fail (such as
   when the DHCP server is down).

   While the performance of DNAv4 is dependent on the reliability of the
   hints provided to the client, the host will ultimately determine the
   correct IPv4 configuration even in the presence of misleading hints.
   Where the host mistakenly concludes that it has attached to a network
   on which it has a valid configuration a timeout will occur, providing
   poorer performance than would be experienced by initially attempting
   to obtain IP configuration using DHCPv4.  However, after timing out,
   the host will obtain its configuration using DHCPv4, so that the
   correct configuration will eventually be obtained.

   To improve robustness, this document suggests that hosts behave
   conservatively with respect to assignment of IPv4 Link-Local address,
   configuring them only in situations in which they can do no harm.
   Experience has shown that IPv4 Link-Local addresses are often
   assigned inappropriately, and that inappropriate assignment can
   compromise both performance and connectivity.

   DNAv4 does not increase the likelihood of an address conflict.  The
   DNAv4 procedure is only carried out when the host has a valid address
   on the MLPA, implying that duplicate address detection has previously
   been completed.

   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.  As a
   result, until a host has verified the validity of its IPv4
   configuration, it SHOULD NOT respond to ARP requests.  In addition,
   prior to confirming its IP configuration, a host with a private
   address SHOULD NOT send ARP requests containing its address within
   the sender protocol address field (ar$spa);  instead it SHOULD use
   the unspecified address, as described in Section 2.2.1.  However,
   where the host has a valid routable non-private address on the MLPA,
   it MAY send ARP requests using its address within the sender protocol
   address field (ar$spa) prior to validating its IPv4 configuration."

Change Section 2.2 to the following:

"2.2.  Reachability Test

   If the host has a valid routable IPv4 address on the MLPA, a host
   conforming to this specification SHOULD perform a reachability test,
   in order to to confirm that it is connected to network on which it
   has a valid routable IPv4 address.  If the reachability test is not
   successful, the host proceeds to the IPv4 address acquisition phase,
   described in Section 2.3.

   The host skips the reachability test and proceeds to the IPv4 address
   acquisition phase if any of the following conditions are true:

   [a] The host does not have a valid routable IPv4
       address on the MLPA.  In this case, the reachability
       test cannot confirm that the host has a valid
       routable IPv4 address, so that completing the
       reachability test would serve no purpose.

   [b] The host does not have information on the default
       gateway(s) on the MLPA.  In this case, insufficient
       information is available to carry out the reachability
       test.

   [c] 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.  Where reliable hints are
       unavailable, this will typically complete more
       quickly than the reachability test.

   [d] If secure detection of network attachment is required.
       The reachability test utilizes ARP which is insecure,
       whereas DHCP can be secured via DHCP authentication,
       described in [RFC3118].  See Section 5 for details.

   The host MAY probe only the primary default gateway, or it MAY probe
   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.

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 other than a private
   address [RFC1918] 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 enables the host to confirm reachability even where
   it has moved between two private networks.  In this case the IPv4
   address of the default gateway could remain the same, while the MAC
   address would change, so that both addresses need to be checked.

   Sending an ICMP Echo Request [RFC792] to the default gateway IPv4
   address does not provide the same level of assurance since this
   requires an ARP Request/Response to be sent first.  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, then the host could mistakenly
   conclude that it remained on the same network, when in fact it had
   moved, 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
   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 IPv4 address acquisition phase."

-------------------------------------------------------------------------------------------------
Issue 23: AD Review
Submitter name: Margaret Wasserman
Submitter email address: [email-masked]
Date first submitted: March 21, 2005
Reference:
http://www1.ietf.org/mail-archive/web/dhcwg/current/msg04751.html
Document: DNA-09
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:
I have two questions about draft-ietf-dhc-dna-ipv4-09.txt that I would
like to discuss before I send this document to IETF LC.

(1) Could you explain why sending an ARP request to the default gateway(s)
of the MLPA (as described in section 2.2) is a better mechanism to confirm
what IPv4 configuration parameters should be used than re-initiating
DHCPv4 and/or attempting to renew the DHCPv4 lease (as described in
section 2.3)?

The only text in the document that might explain this seems to be:

   In contrast to a DHCP exchange, which may be between a DHCP client
   and an off-link DHCP server, the reachability test is designed to
   verify bi-directional connectivity to the default gateway(s) on the
   MLPA.

But, I'm not sure why this is better than using DHCP and/or how this
compensates for the possibility that the mechanisms described in this
document may result in a two step process: an ARP exchange (with a 200ms
timeout) followed by a DHCP exchange. Has there been some analysis and/or
empirical testing that shows that this mechanism produces superior
results?

(2) Is it assumed that the host would not send any non-DNA-related IPv4
traffic using its presumed address on the MPLA during the reachability
test and address acquisition phases? If so, would it make sense to state
that restriction here? Do you expect that packets would be queued until
the address status is resolved? Or that upper layers would receive errors
consistent with an interface that has not addresses configured?

[Bernard Aboba]

DNA is an optimization technique. Where hints can "reliably determine"
that the host has remained on the same subnet, an ARP Request/Response
exchange with the default gateway can be completed more quickly than a
DHCPv4 exchange with a DHCPv4 server that might be located off of the
local network.

Note that if the host has in fact moved to a different subnet, then DNA
can actually take longer than DHCPv4, since DNA will incur a timeout when
the default gateway does not answer the ARP Request. So the reliability of
the hints is in practice quite important, as discussed in Appendix A.1.

Appendix A.1 analyzes the conditions under which DNA will produce better
results. Schemes similar to DNA have been shipping for several years now,
and where the host changes subnets infrequently, the benefits are
substantial (e.g. savings of 20 - 100 ms).

    (2) Is it assumed that the host would not send any non-DNA-related
IPv4 traffic using its presumed address on the MPLA during the
reachability test and address acquisition phases? If so, would it make
sense to state that restriction here?

There is an assumption that the host would not send/receive ARP traffic in
some circumstances.  These restrictions result from a desire to prevent
address conflicts.  However, there are no restrictions on
sending/receiving traffic in the current document.

    Do you expect that packets would be queued until the address status is
resolved? Or that upper layers would receive errors consistent with an
interface that has not addresses configured?

[BA] I don't believe it is necessary to queue packets pending completion
of DNA unless the ARP cache entry has expired and the prohibition on
ARP traffic prevents it from being renewed.

[David Hankins]

> I don't think this assumption is required.  If the lease is still valid,
> sending packets prior to completion of DNA cannot result in an address
> conflict, and MAC learning needs to occur anyway.

I think it can result in an address conflict, in the case where a client
moves between two networks who both use the same ipv4 default router
(example: RFC1918 space), and for some reason have the same MAC address
(example: RFC2338 VRRP using the same VRID).

DNA would be fooled into using its previously bound ipv4 address, which
may not in fact belong to it.  Damage which may be considered more
substantial than the benefits of avoiding a ~100ms delay.

But that combination of examples is not a very common configuration in
practice.

What you meant to say was that DNA does not cause any new forms of
address conflict which are not done already by hosts not implementing
DNA or similar.

The fact that the DNA client does something, anything, to verify its
address, should be considered a substantial improvement.

I suggest the client should not respond to ARP for its address, along with
the already present "SHOULD NOT send ICMP echo requests", until DNA
completes is a reasonable attempt to mitigate all forms of address
conflict damage.

In the case where a client has not moved networks, it probably also has
a fresh ARP cache entry on its router and peers it has spoken to recently,
and is unlikely to start a new conversation within ~100ms anyway...so this
is probably reasonable, and still gives DNA a benefit where it is most
desired?

It may also be that a client implementing DNA could compare the source
ethernet mac address against the contents of arp$spa to detect RFC2338
and similar conditions without the need for manual configuration, but
I'm not sure on that point.

[Bernard Aboba]

>I think it can result in an address conflict, in the case where a client
>moves between two networks who both use the same ipv4 default router
>(example: RFC1918 space), and for some reason have the same MAC address
>(example: RFC2338 VRRP using the same VRID).

Use of VRRP/HSRP to protect against failure of the default gateway does
not cause a problem. The bi-direction reachability test requires that both
the IP Address and MAC address match, and so the DNA client will think it
is on the same network (which it is). The only situation which would cause
a problem is if routers with RFC 1918 addresses had duplicate MAC
addresses. This is very uncommon.

>DNA would be fooled into using its previously bound ipv4 address, which
>may not in fact belong to it. Damage which may be considered more
>substantial than the benefits of avoiding a ~100ms delay.

DNA checks both the IP address and the MAC address of the default gateway.
So reuse of an RFC 1918 address is not a problem unless the MAC address is
also reused.

>What you meant to say was that DNA does not cause any new forms of
>address conflict which are not done already by hosts not implementing
>DNA or similar.

Correct.

>The fact that the DNA client does something, anything, to verify its
>address, should be considered a substantial improvement.

DNA clients don't verify their addresses; they verify that they remain on
a network in which they already have a valid address. That is, DNA is only
carried out on an address which has a valid lease and which has completed
duplicate address detection.

>If I had been paying attention when this WG item was discussed, I think
>I would have suggested language to at least suggest the client should
>not respond to ARP for its address, along with the already present
>"SHOULD NOT send ICMP echo requests", until DNA completes is a reasonable
>attempt to mitigate all forms of address conflict damage.

The case to worry about is movement between RFC 1918 networks. Until the
client gets a reply from the default router, it does not know if it is on
the same network or not. But in the case where the client has an RFC 1918
address, it also doesn't know whether its address is valid or not. I agree
that where the host has an RFC 1918 address, it should probably not answer
an ARP request until it has completed DNA. However, where the host has a
valid routable address, I don't think that the host needs to wait, because
duplicate address detection has previously been completed.

>In the case where a client has not moved networks, it probably also has
>a fresh ARP cache entry on its router and peers it has spoken to
>recently, and is unlikely to start a new conversation within ~100ms
>anyway...so  this is probably reasonable, and still gives DNA a benefit
>where it is most desired?

I think it is reasonable for the RFC 1918 case. I am not clear that it is
needed where the client already has a valid routable address. However, it
does seem like a reasonable precaution.

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg