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

> From: "Bernard Aboba" <[email protected]>
>
> >   | I think the resolution of LL 58 re-introduces a normative
> >   | dependency on [DNAv4].
> >
> > Yes (that was always there), but ...
> >
> >   |    A "valid routable address" is a routable address which is =
either
> >   |    statically assigned or whose lease has not expired and that =
passes
> >   |    the reachability test described in section 2 of "Detection of =
Network
> >   |    Attachment (DNA) in IPv4" [DNAv4].
> >
> > does nothing to change that, it is still a normative reference.
>=20
> The proposal is to make this a definition in the terminology section, =
and
> remove all normative uses of the term "valid".   With the changes, the
> only use of the term in the document is to describe ways in which an
> address *might* be configured.

There are two things which may occur to initiate a change to or from =
using IPv4LL.

First are events internal to the host/stack. I think of these as =
"configuration" changes and they include manual configuration changes =
and re-configuration by the DHCP client as a result of lease change or =
expiry. These events are easily detected and their effects fairly easily =
predicted or established. I find the term "configuration" strongly =
suggests this type of change in my mind and this is why I do not like =
applying it for changes which do not involve explicit internal events.

Second are context changes which are external to the host/stack and =
include roaming to different networks or other changes to the network =
context such as router changes. External events are not so easy to =
detect and their effects may not be so easily established nor clear cut =
as discussion has shown.

In the case of external context changes we have been unable to comne up =
with a hard and fast algorithm to say when a routable address changes =
between "useful" and "useless" - indeed they are not even distinct =
states but fall on a continuum. The current draft (14) uses DNAv4 as a =
test to distinguish between "useful" and "useless", but discussion has =
shown that the DNAv4 test is not definitive (and therefore should not be =
normative). The best solution is make this clear in the text.

I find the use of "configured" to mean external context changes very =
confusing and I also recognise though that "valid" may lead to confusion =
(e.g. with "valid lease" in DHCP).

I propose rewording your latest text as below. I hope that in editing =
your text I have made this section clearer. I have removed most use of =
"configured" and all use of "valid". I have added a little to make clear =
that these are transitional cases only. I have introduced and defined =
the term "operable" and made plain that there is no easy rule to =
determine operability. There is no need to define "valid" or anything =
extra in the terminology section at all.

The revised section becomes:

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 routable address and an IPv4 Link-Local =
address
   configured on the same interface. When an operable routable address =
is
   available on an interface, the host SHOULD NOT also assign an IPv4
   Link-Local address on that interface. However, during transition (in
   either direction) between using routable and IPv4 Link-Local =
addresses
   both MAY be in use at once subject to these rules.

   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.

   The term "operable address" is used to mean an address which works
   effectively for communication in the current network context (see =
below).

   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 an existing address
      becomes operable.

   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.

   A useful guide is provided by the reachability test described in
   "Detection of Network Attachment (DNA) in IPv4" [DNAv4] which also
   provides further discussion of address assignment.

Philip