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

From: Erik Guttman <[email-masked]>
Date: Fri, 01 Aug 2003 11:14:04 +0200

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

---

From: Erik Guttman <[email-masked]>
Date: Fri, 01 Aug 2003 14:25:26 +0200

Rereading my note I saw a couple errors, sorry.

> opinion on them if you have one.

should be the real draft *name*

it is quite possible for that all the probes will be answered, but the
host sending the probes will ignore the replies.

Erik

---

From: Mika Liljeberg <[email-masked]>
Date: 01 Aug 2003 18:34:59 +0300

> host sending the probes will ignore the replies.

Aagh, let's stop turning the knob and put the knob in the specification
instead. Here's IPv6 DAD for comparison [rfc2462]:

   "To check an address, a node sends DupAddrDetectTransmits Neighbor
   Solicitations, each separated by RetransTimer milliseconds. The
   solicitation's Target Address is set to the address being checked,
   the IP source is set to the unspecified address and the IP
   destination is set to the solicited-node multicast address of the
   target address.

   If the Neighbor Solicitation is the first message to be sent from an
   interface after interface (re)initialization, the node should delay
   sending the message by a random delay between 0 and
   MAX_RTR_SOLICITATION_DELAY as specified in [DISCOVERY].  This serves
   to alleviate congestion when many nodes start up on the link at the
   same time, such as after a power failure, and may help to avoid race
   conditions when more than one node is trying to solicit for the same
   address at the same time. In order to improve the robustness of the
   Duplicate Address Detection algorithm, an interface MUST receive and
   process datagrams sent to the all-nodes multicast address or
   solicited-node multicast address of the tentative address while
   delaying transmission of the initial Neighbor Solicitation."

Default values:
	DupAddrDetectTransmits 		1
	RetransTime			1 second
	MAX_RTR_SOLICITATION_DELAY	1 second

IPv6 DAD takes 1..2 seconds with default parameters. I see absolutely no
reason to reinvent the wheel for v4LL. Retransmissions only make sense
for reducing failure probability in case there is an address collission
(implies picking a new LL for the retransmit). I would allow up to 4
retries. If there is no address collision, retransmitting DAD is a waste
of time. The parameters can always be tuned for unusual environments.

10 seconds is way too slow.

	MikaL