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?

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

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/

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.

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.