udhcpc: IPv4LL (unique link local address when DHCP server does not respond)

[Peter Faasse]

On Tuesday 05 April 2016 12:22:06 Prasant J wrote:
> Hi,
> 
> I'm using busybox version 1.23.1 (yocto jethro release).
> 
> When DHCP server is not available I see my linux system getting IPv4LL
> (Link local) address (169.254....). We may have many linux sytsems
> running together.
> 
> 
> My queries:
> - Who assigns a link local address to the system? (ifup/udhcpc/... any
> other tool)

Not quite sure about busy box-situation.. I've experimented with this link-
local addresses. Usually, dhcpcd assigns them if/when no dhcp server is 
present. dhcpcd has an option (from-memory: -L) to disable this. With -L, if 
no dhcp server is present, no address at all will be assigned.

> - Does udhcpc/ifup ensures each system is assigned a unique link local
> address when multiple systems may be present?

There it gets really interesting. 

A bit of background:

This link-local addressing mechanism is -when used intentionally- usually part 
of a so-called 'bonjour' (Apple-name..), avahi (one of the linux 
implementations), mdns (more generic name) network. Yep: many names for the 
same thing. 'It' is a standard developed by Apple, with free implementations 
on Linux. The goal is to provide no-configuration networking to a cluster of 
computers all connected to a local network. The 169.254.X.X IP range is 'free' 
for this. 

IP address assignment works roughly as follows:

When a node becomes active on such a network, it 'proclaims' its intention to 
use a 'wisely' choosen IP address by sending network packets to the 
169.254.X.X network. If another node on the network already 'owns' that 
address, and receives such proclamation packets, the already-owner responds, 
effectively complaining that the newcomer is attempting to steal its address. 
The newcomer must respond with a re-try of proclamation with a different 
address. This is not race-free/bomb-proof, so the mechanism does allow a node 
to run-time re-assign its own address. NB: the 'wisely' in previous section 
usually entails that a node becoming active attempts to re-use the address 
that 'worked' the last time.. NB2: Yes a run-time re-assignment is a desaster 
for already-established TCP sockets, but: so is a network with an ghost of 
your IP address :-)

The mdns protocol 'stuff' provides a whole load of other nice facilities. How 
much of that is active depends on how much of the zeroconf 'stack' you have 
installed and -hem, hem- configured... :-)  A fully active stack would allow a 
cluster of zeroconf computers to form a network of peers with no dedicated 
'servers' that can assing IP addresses, resolve names and find and access 
services (think: printer, ftp/nfs server, www-server) on the nodes of the 
cluster.

That dhcpcd (or brother/sister app..) supports assigning a zeroconf address is 
the first step of a long and -for me at least- interesting road. I hardly ever 
*use* this mechanism on Linux, but it was a nice thing to study/learn about... 

NB: there is an O'Reilly book about 'zeroconf networking'.. 

> 
> 
> Any inputs will be of help to me.
> 
> Regards, Pj
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://lists.busybox.net/mailman/listinfo/busybox
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20160405/0d91e73a/attachment.asc>