IPv6 discussions

xiaofan · Aug 24, 2024

Interesting news from China.
https://www.lightreading.com/regula...irects-telcos-again-to-speed-up-ipv6-adoption

The operators are instructed to come up with a "network De-NAT" plan to progressively eliminate the kit from their networks. They are to permit no new NAT44 gear from July 2025.

By the end of 2024, the IPv6 connectivity rate of telcos' wireline broadband users must be no less than 80%. They must ensure at least 70% of the fixed-line portion of traffic connecting to mobile apps is IPv6.

Additionally, operators must start measuring key metrics such as fixed-line IPv6 connectivity and the level of IPv6 fixed-line traffic.

xiaofan · Aug 31, 2024

1. The usual way to get IPv6 if your ISPs do not support IPv6 is to use HE.net IPv6 Tunnel Broker.
https://tunnelbroker.net/register.php

2. I have not tried that myself since I can still use Singtel 6rd as of now (using unbridged Singtel ZTE F8648P ONR). But I can only get one /64 prefix delegation using the OpenWRT virtual router (using DMZ of the Singtel ONR).

For the other clients connected to the Asus RT-AX86U, or the Miniroute R1 (10G capable) Mini PC running Ubuntu 24.04 which is connected to the Singtel ONR directly (UFW firewall ON), I can not get Singtel 6rd to work.

3. The easier option is to use Cloudflare Warp client. I have tried it under Windows before and it is still working now.

Today I just tried it under the mini PC running Ubuntu 24.04 and it works. Speed is limited to 300+ Mbps only.

4. Setup procedure:
https://developers.cloudflare.com/warp-client/get-started/linux

5. Test result

Bash:

mcuee@miniroute10g:~/build/networking/speedtest$ ping -c 4 ipv6.google.com
ping: connect: Network is unreachable
mcuee@miniroute10g:~/build/networking/speedtest$ warp-cli registration new
NOTICE:

Cloudflare only collects limited DNS query and traffic data (excluding payload)
that is sent to our network when you have the app enabled on your device. We
will not sell, rent, share, or otherwise disclose your personal information to
anyone, except as otherwise described in this Policy, without first providing
you with notice and the opportunity to consent. All information is handled in
accordance with our Privacy Policy.

More information is available at:
- https://www.cloudflare.com/application/terms/
- https://www.cloudflare.com/application/privacypolicy/

Accept Terms of Service and Privacy Policy? [y/N] Y

Success
mcuee@miniroute10g:~/build/networking/speedtest$ warp-cli connect
Success

mcuee@miniroute10g:~/build/networking/speedtest$ curl https://www.cloudflare.com/cdn-cgi/trace/ | grep warp
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   215    0   215    0     0   1218      0 --:--:-- --:--:-- --:--:--  1214
warp=on
mcuee@miniroute10g:~/build/networking/speedtest$ ping -c 4 ipv6.google.com
PING ipv6.google.com (2404:6800:4003:c00::65) 56 data bytes
64 bytes from sa-in-x65.1e100.net (2404:6800:4003:c00::65): icmp_seq=1 ttl=59 time=45.3 ms
64 bytes from sa-in-x65.1e100.net (2404:6800:4003:c00::65): icmp_seq=2 ttl=59 time=43.5 ms
64 bytes from sa-in-x65.1e100.net (2404:6800:4003:c00::65): icmp_seq=3 ttl=59 time=43.6 ms
64 bytes from sa-in-x65.1e100.net (2404:6800:4003:c00::65): icmp_seq=4 ttl=59 time=43.4 ms

--- ipv6.google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 43.396/43.936/45.300/0.790 ms

mcuee@miniroute10g:~/build/networking/speedtest$ ./speedtest -s 13623

   Speedtest by Ookla

      Server: Singtel - Singapore (id: 13623)
         ISP: Cloudflare Warp
