Re: new issue: LL34 Better transition to routable from v4LL using DHCP

Seems to me the underlying issue is the interaction between v4LL and any
"working routable address" (a routable address that can be used for off-link
communication).  That is, I don't think it matters where the routable
address comes from - whether it be DHCP, manual configuration, or some other
mechanism - rather, the issue is how to get the interface to a state in
which it can use a v4LL address when no working routable address is available.

The way in which I would describe how a device uses v4LL would be to use the
state of the interface itself as the basis for invoking v4LL.  If an
interface does not have a working routable address, the device invokes v4LL
for that interface.  When the interface does have a working routable
address, v4LL is not used.

The issue of when to use v4LL is indirectly addressed in section 1.7 and
more directly in 2.11.  I suggest combining 1.7 and 2.11 into a single
section that:

* states the conditions under which v4LL is used (paraphrasing what I wrote
   in the previous paragraph)
   - based on state of interface
   - defines "working routable address"
   - v4LL used when no working routable address is available
* gives pointers to other documents, such as draft-ietf-dhc-dns-ipv4-01.txt,
   that define how to determine if an interface has a working routable address
* points out the it is an implementation detail for the protocol software to
   monitor the state of the interface and invoke v4LL as appropriate
* emphasizes that v4Ll has no effect on the use of other configuration
   mechanism

- Ralph

At 11:14 AM 9/11/2003 +0200, Erik Guttman wrote:
>Description of Issue: Better transition to routable from v4LL using DHCP
>Submitter Name  Bernard Aboba
>Submitter Email Address  [email protected]
>Date first submitted  11 Sep 03
>Reference
>Comment Type  Technical
>Priority  S (must change)
>Section  2.11 (new section)
>Rationale/Explanation of issue:
>
>(a)  We need to ensure an orderly method for recovering a routable
>      address given LLv4 addressing.  Much of the time an LLv4 address
>      is allocated inappropriately,  and so it's important to be able
>      to obtain a routable address via DHCP if one is available.  The
>      current LLv4 spec doesn't address this, and the current default
>      retry interval of 5 minutes is way too long.
>
>(b) Interactions of DHCP with LLv4. The LLv4 specification seems to
>     imply that an LLv4 address should be allocated when a DHCPREQUEST
>     or DHCPDISCOVER does not obtain an answer.  Existing implementations
>     show that this behavior is problematic since the lack of response is
>     most likely a temporary phenomena or the result of a bug of some
>     kind rather than the lack of a DHCP server on the link.
>
>     5 minutes is too long. I'd suggest 1 minute or even less (I've
>     seen a Linux implementation which retries every 30 seconds with
>     jitter and that works a lot better).
>
>
>Lengthy description of problem:
>
>Requested change:
>
>Create a new section:
>2.11  Repeatedly Attempt to Obtain A Routable Address
>
>   As per Section 1.7, use a routable address is preferred to use of
>   a link-local address.  In many cases, a link-local address is
>   configured because a DHCP server failed to respond to an initial
>   query, or is inoperative for some time.  Experience has shown that
>   five minutes (see Appendix A.2 for example) was too long an
>   interval to wait and try to configure with DHCP.
>
>   A host which has been configured with an IPv4 link-local address
>   SHOULD periodically attempt to obtain an IPv4 address via DHCP.
>   The recommended policy is to attempt to configure using DHCP after
>   waiting for RECONF_INTERVAL, plus a random number of seconds,
>   uniformly distributed, between zero to RECONF_JITTER seconds.
>
>Modify:
>9.  Constants
>
>Add:
>
>    RECONF_INTERVAL      25 seconds
>    RECONF_JITTER        10 seconds