[HOWTO] Configure IPv6 in order to "just work" (tm)

[meyergru]

No. You can choose the interface identifier freely. Usually, it is derived from the MAC as an EUI-64, but many OSes nowadays "fake" the MACs and/or the interface identifier anyway. Also, that EUI-64 is part of one of many possible IPv6s, with IPv6 privacy extensions enabled, you will use a randomized interface identifier that changes after a while for any outbound connection, while keeping the EUI-64 for inbound addressing.

So, the lower 64 bits are arbitrary and only these will allow identifying a specific client.

However, the prefix (if static) can be used to identify your "connection", so to speak. It will suffice to identify your company or to issue a copyright strike when you do bad things (tm).

As to examples, I assume there are videos out that explain it with examples. Otherwise, there is RFC4941.

But yes, I think that dynamic IPv6 will be somewhat better for private use cases. Since your ISP knows who owned which IPv6 prefix at what time, that will not help against copyright strikes, either. That is what I meant by:

one might argue that this can only be achieved by using a VPN

[n3]

Thats what I meant. It is not safe for crimonal activitys, but with a dynamic prefix I can make it amazon, google etc. a little bit more difficult.

Maybe you can link this documentation to your post: https://docs.opnsense.org/manual/how-tos/ipv6_dsl.html
Or extend the documentation with your post and screenshots.

[IsaacFL]

I've had a working IPv6 setup for some time using radvd in an unmanaged configuration.

My local servers are set up as IPv6-only, and most of my local clients use IPv6 via DHCP option 108. This setup has been working very well since my ISP provides a stable prefix through DHCP-PD. I only have one subnet that still uses IPv4 for legacy IoT devices. All other clients correctly honor option 108 and do not receive an IPv4 address.

However, recently my ISP connection went down for about eight hours, and during that time radvd stopped advertising routes, even for internal access. As a result, I had no way to reach my local services.

This seems like a bug, since internal IPv6 routing should continue to work even when the WAN is temporarily down.

Is there a configuration option that will keep the delegated prefix active for local IPv6 traffic when the WAN interface is down? What exactly causes radvd to stop advertising routes—is it triggered by gateway monitoring or dpinger in some way? It's not easy to test without taking the entire network offline.

I'd prefer not to use ULA addresses, as I've found they don't work well and tend to be ignored by clients. I've considered switching to static prefixes since my delegated prefix is very stable, but how can I detect if the ISP ever changes it?

[Maurice]

If your prefix is stable, I'd recommend configuring the LAN interfaces statically (while still using DHCPv6 PD on the WAN - most ISPs require this).

"Track interface" doesn't really make sense for a prefix which never changes and you just discovered one of the main disadvantages.

Cheers
Maurice

[Patrick M. Hausen]

If your prefix is stable, I'd recommend configuring the LAN interfaces statically (while still using DHCPv6 PD on the WAN - most ISPs require this).

"Track interface" doesn't really make sense for a prefix which never changes and you just discovered one of the main disadvantages.

Amen, brother.

[meyergru]

As you already stated, ULAs are not a viable solution to anything considering that they are priritized even lower than IPv4.

A real solution would be static GUAs, which you most ISPs will not give you.

With dynamic prefixes, SLAAC is the best choicde, because a) many clients do not honor DHCPv6 and b) because it is the only possibility to "push" new prefixes when they change.

When you internet connection is down, you obviously have no WAN with valid GUA prefixes, so "track interface" cannot provide for any valid prefix. If you temporarily configured your LAN interface(s) with static IPv6 GUAs, it would work, so maybe a kind of "fallback IPv6" would do the trick.

Actually, I am not aware if this could already be achieved by using an additional virtual IPv6 on the LAN interface or if there would have to be a new feature to achieve this.

That is mostly because I never had that problem: Why/how do you absolutely need IPv6 absent a working internet connection?

I use IPv4 for my (V)LAN communication and IPv6 for outbound connections only - I could use firewall rules for some selective inbound connections, but deliberately choose to use a reverse proxy for that. This way, I only have internal IPv4 services, which can be presented via IPv6 to the internet.

I have continually argued against using "IPv6 only" or relying on IPv6 for LAN services in its current (bad) state, which has mostly been caused by ISPs who deliberately break it by enforcing dynamic IPv6. People can argue for "pure" technological reasons to use IPv6 over IPv4, but that does not help them at all in reality.

[IsaacFL]

I use IPv4 for my (V)LAN communication and IPv6 for outbound connections only - I could use firewall rules for some selective inbound connections, but deliberately choose to use a reverse proxy for that. This way, I only have internal IPv4 services, which can be presented via IPv6 to the internet.

I'm the opposite — my network is IPv6-only from subnet to subnet, with external IPv4 access provided via NAT64. The only IPv4 subnet is the one used for legacy devices, which can reach the internet but not internal resources.

I've definitely considered using static IPv6 assignments on the interfaces, but I don't have any guarantee that my ISP won't change the delegated prefix in the future. I'd need some way to be notified if the prefix ever changes, since that would be difficult to debug otherwise. I'm also not sure how the ISP would react if I started using invalid upstream addresses after a prefix change.

In that case, OPNsense would continue routing what are now invalid IPv6 addresses toward the ISP, which technically violates the relevant RFCs.