Idle Latency:    43.00 ms   (jitter: 1.29ms, low: 42.56ms, high: 44.71ms)
    Download:   382.18 Mbps (data used: 504.8 MB)
                204.17 ms   (jitter: 52.28ms, low: 41.39ms, high: 724.45ms)
      Upload:   336.01 Mbps (data used: 334.6 MB)
                 46.29 ms   (jitter: 4.08ms, low: 41.79ms, high: 90.11ms)
 Packet Loss:     0.0%
  Result URL: https://www.speedtest.net/result/c/e37d0947-6c76-4df1-9602-59657c0d3b50

mcuee@miniroute10g:~/build/networking/speedtest$ warp-cli disconnect
Success
mcuee@miniroute10g:~/build/networking/speedtest$ ping -c 4 ipv6.google.com
ping: connect: Network is unreachable

xiaofan · Aug 31, 2024

It is also possible to use warp-cli under Windows.

Bash:

PS C:\work\networking\ookla-speedtest-1.2.0-win64> warp-cli connect
Success
PS C:\work\networking\ookla-speedtest-1.2.0-win64> ping -n 4 ipv6.google.com

Pinging ipv6.l.google.com [2404:6800:4003:c05::64] with 32 bytes of data:
Reply from 2404:6800:4003:c05::64: time=39ms
Reply from 2404:6800:4003:c05::64: time=39ms
Reply from 2404:6800:4003:c05::64: time=40ms
Reply from 2404:6800:4003:c05::64: time=44ms

Ping statistics for 2404:6800:4003:c05::64:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 39ms, Maximum = 44ms, Average = 40ms
PS C:\work\networking\ookla-speedtest-1.2.0-win64> .\speedtest.exe -s 13623

   Speedtest by Ookla

      Server: Singtel - Singapore (id: 13623)
         ISP: Cloudflare Warp
Idle Latency:    38.75 ms   (jitter: 1.94ms, low: 38.15ms, high: 42.12ms)
    Download:   354.15 Mbps (data used: 524.3 MB)
                236.45 ms   (jitter: 62.71ms, low: 38.97ms, high: 1462.45ms)
      Upload:   409.24 Mbps (data used: 744.4 MB)
                129.61 ms   (jitter: 11.26ms, low: 39.54ms, high: 259.97ms)
 Packet Loss:     0.0%
  Result URL: https://www.speedtest.net/result/c/1ace2559-bedc-48fd-9f84-6204c0dac17c
PS C:\work\networking\ookla-speedtest-1.2.0-win64> warp-cli disconnect
Success
PS C:\work\networking\ookla-speedtest-1.2.0-win64> ping -n 4 ipv6.google.com
Ping request could not find host ipv6.google.com. Please check the name and try again.

firesong · Sep 1, 2024

xiaofan said:
Interesting news from China.
https://www.lightreading.com/regula...irects-telcos-again-to-speed-up-ipv6-adoption

The operators are instructed to come up with a "network De-NAT" plan to progressively eliminate the kit from their networks. They are to permit no new NAT44 gear from July 2025.

By the end of 2024, the IPv6 connectivity rate of telcos' wireline broadband users must be no less than 80%. They must ensure at least 70% of the fixed-line portion of traffic connecting to mobile apps is IPv6.

Additionally, operators must start measuring key metrics such as fixed-line IPv6 connectivity and the level of IPv6 fixed-line traffic.

Can't help it. The minister in charge of our telecommunications networks has clearly stated she expects everyone else to work in small spaces.

chnajuha · Sep 1, 2024

Starhub Mobile do support iPv6 but only in SA mode with Android APN required to set both iPv4/iPv6
Starting address: 2406:3000:.....

xiaofan · Sep 1, 2024

chnajuha said:
Starhub Mobile do support iPv6 but only in SA mode with Android APN required to set both iPv4/iPv6
Starting address: 2406:3000:.....

Thanks. Then it is quite similar to Singtel.

Singtel 5G SA -- IPv6
Singtel 5G NAS -- inconsistent IPv6
Singtel 4G -- no IPv6

firesong · Sep 2, 2024

chnajuha said:
Starhub Mobile do support iPv6 but only in SA mode with Android APN required to set both iPv4/iPv6
Starting address: 2406:3000:.....

NSA mode is not true 5G. No surprises there.

