I'm trying to get a newly created Ubuntu 26.04 Server VM (running on Proxmox VE) to properly process DHCPv4 Option 108 (ipv6-only-preferred) served by an OPNsense / Kea DHCPv4 router using router advertisements set to unmanaged.

It is getting the ipv6 via SLAAC as expected and Apple devices and other clients on the same VLAN process Option 108, drop IPv4, and transition to IPv6-only mode so I have KEA configured correctly. However, Ubuntu Server continues to accept and hold onto its IPv4 lease

This is a newly installed ubuntu server 26.04 VM. AI has ran me thru several trys and it has not succeeded.

I'm using Vodafone as my ISP and I'm seeing what appears to be DNS filtering/interference.

The IPv6 resolver works perfectly:

$ dig -t AAAA google.com @2001:4860:4860::8888

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58402
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;google.com.      IN    AAAA

;; ANSWER SECTION:
google.com.177    IN    AAAA    2a00:1450:4003:810::200e

;; Query time: 20 msec
;; SERVER: 2001:4860:4860::8888#53(2001:4860:4860::8888) (UDP)
;; WHEN: Wed Sep 02 21:22:41 CEST 2026
;; MSG SIZE  rcvd: 67

However, querying Google's DNS server over IPv4:

$ dig -t AAAA google.com @8.8.8.8

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1220
;; QUESTION SECTION:
;google.com.      IN      AAAA

;; Query time: 16 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Wed Sep 02 21:26:53 CEST 2026
;; MSG SIZE  rcvd: 67 

But with trace, the AAAA register appears:

$ dig -t AAAA google.com @8.8.8.8 +trace

;; global options: +cmd
.6789INNSl.root-servers.net.
.6789INNSc.root-servers.net.
.6789INNSa.root-servers.net.
.6789INNSi.root-servers.net.
.6789INNSj.root-servers.net.
.6789INNSk.root-servers.net.
.6789INNSg.root-servers.net.
.6789INNSe.root-servers.net.
.6789INNSf.root-servers.net.
.6789INNSd.root-servers.net.
.6789INNSb.root-servers.net.
.6789INNSm.root-servers.net.
.6789INNSh.root-servers.net.
.7122INRRSIGNS 8 0 518400 20260915050000 20260902040000 57780 . LWJGyncex/6vaD/0AWFuPl2Ng7NFGVERJ7xgwJ/P75OBT8suIB0TnK5E 7RowXHInpGA2UcDK/AxCOKUXsUtSd1OeUnQBZLE4m0YWKjlCQ6+F0UrG oMWTGZuJMSrj9WxolONFlWCfm2cnGOF6ZNirmYzc7L5ZqNd6zDFtJE/E jcBvUdvFsj90Yq7ac59GrXMAP9lzY2E95YNI6atc0lwcN+IHXIzhzQWx HR9Df8SjP64V+4vujb61r2m8V0zxUYom4Fx9M572zuS3o0G9mVfqFNaW KLGQGiWA1fvD/Rd5YcBhCW2d+f5iWb1lNJ8i5PpCp88zk25Zsku8J4pd PuBarg==
;; Received 693 bytes from 8.8.8.8#53(8.8.8.8) in 4 ms

