firewall: global prefix in rules needs to be changed manually when IPv6 upstream prefix changes

[RyuunoAelia]

While playing a bit with NPTv6 I found a a workflow issue. The main and only reason to use NPTv6 is to avoid changing your local configuration (firewall rules, etc) when your upstream changes.

However, as things are done in opnsense right now, you need to manually update the NPTv6 rule each time the upstream changes.

This is fine for cases where you have complete control over when the prefix change occurs (multi-homed setup, etc). However, when the prefix may change without your knowledge (say a 6rd setup, or ISP providing ipv6 connectivity with short lived DHCP leases), having to manually update the rule painful.

I understand selecting the IPv6 might be problematic to implement in general. An interface may have multiple IPv6 at a point in time (even if you ignore link-local addresses). So maybe having a way to select on an interface if this interface will have dynamic NPTv6 rules might be a more straightforward flow for setting up things. But since I do not know much about the internals of the UI, I cannot give a pertinent insight.

My full context is described in #2538.

[fichtner]

This is also useful for DHCPv6 and SLAAC, but will require more tinkering.

[marjohn56]

With the manual addition we did to dhcpd6 it should change the prefix as the config for dhcpd6 has is re-written and re-loaded, that was always the bugbear, but I think that side is working. Whether it works when not using manual override (default) I did not test.

[fichtner]

Not for the rules currently. It doesn't allow tracking the interface prefix change.

[marjohn56]

So maybe we try splitting the rules into prefix/suffix..,, Alias for Prefix+suffix. It does make it complex for the user too, but that's the problem with a changing prefix, it's not for the faint-hearted.

[fichtner]

We already have a larger change in that area to make 6RD usable for "inet6" type rules and need to see if that is alright before we stack another layer on top, but generally an automatic prefix adaption option should be possible.

[chris42]

Having similar troubles discussed with marjohn56 in https://forum.opnsense.org/index.php?topic=9438.0

Being completely obvious on how technically the DHCPv6, SLAAC, RADV and the firewall works: Since the clients in the network negotiate their IPv6 couldn't Opnsense create a central register in the DNS, that is build during the negotiation process? This would keep the changing IP information centralized and up to date in realtime. (This would cover prefix changes as well as changes by e.g. privacy extensions) Then you could use that register with Hostname in the firewall rules?

Basically using the Alias, but not having a 5min delay between resolving the hostname, but accessing the register (which should be up-to-date) of IPv6s in the network?

[fichtner]

Since we need to force a rules update on IP changes it's probably better to read the current IPv6 and merge the prefix accordingly and reload the rules. That should cover 99% of the use cases. The only tricky thing is integrating this logic and how to present it to the user (if applicable).

[chris42]

I would put an option next to the prefix delegation option to enable automatic prefix update to firewall rules. Then have in the Firewall rule next to the IP window an option to use delegated prefix. IP window then only holds the suffix part. Then you could control if you actually want to use that feature next to the prefix delegation and then control per firewall rule, if it is a rule, that uses this feature. Just to mark it: opinion.... ;-)

[RyuunoAelia]

To answer the "use hostname in rules" remark. It is not recommended by pf (the firwall software) documentation (because in general the firewall is started before any other services thus there is no DNS available to query).

The thing is, we don't need a convoluted thing like DNS, since opnsense (and pfsense for that matter) already regenerates all firewall rules when the IPv4 changes via DHCP, so we only need to have a way to map the IPv6 change too. With IPv6 it makes sense to split the network part and the machine part of addresses I think. Event if both parts of IPv6 addresses can be dynamic since the internal network controls the machine part we can forget about it, and only concerntrate on managing changes in the network part (A.K.A. prefix).

The way I see things, you don't even need to change that much to UI, just make the IPv6 firewall rule editing look more like the IPv4 rule, with the drop-down list for Type of Source/Destination with a "Interface subnet" option and an optional "machine part of address" field or something like that. Then there's a bit of a tricky mangling of the input to regenerate the full address to pass to the pf command to do in the *.inc files.

[staeglis]

What's the current state of this issue? Will this be really solved in 19.7?

[cpw]

Is there anything I can do to help and or test anything?

[chris42]

This is quite disappointing. Together with the other IPv6 changes I was really looking forward to the 19.7 Now it is another 6 month.

