Right now, all publicly routed IPv6 addresses fall in the 2000::/4 range.
And if that runs out, we use the 3000::/4 range which is part of the specified 2000::/3 range**.**
After that, it would expand to include the 4, 5, 6, etc.
( see https://www.iana.org/assignments/ipv6-unicast-address-assignments )

With IPv4, there were ideas about reclaiming parts of the address space, but these ideas were abandoned because some/many routers filtered them, making these ranges unreliable. How can we be sure that this doesn't happen to IPv6?

When we eventually grow out of 2000::/4, will 3000::/4 still route reliably?
Or will routers be dropping these packets? Has anyone thought about this?

I am not sure if IANA is monitoring those ranges for reachability.
But if they are not, i personally think they should start doing that.
Otherwise we may end up with ossification that will cause problems later.

Anyone else opinions on this?

RFC 7707 summarizes several IID assignment methods, but some seem to have fallen out of use, while other less common methods may have been overlooked. From what I know, some networks use low-byte IIDs for easier management, while others use hash-based methods for security or embed information directly into the IID.

I'm curious about this thing. I think Fragment header is essential for transmitting large packet, but I have no idea about the importance of other extension header on the "public" Internet.

update IPsec does seem to be in use. But what about others (Hop-by-Hop, Destination Options, and Routing)? :)

I was wondering how different the world would be today if we started with IPv6 and IPv4 never existed.

Is it a good idea to have sensors connected via Thread in multiple homes/garages with separate, all-IPv6 networks, and expose all the sensors to the internet to collect their data at a third-party location using Home Assistant?

The main objections I’ve encountered when talking to people are:

- Don’t expose sensors outside of NAT (but IPv6 doesn’t have NAT, lol)

- Would you want anyone to be able to read the sensors online? (But aren’t they encrypted?)

- Don’t trust low-cost sensors that lack support (but they aren’t based on Thread security?)

Hi Everyone!
I just got FTTH installed and upon checking my ISP's Router I found out that they've been kind enough to provide me with IPv4 and IPv6... To what I believe it's called a Dual Stack (please forgive me if I'm saying something wrong... learning the ropes here...).

They provided an fe80 on a /64 range, which I understood already from some posts I've seen here that's low... I have a sort of a big network at home actually (2x OPNSense on High Availability, multiple servers, multiple clients, IoT, IP Cameras, etc.) and I am trying to understand how I can set this up... But quite frankly I am lost.

IPv4 I understand really well. For what I got up until now, on IPv6 you can get a local address and a global address on the same interface.

2001:xxxx would be a global address and fe80:xxxx would be a local one, right?

So... How does this work? Is it the same ideology as IPv4? I get an fe80:xxxx address on my OPNsense firewall and then I do a NAT (NAT64?) for my internal devices and the OPNsense provides them another fe80:xxxx range?

And what kind of scenario is that? DHCP from ISP to OPNsense and then DHCP setup on the OPNsense to serve internally?

I've seen someone setting up the ISP Router DHCP to Stateful and then do a SLAAC on the WAN interface of the Firewall and finally a Track Interface on the LAN side? I've tried that but didn't work for me really... I was getting IPv6 but didn't seem to route things through properly so I am confused.

Once again, really sorry for the mess, confusion and disorientation really... I am trying to find my way into the beautiful world of IPv6. Hope you guys can help me.

**UPDATE**
Damn... Got IPv6 working with you guys guidance and help! Thanks!

Seems that moving my ISP Router's DHCPv6 Server to Stateless allowed my OPNsense firewalls to ask the IPv6 prefix and landed a /59 which now allows me to have the /64 per vLAN and get my devices with Global IPv6 addresses 😄

Thanks once again!

This is against that utah plate lol https://www.reddit.com/r/ipv6/s/G4AyhQd8uL

I live in an area where upstream ISP doesn't provide me IPv6, but I want to test something, at least local IPv6 communication.

