Subject: WG ACTION: resolution of open isues LL53 LL63 LL70, changes to LL56 LL57

From: Erik Guttman <[email-masked]>
Date: Mon, 7 Jun 2004 12:27:15 +0200 (CEST)

Next Steps:

  Please review the propsed consensus calls below.  This is really your last
  chance to voice a position on the issues before we declare them closed.

  We will post an internet-draft including the changes.

  Once it appears I will initiate a one week last call for us to review
  the document to make sure that he decided changes have been made.  After
  that, we will make any last fixes required to make it consistent with our
  decisions.

  Once we have a completed draft, I will request the IESG advancement it
  to proposed standard.

Outcome of the last round of last calls:

  LL53  Improve constants text - fix various errors due to recent changes
  LL56  Clarify disputed text
  LL57  Add additional text to Section 9 clarify WATCH_WAIT applies to
        IEEE 802
  LL63  Accept choice 'D'
  LL70  Accept revised text

Details:

---------------------------------
LL53 Forward references requested

Change 1.3 from

   (a) the number of, and interval between, ARP probes,
       see NUM_PROBES, PROBE_MIN, PROBE_MAX defined in Section 2.2.1
           ^^^^^^^^^^
to

   (a) the number of, and interval between, ARP probes,
       see PROBE_NUM, PROBE_MIN, PROBE_MAX defined in Section 2.2.1

Section 9 must include WATCH_WAIT and omit PROBE_INTERVAL (which is not
needed, since this is now defined using PROBE_MIN and PROBE_MAX.)  I reviewed
the document (the text in the latest prerelease draft-ietf-zeroconf-ipv4-
linklocal-15.txt) to ensure that the text below is consistent.

   START_WAIT           1 second   (initial random delay)
   PROBE_MIN            1 second   (minimum delay till repeated probe)
   PROBE_MAX            2 seconds  (maximum delay till repeated probe)
   PROBE_NUM            3          (number of probe packets)
   ANNOUNCE_N           2          (number of announcement packets)
   ANNOUNCE_INTERVAL    2 seconds  (time between announcement packets)
   MAX_COLLISIONS      10          (max collisions before rate limiting)
   RATE_LIMIT_INTERVAL 60 seconds  (delay between successive attempts)
   DEFEND_INTERVAL     10 seconds  (after probes, wait for defense)
   WATCH_WAIT          10 seconds  (time to continue to defend your address,
                                    for IEEE 802 networks)

If we accept the following suggestion - constants throughout the document
must change.  Therefore, I suggest we reject:

  We now have 5 parameters for the probing process and there is clearly
  confusion over their meaning. I would like to see clearer naming:
  NUM_PROBES, PRE_PROBE_MAX, INTER_PROBE_MIN, INTER_PROBE_MAX, POST_PROBE_WAIT.

  The new text of 3.1(a) should name all 5 of the probing parameters thus:

      (a) the number and timing of ARP probes
          See NUM_PROBES, PRE_PROBE_MAX, INTER_PROBE_MIN, INTER_PROBE_MAX,
          POST_PROBE_WAIT defined in section 2.2.1

------------------------
LL56 Contradictory text?

Change:

"IPv4 addresses and names which can only be resolved on the local link
SHOULD NOT 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."

To:

"IPv4 addresses and names which can only be resolved on the local link
SHOULD NOT be forwarded beyond the local link.  IPv4 Link-Local addresses
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."

------------------------------------
LL57 Straightforward editorial fixes

Philip was concerned with the text in LL57.  I believe his concern is
satisfied by the fix in LL53, which modifies the definition of the
WATCH_WAIT constant in section 9.

   WATCH_WAIT          10 seconds  (time to continue to defend your address,
                                    for IEEE 802 networks)

---------------------------------
LL63 Text should be more explicit

Section 2.11, Replace

   A device that implements both IPv4 Link-Local and a DHCPv4 client
   should not alter  the behavior of the DHCPv4 client to accommodate
   IPv4 Link-Local  configuration. In particular configuration of an
   IPv4 Link-Local address,  whether or not a DHCP server is currently
   responding, is not sufficient  reason to unconfigure a valid DHCP
   lease, to stop the DHCP client from  attempting to acquire a new IP
   address, to change DHCP timeouts or to  change the behavior of the
   DHCP state machine in any other way.

   Several early implementations of IPv4 Link-Local have modified the
   DHCP  state machine in an attempt to make IPv4 Link-Local more
   reliable, and the  field experience we have gained from this has
   shown that it does not work  - reliability of DHCP service is
   significantly reduced.   If increased reliability of IPv4 Link-Local
   is desired, we recommend that the IPv4 Link-Local state machine track
   the DHCP client state machine and, in cases where it is not certain
   that the DHCP-assigned address is correct, the  IPv4 Link-Local state
   machine acquire an IPv4 Link-Local address without causing the DHCP
   state machine to relinquish its address.

With

   As documented in Appendix A, early implementations of IPv4
   Link-Local have modified the DHCP state machine.  Field experience
   shows that these modifications reduce the reliability of the DHCP
   service.

   A device that implements both IPv4 Link-Local and a DHCPv4 client
   should not alter the behavior of the DHCPv4 client to accommodate
   IPv4 Link-Local configuration. In particular configuration of an
   IPv4 Link-Local address, whether or not a DHCP server is currently
   responding, is not sufficient reason to unconfigure a valid DHCP
   lease, to stop the DHCP client from attempting to acquire a new IP
   address, to change DHCP timeouts or to change the behavior of the
   DHCP state machine in any other way.

   Further discussion of this issue is provided in [DNAv4]."

