Subject: Re: Turning off link-locals?

From: "s. goswami" <[email-masked]>
Date: Tue, 21 Jan 2003 21:02:12 -0500 (EST)

Yes, using DHCP for 169.254/16 is not necessary. What are
the pitfalls if one wishes to do so ?

Subrata

On Wed, 22 Jan 2003, Ian Lister wrote:

> On Tue, 21 Jan 2003, s. goswami wrote:
> >So a relevant question is can LL coexist with DHCP/Manual ?
> >
> >1. In different subnets (or physical link). Absolutely.
> >2. In the same physical link (i.e. mix 169.254/16 with say 192.168/16 )?
> >   A 169.254 interface can talk to a 192.168 host sitting on the same
> >   physical link without a router.  DHCP servers can handout 169.254/16
> >   addresses if they want.
>
> I'm not quite sure what you're driving at, but yes, IPvLL can coexist with
> non-IPv4LL on the same link and can communicate with each other.
> However, configuring a DHCP server to hand out IPv4LL addresses seems like
> a distinctly bad idea.
>
> Ian
>

---

From: Daniel Senie <[email-masked]>
Date: Tue, 21 Jan 2003 21:17:08 -0500

>the pitfalls if one wishes to do so ?

Addresses in 169.254/16 are self-assigned, using claim and defend.

DHCP servers need not be attached to the segment or subnet on which they're 
handing out addresses (e.g. DHCP Relay in use). As such, the DHCP server 
has no way to know which addresses are in use on a subnet where stations 
self assign addresses. Even if the DHCP server were on the same subnet, IT 
would have to do the claim and defend for all addresses it handed out. This 
is not wise.

So, it's important that DHCP servers NEVER hand out addresses in LL space.

---

From: "s. goswami" <[email-masked]>
Date: Tue, 21 Jan 2003 21:31:26 -0500 (EST)

see inline

> would have to do the claim and defend for all addresses it handed out. This

the DHCP server is supposed to ping (ICMP) the address before handing it
out (takes IT out of the loop).

---

From: Keith Moore <[email-masked]>
Date: Tue, 21 Jan 2003 22:08:16 -0500

> the pitfalls if one wishes to do so ?

well, there are the normal pitfalls associated with scoped addresses of any
kind - they're ambiguous, etc.  of course those pitfalls exist with RFC 1918
addresses also.

then you can probably expect that some applications will treat v4LL addresses
differently than normal routable addresses, where this behavior is
application-specific and might or might not be what you want for your network.

then there is the potential for conflict between DHCP-assigned addresses in
that space and automatically-claimed addresses in that space, from legacy (i.e.
pre-standardization) implementations of v4LL.

offhand it seems better if such addresses are not doled out by DHCP.

Keith

---

From: Daniel Senie <[email-masked]>
Date: Wed, 22 Jan 2003 08:07:22 -0500

>out (takes IT out of the loop).

Two problems I see with this:

1. A ping is NOT equivalent or compatible with what this draft requires for 
claim and DEFEND. Note my emphasis on the latter part. If the DHCP server 
is providing the address, the DHCP client generally expects it will get to 
keep that address. So if an LL host comes up and chooses the same address, 
will the DHCP client defend itself? Should it have to? Isn't the station 
(DHCP Server) which made the allocation responsible for ensuring the 
address is (AND REMAINS) available for that station? Please read section 
1.4 of the LL draft and explain how and why you think thia is in error.

2. It is possible for a DHCP server to functionally hand out addresses on a 
network which it cannot reach via routed packets. Since DHCP Relay is a 
function of intervening routers, there's the possibility it would not be 
able to ping the remote lan where the allocation is being made. Whether 
this violates the DHCP specs or not is not entirely clear to me without 
doing some research.

Fundamentally, I fail to see why you're harping on this issue in the first 
place. Why do you want a DHCP server handing out 169.254/16 addresses at 
all? What value or benefit do you see in this? If it's to try and give out 
addresses that are in the same IP Subnet as LL addresses, so that LL and 
non-LL can talk, there could almost be merit there, but since the DHCP 
servers will more often NOT give out such addresses, the problem of 
intercommunication must still be solved. Also note that the first 256 and 
last 256 addresses in 169.254/16 are reserved for future IETF standards 
work. If there were a compelling reason to permit DHCP to allocate anywhere 
in 169.254/16, it would be into one of these two blocks, but would also 
require an IETF Standards Track document.