"Recent posts
#1
26.1 Series / Re: Options to stabilize prefi...
Last post by OPNenthu - Today at 02:48:06 AMQuote from: Javier® on Today at 02:30:25 AMForgive me if I've been overly enthusiastic.Not at all. I welcome the suggestions, and thank you.
And yes people here tell me all the time how my ISP is terrible for not following RIPE recommendations for a static /48. I think this forum is heavily skewed toward non-U.S. countries where ISPs are maybe more consumer friendly and less profiteering :) My ISP is one of the larger ones here and they commonly do this, unless you pay for a business plan.
#2
26.1 Series / Re: Options to stabilize prefi...
Last post by Javier® - Today at 02:30:25 AMOne of the biggest problems with IPv6 is ISPs, in theory, they should assign a fixed prefix.
The only thing I've noticed with this configuration is that IPv4 DNS is used more. But the faster of the two still works, and it does depend a lot on the client.
NAT in IPv6 isn't from ULA to global, it's global to global, I think.
Forgive me if I've been overly enthusiastic.
Thank you OPNenthu
The only thing I've noticed with this configuration is that IPv4 DNS is used more. But the faster of the two still works, and it does depend a lot on the client.
NAT in IPv6 isn't from ULA to global, it's global to global, I think.
Forgive me if I've been overly enthusiastic.
Thank you OPNenthu
#3
26.1 Series / Re: Options to stabilize prefi...
Last post by OPNenthu - Today at 02:18:42 AMThis seems fuzzy. I asked ChatGPT (but I don't trust it):
So I guess it depends a lot on the client.
I know that Happy Eyeballs will choose the faster of the two, but I didn't think that clients would even try the ULA route if there is no GUA and IPv4 was available.
(And of course, if the destination is IPv6 only then it can't use IPv4.)
---
Anyway, another good alternative method to keep in my toolbox. Thanks again.
To reiterate though the only problem I'm seeing with DHCPv6-PD so far is the premature deprecation of the prefix when the modem reboots and gives me the same prefix again. I think there is a bad assumption built into the stack that dynamic IPv6 means a new prefix every time. That's just not true.
Quote1. ULA vs Global IPv6
If the client only has a ULA (fc00::/7) and the destination is a global IPv6 address, RFC 6724 technically prefers matching scopes. That can:
- De-prioritize ULA for global destinations
- But many real-world stacks still try IPv6 first if it appears usable
So I guess it depends a lot on the client.
I know that Happy Eyeballs will choose the faster of the two, but I didn't think that clients would even try the ULA route if there is no GUA and IPv4 was available.
(And of course, if the destination is IPv6 only then it can't use IPv4.)
---
Anyway, another good alternative method to keep in my toolbox. Thanks again.
To reiterate though the only problem I'm seeing with DHCPv6-PD so far is the premature deprecation of the prefix when the modem reboots and gives me the same prefix again. I think there is a bad assumption built into the stack that dynamic IPv6 means a new prefix every time. That's just not true.
#4
26.1 Series / Re: Options to stabilize prefi...
Last post by Javier® - Today at 01:53:02 AMWell, the problem is that the connection is now IPv4 and IPv6. For me, managing the local network with ULA is easier, just like with IPv4, and offers greater control. If only IPv4 or IPv6 existed, we wouldn't have this problem.
It's easier to reach a host the way it's always been done with IPv4
Having each customer with only one LLA address and two ULA addresses is cleaner
Stateless Address Autoconfiguration (SLAAC, SOII)
MacOS and OpenBSD use Temporary and Semantically Opaque Interface Identifiers by default. Ubuntu Linux uses stable addresses for wired links, and temporary for wireless interfaces. FreeBSD and Alpine Linux use EUI64.
Complicated :)
It's easier to reach a host the way it's always been done with IPv4
Having each customer with only one LLA address and two ULA addresses is cleaner
Stateless Address Autoconfiguration (SLAAC, SOII)
MacOS and OpenBSD use Temporary and Semantically Opaque Interface Identifiers by default. Ubuntu Linux uses stable addresses for wired links, and temporary for wireless interfaces. FreeBSD and Alpine Linux use EUI64.
Complicated :)
#5
26.1 Series / Re: Options to stabilize prefi...
Last post by OPNenthu - Today at 01:44:59 AMQuote from: Javier® on Today at 01:11:44 AMI don't know if you understand the concept.
That's very likely :)
I understood that source-hash means each client gets a unique address from the NAT pool: https://www.openbsd.org/faq/pf/pools.html
I'm still missing something about why the client chooses the (from its perspective) ULA address when it has an IPv4.
#6
Tutorials and FAQs / Re: [HOWTO] Configure WAN MTU ...
Last post by wp - Today at 01:28:15 AMQuote from: hushcoden on March 20, 2026, 05:10:01 PMI've got my new FTTP connection (PPPoE with no VLAN) and in the WAN interface I can see "Calculated PPP MTU: 1492" and I hope I can bring that value up to 1500.
Reading the first post, I should also set the MTU on my ONT, but I have no access to its GUI, so hopefully it won't be a problem.
The only thing I can do is clicking on the WAN interface -> point-to-point configuration - > Advanced -> Show advanced options -> MTU = 1508
Is that it?
Tia.
The ONT is usually from your ISP which doesnt allow a enduser to change things on it. So settings the WAN interface to 1508 should cover it. You can verify it with the 1472 ping (exact syntax is in this topic), if you get a reply all is ok.
#7
Tutorials and FAQs / Re: [HOWTO] Configure WAN MTU ...
Last post by wp - Today at 01:14:00 AMGot it working, so removed this post. :)
#8
26.1 Series / Re: Options to stabilize prefi...
Last post by Javier® - Today at 01:11:44 AMWhen using a pool with a prefix, each local client accessing the internet is assigned an address within the pool, each client has a different address. I don't know if you understand the concept.
match out on egress inet6 from (igc1:network:2) to any nat-to 2a01:xxxx:xxxx:xxxx::/64 source-hash 0x1ab50493a660a20f6dbcbe662ee9fd
ftp -o - -V -M https://myipv6.addr.tools/
2a01:xxxx:xxxx:xxxx:f277:1996:89b8:81ce
match out on egress inet6 from (igc1:network:2) to any nat-to 2a01:xxxx:xxxx:xxxx::/64 source-hash 0x1ab50493a660a20f6dbcbe662ee9fd
ftp -o - -V -M https://myipv6.addr.tools/
2a01:xxxx:xxxx:xxxx:f277:1996:89b8:81ce
#9
26.1 Series / Re: Options to stabilize prefi...
Last post by Javier® - Today at 12:38:33 AMThanks to you. It's just an idea, it involves using IPv6 like IPv4. It works well.
Such a configuration does not prioritize IPv4 over IPv6, IPv6 connections are used when a server supports them. This is normal.
Such a configuration does not prioritize IPv4 over IPv6, IPv6 connections are used when a server supports them. This is normal.
#10
26.1 Series / Re: Options to stabilize prefi...
Last post by OPNenthu - Today at 12:12:52 AMThanks for sharing @Javier, it was a good read and I bookmarked it. I share that administrator's frustrations with regard to dynamic prefixes and tracking SLAAC clients. A silver lining though: the hostwatch service can potentially help with client tracking by enriching DNS with SLAAC addresses, for instance, in future OPNsense releases. Also, Dnsmasq can already register SLAAC hosts as long as they are using DHCP(v4) and also not using privacy extensions.
However this method is nothing but ULA addressing with NAT(66), I think. It skirts the problem I mentioned and I'd rather fix it at the source because one of my goals with IPv6 is to not use NAT.
I asked a similar question regarding NPTv6 and the issue is that ULA addressing would not be used at all for outbound connections when IPv4 is also available (which on my network it is).
However this method is nothing but ULA addressing with NAT(66), I think. It skirts the problem I mentioned and I'd rather fix it at the source because one of my goals with IPv6 is to not use NAT.
I asked a similar question regarding NPTv6 and the issue is that ULA addressing would not be used at all for outbound connections when IPv4 is also available (which on my network it is).
