Subject: [dhcwg] DHCP Version 3 Issue

From: "Aaron Leach" <[email-masked]>
Date: Tue, 30 Sep 2003 15:14:11 -0600

Having Issue with DHCP version 3

We are having a few types of devices not getting addresses via the DHCP
server. DHCP server is running on OpenBSD version 3.2.
Basically, the types of devices that are in question are Netgear and Linksys
routers, Packet 8 DTA-310 terminal devices, and some older Macintosh
versions older than OS-X 10.0. 
We use a MYSQL database that dynamically creates a DHCP.conf file. We put
the exact mac address into the database. We use mac authentication so that
only those who are in the database work.
I did a network sniff on one of the devices that was having an issue. I
noticed in the sniff that a mac address was not being sent, but rather a
device identifier and the last 6 digits of the mac address. Something that
looked like this:

Kino 34:0b:36  

(I could not remember the device identifier for the DTA-310, but I think it
was Kino. I accidentally deleted the sniff, so the Kino part could be wrong)

The sniff showed that only requests were sent from the DTA-310, not offers.
The dhcp.leases file showed no requests going to the mac that requested an
address.

Now there might be an issue where the device is sending part-name/part-mac
address and this could be throwing off the DHCP server which results as an
offer not being sent. 

Is this the case? Is there a fix for this issue? Or, can someone direct me
in the book the answer is so that I can get this issue fixed? I appreciate
any help that is given.

Thanks,

A Leach
Iprovo.net

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, September 30, 2003 10:00 AM
To: [email-masked]
Subject: dhcwg digest, Vol 1 #639 - 3 msgs

Send dhcwg mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www1.ietf.org/mailman/listinfo/dhcwg
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of dhcwg digest..."

Today's Topics:

   1. Re: WG consensus action: ACCEPT LL34 better transition to routable
from v4LL using DHCP (Ted Lemon)
   2. Proposed Resolution to DNA Issue 6: SIRs review (Bernard Aboba)
   3. Proposed resolution to DNA Issue 5: IPv4LL -> DHCP transition (Bernard
Aboba)

--__--__--

Message: 1
Date: Mon, 29 Sep 2003 21:49:14 -0500
Subject: Re: [dhcwg] WG consensus action: ACCEPT LL34 better transition to
routable from v4LL using DHCP
Cc: [email-masked], [email-masked]
To: Erik Guttman <[email-masked]>
From: Ted Lemon <[email-masked]>

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

--__--__--

Message: 2
Date: Mon, 29 Sep 2003 07:19:19 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: [dhcwg] Proposed Resolution to DNA Issue 6: SIRs review

The text of DNA Issue #6 is enclosed below.  The proposed fix is as
follows:

Change the abstract to:

" The time required to detect movement (or lack of movement) between
subnets, and to obtain (or continue to use) a valid IPv4 address may
be significant as a fraction of the total delay in moving between
points of attachment. This specification synthesizes experience
garnered over the years in the deployment of hosts supporting ARP,
DHCP and IPv4 Link-Local addresses, in order to optimize detection of
network attachment by mobile hosts."

Add the following text to Section 1:

" The time required to detect movement (or lack of movement) between
subnets, and to obtain (or continue to use) a valid IPv4 address may
be significant as a fraction of the total delay in moving between
points of attachment. As a result, optimizing detection of network
attachment is important for mobile hosts."

Add the following text to Section 2.2:

" Since the ARP Response is sent to the sender hardware address, the
contents of the sender protocol address field do not affect delivery
of the ARP Response. Since existing implementations do not create an
ARP cache entry for 0.0.0.0, using this as the sender protocol
address is harmless."

----------------------------------------------------------------------------
------
Issue 6: SIRs Review
Submitter: Joel Halpern
Submitter email address: [email-masked]
Date first submitted: September 15, 2003
Reference:
http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg02357.html
Document: DNAv4-01
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

Over all the draft is well written and clear. It is on the right track,
but I believe it could use some clarifications. In particular, two aspects
seem to me to be in need of assistance.

Firstly, the problem statement seems to be missing a piece. While the
concern being addressed is likely obvious to those who work daily with
DHCP and DHCP related issues, it is not obvious to a reader from another
community. In particular, I found myself asking why I would use the
reachability validation step rather than simply going directly to
INIT-REBOOT state and sending a DHCPREQUEST to the broadcast address. I
suspect that the ARP reachability verification mechanism is expected to be
significantly faster and to place less load on other parts of the system.
But the document does not say that.

Secondly, in the description of the reachability verification mechanisms
it would be helpful if there were a sentence indicating why the use of the
0.0.0.0 source protocol address will be effective. (I checked the ARP RFC<
not having ARP code handy, and I understand that the ARP response
generation sends the response to the source hardware address. It would be
helpful to the reader if the document said this.) Related to this
clarification, it would probably be helpful to note (probably in an
appendix) both whether this behavior has been observed to cuase any
strange ARP cache entries and whether most observed implementations do
indeed respond properly to the message proposed here. (I know they should.
However, the difference between theory and practice...)

--__--__--

Message: 3
Date: Mon, 29 Sep 2003 07:26:02 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: [dhcwg] Proposed resolution to DNA Issue 5: IPv4LL -> DHCP
transition

