NPTv6: add dynamic source addresses via track interface

[bimbar]

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

• [X] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• [X] I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Is your feature request related to a problem? Please describe.

The problem hear is small site multihoming. It's very nicely described here: https://blog.ipspace.net/2010/12/small-site-multihoming-in-ipv6-mission.html and can pretty much only be done with local ULA addresses and some sort of address translation toward the WAN interfaces. Right now it can only be done via NA(P)T66, which is the very same as NA(P)T44, and I don't think we want that anymore. Now the implementation problem with it is that with NAT you can do the following:

nat on WAN inet6 from SOME_IP_RANGE to any -> (WAN:0) port 1024:65535

while with NPT (binat) you have to specify a source and a destination network, so some sort of integration into interface newwanipv6 will be necessary.

Describe the solution you like

I would like a "Track Interface" External IPv6 Prefix Option in addition to static External IPv6 Prefix in NPTv6, pretty much just like it is in the interface configuration dialog. Specified would be:

• IPv6 Interface
• IPv6 Prefix ID

Describe alternatives you considered

Oh so many ones, but none of them work. The best one in clean IPv6 terms so far is to use two independent routers each with their own GUA prefixes which the independently advertise into LAN, only that works only if RFC3484bis is implemented or asymmetric routing is achieved. The one that works is to just do it like in IPv4, with local addresses for LAN, and NA(P)T on the outside interface, but that's hardly the right solution.

Additional context

There's even a very nice RFC for that, namely https://datatracker.ietf.org/doc/html/rfc7157 "IPv6 Multihoming without Network Address Translation" but even they concede that NPTv6 is probably needed for now. For static prefixes this should work nicely with static NPTv6, but if the prefixes are dynamic, it falls down.

[bimbar]

But I'm not sure if that's even possible, it depends on the dhcpcv6 daemon telling someone which prefixess it was assigned.

[cnbatch]

Indeed, this feature should be fully supported by OPNSense ASAP.

FreeBSD itself supports such operation with IPFW, see the part of 'IPv6-to-IPv6 NETWORK PREFIX TRANSLATION (NPTv6)': https://www.freebsd.org/cgi/man.cgi?query=ipfw&sektion=8&format=html

This feature was added on Oct 30 2018: https://reviews.freebsd.org/D17765 by https://github.com/opnsense/core/issues/2544#issuecomment-797369686

One can use a command like ipfw nptv6 NPT create int_prefix fd24:ca16:8eb0:5ab6:: ext_if em0 prefixlen 64 to create NPTv6 mappings and let the system monitor the change of IPv6 addresses.

This IPFW feature can also be used in command line console of OPNSense, but not yet supported in Web Interface.

[AdSchellevis]

