IPv6 discussions

xiaofan

High Supremacy Member
Joined
Sep 16, 2018
Messages
32,766
Reaction score
10,251
Oops, after changing my OpenWRT virtual router from the old Intel J4105 mini PC (PVE 7.4) to Intel N100 mini PC (PVE 8.0), it seems to me I can no longer get Singtel Native IPv6 to work.

Guess I have to wait for the issues to be sorted out by itself (not so sure how long).

Guess I did not wait enough for OpenWRT side (it was not working after 24 hours so I gave up).

Now it works again.

Code:
root@OpenWrt:~# ping -c 6 ipv6.google.com
PING ipv6.google.com (2404:6800:4003:c1c::8b): 56 data bytes
64 bytes from 2404:6800:4003:c1c::8b: seq=0 ttl=105 time=3.896 ms
64 bytes from 2404:6800:4003:c1c::8b: seq=1 ttl=105 time=3.744 ms
64 bytes from 2404:6800:4003:c1c::8b: seq=2 ttl=105 time=3.845 ms
64 bytes from 2404:6800:4003:c1c::8b: seq=3 ttl=105 time=3.759 ms
64 bytes from 2404:6800:4003:c1c::8b: seq=4 ttl=105 time=3.483 ms
64 bytes from 2404:6800:4003:c1c::8b: seq=5 ttl=105 time=3.956 ms

--- ipv6.google.com ping statistics ---
6 packets transmitted, 6 packets received, 0% packet loss
round-trip min/avg/max = 3.483/3.780/3.956 ms
 

xiaofan

High Supremacy Member
Joined
Sep 16, 2018
Messages
32,766
Reaction score
10,251
OpenWRT NAT66 guide
https://openwrt.org/docs/guide-user/network/ipv6/ipv6.nat6

This may not be so useful -- so it is just a testing for me.

Asus RT-AX86U with IPv6 -- OpenWRT virtual router (double NAT) with /64 IPv6 address -- wireless AP -- wireless clients

Bash:
root@OpenWrt:~# cat /etc/config/network

config interface 'loopback'
        option device 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'dda5:edda:cf50::/48'

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'eth1'

config interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option ipaddr '192.168.48.1'
        option netmask '255.255.255.0'
        option ip6assign '64'
        list ip6class 'local'

config interface 'wan'
        option device 'eth0'
        option proto 'dhcp'

config interface 'wan6'
        option device 'eth0'
        option proto 'dhcpv6'
        option reqaddress 'try'
        option reqprefix '64'
        option sourcefilter '0'
        option delegate '0'

root@OpenWrt:~# cat /etc/config/firewall

config defaults
        option syn_flood '1'
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'

config zone
        option name 'lan'
        list network 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'

config zone
        option name 'wan'
        list network 'wan'
        list network 'wan6'
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option masq '1'
        option mtu_fix '1'
        option masq6 '1'

config forwarding
        option src 'lan'
        option dest 'wan'

config rule
        option name 'Allow-DHCP-Renew'
        option src 'wan'
        option proto 'udp'
        option dest_port '68'
        option target 'ACCEPT'
        option family 'ipv4'

config rule
        option name 'Allow-Ping'
        option src 'wan'
        option proto 'icmp'
        option icmp_type 'echo-request'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-IGMP'
        option src 'wan'
        option proto 'igmp'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-DHCPv6'
        option src 'wan'
        option proto 'udp'
        option dest_port '546'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-MLD'
        option src 'wan'
        option proto 'icmp'
        option src_ip 'fe80::/10'
        list icmp_type '130/0'
        list icmp_type '131/0'
        list icmp_type '132/0'
        list icmp_type '143/0'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Input'
        option src 'wan'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        list icmp_type 'router-solicitation'
        list icmp_type 'neighbour-solicitation'
        list icmp_type 'router-advertisement'
        list icmp_type 'neighbour-advertisement'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Forward'
        option src 'wan'
        option dest '*'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-IPSec-ESP'
        option src 'wan'
        option dest 'lan'
        option proto 'esp'
        option target 'ACCEPT'

config rule
        option name 'Allow-ISAKMP'
        option src 'wan'
        option dest 'lan'
        option dest_port '500'
        option proto 'udp'
        option target 'ACCEPT'