They are using 4G signalling equipment and standards. It does not include IPv6 as a mandated requirement, so they simply don't bother with IPv6.

I recall true 5G does state IPv6 in the standard somewhere. So ironically, it's not because of welfare of consumers or wanting a better network experience that pushes IPv6 adoption in Singapore. It's because of their greed for mobile dollars.

firesong · Sep 2, 2024

Further to that, this deck is useful for a quick summary of why IPv6 is needed.

https://www.ipv6council.be/wp-content/uploads/2022/04/220401-IPv6-in-5G.pdf

This point alone should be strong justification for the need to shift. Why impose a performance penalty on your network equipment by using 5G NSA or 4G? Keep old tech and inherit the slowness?
• NAT44 and NAT64 costs 50% of processing power in User Plane
• User Plane is up to 50% of the footprint of a Cloud Core Network
• IPv6 unlocks lower latency communications in 5G

Can see why IMDA chose to mandate SA over NSA, but market forces are insisting on old tech.

xiaofan · Sep 2, 2024

The IPv6 address seems to start at 2400:1c00 for SingTel 5G SA.

xiaofan · Sep 3, 2024

yjwong said:
Fast forward, after a whole bunch of calls and 2 field engineer visits later, today SingTel finally enabled native IPv6 for my account.

However, it was quite short lived - while I was trying to enable port forwarding/DMZ, I forgot my password and had to reset the router. Upon reset, native IPv6 was gone.

This was quite interesting, because it suggests that it isn't just something at the account level, but something to do with the configuration on the F8648P itself. It might be some kind of configuration push to the ONR?

I'm not sure, will contact SingTel again and see how this goes.

That said, now that M1 has 2.5 Gbps, kind of regret signing up. M1 was much more hassle free in both having bridge mode + native IPv6.

FYI, I am lucky to get Singtel native IPv6 to work with unbridged Singtel XGS-PON ONR (ZTE F8648P) working with the first visit of Singtel field person.

1. After removing the non-working 6rd profile, reboot the ONR and everything is working now on the ZTE F8648 XGS-PON ONR.

2. Tests done
First test shows that LAN clients of the Singtel ZTE F8648P ONR get IPv6 working.

Second test: set up Asus RT-AX86U behind ZTE F8648P ONR (Double NAT) to pass through IPv6, then the wireless clients of Asus RT-AX86U get IPv6 working.

Third test: remove the working WAN 6rd profile of the virtual OpenWRT router (Double NAT) and use DHCPv6 and then relay DHCPv6 and RA, then wireless clients of the ZTE BE7200 Pro+ AP (connected to virtual OpenWRT router) get IPv6 working.

3. Downside is that I can not confirm whether it is /56 or not from the ZTE ONR.

ZTE ONR --> 2400:d802:d10::xxxx
WAN Connection Status
Connection Name: Internet
Type: IP
IP Version: IPv4/v6
NAT: On
GUA: 2400:d802:d10::xxxx
DNS: 2400:d800::1; 2400:d800::2
IPv6 Connection Status: Connected
IPv6 Online Duration: 1 h 17 min 4 s

Asus RT-AX86U router WAN --> 2400:d802:dd3:3f00
OpenWRT virtual router WAN --> 2400:d802:dd3:3f00

xiaofan · Sep 3, 2024

xiaofan said:
2. Tests done
Second test: set up Asus RT-AX86U behind ZTE F8648P ONR (Double NAT) to pass through IPv6, then the wireless clients of Asus RT-AX86U get IPv6 working.

Update: this does not seem to be stable, sometimes working and sometimes not working.
Symptom: wireless client gets valid IPv6 address but no route to Internet.

Work-around now --> use the Adguard Home DNS (IPv4: 192.168.50.11, using its link-local IPv6 address as DNS server for IPv6) and not using automatic DNS from upstream.

xiaofan · Sep 4, 2024

xiaofan said:
Second test: set up Asus RT-AX86U behind ZTE F8648P ONR (Double NAT) to pass through IPv6, then the wireless clients of Asus RT-AX86U get IPv6 working.

