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

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

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
> 

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

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

DOUBT  ANNOUNCE          1.7                            | 

      ^|      | 2.4                                         |

   State       Behavior

Erik

---

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, 30 Sep 2003 19:11:26 +0200

Ted Lemon wrote:

> 
> On Tuesday, September 23, 2003, at 05:14 AM, Erik Guttman wrote:
> 
>> The text supplied by Bernard has the property that it does not
>> specify any new behavior for DHCP.  The new text makes it clear
>> that an implementation of IPv4LL must attempt to obtain configuration
>> via DHCP according to the DHCP specification, even if it has failed
>> to in the past.  I think this satisfies Ted's concern:
>>
>> Ted Lemon wrote:
>> > The correct fix is to make sure that the DHCP client does not in fact
>> > modify its behaviour to make IPv4ll work, but rather to modify IPv4ll
>> > so that it doesn't interfere with the operation of the DHCP client.
> 
> 
> The new text that Bernard has supplied, at least as specified in your 
> proposed resolution for LL34, does not seem to address the problem at 
> all.   The problem is that right now the IPv4ll protocol specification 
> creates a situation in which there is an incentive to break the DHCP 
> client in order to get correct IPv4ll behavior. 

I do not follow you.  Please see my assessment of the current draft,
below.  I see nowhere, except where it is stated that DHCP SHOULD NOT
configure from the IPv4 LL prefix, that we introduce direct or indirect
requirements on DHCP or DHCP client behavior.

 > My goal is not to
> break the DHCP client less.   It is to not break it at all.   If you 
> don't agree with this goal, can you please try to build consensus by 
> explaining why you don't agree with it?

> Also, I think  that you should withdraw the statement that your proposed 
> solution to LL34 has been accepted, since there was no discussion on it, 
> and thus no opportunity for consensus.  

There was plenty of discussion about it both here and on the zeroconf
list, but that is neither here nor there.  I want to satisfy your
technical concern even if I can't respond to your liking about the
process by which we've been demanding decision points in otherwise
circular ZEROCONF discussions.

> I certainly do not agree that 
> it solves the stated problem.    Possibly I am reading too much into the 
> problem statement, but if so, I think we need a new discussion item: 
> "IPv4LL state machine must not place requirements on DHCPv4 state machine."

What if we add this sentence, verbatim, to the end of section 2.11?

   This specification places no requirements on the DHCPv4 state machine.

-----------

Let's be 100% clear what the requirements that ZEROCONF is placing on
DHCP.  The current text in
http://www.ietf.org/internet-drafts/draft-ietf-zeroconf-ipv4-linklocal-10.txt
regarding DHCP is as follows (an exhaustive excerpt).  I add emphasis
to aid those who follow the DHC list but not the zeroconf list.

Abstract

    To participate in wide-area IP networking, a host needs to be
    configured, either manually by the user or automatically from a
    source on the network such as a DHCP server.  Unfortunately, such
                                                  *******************
    external configuration information may not always be available.  It
    ***************************************************************
    is therefore beneficial for a host to be able to depend on a useful
    subset of IP networking functions even when no configuration is
    available.  This document describes how a host may automatically
    configure an interface with an IPv4 address within the 169.254/16
    prefix that is valid for communication with other devices connected
    to the same physical (or logical) link.

=> no requirements on dhcp

1. Introduction

    As the Internet Protocol continues to grow in popularity, it becomes
    increasingly valuable to be able to use familiar IP tools such as FTP
    not only for global communication, but for local communication as
    well. For example, two people with laptop computers supporting IEEE
    802.11 Wireless LANs [802.11] may meet and wish to exchange files.
    It is desirable for these people to be able to use IP application
    *****************************************************
    software without the inconvenience of having to manually configure
             *******                      *********
    static IP addresses or set up a DHCP server [RFC2131].
                           ******************************

=> no requirements on dhcp