com.172800INNSg.gtld-servers.net.
com.172800INNSa.gtld-servers.net.
com.172800INNSc.gtld-servers.net.
com.172800INNSe.gtld-servers.net.
com.172800INNSb.gtld-servers.net.
com.172800INNSk.gtld-servers.net.
com.172800INNSf.gtld-servers.net.
com.172800INNSm.gtld-servers.net.
com.172800INNSj.gtld-servers.net.
com.172800INNSd.gtld-servers.net.
com.172800INNSh.gtld-servers.net.
com.172800INNSi.gtld-servers.net.
com.172800INNSl.gtld-servers.net.
com.86400INDS19718 13 2 8ACBB0CD28F41250A80A491389424D341522D946B0DA0C0291F2D3D7 71D7805A
com.86400INRRSIGDS 8 1 86400 20260915170000 20260902160000 57780 . sR14KQ7PJ5pG/gi0HseqXQGU1m6cNAQ58TsDeo3Ua2J5r5GAU4feKjOg 7VsdMFLHyoP8hZRg4+FXTPb0qOt1tHUqAtReiZ7E7OTeFAxPtm4nb9V/ aE3AvGCxR+sUC8OWa1R7nswb/+QlTwiu8NyywxyKA+XvHDHcflANfqTC qLlYsutoOmGtB9KGYCq25aauhy1/FpqLVPkKJ7ERWmIjyLR4RXdnbcvp QmCxFkJMVMNqVeHTaGH9PgDzn1zeCwchUru+yPQn/JUL4+SPSpUirJcw 1kcIx8ROliCCeSwmrpcMYZQTpvl/k08eZK5+IYsmI9yJdl5QKhpjs3Fn J8VZow==
;; Received 1198 bytes from 2001:500:2f::f#53(f.root-servers.net) in 12 ms

google.com.172800INNSns2.google.com.
google.com.172800INNSns1.google.com.
google.com.172800INNSns3.google.com.
google.com.172800INNSns4.google.com.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 900 IN NSEC3 1 1 0 - CK0Q35HRS4H76G6CHNB9414CJN6S5UPL NS SOA RRSIG DNSKEY NSEC3PARAM
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 900 IN RRSIG NSEC3 13 2 900 20260907002613 20260830231613 41446 com. sg9EOEcu6SU4/ORJtbNXqgcb5RzZqJQmdWxcqkGAZOQ3FLF/Sx7pE1hn Yv/Skldv5Z0zZJ0G4tqCovTBylPKdQ==
S84BOR4DK28HNHPLC218O483VOOOD5D8.com. 900 IN NSEC3 1 1 0 - S84BR9CIB2A20L3ETR1M2415ENPP99L8 NS DS RRSIG
S84BOR4DK28HNHPLC218O483VOOOD5D8.com. 900 IN RRSIG NSEC3 13 2 900 20260908012131 20260901001131 41446 com. xUh2VrKslVK6kTUnET647tTAQSz+xF0jbkDAik9EXrcXeC+SiAxOrNEC xMd9ksojMnBs6+Ursf+99GmTxlpnjg==
;; Received 644 bytes from 2001:503:d2d::30#53(k.gtld-servers.net) in 44 ms

google.com.38332INNSns4.google.com.
google.com.38332INNSns2.google.com.
google.com.38332INNSns1.google.com.
google.com.38332INNSns3.google.com.
;; BAD (HORIZONTAL) REFERRAL
;; Received 139 bytes from 216.239.34.10#53(ns2.google.com) in 8 ms

;; communications error to 216.239.34.10#53: timed out
google.com.38327INNSns2.google.com.
google.com.38327INNSns3.google.com.
google.com.38327INNSns1.google.com.
google.com.38327INNSns4.google.com.
;; BAD (HORIZONTAL) REFERRAL
;; Received 139 bytes from 216.239.34.10#53(ns2.google.com) in 4 ms

google.com.300INAAAA2a00:1450:400c:c02::65
google.com.300INAAAA2a00:1450:400c:c02::64
google.com.300INAAAA2a00:1450:400c:c02::8a
google.com.300INAAAA2a00:1450:400c:c02::8b
;; Received 151 bytes from 2001:4860:4802:38::a#53(ns4.google.com) in 36 ms

With other DNS servers, like 1.1.1.1 or 9.9.9.9 equal response, Answer: 0.

Is there a way to confirm it from the client side in any other way?

Thanks,

Finally I got Jool working on my VM, a clone of my primary DNS server, it's got Unbound and Jool, aside from Pihole, the EdgeRouter sends all the requests from 64:ff9b to our VM using the ula of that machine!

Don't mind the ipv4 on the desktop VM, it's for SSH to throw quick commands, network manager hasn't been too kind today!

Sorry I had to share the excitement, I've been trying since April!