xiaofan said:
Update: this does not seem to be stable, sometimes working and sometimes not working.
Symptom: wireless client gets valid IPv6 address but no route to Internet.

Work-around now --> use the Adguard Home DNS (IPv4: 192.168.50.11, using its link-local IPv6 address as DNS server for IPv6) and not using automatic DNS from upstream.

Same for the other Asus TUF-BE6500 router, if using router mode, it seems to be unstable. Using AP mode then no issues at all.

1) Singtel ONR --> TUF-BE6500 in router mode (Double NAT) with IPv6 passthrough.
Sometimes it is very strange, I can ping ipv6.google.com from the wireless client's Windows Terminal Powershell prompt, but Chrome browser IPv6 tests will fail.

Edit --> The issue is due to uBlock Origin Lite browser extension. Removing the extension and Windows is okay.

2) Singtel ONR --> TUF-BE6500 in AP mode (no Double NAT)
IPv6 works fine.

3) Singtel ONR --> Another OpenWRT instance (Double NAT) --> TUF-BE6500 in AP mode
IPv6 seems to work fine.

So probably Asus router IPv6 passthrough has some limitations. Anyway, I do not want to use tripple NAT so the above configuration is the one I want to use.
Singtel ONR --> Another OpenWRT instance (Double NAT, may change to pfSense soon) --> TUF-BE6500 in AP mode

4) But so far RT-AX86U works fine with the above work-around.
Singtel ONR --> RT-AX86U in router mode (Double NAT), using RT-AX86U Adguard Home LAN client's Link-local IPv6 address as the IPv6 DNS server (my previous setup also uses this to have Adguard Home DNS filtering working for IPv6).

Edit: need to carry out more tests. Sometimes it does not see to work.

xiaofan · Sep 4, 2024

The following configuration works pretty reliable under Windows.
Singtel ONR -- Main OpenWRT virtual router (Double NAT) --> ZTE BE7200 Pro+ as AP.

I believe the following will also work nicely under Windows.
Singtel ONR -- Second OpenWRT virtual router (Double NAT) --> Asus TUF-BE6500 as AP.

Edit -- need to carry out further testing.

I will test the following configuration later.
Singtel ONR -- pfSense virtual router (Double NAT) --> Asus TUF-BE6500 as AP.

Relevant main OpenWRT virtual router configurations.
(my configuration files got more stuff like Wireguard and static IP assignment)

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 'fda5: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.38.1'
        option netmask '255.255.255.0'
        list ip6class 'wan6'
        option ip6assign '64'

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

config interface 'wan6'
        option proto 'dhcpv6'
        option reqaddress 'try'
        option reqprefix 'auto'
        option device 'eth0'
        option norelease '1'

config interface 'tailscale'
        option proto 'none'
        option device 'tailscale0'

config interface 'zerotier'
        option proto 'none'
        option device 'ztyqbuckbd'

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

config dnsmasq
        option domainneeded '1'
        option boguspriv '1'
        option filterwin2k '0'
        option localise_queries '1'
        option rebind_protection '1'
        option rebind_localhost '1'
        option local '/lan/'
        option domain 'lan'
        option expandhosts '1'
        option nonegcache '0'
        option cachesize '1000'
        option authoritative '1'
        option readethers '1'
        option leasefile '/tmp/dhcp.leases'
        option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
        option nonwildcard '1'
        option localservice '1'
        option ednspacket_max '1232'
        option filter_aaaa '0'
        option filter_a '0'
        list server '/mask.icloud.com/'
        list server '/mask-h2.icloud.com/'
        list server '/use-application-dns.net/'
        list server '127.0.0.1#5053'
        list server '127.0.0.1#5054'
        option doh_backup_noresolv '-1'
        option noresolv '1'
        list doh_backup_server '/mask.icloud.com/'
        list doh_backup_server '/mask-h2.icloud.com/'
        list doh_backup_server '/use-application-dns.net/'
        list doh_backup_server '127.0.0.1#5053'
        list doh_backup_server '127.0.0.1#5054'
        list doh_server '127.0.0.1#5053'
        list doh_server '127.0.0.1#5054'
        option serversfile '/var/run/adblock-fast/dnsmasq.servers'