1.6.  Alternate Use Prohibition

    Note that addresses in the 169.254/16 prefix SHOULD NOT be configured
              ***********************************************************
    manually or by a DHCP server.  Manual or DHCP configuration may cause
                ****************
    a host to use an address in the 169.254/16 prefix without following
    the special rules regarding duplicate detection and automatic
    configuration that pertain to addresses in this prefix.  While
    [RFC2131] indicates that a DHCP client SHOULD probe a newly received
    address with ARP, this is not mandatory.  Similarly, while [RFC2131]
    recommends that a DHCP server SHOULD probe an address using an ICMP
    Echo Request before allocating it, this is also not mandatory, and
    even if the server does this, Link-Local IPv4 addresses are not
    routable, so a DHCP server not directly connected to a link cannot
    detect whether a host on that link is already using the desired Link-
    Local IPv4 address.

    Administrators wishing to configure their own local addresses (using
    manual configuration, a DHCP server, or any other mechanism not
    described in this document) should use one of the existing private
    address prefixes [RFC1918], not the 169.254/16 prefix.

=> SHOULD requirement placed on DHCP administration

2.6.1.  Source Address Usage

    Since each interface on a host may have a Link-Local IPv4 address in
          *********************************
    addition to zero or more other addresses configured by other means
                ************       *********************
    (e.g. manually or via a DHCP server), a host may have to make a
     ****             *****************

    choice about what source address to use when it sends a packet or
    initiates a TCP connection.

=> no requirements placed on DHCP

2.8.  Link-Local Packets are Local

    It should be understood that this mediated communication is not
    mandatory; it is an option afforded to designers of extremely simple
    devices.  Any designer of a device desiring unmediated communication
              **********************************************************
    outside the local link need only implement today's conventional IP
    ****************************************************************** 

    host software (e.g. a DHCP client) in order to enjoy the same degree
    **********************************
    of global addressability available to other conventional IPv4 hosts.
    Such networked devices should of course implement a degree of
    security appropriate to being connected to a global public network.

=> no requirements on DHCP

2.11.  Transition from Link-Local to Routable Address

    As discussed in Section 1.7, use of a routable address is preferred
    to assignment of a Link-Local IPv4 address. A Link-Local IPv4 address
                                                *************************
    can be configured due to transient failures, such as incomplete link-
    *****************
    layer authentication, spanning tree convergence issues, or because a
                                                               *********
    DHCP server failed to respond to an initial query, or is inoperative
    *****************************
    for some time.

    Where a Link-Local IPv4 address is assigned due to a transient
    failure, experience has shown that five minutes (see Appendix A.2)
             *********************************************************
    may be too long an interval to wait prior to attempting to configure
    ******************************************************************** 

    with DHCP.  This document does not specify a strategy for quickly
    *****************************************************************
    recovering a routable address in situations where a Link-Local IPv4
    *******************************************************************
    address is assigned due to a transient failure. In situations where
    *******************************************************************
    many hosts are present on a single subnet, frequent attempts to
    ***************************************************************
    contact the DHCP server could result in a heavy traffic load. Further
    ************************************************************
    discussion of this issue is provided in [DNAv4].

=> no requirements on DHCP.  The current text states what existing
    implementations do, and that this has problems.  Apparently they
    are ignoring the DHCP recommendations, which I hope I get right:

    RFC2131, section 3 subsection 5 which suggests that

                               The client should choose to retransmit
      the DHCPREQUEST enough times to give adequate probability of
      contacting the server without causing the client (and the user of
      that client) to wait overly long before giving up; e.g., a client
      retransmitting as described in section 4.1 might retransmit the
      DHCPREQUEST message four times, for a total delay of 60 seconds,
      before restarting the initialization procedure.  If the client
      receives neither a DHCPACK or a DHCPNAK message after employing the
      retransmission algorithm, the client reverts to INIT state and
      restarts the initialization process.

    and RFC2131, section 4.4.1 which requires (SHOULD) that a random
    delay of 1-10 seconds elapse before a DHCPDISCOVER packet is sent
    while in INIT state.

    The Microsoft and Apple software which implements the '5 minute'
    delay before initiating DHCP configuration lengthened the suggested
    1-10 second wait before reentering INIT state.

The appendices describe current practice and do not place any
requirements on DHCP.

========================================================================

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

On Tue, 2003-10-07 at 14:47, Erik Guttman wrote:
> 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: Erik Guttman <[email-masked]>
Date: Tue, 07 Oct 2003 13:47:22 +0200

Mika,

I remind (as wg chair)

Note the word >>may<<.

    1) add a new section:

           <as cited below>

Erik

---

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

On Wed, 2003-10-08 at 12:39, Erik Guttman wrote:
> 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.

[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.

> 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.

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.

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

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

> The point is, the sensible default policy is that when the host is
> 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).

> 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.

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

---

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

Choices are

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

-----------