Subject: Fwd: linklocal + DHCP servers

From: Ralph Droms <[email-masked]>
Date: Thu, 04 May 2000 17:48:07 -0400

Jay Goldschmidt posted the question below to the zeroconf mailing list; the 
discussion morphed into the broader question about whether DHCP servers 
should ever hand out link-local (169.254/16) addresses.  Seemed like a good 
question to ask on the DHCP mailing list, too...

There's a related question - after taking on a link-local address, should 
the DHCP client use that link-local address or 0.0.0.0 as the source 
address in subsequent broadcast DHCPDISCOVER messages?

- Ralph

>From: Jason Goldschmidt <[email-masked]>
>To: [email-masked]
>Subject: linklocal + DHCP servers
>
>When a DHCP server comes up on a zeroconf network, are link-local
>configured devices considered as configured devices to the DHCP server?
>
>Or in other words:  There is a zeroconf device that has configured itself
>w/ a link-local address. Can that device, send a DHCPREQUEST for its
>link-local address? And if so, what should the DHCP server do with that
>address request?
>
>A server might want to allow the zeroconf device to keep the address and
>then respond w/ additional configuration information in the subsequent
>DHCPACK.  Though, doing so would still bring up the problems that Bernard
>just mentioned about NATing for link-local addresses.
>
>Thanks,
>
>-Jason
>
>
>*************************************)
>Jason Goldschmidt  [email-masked] *)
>http://coral.bucknell.edu/~jgoldsch *)
>"My Reality Check Bounced"          *)
>                 -Scott Adams        *)
>*************************************)
>
>
>
>
>

---

From: Richard Jones <[email-masked]>
Date: Thu, 04 May 2000 15:16:24 -0700

It's an excellent question. I can't imagine an admin wanting to configure
a network to run from a pool of link-local addresses, but it seems to
me that having the protocol start to carve up pieces of the address
space and call them off limits (or special cases) would be a bad
precedent, at the least.

It sounds like the idea is to have clients come up with their own
link-local addresses and have the DHCP server 'approve' them,
optionally adding configuration info. Sounds like a different protocol.

As far as the source address goes, (doesn't that refer to 'ciaddr'?),
it looks to me like 2131 is clear about it being zero during a
DHCPDISCOVER (not that I'm comfortable quoting that RFC to
you, Ralph ;-).

It would seem like an implementation issue if someone wanted to
support clients that do otherwise, unless we want to change the
protocol.

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 5 May 2000 06:16:01 -0700

draft-ietf-dhc-ipv4-autoconfig-04.txt states:

[Section 4]
    When the client originally sent out it's request, there may have
    been a network problem stopping the DHCP Server from responding.  To
    make sure this is not the case, a host with an auto-configured IP
    address MUST keep checking for an active DHCP Server.  To do this,
    the host MUST attempt to fetch an IP address as described in section
    1 of this document.

[Section 1]
    This is
    done by sending out a DHCPDISCOVER message, with various tags set
    indicating what options the DHCP Client would like to receive
    information for [DHCPOPT].  The DHCP Client SHOULD also send the
    DHCP AutoConfigure option described in [DHCPAC].

So the client is supposed to send a DHCPDISCOVER, not a DHCPREQUEST.

One of the arguments for *not* allowing
DHCP to allocate 169.254/16 is the issue of conflict avoidance.
If the DHCP server is directly attached to the 169.254/16 segment,
it is possible for the DHCP server to do the same checks
that the client would, namely ARP'ing for the address before
allocating it. However, if the DHCP server is not directly
attached, such a check would not be possible and since
addresses within the 169.254/16 prefix are not supposed to
be routable, it is not clear how the DHCP server could
ping the address or otherwise accomplish the check.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Ralph Droms
Sent: Thursday, May 04, 2000 2:48 PM
To: DHCPv4 discussion list
Subject: Fwd: linklocal + DHCP servers

- Ralph

---

From: Bill Manning <[email-masked]>
Date: Fri, 19 May 100 01:14:54 -0700 (PDT)

% 
% Jay Goldschmidt posted the question below to the zeroconf mailing list; the 
% discussion morphed into the broader question about whether DHCP servers 
% should ever hand out link-local (169.254/16) addresses.  Seemed like a good 
% question to ask on the DHCP mailing list, too...

	Whats the point?  These are autoconfigured by the end systems.

% There's a related question - after taking on a link-local address, should 
% the DHCP client use that link-local address or 0.0.0.0 as the source 
% address in subsequent broadcast DHCPDISCOVER messages?

	My take is that they use the link-local address as source.

% 
% - Ralph
% 
% >From: Jason Goldschmidt <[email-masked]>
% >To: [email-masked]
% >Subject: linklocal + DHCP servers
% >
% >When a DHCP server comes up on a zeroconf network, are link-local
% >configured devices considered as configured devices to the DHCP server?
% >
% >Or in other words:  There is a zeroconf device that has configured itself
% >w/ a link-local address. Can that device, send a DHCPREQUEST for its
% >link-local address? And if so, what should the DHCP server do with that
% >address request?
% >
% >A server might want to allow the zeroconf device to keep the address and
% >then respond w/ additional configuration information in the subsequent
% >DHCPACK.  Though, doing so would still bring up the problems that Bernard
% >just mentioned about NATing for link-local addresses.
% >
% >Thanks,
% >
% >-Jason
% >
% >
% >*************************************)
% >Jason Goldschmidt  [email-masked] *)
% >http://coral.bucknell.edu/~jgoldsch *)
% >"My Reality Check Bounced"          *)
% >                 -Scott Adams        *)
% >*************************************)
% >
% >
% >
% >
% >
% 
% 