config dhcp 'lan'
        option interface 'lan'
        option start '100'
        option limit '150'
        option leasetime '12h'
        option dhcpv4 'server'
        option dhcpv6 'relay'
        option ra 'relay'
        option ndp 'relay'

config dhcp 'wan'
        option interface 'wan'
        option ignore '1'

config odhcpd 'odhcpd'
        option maindhcp '0'
        option leasefile '/tmp/hosts/odhcpd'
        option leasetrigger '/usr/sbin/odhcpd-update'
        option loglevel '4'

config dhcp 'wan6'
        option interface 'wan6'
        option ignore '1'
        option master '1'
        option ra 'relay'
        option dhcpv6 'relay'
        option ndp 'relay'

xiaofan · Sep 4, 2024

xiaofan said:
Same for the other Asus TUF-BE6500 router, if using router mode, it seems to be unstable. Using AP mode then no issues at all.

1) Singtel ONR --> TUF-BE6500 in router mode (Double NAT) with IPv6 passthrough.
Sometimes it is very strange, I can ping ipv6.google.com from the wireless client's Windows Terminal Powershell prompt, but Chrome browser IPv6 tests will fail.

Same for Xiaomi BE5000.
Singtel ONR --> Xiaomi BE5000 in router mode (Double NAT) with IPv6 passthrough (or auto configuration)

Ping is okay from my Windows 11 Acer laptop (wireless client).

Bash:

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

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

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

But IPv6 test from the browser failed.
Edit --> The issue is due to uBlock Origin Lite browser extension. Removing the extension and Windows is okay.

xiaofan · Sep 4, 2024

Summary of various test results.

1. No Double NAT --> IPv6 works fine under both Windows and Linux
2. Windows and Linux do not behave the same under Double NAT but there are no consistenly working configurations with Double NAT.

More details.

3. The following configurations does not work consistently under Windows. Totally not working under Linux.
Singtel ONR -- Main OpenWRT virtual router (Double NAT) --> ZTE BE7200 Pro+ as AP.
Singtel ONR -- Secondary OpenWRT virtual router (Double NAT) --> Asus TUF-BE6500 as AP.

The two instances of virtual OpenWRT routers have working IPv6 but then not the wireless clients. Take note in this case, OpenWRT WAN has valid IPv6 address but not LAN. However, the LAN is supposed to be relaying DHCPv6 and RA to the LAN/Wireless clients which do get proper IPv6 address, It seems to me the IPv6 gateway is not properly configured (some suggestions say to specify the WAN link-local address as gateway explicitly may help).

4. The following Double NAT configuration work under Linux but notconsistenly under Windows.
Singtel ONR --> Xiaomi BE5000 in router mode (Double NAT) with IPv6 passthrough (or auto configuration)

5. The following Double NAT configutations work under Linux, but not consistenly under Windows.
Singtel ONR --> RT-AX86U in router mode (Double NAT), using RT-AX86U Adguard Home LAN client's Link-local IPv6 address as the IPv6 DNS server
Singtel ONR --> Asus TUF-BE6500 in router mode (Double NAT) with IPv6 passthrough

6. All in all, Double NAT is causing inconsistent behaviours for IPv6. Again the lesson learned is to avoid ONR altogether.

xiaofan · Sep 4, 2024

xiaofan said:
I will test the following configuration later.
Singtel ONR -- pfSense virtual router (Double NAT) --> Asus TUF-BE6500 as AP.

This does not work at all.

pfSense WAN got IPv6 address (so itself works with IPv6), but not LAN and it seems to me that there is no way to pass through IPv6.

xiaofan · Sep 4, 2024

xiaofan said:
Same for Xiaomi BE5000.
Singtel ONR --> Xiaomi BE5000 in router mode (Double NAT) with IPv6 passthrough (or auto configuration)

Ping is okay from my Windows 11 Acer laptop (wireless client).

Bash:

PS C:\work> ping ipv6.google.com Pinging ipv6.l.google.com [2404:6800:4003:c05::71] with 32 bytes of data: Reply from 2404:6800:4003:c05::71: time=11ms Reply from 2404:6800:4003:c05::71: time=6ms Reply from 2404:6800:4003:c05::71: time=5ms Reply from 2404:6800:4003:c05::71: time=9ms Ping statistics for 2404:6800:4003:c05::71: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 5ms, Maximum = 11ms, Average = 7ms

But IPv6 test from the browser failed.
Edit --> The issue is due to uBlock Origin Lite browser extension. Removing the extension and Windows is okay.

Hmm, the issue comes back again tonight.

So the issue is not the browser extension after all.

Looking at the ping -- got packet drops badly at 17%.

Bash:

PS C:\work> ping www.google.com -t

Pinging www.google.com [2404:6800:4003:c00::6a] with 32 bytes of data:
Reply from 2404:6800:4003:c00::6a: time=7ms
Reply from 2404:6800:4003:c00::6a: time=8ms
Reply from 2404:6800:4003:c00::6a: time=8ms
Reply from 2404:6800:4003:c00::6a: time=5ms
Reply from 2404:6800:4003:c00::6a: time=6ms
Reply from 2404:6800:4003:c00::6a: time=7ms
Reply from 2404:6800:4003:c00::6a: time=5ms
Reply from 2404:6800:4003:c00::6a: time=7ms
Reply from 2404:6800:4003:c00::6a: time=8ms
Reply from 2404:6800:4003:c00::6a: time=6ms
Reply from 2404:6800:4003:c00::6a: time=6ms
Reply from 2404:6800:4003:c00::6a: time=10ms
Reply from 2404:6800:4003:c00::6a: time=7ms
Reply from 2404:6800:4003:c00::6a: time=5ms
Reply from 2404:6800:4003:c00::6a: time=5ms
Reply from 2404:6800:4003:c00::6a: time=5ms
Reply from 2404:6800:4003:c00::6a: time=6ms
Reply from 2404:6800:4003:c00::6a: time=6ms
Reply from 2404:6800:4003:c00::6a: time=8ms
Reply from 2404:6800:4003:c00::6a: time=9ms
Reply from 2404:6800:4003:c00::6a: time=7ms
Request timed out.
Reply from 2404:6800:4003:c00::6a: time=6ms
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from 2404:6800:4003:c00::6a: time=5ms
Reply from 2404:6800:4003:c00::6a: time=9ms
Reply from 2404:6800:4003:c00::6a: time=5ms
Reply from 2404:6800:4003:c00::6a: time=5ms
Reply from 2404:6800:4003:c00::6a: time=5ms
Reply from 2404:6800:4003:c00::6a: time=6ms

Ping statistics for 2404:6800:4003:c00::6a:
    Packets: Sent = 34, Received = 28, Lost = 6 (17% loss),
Approximate round trip times in milli-seconds:
    Minimum = 5ms, Maximum = 10ms, Average = 6ms
Control-C

xiaofan · Sep 5, 2024

5. The following Double NAT configutations work under Linux, but not consistenly under Windows.
Singtel ONR --> RT-AX86U in router mode (Double NAT), using RT-AX86U Adguard Home LAN client's Link-local IPv6 address as the IPv6 DNS server

Very strange under Windows.

When there is no issue, everything is okay.
When ther is an issue under Windows, I can see that under WIndows command line I can ping various IPv6 targets without issues (no packet loss), but browser IPv6 tests failed (tried different browsers as well -- Chrome, Edge and librewolf).

Seems to be a not-so-rare Windows IPv6 situation. Some say that the issue is with MTU.

darkmatt · Sep 6, 2024

xiaofan said:

1. The usual way to get IPv6 if your ISPs do not support IPv6 is to use HE.net IPv6 Tunnel Broker.
https://tunnelbroker.net/register.php

2. I have not tried that myself since I can still use Singtel 6rd as of now (using unbridged Singtel ZTE F8648P ONR). But I can only get one /64 prefix delegation using the OpenWRT virtual router (using DMZ of the Singtel ONR).

For the other clients connected to the Asus RT-AX86U, or the Miniroute R1 (10G capable) Mini PC running Ubuntu 24.04 which is connected to the Singtel ONR directly (UFW firewall ON), I can not get Singtel 6rd to work.

