Subject: [dhcwg] [Fwd: new issue: LL34 Better transition to routable from v4LL using DHCP]

From: Erik Guttman <[email-masked]>
Date: Thu, 11 Sep 2003 21:10:45 +0200

This is important for the DHC WG to look at.  It is the last open
issue up for discussion in the ZEROCONF WG.  Feedback is requested
in the next week.  Obviously we can't make a decision about this
without direction from the DHC WG.

Thanks,

Erik

ps. sorry if this is a duplicate message

-------- Original Message --------
Date: Thu, 11 Sep 2003 11:14:02 +0200
From: Erik Guttman <[email-masked]>
To: [email-masked]
Subject: new issue: LL34 Better transition to routable from v4LL using DHCP

Description of Issue: Better transition to routable from v4LL using DHCP
Submitter Name  Bernard Aboba
Submitter Email Address  [email-masked]
Date first submitted  11 Sep 03
Reference
Comment Type  Technical
Priority  S (must change)
Section  2.11 (new section)
Rationale/Explanation of issue:

(a)  We need to ensure an orderly method for recovering a routable
       address given LLv4 addressing.  Much of the time an LLv4 address
       is allocated inappropriately,  and so it's important to be able
       to obtain a routable address via DHCP if one is available.  The
       current LLv4 spec doesn't address this, and the current default
       retry interval of 5 minutes is way too long.

(b) Interactions of DHCP with LLv4. The LLv4 specification seems to
      imply that an LLv4 address should be allocated when a DHCPREQUEST
      or DHCPDISCOVER does not obtain an answer.  Existing implementations
      show that this behavior is problematic since the lack of response is
      most likely a temporary phenomena or the result of a bug of some
      kind rather than the lack of a DHCP server on the link.

      5 minutes is too long. I'd suggest 1 minute or even less (I've
      seen a Linux implementation which retries every 30 seconds with
      jitter and that works a lot better).

Lengthy description of problem:

Requested change:

Create a new section:
2.11  Repeatedly Attempt to Obtain A Routable Address

    As per Section 1.7, use a routable address is preferred to use of
    a link-local address.  In many cases, a link-local address is
    configured because a DHCP server failed to respond to an initial
    query, or is inoperative for some time.  Experience has shown that
    five minutes (see Appendix A.2 for example) was too long an
    interval to wait and try to configure with DHCP.

    A host which has been configured with an IPv4 link-local address
    SHOULD periodically attempt to obtain an IPv4 address via DHCP.
    The recommended policy is to attempt to configure using DHCP after
    waiting for RECONF_INTERVAL, plus a random number of seconds,
    uniformly distributed, between zero to RECONF_JITTER seconds.

Modify:
9.  Constants

Add:

     RECONF_INTERVAL      25 seconds
     RECONF_JITTER        10 seconds

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

---

From: Ted Lemon <[email-masked]>
Date: Thu, 18 Sep 2003 12:37:12 -0500

> without direction from the DHC WG.

So I think the right answer to this question is to simply decouple the IPv4LL 
and DHCP state machines.   As long as the IPV4ll state machine can reach out 
and touch the DHCP state machine, it's likely to do things that break the 
operation of the DHCP state machine.

So the right answer is, IMHO, that if the IPv4LL believes that it *may* be in 
a state where connectivity has been lost, it should configure itself a 
link-local address, and when it leaves that state, it should make the 
transition back to using the globally routable address exclusively.

In other words, the IPv4LL state machine should watch the DHCP state machine 
and make decisions at least in part based on what state the DHCP client is 
in, but the DHCP client should not change its behavior at all to accomodate 
this.   So if the DHCP client is in the INIT-REBOOT state and doesn't get an 
answer from the DHCP server, it should continue using its globally routable 
address.   But the IPv4LL agent should make note of this, and configure an 
IPv4LL address.

Does that make sense?   I realize that this has the downside that now the 
IPv4LL agent must be able to watch the DHCP client in order to do a good job 
of maintaining Iv4LL service, but I think this is preferable to breaking DHCP 
service.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 18 Sep 2003 12:56:20 -0500

On Thursday 18 September 2003 12:37, Ted Lemon wrote:
> So I think the right answer to this question is to simply decouple the
> IPv4LL and DHCP state machines.