The text for DNA Issue 5 is enclosed below.  The proposed fix is as
follows:

Add the following text to Section 2.3:

"Where a Link-Local IPv4 address is assigned, experience has shown
that five minutes (see [IPv4LL] Appendix A.2) is too long an interval
to wait until retrying to obtain a routable IPv4 address using DHCP.
According to [RFC2131] Section 4.1:

The retransmission delay SHOULD be doubled with
subsequent retransmissions up to a maximum of 64 seconds.

As a result, a DHCP client compliant with [RFC2131] will continue to
retry every 64 seconds, even after allocating a Link-Local IPv4
address. Should the DHCP client succeed in obtaining a routable
address, then as noted in [IPv4LL], the Link-Local IPv4 address is
deprecated. In order to avoid inappropriate assignment of an IPv4
Link-Local address, it is RECOMMENDED that such an address not be
assigned until the DHCP client has retransmitted at least 3 times."

-------------------------------------------------------------------------
Issue 5: IPv4LL -> DHCP transition
Submitter: Robert Elz
Submitter email address: [email-masked]
Date first submitted: September 10, 2003
Reference:
http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg02331.html
Document: DNAv4-01
Comment type: T
Priority: S
Section: 2.3
Rationale/Explanation of issue:

I certainly agree that the long waits that dhcp clients usually
fall into after their initial few attempts to contact a dhcp
server can be most annoying, and that retrying more often would
be nicer from the end user's viewpoint.

On the other hand, I'm not sure that I'd be happy to have a LAN
with perhaps hundreds of hosts (maybe thousands) all sending
continuous streams of broadcast packets looking for a DHCP server.
(A thousand hosts, with a 25 second (avg) delay is 40 broadcast
packets a second, which is starting to get too high - make that
5000 hosts, which is not unreasonable in some switched environments,
and you're at 200 broadcast packets a second - which is beyond
inconvenient and into extremely annoying).

It may be that the correct strategy here is for hosts that have
failed to contact the DHCP server [and allocated an IPv4LL address is] to
remain on a "slow retry" regime, but always set the "broadcast reply" bit
in dhcp requests.

Then, upon noticing a DHCP reply, hosts could (after a short random
delay to avoid a packet deluge) try again to get an address (no
requirement
to request a broadcast reply, if not needed, after seeing one) - the
observed reply would indicate that the DHCP server has returned to life.

If there are just a few hosts that aren't getting replies, perhaps
because the DHCP server is ignoring them deliberately, having them
set the broadcast reply request bit (unnecessarily) will be harmless,
there won't be replies.

If the DHCP server has really gone absent, and there are lots of people
looking for replies, this would allow the hosts to avoid sending much
traffic until there is evidence that there's a reasonable chance of
achieving a result.

Ideally, the slow down rate would depend upon the number of clients
around to make requests (what is really wanted is one client at random
making a request every few seconds, and all the others staying quiet until
they observe a reply) but with DHCP, knowing how many other clients there
are would mean listening to request packets, that clients don't usually
want to do (and on some OS's is hard, without precluding the client from
also being a server on a different LAN).   So, probably there just needs
to be a reasonable compromise rate set.

But this is all DHCP, not LL addressing, and needs the DHCP experts
to give advice on - it is possible that they have considered, and
rejected, this kind of approach in the past.

[Ted Lemon]

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.

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.

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.

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.

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.

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.

[Robert Elz]

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

[Ted Lemon]

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.

[Robert Elz]

  | In this case, the DHCP client
  | will still configure its interface if it has a valid lease.

Yes, and in most circumstances where that happens, that address will
work just as well as a LL address (the DHCP client is supposed to
verify that the lease still makes some kind of sense - it needs to do
that to choose between the several valid leases it might have from
past assignments (I've had clients allocated multi-year leases from some
weird servers, and sometimes had several of those simultaneously).  If
the DHCP client checks that the address seems functional before assigning
it, then the LL address would only be useful in the rarest cases.

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

That's true - but no-one knows.   The DHCP client doesn't (if it knew it
was incorrect, it would not configure it, to know it is correct it needs
a DHCP server response, which we are assuming does not happen), the LL
assignment machinery has no idea, it just sees a non-LL address (and
perhaps the DHCP timeout), but more than that, none of the applications
that are to use the address know either.   They're going to be faced with
the situation of having a choice of 2 local addresses to use, and no idea
which one is going to work better.   In most cases, the (old) DHCP address
will work fine, and probably reach more destinations than the LL address,
so in most cases that is what the applications are going to want to use, I
suspect.   Given that, doing the extra work to assign an LL address in
this scenario seems pointless.

  | So simply watching the interface isn't going to get you the best
  | results for IPv4ll,

If getting the best results for IPv4LL was an objective, I'd probably
agree.   But it isn't.   Rather, IPv4LL is an attempt to get the best
results for the system (or more likely, the system's user).   That is,
it doesn't matter in the slightest if IPv4LL fails miserably, as long
as the end result is correct, and communications get established,
at least in the vast majority of cases.

[Erik Guttman]

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.

--__--__--

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

End of dhcwg Digest

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