-- 
--bill

---

From: Ralph Droms <[email-masked]>
Date: Fri, 19 May 2000 07:58:32 -0400

>         Whats the point?  These are autoconfigured by the end systems.

Autoconfiguration and link-local are two distinct characteristics of
169.254/24 addresses.  I'm asking if DHCP-configured, link-local addresses
might ever be of interest.  And, if the question has been asked once, is it
likely to be asked again - if so, we should make a decision and codify
that decision in an appropriate spec so we don't revisit the question
in the future.

>         My take is that they use the link-local address as source.

According to RFC2131, DHCPDISCOVER messages are to be sent with source
address 0.0.0.0  We should decide if we want to change that aspect
of the DHCP spec to accommodate autoconfiguring hosts.  There may be
a DHCP server that drops incoming DHCPDISCOVER messages with non-zero
source addresses.

- Ralph

---

From: Kim Kinnear <[email-masked]>
Date: Fri, 19 May 2000 10:17:44 -0400

At 07:58 AM 5/19/00 -0400, Ralph Droms wrote:
>>  [...]

Interesting.  I was under the impression that the IP source
address was essentially a don't care for the DHCP protocol
(though no doubt someone can quote me a paragraph or two that
contains words that appear to counter my claim).  But,
semantically, what does the source address matter to the DHCP
protocol?  The only times we care about the current address of
the client we require the client to explicitly put it in the
ciaddr.

I would say that we should revise RFC2131 to say that the
protocol is independent of the source IP address (since
apparently that is not explicit now) since all of the information
used by the protocol is *inside* of the DHCP packet itself (which
plays well with the forthcoming authentication).

Or am I missing something here?

Cheers -- Kim

---

From: Ralph Droms <[email-masked]>
Date: Fri, 19 May 2000 11:02:11 -0400

At 10:17 AM 5/19/00 -0400, Kim Kinnear wrote:

>contains words that appear to counter my claim).

 From RFC2131 (page 23)

4.1 Constructing and sending DHCP messages

    [...]

    DHCP messages broadcast by a client prior to that client obtaining
    its IP address must have the source address field in the IP header
    set to 0.

If I remember correctly, we added that text for compliance with RFC1122
(and I'll offer to be corrected by an appropriate quote) that requires
a source address of 0.0.0.0 for broadcast packets from a host that has
not been assigned an IP address.

>   But,

Agreed.  I'm coming at this issue from the point of view of
strict interpretation of the words in the RFC, not so much
what is needed for correct operation.

There is a related - although non-DHCP - issue: what does the IP
spec day about IP datagrams with a link-local source address, and
(as a practical matter) what do routers with those datagrams?  I
guess this question would apply to both 169.254/24 (IPv4) and IPv6
link-local addresses.

>plays well with the forthcoming authentication).

