OPNsense Forum

There have been multiple threads about problems with IPv6 configuration lately.

While there are instructions in the documentation (https://docs.opnsense.org/manual/ipv6.html), they leave some vital parts as an exercise to the reader.

Preface:

Despite there being enough IPv6 address prefixes with the abundance of 2^128 possible IPs, many ISPs do not provide you with a static IPv6 prefix like the RFCs propose. Some of them will give you just one /64 range, which is awkward, because you usually need one /64 for each of your subnets/VLANs. Even if they provide a /56 or /48 prefix, which you can then subdivide, some ISPs change the ranges regularly or at least when the connection drops. I think this is to make it harder to host services like a business customer would and thus to differentiate business and consumer uplinks. You can try "prevent release" and setting the DUID under "Interfaces : Settings", but usually, it does not help.

With OpnSense, it is possible to create firewall aliases of type "Dynamic IPv6 Host", that specify only the EUI-64 part of the address and are provided with the 64 bits long prefix of the (V)LAN interface. However, anything else than static DHCP prefixes neccessitate dynamic DNS for IPv6 if you want to make services available from outside. This is sometimes difficult when there are different IP prefixes for your WAN (IA_NA) and (V)LAN (IA_PD) ranges.

So, mostly, you want to have inside-out IPv6 access first, potentially using IPv6 privacy extensions for this in order to hide your identity.

If you also want to expose services, I recommend to use reverse proxies like HAproxy, Caddy or Nginx - there are tutorials on how to use them here on the forum. The reverse proxies can also convert from incoming IPv6 connections to internal IPv4 services, which further reduces complexity for these scenarios. Also, you can (and should) use wildcard certificates if ever possible, because named certificates will be published and can be used to scan for IPv6-based services where a normal port scan is infeasible.

When you are behind CG-NAT, your only chance to expose services is via a reverse tunnel like Cloudflare or to use IPv6. In the latter case, a reverse proxy will work as well.

You can also expose individual (V)LAN clients via their static EUI-64, but you will need both firewall aliases and a decent dynamic DNS to do it.


The way I do this is as follows:

1. I configure the WAN interface to request an IPv6 prefix via DHCPv6.

Usually, this will be a /56 or a /48 prefix, depending on your ISP. It must be < /64 for the rest to work.
I also use "Request prefix only", because some ISPs do not hand out IA_NA (i.e. a /128 WAN IPv6 GUA) anyway and some even refuse to respond to DHVPv6 requests for it. That way, I will only get a IA_PD IPv6 GUA prefix and no WAN IPv6, but that can actually be turned into an advantage:

If I got an IA_NA, it would be from another range than the IA_PD. Thus, when I update a dynamic DNS entry from OpnSense, the IA_NA prefix will get registered and I cannot make LAN clients available, because they use the other (IA_PD) prefix. So, it is better to use the IA_PD prefix for the WAN interface, too.

It is essential to specify an "Optional prefix ID" that is different from all (V)LAN prefixes in this case, because each interface has to have a different prefix ID. Consider a /56 prefix from the provider that is: 1111:2222:3333:44XX:YYYY:YYYY:YYYY:YYYY/56. Then, XX denotes the prefix ID, leaving the 64 lower bits (YYYY) for SLAAC assignments on the repective interface.

You can leave the "Optional interface ID" empty, in which case the EUI-64 that is derived from the MAC (https://en.wikipedia.org/wiki/MAC_address) of the WAN interface will be taken as a default. This in turn leaks information about the manufacturer of your WAN NIC via its OUI (https://en.wikipedia.org/wiki/Organizationally_unique_identifier), so you may want to specify something arbitrary (or memorable) here.

2. I use SLAAC (https://en.wikipedia.org/wiki/IPv6_address#Stateless_address_autoconfiguration_(SLAAC)) only for my (V)LAN interfaces, not DHVPc6. That is for several reasons:

• DHCPv6 is not understood by many devices (like Android).
• DHCPv6 is unable to specify more than one prefix (it cannot assign ULA (https://en.wikipedia.org/wiki/Unique_local_address) IPv6 on top of GUA IPv6, e.g.).
• DHCPv6 will keep your clients to use an outdated, non-working prefix in case your connection drops or your ISP changes GUA (https://www.oreilly.com/library/view/ipv6-fundamentals-a/9780134670584/ch05.html) prefixes regularly.
• By using SLAAC, you also can use IPv6 Privacy Extensions (RFC 8981) (https://datatracker.ietf.org/doc/html/rfc8981) on the clients, still leaving an EUI-64 based management IPv6 for predictable inbound use.

SLAAC is done via router advertisements (RA) and can also handle DNS server and gateway announcements.

Therefore, I use these settings:

• IPv6 Configuration Type = Track interface
• Parent interface = WAN
• Assign prefix ID = <different for each interface>
• Optional Interface ID = empty
• Manual configuration = checked

The prefix ID can be only N bits long, where N = 64 minus the ISP-provided prefix size, e.g. 8 bits when /56 is used or 16 bits with /48.
On (V(LAN interfaces, I usually do not specify an interface ID.

Under Services: Router Advertisements, I use these settings for any (V)LAN:

• Router Advertisements = Unmanaged (meaning SLAAC only)
• Router Priority = normal
• Source Address = automatic
• Advertise Default Gateway = checked
• DNS options = both unchecked (meaning use the system DNS servers
• DNS servers = empty
• Domain search list = whatever you need
• Minimum Interval = 30
• Maximum Interval = 60

I use rather short intervals to distribute RAs quite often and also, to have a short lifetime in case the WAN interface changes its GUA. I want to keep a potential use of deprecated prefixes as short as possible. This can have an averse effect on battery life for WLAN clients.

Mind you, there may be reasons why RAs do not work for your clients. You can always look at the resulting RA settings by inspecting /var/etc/radvd.conf and see if the GUA prefix was picked up and if your (V)LAN prefixes and other settings seem right. Then, you can look at your client if it really receives the RAs.

3. Finally, a neat trick: If you want (or need) to configure your OpnSense to announce itself for any service, like, as a gateway, NTP or DNS server, you can always use its link-local address - because you do not know the GUA beforehand with changing prefixes. You can even create a virtual IP like fe80::1/64 on each local interface and use that instead. This is also easier to memorize for static configurations.

Good summary, thank you!

DNS server announcements via RA (RDNSS option) are supported by many, but not all devices (especially older ones). For best compatibility, I'd recommend announcing DNS options via both RAs as well as stateless DHCPv6. Set Router Advertisements to "Stateless" and enable the DHCPv6 server, but do not specify an address range.

Be careful with short RA intervals, these can have a negative impact on battery-powered devices: https://datatracker.ietf.org/doc/html/rfc7772

Cheers
Maurice

I do not rely on DNS server announcements via IPv6, because I use dual-stack, so the DNS servers can be got via IPv4 anyway, but good to know, thank you! ;-)

Given that "DeprecatePrefix On" ist now the default in radvd.conf, one could probably use longer intervals now even when the prefix changes often. I have one problematic Windows 11 client that never does router solicitations after boot, so I need a short interval to have it pick up an IPv6 address without an endless wait.

Quote from: Maurice on February 14, 2025, 12:20:26 AMGood summary, thank you!

DNS server announcements via RA (RDNSS option) are supported by many, but not all devices (especially older ones). For best compatibility, I'd recommend announcing DNS options via both RAs as well as stateless DHCPv6. Set Router Advertisements to "Stateless" and enable the DHCPv6 server, but do not specify an address range.

Be careful with short RA intervals, these can have a negative impact on battery-powered devices: https://datatracker.ietf.org/doc/html/rfc7772

Cheers
Maurice

Are there any 'gotchas' with this? I tried this an appeared to lose IPv6 connectivity on the device I was testing (tested using ipv6-test website). Disabling the DHCPv6 server for that interface and everything came back to life again.

Stateless DHCPv6 shouldn't cause loss of connectivity. What's the actual issue? DNS? Invalid interface address? Routing?

Quote from: Maurice on February 16, 2025, 08:32:56 PMStateless DHCPv6 shouldn't cause loss of connectivity. What's the actual issue? DNS? Invalid interface address? Routing?

Thanks Maurice - I'll investigate.

Before I went down a potential rabbit hole trying to see what the issue is, I thought I'd double check there wasn't any obvious addition such as 'but if you do this, then you must also...' etc. The way I read it was from the working configuration above, change RA from unmanaged to stateless, tick DHCPv6 Server for the Interface, make sure range is empty, and all should work.

I'll investigate what aspect has broken. Initial view was unable to reach ipv6 only sites, fails all the IPv6 test sites available etc but I haven't looked into the actual cause.

Quote from: meyergru on February 13, 2025, 02:54:29 PM...

@meyergru First of all, thanks for writing out this great detailed guide... Really, really helpful to get started with IPv6.

I have a similar setup, I get a /56 dynamic IPv6 range from the ISP that changes with every reboot.
So far have not been able to get the same IPv6 allocated on reboot - played around with the suggested settings of specifying values for 'DHCP Unique Identifier' and enabled 'Prevent release' in Interfaces->Settings.

I am running Blocky (https://github.com/0xERR0R/blocky) (It is an adblocker like AdGuardHome/PiHole) as a plugin (https://github.com/gspannu/OPN-Plugins) on OPNsense, but in order to manage adblocking per client, I need static IP addresses with hostnames for each IPv6 client for use within the local network. IPv4 is super simple and all clients across my 3 VLANs are assigned static IPv4 through DHCPv4 server.

Q: How do I get static IPv6 addresses to these LAN/vLAN clients using the setup you have suggested above? Some have suggested static ULAs, but I have no idea how to implement the same.

Request: Could you please expand your guide to cover static IPv6 addresses (similar to IPv4) for LAN clients, so that IPv6 clients can be assigned hostnames and be distinguished uniquely for PiHole kind of applications (within the local network)?

Thanks..

I explained most of that already. As you already found out, "prevent release" usually does not help if your ISP gives you dynamic IPv6 prefixes.

So, for your blocky DNS you have to decide which DNS server they should use, how you get them to use that DNS server and in your specific case, how the client then contacts the DNS server for it to make a client-based decision.

1. In theory, you can supply any DNS server to your clients (via any means), but with IPv6, that is somewhat limited. Why? Consider:

a. a link-local IPv6 like fe80::x.y.z - yes, you can do that if you know the server's EUI-64. IDK if the clients could use it, though, because a link-local IPv6 usually needs an interface specification.
b. a GUA IPv6 like 2001::x.y.z - probably not, because of changing prefixes and you must supply the complete IPv6.
c. an ULA IPv6 like fd80::x.y.z - yes, you can have that, but wait until later...
d. a RFC1918 IPv4 - you can surely do that unless you have IPv4 only (but I can hardly imagine any case where this is sufficient).

2. You can supply your clients with a DNS server IP (any kind) via these schemes:

a. via DHCPv4 - only, if you have IPv4, but then, yes, you probably do...
b. via DHCPv6 - yes, but many clients do not support that.
c. via SLAAC - yes, but some clients do not support that.
d. via a mix of those mechanisms - probably, but which has priority when they differ?

3. You clients can contact the DNS server only via its IP, by which he will be identified.

a. via its IPv4 - this is easy, when available. You can make static DHCPv4 reservations and thus the clients can be identified.
b. via its IPv6 - but which one? He can have many, like link-local, ULA or GUA. Which of these will he use to contact the DNS server?

So, with much luck, you could figure out a way to have ULAs on top of dynamic GUAs, but that will help you only to make the clients and the DNS server addressable via a fixed IPv6 (which would either be based on an EUI-64 in case of SLAAC or a static reservation in case of DHCPv6). It does not help with your situation, because that probably does not even guarantee that your clients will not use another IPv6 to contact the DNS server (https://blog.ipspace.net/2014/01/source-ipv6-address-selection-saves-day/). Although that is specified in some RFCs, IDK if that works like it should, so happy debugging.

What I mean to say by that, is that your assumption is wrong:

QuoteI need static IP addresses with hostnames for each IPv6 client

That sure helps to address the clients, and I explained how to do that. It is not what is needed for your situation, because the clients ask the DNS server via (any of) their IP(s), not their hostnames.

The short version of this is:

You should have dual-stack (you can always have this via RFC1918, even when there is no IPv4 internet connection). Then, use DHCPv4 with static reservations for your clients. Assign your (blocky) DNS server IPv4 via DHCPv4 and have it decide based on the client's IPv4.

That being said, remember that many browsers use DoT or DoH these days and circumvent your local DNS altogether.

@gspannu If you need to reliably identify groups of hosts based on the IPv6 addresses they use for outbound connections, your only realistic option is multiple interfaces, each with its own subnet. Then you can use the subnet ID as an identifier.

@meyergru IPv6-only is very much possible, I've been running such networks for years. In many scenarios you'll of course need a separate IPv4-only network for legacy devices, but this has significant advantages over having a single dual-stack network.

I said I can hardly imagine a case where IPv6-only is sufficient, which does not mean that there are no edge cases where it is. As you confirmed, many legacy devices only support IPv4. For many people without manageable switches, VLANs to separate them are infeasible. And I have yet to see an ISP who offers IPv6-only with a NAT64 gateway, all that I know use DS or DS-Lite.

Not sure where my last post vanished..

So for me it works as described but there is some caveat with it.

1. Now I do not get a DHCPv6 addresse reported (which is somehow wanted). Windows 11 prefers the DHCP provided DNS records over RA provided and therefor will forever use IPv4 DNS. If you disable IPv4 it still works, as then the IPv6 address provided by RA is getting used.

However I wanted to define the link local IPv6 address and get it used by Windows (just because I can). So even the above clearly works in any dual stack, because you actually would not need any IPv6 DNS server at all, I wanted to figure out how this could work.

So the problem is clearly on the client side of Windows preferring DHCP DNS entries over RA entries.

This is how it looks like if I manually configure the link local address in RA on Windows end:
Ethernet adapter Ethernet 4:

  Connection-specific DNS Suffix  . : home.local
  Description . . . . . . . . . . . : Realtek PCIe GbE Family Controller
  Physical Address. . . . . . . . . : D8-BB-C1-36-5E-49
  DHCP Enabled. . . . . . . . . . . : Yes
  Autoconfiguration Enabled . . . . : Yes
  IPv6 Address. . . . . . . . . . . : 2003:xx:xxx:xxxx:xxxx:xxxx:e8a7:6ece(Preferred)
  Lease Obtained. . . . . . . . . . : Mittwoch, 19. Februar 2025 13:32:44
  Lease Expires . . . . . . . . . . : Mittwoch, 19. Februar 2025 15:32:44
  IPv6 Address. . . . . . . . . . . : 2003:xx:xxx:xxxx:xxxx:xxxx:20ec:3554(Preferred)
  Temporary IPv6 Address. . . . . . : 2003:xx:xxx:xxxx:xxxx:xxxx:fdfb:315f(Preferred)
  Link-local IPv6 Address . . . . . : fe80::c786:8cfd:d5e1:1dbf%6(Preferred)
  IPv4 Address. . . . . . . . . . . : 192.168.0.179(Preferred)
  Subnet Mask . . . . . . . . . . . : 255.255.255.0
  Lease Obtained. . . . . . . . . . : Mittwoch, 19. Februar 2025 13:17:46
  Lease Expires . . . . . . . . . . : Mittwoch, 19. Februar 2025 15:13:20
  Default Gateway . . . . . . . . . : fe80::6662:66ff:fe21:b957%6
                                      192.168.0.1
  DHCP Server . . . . . . . . . . . : 192.168.0.1
  DHCPv6 IAID . . . . . . . . . . . : 131644353
  DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-28-C2-F1-61-D8-BB-C1-36-5E-48
  DNS Servers . . . . . . . . . . . : 192.168.0.1
                                      fe80::6662:66ff:fe21:b957%6
  NetBIOS over Tcpip. . . . . . . . : Enabled
  Connection-specific DNS Suffix Search List :
                                      lab.local
So we can see the first DNS server entry is the IPv4 address. And there is nothing advertised by the DHCPv6.

Now I changed RA to Stateless and also ticked "Do not send any DNS configuration to clients".
I also enabled DHCPv6 and entered my link local address into the DNS server field.

Result was not as expected:
Ethernet adapter Ethernet 4:

  Connection-specific DNS Suffix  . : home.local
  Description . . . . . . . . . . . : Realtek PCIe GbE Family Controller
  Physical Address. . . . . . . . . : D8-BB-C1-36-5E-49
  DHCP Enabled. . . . . . . . . . . : Yes
  Autoconfiguration Enabled . . . . : Yes
  IPv6 Address. . . . . . . . . . . : 2003:xx:xxx:xxxx:xxxx:xxxx:e8a7:6ece(Preferred)
  Lease Obtained. . . . . . . . . . : Mittwoch, 19. Februar 2025 13:32:44
  Lease Expires . . . . . . . . . . : Mittwoch, 19. Februar 2025 15:32:44
  IPv6 Address. . . . . . . . . . . : 2003:xx:xxx:xxxx:xxxx:xxxx:20ec:3554(Preferred)
  Temporary IPv6 Address. . . . . . : 2003:xx:xxx:xxxx:xxxx:xxxx:fdfb:315f(Preferred)
  Link-local IPv6 Address . . . . . : fe80::c786:8cfd:d5e1:1dbf%6(Preferred)
  IPv4 Address. . . . . . . . . . . : 192.168.0.179(Preferred)
  Subnet Mask . . . . . . . . . . . : 255.255.255.0
  Lease Obtained. . . . . . . . . . : Mittwoch, 19. Februar 2025 13:17:46
  Lease Expires . . . . . . . . . . : Mittwoch, 19. Februar 2025 15:13:20
  Default Gateway . . . . . . . . . : fe80::6662:66ff:fe21:b957%6
                                      192.168.0.1
  DHCP Server . . . . . . . . . . . : 192.168.0.1
  DHCPv6 IAID . . . . . . . . . . . : 131644353
  DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-28-C2-F1-61-D8-BB-C1-36-5E-48
  DNS Servers . . . . . . . . . . . : 192.168.0.1
  NetBIOS over Tcpip. . . . . . . . : Enabled
  Connection-specific DNS Suffix Search List :
                                      lab.local
Now I did not even have any entry left. So I was left scratching my head and did not understand it.

Then I found this post:
https://forum.opnsense.org/index.php?topic=26864.msg156802#msg156802

There was a hint, that you actually do need to enter a range, otherwise DHCPv6 will simply not work.

So I did:
Range.jpg

Saved it and now that is actually what I wanted to achieve.
Obviously you can also assign the full range (::0:0:0:0 - ::ffff:ffff:ffff:ffff).

The result is this:
Ethernet adapter Ethernet 4:

  Connection-specific DNS Suffix  . : home.local
  Description . . . . . . . . . . . : Realtek PCIe GbE Family Controller
  Physical Address. . . . . . . . . : D8-BB-C1-36-5E-49
  DHCP Enabled. . . . . . . . . . . : Yes
  Autoconfiguration Enabled . . . . : Yes
  IPv6 Address. . . . . . . . . . . : 2003:xx:xxx:xxxx::e8a7:6ece(Preferred)
  Lease Obtained. . . . . . . . . . : Mittwoch, 19. Februar 2025 13:32:44
  Lease Expires . . . . . . . . . . : Mittwoch, 19. Februar 2025 15:32:43
  IPv6 Address. . . . . . . . . . . : 2003:xx:xxx:xxxx:9bdd:a6fb:20ec:3554(Preferred)
  Temporary IPv6 Address. . . . . . : 2003:xx:xxx:xxxx:3d90:5292:fdfb:315f(Preferred)
  Link-local IPv6 Address . . . . . : fe80::c786:8cfd:d5e1:1dbf%6(Preferred)
  IPv4 Address. . . . . . . . . . . : 192.168.0.179(Preferred)
  Subnet Mask . . . . . . . . . . . : 255.255.255.0
  Lease Obtained. . . . . . . . . . : Mittwoch, 19. Februar 2025 13:17:46
  Lease Expires . . . . . . . . . . : Mittwoch, 19. Februar 2025 15:13:20
  Default Gateway . . . . . . . . . : fe80::6662:66ff:fe21:b957%6
                                      192.168.0.1
  DHCP Server . . . . . . . . . . . : 192.168.0.1
  DHCPv6 IAID . . . . . . . . . . . : 131644353
  DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-28-C2-F1-61-D8-BB-C1-36-5E-48
  DNS Servers . . . . . . . . . . . : fe80::6662:66ff:fe21:b957%6
                                      192.168.0.1
  NetBIOS over Tcpip. . . . . . . . : Enabled
  Connection-specific DNS Suffix Search List :
                                      lab.local
So the first change is as expected that I got an address from the range
    IPv6 Address. . . . . . . . . . . : 2003:xx:xxx:xxxx::e8a7:6ece(Preferred)

Second, I do now see the DNS server and also in preferred order and that DNS server will be correct whatever Prefix I will get from my provider.

C:\Users\chris>nslookup tinuviel
Server:  firewall.home.local
Address:  fe80::6662:66ff:fe21:b957

Name:    tinuviel.home.local
Address:  192.168.0.179
So I personally think that this is the best setup as it combines advantages of both using RA and DHCPv6 for the reasons mentioned in the howto in the first page.

Thanks again @meyergru for bringing all this together.

BTW:
My example is for Deutsche Telekom consumer fibre with Telekom Modem (not DSL Router). The OPNsense is directly connected to the fibre modem using VLAN7 and PPPoE configuration.

Thanks for the detailed description and tutorial.

If I understnd correctly, your ISP is delegating /56 to you, and then each of your VLANs is getting /64 assigned. Is that right?
Could you share how is your /var/etc/dhcp6c.conf look like? Either my OPNsense is destroyed after my experiments or something didn't work for me, because with PPPoE for IPv4 and DHCPv6 for IPv6 the dhcp6c is not starting, nor the config is generated. Once I created it manually i could get (almost) everything, but it required lot of manual configuration. So I wonder what is the OPNsense script generating after you configured it and have it working.

Thanks,
M.

For me, it looks like this:

interface pppoe0 {
  send ia-pd 0; # request prefix delegation
  request domain-name-servers;
  request domain-name;
  script "/var/etc/dhcp6c_wan_script.sh"; # we'd like some nameservers please
};
id-assoc pd 0 {
  prefix ::/56 infinity;
  prefix-interface pppoe0 {
    sla-id 77;
    sla-len 8;
    ifid 1234;
  };
  prefix-interface igc0_vlan5 {
    sla-id 5;
    sla-len 8;
  };
  prefix-interface igc0_vlan4 {
    sla-id 4;
    sla-len 8;
  };
  prefix-interface igc0_vlan7 {
    sla-id 7;
    sla-len 8;
  };
  prefix-interface igc0_vlan10 {
    sla-id 10;
    sla-len 8;
  };
};


@SerErris: If you specify "Stateless", the only reason to specify DHCPv6 ranges would be a syntactic one - iff DHCPv6 does not work without it, albeit the adresses are in fact assigned via SLAAC.

I understand that Windows prefers DHCPv4-provided DNS servers over RA-provided ones, yet: both usually point to the same DNS server and - either way - can provide DNS answers for both IPv4 and IPv6. And if you are on IPv6-only, you do not have a conflicting IPv4 DNS server, either.

So why use DHCPv6 in this scenario? I can follow that if your clients cannot handle DNS via RA (RDNSS option), then you would have to use DHCPv6 (again, with IPv6 only). That is not the case for Windows, though and personally, I have never met such clients (more often, old clients do not speak IPv6 at all).

I still think that "Unmanaged" mode is the easiest way to go.

I still use IPv4 only for DNS in networks with clients and SLAAC/DHCPv4. In the data centre servers get their static configuration via Ansible.

Thank you everyone for the amazing amount of information in the above posts on this topic. Need to read each post carefully and then get to playing around with my setup.

Thank you all...

@SerErris Ticking "Do not send any DNS configuration to clients" in the RA settings is generally not recommended. It will prevent devices without DHCPv6 support (Android etc.) from acquiring IPv6 DNS servers.

The DHCPv6 server does not require an address range. But stateless DHCPv6 requires clients to send information request messages for acquiring DNS settings. I'm not sure whether Windows does that, especially when DHCPv4 is available. Windows preferring IPv4 DNS servers over IPv6 DNS servers learned through RAs is a well-known issue.
Of course, you don't have these issues in an IPv6-only network. ;-)

@meyergru VLANs are something I would consider essential. But you're right that you can live without them in a bare minimum home network, where dual-stack might indeed be the better "just works" option.
ISPs not providing NAT64 gateways is unfortunate, yes. But there are some very reliable public ones.

The proof is in the configuration.

If I do not enter a range it simply does not work. If you tell me Linux commands for any dhcp-client to verify that, it should not even work on Linux. But I do not know how to just ask a dhcp server and print the information to console vs. using it to actually set an interface.

RA is just disabled to check the DHCPv6 setting ... it does not make any difference if I do enable it or not. As long as DHCPv6 is not sending out DNS server, Windows will ignore everything from RA for name resolution and use DNS server from DHCPv4. That is a Windows problem and I agree that RA should be configured as well (actually both).

But again you can test DHCPv6 on your own. Whatever you enter into DNS server - without anything in Range - DHCPv6 will just not work and I mean at all.

I disabled IPv4 on the Windows Server completely and RA, and I got exactly nothing from the DHCP Server, which I should get.

All in all i think we do have a bug in DHCPv6, that it actually does need a range if you do manual configuration and it just does not check it. The consistent behaviour however should be to apply the default if you do not enter anything, which would be the full available range. That is exactly what DHCPv6 does if you do not manually configure the whole IPv6 part.

However the problem is, you cannot instruct the DHCP Server then to use the link local address, and every time the IPv6 prefix changes the Windows machines will not be able to resolve any name any longer.

Quote from: meyergru on February 19, 2025, 04:16:31 PM@SerErris: If you specify "Stateless", the only reason to specify DHCPv6 ranges is a syntactic one - DHCPv6 does not work without it, albeit the adresses are in fact assigned via SLAAC.

I understand that Windows prefers DHCPv4-provided DNS servers over RA-provided ones, yet: both usually point to the same DNS server and - either way - can provide DNS answers for both IPv4 and IPv6. And if you are on IPv6-only, you do not have a conflicting IPv4 DNS server, either.

So why use DHCPv6 in this scenario? I can follow that if your clients cannot handle DNS via RA (RDNSS option), then you would have to use DHCPv6 (again, with IPv6 only). That is not the case for Windows, though and personally, I have never met such clients (more often, old clients do not speak IPv6 at all).

I still think that "Unmanaged" mode is the easiest way to go.

As long as you use unmanaged the IPv6 DHCP will never be used at all for anything in Windows. That is just the fact. It might not be important for the reasons you outlined.

However I do want to get IPv6 DNS propagated as link local, so that it does NOT change. And nothing I do will ever change that correctly. And yes as soon as you do congiure DHCPv6, you need to enter a valid range. No range will just still disable the DHCPv6 - or maybe it just does not answer any requests, because of whatever reason.

So my setup will get both worlds the exact same thing. To manage everything correctly you actually need DHCPv6 to deliver a DNS server entry for IPv6 and this is actually where I stuck, because I was not aware of the range issue.

Now with range in place it does exactly what I want.

Quote from: SerErris on February 20, 2025, 12:26:21 PMHowever I do want to get IPv6 DNS propagated as link local, so that it does NOT change. And nothing I do will ever change that correctly.

According to this posting: https://www.reddit.com/r/ipv6/comments/1h40fad/windows_11_is_supporting_rdnss_now/ , Windows 11 now supports RDNSS via RA correctly, even with DHCPv4 still enabled.

But anyway, as I pointed out:

- If you have dual-stack, then it does not matter if you contact your DNS server via IPv4 or IPv6, so the priority of DHCPv4 vs. RDNSS does not matter, even without the mentioned fix, as long as both IPs point to the same DNS server instance.

- If you have IPv6-only, then even before the fix mentioned, Windows will accept RDNSS in absence of DHCPv4. And you can specify any DNS server addresses you like in the router advertisement section - which includes link-local IPs.

So again, you miss nothing with SLAAC in "Unmanaged" mode either way - at least for Windows and probably most other clients.

Only with clients that do not handle RDNSS, will you have to use "Stateless" mode and make DHCPv6 work (apparently by formally including an IP range that is not really used with "Stateless" mode).

Yes Windows does support RDNSS as shown in the screenshot of the reddit post.

However it will never use it as long as it has a DNS server entry from DHCP. That is what I wrote. And again - yes I am aware that this is not a real issue on Windows as I anyhow have dual stack and even in single stack this would now work flawless (tested and works).

However to make a fully universal solution you actually should setup both and that inludes a statefull DHCPv6 (assisted) with range AND DNS server.

This is what I have setup now and it works as expected.

Thanks for all the work you put into it and the answers provided. Was really helpful to get myself sorted on this (still new) topic.

Quote from: SerErris on February 20, 2025, 12:21:38 PMBut again you can test DHCPv6 on your own. Whatever you enter into DNS server - without anything in Range - DHCPv6 will just not work and I mean at all.

I disabled IPv4 on the Windows Server completely and RA, and I got exactly nothing from the DHCP Server, which I should get.

I just tested it (again) and it works just fine.

In OPNsense 25.1.1:
- disable the DHCPv4 server
- set Router Advertisements to "Stateless" and check "Do not send any DNS configuration to clients"
- enable the DHCPv6 server, don't enter an address range, but enter DNS servers

Hosts will now configure IPv6 addresses using SLAAC and request DNS servers via stateless DHCPv6. I've tested this with Windows (11 Pro 24H2 build 26100.3194) as well as OPNsense (25.1.1, WAN set to SLAAC).

Quote from: SerErris on February 20, 2025, 12:21:38 PMThe consistent behaviour however should be to apply the default if you do not enter anything, which would be the full available range.

Not at all, this would make it impossible to use stateless DHCPv6.

Tested again - does not work here. I do not get any DNS name as soon as I do not enter any range, regardless what RA mode I have - RA statless or any other mode. Never getting an DNS entry from DHCPv6.

But anyhow - does not matter, my problem is solved.

Regarding the things that would make different modes impossible to use. I do understand that point. However the documentation should really talk about this. By now to much information is just things you actually need to know. This is not good for any product. A little bit broader description in the manual to describe all the different modes and which setting is meant to do what would be great. Esp. as a lot of technologies work quite different in IPv6 than in IPv4 and transfering knowledge from IPv4 to IPv6 does not work very well, as I figured out by myself :-(