I'm not sure why radvd is being configured to stop advertising the prefix when the WAN goes down. That behavior should really be handled at the routing table level, not by radvd itself. radvd should simply update its advertisements when the prefix changes, rather than stopping completely. OPNsense remains the router, even when it temporarily loses a WAN route.

[Patrick M. Hausen]

But if the internal interfaces are configured as "track WAN", then there is no prefix once the WAN connection drops. So what should radvd advertise? I have not looked at the code yet, but I assume that it is not radvd stopping to advertise, but OPNsense actively removing the configured GUAs from the interfaces.

Can you confirm? I don't use "track".

[IsaacFL]

But if the internal interfaces are configured as "track WAN", then there is no prefix once the WAN connection drops. So what should radvd advertise? I have not looked at the code yet, but I assume that it is not radvd stopping to advertise, but OPNsense actively removing the configured GUAs from the interfaces.

Can you confirm? I don't use "track".

I use Track Interface to assign prefixes to my interfaces.

I understand the implications of using Track Interface with the way OPNsense implements it, but there's also a downside to using static assignments if the ISP ever changes the prefix — even if such changes are rare.

The expected behavior should be that if the ISP changes the delegated prefix, radvd automatically updates the prefix it advertises.

If the WAN interface goes down, radvd should continue advertising the existing prefix for internal traffic, while the routing table should handle the loss of external connectivity by returning "destination unreachable" for external sites.

If gateway monitoring is turned off, would that keep radvd from being reconfigured?

[IsaacFL]

But if the internal interfaces are configured as "track WAN", then there is no prefix once the WAN connection drops. So what should radvd advertise? I have not looked at the code yet, but I assume that it is not radvd stopping to advertise, but OPNsense actively removing the configured GUAs from the interfaces.

Can you confirm? I don't use "track".

I believe that opnsense actively removes the GUAs from the interfaces.

[Patrick M. Hausen]

You can assign static ULAs in addition to the "tracked" GUAs so internal IPv6 connectivity remains functional.

[meyergru]

But that depends solely upon you using internal DNS names based on the ULAs. I still fail to see how having no IPv6 assigned makes intranet operations go awry unless you use "IPv6 only".

@IsaacFL: Even if OpnSense did remove the GUA from the interfaces - that is technically correct, since you do not own these prefixes any longer.

As I said: You can actually use "IPv6 only" - and if it were not for the ISP to use dynamic prefixes, that would work just fine. You see what happens with dynamic prefixes now. I can see only these strategies going forward:

1. Ask your ISP for static prefixes (good luck).
2. Use (static) ULAs for your internal communication needs - IPv6 allows for ULAs and GUAs to co-exist, but you need to use internal DNS naming based on ULAs, then.
3. Try to request a new feature on Github to have a means to no give up GUA prefixes on WAN disconnect and hope for the best.
4. Use dual-stack. As I said: This is a pragmatic approach that works OOTB - you do not have to follow that advice, though.

You can argue how this is unfair and how it should be, but quoting from "Bridge of spies": "Would it help?". It is a theoretical discussion. I am all for working solutions, that is just how I am.

[IsaacFL]

The ipv6 mostly dhcp option 108 does work well for my network, since all of my clients do support it, and I have been using ipv6 for a very long time and understand it. My knowledge of NAT of any kind is not good since we always had real public ipv4 addresses where I worked.

ULA does not work well, in that really you are running an additional network stack, so dual stack to triple stack?

Opnsense implementation of ipv6 could definitely be improved. There is no reason to remove the GUA addresses on the interfaces when the WAN goes down. You dont know if you "own" the prefixes or not at that point. It seems the fix is to use static assignments but I dont "own" them either.

Mostly I was just wondering if I could change something in the gateway monitoring so it doesnt wipe out the configuration when the wan goes down.

[Maurice]

@IsaacFL
I get what you're asking for: A semi-static LAN configuration which only gets updated when a new prefix gets delegated, but doesn't get removed if the PD expires or the WAN goes down. You'd also have to persist the PD to disk to make sure you have a prefix after a reboot. This would certainly be possible, but most likely would require a complete rewrite of the "track interface" feature.
For the time being, I'd really recommend a static LAN configuration. That's what I did when I was with an ISP who changed the prefix maybe once a year. You can e. g. use Monit to monitor for prefix changes. Your ISP simply filters packets with source addresses from prefixes not delegated to you. It's highly unlikely you'll get in trouble for this, it certainly happens a lot.

@meyergru
"Unless you use IPv6-only" is exactly the point. That's where we're all heading eventually and some of us choose to do it earlier than others. Nothing wrong with that, everyone at their own pace. My home networks have been IPv6-only for years, except for one IPv4-only LAN for legacy devices (just like IsaacFL). It's not for everyone, but totally viable.
My current ISP changes the prefix every 24 hours so I depend on "track interface". In addition to the dynamic GUAs for Internet access, I use static ULAs for internal services. The internal DNS zone has AAAA records with ULAs. Not a problem at all.

[meyergru]

@Maurice, yes, your setup is #2 from my list. I am not arguing against IPv6 only, I only say you have to circumvent the effects of the dreaded dynamic prefixes somehow (i.e. you cannot do #1). ULA is one way to that, dual-stack (#4) is the other.

I second that a rewrite of the "track interface" feature (#3) is quite a challenge.