[fichtner]

I'm happy to say to be disappointed by disappointment for lack of hands on deck on issues that are disappointing to be left disappointed in the first place. If nobody cares enough the community will go nowhere and disappointment is really displaced because there is a general lack of drive.

[chris42]

Than that is something that should be made public, that developers, funds, etc. are needed.

For me as a user, I cannot tell. I can only see the features that are rolled out and what is pushed back. IPv6 sadly/disappointingly the latter.

[fichtner]

No, as a user you can do better than simply share your subjective disappointment, especially on a major release day where a couple of things have been accomplished despite said disappointment.

[chris42]

I agree that the timing could have been better tomorrow. Just see that I happily waited and tinkered with my setup for over a year now to get a proper IPv6 support. Something I cannot solve on my own, but need a developer to do. Until I saw your release E-Mail, I only knew it was tagged for 19.7 for half a year and came here to see, that it was moved 2 weeks ago.

So if you ask me to do better in communication, I will happily try to. But then it follows, that I ask you to do better in it as well and look into proper expectation management and tell us what Opnsense would need as support.

So I apologize for throwing my unfiltered disappointment out there. Please see it, as how much I like Opnsense and how much I want it to succeed. (there is no irony or sarcasm here)

[fichtner]

Thanks for the explanation. Please consider me responding immediately to questions as "expectation management". I don't know what "proper" is, it looks to be in the eye of the beholder. For myself "proper" would mean transparent and precise.

The problem we see is we have about 150 open tickets at any point in time. Some of them are support questions, setup issues and others are bugs and features. For 19.7 we tackled 112 of bugs and features alone. Many if not all of them are more important than this, probably due to a mix of complexity, previous state and underlying code base that does not recognise the shifting prefix fact that the ISP for all intents and purposes only does to annoy customers as there is no real need for it.

There is also private life and these things naturally do not help with having contributors contribute more.

Lastly, we have this bug tracker not as a sort of vending machine where anyone can press a button and a feature drops out in the next version. We use tagging to make clear priorities. Tagging a milestone is good. It doesn't necessarily mean work will be finished in time. Some features took years to pull off. All we really have is time and I appreciate all suspending of judgement on these subjectively pressing matters.

Cheers, Franco

[staeglis]

Is there still a realistic chance to see this feature in 20.1?

[fichtner]

Planning is provided as "best effort" for the next upcoming release. In this particular case, I don't think this will make 20.1.

[chris42]

To maybe prevent the same issue as with 19.7: If this is not making 20.1, the milestone should be removed, just for transparency and precision.

[BigSnicker]

Don't have the expertise to help, but I donated some cash and would love to see this feature to help out vs. my insane prefix-changing, 10m subscribers, largest-in-Canada ISP (Rogers).

Found this thread from https://forum.opnsense.org/index.php?topic=11011.0

[fichtner]

@chris42 my best contribution here for the moment is to keep this in the milestone queue otherwise the ticket will be dropped eventually if nobody works on it. the only thing that helps more is code...

[marjohn56]

@fichtner - Let's try and work out something for this, and other related issues to do with dynamic IPv6, we've got quite a long way towards resolving this is and related issues with the work we did early last year with the dynamic manual dhcpd6 changes.

It would seem logical to have a single function somewhere that gets called and updates the fw, unbound and others when the prefix changes; possibly a unified function that that gets called whether it's static or dynamic and does the work of all the different calls that are presently in place scattered about other files. I should have some time to play with this again and come up with ideas you can pull to pieces until we find one that fits.

[AdSchellevis]

@marjohn56 sorry for stepping in, but would it be possible to construct a test setup simulating the issue or issues (two OPNsense xml's and steps to reproduce)?

I'm getting the feeling we're trying to solve multiple (possibly related) issues at once, which has a high risk of ending up in patchwork. There likely is some sort of rfc beneath a lot of this, it would be good to stay as close as possible to how things are originally intended to work (unwinding these things later has the habit of ending up in a lot of work and new user challenges)

[marjohn56]

Don't be sorry, more on deck the better, many hands make light work ( or too many chefs spoil the broth! ). Many of the issues are related, and to do with manually assigned dhcpd6 with a tracking interface. It was a feature a lot of users asked for and we got that bit working early in 19.7.1, what we missed were the associated requirements to change a few things in Unbound etc when we have a change, static mapping is one that comes to mind. It's not my intention to try and get a rapid fix out for 20.2, but to look at that area as a whole and see if we can push it forward in a way that we have a single inc file that contains the glue that brings together the calls to the various other functions needed when an interface prefix changes. That way it should be easier to maintain going forward.

The error I/we made before was not realising the chain reaction that would happen in the likes of unbound etc. The firewall area is a baby you can bounce on your lap. :)

