Subject: RE: 169.254/16 IP addresses

From: "Peter Ford" <[email-masked]>
Date: Mon, 24 Apr 2000 11:24:51 -0700

What problem are people trying to solve here?

What breaks when DHCP configures a 169.254/16 address for an end system?

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Monday, April 24, 2000 6:07 AM
To: [email-masked]; 'Thomas Narten'; [email-masked]
Subject: RE: 169.254/16 IP addresses 

Prompted by Bernard's recent questions...

Is the 169.254/16 prefix a linklocal prefix, or specifically an 
autoconfiguration linklocal prefix?   The answer to that question would 
help us decide whether a DHCP server ought or ought not hand out
addresses 
with a 169.254/16 prefix.

- Ralph

---

From: Daniel Senie <[email-masked]>
Date: Mon, 24 Apr 2000 14:37:36 -0400

> Peter Ford wrote:

that's a good question.

> What breaks when DHCP configures a 169.254/16 address for an end

A DHCP server need not be on the same LAN as it is giving out addresses
on. See DHCP/BOOTP relay capabilities for a description of this. One
very real weakness of having DHCP hand out addresses in the link-local
space is the DHCP server may not be able to determine which addresses
are in use. Remember that link-local addresses can be self-assigned.

Will someone implement it and try it? Probably. Will it work? In most
cases, probably. I sure wouldn't want to be debugging a client's network
where this was all taking place and problems were arising...

In general, a major issue which must be remembered is that subnetting
169.254/16 is fraught with peril. Stations self-assign IP addresses
within this /16. Any partitioning will result in address conflicts.
We've covered these cases previously in discussions of zeroconf (e.g.
two isolated LANs getting bridged), but there's no provision that will
cleanly permit routing between pieces of 169.254/16 as presently
specified and being used.

-- 
-----------------------------------------------------------------
Daniel Senie                                        [email-masked]
Amaranth Networks Inc.                    http://www.amaranth.com

---

From: Peter Johansson <[email-masked]>
Date: Mon, 24 Apr 2000 12:51:14 -0700

>are in use. Remember that link-local addresses can be self-assigned.

Could the definition of a DHCP server be extended / modified so that
169.254/16 IP addresses are allocated ONLY on the link to which the DHCP
server's interface is connected?

Regards,

Peter Johansson

Congruent Software, Inc.
98 Colorado Avenue
Berkeley, CA  94707

(510) 527-3926
(510) 527-3856 FAX

[email-masked]

---

From: Ralph Droms <[email-masked]>
Date: Mon, 24 Apr 2000 19:36:29 -0400

Interesting suggestion; the DHCP server would, at least, be able to use the 
same address-defense mechanisms as the auto-config hosts.

Would the DHCP server pick a link-local address on demand (using the 
auto-config mechanisms for duplicate address detection) or would it use a 
range of pre-configured link-local addresses?  If the latter is allowed, 
will the DHCP server defend all of its configured link-local addresses 
against duplicate address detection?

- Ralph

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 25 Apr 2000 19:17:13 -0700

Perhaps we should take this discussion to the DHC WG mailing
list.

>same address-defense mechanisms as the auto-config hosts.

The danger is that the DHCP server allocation will conflict with
an auto-configured host. However, DHCP already recognizes this
possibility and RFC 2131 discusses how to deal with it. So hosts
receiving a DHCPOFFER can check that the address is not already
allocated (and send a DHCPDECLINE if it is) and DHCP servers can
also check. I'm not convinced that these mechanisms are inadequate
to the task.