Subject: [dhcwg] Proposed Resolution of DNA Issue 8: DNA-02 Review

From: Bernard Aboba <[email-masked]>
Date: Tue, 21 Oct 2003 16:48:04 -0700 (PDT)

The text of DNA Issue 8 is enclosed below.  The proposed resolution is to
accept all proposed changes.

--------------------------------------------------------------------------
Issue 8: DNA-02 Review
Submitter: Henrik Levkowetz
Submitter email address: [email-masked]
Date first submitted: October 15, 2003
Reference:
http://www.levkowetz.com/ietf/rfcmarkup.cgi?url=../ietf/reviews/review-ietf-dhc-dna-ipv4-03.txt&comments=HENRIK
Document: DNAv4-02
Comment type: E
Priority: S
Section: Various
Rationale/Explanation of issue:

In Section 1.2. Terminology:
To ease the readibility for people not familiar with the ARP rfc
(RFC 826) it might be good to mention that names of the form
ar$xxx.. are names of fields in the Address Resolution ethernet
packet data, as described in the ARP RFC [RFC826]. Alternatively
give definitions for ar$tpa, ar$sha, ar$spa, ar$tha, something
like this:

"ar$sha ARP packet field: Source Hardware Address [RFC826]. The
hardware (MAC) address of the originator of an ARP packet.

ar$spa ARP packet field: Source Protocol Address [RFC826]. For IP
Address Resolution this is the IP Address of the sender
of the ARP packet. If the sender address is unknown,
this is set to 0.0.0.0.

ar$tha ARP packet field: Target Hardware Address [RFC826]. The
hardware (MAC) address of the target of an ARP packet,
or the broadcast address if the target hardware address is
unknown.

ar$tpa ARP packet field: Target Protocol Address [RFC826]. For IP
Address Resolution, the IP address for which one desires
to know the hardware address."

In Section 2.1. Reachability Test:

"[b] If the host does not have a valid routable IPv4 address
on the network. Since Link-Local IPv4 addresses are a
last resort, these addresses do not count as a valid
routable IPv4 address."

Link-Local addresses are excluded from valid routable IPv4
addresses by the definition in Section 1.2 "Terminology",
so I suggest rewriting as follows:

[b] If the host does not have a valid routable IPv4 address on the
network. (A Link-Local IPv4 address do not count as a valid
routable IPv4 address.)

In Section 2.2. Packet Format
"If the initial ARP Request does not elicit a Response, the host waits
200ms and then sends another ARP Request. If no ARP Response is
received in response to this second Request, the host 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 address acquisition phase."

A motivation for the choice of 200ms would be good, both for
immediate understanding, and for later evaluation of possible
alternative values.

In Section 2.3. IPv4 Address Acquisition:

"....the DHCPREQUEST needs to be forwarded to and from the DHCP
server by a DHCP Relay so that the response can be broadcast."
- I don't seem able to quite understand what is meant by this.
(Anyway, RFC2131 indicates clearly in 4.3.6, with no exceptions
given elsewhere, that in INIT-REBOOT the client sends messages
by broadcast.)

In Section 3. IANA Considerations:

"Guidelines for IANA considerations are specified in [RFC2434]. This
specification does not request the creation of any new parameter
registries, nor does it require any other IANA assignments."

Maybe skip the first sentence?

In Section 4. Security Considerations:

Detection of Network Attachment (DNA) is typically insecure, so that
it is inadvisable for a host to adjust its security based on which
network it believes it is attached to. For example, it would be
inappropriate for a host to disable its personal firewall based on
the believe that it had connected to a home network.

s/believe/belief/

In Section 5.1. Normative References:

RFCs 792 and 2132 does not seem to be referenced in the document text.
RFC 2434 is hardly normative as seen by the readers of the document.

In Appendix A:

"On IEEE 802 [IEEE802] wired networks, hints include link-layer
discovery traffic as well as information exchanged as part of IEEE
802.1X authentication [IEEE8021X]. Link-layer discovery traffic
includes Link Layer Discovery Protocol [IEEE8021AB] traffic as well
as network identification information passed in the EAP-
Request/Identity or within an EAP method exchange, as defined in EAP
[RFC2284]."

I suggest adding the abbreviation LLDP:
"... Link Layer Discovery Protocol (LLDP)"
so it's known when it's used in the next paragraph.

In Appendix A:

"Thus, associating to the same SSID is a necessary, but not
necessarily a sufficient condition, for remaining within the same
subnet. While a Station associating to the same SSID may not
necessarily remain within the same subnet; on the other hand, a
Station associating to a different SSID is likely to have changed
subnets."

Maybe rewrite for easier reading:
"Thus, associating to the same SSID is a necessary, but not
necessarily a sufficient condition, for remaining within the same
subnet: while a Station associating to the same SSID may not
necessarily remain within the same subnet, a Station associating
to a different SSID is likely to have changed subnets."

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