IPv6 Prefix Delegation: routes missing

[Maurice]

This is not about requesting a prefix from an upstream router / ISP, but about delegating prefixes to downstream routers in the LAN.

I have a static /48 from my ISP. OPNsense is used as a distribution router and should delegate /56 prefixes to other routers connected to its LAN interface.

Prefix Delegation Range and Prefix Delegation Size are properly configured in Services / DHCPv6 / LAN and downstream routers successfully request prefixes (visible in Services / DHCPv6 / Leases / Delegated Prefixes).
However, OPNsense doesn't seem to add routes for the delegated prefixes to its routing table. So clients connected to the downstream routers can't access the Internet.

Is this working for someone? If so, am I missing something? Or could this be a bug?

[franco]

Hi Maurice,

It used to be a bug, but it was supposed to be fixed in 18.1. Which version are you using?

https://github.com/opnsense/core/pull/2077


Cheers,
Franco

[Maurice]

Hi Franco,

Thanks for helping out so quickly. I'm on OPNsense 18.1.5-amd64.

These are my OPNsense IPv6 LAN settings:
Static IPv6 address: 2001:db8:feed::1/64
DHCPv6 Prefix Delegation Range: 2001:db8:feed:8000:: to 2001:db8:feed:bf00::
DHCPv6 Prefix Delegation Size: /56

I can see a downstream router getting delegated the prefix 2001:db8:feed:bf00::/56. I expected to find an auto-added route to this prefix in System / Routes / Status, but it's not there.

How could I troubleshoot this?

