Document review blast

The following are comments on the ZEROCONF Working group Internet
Draft document, named "draft-ietf-zeroconf-ipv4-linklocal-10.txt".

I recently corresponded directly with Erik Guttman, who suggested that
(after reviewing the latest draft and issues list and mail list archive)
I submit my comments and let them be hashed out by the group.  Some
of the following is also related to earlier correspondence I had
with Stuart Cheshire regarding address conflict detection.

I have broken my comments into three general groups:
	- General. Overall impressions
	- Technical. Suggestions/observations related to technical
details
	- Editorial. More alolng the lines of rewording suggestions,
etc.

Within the technical area, I have grouped my comments into four
subgroups:
	- Parameterization. I think the document would benefit from more
	  explicitly stating some parameters to the algorithms, even if
	  those parameter values are expected to never change
	- Probing intervals.  Yes, I dare to suggest changes to the
	  underlying protocol, despite the recent flurry of discussion
	  about "Aggressive Time-outs" (my suggestion is even more
        aggressive).
	- Multiple interfaces.
	- Other clarifications.

I don't expect to be able to participate very fully in this group, but
felt that my observations based on my recent work with the Link-Local
and address conflict detection stuff might be worth sharing.  I will
be happy to answer questions about the content of this message though.

							- Alex Elder
	
[email protected]

General
-------
- There is a huge amount of overlap between this document and the
  document "draft-cheshire-ipv4-acd.txt" which covers the more general
  problem of address conflict detection.  It would be nice if the two
  jobs (LL address selection and general conflict detection) could be
  more clearly separated, to avoid the redundancy.  The obvious problem
  with this redundancy is keeping both documents mutually consistent,
  and already details of the content of the two documents are diverging
in
  places where they should be the same.  (Example: ACD document
indicates
  specifically that the host can begin using a claimed IP address
*after*
  it sends out an announcement packet, while the LL document currently
  doesn't say this quite so specifically.)

- (Related to issues 30, 39.)  Generally, this document talks about
  support for multiple interfaces, but doesn't cover it very uniformly.
  As an example, In section 2.2.1, 4th paragraph, it's mentioned that
any
  ARP packet received which has a sender IP address matching the probe
  address indicates a conflict.  In fact, I think that should state
  that any such ARP packet received *on any of the host's interfaces*
  indicates a conflict.

Technical Feedback
------------------

a) Parameterization

- Section 2.2.1, last paragraph.  The value "10" for the number of
  collisions during the probe cycle is clearly arbitrary.  That's OK,
  but I suggest it be called out with an explicit parameter name rather
  than fixing it in stone in the text (even if in reality it is fixed
  in stone).

- Section 2.2.1, last paragraph.  Similarly, the "1 address probe
  attempt per minute" is another arbitrary selection, and there too I
  suggest this rate be defined as a named parameter, even if it ends
  up being a permanently fixed parameter.  (This one, more than the
  "10" value just mentioned, seems like it might worthy of scaling
  based on characteristics of the underlying medium someday.)

- Section 2.5, paragraph (b).  The value *ten seconds* for the
  period over which a previous ARP message should be considered "recent"
  is arbitrary.  As I have suggested for other things above, I think
  this should be defined by an explicit parameter rather than fixing it
  permanently in the text (even if its value is permanently fixed).

- All of these parameters, their values, and their meanings, should
  be explicitly listed in section 9, Constants.

b) Probing Intervals (related to issues 31, 37)

- Section 2.2.1, third paragraph. What is the purpose of delaying
  *at least* PROBE_MIN (= 1 second) *before* anything ever gets started?
  The initial delay should range from 0..<something>, not from
  <something>..<something greater>; the extra initial delay is just a
  waste of time.

- Section 2.2.1, third paragraph.  What is the benefit of having
  the delays between probes be random?  Isn't it sufficient for the
  initial delay to be random, followed by a fixed, as-small-as-possible
  (presumably PROBE_MIN) delay between probes?  I don't know that the
  subsequent random delays really improve anything with respect to
  simultaneous probes that an initial random delay wouldn't already
  mitigate.  So the suggestion is use a fixed minimum inter-probe delay
  rather than randomizing it.