What we need first is a framework of what needs to be included/updated when a prefix changes.

[Vagor96]

Would it be possible to merge the fix described in #3657 as a workaround? The DNS entries could then be used in firewall rules until a better system is in place. At the moment the firewall is really barely usable for IPv6 on connections with dynamic prefix.

[HikariWS]

I had described my situation on https://forum.opnsense.org/index.php?topic=19405.0 and believe that this would help me a lot!

tnx anybody who's making this happen :)

[spi43984]

Not sure I understand that right.

This ticket #2544 is about the feature to use dynamic prefixes in rule, e. g. use some variable for the current prefix in rules. That feature was planned for 21.1.

The ticket #4642 is about the missing prefix in DNS replies.

If #4642 was fixed DNS queries would work. I could use DNS names in firewall rules then but the issue from this ticket #2544 still would exist and there wouldn't be any way to use firewall rules with IPv6 addresses and dynamic prefixes.

[fichtner]

2544 It was planned for the next milestone we had... we only have a milestone for the next version. We can't tackle all the things all the time on core time and so now we have a "community" milestone to better reflect the lack of outside contributions regarding the request.

4642 yes

If #4642 was fixed DNS queries would work. I could use DNS names in firewall rules then but the issue from this ticket #2544 still would exist and there wouldn't be any way to use firewall rules with IPv6 addresses and dynamic prefixes.

Not really. The prefix change still breaks a setup easily so you have the DNS leases on the old prefix even when fixed to use the prefix when it was last configured.... In the end, the shifting prefix is an annoyance that will not go away easily even if a lot of work is put into dodging its effects from our end.

[spi43984]

Ok, thanks. Understood. Dynamic prefixes are an annoyance.

Is there a workstream (or some ticket) though looking into how to technically best support dynamic prefixes? I don't expect all Internet providers to switch to static prefixes for all their customers.

[froogl]

If I understand this correctly the actual problem is that, contrary to other firewall solutions out there, FreeBSD's packet filter (pf) does neither support suffix matches nor outgoing interface matches. What we'd actually need is support for firewall rules like in Linux, just like this (nftables example):

nft add rule inet filter iifname $WAN oifname $LAN ip6 daddr & ::ffff:ffff:ffff:ffff == ::f2e5:3a81:15cf:8e16 tcp dport ssh accept

That rule completely ignores the prefix and only matches based on interface names and IPv6 tokens/suffixes. I think FreeBSD's ipfw2 at least has support for matching the outgoing interfaces, however I am not sure about IP suffix matches. In the end this is a limitation of the underlying operating system (BSD) which is showing it's age in this case, as it's lacking support for features required by modern internet protocols and their implementation in the real world.

I don't think this issue can be easily resolved at the OPNsense project level. It could only be worked around by a hell of shell scripts and triggers (which the prefix handling kind of is already) but a clean solution will probably not be achievable with the current state of the FreeBSD networking stack.

So in the end there are a couple of options:

1. Go the scripting way (e.g. reloading firewall rules on prefix changes). This is a quick, easy and hard to maintain solution. And it's ugly as hell, as it's just working around the core problem.
2. Invest a lot of time in improving pf, so it actually supports firewall rules with suffix matches and interface matches. If I understand the architecture of pf correctly, especially the interface matching part is out of scope of the software. If I am correct with this one this would definitely be a deal-breaker.
3. Switch to one of the other firewalling frameworks which FreeBSD offers. Not sure if there is any which actually supports the required features.
4. Switch to a completely new OS base, such as Linux. This way we could get a more advanced and modern networking and firewall stack. A neat side-effect would also be much better driver support in general and better throughput for many drivers.

[spi43984]

I'm not much into BSD's packet filter so I can't tell if this might be an approach or not: with pfctl it seems to be possible to rewrite the prefix after it changes: https://forums.freebsd.org/threads/how-to-apply-non-numeric-mask-to-ipv6-address.69829/

