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

Tomek Mrugalski thomson at klub.com.pl
Sat Nov 10 10:44:13 CET 2018


On 09/11/2018 22:45, Tore Anderson wrote:

> 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.
That would likely be possible with a bit of code tweaking. But the
problem is Dibbler is effectively an abandoned project.
> 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. 
True. It was mostly ignorance of the implementer, which happen to be me.
If I rewrite relay, this is one of the things I'd do differently.

The original reason was that for relays it is essential to control which
interfaces the packets are coming in and out. That's why I originally
implemented this as an interface parameter.
> 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?
Seems like a bug. I don't know why relay sends duplicates. It probably
has to do with how RelTransMgr iterates over the interfaces. Also, the
code in RelIfaceMgr::send is rather naive.

My major point here is that relay implementation in dibbler was well
through out. When I implemented it (I got first prototype over a weekend
and then it took years to improve it), I didn't understand the
deployment models and was looking at this strictly from protocol
perspective.


Cheers,
Tomek


More information about the Dibbler mailing list