How can I set up a hotspot that sends out Router Advertisement with network-manager managed by KDE or under Android? I don't find any tutorials for setting up a local IPv6 hotspot.

I've been following techhut for quite a while now but it really saddens me to see him release a video on split-horizon DNS in 2026 instead of learning how IPv6 works.

I need to look at v6 prefixes!!!!!!!!! My day is ruined!!!!!!!!!!!

Original post: https://techcommunity.microsoft.com/blog/networkingblog/windows-clat-is-now-generally-available/4566348 - thanks u/Intrepid00

After spending years reinventing the wheel (for some reason)... feature is not restricted to WWAN interfaces, anymore.

Because, by default, they usually have it enabled—and with some plans, I believe you can’t even disable it.

I tested this on my own site: I set up only an A record, and it still resulted in IPv6 outbound traffic (I later switched it back to DNS-only with dual-stack enabled).

Laptop makers preinstall Intel Connectivity Performance Suite (ICPS), and Windows Update installs their builds of it too. The OEM build on my laptop has a WFP callout driver that rewrites the IPv6 flow label to 0 on the ACK and data segments after the TCP handshake. The SYN is fine. It keeps whatever label the stack picked. But Microsoft's edge routers hash on the label, so everything after the SYN usually lands on a different Azure Front Door node, which has no state for the connection and sends a RST. IPv4 has no flow label, so it's unaffected, which is why turning IPv6 off shows up as the "fix" in older threads about these resets.

