[dhcwg] Proposed resolution to DNA issue 11: Reachability test

The DNA issues list is available at:
http://www.drizzle.com/~aboba/DNA/dnaissues.html

The text of DNA issue 11 is enclosed below.  The proposed resolution is as
follows:

Add the following definition to the terminology section (1.2):

"Valid address
     In this specification, the term "valid address" refers to either a
     staticly configured IPv4 address, or an address assigned via DHCPv4
     which has not been relinquished, and whose lease has not expired."

Change Section 2.1 to the following:

"2.1.  Reachability Test

   The purpose of the reachability test is to determine whether the host
   is connected to a network on which it has a valid routable IPv4
   address.

   The host skips the reachability test in the following circumstances:

   [a] If the host does not have good reason to believe that
       is connected to a network on which it has a valid
       routable IPv4 address.  Since confirming failure of
       the reachability test requires considerable latency,
       mistakes are costly.  In the absence of other
       evidence, a host SHOULD instead send a DHCPREQUEST
       from the INIT-REBOOT state, as described in [RFC2131],
       Section 3.2 and 4.3.2.

   [b] If the host believes that it is connected to a network
       on which it does not have a valid routable IPv4 address.
       A Link-Local IPv4 address does not count as a valid
       routable IPv4 address, nor does an IPv4 address assigned
       via DHCPv4, but whose lease has expired.  In this case,
       the host SHOULD send a DHCPDISCOVER from the INIT state,
       as described in [RFC2131] Section 4.4.

   [c] If the host does not have information on default
       gateway(s) on the network to which it believes it is
       connected.

   The reachability test is performed by attempting to verify
   reachability of default gateway(s) on a former point of attachment.
   The host may probe only the primary default gateway, or it may probe
   primary and secondary default gateways, in series or in parallel.
   However, the host MUST only configure default gateway(s) which pass
   the reachability test.

   If the 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).  In contrast to
   a DHCP exchange, which may be between a DHCP client and an offlink
   DHCP server, the reachability test occurs between a host and its next
   hop router."

---------------------------------------------------------------------------
Issue 11: Reachability test
Submitter: Mark Stapp
Submitter email address: mjs@cisco.com
Date first submitted: November 11, 2003
Reference:
http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg02702.html
Document: DNAv4-04
Comment type: T
Priority: S
Section: 2.1
Rationale/Explanation of issue:

I have some comments on draft-ietf-dhc-dna-ipv4-04.txt - on section 2.1 in
particular.

[2.1] Reachability Test

Doesn't this sentence in 2.1 sort of turn DHCP on its head?

"The purpose of the reachability test is to determine whether
the host is connected to a network on which it had previously
obtained a still valid routable IPv4 address."

As I understand it, it's only the DHCP server who knows
authoritatively whether the address binding that the client
remembers is still valid. Working around that authority in
circumstances where the server has failed, if the client could
actually determine that, would be one thing. But working around
that without the client's even attempting to confirm its binding
with the server is problematic.

This section states that a host may skip confirmation of its DHCP
address when it reconnects under some circumstances. The DHCP
INIT-REBOOT state is actually pretty important, and skipping it
could have some undesireable consequences. As 2.1 is worded now, a
host could have a week-old memory of an address it got on network
A, and could re-use it upon reconnecting to network A without
attempting INIT-REBOOT. That's a pretty dramatic change, if I've
read the text accurately, and I'm not comfortable with it.

Is the goal of 2.1 to assist clients who have marginal connections
- wireless clients whose associations are flapping, for example?
Maybe a time-based, stateful heuristic would be appropriate
here. For example, if the host believes that it has reconnected to
network A, and that it last communicated with the DHCP server on
network A within the last - one minute? five minutes? - then it
could proceed without INIT-REBOOT. If the host had

a) been off of network A for more than five minutes, or

b) been attached to some other network since it last
attached to network A

then it would go through INIT-REBOOT normally.

Or are there folks who think that the client should always do
INIT-REBOOT if it can? In that case, if there's a latency issue
for some types of client or some types of link, maybe we should
try to make a low-latency answer available from the server without
changing the client behavior at all.

[Ted Lemon]

Some people have made a lot of what I would consider a misreading of
RFC2131 - that INIT-REBOOT is optional. I believe it's optional because
some hosts may not have stable store, not because hosts that *do* have
stable store should ever skip INIT-REBOOT.

I think that in order to get good behavior in the case where we have
flapping going on on an 802.11 link, it's going to require a compromise on
one of three directions. The choices are (remember, this is just for
802.11):

- Try to do it right. This means that when we see a change, we look for a
new configuration but don't immediately throw out the old, in the sense
that we keep the old address configured alongside the new, and only kill
it off after a timeout has passed. I don't think that anybody is going to
implement this, and I'm not seriously proposing it - just wanted to
mention it.

- Compromise in the direction of switching quickly. This means that when
we detect a possible change in attachment, we assume that the old
connection is gone and never coming back. So we throw it away immediately
and switch. MacOS X does this now. My wife Andrea was unable to get her
email for quite a while this afternoon as a result, because she has a
Titanium, which has, shall we say, antenna issues. She kept losing her
access point in the middle of downloading her email, so she got the same
ten messages quite a few times before she gave up.

- Compromise in the direction of switching slowly. AFAIK nobody does this
now. What this means is that when we notice a network transition, we keep
it in mind, but don't try to reconfigure immediately - we wait 90 seconds,
long enough for any active TCP sessions to time out. If, during that
timeout period, the old network comes back, we continue using it. After
this period has passed, we give up and move to the new network.

This is a point solution for 802.11. I think that aggressive switching
probably works fine for ethernet and similar media, because a change in
media is usually a physical process. The solutions proposed in DNAv4
having to do with not trying to reconfigure until we actually detect a new
link, as opposed to the loss of the old link, make a lot of sense - this
means that if the switch is power cycled, we don't lose our address, but
if we're plugged into a different switch, we get a new address quickly.

[Mark Stapp] Couldn't quite tell from this whether you agreed with me that
the text in the draft was ... too general.

Like your wife, I've occasionally had 802.11 troubles, and I'd be
interested in providing some guidelines that would make it easier for an
802.11 client to deal with those troubles better. I don't read INIT-REBOOT
to mean 'throw out your configuration.' I've read it as 'try to confirm
that your configuration is still valid'; there are lots of ways of
optimizing the confirmation process. The dna draft proposes optimizing it
by avoiding it - skipping the confirmation message based on some
heuristic. The heuristic that's in the text isn't restricted to 802.11
clients, and isn't time-based or damped. The draft also doesn't discuss
interactions between L2 (which notices that the link has gone down and
been reconnected), the IP stack, and the DHCP client, and I agree with you
that users are most likely to notice a transient link problem if it takes
down their TCP connections.

I'd like to distinguish 'reconfiguration' from 'confirmation'. I agree
that helping 802.11 clients avoid unnecessary reconfiguration is
desirable, and I'd support text that made specific recommendations for
those clients. But the -04 draft loses the benefits of confirmation in too
many situations.

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg