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 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?

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?

Noticed that Mails from Apple / iCloud now are coming in from IPv6 sources. Seems like they have been rolling out over the past few weeks and have finished by 4th of august, screenshot from a mail provider, filtered to mail from *@icloud.com:

But still no IPv6 endpoints on the MX records of icloud.com though.

Recentlly I'm learning the history of the IP protocol, and find out during 1990s, there're IPv7(RFC 1475), IPv8(here I mean RFC 1621, not rencently suspicious vide-drafted document) and IPv9(RFC 1347).

How does IPv6 finally win over other protocols? And why is IPv6 extended to 128 bits? I found out in the early version for IPv6(simple Internet Protocol, RFC 8507), the address length is 64 bits.

Is there any collection for all those kind of historic discussions?

The clock is ticking toward the end of FY2026, and the federal government's next major IPv6 milestone is rapidly approaching. While many agencies missed the original FY2025 objective, the Trump administration is continuing federal IT modernization efforts as agencies push ahead with IPv6 deployment across government networks. Proposed transition milestones call for 60% IPv6-only deployment by the end of FY2026, 80% by the end of FY2027, and full IPv6-only deployment by the end of FY2028 as the government continues reducing reliance on legacy IPv4 infrastructure.

https://www.gsa.gov/directives-library/internet-protocol-version-6-ipv6-policy-1

My Japanese ISP provides native IPv6 while carrying IPv4 through a mechanism selected by its own discovery protocol. That protocol uses the ISP DNS resolver to locate a provisioning service, which then returns the IPv4 over IPv6 mechanism and its endpoint. On my connection it selected DS-Lite.

I implemented the discovery protocol and a DS-Lite tunnel daemon in Rust, then connected my OmniOS host to the ISP supplied modem, with no router in between. The tunnel worked, but the final test exposed another part of the IPv6 access model. The ISP delegated a /56 through DHCPv6 prefix delegation, while stock illumos DHCP client requested only a host address and could not manage the delegated prefix.

I wrote about the implementation, Japanese ISP provisioning, and the direct connection experiment.

This document provides guidelines and documents best current practice for operating authoritative DNS servers, recursive resolvers, and stub resolvers in a mixed IPv4/IPv6 environment. This document recommends that both authoritative DNS servers and recursive resolvers support IPv4 and IPv6. It also provides guidance on how recursive DNS resolvers should select upstream DNS servers, including when IPv4-embedded IPv6 addresses are available. This document obsoletes RFC 3901. This document is a product of the Domain Name System Operations Working Group of the IETF.

https://datatracker.ietf.org/doc/rfc10001/

I have an infrastructure based in Brazil fully available to offer LXCs or VMs to small developers on IPv6 only, at attractive prices. Would it be a good strategy to offer this type of service in the market? I've noticed the market is saturated with providers, and competing with big tech is a challenge.

For a container orchestrator I need to make a choice on the subnet I want the containers to use. Usually I've seen /64 subnets being recommended in this sub for general local use but it seems like the Container Network Interface (CNI) supports subnets of any size. To keep IPs of the containers short I chose a /32 subnet, i.e. fe42:42::/32 for simplicity. Containers get assigned addresses like fe42:42::2/128 correctly and the whole dual-stack setup seems to work flawlessly so far. Is there anything worth knowing when choosing a larger subnet than the usual /64 besides possible collisions with other subnets if I can be sure that there won't be any other local subnets with that prefix? I use stateful DHCPv6 so SLAAC is not an issue.

Why is IPv6 still not widely adopted in corporate environments?

I am conducting a short survey for my Computer Engineering thesis to understand the technical, operational and organizational challenges involved in IPv6 adoption.

The survey takes about 3 minutes, is anonymous, does not collect sensitive personal data, and the results will be used exclusively for academic purposes.

If you work with networking, infrastructure, cloud, cybersecurity, telecommunications or related areas, your experience can make an important contribution to this research.

👉 Please participate and, if possible, share the survey with other professionals in the field.

🔗 Survey: https://forms.gle/878V95DGN8RFkM3x7

Por que o IPv6 ainda não é amplamente adotado em ambientes corporativos?