------------------------------------
LL70 DNAv4 normative or informative?

Was:
1.9.  When to configure a Link-Local IPv4 address

   Having addresses of multiple different scopes assigned to an
   interface, with no adequate way to determine in what circumstances
   each address should be used, leads to complexity for applications and
   confusion for users.  A host with an address on a link can
   communicate with all other devices on that link, whether those
   devices use Link-Local addresses, or routable addresses.  For these
   reasons, a host SHOULD NOT have both a valid routable address and a
   Link-Local IPv4 address configured on the same interface.

   A routable address is any address that is:

   * a unicast address (see Section 1.2)
   * not a loopback address
   * not contained within the 169.254/16 prefix reserved for Link-Local
      IPv4 addresses

   A "valid routable address" is a routable address that passes the
   reachability test described in section 2 of "Detection of Network
   Attachment (DNA) in IPv4" [DNAv4].

   The assignment and use of a Link-Local IPv4 address on an interface
   is based solely on the state of the interface, and is independent of
   any other protocols such as DHCP.  A host MUST NOT alter its behavior
   and use of other protocols such as DHCP because the host has assigned
   a Link-Local IPv4 address to an interface.

   When an interface has a valid routable address configured on an
   interface, the host SHOULD NOT also assign a Link-Local IPv4 address
   to that interface.

   If a host finds that an interface that was previous configured with a
   Link-Local IPv4 address is now configured with a valid routable
   address, the host MUST always use the routable address when
   initiating new communications, and MUST cease advertising the
   availability of the Link-Local IPv4 address through whatever
   mechanisms that address had been made known to others.  The host
   SHOULD continue to use the Link-Local IPv4 address for communications
   underway when the routable address was configured, and MAY continue
   to accept new communications addressed to the Link-Local IPv4
   address.  Ways in which a valid routable address might be configured
   for the interface include:

   * Manual configuration
   * Address assignment through DHCP
   * Roaming of the host to a network on which a routable address
      assigned to the interface is valid

   If a host finds that an interface that was previously configured with
   a valid routable address no longer has a valid routable address, the
   host MAY identify a usable Link-Local IPv4 address (as described in
   section 2) and assign that address to the interface.  Ways in which a
   valid routable address might no longer be assigned to an interface
   include:

   * Removal of the address from the interface through manual
      configuration
   * Expiration of the lease on the address assigned through DHCP
   * Roaming of the host to a new network on which the address is no
     longer valid.

   Further discussion of the issues in detection of transient failures
   and the use of DHCP in response to network attachment failure is
   provided in "Detection of Network Attachment (DNA) in IPv4". [DNAv4]

Becomes:

1.9.  When to configure an IPv4 Link-Local address

   Having addresses of multiple different scopes assigned to an
   interface, with no adequate way to determine in what circumstances
   each address should be used, leads to complexity for applications and
   confusion for users.  A host with an address on a link can communicate
   with all other devices on that link, whether those devices use Link-
   Local addresses, or routable addresses.  For these reasons, a host
   SHOULD NOT have both an operable routable address and an IPv4
   Link-Local address configured on the same interface. The term
   "operable address" is used to mean an address which works
   effectively for communication in the current network context
   (see below).  When a operable routable address is available
   on an interface, the host SHOULD NOT also assign an IPv4
   Link-Local address on that interface.  However, during the
   transition (in either direction) between using routable and IPv4
   Link-Local addresses both MAY be in use at once subject to these rules:

   1. The assignment of an IPv4 Link-Local address on an interface is
      based solely on the state of the interface, and is independent of
      any other protocols such as DHCP.  A host MUST NOT alter its
      behavior and use of other protocols such as DHCP because the host
      has assigned an IPv4 Link-Local address to an interface.

   2. If a host finds that an interface that was previously configured
      with an IPv4 Link-Local address now has an operable routable
      address available, the host MUST use the routable address when
      initiating new communications, and MUST cease advertising the
      availability of the IPv4 Link-Local address through whatever
      mechanisms that address had been made known to others.  The host
      SHOULD continue to use the IPv4 Link-Local address for
      communications already underway, and MAY continue to accept new
      communications addressed to the IPv4 Link-Local address. Ways in
      which an operable routable address might become
      available on an interface include:

         * Manual configuration
         * Address assignment through DHCP
         * Roaming of the host to a network on which a previously
           assigned address becomes operable.

   3. If a host finds that an interface no longer has an operable routable
      address available, the host MAY identify a usable IPv4 Link-Local
      address (as described in section 2) and assign that address to the
      interface. Ways in which an operable routable address might cease to
      be available on an interface include:

         * Removal of the address from the interface through manual
           configuration
         * Expiration of the lease on the address assigned through DHCP
         * Roaming of the host to a new network on which the address is no
           longer operable.

   The determination by the system of whether an address is "operable" is
   not clear cut and many changes in the system context (e.g.
   router changes) may affect the operability of an address. In
   particular roaming of a host from one network to another is likely -
   but not certain - to change the operability of a configured address but
   detecting such a move is not always trivial.

   "Detection of Network Attachment (DNA) in IPv4" [DNAv4]
   provides further discussion of address assignment and operability
   determination.

------------------------------
Erik Guttman
ZEROCONF WG Chair