Dynamic prefixes are a pain but will accompany us for quite some time, see https://tools.ietf.org/html/draft-ietf-v6ops-slaac-renum-04#ref-GERMAN-DP and especially in countries like Germany for data privacy reasons (in German language only): http://www.bfdi.bund.de/SharedDocs/Publikationen/Entschliessungssammlung/DSBundLaender/84DSK_EinfuehrungIPv6.pdf?__blob=publicationFile

The document by state's and countries' data privacy officers suggests the Internet providers implement at least dynamic prefixes for data privacy reasons. In case they offered fixed prefixes they also need to offer other ways to get the IPv6 changed by the user. So the easiest impementation is just to offer a dynamic prefix. Too bad.

As I move away from pfsense to something else I stumbled across the dynamic IPv6 issue in opnsense. As I understand that is not easy to fix in opnsense, I wonder how other's have solved this issue? One of course could be to use native IPv6 only for outgoing client connections and implement an additional IPv6 tunnel broker with a fixed prefix for server connectivity from the Internet. But maybe there are smarter ways?

[HikariWS]

I didn't know FreeBSD has this limitation, very sad. This is offtopic, but what Linux distro other than OpenWRT is best equivalent to OPNsense in features?

On OpenWRT, prefix and suffix are handled separately. Global prefix comes from ISP and "just works", and ALAIK we can't manually set the remaining bits when it's shorter than 64bit. The suffix is set on /etc/conf/dhcp on each host (hostid) then DHCPv6, SLAAC and odhcp use it to build the IPv6 addr together with the prefix.

It supports stuff like "$(uci get network.globals.ula_prefix | sed -e "s/^./d/")" according to https://openwrt.org/docs/guide-user/network/ipv6/ipv6.nat6

IPv6 has this big design flaw where LAN addresses may use ISP provided global prefix. This allows ISP to mess with our private LAN, as when they provide only /64 prefix and blocks us from creating VLANs. ISPs won't stop these practices, so IMHO we'll end up needing NPTv6 so we can isolate LAN "GUA" from ISP global prefix.

[froogl]

This is offtopic, but what Linux distro other than OpenWRT is best equivalent to OPNsense in features?

Due to FreeBSD's IPv6 shortcomings I have migrated from OPNsense to Debian with nftables, systemd-networkd, dnsmasq and wireguard. It's a very clean configuration without any hacky shell scripts. I don't need a web UI, so I am basically unlimited in features and possibilities. And I can finally saturate my 1G fibre connection, OPNsense capped the throughput at ~600 Mbits. So if you feel comfortable with the command line, that would be the way to go (replace "Debian" with the distro of your choice).

IPv6 has this big design flaw where LAN addresses may use ISP provided global prefix.

This is not a design flaw. I still think it's great to have global addresses in my private network. As long as you have a firewall in between there is nothing to worry about :) No need to set up NPTv6 or any other mapping hacks, as long as the underlying OS/firewall handles prefix changes correctly.

[marjohn56]

The flaw is with the ISPs, there is absolutely no reason to use changing prefixes and for ISPs it's a cash cow. If you want statics you need to pay extra for it. My suggestion, change to a decent ISP if you can. My ISP gives me a static /48 at no extra cost.

[froogl]

I personally prefer changing IPv4 addresses and IPv6 prefixes, as I consider it a privacy feature. Sometimes I actually need a new IP address/prefix to bypass IP restrictions. I also don't consider it a flaw, it's just an implementation of RFC3633/8415:

Each prefix has an associated valid and preferred lifetime, which constitutes an agreement about the length of time over which the requesting router is allowed to use the prefix.

So if a firewall cannot properly deal with prefix lifetime and rollover, as specified by the mentioned RFCs, I'd rather consider this a flaw in the firewall implementation instead of the ISP. No offence here, I know this is definitely not trivial to implement. But my feeling is that the only thing that has been done on this matter in the past was throwing mud at the ISPs. It's clearly a software issue.

Is a static prefix easier to handle? Sure it is. But that does not mean that these changing prefixes are an evil thing we need to fight. And even if it was, we need to face the reality: The vast majority of ISPs in the world offer dynamic prefixes to their consumer-grade customers. And as mentioned earlier this reality is perfectly fine even from a standards perspective.