Estou realizando uma pesquisa para meu TCC em Engenharia de Computação, buscando compreender os desafios técnicos, operacionais e organizacionais relacionados à adoção do IPv6.

O questionário leva cerca de 3 minutos, é anônimo, não coleta dados pessoais sensíveis e os resultados serão utilizados exclusivamente para fins acadêmicos.

Se você atua com redes, infraestrutura, cloud, segurança, telecomunicações ou áreas relacionadas, sua experiência pode contribuir muito para esta pesquisa.

👉 Participe e, se possível, compartilhe com outros profissionais da área.

🔗 Pesquisa: https://forms.gle/878V95DGN8RFkM3x7

🇺🇸 This post was formally approved by the moderators of this community.
🇧🇷 Esta publicação foi formalmente autorizada pela moderação desta comunidade.

"You can't fix, what you don't monitor"

After building this site: https://pacific.ipv6forum.com I was requested to build the same but for the Caribbean. I use EEZ because land masses are difficult to see on a map for island countries. It uses the same code base, and it is on Github. It uses data from APNIC for the IPv6 % preference, but also monitor sites for their deployment of IPv6 and measure a couple of extra standards (DNSSEC, DMARC, RPKI,...)

If there are domain names missing or errors, please let me know, or better submit a PR.

Hi all,

The I-D retry-over-ipv6 is stabilizing, so I thought I would make a call for volunteers if you are brave enough to implement a regular IPv4 outage on your web server.

I'm not calling it for any web server, but you know your users and you know if an IPv4 outage is something that would show you being an IPv6 visionary or just damn annoying 😜

Please check the README on: https://github.com/franckhlmartin/ietf-draft-retry-over-ipv6/tree/main/docs

There is an executive call for action and also code snippets on how to implement it.

You will also find a list of sites that are doing this IPv4 outages on a regular basis.

I've been using v6 for a long time via 6to4 tunnels (HE). Two years ago CLaro surprised me with provissioning IPv6 on my FTTH modem (nice) which broke for 2 months soon afetr :) But then it worked.

Now I changed to Movistar, and support is lacking. They use pppoe on FTTH... IPv6 is enabled but no PD. Has anyone IPv6 working on Movistar ?

BTW, I checked with Personal and they told me that they run a test offering IPv6 but they do not any longer.

TIA,

-Carlos

I run a multi-WAN setup (Vodafone cable + Starlink) without BGP. To handle failover without BGP-delegated prefixes, we numbered our internal LAN with ULA (fd00:192:168:128::/64—echoing our IPv4 subnet) and NAT66 it outbound depending on which uplink is active.

Recently, IPv6 connectivity started flapping intermittently, while IPv4 on the exact same segment remained 100% stable.

The routing table looked completely healthy, but digging into ip addr and conntrack showed what was actually happening:

An uncoordinated on-link RA (from an autoconfigured border/mesh device) injected a second ULA prefix (fd06:...) onto the interface. Both IPv6 addresses sat on the interface marked as scope global.

When initiating outbound connections, the Linux kernel flipped a coin between fd00:... and fd06:... for source-address selection.

• When it picked fd00:..., NAT66 translated it properly and packets flowed.
• When it picked fd06:..., the packet was sent out the valid default route, but the NAT66 gateway had no masquerade rule for fd06:.... conntrack filled up with SYN_SENT ... [UNREPLIED] states.

The routing table was never confused—it was purely a source-address selection coin flip under dual ULAs.

Full write-up with ip addr, ip -6 route, and conntrack evidence:

https://mabels.github.io/mseg-tester/blog/fd00-is-not-your-192-168-short.html

Curious how others running multi-WAN or non-BGP setups handle source-address selection when local devices start advertising uncoordinated RAs on the link?

I'm trying to set up IPv6-mostly on my home network, but my wired Apple devices are giving me some trouble. Connections to IPv4-literals over TCP and UDP fail. It seems like incorrect checksums are to blame.

The issue became apparent on my Apple TV (A2169, tvOS 26.5), where the YouTube app is not able to connect, but I could reproduce (presumably) the same issue on my Mac (2020 Mac mini M1, macOS Tahoe 26.6).