3. The easier option is to use Cloudflare Warp client. I have tried it under Windows before and it is still working now.

Today I just tried it under the mini PC running Ubuntu 24.04 and it works. Speed is limited to 300+ Mbps only.

4. Setup procedure:
https://developers.cloudflare.com/warp-client/get-started/linux

5. Test result

Bash:

mcuee@miniroute10g:~/build/networking/speedtest$ ping -c 4 ipv6.google.com
ping: connect: Network is unreachable
mcuee@miniroute10g:~/build/networking/speedtest$ warp-cli registration new
NOTICE:

Cloudflare only collects limited DNS query and traffic data (excluding payload)
that is sent to our network when you have the app enabled on your device. We
will not sell, rent, share, or otherwise disclose your personal information to
anyone, except as otherwise described in this Policy, without first providing
you with notice and the opportunity to consent. All information is handled in
accordance with our Privacy Policy.

More information is available at:
- https://www.cloudflare.com/application/terms/
- https://www.cloudflare.com/application/privacypolicy/

Accept Terms of Service and Privacy Policy? [y/N] Y

Success
mcuee@miniroute10g:~/build/networking/speedtest$ warp-cli connect
Success

mcuee@miniroute10g:~/build/networking/speedtest$ curl https://www.cloudflare.com/cdn-cgi/trace/ | grep warp
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   215    0   215    0     0   1218      0 --:--:-- --:--:-- --:--:--  1214
warp=on
mcuee@miniroute10g:~/build/networking/speedtest$ ping -c 4 ipv6.google.com
PING ipv6.google.com (2404:6800:4003:c00::65) 56 data bytes
64 bytes from sa-in-x65.1e100.net (2404:6800:4003:c00::65): icmp_seq=1 ttl=59 time=45.3 ms
64 bytes from sa-in-x65.1e100.net (2404:6800:4003:c00::65): icmp_seq=2 ttl=59 time=43.5 ms
64 bytes from sa-in-x65.1e100.net (2404:6800:4003:c00::65): icmp_seq=3 ttl=59 time=43.6 ms
64 bytes from sa-in-x65.1e100.net (2404:6800:4003:c00::65): icmp_seq=4 ttl=59 time=43.4 ms

--- ipv6.google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 43.396/43.936/45.300/0.790 ms

mcuee@miniroute10g:~/build/networking/speedtest$ ./speedtest -s 13623

   Speedtest by Ookla

      Server: Singtel - Singapore (id: 13623)
         ISP: Cloudflare Warp
Idle Latency:    43.00 ms   (jitter: 1.29ms, low: 42.56ms, high: 44.71ms)
    Download:   382.18 Mbps (data used: 504.8 MB)
                204.17 ms   (jitter: 52.28ms, low: 41.39ms, high: 724.45ms)
      Upload:   336.01 Mbps (data used: 334.6 MB)
                 46.29 ms   (jitter: 4.08ms, low: 41.79ms, high: 90.11ms)
 Packet Loss:     0.0%
  Result URL: https://www.speedtest.net/result/c/e37d0947-6c76-4df1-9602-59657c0d3b50

mcuee@miniroute10g:~/build/networking/speedtest$ warp-cli disconnect
Success
mcuee@miniroute10g:~/build/networking/speedtest$ ping -c 4 ipv6.google.com
ping: connect: Network is unreachable

HE tunnel giving me a lot of problems. need to captcha everytime i do a google search..

Mach3.2 · Sep 6, 2024

that a big downside which eventually lead me to move away from them for normal web browsing.

IPv6 discussions

High Supremacy Member

High Supremacy Member

High Supremacy Member

Supremacy Member

Junior Member

High Supremacy Member

Supremacy Member

Supremacy Member

High Supremacy Member

High Supremacy Member

High Supremacy Member

High Supremacy Member

High Supremacy Member

High Supremacy Member

High Supremacy Member

High Supremacy Member

High Supremacy Member

High Supremacy Member

Supremacy Member

Great Supremacy Member