[marjohn56]

The issue is not with the rollover/lifetime, dhcp6c handles that without an issue, the issue is with all the down link stuff. Sure, we can make radvd send out a depreciate prefix, no problem and I know that works, and if you don't use dhcpd6 and just rely on SLAAC then the downstream devices will update. It's not correct to say no work has been done on this, a lot of work has been done on this, but as soon as we fix one thing another pops up. There was also an issue with radvd with 12.1 where it would crash if the deprecate prefix flag was set, that seems fixed now but it took another issue with radvd to fix that as a by-product.

[fichtner]

I'm not sure how great Linux compares with threads like this https://forum.openwrt.org/t/delegated-ipv6-prefix-not-updated/56135/9

I spend quite some time to research this and you hit a lot of dead ends with pf, SLAAAC being handled in the kernel only so you can't listen for events, DHCPv6 not notifying when forcing a prefix reload on an upstream router, DHCPv6 not being able to probe for new prefix because the socket is blocked by the running DHCPv6 client already.

[froogl]

Then get on and fix it.

Well, I have personally already fixed the situation for myself by migrating to a nftables-based system. And I was trying to give some options to discuss https://github.com/opnsense/core/issues/2544#issuecomment-769811809 as a starting point. I still don't know which route should be taken.

It's not correct to say no work has been done on this, a lot of work has been done on this, but as soon as we fix one thing another pops up.

Sorry about this, I was not trying to say that no work has been done. But all I can read on the forums and Github are statements like "dynamic prefixes are [broken|wrong|evil|whatnot]_". And I wanted to clarify that they are not. They are perfectly fine if you are using the proper tools.

[spi43984]

I am coming from pfsense and have just recently migrated to opnsense. I like many features and the ease of useability. But as I am customer of a large German ISP I am also stuck with changing prefixes. There is no way to change the ISP or use a business plan due to other limitations like lack of IPTV then. So I'll be stuck with dynamic prefixes until the ISP changes that if ever. Feeling like standing at a crossroad I was also thinking of migrating to Debian. Another option might be (which I haven't thought through yet) is use the ISP's IPv6 for outgoing client connections (with some additional benefit of privacy) and use an IPv6 broker for incoming IPv6 connections aimed at servers.

[HikariWS]

This is offtopic, but what Linux distro other than OpenWRT is best equivalent to OPNsense in features?

Due to FreeBSD's IPv6 shortcomings I have migrated from OPNsense to Debian with nftables, systemd-networkd, dnsmasq and wireguard. It's a very clean configuration without any hacky shell scripts. I don't need a web UI, so I am basically unlimited in features and possibilities. And I can finally saturate my 1G fibre connection, OPNsense capped the throughput at ~600 Mbits. So if you feel comfortable with the command line, that would be the way to go (replace "Debian" with the distro of your choice).

Interesting. So Linux is indeed better than FreeBSD for IPv6?

I was searching articles and OPNsense is the top recommended FOSS OS for router, the only one using Linux seems to be IPFire. Of course I'd like a distro that's prepared for the job, but I'd not skip a lean distro either. I like WebUI for monitoring stuff, but for configuring I prefer plain txt files which I can handle on Subversion. On my current OpenWRT, I rarely use Luci for configs. But I'd need to learn a big lot to manage everything from a lean distro, which is troubling when we're talking about router.

IPv6 has this big design flaw where LAN addresses may use ISP provided global prefix.

This is not a design flaw. I still think it's great to have global addresses in my private network. As long as you have a firewall in between there is nothing to worry about :) No need to set up NPTv6 or any other mapping hacks, as long as the underlying OS/firewall handles prefix changes correctly.

As I said, the issue is ISP being able to dictate our LAN addresses: change prefix and breaking internal connectivity, break VLANs, etc etc. I don't want NAT as a security feature, I want some feature to decouple LAN addresses from ISP prefixes, and better multi-homing. Without workarounds.

The flaw is with the ISPs, there is absolutely no reason to use changing prefixes and for ISPs it's a cash cow. If you want statics you need to pay extra for it. My suggestion, change to a decent ISP if you can. My ISP gives me a static /48 at no extra cost.

