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

Erik,

I know we have a (more than rough) WG consensus to not configure a
link-local at the same time with a routable address but we should not
take that contraint beyond the point where it stops being useful.
Remember that we made this decision to protect a small class of
applications that may fail, because they are unaware that they are not
supposed to pass LLs around.

If it is not possible to verify that a routable address is working we're
faced with a situation where nearly ALL applications will break (due to
having no connectivity at all) if we make the wrong choise. In this
situation, having BOTH the routable address and the LL configured at the
same time is simply the least desctructive option.

So what I'm trying to say is, if we have a valid DHCP lease and we can't
get a response from the DHCP server, there is absolutely no reason why
we should discard that lease prior to configuring a LL. In this case it
is acceptable to configure both. I'm not proposing that an
implementation SHOULD configure both, merely that it MAY do so. In any
case the LL can and should be deprecated as soon as the DHCP server
comes back online.

As for a manually configured addresses, there is absolutely no reason to
prevent a manually configured address from coexisting with a LL address,
since the admin can also manually disable the LL if it is not desired.
If the admin wants to have both why should be care?

	MikaL


On Tue, 2003-10-07 at 14:47, Erik Guttman wrote:
> Mika Liljeberg wrote:
>  > 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.
> 
> Mika,
> 
> You are not satisfied with the arcs in the state machine which
> lead to 'EXIT' since they do not spell out the exact conditions
> in which an interface 'has been configured'.
> 
> I remind (as wg chair)
> 
>   - We have already ruled out the formal application of IPv4LL
>     'in all cases' or 'to provide IP configuration in the case
>     of *misconfiguration*' to provide robustness, etc.
> 
> I believe (as wg participant, not as wg chair)
> 
>   - We must rule out the case where the IPv4LL spec 'overrules'
>     manually configured addresses.
> 
>   - We must cautiously state what it means to be configured with
>     a DHCP - as we may 'wake up' with a valid lease in a context
>     other than that which DHCP configured the host.
> 
> We have already had this discussion.  It hinges upon a passage
> in RFC 2131:
> 
>     3.7 When clients should use DHCP
> 
>     A client SHOULD use DHCP to reacquire or verify its IP address and
>     network parameters whenever the local network parameters may have
>     changed; e.g., at system boot time or after a disconnection from the
>     local network, as the local network configuration may change without
>     the client's or user's knowledge.
> 
>     If a client has knowledge of a previous network address and is unable
>     to contact a local DHCP server, the client may continue to use the
>     previous network address until the lease for that address expires.
> 
> Note the word >>may<<.
> 
> Thus, the implementor of IPv4LL has discretion.  I suggest that we
> 
>     1) add a new section:
> 
>        2.12 Transition from Routable Address to Link-Local
> 
>           A host may 'wake up' (see Section 2.2) with a valid DHCP
>           lease.  According to RFC 2131, Section 3.7:
> 
>              A client SHOULD use DHCP to reacquire or verify its
>              IP address and network parameters whenever the local
>              network parameters may have changed; e.g., at system
>              boot time or after a disconnection from the local
>              network, as the local network configuration may change
>              without the client's or user's knowledge.
> 
>              If a client has knowledge of a previous network address
>              and is unable to contact a local DHCP server, the client
>              may continue to use the previous network address until
>              the lease for that address expires.
> 
>           Before a host with a valid DHCP address configures an IPv4
>           LL address it MUST use DHCP to attempt to reacquire or
>           verify its IP address and network parameters.  In the case
>           where the the DHCP client is unable to contact a local DHCP
>           server, the behavior of the IPv4 link-local configuration
>           implementation is not specified.  The implementor has a
>           choice:  Either abandon the DHCP lease and configure a
>           link-local address or retain the previous network address.
> 
>           Implementors are faced with a trade-off:  'Robustness to
>           DHCP Server Unresponsiveness' versus 'Rapid Transition to
>           Autoconfigured State'.
> 
>           If DHCP configuration parameters continue to be used
>           despite the DHCP server's lack of response, the client
>           will be more robust to transient DHCP server inavailability.
>           The disadvantage is that a mobile host removed from the
>           context in which it received a long-duration lease will not
>           autoconfigure.  This means, for example, that a laptop
>           computer may continue to use the configuration it received
>           'at work' even though the owner is currently 'at home.'
> 
>           If autoconfiguration occurs as soon as it has been determined
>           that the DHCP client is unable to contact a local DHCP server,
>           the host will respond to 'waking up' in a new network
>           environment.  This will allow the host to communicate with
>           other hosts which implement this specification on the link
>           as soon as possible.  The disadvantage of this strategy is
>           that it will encourage unneeded and disruptive interface
>           configuration changes in the case where a DHCP server is
>           unresponsive for a short period of time.
> 
>           Retaining the configuration supplied by DHCP emphasizes
>           stability of service for hosts on centrally configured
>           networks.  This is the most prevalent networking context
>           today.  Users are easily annoyed if their hosts become
>           reconfigured and unusable for several minutes at a time,
>           which is the likely outcome if a spurious configured to
>           link-local transition is undertaken.  Obtaining
>           autoconfiguration parameters as quickly as possible
>           (according to the protocol timers defined by RFC 2131 and
>           this specification) benefits the mobile user whose host
>           finds itself in different networking contexts and wishes
>           to gain access to their resources immediately.
> 
>     2) add the state machine below to the IPv4 LL specification in a
>        new section:
> 
>        2.13 IPv4 Linklocal Configuration State Machine
> 
>            <as cited below>
> 
> I think that this addresses your concerns and would greatly improve
> the draft.  This gets to the heart of Ted's concerns, too, I think.
> 
> Erik
> 
> > On Wed, 2003-10-01 at 11:34, Erik Guttman wrote:
> >>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
> >>
> > 
> 
>