- If the previous two suggestions were implemented, the range of time
  required for a successful claim of an unused address (using
PROBE_MIN=1
  and PROBE_MAX=2) could be cut about in half, changing from 4-8 seconds
  (+ 2 seconds between announcements) down to 3-4 seconds (+ 1 second
  between announcements).  (This would need to be reflected in the text
  in section 2.3.)

- Section 2.2.1, third paragraph.  I think the range of the random
  initial delay needs not to be dependent on the inter-probe delay.
  The purpose of the inter-probe delay (as I understand it) is to ensure
  at least one probe has a chance of not being lost as a result of a
known
  design constraint (which has to do with details of the 802.3 spanning
  tree protocol[?]).  The purpose of the initial randomness is to avoid
  a flood of simultaneous probes occurring in lock-step due to, e.g.,
  sudden power-on of a whole network link full of interfaces.  I suggest
  the initial delay be a parameter separate from the inter-probe delay
  (currently defined by PROBE_MIN and PROBE_MAX).  Whether it should be
  shorter or longer than PROBE_MIN or PROBE_MAX I can't answer at this
  point.

- Section 2.2.1, fourth paragraph.  If all inter-probe delays were
  PROBE_MIN (rather than the range PROBE_MIN to PROBE_MAX), I think
  the delay following the last probe and the first announcement can be
  reduced to PROBE_MIN as well.

So I guess my proposal would be something like:
	delay(random(0..INITIAL_DELAY=1 second))
	send_arp_probe(addr)           \___ repeat PROBE_COUNT=3 times
	delay(PROBE_DELAY=1 second)    /
	send_arp_annoucement(addr)     \___ repeat ANNOUNCE_COUNT=2
times
	delay(ANNOUNCE_DELAY=1 second) /    (but skip delay after the
last)

c) Multiple interfaces

- Section 2.2.1, fourth paragraph.  Do *all* interfaces on a host
  need to be monitored for ARP's indicating an address for *any/all*
  of the host's interfaces (and defend the other interface IP's when
  a conflict is seen)?  I think they do, to avoid address ambiguity.
  I.e., it shouldn't be acceptable for a host's eth1 to have the same
  LL address as a different interface reachable via that host's eth0.

- Perhaps related, should ARP probes, announcements, and defense
  announcements go out over *all* of a host's interfaces?  (I think
  so.)  Should defense packets go out only on the interface that
  received an ARP packet indicating a conflict (I think so); or on
  the interface whose LL IP conflicts (I think not); or on both, or
  on all interfaces?

- Section 2.5, first paragraph (related to issue 15). I don't understand
  why the probe case differs from the ongoing monitoring case with
  respect to the 'sender hardware address' field in a received ARP.
  While probing, an ARP containing a 'sender IP address' in conflict
with
  the probe address is considered a conflict irrespective of the sender
  hardware address.  But in the ongoing monitoring case only such ARP's
  for which the sender hardware address is not one of the host's own are
  considered indicative of conflict.  It seems to me they should both
  only "care" if the packet originates from a different host (i.e., the
  probe case should be just as specific as the ongoing monitoring case).
  Is this just to support of the idea of multiple interfaces on a host
  being handled independently (i.e., each having no knowledge of any
  other's address configuration state?)

- Section 2.5, first paragraph.  Again, I think the host probably
  needs to be monitoring *all* of its interfaces for conflicts indicated
  for *any* of its own Link-Local addresses.  So this section should
  state that "At any time, if a host receives an ARP packet (request
*or*
  reply) ***on any of its interfaces*** where the ..."

d) Other clarifications

- A situation could arise that is not currently addressed by the
  specification.  It is conceivable that a pathological rogue host
  only answers the ARP *announcements*, not the *probes*, in which
  case addresses could be claimed, then immediately (after a defense
  announcement) given up, restarting the process indefinitely, with
  no throttle action such as what exists for repeated conflicts during
  the probing phase.  Mitigating this probably requires a separate
  counter or timer that tracks how recently or how frequently *claimed*
  (not just probed) addresses are lost.

