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

From: Erik Guttman <[email-masked]>
Date: Wed, 01 Oct 2003 10:34:17 +0200

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

---

From: Alex Karahalios <[email-masked]>
Date: Wed, 1 Oct 2003 07:28:30 -0700

Does this mean that once a DHCP address is established that the machine 
will not participate in IPv4LL? If this is the case, then it would be 
problematic in that if another node is brought online that does not 
obtain an DHCP address (either it does not want to or DHCP server is 
down), then that node cannot communicate with the first node using 
IPv4LL.

Alex Karahalios

---

From: Robert Elz <[email-masked]>
Date: Wed, 01 Oct 2003 22:34:23 +0700

Date:        Wed, 1 Oct 2003 07:28:30 -0700
    From:        Alex Karahalios <[email-masked]>
    Message-ID:  <[email-masked]>

  | Does this mean that once a DHCP address is established that the machine 
  | will not participate in IPv4LL? If this is the case, then it would be 
  | problematic in that if another node is brought online that does not 
  | obtain an DHCP address (either it does not want to or DHCP server is 
  | down), then that node cannot communicate with the first node using 
  | IPv4LL.

This is simply not true.   Go back and read the list archives.

kre

---

From: Mika Liljeberg <[email-masked]>
Date: Wed, 01 Oct 2003 19:41:16 +0300

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

---

From: "Philip Nye" <[email-masked]>
Date: Thu, 2 Oct 2003 10:15:41 +0100

> From: "Erik Guttman" <[email-masked]>
>

The IPv4LL state machine is affected by the configuration state or the
interface. That state may be affected by DHCP state machine in certain
circumstances. However, the question the IPv4LL state machine has to ask, is
"Does the interface have a working routable address configured" and that is
not asked of the DHCP state machine.

I think your state diagram captures this well. However, in my phrasing of
the question above "working" is a weasle word which allows for configured
but inappropriate addresses to be ignored. How this is determined is an
issue we should avoid, but the DNA draft helps by providing a pointer.

I do not see any serious difference in opinion among recent posts, but the
level of discussion confirms that the wording has to be chosen carefully -
the state machine helps.

Philip

---

From: Erik Guttman <[email-masked]>
Date: Tue, 07 Oct 2003 13:47:22 +0200

> 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

---

From: Mika Liljeberg <[email-masked]>
Date: Tue, 07 Oct 2003 20:53:58 +0300

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

---

From: Erik Guttman <[email-masked]>
Date: Wed, 08 Oct 2003 11:39:13 +0200

> same time is simply the least desctructive option.

In the case of the transition from unconfigured to configured there
is clear consensus that one should 'give up' (that is: stop advertising,
stop initiating new connections from and eventually stop accepting
communication from) a link-local configured address.

In the case of the transition from configured to unconfigured there
is no clear consensus yet.

Choices are
   - give up dhcp configuration and configure link-local
   - hold onto dhcp configuration and don't configure link-local

These I discussed in the text I suggested.  (Does that text make sense?)

   - hold onto dhcp configuration and configure link-local

This is a problematic situation in that the host is now 'multihomed',
with all the attendant problems we have discussed ad nauseum.  One
way to address this is to mention that this implementation is in no
way ruled out, but neither is it specified, and refer anyone
interested in pursuing this option to section 3.

> If the admin wants to have both why should be care?

Manual intervention of host configuration is not always possible (to
deconfigure a link-local address, for example).

The point is, the sensible default policy is that when the host is
configured manually, link-local addresses do not get configured.
If an implementor wishes to venture into multihoming-territory, we
do not forbid it, but we do list a set of issues of which the
implementor must consider and address.  The specification and its
state machine assume the implementor will not go this way.  In the
case of an interface configured with more than one addresses, the
state machine is more complex since it needs to take into account
such things as changes to the host's routing table.

Erik

-----------

---

From: Mika Liljeberg <[email-masked]>
Date: Wed, 08 Oct 2003 20:03:15 +0300

> communication from) a link-local configured address.

[I presume you're using the terms configured and unconfigured to refer
to the routable address. The usage in the v4LL state machine description
is inverted.]

Agreed.

> interested in pursuing this option to section 3.

The really difficult problem here is *when* to transition, a problem
which we have been unable to solve. Having both addresses configured
during the transition period actually makes a lot of sense. While a
reference to section 3 is appropriate, the text should not actively
steer implementors away from what may be the only robust way implement
this thing.

I second Philip's suggestion that the v4LL implementation needs to
determine whether there is a "*working* routable address" or not. This
should be reflected in the state machine and also discussed in the
descriptive text. The state transition from INIT to SELECT is logically
triggered by the signal that the validity of the routable address can no
longer be confirmed.

Similarly, the state transition from CONFIGURED to DEPRECATED is
triggered by the signal that a routable address has been configured and
validated.

> deconfigure a link-local address, for example).

That's purely an implementation issue. It can be done.

> configured manually, link-local addresses do not get configured.

Yes, I agree this is the sensible default policy as long as the policy
is not hardcoded into the state machine. If v4LL is administratively
enabled on the interface, the v4LL state machine should be able to
proceed from INIT to SELECT when the manually configured address stops
working (by whatever criteria the implementation uses to detect such
things).

> state machine assume the implementor will not go this way.

Sadly, I think this is a false assumption. The reality simply is that
most implementations are multihomed (even if most deployed hosts are
not) and the implementors are faced with having to work out how to
accommodate v4LL in their multihomed code. It will be interesting to see
how people deal with this dilemma.

> ps. please comment on suggested text (from previous message):

I'll refrain until I see how the third option gets worked into the text.

	MikaL