comments on draft-ietf-zeroconf-ipv4-linklocal-08.txt

Proposed revisions of draft-ietf-zeroncof-ipv4-linklocal-08.txt
after a detailed reread.

I do not expect these will be controversial.  Please express an
opinion on them if you have one.

--------------------------------------------------------------------

Editorial

1) <draft-ietf-ipv4-linklocal-08.txt>
should be the real draft number

2) Editorial refinement:
     section 1.4, subsection b:
     Names that are globally resolvable to routable addresses should
     be used within applications wherever they are available.  Names
     that are resolvable only on the local link ... MUST NOT be used
     in off-link communication.  This can be prevented by using
     Link-Local IPv4 addresses or names resolvable on the local
     link when a Link-Local IPv4 address is used as the source address
     of the packet.

The last sentence should be rewritten to

    IPv4 addresses and names which can only be resolved on the local
    link SHOULD NOT be forwarded in application layer protocol
    messages.  If they must be forwarded, they SHOULD only be sent
    when a Link-Local address is used as the source address.  This
    strong advice should hinder limited scope addresses and names
    from leaving the context in which they apply.

3) Section 1.8

Text was:
    Hosts that support multi-homing have additional considerations if
    they wish to use Link-Local IPv4 addresses on more than one
    interface at a time.  These are discussed in Section 3.

Should be rewritten as:
   Additional considerations apply to hosts that support more than
   one active interface where one or more of these interfaces support
   Link-Local IPv4 address configuration.   These considerations are
   discussed in Section 3.

4) Section 3.1

    This way, the correct interface could be selected, a safe procedure
    could be followed with respect to forwarding addresses and other
    parameters.

should read

    This way, the correct interface could be selected, and a safe
                                                       ^^^
    procedure could be followed with respect to forwarding addresses
    and other parameters.

=============================================================
Substantial

1) The abstract no longer reflects the purpose of the draft,
    poor English

says

It is therefore beneficial for a host to be able to depend on a
useful subset of IP network to always be functional, even when
no configuration is available, or the available configuration is
incorrect.

should say

It is therefore beneficial for a host to be able to depend on a
useful subset of IP networking functions even when no configuration
is available.

---------------------

2) Timing:

a) Note that in 1.3 "applicability" we state that
    This specification applies to all IEEE 802 Local Area Networks (LANS)
    ...that... have a round-trip latency of at most one second...

b) Section 2.2 says
    When ready to begin probing the host should wait for a random time
    interval selected uniformly in the range zero to one seconds, and
    should then send three probe packets, spaced uniformly, zero to one
    seconds apart.

c) I conclude:  If the applicability of this protocol includes
    networks for which a  1 second round-trip latency can exist, it is
    quite possible that all the probes will be answered by the host
    sending the probes will ignore the replies.

d) therefore, we need to amend section 2.2 to values which are greater
    than the roundtrip latency.   I suggest the following new text:

    When ready to begin probing the host should wait for a random time
    interval selected uniformly in the range zero to two seconds, and
    should then send three probe packets, spaced uniformly, 1 to 2
    seconds apart.

e) an alternative would be to modify section 1.1 applicability to lower
    the round trip latency we support.  In any case 2.2 intervals must be
    no shorter than the supported round trip latency.

f) based on the final delay we decide upon, we need to revise the values
    cited in section 2.3

    The time values specified above result in a delay of 8-10 seconds
    before a chosen IP address may be used.   ... a ten-second delay...

   and section 2.5

    ...(within 10 seconds for IEEE 802)...

   Given the time values I suggest above, we actually return to those
    values recommended in the previous version of the draft and these
   numbers are (fortuitously) accurate.

--------------

3)  Section 1.9  "Communication with Routable Addresses"

This change is important because the current text
   * does not make it clear that hosts should transition to use routable
     addresses as per 1.7.  This is not the place to reiterate that.
     Configuration of interfaces with  addresses of multiple scopes
     should not be mentioned as if it generally supported.

   * discussion of configuration of multiple addresses per interface is
     not the main topic of this section.  This is a distraction from
     the main point we need to make here.  This is especially confusing
     because the current text makes it seem as if this is the *reason*
     this issue must be discussed.  (This was true at one time when
     we considered that LL addresses would be supported at all times,
     so this is hold-over text that needs to be dropped).

The text currently reads:

    For some devices, engineering constraints may mean that it is only
    possible to implement a single address per interface, either
    Link-Local or routable, but not both at the same time.  For this
    reason the rules in Section 2.6 allow communication from a routable
    address to a Link-Local IPv4 destination on the same physical
    link and vice versa.

This text should read:

    There will be cases when devices with a configured Link-Local
    address will need to communicate with a device with a routable
    address configured on the same physical link, and vice versa.
    The rules in Section 2.6  allow this communication.

-----------------

Erik