In case you ever wanted to know whether a Website ist IPv6-only ready, here is a tool to test that. Let’s see what examples of prominent Web sites with IPv6 gaps we find….

So this has been the only pain point for me in the transition. IPv4 wasn't great here either, but on the DHCP leases at least there were some hostnames. But this seems to be next to zero with NDP.

It's especially tricky when I'm looking at nginx access logs - I'd like an easy way to figure out what device is what.

Router advertisements are coming from pfSense, and Technitium is my DNS resolver by the way.

Turning off DHCP seems the most obvious and straightforward, and that's what I've done on my Linux workstation after installing clatd, works like a charm.

The less straightforward devices are the ones without this option. I've just blocked their MAC addresses from getting DHCP leases in pfSense, and that works but definitely doesn't scale well and I have to keep a notepad of which is which.

Pfsense also supports whitelisting instead but too many devices require v4 sadly.

I wish pfsense just let me pull up the lease list and block devices right from there. Does other router software support this?

Or is there a better way?

Bonjour je sais que cest quasi impossible avoir une identite full name dune ipv6?

#ipv6

Just found out the server provider I use doesn't support IPv6 unless you have one of their expensive dedicated servers provider is gthost.com. This sucks

Is there a way to fix this? do i need ipv6 to join xbox parties through pc? so many questons and ive been trying to troubelshoot for the last 72 hours lol

So im trying to setup a ipv6 only LAN network. Have podman, tyga,unbound , radvd setup and running.

I have a seperate dns64 dns address as well. Everything is fine except my android phone drops ipv4 after detecting option 108, but then doesnt turn on clat

It sees everything like my nat 64etc needed. So that leaves me with either android 15/hyperOS 2 has a problem, or idk relly. I have exhausted , i think , almost all options

W3Techs now shows that 60% of the top 1000 sites use IPv6.

https://w3techs.com/technologies/breakdown/ce-ipv6/ranking

The more popular a site is, the more likely it is to use IPv6.

W3Techs also has graphs showing the historical graph.

Percentage of websites supporting IPv6 on various ranking levels

https://w3techs.com/technologies/details/ce-ipv6

Salut. Je pense à créer un site qui liste les bons et mauvais FAI pour l'auto-hébergement—couvrant à la fois IPv6 et IPv4—pourrais-tu partager tes expériences concernant IPv6 et l'auto-hébergement avec tes FAI ?

Quel est le nom du FAI ?

Ils fournissent seulement un préfixe IPv6 de /64, ou bien offrent-ils plus—comme un /60, /56, ou /48 ?

La pile IPv6 du routeur du FAI est-elle fiable, ou présente-t-elle des bugs occasionnels ?

Le routeur fourni par le FAI est-il obligatoire, ou peux-tu connecter ton propre routeur directement ?

Le FAI propose-t-il IPv6, ou seulement IPv4 ? (Je devrais probablement avoir commencé par cette question.)

