Subject: [dhcwg] Proposed Resolution of DNA Issue 29: Review

From: Bernard Aboba <[email-masked]>
Date: Mon, 27 Jun 2005 08:35:06 -0700 (PDT)

The text of Issue 29 (submitted by Thomas Narten) is included below.
DNAv4 Issues are tracked at the following website:
http://www.drizzle.com/~aboba/DNA/

A version of the document with the changes applied is available here:
http://www.drizzle.com/~aboba/DNA/draft-ietf-dhc-dna-ipv4-13.txt

The proposed resolution is as follows:

Accept the grammatical corrections.

Change the abstract to the following:

"   The time required to detect movement between networks, and to obtain
   (or continue to use) an IPv4 configuration may be significant as a
   fraction of the total handover latency in moving between points of
   attachment.  This document synthesizes experience in the deployment
   of hosts supporting ARP, DHCP, and IPv4 Link-Local addresses to
   define a set of steps known as Detecting Network Attachment for IPv4
   (DNAv4), in order to decrease the handover latency in moving between
   points of attachment."

Change Section 1 to the following:

"   The time required to detect movement between networks and to obtain
   (or continue to use) an operable IPv4 configuration may be
   significant as a fraction of the total handover latency in moving
   between points of attachment.

   This document synthesizes experience in the deployment of hosts
   supporting ARP [RFC826], DHCP [RFC2131], and IPv4 Link-Local
   addresses [RFC3927] to define a set of steps known as Detecting
   Network Attachment for IPv4 (DNAv4).  DNAv4 optimizes the (common)
   case of reattachment to a network that one has been connected to
   previously by attemping to re-use a previous (but still valid)
   configuration, reducing the reattachment time to a few milliseconds
   on LANs.  Since this procedure is dependent on the ARP protocol, it
   is not suitable for use on media that do not support ARP [RFC826]."

In Section 1.2, change the definitions of "ar$sha" and "ar$spa" to the
following:

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

ar$spa
     ARP packet field: Sender Protocol Address [RFC826].  For IP Address
     Resolution this is the IPv4 address of the sender of the ARP
     packet."

In section 1.2 and elsewhere, change "MLAN" to "MLN":

Most Likely Network (MLN)
     The attached network heuristically determined by the host to be
     most likely, based on hints.

In Section 2.2, change the first paragraph to the following:

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

--------------------------------------------------------------
Issue 29: Review
Submitter name: Thomas Narten
Submitter email address: [email-masked]
Date first submitted: June 22, 2005
Reference:
Document: DNA-12
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

I just reviewed this document, and overall I think its fine. Just some
nits (below).

But, stepping back, I'm trying to put my finger on what problem this
document actually solves. It doesn't change anything in the DHC spec
(i think). So is it just advice to implementations to be smarter than
they have been so far?

Is it to specifically point out stuff that existing implementations
just haven't done? but should be?

Is the win specifically:

- don't invoke DHC everytime you reattach, better to skip that? (does
this phase in practice cause long time outs)? Seems to me that dhc
shouldn't take that long in practice.

- is it mostly to fix broken behavior related to LL addresses and
giving up on DHC too soon?

- is it clarifying DHC issues (and if so, does it "update" the DHC
spec?) My sense is it doesn't do this.

or something else?

Or maybe, by how much time (roughly) does this reduce the "config"
process? Does it reduce it from one second to a couple hundred
milliseconds?

When we started this effort, I had a clear sense that things were
broken and could be made better. In the IPv6 case, I think I still see
that (i.e., waiting for RAs takes time, one has DAD, etc.) But for
IPv4, I'm less clear.

If we can summarize this, it might be good to add a paragraph to the
introduction. I.e., why its a no brainer to implement the spec.

Thomas

> ar$spa
> ARP packet field: Source Protocol Address [RFC826]. For IP Address
> Resolution this is the IPv4 address of the sender of the ARP
> packet.

s/source/sender/ (that is the terminology used in 826)

DNAv4 is used (in defn.) prior to definition. Perhaps define/use in
Introduction, e.g., "this document defines DNAv4, ...

> Most Likely Attachment Network (MLAN)

could be better acronym...

> Operable address

better called "candidate DNA address"? (not clear it is actually
"operable") or "previously assigned address"? Want the name to be
clear that the address is only a candidate of some sort, until the DNA
tests have completed...

Maybe "previously valid address"?

> If the reachability test is successful, the host MAY continue to use
> an operable routable IPv4 address without having to re-acquire it.

MAY??? what is the point of this spec if this is only a MAY?

> stored, the host makes an an educated guess of which network it has

s/an an/an/
s/of which/as to which/ ?

> in order to to confirm that it is connected to network on which it

s/to to/to/
s/to network/to an network/

> routable IPv4 address, so that completing the

s/that//

> 2.3. IPv4 Address Acquisition
>
> If the host has an operable routable IPv4 address on the MLAN but the
> reachability test fails, the host SHOULD verify the configuration
> by

s/verify/attempt to revalidate/ ??

> entering the INIT-REBOOT state, and sending a DHCPREQUEST to the
> broadcast address as specified in [RFC2131] Section 4.4.2.

[Thomas Narten]

> The document does point out problems in existing implementations, such
> causing address collisions when moving between private networks.

Right. The advantages seem scattered throughout the document. What I
think would be good is to (in the introduction) have some sort of more
concrete explanation/motivation for why one should implement this.

How about changing paragraph two to something like:

This document synthesizes experience in the deployment of hosts
supporting ARP [RFC826], DHCP [RFC2131], and IPv4 Link-Local
addresses [RFC3927] to define a set of steps known as Detecting
Network Attachment (DNA). DNA optimizes the (common) case of
reattachment to a network that one has been connected to previously
by attemping to re-use a previous (but still valid) configuration
rather than go through the standard steps one invokes when
attaching to an network for the first time. Use of DNA can reduce
the reattachment time to a few milliseconds on common LANs. Since
this procedure is dependent on the ARP protocol, it is not suitable
for use on media that do not support ARP [RFC826].

> > > Most Likely Attachment Network (MLAN)
> >
> > could be better acronym...

> This is the term that we came up with after discussion on "most likely
> point of attachment" (MLPA). After deciding that an attachment point was
> an L2 concept, and that we would use the 802.221 definition of "link" the
> only term left to describe this was "network". Would MLN be better? MAN
> is already taken.

I can't help be read the acronym as M - "LAN", which it of course
isn't. I'd prefer MLN.

> > > Operable address
> >
> > better called "candidate DNA address"? (not clear it is actually
> > "operable") or "previously assigned address"? Want the name to be
> > clear that the address is only a candidate of some sort, until the DNA
> > tests have completed...

This is the term used in IPv4LL, and so we changed it for consistency.

> > Maybe "previously valid address"?
> >
> > > If the reachability test is successful, the host MAY continue to use
> > > an operable routable IPv4 address without having to re-acquire it.
> >
> > MAY??? what is the point of this spec if this is only a MAY?

> Would SHOULD be better? A MUST seems somewhat strong here.

SHOULD would be fine. This action is the crux of the spec, and it
seems weird for an optional spec to use MAY to highlight the main
action, IMO. If one doesn't want to do this step, why are they
implementing the spec at all...

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