Subject: [dhcwg] Proposed Resolution to DNA Issue 6: SIRs review

From: Bernard Aboba <[email-masked]>
Date: Mon, 29 Sep 2003 07:19:19 -0700 (PDT)

The text of DNA Issue #6 is enclosed below.  The proposed fix is as
follows:

Change the abstract to:

" 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. This specification synthesizes experience
garnered over the years in the deployment of hosts supporting ARP,
DHCP and IPv4 Link-Local addresses, in order to optimize detection of
network attachment by mobile hosts."

Add the following text to Section 1:

" 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."

Add the following text to Section 2.2:

" Since the ARP Response is sent to the sender hardware address, the
contents of the sender protocol address field do not affect delivery
of the ARP Response. Since existing implementations do not create an
ARP cache entry for 0.0.0.0, using this as the sender protocol
address is harmless."

----------------------------------------------------------------------------------
Issue 6: SIRs Review
Submitter: Joel Halpern
Submitter email address: [email-masked]
Date first submitted: September 15, 2003
Reference:
http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg02357.html
Document: DNAv4-01
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

Over all the draft is well written and clear. It is on the right track,
but I believe it could use some clarifications. In particular, two aspects
seem to me to be in need of assistance.

Firstly, the problem statement seems to be missing a piece. While the
concern being addressed is likely obvious to those who work daily with
DHCP and DHCP related issues, it is not obvious to a reader from another
community. In particular, I found myself asking why I would use the
reachability validation step rather than simply going directly to
INIT-REBOOT state and sending a DHCPREQUEST to the broadcast address. I
suspect that the ARP reachability verification mechanism is expected to be
significantly faster and to place less load on other parts of the system.
But the document does not say that.

Secondly, in the description of the reachability verification mechanisms
it would be helpful if there were a sentence indicating why the use of the
0.0.0.0 source protocol address will be effective. (I checked the ARP RFC<
not having ARP code handy, and I understand that the ARP response
generation sends the response to the source hardware address. It would be
helpful to the reader if the document said this.) Related to this
clarification, it would probably be helpful to note (probably in an
appendix) both whether this behavior has been observed to cuase any
strange ARP cache entries and whether most observed implementations do
indeed respond properly to the message proposed here. (I know they should.
However, the difference between theory and practice...)

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