Re: WG ACTION: 1 week continued discussion [LL70] DNAv4 normative or informative?

I also support the principle that DNAv4 should become informative.  I gave
DNAv4 to a network apps developer, and he implemented the reachability test
described in DNAv4 differently from the way I interpreted and implemented
it.

As has been pointed out before, the assignment of IP addresses to interfaces
is primarily an operating systems issue.  Since most net apps are sockets
apps,  most net applications won't be able to assign an IPv4LL address.  So
I think Apple, Microsoft, and Sun (alphabetically) should come up with the
advisory wording.

The issue was discussed a year ago.  The thread was: "New issue: When to
configure a LL address."  Instead of flailing a dead horse, could the
wording be taken from that thread?  From Stuart (reproduced here without
permission):

"The one-and-only truly accurate way to determine whether operation A will
succeed is to try doing operation A, and see if it succeeds. (Those with
a formal computer science background will recognize this as a trivial
re-statement of the halting problem.)

Any attempt to determine whether operation A (e.g. connect to
www.amazon.com) will succeed by first performing some different operation
B (e.g. ping the DHCP server) is plagued by false positives and false
negatives.

False positive: Just because the DHCP server responds doesn't mean you
have a path all the way to www.amazon.com and back.

False negative: Just because the DHCP server doesn't respond doesn't mean
you *don't* have a path all the way to www.amazon.com and back.

Therefore, the best and simplest test to see whether a routable address
will work is to try it, and if it does not work, to try an alternative
instead."

Jim

----- Original Message ----- 
From: "Philip Nye" <[email protected]>
To: "Erik Guttman" <[email protected]>; <[email protected]>
Sent: Wednesday, May 26, 2004 3:42 AM
Subject: Re: WG ACTION: 1 week continued discussion [LL70] DNAv4 normative
or informative?


I support the principle that DNAv4 should become informative rather than
normative - espescially as recent discussions here have shown that the
reachability test of DNAv4 is a guide rather than a final and decisive test
of the useability of an address.

I do not support the resolution text as it stands for several reasons:

1. (editorial) an extra meaningless paragraph has appeared which is a
combination of two others:

>    When an interface has a routable address configured 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. (editorial) "When an interface has a routable address configured on an
interface" needs to be changed. The paragraph should read:

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

3. (substantive) as I have said in previous discussion, the term "valid"
carries meaning that is lost when it is simply dropped as here. I would
rather keep the term "valid" (or "working" or "useable") and leave its
definition fuzzy if necessary. I don't believe the proposed text adequately
resolves this issue.

    If a host finds that an interface that was previous[ly] configured
    with an IPv4 Link-Local address is now configured with a routable
    address, the host MUST use the routable address when initiating new
    communications...

I would interpret this text as a firm injunction preventing me from using
IPv4LL on any interface which has a routable address however wrong and
unuseable that address is. The only get out is weasle words about the
meaning of "configured".

Philip


----- Original Message ----- 
From: "Erik Guttman" <[email protected]>
To: <[email protected]>
Sent: Tuesday, May 25, 2004 4:56 PM
Subject: WG ACTION: 1 week continued discussion [LL70] DNAv4 normative or
informative?


> LL70
>
> This issue will remain open for comment until June 2, 2004.
> After that point, if no comments are received, the issue will be
> resolved by making DNAv4 normative and leaving the text as it currently
> stands.
>
> Bernard suggests the following resolution, which should allow DNAv4 to
> remain an informative reference.
>
> 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 a routable address and an IPv4
>    Link-Local address configured on the same interface.
>
>    The assignment and use 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.
>
>    When an interface has a routable address configured 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.
>
>    When an interface has a routable address configured on an interface,
>    the host SHOULD NOT also assign an IPv4 Link-Local address to that
>    interface.
>
>    If a host finds that an interface that was previous configured with
>    an IPv4 Link-Local address is now configured with a routable address,
>    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 underway when the routable
>    address was configured, and MAY continue to accept new communications
>    addressed to the IPv4 Link-Local address.  Ways in which a routable
>    address might be configured for the interface include:
>
>    * Manual configuration
>    * Address assignment through DHCP
>   * Roaming of the host to a network on which the host has a
>         valid routable address
>
>    If a host finds that a routable address is no longer assigned to an
>    interface, 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 a 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 address assignment and the detection of network
>    attachment is provided in [DNAv4].
>
> Erik Guttman
> ZEROCONF WG Chair
>
>