(Si tu as des infos concernant IPv4 aussi, ça m'intéresse.)

Dans quel pays se trouve le FAI ?

Le FAI a t'il une limite de données ?

Bonne journée ou soirée.

Anyone here with dual stack experience on GWN7672 and GWN7574 APs? I found that I had to disable MLO to get IPv6 working.

The APs are configured pretty basic in bridge mode with WPA2/WPA3.

Ping6 worked, netcat -6 showed no errors, but doing a curl -6 revealed traffic stopped after or during the TLS handshake.

Raised a case with Support, but wondering if anyone else has run into this.

Back when Google VPN was included in my Google Drive Subscription, I really liked to use it because it was one of the few VPNs that supports IPv6, and it was also very seamless on my device. Sadly Google killed it.

However, I just got myself a Pixel, which has Google VPN included. However, now I don't get an IPv6 address. Has Google removed IPv6 from its VPN? Cause that'd be a bummer.

Short version: How do I format an IPv6 address in my email SPF record to enable Microsoft Direct Send?
(I know, ask google, but I've been looking for an excuse to make a post about dual-stacking my office.)

Long version:
I am the sole IT technician for a 20 person office, as long as the emails keep going through, I have the freedom to do what I want, tech-wise.

I used this freedom to dual-stack my office this summer, and considered my office fully moved to dual-stack 4 weeks ago.

I have a Fortigate 60F boundary router, and an on-prem active directory on a Server 2022 computer, and about 20 users with their own computers.

Because I have the active directory, I need the Server 2022 as my DNS server, I can't use the Fortigate for DNS, and thanks to past experiences, I wanted ULA's assigned as well as GUA's so the internal network would stay up if the internet (and GUA's) goes down. (Ignoring the fact the IPv4 side would keep things functioning internally.)

Figuring out how to get the Fortigate to assign both the GUA and ULA took a bit, as well as getting the Server 2022 assigned as the DNS server was another sticking point, but that was it really.

Overall, it was pretty easy to get IPv6 rolled out, the IPv4 network never even hiccuped, and now my office is fully dual stacked with no Nat or workarounds on the IPv6 side.

Admittedly, we are fully a Microsoft shop, and Microsoft fully supports IPv6 (at least in the services we use) so that probably made my life easier.

Although Microsoft fully supporting IPv6 caused my problem today. To enable Microsoft Direct Send, so old scanners and faxes can send emails to the cloud email service, you have to add your office's public IP to your SPF record as an anti-spam measure.

Most scanners in my office don't support IPv6, so they continued to chug away, sending their emails from the IPv4 address, and all was well as my SPF record has said IPv4 address in it.

Until this other scanner today was used, which does support IPv6. So that scanner stopped sending emails because my public IPv6 record is not in my SPF record, so the email was coming from my IPv6 address, not my IPv4 address, and Microsoft was dropping the email as spam.

Adding my IPv6 address to the SPF record is not a big deal, just annoying with the DNS propagation delay, so I can't test it immediately.

Although moving to dual-stack has also helped prevent a critical incident last week. An employee plugged in a device with a malfunctioning DHCP client, where it would request an IPv4 address, the server would assign it, but the client would not accept it. So it would time out after 30 seconds, then send another DCHP request, the DHCP server would assign the next address, and repeat until my DHCP address pool was exhausted.

I think the bad device had 25 IPv4 addresses assigned on the DHCP server by the time I fixed the issue.

But Microsoft fully supports IPv6. The in-progress Teams video call the company owner was on never stuttered, continuing to work over IPv6 even though the IPv4 network was unstable and his computer had lost its IPv4 address.

Turned a (potentially) major "the internet is out, fix it!" incident into a minor "why won't these specific webpages load?" problem.

Having said that, looking at my network and what is connected to it, it is going to be a long time before I am in a position to even consider disabling IPv4, too much stuff still requires it.

But chalk my office up as a "100% IPv6 Network"!

Well, as much as dual-stack counts for that anyway.

Hi,

I'm trying to understand how IPv6 prefix delegation is supposed to work on 2degrees broadband (originally MyRepublic).

I'm using a UniFi Gateway Ultra (UCG-Ultra) and have IPv6 working, but the problem is that my router appears to receive only a /64 delegated prefix, rather than the /56 that 2degrees documentation indicates should be available.

I have 5 VLANs, so ideally I would expect something like:

ISP delegates: xxxx:xxxx:xxxx:xx00::/56

VLAN 10: xxxx:xxxx:xxxx:xx10::/64
VLAN 20: xxxx:xxxx:xxxx:xx20::/64
VLAN 30: xxxx:xxxx:xxxx:xx30::/64
VLAN 40: xxxx:xxxx:xxxx:xx40::/64
VLAN 50: xxxx:xxxx:xxxx:xx50::/64

Instead, the gateway seems to receive something equivalent to:

xxxx:xxxx:xxxx:xxxx::/64

That prefix can be assigned to one VLAN, and IPv6 works correctly there, but obviously I can't subdivide a /64 into additional normal SLAAC /64 networks for the other VLANs.

DHCPv6-PD capture

On the WAN VLAN (eth4.10) I can see the UCG-Ultra sending DHCPv6 Solicit packets with both IA_NA and IA_PD:

IP6 fe80::[REDACTED].546 > ff02::1:2.547:
dhcp6 solicit
  (elapsed-time 0)
  (option-request ...)
  (client-ID hwaddr type 1 [REDACTED])
  (reconfigure-accept)
  (Client-FQDN)
  (IA_NA IAID:1 T1:0 T2:0)
  (IA_PD IAID:1 T1:0 T2:0
    (IA_PD-prefix ::/56 pltime:0 vltime:0))

The ISP responds and the DHCPv6 exchange continues through Advertise → Request → Reply, but the delegated prefix I eventually see on the gateway is a /64, not a /56.

The UniFi logs also show the delegated prefix being installed on one of the LAN bridges and later removed:

Removing PD prefix [REDACTED]::/64 from interface eth4.10

Removing PD address [REDACTED]::/64 from interface br30

Removing PD route [REDACTED]::/64 from interface br30

I also see odhcp6c being restarted/suspended/resumed during this process:

Suspending odhcp6c-eth4.10
Resuming odhcp6c-eth4.10

So DHCPv6-PD itself definitely seems to be working — the issue is specifically the size of the delegated prefix.

What I'm trying to determine

Has anyone using 2degrees / former MyRepublic fibre successfully received a /56 via DHCPv6-PD?

In particular:

• Does 2degrees actually delegate a /56 to residential customers?
• Do I need to explicitly request a /56 rather than letting UniFi use Auto?
• Is there a specific DHCPv6-PD configuration required on UniFi?
• Does 2degrees perhaps delegate only /64 unless a particular prefix length is requested?
• Is there anything specific to former MyRepublic connections/accounts that could explain this?
• If you're using UniFi with multiple VLANs on 2degrees, how have you configured IPv6?

My expected setup is basically:

2degrees
    |
    | DHCPv6-PD /56
    |
UCG-Ultra
    |
    +-- VLAN 10 --> /64
    +-- VLAN 20 --> /64
    +-- VLAN 30 --> /64
    +-- VLAN 40 --> /64
    +-- VLAN 50 --> /64

But currently it behaves more like:

2degrees
    |
    | DHCPv6-PD /64
    |
UCG-Ultra
    |
    +-- VLAN 30 --> /64  ✓
    +-- VLAN 10 --> no global prefix
    +-- VLAN 20 --> no global prefix
    +-- VLAN 40 --> no global prefix
    +-- VLAN 50 --> no global prefix

IPv6 itself works correctly when the delegated /64 is assigned to a VLAN, so this doesn't look like a general IPv6 routing/firewall issue.

I'm mainly trying to figure out whether this is a 2degrees DHCPv6-PD issue, a UniFi configuration issue, or expected behaviour on former MyRepublic connections.

Would be particularly interested in seeing the WAN IPv6 / DHCPv6-PD settings from anyone running 2degrees with UniFi and multiple VLANs.

Thanks!

Update: The issue was the ISP configuration. They fixed it and now I have ipv6 on all my networks

I host a a lot of mobile proxies and LYCA mobile was an easy goto for IPv6 as their Parent company EE only offers IPv6 on contract packages.

Im not really looking for help as I know nothing can be done. I'm just curious if anyone knows anything about why my my old sims are fine work dual stack but any sim card I activate now has a completely different IP pool and no IPv6

Hello everyone,

I'm currently trying to get multihoming without BGP on OPNsense to work. Uplink A has a /56 delegation that I use to provide GUAs for each device. Uplink B is using the cellular network and receives a /128 GUA and a /128 ULA. If uplink A goes down I want to route the traffic with NAT over uplink B. None of the IPv6 addresses are static.

I've been setting it up and it works if I specify the /128 GUA as a translation address. If I just specify the interface address it will unfortunately translate to the ULA and not work. Is there a way to fix this without scripting?

Looking forward to your responses!

Hi r/ipv6,

About 8 months ago I shared my IPv6-mostly home lab and the lessons I had learned while moving my network toward IPv6-first operation. Since then, the lab has evolved quite a bit, and I thought I'd share some of the more interesting additions and implementation details.

The goal of this project is still the same: run day-to-day services over IPv6 wherever possible while providing transparent access to IPv4 resources only when necessary. Rather than simply making IPv6 "work", I've been trying to understand how the transition technologies actually behave and how they can be combined into a practical network.

Some of the additions since my last post include:

• Native NAT64/DNS64 for IPv6-only clients
• 464XLAT using dedicated CLAT gateway for IPv4-only applications on an IPv6-only network.
• An internal NAT64 translator that allows IPv6-only devices to reach IPv4-only internal services (currently Plex).
• An IPv6-only transit network between translation components.
• Automatic recovery after reboot using systemd services for Jool and the required iptables steering rules.

One of the more interesting discoveries involved RFC 8781.

I wanted to keep a single PREF64 (/96) while sending only the embedded 10.0.0.0/8 addresses to a separate NAT64 translator. Linux routing made this possible by installing a more-specific /104 route for the embedded 10/8 space, while all remaining traffic continued to the primary Internet NAT64 translator.

Initially this didn't work because I was running Jool in Netfilter mode. Jool intercepted every packet destined for the /96 before Linux had a chance to apply longest-prefix routing, so the /104 route was never used.

Switching Jool to iptables mode solved the problem by allowing selective interception. Internal NAT64 traffic is now routed first by Linux to the second translator, while Internet traffic continues to be translated locally by the NAT64 gateway.

The result is a design where clients only know about a single NAT64 prefix, while the network transparently selects the appropriate translator.

Tha lab now successfully supports all three simultaneously:

• Native Internet NAT64
• 464XLAT for legacy IPv4 applications
• Internal NAT64 for IPv4-only services such as Plex

This has been a really fun learning project over the past few years. Although it's build entirely from repurposed hardware rather than carrier equipment, it is been a great way to explore how IPv6 transition mechanism interact in practice and to better understand the operational behavior behind the RFCs.

I'm happy to answer questions, and I'd also be interested in hearing how others are approaching IPv6-only or IPv6-mostly home networks.

I know, I know, the answer is 2^64 (or 2^64-1).

But how many can I realistically put on a /64 subnet without any problems?

Every time I read about the advantages of IPv6 over IPv4, bigger address space and no broadcast come up. Because broadcast is one of the reasons we usually don't use much bigger subnets than /24 in IPv4, i was wondering how much of a difference it really makes.

Do u have any experience or resources on this?

I am new to IPv6. I've used IPv4 since the late 80s so its mostly the V6 part that I have questions on.

My local ISP ( Frontier Texas region ) still does not do IPv6 so I've never really seen much need for it.. one reason I haven't paid much attention to it. Seriously... the MAJOR thing I've never liked about IPv6 is because I am old and set in my ways and I've am very familiar with IPv4 addresses and subnets.

I see:
2607:f8b0:4023:100b::64

fe80::2a13:ff4f:44ff:c1e2

fe80::fc54:ff:fe59:4166

fe80::fc54:ff:fe34:35d4

fe80::2e0:4cff:fe6a:6edd

fe80::c24:eb03:3c7d:d777

fe80::dc49:5a0:2144:8ca9

fe80::aad4:ce50:2157:56c2

and I just want to bury my head in my pillow...

I was asking google about setting up a local ipv6 network and it said that I could use:
fd00:10:12:14::31 (NIC 1 for serverA)

fd00:172:16:12::31 (NIC 2 for serverA)

fd00:10:12:14::32 (NIC 1 for serverB)

fd00:10:12:14::4 (NIC 1 for serverC)

is that True? I could have used those all along? That never occurred to me. I know that it's hex and not base 10.. but I am a visual person and I can visualize those ips just fine.

is it really that simple?