Wireless clients will get an IPv6 with local ULA prefix dda5:edda:cf50:0:xxx:xxxx:xxxx:xxxx, but they can communicate using IPv6.

Bash:
PS C:\work\speedtest> ping ipv6.google.com

Pinging ipv6.l.google.com [2607:f8b0:4007:810::200e] with 32 bytes of data:
Reply from 2607:f8b0:4007:810::200e: time=165ms
Reply from 2607:f8b0:4007:810::200e: time=163ms
Reply from 2607:f8b0:4007:810::200e: time=163ms
Reply from 2607:f8b0:4007:810::200e: time=162ms

Ping statistics for 2607:f8b0:4007:810::200e:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 162ms, Maximum = 165ms, Average = 163ms

Also tested with the following IPv6 test site -- it will show the IPv6 address of the OpenWRT virtual router and not the client's private IPv6 address.
https://test-ipv6.com/
 

xiaofan

High Supremacy Member
Joined
Sep 16, 2018
Messages
32,766
Reaction score
10,251
OpenWRT NAT66 guide
https://openwrt.org/docs/guide-user/network/ipv6/ipv6.nat6

This may not be so useful -- so it is just a testing for me.

Asus RT-AX86U with IPv6 -- OpenWRT virtual router (double NAT) with /64 IPv6 address -- wireless AP -- wireless clients

Wireless clients will get an IPv6 with local ULA prefix dda5:edda:cf50:0:xxx:xxxx:xxxx:xxxx, but they can communicate using IPv6.

Bash:
PS C:\work\speedtest> ping ipv6.google.com

Pinging ipv6.l.google.com [2607:f8b0:4007:810::200e] with 32 bytes of data:
Reply from 2607:f8b0:4007:810::200e: time=165ms
Reply from 2607:f8b0:4007:810::200e: time=163ms
Reply from 2607:f8b0:4007:810::200e: time=163ms
Reply from 2607:f8b0:4007:810::200e: time=162ms

Ping statistics for 2607:f8b0:4007:810::200e:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 162ms, Maximum = 165ms, Average = 163ms

Do not be concerned about the high latency. It is the same when I connect through the Asus RT-AX86U router.

Bash:
PS C:\work\speedtest> ping ipv6.google.com

Pinging ipv6.l.google.com [2607:f8b0:4007:810::200e] with 32 bytes of data:
Reply from 2607:f8b0:4007:810::200e: time=162ms
Reply from 2607:f8b0:4007:810::200e: time=177ms
Reply from 2607:f8b0:4007:810::200e: time=284ms
Reply from 2607:f8b0:4007:810::200e: time=192ms

Ping statistics for 2607:f8b0:4007:810::200e:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 162ms, Maximum = 284ms, Average = 203ms

Then I have another home network with better latency.

Bash:
PS C:\work\speedtest> ping ipv6.google.com

Pinging ipv6.l.google.com [2404:6800:4003:c03::71] with 32 bytes of data:
Reply from 2404:6800:4003:c03::71: time=5ms
Reply from 2404:6800:4003:c03::71: time=5ms
Reply from 2404:6800:4003:c03::71: time=5ms
Reply from 2404:6800:4003:c03::71: time=5ms

Ping statistics for 2404:6800:4003:c03::71:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 5ms, Maximum = 5ms, Average = 5ms

Unfortunately both networks have bad latency to M1 SpeedTest server through IPv6.
Bash:
PS C:\work\speedtest\ookla-speedtest-1.2.0-win64> .\speedtest.exe -s 7311

   Speedtest by Ookla

      Server: M1 Limited - Singapore (id: 7311)
         ISP: Singtel Fibre
Idle Latency:   278.07 ms   (jitter: 62.47ms, low: 220.72ms, high: 307.65ms)
    Download:   301.04 Mbps (data used: 390.3 MB)
                328.81 ms   (jitter: 84.11ms, low: 215.79ms, high: 734.24ms)
      Upload:    32.72 Mbps (data used: 53.5 MB)
                335.43 ms   (jitter: 85.15ms, low: 214.55ms, high: 488.41ms)
 Packet Loss: Not available.
  Result URL: https://www.speedtest.net/result/c/9c0c2626-bb71-4aac-99f5-9b1aa990bc10
