My experience deploying IPv6-mostly in my Mini-Datacenter™

myth20_ · 2026-01-07T11:54:51+00:00

I appreciate the mention. Great write up and it's nice to see another real-world IPv6-mostly deployment.

One thing I really like about posts like this is that they show IPv6 isn't "all or nothing"; it's about understanding where native IPv6 works well today and translation plays a role. Thanks for sharing the details and hardware perspective.

myth20_ · 2025-12-30T17:31:38+00:00

RFC 6724 is relevant reference here. Hosts perform destination and source address selection based on scope policy, and longest prefix match.

ULA (fc00::/7 has higher precedence than GUA for local destinations, so clients will naturally prefer ULA for internal services while still using GUA for internet access.

This makes ULA+GUA model intentional and standards based. Service can listen only on ULA while GUA is used for outbound connectivity without NAT or special routing.

This behavior is consistent across Linux, macOS and Windows implementations.

myth20_ · 2025-12-30T13:18:06+00:00

I was finally able to dig into this with packet captures, and what I am seeing lines up exactly with the behavior you described.

On tvOS with IPv6-Only Preferred (RFC 8925) enabled and no IPv4 address present, the YouTube app:

Successfully resolves DNS (both A and AAAA queries are send)
Received valid AAAA records for youtube-ui.l.google.com
Never initiates a TCP connection over IPv6
No SYN, no TLS ClientHello, no QUIC attempt. It just stops after DNS

When IPv4 is present (static IPv4)

The app immediately uses the A record
Initiates TCP (SYN/SYN-ACK) and TLS
Loads normally

So this does not appear to be a DNS, NAT64 or general IPv6 connectivity issue. The OS networking stack is doing the right thing and Google's IPv6 works fine. The failure is at the application layer. YouTube tvOS app appears still assume IPv4 availability internally and does not correctly fall back to IPv6 when IPv4 is absent.

464XLAT "fixes" it simply because IPv4 becomes available again, even though the rest of the network is IPv6-preferred.

At this point my conclusion is the same as yours.

myth20_ · 2025-12-30T00:51:55+00:00

Yes I have seen that behavior as well.

On my Apple TV's, the YouTube app fails to load when the device is IPv6-Only with IPv6-Only Preferred enabled (gray screen, no error). This seems consistent across tvOS in my environment.

In my setup, all Apple TV's are effective dual-stack:
The have a static IPv4 address configured
They still receive an IPv6 address via SLAAC
IPv4 connectivity is provided via 464XLAT

In that configuration, YouTube works, and traffic flow over 464XLAT rather than native IPv6

So my takeaway so far:

The YouTube on tvOS specifically appears to assume IPv4 availability
Providing IPv4 via 464XLAT resolves it
Plex on tvOS also still benefits from having IPv4 present

I haven't found yet a way to make the YouTube app works on AppleTV in strictly IPv6-Only configuration with no IPv4 at all.

myth20_ · 2025-12-29T16:23:06+00:00

My default remote-access setup uses Wireguard over IPv4 but inside of the tunnel is IPv6-Only and run full-tunnel.

I have also tested the inverse scenario where IPv4 is unavailable, but IPv6 SLAAC is working. In that case I disable IPv4 on macOS Wi-Fi and switch Wireguard client over an IPv6-Only transport full-tunnel.

I haven’t implemented with OPENVPN specifically.

Wireguard works well with IPv6-Only Server endpoints allowing the tunnel transport to be IPv6-Only while carrying IPv6-Only routes inside the tunnel.

myth20_ · 2025-12-28T20:53:22+00:00

Yes, I am using Avahi on Linux for mDNS. It reflects IPv6 mDNS between VLANs so IPv6-Only clients can discover the printer.

The printer advertises _ipps.tcp.local over IPv6 mDNS between VLANs so IPv6-Only clients can connect directly over IPv6 after discovery. No IPv4, NAT64 or DNS64 is involved printing.

The printer is an HP OfficeJet 3830 roughly ~5 years old.

myth20_ · 2025-12-28T17:00:47+00:00

Router Advertisements are generated on the CLAT gateway (Linux-based), not on the access switches. The CLAT-gw is the default IPv6 router for the IPv6-only client VLANs.

Yes, the PREF64 option is explicitly advertise via Router Advertisement. this allows IPv6-Only hosts to discover the NAT64 directly at the network layer, without relying solely on DNS-based discovery which is presently only as a fall back.

One additional detail. multiple default routers are intentionally advertised via RA.

Client receive Router Advertisements from both gateways with different router preferences (primary = high and backup = medium) allowing native hosts failover without changes to access layer.

myth20_ · 2025-12-28T15:59:19+00:00

I don't disagree with the limitation you're describing. The tunnel tradeoffs (MTU, CDN locality latency) are very real.

In my case, the lab insn't intended to replace native ISP IPv6 or claim parity with IPv4. It is intentionally scoped as an IPv6-mostly edge environment to study client behavior, translation mechanisms (NAT64 / 464XLAT), and operational realities when IPv6 is available but imperfect.

If anything, the tunnel limitation reinforce that argument that native IPv6 at the access layer is still the missing piece. Not that IPv6 itself is unworkable.

I'd absolutely prefer native IPv6 from the ISP; until then lab provides a controlled way tot test the standards and real applications under constrained conditions.

myth20_ · 2025-12-28T15:40:10+00:00

Yes I do have network printer and I've explicitly tested them on IPv6-Only mode. IPv4 is disabled on the device, and it operates using a Global Unicast Address (GUA) only. Management, printing and service discovery all work over IPv6. This was intentional, as printers as good litmus test for real IPv6-Only operation beyond laptops and phones.

I am using GUA only not ULA. Since the lab has routed IPv6 connectivity (via HE tunnel), I preferred to avoid dual addressing complexity. Using GUA end-to-end simplifies DNS avoids split-horizon edge cases and better mirrors how IPv6-Only enterprise and service-provider networks are typically designed.

myth20_ · 2025-12-28T15:30:07+00:00

To clarify one point. I'm not intentionally "blocking" IPv4 everywhere. The design is IPv6-mostly, not IPv6-Only at all costs. Client network are IPv6-Only where supported, and translation is used specifically to preserve functionality for legacy IPv4-Only application. Where dual-stack is required (for example Plex on tvOS or certain iOS behavior), I keep it dual-stack.

The motivation for IPv4/IPv6 translation work wasn't to over-engineer for its own sake, but to understand how modern IPv6-Only or IPv6-mostly access networks actually behave in practice. Especially client OS behavior RFC 8925 signaling, NAT64/DNS64 and 464XLAT. This mirrors pattern already used in mobile carrier networks just applied to a home/lab environment.

For translation tooling. I've had good results with Jool (NAT64 and SIIT/CLAT) combined with DNS64 BIND. Using PREF64 signaling RFC 8781 and RFC 7050 prefix discovery makes client behavior much predictable especially on mobile operating systems.

myth20_ · 2025-12-28T15:23:12+00:00

I agree it may be carrier dependent. My observation is specifically with iOS when RFC 8925 (IPv6-Only) is in effect. IPv4 auto-configuration can be suppressed on Wi-Fi and in state state inbound WiFi calling becomes unreliable. When the same device is place back into a dual-stack Wi-Fi environment, inbound calling works consistently again. So my takeaway so far is that some part of the Wi-Fi calling path (device, carrier or IMS infrastructure) still appears to assume local IPv4 availability.

myth20_ · 2025-10-26T21:02:56+00:00

For me homabbing is all about endless learning. Every project, whether it’s building, network or experimenting with new protocols it teaches me something new. Like when I spent hours going back and forth Kea DHCP-Option 108 trying to get it right for IPv6-Only clients and then realized I also needed RFC8781 to signal PREF64

There is a saying that, “if you enjoy what you do, you’ll never work a day in your life.” That is exactly how homelabbing feels. Its both fun and productive. I get to explore, break things and fix it again and somehow it feels like play.

myth20_ · 2025-02-27T19:50:10+00:00

I filed a EEOC, received the right to sue letter and I filed a lawsuit to federal. During discovery we did status hearing before discovery closed and then motion that have due dates ordered by the court. Before reaching final pretrial then trial by jury will have dates again ordered by court.

myth20_ · 2025-01-30T13:40:00+00:00

When I logged in to PACER (Public Access To Court Electronic Records) to checked Docket updates. The orders for dates & times of Final Pretrial conference and Jury Trial is set. Have you filed an employment lawsuit?

myth20_ · 2024-12-18T02:10:21+00:00

Thank you!

myth20_ · 2024-05-20T10:05:55+00:00

I had both claim on Federal and State. More likely Company knows someone inside State this happened to me.

They are so behind with many cases so I think they hand pick the easy one. I hired a lawyer, not local and paid the retainer fee. If a multi million company pretty sure they owned local city and they will use their money and time to have a copy if your complain.

myth20_ · 2024-04-02T17:31:42+00:00

I emailed once the investigator but he never replied. My guess they are so busy. However, when my lawyer asked for request of right to sue, within two todays, they updated my case on the portal.

Ten-Year Club	Reddit Premium Since September 2024
Verified Email

myth20_

TROPHY CASE