- Last paragraph of section 2.1.  When should an address be saved
  to persistent storage?  I believe it should occur only after an
  address has been successfully claimed.  The text is not so specific,
  allowing (for example) a newly selected but not yet probed address to
  be saved to persistent storage.  This difference may not matter much
  in the end, but my suggested approach could avoid some unnecessary
  saves of the information, and adds a bit of increased value to the
  address saved (i.e., not only is it an address that has been selected,
  but it's known to have been "good" at one time).

- Section 2.2.1, fourth paragraph.  It is not clear what constitutes
  "the beginning of the probing process".  I believe the probing process
  begins at the moment the initial random delay begins.  But as worded,
  it could be interpreted as, for example, beginning when the first
  probe packet is sent out.

- Section 2.2.1, fifth paragraph.  It is not clear from the
  specification at what point the failed address claim attempt counter
  gets reset to zero.  I believe it should be reset whenever an address
  gets claimed (i.e., at the point at which the first address
announcement
  gets sent).  If it isn't reset, then having "trouble" acquiring an
  address once will penalize all future attempts to acquire a new
address
  in the face of a post-claim collision.

- Section 2.2.1, last paragraph.  This paragraph indicates that
  "the host has successfully claimed the desired Link-Local IPv4
address"
  after PROBE_MAX after the last probe.  A separate draft standard
  (on address conflict detection) says more explicitly that the host
  can begin using the address once the host had sent out the first
  ARP announcement.  The part about when the host can begin using the
  address should be stated explicitly.  And the discrepancy between the
  two documents should be resolved (one way or another).

- Section 2.4, last paragraph.  This comment is really a set of
  questions, I guess rhetorical.  Why is the period between
announcements
  PROBE_MAX?  Why can't it be PROBE_MIN (is it because the maximum
  inter-probe delay is PROBE_MAX)?  Does this delay have anything to
  do with spanning tree protocol?  If not, does it have to be tied to
  PROBE_MAX or is that just an arbitrary way of reusing an existing
  parameter of the specification?  Why is this value *not* scaled by the
  shorter timeouts?  Perhaps the document could at least attempt to give
  some answers to these kinds of questions, maybe in an appendix.

- Section 2.5, paragraph (b).  It think it may be important to
  distinguish more precisely what the differences (and similarities) are
  between what happens when an interface using a LL address is shut down
  and reconfigured due to a repeated collision, and when an interface
  using a LL address is shut down to reconfigure it with a routable
  address as mentioned in section 1.7.  One difference I note is that in
  the LL->routable case the "host SHOULD continue to use the Link-Local
  IPv4 address for communications underway" while in the LL->LL case it
  "MUST immediately cease using this address."

Editorial Feedback
------------------

- The abstract, and subsequent sections repeatedly use the phrase
  "physical (or logical) link" without really describing why it is
spelled
  out this way until later.  Section 1.2 defines the phrase "on the same
  link" but never says anything about the "physical (or logical)" part.
  Suggest using something less awkward, such as "network link" until
  the more precise definition is provided.

- Abstract, second paragraph, as well as end of paragraph in section
  1.4 at the top of page 4.  The statement is made that "This document
  does not recommend that Link Local IPv4 addresses and routable
  addresses be configured simultaneously on the same interface."  Is it
  intentional to not go so far as "recommends not to" rather than "does
  not recommend?"  It's a subtle difference; maybe this phraseology is
  normal for this type of document.

- Section 1.3, last line of page 4.  Does "round-trip latency" have
  a well-defined meaning?  I know what I think is meant (i.e., twice the
  maximum time it takes for data to travel between a pair of interfaces
  on the medium), I just wondered whether "round-trip latency of at most
  one second" has the same sort of precision as "data rates of at least
  1 Mbps," for example.