PS C:\work\speedtest\ookla-speedtest-1.2.0-win64> .\speedtest.exe -s 7311

   Speedtest by Ookla

      Server: M1 Limited - Singapore (id: 7311)
         ISP: Singtel Fibre
Idle Latency:   237.48 ms   (jitter: 54.88ms, low: 212.21ms, high: 300.21ms)
    Download:   299.82 Mbps (data used: 428.6 MB)
                321.13 ms   (jitter: 78.76ms, low: 211.22ms, high: 714.83ms)
      Upload:    85.23 Mbps (data used: 139.7 MB)
                343.14 ms   (jitter: 86.12ms, low: 216.21ms, high: 508.55ms)
 Packet Loss: Not available.
  Result URL: https://www.speedtest.net/result/c/af2e2407-e275-4ba8-bb59-2f08494680b1
 

xiaofan

High Supremacy Member
Joined
Sep 16, 2018
Messages
32,766
Reaction score
10,251
OpenWRT NAT66 guide
https://openwrt.org/docs/guide-user/network/ipv6/ipv6.nat6

This may not be so useful -- so it is just a testing for me.

Asus RT-AX86U with IPv6 -- OpenWRT virtual router (double NAT) with /64 IPv6 address -- wireless AP -- wireless clients

Wireless clients will get an IPv6 with local ULA prefix dda5:edda:cf50:0:xxx:xxxx:xxxx:xxxx, but they can communicate using IPv6.

Also tested with the following IPv6 test site -- it will show the IPv6 address of the OpenWRT virtual router and not the client's private IPv6 address.
https://test-ipv6.com/

I want to try this under pfSense but then I find out that pfSense does not support NAT66. It only supports NPt which will not work in this case since I only get single IPv6 address (and not a /64 delegate) from the upstream Asus router.
https://docs.netgate.com/pfsense/en/latest/network/ipv6/nat.html
https://docs.netgate.com/pfsense/en/latest/nat/npt.html

The same seems to apply to OPNsense as well.
https://forum.opnsense.org/index.php?topic=27824.0
https://docs.opnsense.org/manual/nptv6.html
 
Last edited:

Mach3.2

Great Supremacy Member
Joined
Apr 8, 2011
Messages
72,406
Reaction score
2,466
NPt is designed to map prefixes ISP delegated prefix with ULA prefixes 1:1, so you can do failover between ISPs without your own provider independent IPv6 space.


Not supported and some things WILL break (unsolicited inbound traffic), but you can kinda abuse it on pfsense by mapping a single ISP delegated /64 to multiple ULA /64s.
 
Last edited:

xiaofan

High Supremacy Member
Joined
Sep 16, 2018
Messages
32,766
Reaction score
10,251
Now it seems to me pfSense CE 2.7.2 works with Singtel IPv6.

Bash:
[2.7.2-RELEASE][root@pfSensen100new.home.arpa]/root: uname -a
FreeBSD pfSensen100new.home.arpa 14.0-CURRENT FreeBSD 14.0-CURRENT amd64 1400094 #1 RELENG_2_7_2-n255948-8d2b56da39c: Wed Dec  6 20:45:47 UTC 2023     root@freebsd:/var/jenkins/workspace/pfSense-CE-snapshots-2_7_2-main/obj/amd64/StdASW5b/var/jenkins/workspace/pfSense-CE-snapshots-2_7_2-main/sources/FreeBSD-src-RELENG_2_7_2/amd64.amd64/sys/pfSense amd64

[2.7.2-RELEASE][root@pfSensen100new.home.arpa]/root: ping -c 4 ipv6.google.com
PING6(56=40+8+8 bytes) 2400:d802:1c18::3:b7a --> 2404:6800:4003:c1a::71
16 bytes from 2404:6800:4003:c1a::71, icmp_seq=0 hlim=55 time=3.169 ms
16 bytes from 2404:6800:4003:c1a::71, icmp_seq=1 hlim=55 time=3.816 ms
16 bytes from 2404:6800:4003:c1a::71, icmp_seq=2 hlim=55 time=3.041 ms
16 bytes from 2404:6800:4003:c1a::71, icmp_seq=3 hlim=55 time=3.414 ms

