[dhcwg] Proposed Resolution of DNA Issue 19: Review of DNA-07

[Bernard Aboba <[e-mail]>]

The text of DNA Issue 19: Review of DNA-07 is enclosed below.  The
proposed resolution is as follows:

In Section 2, delete:

"[c] Treatment of link-down indications. 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."

In Section 2.2, change [a]-[d] to the following:

[a] The host does not have a valid routable IPv4
address on the "most likely" point of attachment.
In this case, it is not possible to confirm that
the host has a valid routable IPv4 address, so
that the reachability test is unnecessary.

[b] The host does not have information on the default
gateway(s) for the "most likely" point of attachment.
In this case, it is not possible 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 on average 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.

These changes are included in DNA-08:
http://www.drizzle.com/~aboba/DNA/draft-ietf-dhc-dna-ipv4-08.txt

Issue Status is available at:
http://www.drizzle.com/~aboba/DNA/dnaissues.html

-----------------------------------------------------------------
Issue 19: Review of DNA-07
Submitter: Jim Busse
Submitter email address: [e-mail]
Date first submitted: June 5, 2004
Reference:
Document: DNAv4-07
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

The DNA sentence "On disconnection from a network, there is no
need to take action until the host is reconnected" does not reflect the
state of Windows communications stacks in numerous products. In fact,
action is required so applications' various function calls don't hang and
sometimes blue screen the client. As a test, take a win98 SE client, open
IE and go to a page that takes a long time to load. During the load,
disconnect the Ethernet cable, and hit the refresh button 8-10 times.
You'll BSOD.

Regarding the reachability section 2.2, it's unclear whether the items
a,b,c,d are "and'ed" or "or'ed" for truth. Or, it may take a and c for
truth, or b for truth, for example--it's just not clear. I did a truth
table based on the standard, and one of my engineers did a truth table
after reading the document, and both were different.

The other item regarding reachability: you of course have much more
experience than I, but we have found the case where gateways are
unreachable for one reason or another (sometimes for lengthy periods of
time), but the proxy server is reachable, and it looks to the user like a
gateway is there--who knows the difference? So for a client with fixed IP
configuration, when the gateway goes down, the reachability test will
fail, a link-local address will be assigned, and the next instance of the
browser won't be able to reach the proxy server. The gateway will come
back up,  but a DHCP address won't be assigned because the client started
with a fixed IP configuration but now has a link-local address assigned.
The link-local address isn't DHCP assigned, and Windows won't release
it.or renew it.  The only way we found to get Windows to dump the LL
address was to stop and restart the interface with the registry set to the
correct values for the restart. This of course trashes all pending
transactions and can be harmful to some applications. Like IE--you need to
close it and re-open it.

That was the purpose of my original question, and your response was
correct--just the fact that you can't reach it now doesn't mean you should
assign and use a new address. So the implementers of the standard will be
confused: just when *should* you assign and use a new address? (rhetorical
question).



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