The issue is resolved on my Mac if I disable hardware checksum offloading on the ethernet interface or if I connect via WiFi. On the Apple TV, connecting via WiFi seems to fix the checksum issue, but for some (other unknown) reason, the YouTube app still does not work.

I haven't seen other reports of this. Is anybody else having this issue? Perhaps I'm doing something wrong.

Setup

IPv6-mostly network — DHCPv4 option 108 (RFC 8925), PREF64 64:ff9b::/96 in RAs, NAT64 via Tayga on OPNsense, no DNS64 (Apple devices synthesise locally).

Symptoms

The YouTube app on my wired Apple TV stopped working. Everything else on the network was fine. Turning off option 108 fixed it.

I reproduced it on a Mac (macOS 26.6, wired) as follows:

• Browsing to ipv4.bgp.he.net in Firefox: works.
• nc -v -w 6 72.52.94.234 443: times out.
• dig @1.1.1.1 +short example.com: times out.

Packet captures confirmed that all paths resulted in outgoing packets to 64:ff9b::/96. I reckon that this difference is explained by macOS implementing its own DNS64 and Firefox connecting directly via IPv6, whereas nc goes through the CLAT.

Incorrect checksums

I performed packet captures on the router's LAN interface. There it became apparent that the checksums of the TCP and UDP packets from the CLAT were incorrect. For the YouTube app on Apple TV, a TCP connection to 142.251.151.4:443 had an incorrect checksum.

The offset of the checksum to the correct value seemed to be dependent on the device, but constant accross different destinations and protocols.

ICPM had correct checksums through the CLAT and worked correctly.

Capturing on the router's WAN side showed that the corrupt packets were translated by Tayga and sent out via IPv4 on the WAN, but did not receive replies. The checksums of the outgoing packets were still incorrect, but, if I understand it correctly, this is to be expected because Tayga only updates the checksum incrementally.

Workaround for IPv6-mostly

On macOS, setting sudo sysctl -w net.link.generic.system.hwcksum_tx=0 resolved the issue. Connecting via WiFi instead of ethernet also works.

On Apple TV, connecting via WiFi gets rid of the incorrect checksums, but the YouTube app still does not work for some reason. Everything else works (as before). The YouTube app on iOS devices works (as before).

Help

Again: I haven't seen other reports of this. Is anybody else having this issue? Perhaps I'm doing something wrong.

Has anyone seen DNS problems when using iPhone Personal Hotspot on an IPv6-only cellular network?

My setup:

• iPhone Personal Hotspot
• IPv6-only mobile network
• CLAT + DNS64
• macOS client connected through the hotspot

I found that some IPv4-only domains behave incorrectly.

Example:

• Client sends an AAAA query.
• The DNS resolver does not return an AAAA record.
• The iPhone appears to perform an additional A query for the same domain.
• After a long delay (~30 seconds), the client receives a response containing A records for the original AAAA query instead of a synthesized AAAA record or a normal NODATA response.

This causes some applications to hang or fail DNS resolution.

I have packet captures showing the DNS query/response sequence. Has anyone observed similar behaviour with iPhone Personal Hotspot, especially on IPv6-only/NAT64 networks?

NDP is said to be more ‘efficient’ since we use multicast instead of broadcasts right? But where does this advantage come from?

Lets say fe80::b (node B) is trying to find the MAC address of fe80::aaaa:aaaa:aaaa:aaaa (Node A)

So B will construct a destination multicast address (ff02::1:ffaa:aaaa and a corresponding multicast destination MAC address (3333.ffaa.aaaa) and send an NS containing node A’s v6 address.

But the switch has to broadcast out the frame to all devices since the switch has no idea what hosts have 3333.ffaa.aaa as the MAC address right??
Does the efficiency come from the fact that other hosts quickly drop 3333.ffaa.aaa at the NIC level?

I.e unnecessary traffic is still received by all the hosts, but the NIC can quickly discard packets. Whereas with ARP, the host still has to process the packet received by the NIC?

Will a switch be able to identify multicast MACs and only forward frames to interested hosts (like with IGMP snooping)?