(BTW, I don't use OPNsense's DHCPv6 server for assigning addresses, so no address range is specified. Downstream routers get their WAN addresses via SLAAC. No idea whether that's relevant, but I better mention it.)

Thanks,

Maurice

[Maurice]

I did some lab testing today with two freshly installed OPNsense VMs. Router A is delegating prefixes via its LAN interface, router B is requesting a prefix via its WAN interface (connected to A's LAN interface). B gets a prefix from A easily, but A only adds a route to the delegated prefix under very specific conditions: An address range must be specified in A's DHCPv6 server AND B's DHCPv6 client must be configured to actually request a WAN address.

If A's DHCPv6 server is used for PD only (no address range specified) OR B's DHCPv6 client is configured to only request a prefix (not an address), then A will still delegate a prefix, but won't add a route pointing to it.

I consider this to be a bug. Prefix Delegation should work independently of assigning addresses via DHCPv6. It is quite common to use a router's DHCPv6 server for Prefix Delegation only and to use a separate machine (e. g. Active Directory integrated Windows Server) for assigning IPv6 addresses (or to simply use SLAAC only).

Should I create a bug report on GitHub?

[marjohn56]

IMHO it is working the way it should...

If you request a prefix, and this is given you using dhcpv6, then the allocating router needs to know the route to the prefix. If the requesting router does not request a stateful address then the allocating router is not going to know where to send packets destined for the prefix subnet.

https://thenetworkway.wordpress.com/2015/06/23/ipv6-prefix-delegation-what-is-it-and-how-does-it-going-to-help-openstack/

[Maurice]

I respectfully disagree. The delegating router always knows where to send packets destined for the delegated subnet to: The address where the PD request came from.

• This issue is specific to OPNsense. Other delegating routers handle PD-only just fine. They route the delegated prefix to the requesting router's link-local WAN address.
• OPNsense's DHCPv6 client has an option to only request a prefix, not an address. This currently only works if the delegating router is a third-party box, but not if it's an OPNsense router, too.
• The current behavior makes it impossible to deploy PD in networks which already run a third-party DHCPv6 server for address assignment. A Windows Server running DHCP with Active Directory integration is a real world scenario found in many places. So it must be possible to use separate DHCPv6 servers for address assignment and PD.
• RFC 3633 says: "Prefix delegation with DHCP is independent of address assignment with DHCP.  A requesting router can use DHCP for just prefix delegation or for prefix delegation along with address assignment and other configuration information."

[marjohn56]

OK, well there's a manual route command in FreeBSD, if you can get it to work with Link-local addresses then let me know how and I'll make it work. I've tried this afternoon and spent some time going through the man pages and I cannot see how it can be done...

I've created a routine that pulls the requesting link local address from the dhcpd log and ties that to the allocated prefix.... all that's needed now is someway of adding a route.

Franco?

[Maurice]

Thanks, great work!

Here is what I just tried on the delegating router (via Web GUI):

• Add a new gateway: Interface LAN, Address Family IPv6, Name Test_PD, Gateway fe80::215:5dff:fe12:3456%hn0 (the requesting router's link-local WAN address)
• Add a new route: Network Address 2001:db8:feed:bf00::/56, Gateway Test_PD
• The route now properly shows up in the routing table. I have yet to test whether it actually works. It works! A test client connected to the requesting router's LAN interface has IPv6 Internet access.

It is important to specify the correct zone identifier (%hn0 for the first LAN) when creating the gateway. Without it the created route won't show up in the routing table.

So manually adding a route using a link-local address as gateway works. Now this "only" needs to be done automatically using the routine you created. I'm not exactly sure how the steps in the Web GUI translate into using FreeBSD's manual route command, but maybe it helps?

[marjohn56]

So which has a routing issue, Primary or Secondary... I would have thought it should be the primary, but after reading your message I'm not sure.

[Maurice]

Correct, primary, which is the delegating router (router A in my example). That's where I manually created the route (which should be created automatically).

No issue on the requesting router (router B in my example).

[marjohn56]

I'm confused as to why you needed to add a LAN gateway?

.... after reading what you wrote again...

No I'm not, just being obtuse...

[marjohn56]

And it appears this is where the issue is...

When a V4 request comes it, dhcpd tells us which interface it came in on, when it gets a v6 requst it does not..

Here for example is a v4 request ...

Code: [Select]

Mar 28 18:25:37 dhcpd: DHCPACK on 192.168.1.115 to 00:0c:29:b3:b0:d4 (OPNsense) via bridge0
Mar 28 18:25:37 dhcpd: DHCPREQUEST for 192.168.1.115 from 00:0c:29:b3:b0:d4 (OPNsense) via bridge0
And here is the V6 request from my test VM to my primary router...

Code: [Select]

Mar 28 18:25:41 dhcpd: Sending Reply to fe80::20c:29ff:feb3:b0d4 port 546
Mar 28 18:25:41 dhcpd: Reply PD: address 2a02:****:****:2::/64 to client with duid 00:01:00:01:21:da:2b:6d:00:0c:29:d2:7e:2f iaid = 0 valid for 7200 seconds
Mar 28 18:25:41 dhcpd: Request message from fe80::20c:29ff:feb3:b0d4 port 546, transaction ID 0x3FE76000
Mar 28 18:25:40 dhcpd: Sending Advertise to fe80::20c:29ff:feb3:b0d4 port 546
Mar 28 18:25:40 dhcpd: Advertise PD: address 2a02:****:****:2::/64 to client with duid 00:01:00:01:21:da:2b:6d:00:0c:29:d2:7e:2f iaid = 0 valid for 7200 seconds
Mar 28 18:25:40 dhcpd: Solicit message from fe80::20c:29ff:feb3:b0d4 port 546, transaction ID 0xE039DD00

It's fine if you only have one LAN interface, if you have more than that it's an issue, so I'm not sure how we can get around this.

[Maurice]

Sorry for the delay.

You're right, a simple workaround (reading the dhcpd output) most likely won't work.
It seems that routes for delegated prefixes are currently created by parsing the DHCPv6 lease file and matching address assignments (IA_NA) to prefix delegations (IA_PD). I think this was implemented pre-OPNsense, probably as some kind of "quick fix to get it working somehow". This seems fundamentally broken to me since it relies on the requesting router also requesting an address. Also, it is considered best practice to use link-local addresses as next-hop on links between routers, not Global Unicast addresses.

Others solved this by patching the ISC DHCP server so it makes link-local addresses of requesting routers available to custom hooks:
https://github.com/mpalmer/isc-dhcp

See also this very interesting discussion:
http://bird.network.cz/pipermail/bird-users/2017-April/011152.html

Unfortunately porting this to OPNsense is beyond my capabilities, but I think it should be put on the roadmap. Having reliable Prefix Delegation is becoming more and more important.