No null route is created for delegated prefix

[maurice-w]

When a DHCPv6 WAN interface gets delegated a prefix, a null route should automatically be created for this prefix. This is best practice to prevent routing loops and is implemented in most routers.

Example: ISP delegates prefix 2001:db8:1:a00::/56. OPNsense uses prefix ID 1 (2001:db8:1:a01::/64) for its tracking LAN interface. A host in this LAN sends packets to an address in any other (unused) subnet of the delegated prefix (e.g. 2001:db8:1:a02::/64). OPNsense routes these packets to the ISP who routes them back to OPNsense which routes them to the ISP... and so on. This can easily be reproduced using traceroute.

If you have a static prefix you can manually add a null route, but this is not possible with dynamic prefixes.

Just for reference, the RFCs which actually mandate this:

RFC 7084 (Basic Requirements for IPv6 Customer Edge Routers):

Any packet received by the CE router with a destination address in the prefix(es) delegated to the CE router but not in the set of prefixes assigned by the CE router to the LAN must be dropped. In other words, the next hop for the prefix(es) delegated to the CE router should be the null destination. This is necessary to prevent forwarding loops when some addresses covered by the aggregate are not reachable [RFC4632].

RFC 4632 (Classless Inter-domain Routing (CIDR)):

A router that generates an aggregate route for multiple, more-specific routes must discard packets that match the aggregate route, but not any of the more-specific routes. In other words, the "next hop" for the aggregate route should be the null destination. This is necessary to prevent forwarding loops when some addresses covered by the aggregate are not reachable.

[fichtner]

I can try, but I am unsure that we're able to hook into the right spot easily. All guidance welcome.

[fichtner]

@maurice-w so what does this delegated prefix null route look in a real world example? Because if we have to generate routes for all unused subnets that is going to be quite a bit of routes to be generated and set and to be kept in sync, especially tricky if we have PD to downstream as well...

[maurice-w]

@fichtner, we only have to add one null route when we get delegated a prefix (and remove that route when the lease for the prefix delegation expires). Example:

• OPNsense gets delegated 2001:db8:1:a00::/56 from upstream (ISP).
• It should add the null route 2001:db8:1:a00::/56 via ::1 to its routing table, so any packet with a destination address in this prefix gets discarded.
• It uses prefix ID 1 for a tracking LAN interface. It adds 2001:db8:1:a01::/64 via link#n to its routing table. This route is more specific than the null route, so routing to the LAN works.
• It delegates 2001:db8:1:ab0::/60 to a downstream router. It adds 2001:db8:1:ab0::/60 via <downstream router WAN address> to its routing table. This route is more specific than the null route, so routing this prefix to the downstream router works.

Cheers Maurice

[IsaacFL]

An interim solution would be to allow Firewall/Alias to be used as the Network Address in the System: Routes: Configuration.

In pfSense I would create an Alias manually for my /56 I would receive from my ISP called NET_IPV6_PREFIX.

I would then create a route using NET_IPV6_PREFIX as the network address to Null6-::1, so if my prefix was changed, then I could manually change it at one place in the Alias and my route would get update.

[fichtner]

@maurice-w hello, are you ok? Is the current implementation working for you?

[maederm]

@fichtner: I don't currently see an automatic null route for the delegated IPv6 prefix with 22.7.9.

[maurice-w]

Hey @fichtner, sorry for leaving you hanging. Life happens, again. I'll eventually be back and investigate further. For now I can only confirm that it doesn't work for me either.

Cheers Maurice

[fichtner]

Hello @maederm @maurice-w :)

It hasn't been added to 22.7.x since we had a good testing loop and final confirmation was missing.

I'm thinking all the changes @maurice-w and I did regarding SLAAC on WAN are good for 23.1 to be released, with a very slim chance to be added to 22.7.x at this point in time.

FWIW, I created a backport for this particular change here which works on 22.7.9:

# opnsense-patch 7d66e10

Cheers, Franco

[fichtner]

@maederm chirp chirp ;)

[maederm]

@fichtner I just tested the patch and rebooted. There is no null route installed for my prefix.

[fichtner]

If there is a prefix it adds the route as well. This part is easy to verify. If there is no prefix the code is probably not there (patched twice?).

# ifctl -p6 -i <WANdev>

It should print your prefix as a first step.

[maederm]

This prints my prefix (redacted)

# ifctl -p6 -i igb0
2a02:dead:beef::/48

[EDIT] Also the patch seems to be applied, as I see the route add command on line 210.

[fichtner]

So this would add the null route?

# ifctl -p6 -i igb0 -da 2a02:dead:beef::/48

The conclusion is that perhaps it works but the routing table is flushed later on while the prefix is still active.

[fichtner]

Possibly by any call of...

# /usr/local/etc/rc.routing_configure

But I can't seem to confirm that here for now. Null route sticks.

[maederm]

So this would add the null route?

Yes, it does.

# ifctl -p6 -i igb0 -da 2a02:dead:beef::/48
route: route has not been found
delete net 2a02:dead:beef::/48 fib 0: not in table
add net 2a02:dead:beef::/48: gateway ::1

[maederm]

Well I know tested it again with another reboot and this time the route was installed.

[fichtner]

Let's close this and keep the target of 23.1. Thanks for testing!

[maederm]

@fichtner Thanks, I just verified again and couldn't reproduce the instability.

Instead of route add -${AF} ${CONTENT} ::1 I would do route add -${AF} ${CONTENT} ::1 -blackhole. Without using -blackhole opnsense sends TTL exceeded packets. This flag is also used when you create a null route with the webinterface.

[fichtner]

@maederm thanks again, good point about -blackhole, added in b8e9bde

[maurice-w]

Just a quick heads up: I noticed this being mentioned as a new feature in the 23.1.r1 changelog, but it still doesn't work for me in 23.1.r_6. Not sure whether it's an issue with my specific setup. Are there any other reports that this actually works?

[fichtner]

It's there on my end:

2003:cd:xxxx:xxxx::/61            ::1                           UGSB        lo0

[maurice-w]

Quick test: On my system, the route gets created when I manually trigger a DHCPv6 reload. But it doesn't get created after a reboot. Probably one of these nasty timing issues.

[fichtner]

DAD timing again? :)