wrapping up the ipv4LL state change discussion

Folks,

The state diagram is a new can of worms for which there is no clear
support.  Let's drop further discussion of improving it so that it
can be included in the draft.

There has been the suggestion that we need to modify draft 10 in order
to clarify how transitions occur.  In particular we need to

  1. Make 100% clear that neither the DHCP state machine nor any other
     address configuration mechanism is changed or effected by the
     IPv4LL configuration mechanism.  Rather the choice of when and how
     to transition

  2. The discussion of the criteria determining when an routable IP
     address is available should be handled through (normative)
     citation of DNAv4.

  3. Explicit text is needed to make it clear that it is not forbidden
     to configure an IPv4LL address when one has other address
     configuration.  This is also not recommended.  Discussion of use
     of IPv4LL while a host has other address configuration for a link
     amounts to support of multihoming.  This topic and concerns it
     raises are discussed in section 3.

Is there agreement that these are the three points we need to address?
If so, let's draft text.

Ralph,

I hope I captured your concerns here.

Erik

Ralph Droms wrote:
> 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
> 
> 


-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  E r i k   G u t t m a n                        cell: +49 172 865 5497
  N1 Serviceability & Manageability         Time zone: CEST (GMT+1)
  Sun Microsystems

    Have you web-enabled viewing your calendar yet?  If not, please do!
                         http://namefinder.sfbay.sun.com/nfPermMail.jsp