[systemd-devel] [PATCH] sd-dhcp: implement IPv4 link-local support

[Lennart Poettering]

On Fri, 28.02.14 14:34, Tom Gundersen (teg at jklm.no) wrote:

> 
> On Fri, Feb 28, 2014 at 2:24 PM, Lennart Poettering
> <lennart at poettering.net> wrote:
> >
> >> If you stop LL state machine and start again, then you will go through
> >> the probe/announce/defend process anyways. Tell you the truth I didn't
> >> quite understand your question.
> >
> > Well, in embedded environments (unlike on mobile/desktop cases) you
> > probably want to leave the network interface continiously configured as
> > soon as you got an IP address, and not take it down as soon as the link
> > beat vanishes, to provide stability for local apps.
> >
> > However, even in that case, each time the link sensing reports that a
> > cable got connected when it wasn't before we should refresh the DHCP
> > release and check with ARP whether the IPv4LL address is still without
> > conflicts, simply as a safety measure.
> 
> I guess we could use CriticalConnection for this? Though currently the
> policy there for DHCP is that we never ever drop the address, so not
> sure how that would work with an IPv4LL conflict.

Maybe a new WatchLinkBeat= or so? If "yes" this would mean that the
iface is unconfigured as soon as link beat is lost, if "no" this would
mean that the iface is always left configured as soon as it got an
address, but still refreshed if link beat changes comes back.

> >> > Hmm, this hash function is probably not that great... We probably should just
> >> > use siphash here, we kind try to standardize on that...
> >>
> >> We are going to change the way we generate LL addresses and there is a
> >> TODO item for this too. We are going to have a predictable
> >> sequence. This way, if network crashes after assigning a LL address,
> >> our start off address will be the last one we have assigned.
> >
> > Hmm, what do you mean by "predicatable"? I mean, if there's a conflict,
> > and both sides notice that and decide to pick a new address but do that
> > with the same PRNG sequence they will try the same address next and so
> > on and so on.
> 
> My suggestion was to seed the PRNG like we do for the persistent MAC
> addresses. The sequence of attempted IP's will be the same for a given
> NIC on a given machine, but different machines/NICs will have
> different sequences.

This only works if the PRNG state can be stored per interface. Can we do
this with the glibc one?

Lennart

-- 
Lennart Poettering, Red Hat