--- ipv6.l.google.com ping6 statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 3.041/3.360/3.816/0.295 ms
 

xiaofan

High Supremacy Member
Joined
Sep 16, 2018
Messages
32,766
Reaction score
10,251
I was playing with Xiaomi AX3000T stock Xiaomi FW and I find it has IPv6 settings, including NAT6.

From Google Translate
kmhb7ka.png


I need to use the auto-configuration or passthrough option to get IPv6 working for wireless clients of Xiaomi AX3000T (router mode, Double NAT). I think passthrough mode will be able to pass SLAAC downstream.

Singtel ONT -- Asus RT-AX86U (/56 IPv6 for WAN, /64 IPv6 for LAN) -- Xiaomi AX3000T in router mode (Double NAT) -- wireless client

I also tested anoth Double NAT setup and it works as well.
Singtel ONT -- pfSense virtual router (/56 IPv6 for WAN, /64 IPv6 for LAN) -- Xiaomi AX3000T (Double NAT) -- wireless client

iQ9fYAF.png


Bash:
PS C:\work\speedtest> ping ipv6.google.com

Pinging ipv6.l.google.com [2404:6800:4003:c03::66] with 32 bytes of data:
Reply from 2404:6800:4003:c03::66: time=5ms
Reply from 2404:6800:4003:c03::66: time=5ms
Reply from 2404:6800:4003:c03::66: time=5ms
Reply from 2404:6800:4003:c03::66: time=6ms

Ping statistics for 2404:6800:4003:c03::66:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 5ms, Maximum = 6ms, Average = 5ms
 
Last edited:

xiaofan

High Supremacy Member
Joined
Sep 16, 2018
Messages
32,766
Reaction score
10,251
Some interesting IPv6 related discussion in the following thread.
https://forums.hardwarezone.com.sg/...et-throttle-during-peak-period.5764619/page-2

You can turn IPv4 off entirely with M1 and use their NAT64 gateway to access legacy sites - offload the NAT overhead to M1.

In practice most of the big sites and CDNs use IPv6, so it will account for more than half of a typical user's traffic so overall cpu usage will be reduced even if you're running dual stack since a lot less traffic will have to take the slower path.

The IPv6 firewall will do connection tracking and filtering, but it doesn't do NAT or recomputing the checksum so the cpu usage is still lower. Turning it off entirely (see the no state options in pfsense) makes a quite noticeable difference especially if your equipment is under specced.
You can also turn it off for specific hosts.

No the point is that M1 have a NAT64 gateway which means you can access legacy sites using pure IPv6 on your devices - M1 handles the translation from v6 to legacy IP and thus the NAT overhead if accessing a legacy site, whereas access to modern sites goes directly and bypasses the translation gateway.

There are also public gateways for this - see https://nat64.xyz

Lots of mobile networks around the world are IPv6-only and have millions of users, they can access legacy sites via NAT64/DNS64. This setup is a lot more scalable than legacy CGNAT or dual stack, and you can place the translation gateway anywhere instead of it needing to be on-path. Mobile networks are almost always CGNAT or NAT64. Some networks using this kind of setup in production are:
  • M1 SG (enabled by default, but dual stack as well)
  • T-mobile USA
  • Orange Poland
  • JIO India
  • Three UK (not all customers are migrated to the new infra yet)
  • Telstra Australia (default for iOS users, optional for Android)
  • Sky Italy (fixed line broadband)
  • NTT Japan (fibre broadband)
Some devices also implement CLAT (ios, macos, android, windows 10/11 but only on cellular connections) - that is the device itself emulates a legacy network, but the kernel then converts the traffic to ipv6 and sends it to the nat64 gateway, so all the traffic leaving your device is pure v6 even if the individual application thinks its connected to a legacy address.

There is also a technology called DS-LITE which is basically a CLAT on the router, so the actual connection is v6-only and then traffic to legacy sites gets translated by a nat64 gateway at the isp.

Microsoft also have a similar setup on their corporate LAN, IPv6-only for most devices and only legacy outbound traffic goes via a translation gateway. Facebook, Google, large parts of the US government etc also do the same.

