Re: [dhcwg] WG consensus action: ACCEPT LL34 better transition to routable from v4LL using DHCP

Nice state machine, although it does not address the case where it is
uncertain whether a configured address is not working or not. In this
case a node must be able to configure a LL address, advertise it, and
allow applications to fall back on it. There are two very common ad-hoc
cases where this can happen: 1) manually configured address in an
invalid context, and 2) valid DHCP lease in an invalid context.

	MikaL

On Wed, 2003-10-01 at 11:34, Erik Guttman wrote:
> Mika Liljeberg wrote:
> > On Tue, 2003-09-30 at 20:11, Erik Guttman wrote:
> > 
> >>I do agree with you.  The DHCP client should not be broken or effected
> >>by IPv4LL.  The host stack which uses both will of course be more
> >>complex than one which does not.
> > 
> > 
> > Are you saying it is ok to run the DHCP and v4LL state machines
> > independently of each other? I just want to be absolutely clear on this.
> 
> The DHCP client state machine is not effected by IPv4LL state machine.
> The IPv4LL state machine *is* effected by the DHCP client state machine.
> 
> Note that according to section 1.7:
> 
>     Where a Link-Local IPv4 address has been configured on an interface,
>     and a routable address is later configured on the same interface, 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.
> 
> This means that the DHCP state machine has succeeded in configuring
> an interface, it has implications for the IPv4 link-local interface.
> 
> We do not have a diagram of a state machine for IPv4LL, but perhaps
> that would be very useful.  I think it would look something like
> this:
> 
>       Interface is active and has no <---------------------+
>       IPv4 address configured                              |
>               |                                            |
>               v    interface has IPv4 addr configured?     |
>       +-->  INIT ---------------------------------------> EXIT
>       |       | 2.2          1.7                         ^  ^
>       |       v    <-------------------+                 |  |
>       |     SELECT <---+               |                 |  |
>       |       | 2.1    | ARP with      |                 |  |
>       |       v        | claimed       |                 |  |
>       |     CLAIM      | address     ADAGIO              |  |
>       |       ^ | 2.2.1| received      ^                 |  |
>       | 2.2.1 | v    --+               |2.2.1            |  |
>       |   CLAIM-WAIT ------------------+                 |  |
>       |       | 2.2.1 -----------------------------------+  |
>   2.5 |       v        interface has IPv4 addr configured?  | 
> 
>     DOUBT  ANNOUNCE          1.7                            | 
> 
>       ^|      | 2.4                                         |
>       |+->      v      interface has IPv4 addr configured?  |
>       +-- CONFIGURED ------------------------------> DEPRECATED
>       2.5  ^     | 2.5       1.7
> conflict! |     |
>            +-----+
>             defend
> 
>    State       Behavior
>    ==========  =============================================
>    INIT        Host has no configured IPv4 address on an
>                interface.  INIT waits before entering SELECT
>                state.  If INIT detects it has been configured
>                during this time, INIT goes to EXIT state.  See
>                Section 2.2.
> 
>    SELECT      Select a suitable address.  See Section 2.1.  The
>                only possible transition is to CLAIM state.
> 
>                A special case of SELECT is where the host has
>                woken up and previously had a link-local address
>                configured.  In this case, the previously configured
>                is selected.  See Section 2.2.
> 
>    CLAIM       Send a probe as per Section 2.2.
> 
>    CLAIM-WAIT  Wait for any ARP messages with the claimed
>                address originating from a different sender.
> 
>                If interface is configured during this wait
>                period enter EXIT state, do not configure an
>                IPv4 LL address.  See Section 1.7.
> 
>                If an ARP message indicates that the selected
>                address is in use, and this is the first through
>                nineth retry, enter SELECT state.  If this is
>                the tenth or more retry, enter ADAGIO state.
>                See Section 2.2.1.
> 
>                If no ARP message is detected as the result of
>                the probe after the wait duration ends, and this
>                is the first or second try, return to CLAIM state.
>                If this is the third try, enter the CONFIGURED
>                state.  See Section 2.2.1.
> 
>    ADDAGIO     Wait at least a minute then enter SELECT state.
> 
>    ANNOUNCE    Send ARP announcements the enter CONFIGURED
>                state.
> 
>    CONFIGURED  The link-local address has been configured for
>                the interface and is now usable.  The host must
>                respond to three events.
> 
>                If a claim is detected, respond with a defending
>                ARP.  Stay in CONFIGURED state.
> 
>                If an ARP with a conflicting assignment of the
>                configured address is detected, defense may be
>                undertaken once (enter the state of DOUBT) or
>                go directly to INIT state, surrendering the
>                configured address.
> 
>    DOUBT       If an ARP with a source address is detecting
>                which conflicts with the configured address
>                during 10 seconds, proceed to INIT state.
>                See Section 2.5.
> 
>                Otherwise, the conflicting use of the address
>                has been defended against.  Return to the
>                CONFIGURED state.  See Section 2.5.
> 
>    DEPRECATED  This state is entered when a link-local address
>                has been autoconfigured for an interface, then
>                subsequently the interface receives a configured
>                address (as from DHCP).  In this state, new
>                connections are established with the configured
>                address and the link-local address is not advertised.
>                Eventually, one SHOULD transition to EXIT state.
>                See Section 1.7.
> 
>    EXIT        Cease using the IPv4 link-local address, do not
>                attempt to configure another such address unless
>                an interface exists for which there is no IPv4
>                link-local address configured.
> 
> 
> 
> I hope that this makes it clear:  In each case where there is
> a transition marked "interface has IPv4 addr configured? 1.7"
> this could be caused by the DHCP state machine entering BOUND
> state.  It is also possible to transition from EXIT to INIT
> in the case where a configured address is no longer available.
> We do not enter into a full discussion of this transition in
> this specification.  It is considered in more detail in
> http://www.ietf.org/internet-drafts/draft-ietf-dhc-dna-ipv4-02.txt
> 
> Erik
>