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

[Maurice]

The "track interface" feature for NPT uses the prefix which is on-link on the selected interface. When using NPT for Internet access, this will typically be the WAN interface. This has several disadvantages; most importantly, you can only use NPT for a single LAN subnet.

What would make more sense is using a subnet of the delegated prefix (like it's done for "track interface" type LAN interfaces), but that's currently not supported.

[OPNenthu]

Comparing the available WAN interface options for DHCPv6 client config between 25.7 and 26.1, there are two new options:

- Request DNS configuration
- Send rapid commit

I noticed that the former one was enabled by default after upgrade, but I don't want the ISP DNS servers for any reason.  Under System->Settings->General I have "Allow DNS server list to be overridden by DHCP/PPP on WAN" unticked.  In that case, does this WAN setting have any effect?

The latter one seems to be an optimization to reduce the number of server<->client messages for IP configuration, but I don't see any guidance in the OPNsense docs about who should or shouldn't use this.  I think the docs are not yet updated for this (?)

https://docs.opnsense.org/manual/interfaces.html

You cannot view this attachment.

I asked ChatGPT and it said that most people should enable it if they know that they are dealing with a single DHCP server upstream, and it also claimed that cable ISPs are safe.  Thoughts on this?

[Maurice]

Under System->Settings->General I have "Allow DNS server list to be overridden by DHCP/PPP on WAN" unticked.  In that case, does this WAN setting have any effect?

The technical difference is that DNS servers are either request via DHCPv6 but then ignored by OPNsense, or they are not requested at all. There are probably very few use cases where this really makes a difference.

Not a lot to document about Rapid Commit since this is nothing OPNsense-specific, but a standard DHCPv6 feature. Whether you can use it depends on whether the upstream DHCPv6 server supports it.

Both settings are probably most relevant when dealing with very picky DHCPv6 servers.

[OPNenthu]

Thanks Maurice.  If rapid commit is a "try and see," then assuming it works, is it generally a good idea to use it?  Or are there certain cases where it's needed but should generally not be used?

Hope that makes sense.

[Maurice]

Not all clients / servers / relays properly support Rapid Commit. And it has disadvantages if there are multiple DHCPv6 servers on a network.
Other than that, if it works, it's a little more efficient than the full four message handshake.