Re: new issue: [LL36] Combine and rework section 1.7 and 2.11 to be clearer

Ralph's approach seems reasonable and I think improves the draft. However, I am concerned that as written it does not allow operation with stacks which only allow a single address per interface.

Philip

----- Original Message ----- 
From: "Ralph Droms" <[email protected]>
To: "Erik Guttman" <[email protected]>
Cc: <[email protected]>
Sent: Tuesday, December 16, 2003 5:00 PM
Subject: Re: new issue: [LL36] Combine and rework section 1.7 and 2.11 to be clearer


> In response to this issue, I suggest deleting subsections 1.7 and 2.11, and 
> inserting the following text as the last subsection of section 1 (in 
> particular, to come after subsection 1.9. "Communication with Routable 
> Addresses"):
> 
> 
> 1.x When to configure a Link-Local IPv4 address on an 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 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 in the 169..2.54/32 subnet 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 or RADIUS.  A host MUST NOT
>     alter its behavior and use of other protocols such as DHCP and
>     RADIUS 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 RADIUS or 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". 
> 
>