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

Folks,

I neglected to mention that the text of draft 12 differs from that which
was discussed previously between Ralph Droms and Phillip Nye in that
removes mention of Radius.

Bernard Aboba wrote:
 > I removed the mention of RADIUS, and also fixed the prefix to be
 > "169.254/16" instead of the /32 that was there.

Erik

Erik Guttman wrote:
> 
> 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]
> 


-- 
  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
    Erik Guttman   -   N1 Manageability   -   Sun Microsystems
       cell: +49 172 865 5497   -   time zone: CET (GMT+1)