WG action: 1 week discussion of [LL36] Combine and rework section 1.7 and 2.11 to be clearer

Please respond to the following proposal in the next week.  Comments
should be sent to the [email protected] mailing list.  A determination
regarding this issue will be determined on Feb 2, 2004.

The proposal is based on the discussion on issue LL36.

A changed candidate version of the document is available for preview
at

http://www.drizzle.org/~aboba/ZEROCONF/draft-ietf-zeroconf-ipv4-linklocal-12.txt

Changes

(1) Remove section 1.7 Multiple Addresses per Interface

    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 this reason, a host that obtains, or is configured with, a
    routable address on an interface, SHOULD NOT attempt to configure a
    Link-Local IPv4 address on the same interface.

    Where a Link-Local IPv4 address has been configured on an interface,
    and a routable address is later configured on the same interface, 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.

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

(2) Remove section 2.11 Transition from Link-Local to Routable Address

    As discussed in Section 1.7, use of a routable address is preferred
    to assignment of a Link-Local IPv4 address. A Link-Local IPv4 address
    can be configured due to transient failures, such as incomplete link-
    layer authentication, spanning tree convergence issues, or because a
    DHCP server failed to respond to an initial query, or is inoperative
    for some time.

    Where a Link-Local IPv4 address is assigned due to a transient
    failure, experience has shown that five minutes (see Appendix A.2)
    may be too long an interval to wait prior to attempting to configure
    with DHCP.  This document does not specify a strategy for quickly
    recovering a routable address in situations where a Link-Local IPv4
    address is assigned due to a transient failure. In situations where
    many hosts are present on a single subnet, frequent attempts to
    contact the DHCP server could result in a heavy traffic load. Further
    discussion of this issue is provided in [DNAv4].

(3) Add a section after "Communication with Routable  Addresses"

1.x.  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 configure on the same interface.

    A routable address is any address that is:

    * a unicast address
    * 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]