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

Janet Christiansen jchristiansen at expresslogic.com
Fri Nov 9 20:02:03 CET 2018

Hello Tore

First, our NetX Duo DHCPv6 Server does not support relay mode, and I am reasonably sure that NetX Duo DHCPv6 Client does not either.  But I will check with our development team. 

Also I am not much of an expert on Dibbler. I principally use it to set up a simple DHCPv6 server (or client) to test our DHCPv6 modules.  Actually my version is a bit out of date, (runs on Windows 7 only).  Your questions sound like they would be best handled at the Dibbler web page support. I've gotten good advice/help from their FAQs and to my direct queries.  

If you have any specific NetX Duo or NetX Duo DHCPv6 Client/Server questions, I am happy to work with you. 


-----Original Message-----
From: Dibbler <dibbler-bounces at klub.com.pl> On Behalf Of Tore Anderson
Sent: Friday, November 9, 2018 7:46 AM
To: dibbler at klub.com.pl
Subject: [Dibbler] DHCPv6 relaying in a link-local-only IPv6 network


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?


More information about the Dibbler mailing list