To be clear, I meant here "decouple the DHCP state machine from the IPv4ll 
state machine," but not "decouple the IPv4LL state machine from the DHCP 
state machine" - obviously this isn't possible if we do what I've proposed.

---

From: Robert Elz <[email-masked]>
Date: Fri, 19 Sep 2003 16:44:48 +0700

Date:        Thu, 18 Sep 2003 23:38:16 -0500
    From:        Ted Lemon <[email-masked]>
    Message-ID:  <[email-masked]>

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

I have no problem with that, that's what I'd do.   The problem that we have
is that everyone wants everything to fall into the perfect state instantly.
Any time that we're in an unexpected state is "broken", even if there's
nothing the implementation could really have done about that.

That is, my approach to this, which I don't think conflicts with the
drafts at all, would be to start the DHCP client (let it go do its thing
just like it does now, ignoring LL addressing), wait a second and a half
(puerly because of that 1 second boring meaningless non-answered ping delay
verifying that the address is not assigned) and then see if I have an address.
If not, configure an LL address as documented, and use that.  Then keep
monitoring the interface.  If a routable address appears from somewhere
(most likely from DHCP, but anywhere will do) mark the LL address (if the
LL process has reached this stage yet) as deprecated - and yes, this means
borrowing some (more) IPv6 innovation and terminology for v4 (which is
really needed anyway to make dhcp work correctly - currently on the stack
I use, if dhcp gives me a v4 address, then the lease expires, dhcp will then
take away the address again - just as it should - but I can trivially avoid
that just by killing my dhcp process, the IP stack has no concept at all
of a lifetime for v4 addresses, if the dhcp process doesn't remove the
address, it is permanent, it should have a valid time, just as v6 addresses do).

The issue I was detecting in the issue (LL34) though is that once we're in
that state, we don't want to remain in it, if a routable address should be
available - LL34 is trying to tell DHCP to keep trying hard to get a
routable address.

  | Lest you conclude that I am off my rocker, a way to check this would be to 
  | look for the place in RFC2131 where it says that the DHCP client should
  | wait for five minutes after failing (that is, having retried and timed out)
  | to  contact a DHCP server, before reinitiating an attempt to contact one.

No, I know that's not there - that's why I used the words "operational 
requirements" in the previous message - LL34 wants to force implementations
to retry quickly.   2131 doesn't say "wait 5 minutes" but it also doesn't
say "don't wait 5 minutes", or "try again every 5 seconds" - something like
the latter is what LL34 seems to be asking of DHCP (though it actually
says 1 minute, not 5 seconds, but hints that 30 secs would be even better).

That's why I see this issue as an attempt to change DHCP from the zeroconf WG.
The LL processing happens just the same, other than wrt absolute times,
whatever the DHCP server does, but people want it to happen quickly, not
slowly...

This is exacerbated with LL addresses existing (the problem is made worse),
so now there's a greater incentive to fix it.

Before LL, networking was simply broken, if no DHCP address could be
obtained.   That's a simple state - easy to explain - easy for the user
to handle ("popop box says no dhcp server responded, no address, no
networking - someone fix the dhcp server please!").   With LL addresses
getting no routable address is "expected", it isn't an error - the stack
just configures an LL address and says "I'm ready, use me" - and the user
believes all is OK - except nothing works.    In this situation we really
want things to revert to the "fixed" state as quickly as possible, lest
frustration result "where did I get this stupid useless address instead
of the one I should have - the network is broken".

kre

---

From: Ted Lemon <[email-masked]>
Date: Thu, 18 Sep 2003 23:38:16 -0500

On Thursday 18 September 2003 22:52, Robert Elz wrote:
> This is really irrelevant to the issue raised.   What was really being
> requested, once all the wrapping is removed, was that this WG make a
> change to the DHCP protocol (or perhaps more precisely, to the operational
> requirements for DHCP) - that is to force DHCP clients to try harder to
> get routable addresses (lower the delay as much as possible if there is
> no immediate answer).

That's one way to read it, yes.   However, the reason for wanting this is that 
IPv4LL places a requirement on the network stack that it quickly *give up* 
trying to acquire an address, and several IPv4LL+DHCP implementations have in 
fact done this.

And now we are being asked to put a bandaid on this by making it *re-acquire* 
an address quickly.   So the root of the problem is, in fact, that the DHCP 
client is being made to act differently because of IPv4ll.   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.

Lest you conclude that I am off my rocker, a way to check this would be to 
look for the place in RFC2131 where it says that the DHCP client should wait 
for five minutes after failing (that is, having retried and timed out) to 
contact a DHCP server, before reinitiating an attempt to contact one.   I 
would direct your attention particularly to section 4.1, which says nothing 
like this.

---

From: Robert Elz <[email-masked]>
Date: Fri, 19 Sep 2003 10:52:57 +0700

Date:        Thu, 18 Sep 2003 12:37:12 -0500
    From:        Ted Lemon <[email-masked]>
    Message-ID:  <[email-masked]>

  | So I think the right answer to this question is to simply decouple
  | the IPv4LL and DHCP state machines.

The relationship with LL addresses is purely coincidental to this.

That's why this really belongs in the DHCP working group (where apparently,
and I guess you already know, something has been proposed already), and
not here at all.