I agree - with the caveat that we don't want to encourage the use
of DHCP in a way that is non-interoperable with other protocols
and legacy devices.

- Ralph

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 19 May 2000 08:34:26 -0700

>         My take is that they use the link-local address as source.

The question is not so much what address is used as source, but what the
DHCP server is expected to *use* the source address for. Is it being
suggested that the DHCP server should use this as some kind of hint
to offer the auto-configured address?

---

From: Bill Manning <[email-masked]>
Date: Fri, 19 May 2000 09:57:09 -0700 (PDT)

%     DHCP messages broadcast by a client prior to that client obtaining
%     its IP address must have the source address field in the IP header
%     set to 0.
% 
% If I remember correctly, we added that text for compliance with RFC1122
% (and I'll offer to be corrected by an appropriate quote) that requires
% a source address of 0.0.0.0 for broadcast packets from a host that has
% not been assigned an IP address.

	Ah, but it has been assigned an IP address from link-local space.

% There is a related - although non-DHCP - issue: what does the IP
% spec day about IP datagrams with a link-local source address, and
% (as a practical matter) what do routers with those datagrams?  I
% guess this question would apply to both 169.254/24 (IPv4) and IPv6
% link-local addresses.

	The IP spec has no concept of link-local.
	Routers et.al. should not forward packets w/
	link-local addresses, heck they should not even
	be bridged, imho. (I've got a draft in on how this
	should occur.)

--bill

---

From: Ted Lemon <[email-masked]>
Date: Fri, 19 May 2000 11:43:52 -0700

> to offer the auto-configured address? 

The DHCP server can't know the source address reliably, since the
source address is lost on relayed packets.   So I hope the answer to
this question is 'no'.   :')

			       _MelloN_

---

From: "Bernard Aboba" <[email-masked]>
Date: Sat, 20 May 2000 07:36:11 -0700

>this question is 'no'.   :')

It isn't possible to offer a linklocal address on relayed packets
since there is no way for the DHCP server to determine whether
the address is in use or not. On a local link, the DHCP server
can ARP for the address. On a non-local link it is not possible
to use ARP for conflict detection and you can't use PING either
because linklocal addresses are not routable.

---

From: Rob Stevens <[email-masked]>
Date: Sat, 20 May 2000 16:23:49 -0700

At 11:43 AM 5/19/00 , Ted Lemon wrote:

>source address is lost on relayed packets.  ...
>
>

Is it? I thought this was a grey area. I distinctly remember posting this
question to this group about 2 years back and getting no consensus
answer.

---

From: Bill Manning <[email-masked]>
Date: Sun, 21 May 2000 16:29:53 -0700 (PDT)

% 
% >The DHCP server can't know the source address reliably, since the
% >source address is lost on relayed packets.   So I hope the answer to
% >this question is 'no'.   :')
% 
% It isn't possible to offer a linklocal address on relayed packets
% since there is no way for the DHCP server to determine whether
% the address is in use or not. On a local link, the DHCP server
% can ARP for the address. On a non-local link it is not possible
% to use ARP for conflict detection and you can't use PING either
% because linklocal addresses are not routable. 
% 

Er, they are not routable in the same way that RFC 1918 space is not
routable. i.e. it is expected that operators will be smart and 
administrativly prohibit the routing.  
When the link-local space is routed, (and it is by some) then
there is no inherent way to attempt to determine origin. 

--bill

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 22 May 2000 07:06:22 -0700

>there is no inherent way to attempt to determine origin. 

Well, there are probably routers that don't treat 169.254/16 as 
a linklocal prefix. But that is what it was allocated as. In
contrast, 192.168/16 was a private prefix, but it is not linklocal.

---

From: Bill Manning <[email-masked]>
Date: Mon, 22 May 2000 07:06:04 -0700 (PDT)

% 
% >Er, they are not routable in the same way that RFC 1918 space is not
% >routable. i.e. it is expected that operators will be smart and 
% >administrativly prohibit the routing.  
% >When the link-local space is routed, (and it is by some) then
% >there is no inherent way to attempt to determine origin. 
% 
% Well, there are probably routers that don't treat 169.254/16 as 
% a linklocal prefix. But that is what it was allocated as. In
% contrast, 192.168/16 was a private prefix, but it is not linklocal.

Given the derth of publication on the IPv4 link-local address,
I'd be surprised if -any- code base treats the 169.254.0.0/16 
prefix as unique. And given its recent vintage and a lack of
understanding of the longer term impact, I'd be shocked if 
this had even made it to SOP status.   It will be a -very- long
time before this has the same status as the loopback space.

--bill

---

From: Ted Lemon <[email-masked]>
Date: Mon, 22 May 2000 08:49:41 -0700

> question to this group about 2 years back and getting no consensus

The DHCP relay agent is a network service, with its own source address
and so on.  Some relay agents are implemented to act as clever
routers, and I don't think this is explicitly forbidden by RFC951, but
it's certainly not recommended either, and it's probably in violation
of some other RFC somewhere.  Not that this is something I think
anybody really cares about, but the point is that even if a particular
relay agent happens to have this quality, the implementor can't assume
that all relay agents have this quality, so it can't be assumed that
the IP source address of the broadcast DHCP packet will make it to the
DHCP server intact.

			       _MelloN_

---

From: Ralph Droms <[email-masked]>
Date: Mon, 22 May 2000 18:37:39 -0400

>this question is 'no'.   :')

Of course.  Duh...

Sorry for raising (and not thinking through) a silly issue.

- Ralph

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 23 May 2000 07:36:51 -0700

>Sorry for raising (and not thinking through) a silly issue.

It's not so silly. Since the DHCP server couldn't test for
an address conflict in the case of a relayed packet, that
case is moot anyway. The question therefore centers on the
case where the DHCP server is on the same segment as the
client. 

In that case, it *is* possible for the DHCP server to test
for an address conflict, by ARP'ing for the address before
allocating it. It is also possible for the DHCP server to
examine the source IP address in making its decision, 
since this will not have been changed by a relay. 

The question is: is the benefit of allowing the clients to
retain their address strong enough to be worth doing something
special for this case? And what is that something special?

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 23 May 2000 07:40:40 -0700

>time before this has the same status as the loopback space.

So are you saying that we should just treat 169.254/16 as 
another private prefix and forget about it being linklocal?
Or that additional precautions need to be taken, like
sourcing packets from TTL=1?

---

From: Bill Manning <[email-masked]>
Date: Tue, 23 May 2000 09:23:50 -0700 (PDT)

% 
% >Given the derth of publication on the IPv4 link-local address,
% >I'd be surprised if -any- code base treats the 169.254.0.0/16 
% >prefix as unique. And given its recent vintage and a lack of
% >understanding of the longer term impact, I'd be shocked if 
% >this had even made it to SOP status.   It will be a -very- long
% >time before this has the same status as the loopback space.
% 
% So are you saying that we should just treat 169.254/16 as 
% another private prefix and forget about it being linklocal?
% Or that additional precautions need to be taken, like
% sourcing packets from TTL=1? 
% 

Er no.  I'm saying that presure ought to be placed on the
IESG to get the damm draft out as an RFC.  Link Local is not
the same as private use... its more restrictive.  TTL=1 is
one indicator.

-- 
--bill

---

From: Ralph Droms <[email-masked]>
Date: Wed, 24 May 2000 00:59:55 -0400

>space and call them off limits (or special cases) would be a bad

Yeah - I personally can't imagine running a network in which I centrally
manage a pool of link-local addresses.  But, it seemed like a good
question to ask - someone, somewhere, might want to do just that...

>optionally adding configuration info. Sounds like a different protocol.

There is the DHCPINFORM mechanism for obtaining other configuration
parameters.  Sounds like at least a separate question: do we want
to define the behavior of a broadcast DHCPINFORM request, with a
link-local source address, forwarded by a relay agent?

>DHCPDISCOVER (not that I'm comfortable quoting that RFC to

I was thinking of the IP header source address.  You've asked a different
question - the client fills in 'ciaddr' when it knows it's own IP
address.  Table 5 (RFC2131, p. 37-38) requires that 'ciaddr' == 0
in a DHCPDISCOVER.

- Ralph