I understand the point you try to make, but in reality, even the most enthusiastic IPv6 users seldom go this route.

I do see the benefits of IPv6 myself. But I think we have to live with the reality that IPv4 will be there for many years and dual stack IPv4/IPv6 is the way to go for most of the users who have IPv6.

In reality you cannot call IPv4 only sites legacy sites as many of the websites and corporate network are still IPv4 only.

BTW, I myself may experiment with NAT64 soon since Singtel /56 native IPv6 becomes quite stable for me, just as a learning exercise.



My comment was in response to Henry, who implied that going IPv6-only would make legacy sites inaccessible.

Many ISPs around the world already go the NAT64 route, DS-LITE or various other mechanisms, it's generally transparent to the user. Full dual stack is not economically viable so you're already facing compromises with legacy traffic, and the compromises get much worse in countries where the user base is expanding rapidly.

Lots of legacy technologies are still in use, that's the point - it's not current, not preferred, and not the focus of active development. Just like it took many years for floppy drives, optical media, rotating hard drives, CRTs etc to fade away. There is also still a long tail of sites which only support HTTP/1.1 (HTTP3 is current), older TLS versions, older HTML standards etc.

The guide you linked to is about running your own NAT64 gateway, which requires that you have dual stack with at least one legacy address.
You can already use public ones simply by changing your DNS resolver (see https://nat64.xyz). The M1 one is already used by default on their mobile service (at least when you have an iOS device) but to use it from a fibre link you need to setup the DNS64 part yourself (on pfsense its as simple as adding the nat64 prefix).

If you tether to an M1 mobile you will notice it's enabled by default, and dns lookups of any legacy sites will show v6 addresses within the NAT64 prefix range.

If you pick a random server from nat64.xyz and set your dns resolver to it on a macos device then turn off legacy ip it will just work, all you'll notice is the performance hit because the public nat64 servers are abroad. If you are able to use the local one provided by M1 there's no performance hit relative to using NAT44, in some cases it's actually faster because their gateway devices are significantly more powerful than a typical home router.
 

bert64

Senior Member
Joined
Jan 20, 2020
Messages
1,027
Reaction score
539
Some interesting IPv6 related discussion in the following thread.
https://forums.hardwarezone.com.sg/...et-throttle-during-peak-period.5764619/page-2
Apple support for NAT64 is very good, i believe you have a mac mini? Try setting your DNS resolver to a DNS64 resolver from https://nat64.xyz, turn off legacy IP and see how you get on.

You should notice a few things...

MacOS will detect the NAT64 prefix, and show it when you run ifconfig.
When you do a DNS lookup of a legacy site it will automatically generate v6 addresses, the address "ipv4only.arpa" is used for this, for example using a public NAT64:

nat64 prefix 2a00:1098:2b::1:0:0 prefixlen 96

And a DNS lookup:

$ host ipv4only.arpa ipv4only.arpa has address 192.0.0.170 ipv4only.arpa has address 192.0.0.171 ipv4only.arpa has IPv6 address 2a00:1098:2b::1:c000:ab ipv4only.arpa has IPv6 address 2a00:1098:2b::1:c000:aa

"c000:ab" is a hex encoding of the legacy address.

The way it works is simple, every legacy address is mapped 1:1 to an address inside the NAT64 prefix, and the DNS server automatically creates AAAA records if the original server does not return any.

Some of the public NAT64 resolvers load balance - ie you will get multiple addresses in multiple different prefixes, this gives you some extra flexibility and scalability that NAT44 cannot do. When you get multiple addresses like this, browsers will try them all and settle on the fastest one, if one happens to be down then it obviously won't be the fastest to respond.

You will also notice that macos assigns a virtual legacy address for CLAT:

inet 192.0.0.2 netmask 0xffffffff broadcast 192.0.0.2

so if you attempt to connect to any legacy address, it will convert it to the corresponding v6 address within the prefix and send it via the NAT64 gateway. If you capture the traffic on the wire you will see that it's all pure v6, but the application software thinks it's talking directly to a legacy network.

ios has this feature as well as does android, linux can do it (but depending on distro it might need to be manually configured) and windows also does it but only for cellular networks - microsoft has publicly committed to enabling it for all network types but not sure when it will be available.

Most modern software works directly with DNS64, only some legacy applications use the CLAT.

There are also ways to automate it at the network level - if your router sets the PREF64 flag on router advertisements, or your DHCP server responds with option 108 clients will automatically disable legacy ip and go v6-only - macos/ios support this.

If you use the public nat64 services everything should work transparently and the only thing you'll notice is that legacy sites are slower because they're going via a NAT64 gateway in Europe or the US.
If you use the M1 NAT64 there's not any performance hit at all since the gateway is local, it might even be a little bit faster since the NAT is done on M1's presumably quite highend equipment rather than your own router.

Google also run a public DNS64 server which responds with the reserved NAT64 prefix, but they don't run a NAT64 so it's useless unless you're on a network which has a NAT64 gateway using the reserved prefix.
 

xiaofan

High Supremacy Member
Joined
Sep 16, 2018
Messages
32,766
Reaction score
10,251
Apple support for NAT64 is very good, i believe you have a mac mini? Try setting your DNS resolver to a DNS64 resolver from https://nat64.xyz, turn off legacy IP and see how you get on.

First hurdle, Apple WiFi Ipv6 does not work at all once IPv4 is disabled (no need to talk about IPv4 and NAT64 in this case). I am running latest macOS 14.4.1 on my Mac Mini M1 2020.

I found a reference here.
https://discussions.apple.com/thread/254470070?sortBy=best

Before:
Bash:
/Users/mcuee > ping6 ipv6.google.com -c 4
PING6(56=40+8+8 bytes) 2400:d802:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx --> 2404:6800:4003:c1a::71
16 bytes from 2404:6800:4003:c1a::71, icmp_seq=0 hlim=103 time=6.594 ms
16 bytes from 2404:6800:4003:c1a::71, icmp_seq=1 hlim=103 time=8.043 ms
16 bytes from 2404:6800:4003:c1a::71, icmp_seq=2 hlim=103 time=49.172 ms
16 bytes from 2404:6800:4003:c1a::71, icmp_seq=3 hlim=103 time=94.362 ms

--- ipv6.l.google.com ping6 statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 6.594/39.543/94.362/35.971 ms

/Users/mcuee > ping6 2606:4700:4700::1113 -c 4
PING6(56=40+8+8 bytes) 2400:d802::xxxx:xxxx:xxxx:xxxx:xxxx:xxxx --> 2606:4700:4700::1113
16 bytes from 2606:4700:4700::1113, icmp_seq=0 hlim=47 time=234.285 ms
16 bytes from 2606:4700:4700::1113, icmp_seq=1 hlim=48 time=247.211 ms
16 bytes from 2606:4700:4700::1113, icmp_seq=2 hlim=47 time=200.865 ms
16 bytes from 2606:4700:4700::1113, icmp_seq=3 hlim=47 time=209.195 ms

--- 2606:4700:4700::1113 ping6 statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 200.865/222.889/247.211/18.668 ms

After:
Bash:
/Users/mcuee > ping6 ipv6.google.com -c 4
ping6: getaddrinfo -- nodename nor servname provided, or not known

/Users/mcuee > ping6 2606:4700:4700::1113 -c 4
ping6: UDP connect: No route to host
 
Last edited:

kindredSG

Member
Joined
Jun 3, 2024
Messages
194
Reaction score
196
First hurdle, Apple WiFi Ipv6 does not work at all once IPv4 is disabled (no need to talk about IPv4 and NAT64 in this case). I am running latest macOS 14.4.1 on my Mac Mini M1 2020.

After:
Bash:
/Users/mcuee > ping6 ipv6.google.com -c 4
ping6: getaddrinfo -- nodename nor servname provided, or not known

/Users/mcuee > ping6 2606:4700:4700::1113 -c 4
ping6: UDP connect: No route to host
Strange, I have a Mac Mini M2 and its fine with IPv6 only WiFi. Are you sure your router DHCP is providing IPv6 DNS resolvers? Those errors above seem like it can't resolve.
 

Mach3.2

Great Supremacy Member
Joined
Apr 8, 2011
Messages
72,406
Reaction score
2,466
First hurdle, Apple WiFi Ipv6 does not work at all once IPv4 is disabled (no need to talk about IPv4 and NAT64 in this case). I am running latest macOS 14.4.1 on my Mac Mini M1 2020.

I found a reference here.
https://discussions.apple.com/thread/254470070?sortBy=best
check your routing table

Edit: pulled out my mbp to test, ya seeing the same thing here 🤔


Are you sure your router DHCP is providing IPv6 DNS resolvers? Those errors above seem like it can't resolve.
The weird thing is once I enable back IPv4, my IPv6 is still broken :s13:

But then again I'm running unsupported hardware so could be incompatibility issues.

Edit: internet still works on chrome and safari. i think it's a bug with ping and traceroute binary in MacOS. I had mtr installed using homebrew and mtr still functions properly with IPv4 disabled.
 
Last edited:

xiaofan

High Supremacy Member
Joined
Sep 16, 2018
Messages
32,766
Reaction score
10,251
Strange, I have a Mac Mini M2 and its fine with IPv6 only WiFi. Are you sure your router DHCP is providing IPv6 DNS resolvers? Those errors above seem like it can't resolve.

It is indeed a very strange error.

I am not so sure if it has anything to do with Asus IPv6 implementation. So I carry out the test under Linux (Ubuntu 20.04) and there are no issues under Linux. I disable IPv4 for my wireless connection and IPv6 still works fine.

Bash:
mcuee@UbuntuSwift3 ~ $ ping ipv6.google.com -c 4
PING ipv6.google.com(se-in-f102.1e100.net (2404:6800:4003:c11::66)) 56 data bytes
64 bytes from se-in-f102.1e100.net (2404:6800:4003:c11::66): icmp_seq=1 ttl=105 time=4.22 ms
64 bytes from se-in-f102.1e100.net (2404:6800:4003:c11::66): icmp_seq=2 ttl=105 time=6.02 ms
64 bytes from se-in-f102.1e100.net (2404:6800:4003:c11::66): icmp_seq=3 ttl=105 time=7.18 ms
64 bytes from se-in-f102.1e100.net (2404:6800:4003:c11::66): icmp_seq=4 ttl=105 time=5.94 ms

--- ipv6.google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 4.216/5.838/7.183/1.058 ms
mcuee@UbuntuSwift3 ~ $ ping 1.1.1.1 -c 4
ping: connect: Network is unreachable
mcuee@UbuntuSwift3 ~ $ ping ipv4.google.com -c 4
ping: connect: Network is unreachable
mcuee@UbuntuSwift3 ~ $ ping 192.168.50.1 -c 4
ping: connect: Network is unreachable
 

xiaofan

High Supremacy Member
Joined
Sep 16, 2018
Messages
32,766
Reaction score
10,251
It is indeed a very strange error.

I am not so sure if it has anything to do with Asus IPv6 implementation. So I carry out the test under Linux (Ubuntu 20.04) and there are no issues under Linux. I disable IPv4 for my wireless connection and IPv6 still works fine.

Then adding nat64.xyz DNS64 server and then legacy IPv4 seems to work fine. But the latency is very bad and ping can even fail. For example, I can open IPv4 only websites like this forum (I am typing the reply under Linux) and I can open up ipv4.google.com website as well. But ping will fail for both cases.

So I guess this experiment can be considered a success (at least for Linux) but those nat64.xyz listed DNS64 servers will not work well in the end.

Bash:
mcuee@UbuntuSwift3 ~ $ ping ipv4.google.com -c 4
PING ipv4.google.com(lhr25s34-in-f14.1e100.net (2a01:4f8:c2c:123f:64:5:8efa:bbee)) 56 data bytes

--- ipv4.google.com ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3064ms

mcuee@UbuntuSwift3 ~ $ ping forums.hardwarezone.com.sg -c 4
PING forums.hardwarezone.com.sg(2a01:4f8:c2c:123f:64:5:98c7:1175 (2a01:4f8:c2c:123f:64:5:98c7:1175)) 56 data bytes

--- forums.hardwarezone.com.sg ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3053ms
 
Last edited:

Mach3.2

Great Supremacy Member
Joined
Apr 8, 2011
Messages
72,406
Reaction score
2,466
IPv6 transition mechanisms can be painful to implement and use, dual stack still the way to go for a long time imo.
 

xiaofan

High Supremacy Member
Joined
Sep 16, 2018
Messages
32,766
Reaction score
10,251
If you use the M1 NAT64 there's not any performance hit at all since the gateway is local, it might even be a little bit faster since the NAT is done on M1's presumably quite highend equipment rather than your own router.

@bert64

Would you please share the M1 NAT64 server address? Thanks.

I want to continue the test under Linux and then go back to troubleshoot my macOS issue later.
 

Mach3.2

Great Supremacy Member
Joined
Apr 8, 2011
Messages
72,406
Reaction score
2,466
@bert64

Would you please share the M1 NAT64 server address? Thanks.

I want to continue the test under Linux and then go back to troubleshoot my macOS issue later.

You'll need to use M1's DNS server too. i'm not sure if you can hit their NAT64 gateway from outside their network.

M1's DNS servers:
- 2401:7400:8888:41::37
- 2401:7400:8888:42::5
DNS64 prefix:
- 2401:7400:8000:0:3:0::/96

https://forums.hardwarezone.com.sg/...band-discussion-part-2.5658375/post-133693958

Edit: in the DNS resolver's advanced setting, you can specify the DNS64 prefix and see if it works. I didn't have to use M1's DNS servers in this instance.
RHJaT4A.png


Edit2: M1's DNS server and NAT64 gateway doesn't seem to accept request from outside M1's network.
 
Last edited:

xiaofan

High Supremacy Member
Joined
Sep 16, 2018
Messages
32,766
Reaction score
10,251
You'll need to use M1's DNS server too. i'm not sure if you can hit their NAT64 gateway from outside their network.

M1's DNS servers:
- 2401:7400:8888:41::37
- 2401:7400:8888:42::5
DNS64 prefix:
- 2401:7400:8000:0:3:0::/96

https://forums.hardwarezone.com.sg/...band-discussion-part-2.5658375/post-133693958

Edit: in the DNS resolver's advanced setting, you can specify the DNS64 prefix and see if it works. I didn't have to use M1's DNS servers in this instance.
RHJaT4A.png


Edit2: M1's DNS server and NAT64 gateway doesn't seem to accept request from outside M1's network.

Thanks. So in the end I can not use M1's NAT64 resolvers.

Even if it accepts request from Singtel, that does not help due to the poor latency from Singtel IPv6 to M1 IPv6 which we already discovered before.

Bash:
mcuee@UbuntuSwift3 ~ $ ping -c 4 2401:7400:8888:41::37
PING 2401:7400:8888:41::37(2401:7400:8888:41::37) 56 data bytes
64 bytes from 2401:7400:8888:41::37: icmp_seq=1 ttl=48 time=280 ms
64 bytes from 2401:7400:8888:41::37: icmp_seq=2 ttl=48 time=303 ms
64 bytes from 2401:7400:8888:41::37: icmp_seq=3 ttl=48 time=223 ms
64 bytes from 2401:7400:8888:41::37: icmp_seq=4 ttl=48 time=247 ms

--- 2401:7400:8888:41::37 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 223.041/263.251/302.661/30.425 ms
mcuee@UbuntuSwift3 ~ $ ping -c 4 2401:7400:8888:42::5
PING 2401:7400:8888:42::5(2401:7400:8888:42::5) 56 data bytes
64 bytes from 2401:7400:8888:42::5: icmp_seq=1 ttl=47 time=260 ms
64 bytes from 2401:7400:8888:42::5: icmp_seq=2 ttl=47 time=281 ms
64 bytes from 2401:7400:8888:42::5: icmp_seq=3 ttl=47 time=303 ms
64 bytes from 2401:7400:8888:42::5: icmp_seq=4 ttl=47 time=541 ms

--- 2401:7400:8888:42::5 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 259.640/346.194/541.260/113.670 ms
 
Important Forum Advisory Note
This forum is moderated by volunteer moderators who will react only to members' feedback on posts. Moderators are not employees or representatives of HWZ Forums. Forum members and moderators are responsible for their own posts. Please refer to our Community Guidelines and Standards and Terms and Conditions for more information.
Top