The flaw is the protocol allowing ISPs to abuse it. To force LAN addresses to be coupled with prefix provided by ISPs. It's useless that the protocol designer kindly asks ISPs to properly follow the protocol standard, much less to not abuse it. It's like asking them to not snuff on HTTP and DNS messages, that's why we have HTTPS and DoH. Hoping for proper ISP competition also can't be on the protocol design, it just helps ISPs under monopoly to be even more abusive.

The standard clearly "suggests" /56 prefix, but nothing stops any ISP from providing /64, and even charge extra fee for bigger one.

What we need is proper protocols/tools that gracefully decouple ISP prefix from LAN topology while inceting devices OS to prefer IPv6.

[chris42]

@HikariWS I think you are messing up IPv4 concepts with IPv6. IPv6 was designed with IPv6 global route able addresses for every device in mind. Also heavily using dynamic allocation and reliance on name resolution. Most services nowadays come from the IPv4 world and have troubles to adapt to that IPv6 world. What you are looking for with you own LAN is fd00::/8. No ISP is messing with that and you are free to build a IPv4 topology with IPv6 addresses. By standard, an ISP does not have to give you a prefix at all and could just handle single IPv6s per device. Please stop mixing different concepts and creating a false narrative of ISPs that try to abuse you.

[BigSnicker]

The flaw is with the ISPs, there is absolutely no reason to use changing prefixes and for ISPs it's a cash cow. If you want statics you need to pay extra for it.

That's true in North America, but I saw someone write that dynamic prefixes are becoming mandatory in the EU, driven by Germany's strict data privacy regulations.

I wasn't able to verify that that's true (I'm sure our Dutch friends will know), but it does seem to come up occasionally:

https://www.huntonprivacyblog.com/2012/11/16/german-dpas-adopt-resolutions-on-eu-data-protection-and-ipv6/

https://forum.openwrt.org/t/ipv6-prefix-privacy/32179

https://svs.informatik.uni-hamburg.de/publications/2012/2012-10-09IPv6-Prefix-Alteration.pdf

On Tue, 2 Feb 2021 at 09:42, HikariWS notifications@github.com wrote:

This is offtopic, but what Linux distro other than OpenWRT is best equivalent to OPNsense in features?

Due to FreeBSD's IPv6 shortcomings I have migrated from OPNsense to Debian with nftables, systemd-networkd, dnsmasq and wireguard. It's a very clean configuration without any hacky shell scripts. I don't need a web UI, so I am basically unlimited in features and possibilities. And I can finally saturate my 1G fibre connection, OPNsense capped the throughput at ~600 Mbits. So if you feel comfortable with the command line, that would be the way to go (replace "Debian" with the distro of your choice).

Interesting. So Linux is indeed better than FreeBSD for IPv6?

I was searching articles and OPNsense is the top recommended FOSS OS for router, the only one using Linux seems to be IPFire. Of course I'd like a distro that's prepared for the job, but I'd not skip a lean distro either. I like WebUI for monitoring stuff, but for configuring I prefer plain txt files which I can handle on Subversion. On my current OpenWRT, I rarely use Luci for configs. But I'd need to learn a big lot to manage everything from a lean distro, which is troubling when we're talking about router.

IPv6 has this big design flaw where LAN addresses may use ISP provided global prefix.

This is not a design flaw. I still think it's great to have global addresses in my private network. As long as you have a firewall in between there is nothing to worry about :) No need to set up NPTv6 or any other mapping hacks, as long as the underlying OS/firewall handles prefix changes correctly.

As I said, the issue is ISP being able to dictate our LAN addresses: change prefix and breaking internal connectivity, break VLANs, etc etc. I don't want NAT as a security feature, I want some feature to decouple LAN addresses from ISP prefixes, and better multi-homing. Without workarounds.

The flaw is with the ISPs, there is absolutely no reason to use changing prefixes and for ISPs it's a cash cow. If you want statics you need to pay extra for it. My suggestion, change to a decent ISP if you can. My ISP gives me a static /48 at no extra cost.

The flaw is the protocol allowing ISPs to abuse it. To force LAN addresses to be coupled with prefix provided by ISPs. It's useless that the protocol designer kindly asks ISPs to properly follow the protocol standard, much less to not abuse it. It's like asking them to not snuff on HTTP and DNS messages, that's why we have HTTPS and DoH. Hoping for proper ISP competition also can't be on the protocol design, it just helps ISPs under monopoly to be even more abusive.

The standard clearly "suggests" /56 prefix, but nothing stops any ISP from providing /64, and even charge extra fee for bigger one.

What we need is proper protocols/tools that gracefully decouple ISP prefix from LAN topology while inceting devices OS to prefer IPv6.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/opnsense/core/issues/2544#issuecomment-771681991, or unsubscribe https://github.com/notifications/unsubscribe-auth/AENGMY24YLRUMJZCHE7HM4TS5AFMFANCNFSM4FJ7DOZA .

[spi43984]

https://www.huntonprivacyblog.com/2012/11/16/german-dpas-adopt-resolutions-on-eu-data-protection-and-ipv6/

That's the one in proper English I was referring to earlier. German ISPs might offer fixed prefixes to end users but in that case they need to offer end users some way to easily change their static IPv6 prefixes. So thinking about some highly-sophisticated backend service to allow end users changing their IPv6 prefix, it's much easier for an ISP to allow dynamic prefixes only. I don't expect that to change soon.

[HikariWS]

@chris42 as I said this is offtopic here. I disagree on your statements, call me in pvt if you are interested on talking about it :)

