IPv6 discussions

[bert64]

Bye Bye SLACC, Android to support DHCPv6-PD soon before the end of the year...

This is PD, not NA. That is:

1) your ISP must delegate you a prefix longer than /64, preferably /56 so that your router can sub delegate prefixes to android devices (and anything else acting as a PD client)
2) your router must support acting as a PD server, not just client

The android device effectively becomes a router and has its own subnet, and then it can use an entire /64 for its own purposes (eg tethering etc).

This will not work at all on ISPs that only delegate you /64 (M1, Starhub etc)

Also note that DHCPv6 does not work on its own, it still needs router advertisements.

 

[bert64]

hi,

for Singtel / Singnet and on the old VLAN10 network, I'd still recommend dhcpv6 and NAT66 for that 1 single ipv6 address.
And to do NAT66, rather than NDP Neighbor Discovery Protocol .
reasons are like such, NDP based addressing is SLAAC
https://datatracker.ietf.org/doc/html/rfc4862
https://www.networkacademy.io/ccna/ipv6/stateless-address-autoconfiguration-slaac
it uses the notion of taking the prefix e.g. /64 from the upstream router and 'paste' it on the interface address, by definition 64 bits.
if we simply only do SLAAC, then everyone's traffic will goto everyone's other network, i.e. you can *sniff* your neighbor's traffic ! Because you receive them all !
(and FYI, this is true for *all mobile networks* in part because android use SLAAC ! very very insecure)
hence, for your 'own security' , do only dhcpv6 get that 1 single ipv6 address (singtel don't give /64, only 1 ( out of 340,282,366,920,938,463,463,374,607,431,768,211,456 total ipv6 addresses ) and do NAT66
using fd00::* /16 (the sub nets/address invent them yourself) for your local networks
https://en.wikipedia.org/wiki/Unique_local_address
and until Singtel / Singnet provide /64 *prefix delegation * (i.e. give you a whole 64 bits network) on DHCP
https://www.isc.org/blogs/dhcpv6-prefix-length-mode/
NAT66 would be the only way out.
if Singtel / Singnet provide /64 *prefix delegation * (i.e. give you a whole 64 bits network) on DHCP,
then in your network do SLAAC (i.e. do router advertisement ) on you lan/wifi with the prefix received from singtel/singnet DHCP.
All your local lan address will sit on the global ipv6 internet, every ip address is real and the whole world (universe) can reach *all* your ip address directly (e.g. you can run your own google.com, amazon.com ) and they can reach you.
this is actually a repeat of my previous comment (2 comments above), read that as that is better written / formatted.

there is a lot of 'secrets', but it is actually just simple technical understanding about NDP Neighbor Discovery Protocol network switching.
'by right' with network switching, only packets deemed for you gets switched to you (based on ethernet mac address), but if you do NDP an simply answer every who is address 'xxyyzz' , then you get all the traffic of *everyone* (do 'bad' things? that's a risk to every one else and to you)
actually, these days things / 'solutions' are more elaborate than that
there are *experimental* stuff like ndppd
https://github.com/DanielAdolfsson/ndppd
which will do like above answer every who is address 'xxyyzz' , but it doesn't abusively do that.
Instead, it forward that "who is address 'xxyyzz' to your lan / wifi, if it gets an answer, then it forward the response e.g. "me" back to the original (public lan)
maybe that is the so called NDP 'relay' mode.
but if your isp (e.g. singtel / singnet) don't do prefix delegation, your are sharing the same prefix with *everyone else*
this is also why *prefix* delegation is *very very important* - for *security* at least
so that 'everyone' get they own /64 prefix (own galaxy)
and your traffic won't mixed up with everyone else.
now, I suspect that is what happens ('everyones' traffic is mixed up'). and especially if you don't do NAT66 with that 1 single ipv6 address.

Mobile networks don't use SLAAC, the addressing for mobile data contexts is assigned by the APN, it's not a traditional ethernet style network. Same if your using VPNs or similar - the VPN itself will have its own method of assigning addresses to clients it doesn't rely on SLAAC.

If you NAT with ULA space you not only lose most of the benefits of IPv6, you will find that in most cases your system won't use the v6 at all because ULA space has a lower priority than legacy space, so dual stack sites will be routed over legacy ip instead of v6 etc.

Singtel do provide PD at least in some locations, something is wrong with your setup. You need to configure your DHCPv6 client to request a PD, and you might need to adjust the DUID type its sending as some ISPs will only respond to certain DUID types (eg M1 respond to DUID-LL but ignore DUID-LLT). I would suggest trying a known-good configuration first (eg OpenWRT as @xiaofan has it working) and if that works you know its a problem with your config, and if it doesn't work you know it's a problem at singtel. As OpenWRT is linux based you can then transfer the working settings from it to your existing linux box.

NDP performs the same function as ARP on legacy networks, but NDP is significantly more advanced.
ARP is broadcast - you will see all ARP requests for all customers in your neighbourhood on your WAN port, whereas NDP is solicited node multicast. ISPs usually filter at their end to prevent users from seeing other users traffic or being able to ARP/NDP poison. NDP is easier to filter, and there is also a secure version of NDP known as SEND which uses cryptographic hashing to authenticate neighbors, but this is not widely used.

Even if you use DHCPv6, you also need router advertisements to determine the subnet size and routing information. SLAAC uses router advertisements and the only difference is the "autonomous" flag set in the RA which tells SLAAC clients they can self-assign addresses within the subnet. You also still need NDP for the router to discover the MAC address of the ISP's upstream router.

If you have layer 2 security problems due to NDP, you will have the same problem with legacy ARP. You can also potentially source-route traffic to "internal" addresses of your neighbors - ie access the devices behind their NAT.

If you are trying to filter ICMPv6 on a firewall you will need to allow several types of ICPMv6 message. In particular you need to allow "packet too big" responses, otherwise PMTUD will break and you will get random failures and stuck connections. In general paranoid firewall rules do more harm than good, noone is going to compromise your devices by sending ICMPv6 packets to them. If you're allowing outbound traffic (eg allowing clients to browse HTTPS sites) that will be FAR more risky as that's what 99.999% of malware and c2 will be using.

The ISP does not need to filter fe80::/10, it is not routable. This is properly non routable - ie you cannot route it even if you control the entire path. This is unlike the fake "non routable" legacy space like RFC1918 which is actually fully routable so long as everything on the path is configured to do so.

 

[bert64]

@xiaofan
After digesting all your previous posts on Singtel IPv6 predicament...
If its ONR acts shitty similarly, can give a shot adopting this OpenWRT|ISP Configurations|AT&T Fiber :



Good luck

This is a different setup...
This is not a bridged setup, they are using the existing AT&T CPE and then putting their own OpenWRT behind it as a secondary router.
AT&T delegates /60 to the AT&T CPE, and then that router supports delegating /64 prefixes to downstream routers, this user is getting the CPE to delegate multiple /64 prefixes to make use of more of the /60 delegated by AT&T.

If they replaced the AT&T CPE with OpenWRT, or switched the CPE into bridged mode they would get the /60 delegation directly on their OpenWRT device.

The equivalent setup would be using the singtel ONR with an OpenWRT device behind it, but this is a moot point because singtel onr doesn't support downstream prefix delegation at all.

 

[hwzlite]

This is PD, not NA. That is:

1) your ISP must delegate you a prefix longer than /64, preferably /56 so that your router can sub delegate prefixes to android devices (and anything else acting as a PD client)
2) your router must support acting as a PD server, not just client

The android device effectively becomes a router and has its own subnet, and then it can use an entire /64 for its own purposes (eg tethering etc).

This will not work at all on ISPs that only delegate you /64 (M1, Starhub etc)

Also note that DHCPv6 does not work on its own, it still needs router advertisements.

Thx!

Another interesting read at "I’m too old to be fighting with windmills, but sometimes I have to get a rant off my chest. This one was triggered by the latest episode of the hilarious1 “DHCPv6 on Android” soap opera"

 

[Jurong640]

https://www.imda.gov.sg/-/media/imd...iated-statement-submitted-by-simba-and-m1.pdf

Simba, M1 to retain popular $10, $12 mobile plans, current prices after proposed merger​

Today's press release about Simba M1 merger.

MergeCo will not face impediments such as legacy systems or fragmented networks that have traditionally plagued IPv6 rollouts. M1 had undertaken a digital transformation of their backend systems, and SIMBA's broadband services are newly established. The NON-CONFIDENTIAL VERSION 22 combination of M1 and SIMBA's networks to create a unified, end-to-end network will enable coordinated IPv6 deployment.

5.2.10
For consumers, this means faster, more reliable connections, easier setup of multiple devices, and future-proofing for the increasing number of connected devices in modern homes. Singapore is investing ahead in a 10Gbps Nationwide Broadband Network, and wide-scale IPv6 adoption will enable MergeCo's customers to take full advantage of the 10 Gbps plans with minimal latency or address limitations. The integrated network also allows for faster introduction of new services and applications, because upgrades can be applied once across the merged platform rather than separately for each operator.

Through consolidation, MergeCo can provide a single, IPv6-ready network.

Additionally, there will be quicker service provisioning, automated address allocation, and centralised monitoring that reduces administrative effort. IT support teams will be freed up to concentrate on strategic initiatives rather than routine maintenance. The enlarged pool of dedicated enterprise support personnel can also quickly address any exigency.

To support IMDA’s plan to upgrade the Nationwide Broadband Network, as part of Singapore’s Digital Connectivity Blueprint, to bring higher internet speeds of up to 10Gbps to more households, the MergeCo will champion the rollout of 10Gbps fibre broadband plans for both consumers and enterprises.

Lastly, M1 is a business reputed for its impeccable customer service and customer experience. M1 has vital physical shopfronts around Singapore which MergeCo will continue to nurture, and a far more established customer support team. MergeCo's subscribers, regardless of the type of service they subscribe to, will benefit from this as MergeCo continues to provide customers with a familiar, face-to-face experience that M1 customers have grown accustomed to. It is planned that MergeCo's customers will, after a period of internal consolidation, be able to receive technical support and service at both M1's and SIMBA's retail shopfronts.

---

TLDR, Simba will offer IPv6

 

[xiaofan]

TLDR, Simba will offer IPv6

SIMBA has offered IPv6 for quite some time.

The main question is not IPv6, but whether SIMBA will ditch CGNAT or not for the Fibre Internet service. I tend to believe it will since it has a negligible subscriber number compared to M1 and M1 does not use CGNAT.

 

[bert64]

https://www.imda.gov.sg/-/media/imd...iated-statement-submitted-by-simba-and-m1.pdf

Simba, M1 to retain popular $10, $12 mobile plans, current prices after proposed merger​

Today's press release about Simba M1 merger.

MergeCo will not face impediments such as legacy systems or fragmented networks that have traditionally plagued IPv6 rollouts. M1 had undertaken a digital transformation of their backend systems, and SIMBA's broadband services are newly established. The NON-CONFIDENTIAL VERSION 22 combination of M1 and SIMBA's networks to create a unified, end-to-end network will enable coordinated IPv6 deployment.

5.2.10
For consumers, this means faster, more reliable connections, easier setup of multiple devices, and future-proofing for the increasing number of connected devices in modern homes. Singapore is investing ahead in a 10Gbps Nationwide Broadband Network, and wide-scale IPv6 adoption will enable MergeCo's customers to take full advantage of the 10 Gbps plans with minimal latency or address limitations. The integrated network also allows for faster introduction of new services and applications, because upgrades can be applied once across the merged platform rather than separately for each operator.

Through consolidation, MergeCo can provide a single, IPv6-ready network.

Additionally, there will be quicker service provisioning, automated address allocation, and centralised monitoring that reduces administrative effort. IT support teams will be freed up to concentrate on strategic initiatives rather than routine maintenance. The enlarged pool of dedicated enterprise support personnel can also quickly address any exigency.

To support IMDA’s plan to upgrade the Nationwide Broadband Network, as part of Singapore’s Digital Connectivity Blueprint, to bring higher internet speeds of up to 10Gbps to more households, the MergeCo will champion the rollout of 10Gbps fibre broadband plans for both consumers and enterprises.

Lastly, M1 is a business reputed for its impeccable customer service and customer experience. M1 has vital physical shopfronts around Singapore which MergeCo will continue to nurture, and a far more established customer support team. MergeCo's subscribers, regardless of the type of service they subscribe to, will benefit from this as MergeCo continues to provide customers with a familiar, face-to-face experience that M1 customers have grown accustomed to. It is planned that MergeCo's customers will, after a period of internal consolidation, be able to receive technical support and service at both M1's and SIMBA's retail shopfronts.

---

TLDR, Simba will offer IPv6

Simba and M1 both already have v6, although there are some issues with their setup.
M1 only delegates a single /64.
Simba block inbound traffic on mobile and only delegate /60 on fibre.

M1 mobile service is actually pretty spot on, so hopefully they won't ruin it with this merger.

 

[bert64]

SIMBA has offered IPv6 for quite some time.

The main question is not IPv6, but whether SIMBA will ditch CGNAT or not for the Fibre Internet service. I tend to believe it will since it has a negligible subscriber number compared to M1 and M1 does not use CGNAT.

They won't be getting any more address space from APNIC, and at auctions they will be competing against the likes of AWS and Azure. Expect to see more CGNAT not less as they will sell the legacy addresses, or reserve them for higher paying business customers.
M1 ditched their non-CGNAT mobile apn a few years back, so they are clearly feeling the pinch, and any potential growth would be severely limited.

Instead of CGNAT, they might look to implement other technologies such as DS-LITE or MAP-T as these scale better. They already have an (optional) NAT64/DNS64 setup.

 

[Jurong640]

SIMBA has offered IPv6 for quite some time.

The main question is not IPv6, but whether SIMBA will ditch CGNAT or not for the Fibre Internet service. I tend to believe it will since it has a negligible subscriber number compared to M1 and M1 does not use CGNAT.

i hope simba will be able to switch to non-cgnat, make it like M1 like fibre

 

[bert64]

Thx!

Another interesting read at "I’m too old to be fighting with windmills, but sometimes I have to get a rant off my chest. This one was triggered by the latest episode of the hilarious1 “DHCPv6 on Android” soap opera"

Android is right not to provide DHCPv6-NA.
SLAAC is the standard way of configuring IPv6, DHCPv6 is a non standard extension which is intended for niche use cases where you need something not provided by SLAAC such as PD or diskless booting.

Quite a lot of devices don't support DHCPv6, but aside from Android most of them are niche.
Some lousy ISPs are extremely stingy with v6 for absolutely no reason (APNIC will easily give them enough space to allocate /56 to every customer), and currently the minimum they can provide is /64 because any smaller than that would break compatibility with Android. A lot of ISPs provide the bare minimum - especially in Asia.
If Android supported DHCPv6-NA you can expect those stingy ISPs to give you a /120 or even less, limiting the number of devices you can have, preventing the use of privacy addressing, breaking ip based blacklisting which works on /64 blocks, and breaking compatibility with the other devices that don't support DHCPv6 as those devices would be niche enough to give the finger to.

 

[xiaofan]

1. https://test-ipv6.com/
test-ipv6.com is retiring December 2025; see retire.test-ipv6.com

This is my favourite site for testing IPv6.

2. Now need to go to alternative site.
https://browserleaks.com/ip
https://ipv6test.google.com/ (too simple)
https://www.whatismyip.com/
...

 

[xiaofan]

The ONT should not make any difference as it is a layer 2 device.

Simplest thing to do is, run a tcpdump on the WAN interface of your router, and then ping (or generate some other traffic) the other /64 blocks from somewhere external. if nothing shows up then the traffic isnt being routed to you and its an upstream problem (especially if you see something like destination unreachable in an externally originated traceroute).
If traffic shows up, then try sending something in the opposite direction and make sure it gets sent out the WAN interface of your router, and arrives at the external destination. First try a ping from the router itself with the source address set to something in one of the /64 blocks, then try sending traffic from an actual client in those networks.

Your problem does sound like an upstream issue, like the dhcpv6 server is delegating /56 but is only inserting a /64 route.

Previous debugging attempt in Nov 2024.
https://forums.hardwarezone.com.sg/threads/ipv6-discussions.6976522/page-15

@bert64
New debugging attempt.

The opposite direction seems to be the main issue.

1. From LAN client --> external IPv6 address, no issues.

root@ubuntu2204ct12tailscale:~# ping -c 4 2001:4860:4860::8888
PING 2001:4860:4860::8888(2001:4860:4860::8888) 56 data bytes
64 bytes from 2001:4860:4860::8888: icmp_seq=1 ttl=114 time=2.12 ms
64 bytes from 2001:4860:4860::8888: icmp_seq=2 ttl=114 time=2.72 ms
64 bytes from 2001:4860:4860::8888: icmp_seq=3 ttl=114 time=2.71 ms
64 bytes from 2001:4860:4860::8888: icmp_seq=4 ttl=114 time=2.59 ms

--- 2001:4860:4860::8888 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 2.116/2.533/2.717/0.246 ms

OpenWRT WAN Interface tcpdump -- can see both the ICMPv6 request and ICMPv6 reply

11:13:33.962424 IP6 2400:d802:dxx:8300::71f > dns.google: ICMP6, echo request, id 17672, seq 1, length 64
11:13:33.964366 IP6 dns.google > 2400:d802:dxx:8300::71f: ICMP6, echo reply, id 17672, seq 1, length 64
...
11:13:34.963986 IP6 2400:d802:dxx:8300::71f > dns.google: ICMP6, echo request, id 17672, seq 2, length 64
11:13:34.966256 IP6 dns.google > 2400:d802:dxx:8300::71f: ICMP6, echo reply, id 17672, seq 2, length 64
...
11:13:35.965856 IP6 2400:d802:dxx:8300::71f > dns.google: ICMP6, echo request, id 17672, seq 3, length 64
11:13:35.968194 IP6 dns.google > 2400:d802:dxx:8300::71f: ICMP6, echo reply, id 17672, seq 3, length 64
11:13:36.967695 IP6 2400:d802:dxx:8300::71f > dns.google: ICMP6, echo request, id 17672, seq 4, length 64
11:13:36.970021 IP6 dns.google > 2400:d802:dxx:8300::71f: ICMP6, echo reply, id 17672, seq 4, length 64

2. From LAN2 client --> external IPv6 address, got issues.

root@debian12ct21:~# ping -c 4 2001:4860:4860::8888
PING 2001:4860:4860::8888(2001:4860:4860::8888) 56 data bytes

--- 2001:4860:4860::8888 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3111ms

OpenWRT WAN Interface tcpdump -- only see the ICMPv6 request but not ICMPv6 reply

11:14:00.086430 IP6 2400:d802:dxx:83f0::4b7 > dns.google: ICMP6, echo request, id 2937, seq 1, length 64
11:14:01.149962 IP6 2400:d802:dxx:83f0::4b7 > dns.google: ICMP6, echo request, id 2937, seq 2, length 64
11:14:02.175004 IP6 2400:d802:dxx:83f0::4b7 > dns.google: ICMP6, echo request, id 2937, seq 3, length 64
11:14:03.198054 IP6 2400:d802:dxx:83f0::4b7 > dns.google: ICMP6, echo request, id 2937, seq 4, length 64

 

[xiaofan]

Previous debugging attempt in Nov 2024.
https://forums.hardwarezone.com.sg/threads/ipv6-discussions.6976522/page-15

@bert64
New debugging attempt.

The opposite direction seems to be the main issue.

1. From LAN client --> external IPv6 address, no issues.

2. From LAN2 client --> external IPv6 address, got issues.

OpenWRT WAN Interface tcpdump -- only see the ICMPv6 request but not ICMPv6 reply

On the other hand, it is also strange from the external host to LAN/LAN2 client.

From OpenWRT WAN interface tcpdump logs, I can see ICMPv6 requst and reply for both ping, but then external ping to LAN client is okay but not LAN2 client.

# ping -c 4 2400:d802:dxx:8300::71f
PING 2400:d802:dxx:8300::71f (2400:d802:dxx:8300::71f): 56 data bytes
64 bytes from 2400:d802:db6:8300::71f: seq=0 ttl=62 time=2.170 ms
64 bytes from 2400:d802:db6:8300::71f: seq=1 ttl=62 time=2.081 ms
64 bytes from 2400:d802:db6:8300::71f: seq=2 ttl=62 time=2.930 ms
64 bytes from 2400:d802:db6:8300::71f: seq=3 ttl=62 time=2.186 ms

--- 2400:d802:db6:8300::71f ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 2.081/2.341/2.930 ms

# ping -c 4 2400:d802:dxx:83f0::4b7
PING 2400:d802:dxx:83f0::4b7 (2400:d802:dxx:83f0::4b7): 56 data bytes

--- 2400:d802:db6:83f0::4b7 ping statistics ---
4 packets transmitted, 0 packets received, 100% packet loss

 

[bert64]

On the other hand, it is also strange from the external host to LAN/LAN2 client.

From OpenWRT WAN interface tcpdump logs, I can see ICMPv6 requst and reply for both ping, but then external ping to LAN client is okay but not LAN2 client.

# ping -c 4 2400:d802:dxx:8300::71f
PING 2400:d802:dxx:8300::71f (2400:d802:dxx:8300::71f): 56 data bytes
64 bytes from 2400:d802:db6:8300::71f: seq=0 ttl=62 time=2.170 ms
64 bytes from 2400:d802:db6:8300::71f: seq=1 ttl=62 time=2.081 ms
64 bytes from 2400:d802:db6:8300::71f: seq=2 ttl=62 time=2.930 ms
64 bytes from 2400:d802:db6:8300::71f: seq=3 ttl=62 time=2.186 ms

--- 2400:d802:db6:8300::71f ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 2.081/2.341/2.930 ms

# ping -c 4 2400:d802:dxx:83f0::4b7
PING 2400:d802:dxx:83f0::4b7 (2400:d802:dxx:83f0::4b7): 56 data bytes

--- 2400:d802:db6:83f0::4b7 ping statistics ---
4 packets transmitted, 0 packets received, 100% packet loss

Hmm so the external ping to ::83f0::4b7 is received by the router, forwarded to the client, and the reply is forwarded back out of the WAN interface... but the external host never receives the reply?

It looks like inbound traffic is routed to you, but for some reason outbound traffic is getting dropped somewhere upstream of your router.

How far do traceroutes get in both directions?

 

[hwzlite]

....
ISPs (with no blocking/restriction?) hate this little mavlan trick which even reported working for /64 PD

I got bored and tried macvlan trick above, confirmed no dice on M1

Another good vid ref starts from 11:10min :

 

[xiaofan]

https://status.test-ipv6.com/

Update: test-ipv6.com will stay online!​

After announcing its retirement, many generous people and organizations offered help - thank you! The project is now transitioning to an RIR (Regional Internet Registry), which will continue running the site in the public interest. I'll share updates as things progress.

 

[uncle_josh]

Why aren't many websites/organizations not enabling IPv6, anyone have an insight view of the current situation ?

 

[bert64]

Why aren't many websites/organizations not enabling IPv6, anyone have an insight view of the current situation ?

Many are, all the big players like google, microsoft, amazon, facebook, netflix etc are v6-first.

Global adoption is sat at around 50% as per stats from google/apnic/akamai/cloudflare, but it varies massively by country. Countries like India and France are more like 80%, while most of africa is at <1% and drags the average down.

As for why someone would delay it's the typical laziness and fear of the unknown. These are the same people who drive around with a warning light on their dashboard because "the car still runs no need to spend $", not realising that the warning signifies something like an emissions system problem that results in greater fuel usage that will quickly add up to more than the one off cost of repair.

 

[xiaofan]

Hmm so the external ping to ::83f0::4b7 is received by the router, forwarded to the client, and the reply is forwarded back out of the WAN interface... but the external host never receives the reply?

It looks like inbound traffic is routed to you, but for some reason outbound traffic is getting dropped somewhere upstream of your router.

@bert64
Yes, that seems to be the problem.

How far do traceroutes get in both directions?

From :83f0::4b7 to ipv6.google.com -- stopped after the OpenWRT38 router LAN2 IPv6 address.

root@debian12ct21:~# mtr ipv6.google.com
                                My traceroute  [v0.95]
debian12ct21 (2400:d802:dxx:83f0::4b7) -> ipv6.google.com (2402025-10-09T13:35:50+0000
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                              Packets               Pings
 Host                                       Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 2400:d802:dxx:83f0::1                    0.0%    38    0.3   0.3   0.1   0.5   0.1
 2. (waiting for reply)

From external (another OpenWRT18 host) ping to ::83f0::1 (OpenWRT38 LAN2 IPv6 address).

root@openwrt18:~# mtr 2400:d802:dxx:83f0::1
                                                 My traceroute  [v0.95]
openwrt18 (2400:d802:xxx:xx00::1) -> 2400:d802:dxx:83f0::1 (2400:d802:dxx:83f0::1)             2025-10-09T21:47:59+0800
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                                               Packets               Pings
 Host                                                                        Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 2400:d801:4001:611::                                                      0.0%    38    1.6   1.5   1.2   2.1   0.2
 2. (waiting for reply)

As a comparison, from external to ::8300::1 (OpenWRT38 LAN IPv6 address)

root@openwrt18:~# mtr 2400:d802:db6:8300::1
                                                 My traceroute  [v0.95]
openwrt18 (2400:d802:xxx:xx00::1) -> 2400:d802:dxx:8300::1 (2400:d802:dxx:8300::1)             2025-10-09T21:45:51+0800
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                                               Packets               Pings
 Host                                                                        Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 2400:d801:4001:611::                                                      0.0%    45    1.4   1.5   1.1   3.1   0.4
 2. 2400:d802:dxx:8300::1                                                     0.0%    44    2.2   2.2   1.8   2.9   0.2

 

[xiaofan]

From external to :83f0::4b7. It goes through the Singtel server and then stops at the OpenWRT38 WAN IPv6 address, and never reaches :83f0::4b7.

root@openwrt18:~# mtr 2400:d802:dxx:83f0::4b7
                                                 My traceroute  [v0.95]
openwrt18 (2400:d802:xxx:xx00::1) -> 2400:d802:dxx:83f0::4b7 (2400:d802:dxx:83f0::4b7)         2025-10-09T22:05:14+0800
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                                               Packets               Pings
 Host                                                                        Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 2400:d801:4001:611::                                                      0.0%    70    1.4   1.5   1.1   2.2   0.2
 2. 2400:d802:d12:xxxx::81                                                    0.0%    70    1.8   2.1   1.8   2.8   0.2 (OpenWRT38 WAN)
 3. (waiting for reply)

From external to :8300::48f as a comparison. It goes through the Singtel server, then OpenWRT38 WAN IPv6 address and lastly to :8300::48f.

root@openwrt18:~# mtr 2400:d802:dxx:8300::48f.
                                                 My traceroute  [v0.95]
openwrt18 (2400:d802:xxx:xx00::1) -> 2400:d802:dxx:8300::48f (2400:d802:dxx:8300::48f)         2025-10-09T21:55:23+0800
 Host  Help   Display mode   Restart statistics   Order of fields   quit
                                                                               Packets               Pings
 Host                                                                        Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 2400:d801:4001:611::                                                      4.6%   173    1.9   1.6   1.0  11.2   0.9
 2. 2400:d802:d12:xxxx::81                                                    0.6%   173    2.4   2.2   1.8   3.1   0.3 (OpenWRT38 WAN)
 3. 2400:d802:dxx:8300::48f                                                   0.0%   173    2.1   2.3   1.8   3.0   0.3