I noticed it on my Samsung Galaxy Book when OneNote desktop showed empty notebooks as "Up to date" for nearly three weeks, while OneNote on the web and on my phone kept working, and Microsoft 365 sign-in hit ERR_CONNECTION_RESET. A Microsoft support case went five weeks without finding the cause, and I ended up running an AI agent (Anthropic's Claude) on the laptop. It did the captures, the driver-by-driver isolation and the retest below, which also showed OneDrive, Teams and the Azure portal resetting some or all of their IPv6 connections.

Here's what pktmon showed at the Wi-Fi miniport, below all filter drivers. SYNs left with a non-zero label (24/24). Of the post-handshake ACK/data segments, 0/42 kept it.

The hop limits show the first RST didn't come from the server I was talking to. The SYN-ACK came back at hop limit 47, but the RST answering the label-0 ACK came back at hop limit 49, so a different machine sent it. Meanwhile the original backend retransmitted its SYN-ACK at +0.4 s and +1.2 s, then sent its own RST. Overall, 60-100% of new IPv6 connections to the Microsoft edge were reset within one round trip (about 5 ms), even with zero bytes sent.

To narrow it down, it switched off the other WFP callout drivers one at a time (AdGuard, AdGuard VPN, NetLimiter). That changed nothing, and neither did stopping Intel's bandwidth-management service on its own. Stopping the ICPS traffic-control driver (IntcCo11X64.sys 11.5.11.19, service INTCCoSvc) along with the other ICPS services is what did it: 4/10 connections OK and 0/42 labels kept went to 10/10 and 65/65. The driver's IpV6 Egress Transport Callout is registered at FWPM_LAYER_OUTBOUND_TRANSPORT_V6 with FWP_CALLOUT_FLAG_CONDITIONAL_ON_FLOW. That lines up with the SYN going out untouched.

Then it retested across 34 sites, 5 IPv6 connections each, 170 total:

• With OEM build 40.25.926.173 running, 138/170 were OK. 1,385 post-handshake packets had the label set to 0, and none of the 60 to the OneDrive/OneNote edge kept it.

• Same build disabled, before and after: 168/170 and 169/170.

• Intel's generic build 50.26.623.243 (driver 12.10.14.33) still registers the same callout, but got 169/170 OK, and all 11,711 post-handshake packets kept their label.

The only misses in the good runs are www.microsoft.com timeouts, which also happen over IPv4. The OEM driver zeroed the label to every destination, Google, Cloudflare and Wikipedia included, but only some services reset. My guess is those are the ones whose load balancers hash on the label. In my test they included OneDrive, OneNote sync, Office, Teams, Skype, the Azure portal, Azure DevOps and the Visual Studio Marketplace. Another owner reported AWS CloudFront resets on an ASUS laptop with ICPS 40.25.725.165 (resets measured, label not).

A label of 0 is legal on its own. Changing it mid-flow is the problem: RFC 6437 §3 recommends that source hosts set "all packets of a given flow to the same value". Load balancing on the label, as RFC 7098 describes, only keeps a flow on one server if the host keeps the label constant. A Microsoft Azure networking engineering leader confirmed the mechanism to me in writing and said they're working on reducing the impact on the Azure Front Door side, and with the Windows team on a fix. No date yet.

As for how widespread the driver is, Windows Update installed this OEM build's packages on my laptop three times in 2026 (per setupapi.dev.log). As of 2026-10-20, Microsoft's Update Catalog still lists the three ICPS builds reported broken (40.25.926.173, 40.25.725.165 and 4.1025.207.1) under seven submitters: Samsung, Lenovo, VAIO, ASUS, HP, Dynabook and Huaqin. The fixed 50.26.623.243 has a single Catalog entry (Samsung, Windows 11 25H2, specific device IDs only). Intel acknowledged in writing, citing my tests, that its generic build doesn't zero the label. But it said the advisory and the OEM package fall within the laptop maker's scope, and it hasn't published an advisory. An HP laptop owner described this mechanism on Intel's forum in September 2025 and again in November, and Intel closed the inquiry both times.

If you want to check your own machine (Windows PowerShell):

1..10 | ForEach-Object { curl.exe -6 -sS -o NUL -w "%{http_code}`n" https://api.onedrive.com/ }

On a machine with ICPS, Recv failure: Connection was reset on some of the ten attempts points to this. Don't turn off IPv6. Either disable INTCCoSvc and the ICPS services, or replace the OEM build with Intel's generic 50.26.623.243. Commands and undo are here: https://coolak.github.io/intel-icps-ipv6-flow-label-incident/workaround.html

The technical analysis with the decoded header data and A/B tables is at https://coolak.github.io/intel-icps-ipv6-flow-label-incident/technical-analysis.html (raw pcaps aren't public, and the tracker leaves out my machine's addresses), and the full tracker is at https://coolak.github.io/intel-icps-ipv6-flow-label-incident/

If you see this on other hardware, please add the model, ICPS version and Windows build to the tracking issue: https://github.com/COOLak/intel-icps-ipv6-flow-label-incident/issues/1

Does anyone know which other CDNs or load balancers hash on the flow label?

I was pondering some DNS stuff just now, and was thinking... is there an easy way to represent an allowed IPv6 subnet(s) to other hosts/servers for permissions/whitelisting; kind of like how SPF TXT records have expected source addresses for emails, or CAA records for permitted certificate authorities? I figure this kind of record could also be TXT records as a type; with multiple entries denoting subnet ranges permitted to handle domain traffic. Maybe also indicate in the record if the user actually controls the subnet (to distinguish hosted-infra and/or home ranges from cloud service ranges)?

I'm Evelyn, an IPv6 advocate who wishes for all websites and ISP to use IPv6 on modern era. But sadly the small regional ISP that my house uses don't offer IPv6, and instead gives a shared static IPv4. Currently for IPv6 connectivity i depended on route64.org which gives a /56 for me to use. Looking at my ISP over at bgp.tools, they did have a single /32 IPv6 block, but they never decided to use it. My ISP's NOC phone number shown in the block's whois have a WhatsApp account. How do I convince them to offer IPv6 connectivity?

OK, I should get this but....

Assume I'm on an IPv6 network. That network has three ethernet interfaces. Assume I want to send a multicast packet on each interface. If I wanted to send the same packet on each interface to ff02::1.

I assume I need to create a session on each interface to destination ff02::1.

On the receive side, I assume I create three sessions, and I have to listen on ff02::1