The flaw is with the ISPs, there is absolutely no reason to use changing prefixes and for ISPs it's a cash cow. If you want statics you need to pay extra for it.

I don't disagree on ISP's bad faith, or on proper needs for prefix changes as pointed by @spi43984. The issue is that IPv6 provides possibility for ISP to change prefix and/or provide /64 prefix, regardless if they are abusing the protocol or due to legal demands.

The protocol design can't allow ISP to prohibit us to use multiple VLANs or drop our connections at will, and then just hope or beg for ISPs to not do it. Some will always do, so the protocol must not support it or provide features to circumvent it.

The topic here isn't either ISPs behavior or how IPv6 is good or bad or how it could be better. Given the circumstances on the table, we must find solutions on network tools (OPNsense here).

We can't stop ISPs from abusing and we have acceptable use cases for prefix changing and even reference on the standard regarding prefix delegation lifetime, so only viable solution I see is for tools to gracefully identify when PD had changed and propagate it to all other router tools and devices under it. I know how hard it is to implement that, which is very sad, and I thank all developers who had been voluntarily working on it.

[bu7cher]

AFAIR, I've added ext_if option for NPTv6 module exactly for such purpose - detect changing of external prefix and reconfigure the NTPv6 instance. Does it not fit for your tasks? https://cgit.freebsd.org/src/commit/sys/netpfil/ipfw/nptv6/nptv6.c?id=b2b56606889cd11b155472009a991d458ff119f7

[marjohn56]

AFAIR, I've added ext_if option for NPTv6 module exactly for such purpose - detect changing of external prefix and reconfigure the NTPv6 instance. Does it not fit for your tasks? https://cgit.freebsd.org/src/commit/sys/netpfil/ipfw/nptv6/nptv6.c?id=b2b56606889cd11b155472009a991d458ff119f7

Nice..

[maurice-w]

Nice indeed, but this once again brings us back to the issue that OPNsense doesn't use ipfw (except for traffic shaper and captive portal I think). Correct?

Same issue with NAT64: Natively supported in ipfw, but we have to use Tayga on OPNsense.

Maybe, just maybe, eventually switching to ipfw would make OPNsense more future proof? But I know it's a very complex task.

[HikariWS]

AFAIR, I've added ext_if option for NPTv6 module exactly for such purpose - detect changing of external prefix and reconfigure the NTPv6 instance. Does it not fit for your tasks? https://cgit.freebsd.org/src/commit/sys/netpfil/ipfw/nptv6/nptv6.c?id=b2b56606889cd11b155472009a991d458ff119f7

Sorry for my noob question on github. Does this mean that OPNsense supports dynamic prefix changing under NPTv6? And what about multi-homing / multi-WAN, is it supported?

If so, could somebody make a tutorial teaching how to enable dynamic prefix support on NPTv6 with 2 WANs? I'm still using OpenWRT and only waiting OPNsense to support dynamic prefix to build a new PC for router.

[maurice-w]

No, this only means that there is a feature in FreeBSD which supports it, but OPNsense doesn't make use of this (yet).

NPT with multi-WAN works, but only with static prefixes.