we use pf(4) (https://www.freebsd.org/cgi/man.cgi?pf(4)), sounds similar to https://github.com/opnsense/core/issues/4923, waiting for someone to properly document the feature (https://github.com/opnsense/docs/pull/330#issuecomment-839531339) before any code will be merged.

[bimbar]

Not quite the same, the one is about dynamic firewall rules, the other about dynamic NPTv6 rules

[AdSchellevis]

which is about the same concept, addresses should follow dynamic addresses for which aliases might be used.

[bimbar]

It likely needs much the same infrastructure in the backend.

[marjohn56]

@bimbar - dhcp6c puts the GUA address on the interface, so you can get the prefix from the GUA address. The trick I think, if I understand NPTv6 correctly - Only looked at this 30 minutes ago - is to assign a ULA address to the interface ( alias is there for that already ) and to use dhcpdv6 and radvd to hand out ULA addresses on the LAN(s). Once you have that done, then would it possible to just NPTv6 the LAN ULA addresses to the GUA prefix for that interface?

[bimbar]

The prefix for the WAN interface is different from the prefix we need. Also, this prefix is not going to be set on any interface. It's not that simple.

[marjohn56]

You misunderstood me I think. I am talking about the LAN(s) not the WAN. dhcp6c assigns the addresses to the interfaces, the GUAs that is. I quote you

But I'm not sure if that's even possible, it depends on the dhcpcv6 daemon telling someone which prefixess it was assigned.

That information is already available, In /tmp there is also another file, my wan is igb0, therefore the file is called igb0_pdinfo, that will give you the prefix and size. If it's any use I also have a versiion of dhcp6c that will give you the prefix that is assigned to the LANs, but as I said, that info is aleady available.

[bimbar]

Ok, so I have a hypothetical LAN interface with Track Interface WAN and offset 4. Now I want NPTv6 to translate the source prefix to the prefix this hypothetical interface would have been assigned (but it has been given a ULA prefix).

[marjohn56]

It will also have been given a GUA address, you cannot stop dhcp6c doing that - unles we have some sort of virtual interface, but that's a different story. You can add an Alias to give a ULA address, BUT, dhcp6d and Radvd will give out the GUA addresses. If that was altered so that they gave out the ULA addresses then packets coming back to the LAN interface would have ULA addresses and, in theory, would hit the NPTv6 rule.

[bimbar]

Why can I not stop dhcp6c giving out GUAs? I can configure the interface with static IPv6 ULA. Giving out GUAs makes the whole feature redundant.

[marjohn56]

Just messing around to prove a point..

So I am using Track Interface, my test router has GUA prefixes on its LANs.. All OK I added a VIP to the LAN of the test router using a ULA address. dhcpdv6 on that interface is disabled, I have also commented out the relevent parts of dhcpd.inc so that no GUA addresses are given out, but ULA ones are, this is what radvd.conf looks like:

interface igb1 { AdvSendAdvert on; MinRtrAdvInterval 200; MaxRtrAdvInterval 600; AdvLinkMTU 1500; AdvDefaultPreference medium; prefix fc01:1::/64 { DeprecatePrefix off; AdvOnLink on; AdvAutonomous on; }; RDNSS 2a02:6b67:605d:3200:4262:31ff:fe00:c1b0 { }; DNSSL localdomain { }; }; It's still using the RDNSS but that doesn't matter in this case.

Then I added an NPTv6 entry, using the GUA /64 prefix from the test router LAN. WAN interface selected. My PC I set to pick up a dhcp6 address and looks like this:

Ethernet adapter traceLAN Test:

Connection-specific DNS Suffix . : localdomain IPv6 Address. . . . . . . . . . . : fc01:1::2e0:4cff:fe67:7b54 Temporary IPv6 Address. . . . . . : fc01:1::c9a6:14fc:c5b:207c Link-local IPv6 Address . . . . . : fe80::2e0:4cff:fe67:7b54%17 IPv4 Address. . . . . . . . . . . : 192.168.1.100 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : fe80::4262:31ff:fe00:c1b0%17 192.168.1.1

And the result is:

C:\Users\marti>tracert -6 www.google.com

Tracing route to www.google.com [2a00:1450:4009:817::2004] over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms OPNsense.localdomain [fc01:1::1] <- test router LAN 2 <1 ms <1 ms <1 ms xxxx:xxxx:605d:0:20e:c4ff:fed2:8143 <- Primary router LAN 3 2 ms 1 ms 2 ms xxxx:xxxx:0:89::1 <- Upstreeam 4 2 ms 2 ms 2 ms 2a02:6b60:0:1:2::66 5 * 2 ms * xge-0-0-0-8.edge1.ld8.lon.network.as201838.net [2a02:6b60:0:1:1::66] 6 3 ms 3 ms 2 ms 2a02:6b60:0:1:3::62 7 * 2 ms * 2a00:1450:80f9::1 8 2 ms 2 ms 2 ms 2001:4860:0:1::41aa 9 * * 2 ms 2001:4860:0:1::248b 10 2 ms 1 ms 1 ms lhr25s26-in-x04.1e100.net [2a00:1450:4009:817::2004]

Trace complete.

So it works, perfectly possible to use the GUA Prefix on the LAN. And If instead of using an address as the external prefix it could use an alias, in the same way as the firewall rules we were working on earlier this year, then that would solve a few problems.

[marjohn56]

Let's take this a step further. I see the need for the following:

• Ability to only enable ULA address handouts in dhcpdv6 and radvd.
• Ability to select the LAN GUA prefix ( as an alias ) in NPTv6
• Abillity to select the LAN ULA prefix in NPTv6

@fichtner & @AdSchellevis - Does this fit the bill?

[bimbar]

Now I'm confused, as far as I can see in your example, you have no GUA prefix on LAN, but only an ULA prefix, yet you write in you conclusion that a GUA prefix on LAN works perfectly.

Anyway, what you tested is pretty much what I was thinking of, only you want to sort of virtually assign the GUA prefix to LAN while not advertising it, which would also be a way to implement it, I guess.

[marjohn56]

That LAN is my PC's LAN, not the LAN of the router. That looks like this. Note I've change the ULA address to fc00 since yesterday.

igb1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=802028<VLAN_MTU,JUMBO_MTU,WOL_MAGIC> ether 40:62:31:00:c1:b0 inet6 fe80::4262:31ff:fe00:c1b0%igb1 prefixlen 64 scopeid 0x2 inet6 fc00:1::1 prefixlen 64 inet6 xxxx:xxxx:3200:4262:31ff:fe00:c1b0 prefixlen 64 inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet autoselect (1000baseT ) status: active nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

It's the way I'd prefer to do it. It makes life much simpler IMHO.

[bimbar]

@bimbar - dhcp6c puts the GUA address on the interface, so you can get the prefix from the GUA address. The trick I think, if I understand NPTv6 correctly - Only looked at this 30 minutes ago - is to assign a ULA address to the interface ( alias is there for that already ) and to use dhcpdv6 and radvd to hand out ULA addresses on the LAN(s). Once you have that done, then would it possible to just NPTv6 the LAN ULA addresses to the GUA prefix for that interface?

Going back to your initial statement, I get what you want to do there, but, if you have a GUA and an ULA on the LAN, but advertise only the ULA, and translate that over to the GUA, what use is it to configure said GUA on LAN if it's not used. It's only used as a NAT pool and as such should not be configured on any real interface.

[marjohn56]

What about ISPs that don't give a GUA on the WAN? What if you want multiple LANs etc? The fact is yes you can get the prefix and size from a file that dhcp6c already creates, but the ability to NPTv6 to the GUA on the same LAN makes it simpler in other ways too. There are many ways to skin a cat.

[bimbar]

What about ISPs that don't give a GUA on the WAN? What if you want multiple LANs etc? The fact is yes you can get the prefix and size from a file that dhcp6c already creates, but the ability to NPTv6 to the GUA on the same LAN makes it simpler in other ways too. There are many ways to skin a cat.

You don't understand, instead of configuring some interface as "Track Interface WAN offset 1", you would configure the NPTv6 Destination Prefix as "Track Interface WAN offset 1".

[marjohn56]

I DO understand I just see benefits of using the real interface. I am well aware that if you know the prefix that's been obtained you could just use that.

[ivwang]

Let's take this a step further. I see the need for the following:

• Ability to only enable ULA address handouts in dhcpdv6 and radvd.
• Ability to select the LAN GUA prefix ( as an alias ) in NPTv6
• Abillity to select the LAN ULA prefix in NPTv6

@fichtner & @AdSchellevis - Does this fit the bill?

This really sounds nice and what I am looking forward to have. Any chance to see it in next few releases? Finger crossed.

Thanks Ivan.

[AdSchellevis]

(from https://github.com/opnsense/core/issues/5284#issuecomment-947566519) we use pf(4) (https://www.freebsd.org/cgi/man.cgi?pf(4)), sounds similar to https://github.com/opnsense/core/issues/4923, waiting for someone to properly document the feature (https://github.com/opnsense/docs/pull/330#issuecomment-839531339) before any code will be merged.

As long as any change in this area fits the boundaries given earlier, I don't mind that much, I just would advise to keep it simple.

We all seem to get lost in this region quickly, which is only solvable if anything we do add will be explained unambiguously.

Speaking for myself (and likely @fichtner as well), I'm not planning to spend time on this before it's absolutely clear, already spend quite some time preparing everything in https://github.com/opnsense/core/tree/FR_4923, after which everything kept circling back.

[bimbar]

I'd propose merging some implementation of something soon, rather than wait for something perfect which may never come.

All with the understanding it may change completely as soon as its shortcomings are understood.

But if nothing is merged, there is no base which can be argued in a wider audience.

Release early, release often.

[AdSchellevis]

Not if the fundamentals are unclear, it's rather simple, someone should write it down (design) before starting to build anything, to prevent future issues impossible to fix further down the road. We spend years refactoring a lot of madness and believe me, trouble starts with vague objectives.

[bimbar]

Well, there's enough ideas, someone ultimately has to decide what to actually do.

[ivwang]

Is it possible to first develop Martin's implementation into a plugin, as a mean to discover what is lacking (if any) down the road?

For my use-case, it's primarily to deploy opnsense and IPv6 reliably with upstream ISPs changing IPv6 PD assignment frequently, in that Insulating LAN side address ranges from those ISPs by NPT and ULA.

So Martin's implementation that

1. enables dhcp6d/radvd to advertise ULA
2. allows user to specify NPT by mapping between ULA prefix and IPv6 PD (tracking WAN)
3. refreshes NPT translation rules automatically when tracked IPv6 PDs are changed. fits the bill. If anything not explicitly stated, is that assigning ULA directly to LAN side physical interfaces without the need to create a virtual one.

Thanks Ivan.

[AdSchellevis]

Is it possible to first develop Martin's implementation into a plugin, as a mean to discover what is lacking (if any) down the road?

I assume you mean the work me and Martin did which is waiting in https://github.com/opnsense/core/tree/FR_4923, but no, you can't easily move that to a plugin as you don't have anything to plug it into. (yes, you can develop a plugin offering this functionality, but I don't expect anyone would like to spend the amount of time needed to convert this to a stand-alone feature).

As soon as the concerns in the doc's PR are cleared (https://github.com/opnsense/docs/pull/330), we can start moving code in, as I've mentioned earlier as well.

[marjohn56]

@AdSchellevis - No, he means the ability to select an address range to use within dhcpdv6. At present you can only create one range within dhcpdv6 / radvd, thus is you use tracking you can overide and make your own range but if you have a ULA alias on that inferface you cannot use that, as the existing code picks the GUA. What it would need is the ability to force the range entered so that the sanity check is overridden. I do not see the need to be able to have both ULA and GUA ranges handed out by dhcpdv6, but where both exist on an interface, then the ability to select or specify the range would be useful. I did a bit of hacking and forced the ULA in dhcpdv6 then used NATv6 to translate the ULA to the GUA prefix on the LAN, it worked nicely. It sort of comes back to being able to track the GUA again and automagically compensate for a changing pd.

[AdSchellevis]

@marjohn56 ok, clear, sounds like a no as well when it comes to building a plugin.

[marjohn56]

Yes agreed, but I'm working on a simpler solution... Really, it's just a case of being able to override the auto prefix addition that happens when using override on the tracked interface. So that's the path I am taking, I'm playing with it later this afternoon as it happens.