kre

---

From: Ted Lemon <[email-masked]>
Date: Thu, 18 Sep 2003 17:10:58 -0500

On Thursday 18 September 2003 16:38, Mika Liljeberg wrote:
> From the implementor's point of view the coupling either exists or it
> doesn't. If it does exist an explicit interface is required between the
> DHCP code and the v4LL code. How that interface is realized is an
> implementation issue.

The distinction is important because I do not want the presence of IPv4ll to 
break DHCP.   There have been several suggestions about minimizing the damage 
that is caused by linking IPv4ll and DHCP.   The way I've proposed eliminates 
the damage, as far as I can tell.

> It would be better to have no coupling at all.

I agree completely.   However, in order for there to be no coupling, we have 
to say that IPv4ll and DHCP addresses should simply coexist at all times.   
We fought that battle and "lost."   Personally, I'd be happier just to give 
up on IPv4ll entirely and use the Rendezvous standard instead, because of 
this damage.   But given that the damage has been done, if the IPv4ll 
standard is going to go forward, it's imperative that we prevent it from 
making DHCP unreliable.

---

From: Mika Liljeberg <[email-masked]>
Date: Fri, 19 Sep 2003 00:38:10 +0300

> state machine" - obviously this isn't possible if we do what I've proposed.

I don't think this is a particularly useful distinction.

	MikaL

---

From: Ted Lemon <[email-masked]>
Date: Fri, 19 Sep 2003 14:01:01 -0500

On Friday 19 September 2003 04:44, Robert Elz wrote:
> verifying that the address is not assigned) and then see if I have an
> address. If not, configure an LL address as documented, and use that.  Then
> keep monitoring the interface.  If a routable address appears from
> somewhere (most likely from DHCP, but anywhere will do) mark the LL address
> (if the LL process has reached this stage yet) as deprecated - [...]

Right, this is exactly what I had in mind too.

> available - LL34 is trying to tell DHCP to keep trying hard to get a

I don't think this is necessary.   Section 4.1 of RFC2131 is already pretty 
explicit about what the DHCP client is supposed to do - the problem is that 
some popular DHCP clients aren't doing this, because (I presume) their state 
machines have been tweaked to accomodate IPv4ll.

> says 1 minute, not 5 seconds, but hints that 30 secs would be even better).

Actually, section 4.1 already says that the DHCP client shouldn't back off to 
more than 64 seconds, so the DHCP client should be retrying roughly every 64 
seconds if it's following RFC2131.   Perhaps the IPv4ll spec needs to make 
clear that implementors of IPv4ll that also implement DHCP must still follow 
the recommendations put forth in RFC2131 section 4.1.

> of the one I should have - the network is broken".

Right, and if we just don't let the IPv4ll state machine reach out and touch 
the DHCP state machine, this is precisely what will happen.   That is, the 
DHCP client should never care about IPv4ll.

It is helpful, however, for the IPv4ll agent to notice that the DHCP client 
has timed out in contacting the DHCP server.   In this case, the DHCP client 
will still configure its interface if it has a valid lease.   However, the 
IPv4ll agent at this point should probably also configure an IPv4ll address, 
since the address the DHCP client is using is by no means guaranteed to be 
correct.   So simply watching the interface isn't going to get you the best 
results for IPv4ll, although it's an improvement over having the IPv4ll agent 
reaching out and touching the DHCP client.