Re: Document review blast

Alex,

I respond briefly.  We will pursue this in more detail.

Summary of my judgment call:

a) open an issue to add some constants
b) open an issue on timing only if there is broad WG support to do so
c) do not open an issue
d) open issues on
    - announcement attack prevention
    - clarifying the 'beginning of the algorithm'
    - algorithm restart after fail timer

e) aside from constants we should add for (a) and (d), I push back
    and ask for support from the WG before opening issues for these
    concerns at this late stage in the game.

I would ideally open issues for every point you make, but this is a lot
of paperwork and I'm busy - sorry!  If anyone disagrees with any of my
assessments below, please post a message to the list.

Elder, Alex wrote:
> 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.)

Revising IPv4 LL (the protocol and the document) in such a major way
is not an option at this point unless the current protocol or document
is terribly broken.

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

This has been changed with LL39.  All multiple interface issues have been
moved to section 3 which is essentially an enumeration of issues not a
definitive prescription for their solution.

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

I don't think this will be controversial.  I will open a new issue to
cover it.

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

Generally the 1-2 second range is needed due to the assumption that
there may be a 1 second latency on links we support.  For the initial
transmission, 0-PROBE_MIN seems reasonable to me.  Let's open an issue
to discuss this.

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

We have discussed this at length.  There are advantages to taking care
to prevent synchronized behavior and few disadvantages to using random
delays.  I do not believe we should reopen this issue.

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

Is 1 second between announcements enough?  If the link can have a 1
second round trip latency...

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

This section has been revised with LL37.

> - 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)

Does anyone else on the list believe we should reopen the timing
algorithm for discussion?   [Not as WG chair:  I say its too late.]

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

See section 3 and LL39.  If you support multiple interfaces and LL
on more than one interface address ambiguity problems exist, period.
It is up to the implementor of this protocol to decide how to handle
these problems.  We can only give advice.

> - 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?

No.  Please refer to the numerous issues related to the security
implications of coupling one interface's configuration to another.
This has been rejected.

> - 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?)

That was the idea, but this text has been changed by LL39.

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

This has been debated back and forth.  We have agreed that the most we
can agree on is a list of caveats for multiple interface interaction
with the IPv4 LL protocol.

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

Good point.  I will initiate an issue for this.  Please propose text.

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

Hmm.  Does anyone else feel this should be submitted as an issue?

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

OK.  Please propose clearer text and we can open an issue.

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

OK.  Please propose a reasonable restart delay for the algorithm.

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

This specification (once approved as an RFC) will be authoritative.

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

Links with a round trip latency of 1 second are supported (see section
1.3).

As long as this is the case, and such links can be bridged to, shorter
timeouts make it possible that the algorithm will fail.  Perhaps this
latency value is too high?  I have asked this question many times and
not gotten a reply.

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

This text is already straying very far into the 'advice' space.  We need
to get the standard specification completed.


> Editorial Feedback
> ------------------

These are minor issues, so I am asking for others on the list to
voice their support for them before generating issues.

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

We have spent a lot of time debating terminology.  1.3 makes it very
clear that when we discuss link we mean logical link (802) technology.

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

Does anyone else find this statement unclear?

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

Does anyone else find this statement unclear?

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

Does anyone else see a problem here?

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

OK - let's include this with (a).

> - 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)

You already suggested this above - and we'll take this up in (a) and
(d).

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

There is a lot of history in this.  We had to choose a number.  Stuart
did a careful assessment of the statistical consequences of this number.
This threshhold fulfills a qualitative purpose (it works well up to this
point) as well as the need to provide a reasonable bound.

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

Please submit text so we can compare the two options.

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

1.3 is the applicability section.  Does anyone else think that these
constants need explanation?

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

Does anyone else feel collision needs to be changed to conflict?

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

No longer a problem: See LL37.

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

No longer a problem: See LL37.

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

Does anyone else agree?

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

Does anyone else agree?



Best regards,

Erik