dhcp-relay: Discussion - how to handle DHCP server replies

[tohojo]

How do we handle the replies from the DHCP server? We need to attach the right
VLAN tags and make sure it goes out the right interface. Capturing these in XDP
on the return path may be the most straight-forward approach.

One consideration here is whether we should assume that the DHCP server is
trusted (and thus just pull the destination data out of the packet), or if we
should keep state for when the reply comes back. The former is probably
simplest.

[yoelcaspersen]

Approach: One-legged BNG

For now, I assume that DHCP server replies are received on the same physical interface as the client requests (although with different VLAN tags). That way, we can use XDP_TX action to pass on a server response to a client once the necessary headers and options have been changed.

Advantages:

• Simplicity (only one XDP program required, no need for XDP_REDIRECT logic)
• Future optimization: Route traffic via XDP (with XDP_TX)

Disadvantages:

• Response packets need to be routed through the same NIC as client traffic - may complicate configuration if multiple NICs are used

Issue #9 contains a list of necessary tasks for a one-legged BNG.

Other possible approaches:

• Receive server response with XDP program on interface A, send to client on interface B with XDP_REDIRECT (requires logic to find interface B)
• Receive server response in user space, send to client via raw sockets or similar

[tohojo]

yoelcaspersen ***@***.***> writes:

For now, I assume that DHCP server replies are received on the same physical interface as the client requests (although with different VLAN tags). That way, we can use XDP_TX action to pass on a server response to a client once the necessary headers and options have been changed.

This seems like it's limiting the deployment unnecessarily. I think using XDP_REDIRECT is more flexible, and the configuration system should know which interfaces are involved anyway.

[yoelcaspersen]

If we want to receive a DHCP response on one NIC and pass it on to the client on a different NIC, we will need some kind of mapping between the intended client QinQ-VLAN (based on Option 82 in response from server) and the physical NIC.

Can we do that in a simple way - without making the DHCP relay stateful?

[tohojo]

On 13 October 2021 20:48:26 CEST, Yoel Caspersen ***@***.***> wrote: If we want to receive a DHCP response on one NIC and pass it on to the client on a different NIC, we will need some kind of mapping between the intended client QinQ-VLAN (based on Option 82 in response from server) and the physical NIC. Can we do that in a simple way - without making the DHCP relay stateful?

Aren't you putting the interface address into the request packets as src IP? So presumably the reply has that as dst?

[yoelcaspersen]

That is correct, but I suppose you would need to maintain a map of IP addresses and corresponding NICs then?

If we can find a way to trust server replies, we could include the ifindex in the option 82 in the request packet - it would provide a shortcut to finding the right NIC on the way back to the client.

[tohojo]

On 13 October 2021 21:05:40 CEST, Yoel Caspersen ***@***.***> wrote: That is correct, but I suppose you would need to maintain a map of IP addresses and corresponding NICs then?

Yeah, or just look it up in the routing table?

If we can find a way to trust server replies, we could include the ifindex in the option 82 in the request packet - it would provide a shortcut to finding the right NIC on the way back to the client.

This seems like a bad idea. ifindexes are internal to a machine, they have no business going out on the wire... :)

[yoelcaspersen]

Yeah, or just look it up in the routing table?

Sure - but that means the IP address will have to be configured on the physical NIC, right? We discussed the possibility of using proxy ARP on all client QinQ interfaces to prevent having to attach the IP address anywhere...

This seems like a bad idea. ifindexes are internal to a machine, they have no business going out on the wire... :)

On a second thought, I think you are right. I suppose ifindex would also change from time to time, making static DHCP server configuration not only hard, but outright impossible.