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

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?

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.

> 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, 30 Sep 2003 20:55:49 +0300

Erik,

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

	MikaL

---

From: Robert Elz <[email-masked]>
Date: Wed, 01 Oct 2003 01:24:13 +0700

Date:        Tue, 30 Sep 2003 20:55:49 +0300
    From:        Mika Liljeberg <[email-masked]>
    Message-ID:  <1064944549.4769.5.camel@hades>

  | 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 state machines run independently, when they're run - but you don't
generate a LL address if you get an address from elsewhere.   DHCP simply
does its thing, as it does now, no changes needed.   LL looks to see if an 
address has been obtained (or even manually configured), and if not, it
runs its state machine to acquire one.

kre

---

From: Mika Liljeberg <[email-masked]>
Date: Tue, 30 Sep 2003 21:44:29 +0300

> runs its state machine to acquire one.

That's not exactly independent.

In any case, in an ad-hoc scenario I need a working address within
approx. 10 seconds after the user activates an application and the RF is
powered up. Not much time to dance around, there. I figure the only way
to meet the usability requirements is to run the state machines in
parallel and deprecate the v4LL address later if DHCP happens to
succeed. Time syncing the state machines is kind of hard, as the DHCP
client is in user space and the v4LL protocol is in kernel space. If
synching the state machines is a requirement, I'm afraid the DHCP client
will have to do it.

	MikaL

---

From: Robert Elz <[email-masked]>
Date: Wed, 01 Oct 2003 02:13:45 +0700

Date:        Tue, 30 Sep 2003 21:44:29 +0300
    From:        Mika Liljeberg <[email-masked]>
    Message-ID:  <1064947469.4768.13.camel@hades>

  | That's not exactly independent.

It is independent state machines - they are just dependencies
on when they're used.

  | In any case, in an ad-hoc scenario I need a working address within
  | approx. 10 seconds after the user activates an application and the RF is
  | powered up.

10 secs should be plenty - it only takes a couple of seconds after the
link is stable to get a DHCP assigned address, if you're going to get one,
in the vast majority of cases (and perhaps an extra second or two for
one more retry).   LL is supposed to take about 3 seconds in the current
version isn't it (I forget just what we eventually decided on the LL
timers).   That's 5-8 if run serially (assuming that you start LL
acquisition if DHCP doesn't quickly get an address, which is what I
suggest - not wait for DHCP to exhaust all its possibilities).

  | I figure the only way
  | to meet the usability requirements is to run the state machines in
  | parallel and deprecate the v4LL address later if DHCP happens to
  | succeed.

Fine, I have no problem with that.

  | Time syncing the state machines is kind of hard, as the DHCP
  | client is in user space and the v4LL protocol is in kernel space.

That's an implementation choice, you could move either to the other
space.   When one makes implementation choices, one, of course, has to
live with the consequences.

  | If synching the state machines is a requirement, I'm afraid the DHCP client
  | will have to do it.

I see no problem with that either, and I don't think Ted does either.
What he's objecting to (I believe) is changing the nature of the DHCP
exchange (the DHCP protocol), not really to changing the dhcp client code.

kre

---

From: Mika Liljeberg <[email-masked]>
Date: Tue, 30 Sep 2003 23:07:42 +0300

> It is independent state machines - they are just dependencies

I'd say that's mostly semantics. There's clearly a dependency but I
think you're saying that it is limited to the DHCP client sending, as
part of one of its own state transitions, the v4LL state machine a start
or stop signal.

I can live with that (it's more or less what I expected the requirement
to be). But I do agree with Ted that there is some danger of
misinterpritation. We need some fairly specific language on
implementation issues to steer implementors away from harmful
interpretations.

	MikaL