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

From: Erik Guttman <[email-masked]>
Date: Tue, 23 Sep 2003 12:14:51 +0200

Action: Accept the issue, with the text as modified during discussion

New text:

2.11  Transition from Link-Local IPv4 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].

[DNAv4]
Aboba, B., "Detection of Network Attachment (DNA) in IPv4",
draft-ietf-dhc-dna-ipv4-01.txt, Internet draft (work in progress),
September 2003.

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

---

From: Ted Lemon <[email-masked]>
Date: Mon, 29 Sep 2003 21:49:14 -0500

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

---

From: Mika Liljeberg <[email-masked]>
Date: Tue, 30 Sep 2003 20:55:49 +0300

Erik,

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.

	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: Ted Lemon <[email-masked]>
Date: Tue, 30 Sep 2003 13:46:35 -0500

> independently of each other? I just want to be absolutely clear on 

This is the meat of the issue.   The fact that the IPv4ll draft doesn't 
explicitly mention IPv4ll interaction with the DHCP state engine 
doesn't mean that there is no interaction.   This is the topic about 
which I would like to see some dialog, and this is why I'm complaining.

Erik, you are correct to say that the draft doesn't explicitly place 
requirements of any kind on DHCP.   However, the draft does say what 
happens when routable IP addresses appear and disappear.   And the 
problem with this is that we have seen implementors do the wrong thing 
because of this.   The requirements in the draft about not having an 
IPv4ll address and an IPv4 routable address at the same time exacerbate 
the situation.

So what would satisfy me would be some implementation notes in the 
document that looks something like this:

x.x.x Interaction between DHCPv4 client and IPv4ll state machines

A device that implements both IPv4ll and a DHCPv4 client MUST NOT alter 
the behavior of the DHCPv4 client to accommodate the IPv4ll state 
machine.   Specifically, DHCPv4 specifies an INIT-REBOOT state.   If a 
DHCPv4 client fails to contact a DHCP server while in INIT-REBOOT 
state, the implementor may be tempted to not configure the IP address 
from the client's valid DHCPv4 lease, preferring instead to acquire an 
IPv4ll address and use that address exclusively.   This is an incorrect 
optimization.   Instead, the implementor should allow the IPv4ll state 
machine in this case to acquire and use an IPv4ll address, while at the 
same time allowing the DHCPv4 client to configure the IP address from 
its lease.

The problem with adding this text is that right now the IPv4ll draft 
isn't very helpful about how to choose an IP source address when you 
have both an IPv4ll address and a routable address.   The result is 
that the implementor will have to figure this out on his or her own, 
through trial and error, or, more likely, will leave the problem 
unsolved, resulting in poor behavior in cases where both addresses are 
configured.   I think that the draft needs to address this in detail, 
but whether it addresses this or not, in order for IPv4ll to not break 
the DHCP client, some text like what I've proposed needs to be added.   
I don't believe simply not explicitly requiring IPv4ll to break the 
DHCP INIT-REBOOT case is sufficient.

---

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

Date:        Tue, 30 Sep 2003 13:46:35 -0500
    From:        Ted Lemon <[email-masked]>
    Message-ID:  <[email-masked]>

  | A device that implements both IPv4ll and a DHCPv4 client MUST NOT alter 
  | the behavior of the DHCPv4 client to accommodate the IPv4ll state 
  | machine.

That's too much, for two reasons.   First, we don't specify how implementers
implement the specifications, just the end results - so that's inappropriate
right from the start.   Second, if I want to alter my dhcp client, to
have the LL address generation done by it, as well as dhcp address aquisition,
why shouldn't I?    Or if I just want to provide info from my dhcp client.

I know those aren't the kinds of modifications you're concerned about, but
they're covered by that blanket exclusion.

If anything needs to be said, all it needs to be is that the DHCP state
machine is not altered by LL.   That's it.

kre

---

From: Ted Lemon <[email-masked]>
Date: Tue, 30 Sep 2003 14:18:16 -0500

> machine is not altered by LL.   That's it.

That's probably a better way to introduce the note than the MUST NOT 
that I put in.   However, I think it's important to state explicitly 
what sort of interaction we are worried about, and why.   You are right 
that we can't and shouldn't place requirements on the implementor as to 
how he or she implements this - that wasn't my intention, just bad 
wording.

---

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: Ted Lemon <[email-masked]>
Date: Tue, 30 Sep 2003 14:33:31 -0500

> exchange (the DHCP protocol), not really to changing the dhcp client 

That's right.

---

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

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