- Section 1.3, top of page 5.  The sentence starting with "Link layer
  technologies..." is phrased in such a way that it seems to conflict
  the earlier statement that this specification only applies to certain
  technologies.  Suggest rewording something more like:
      "This specification could also apply to link-layer technologies
      that support ARP but operate at rates below 1 Mbps or latencies
      above one second, if different values are specified for one or
      more of the following parameters described in sections 2.2, 2.3,
      and 2.4:" ...

- Section 1.3, top of page 5.  Suggest mentioning the names of the
  parameters described here (e.g., PROBE_MIN and PROBE_MAX).  Also, some
  (most?) of these haven't been given formal names, and in those cases
  I recommend names get assigned.

- Section 1.3, top of page 5.  Other values that could be called out
  as parameters of the specification (these should probably be
considered
  technical feedback as well):
    - number of consecutive unsuccessful addresses probed before
      limiting the rate of subsequent address probes (currently 10)
    - Rate at which probes occur after that point (currently no
      more than one probe per 60 seconds)
    - Definition of "recent" with respect to defending an address.
      That is, the time period between receipt of ARP packets that
      indicate an address conflict, such that if the second arrives
      less than that time after the first the interface stops using
      its address, but greater than that time it continues using it.
      (See section 2.5(b).)  (currently 10 seconds)

- Last paragraph in section 1.3.  (Related to issue 22)  The specificity
  of the value "1300" here seems strange, at least in the way it gets
  presented.  What's seems to be happening is that an arbitrary
  threshold of 2% is being chosen as reasonable, in other words, getting
  an address the first try 98% of the time is acceptable.  Out of this
  comes the precise sounding number 1300 (i.e., 2% of a 65024 addresses
  in the IPv4 Link-Local range) as a point where network operators
  should consider partitioning their network. (In fact, they should have
  considered this long before then...) I don't have a suggested
  rewording for you, I'm just making note of the fact that it didn't
  read well.

- Section 1.7, second paragraph.  It may be possible to reword
  this so it's more clear you're talking about configuring BOTH a
routable
  AND a Link-Local address on the same interface at the same time.  As
it
  is it could be interpreted as maybe reconfiguring an interface that
has
  a routable address with a link local one instead (i.e., in its place).

- Section 2.2.1, third paragraph.  PROBE_MIN and PROBE_MAX are
  used here without any prior introduction.  Suggest introducing them
  earlier in the document (such as in section 1.3, when some parameters
  of the specification are first mentioned), or at least earlier in
  this section.

- Section 2.2.1, fourth paragraph.  The term "address collision" is
  first used here.  I know it's interchangeable with "address conflict"
  (which was first used in section 1.3).  However, I recommend a single
  term be consistently throughout the document.  I would recommend using
  "conflict," given the historical significance of the term "collision"
  in the Ethernet world.  I also would try to define the term in such
  a way that it includes the condition of finding an address being
  probed already in use by another interface, as well as an when an
  already-claimed address is found to be in use.  This way a common term
  would be meaningful in both sections of the document to mean, more or
  less, that an address you're concerned with is in use by another host.

- Section 2.3.  This whole section was obviously not updated
  at the time the PROBE_MIN and PROBE_MAX concepts were added earlier
  in the document.  The section should be reconsidered in its entirety
  so I won't really give much suggestion how to rewrite it.  But I will
  point out that the 8-10 seconds is now wrong given the assumed values
  of PROBE_MIN and PROBE_MAX and the number of probes now specified.

- Section 2.3.  It would be nice to have a more specific reference
  that explains (or refers to an explanation of) why 802.1d STP "often
  silently discard[s] all packets for several seconds."

- Section 2.5, first paragraph.  This section is only talking
  about a host's *link local* addresses, and should specify that.
  Specifically, near the middle it says "where the 'sender IP address'
  is the host's own IP address, but..." and it should read something
  more like "where the 'sender IP address' is one of the host's own IPv4
  Link-Local addresses, but...".

- Section 2.5, paragraph (b), second-to-last sentence.  Replace
  "as described above" with "using the process described in sections
  2.2 and 2.4, above" to be more clear about what is being referred to.