[Dibbler] DHCPv6 relaying in a link-local-only IPv6 network

Tore Anderson tore at fud.no
Fri Nov 9 16:45:41 CET 2018


Hi,

I'm experimenting with building an IPv6 data centre network where all
the links are numbered using link-local addresses only (cf. RFC 7404).
The switches do have globally scoped addresses on their loopback
interface, so they can reach remote destinations.

I've been trying to use dibbler-relay on the edge/leaf switches (to
which the DHCPv6 clients are connected), but I'm running into a few
kinks. Example relay.conf:

iface swp1 { # client-facing interface
  client multicast yes
  interface-id 1
} 
[...]
iface swp51 { # uplink interface 1
  server unicast 2001:db8::547
}
iface swp52 { # uplink interface 2 
  server unicast 2001:db8::547
}

That fails with the warning «Warning No global address defined on the
swp51/12 interface. Trying to bind link local address, but expect
troubles with relaying.» (and same for swp52), and indeed, relaying
doesn't work.

Attempting to substitute the «iface swp51/52» blocks for a «iface lo»
block (because that's the only interface with a non-link-local address)
instead causes another failure: «Critical Interface lo/1 is down or
doesn't have any link-layer address».

I can work around this by adding some global addresses to swp51/52
instead, but of course that means the network isn't link-local-only any
longer.

In any case, I'm left with a few questions:

1) Is it possible to override the source address selection for
relay->server traffic? While there's no global address on swp51/52 there
is one on lo, and since Linux uses the weak host model it should be no
problem using that on even though the traffic egresses another
interface. And Linux does this by default, I can test this with e.g.
«echo foo | nc -u 2001:db8::547 547» - the UDP packets show up on the
DHCP server just fine with the loopback-assigned GUA address as the
source.

2) Why does the «server unicast» need to be associated with specific
uplink interfaces, instead being a global setting? It seems much simpler
to me if figuring out the outgoing interface (and the possibly the
source address) was delegated to the kernel and behave exactly like the
nc example in the previous question. That would also mean I wouldn't
have to remember to reconfigure the relay if I'm adding more uplink
capacity and so on. I see ISC dhcrelay also behaves like dibbler-relay
here, requiring the explicit configuration of uplink interfaces. On the
other hand, the DHCPv4 relay dhcp-helper doesn't require that, and works
just fine.

3) If I do add GUA addresses to the uplink interfaces, the client
requests are forwarded fine to the server. However, they're duplicated
by the relay. Presumably, if the edge switch had 6 uplink interfaces
defined, each with their own «server unicast» setting, the server would
normally receive 6 relayed requests for each client request, which is
hardly ideal. Is it possible to suppress this somehow?

Tore


More information about the Dibbler mailing list