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

[Lennart Poettering]

On Fri, 28.02.14 09:05, Umut Tezduyar Lindskog (umut.tezduyar at axis.com) wrote:

> > Hmm, how is this hooked up in detail? i.e. when is the IPv4LL state machine
> > started? I think I'd like to see this started after a short while when no DHCP
> > response is seen, and immediately stopped as soon as one is found later on.
> > Or what are your ideas here? Tom?
> 
> I have discussed this with Tom and Patrick and we have initially
> agreed on starting ipv4ll as soon as possible and let the state
> machine probe/announce/defend an address but let the networkd make the
> LL assignment not before DHCP times out. I, on the other hand, think
> being able to access to a product as early as possible is very
> important. Example would be retrieving a burglary image before waiting
> for dhcp times out. LL state machine is ready for both approaches and
> changing networkd would be relatively easy.

OK.

> > How is this hooked up with the link beat? I mean, if we watch the link beat
> > and it changes, and we already have an ipv4ll address we probably want to
> > check for conflicts immediately?
>
> 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.

> > 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.

Lennart

-- 
Lennart Poettering, Red Hat