IPv6 discussions

Ickart

Junior Member
Joined
Aug 14, 2010
Messages
28
Reaction score
3
Very impressive post about the IPv6 configurations. I've been following it for quite a while to understand how the IPv6 configurations work.

Recently I've been noticing that my ONT or router hasn't been able to connect to IPv6 internet (though I have valid 2400:d803 or d802 addresses), despite being able to connect through previously without issues at all.
Not sure what has my ISP (Singtel) has done, but I do recall some broadband maintenance done in early July - and thereafter my IPv6 functionality has gone bonkers.

Originally I've setup using the 6rd method which was working fine, and with the recent native configuration on the router. Even resetting the ONT and my router doesn't resolve the case.

Sounds pretty bizarre, but I'm still on the legacy Nokia G-240G-E ONT and an Asus ROG Rapture GT6 mesh router. Though I'm due to upgrade to the 3Gbps network sometime this week, fingers crossed if the upgraded network would improve the situation.
 

joeltng

Member
Joined
Dec 29, 2010
Messages
369
Reaction score
25
Just got the 3Gbps (starhub) upgrade today. Relatively painless...however the routing perf is a mixed bag (mostly leaning negative)

For YouTube and Facebook they go from sub 20 ms of ping all the way to 80 for YouTube to even 700ms for Facebook. Only good one is taobao which effectively have it's ping halved going from v4 to v6

Is this consistent with you guys results? Abit torn if I want to keep it enabled. As much as I want to support it, it makes very little sense to do so if it results in a degraded exp for accessing common sites (not to mention not being able to test ALL the sites the family uses to see if net benefit or not)
 

xiaofan

High Supremacy Member
Joined
Sep 16, 2018
Messages
32,662
Reaction score
10,204
pfSense CE 2.8.0 Singtel Native IPv6 settings for reference -- I am not 100% sure if this is totally correct or not.

1. WAN
c7EqxRZ.png


N1Ui5pi.png


2. LAN
bBvuuxo.png


DlCb19e.png


3. DHCPv6 server for LAN

JvMnMyf.png


4. Router Advertisement service for LAN (not so sure if this is correct).

X7b0R4Q.png
 
Last edited:

thiamhui

Senior Member
Joined
Jan 3, 2001
Messages
816
Reaction score
122
pfSense CE 2.8.0 Singtel Native IPv6 settings for reference -- I am not 100% sure if this is totally correct or not.

1. WAN
c7EqxRZ.png


N1Ui5pi.png


2. LAN
bBvuuxo.png


DlCb19e.png


3. DHCPv6 server for LAN

JvMnMyf.png


4. Router Advertisement service for LAN (not so sure if this is correct).

X7b0R4Q.png
I'm using same settings as above for SIMBA with exception for DHCPv6 Prefix Delegation size of 60.
 

thiamhui

Senior Member
Joined
Jan 3, 2001
Messages
816
Reaction score
122
Is Simba really /60?

56 and 60 prefix delegation still does nothing for me. Wan still /64.
With reference to this blog, under "Setup the router", we can see that the prefix delegation should be 60.
Step1b.f0ca2b2f.png

Prefix delegation of 61 works for me as well.
 
Last edited:

hoision

Junior Member
Joined
Dec 2, 2019
Messages
16
Reaction score
8
Fibre ISP IPv6 support matrix
ISPIPv6 SupportDetails/Notes
Singtel6rd tunnel, limited rollout for DHCPv6 PD6rd: /128 for WAN interface, routed /64 prefix for LAN interface
DHCPv6 PD: /128 for WAN interface, routed /56 prefix for LAN interface

6rd tunnel config
StarhubDHCPv6 PD/128 for WAN interface, routed /64 prefix for LAN interface
M1DHCPv6 PD/128 for WAN interface, routed /64 prefix for LAN interface

Supports DNS64/NAT64
DNS64 prefix:
2401:7400:8000:0:3:0::/96
2401:7400:8000:0:4:0::/96
MyRepublicNoNo lol
ViewqwestStatic IPv6A routed /56 prefix assigned via DHCPv6 is available upon request from residential tech support at no additional charges. Not required to subscribe to static IPv4 add-on.

Email residential tech support at: residential.support@viewqwest.com

WAN: /64
LAN: routed /56 prefix for LAN interface

If assigned static prefix is not routable, email residential tech support with mtr/traceroute to an address in your /56 allocation from external servers (i.e. Vultr looking glass servers).
WhizcommNoAssigned 2405:d180::/32 but no IPv6 prefixes announced under AS135600.
SimbaDHCPv6 PDMay be delegating a /61 prefix. Requires testing.

Prefix delegation notes
/48: Great, follows best practices
/56: Acceptable, not great, but at least it still follows best practices
/64: Doesn't follow best practices. Only allows for a single LAN segment to be IPv6 enabled
Ref: https://www.ripe.net/publications/docs/ripe-690

Mobile ISP IPv6 support matrix
ISPIPv6 SupportDetails/Notes
SingtelYes*End point receives a routed /64 prefix

*Enabled on 5G standalone networks only.

iOS carrier profile enables IPv6 by default (Checked on iPhone 13 iOS 17.5.1, carrier bundle 58.0)

Post #17 by bert64
StarhubYes*End point receives a routed /64 prefix

*Enabled on 5G standalone networks only.

Caveats:
- On 5G SA network only.
- iOS carrier profile only enables IPv4 by default (Checked on iPhone 13 iOS 17.5.1, carrier bundle 58.0). You'd need to enable IPv6 using a custom APN config profile.
- On Android, you'd need to enable IPv6 in APN settings.
M1YesEnd point receives a routed /64 prefix

Supports DNS64/NAT64

Supported NVMO: Circles
SimbaYesEnd point receives a routed /64 prefix

Caveats:
- Unsolicited inbound traffic blocked
- Enabling IPv6 support on iOS requires installing a custom configuration profile with cellular APN configurations

Information collated in this post is non-exhaustive, do comment in this thread if you have new information.

Last edited on 31 August 2025
Simba has been giving a /60 PD since a maintenance in June.
 

andrew_g

Member
Joined
Oct 12, 2007
Messages
153
Reaction score
5
Check out official pfSense documentation, use DHCPv6 and SLAAC.
https://docs.netgate.com/pfsense/en/latest/interfaces/configure-ipv6.html

You may also read the posts in Page 1.
I think android is still only SLAAC, no DHCPv6, so if ISP router insist DHCPv6 complain that all the android phones *will not work* , lan side needs SLAAC no matter how.

on a different note, I got stuck today as the old IPv6rd no longer works for SIngTel broadband, need to try DHCPv6 on the wan.
question, what is the netmask for the DHCPv6? /64 ?, can /56 be done?

These days to do IPv6 in the home need to goto those guru level (linux) wizardry like NAT66 (ipv6 - ipv6 nat 128 bits NAT ) !
https://docs.fortinet.com/document/...tion-guide/627219/nat66-nat46-nat64-and-dns64
nat66 do not exist in 'old' linux distributions, need a fairly recent kernel and 'guru wizard' level configs
I just fudge the whole thing and get ip v6 'subnets' using "fd00::" addressed nets
https://en.wikipedia.org/wiki/Unique_local_address
this is the 'synonym' for the 192.168.* local ipv4 addresses.

sub-nets is die die must have if have more than 1 net at home, e.g. wifi + lan, worse if N x wifi (no mesh) + lan
 
Last edited:

andrew_g

Member
Joined
Oct 12, 2007
Messages
153
Reaction score
5
This is follow up on prior comment/post
https://forums.hardwarezone.com.sg/threads/ipv6-discussions.6976522/post-157322145
and on Singtel fibre broadband home:
the old setup of using 6RD Border Relay: 6rd.singnet.com.sg (202.166.127.6)
https://forums.hardwarezone.com.sg/threads/ipv6-discussions.6976522/#post-150382982
it seemed no longer works

I tried setting up my router (actually a pc runninig linux) , apparently Singtel now uses "dual stack"
quite similar to 'other' ISPs I suppose. i.e. DHCPv6
> dhclient -6 -v eno1.10 Internet Systems Consortium DHCP Client 4.4.1 Copyright 2004-2018 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Listening on Socket/eno1.10 Sending on Socket/eno1.10 PRC: Confirming active lease (INIT-REBOOT). XMT: Forming Confirm, 0 ms elapsed. XMT: X-- IA_NA xx:yy XMT: | X-- Confirm Address 2400:d802:xxxx:yyyy::zz XMT: V IA_NA appended. XMT: Confirm on eno1.10, interval 1030ms. RCV: Reply message on eno1.10 from fe80::xxxx:yyyy. RCV: X-- Server ID: 00:01:xxxx message status code Success: "All addresses are on-link" PRC: Bound to lease 00:01:xxxx. ^ it is quite strange the reply from came an fe80 address of the dhcp server. something more about that fe80:: address https://en.wikipedia.org/wiki/Link-local_address#IPv6 fe80:: addresses are "link local" addresses, supposedly don't pass across routers. if say ISP (e.g. Singtel) 'cut off' *firewall* rest of internet from sending from arbitrary fe80:: address, then it is safe for you to say only if my router see DHCP address from fe80:: xxxx I trust, i.e. they cannot spoof (pretend to be) that fe80:: (DHCP server) if ISP drop them. then your firewall rule should only accept *IPV6* DHCPv6 (port 546) from dhcp servers starting wiith address fe80:: . These days one needs to be paranoid about security, anything that you don't firewall enough is open buffet for hackers, crackers, viruses, ransomware, state sponsored attackers. 15: eno1.10@eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000 inet6 2400:d802:xxxx:yyyy::zz/128 scope global there is catch, initially it didn't work you need to open ipv6 port 546 (only ipv6 !) and better restrict (firewall to trusted one) the IP address of the DHCPv6 server or in theory anyone can give you an ipv6 address, and maybe hack your host into the dark side internet.
so that is /128
1 out of 340,282,366,920,938,463,463,374,607,431,768,211,456, addresses, a bit of a miser?
https://en.wikipedia.org/wiki/IPv6

still very early in my experiments, many 'problems' to solve
need to figure out how do to 'delegation' can take /64 or better /56 ?
btw for those who did not figure this out if you get /64 (lower 64 bits) or /56 (lower 72 bits) that is more than 4 billion times the whole IPv4 internet, not 16 billion, instead that number at 64 bits is 18,446,744,073,709,551,616, even lottery cannot fight this.

but the urban legend in the ipv6 age SLAAC
https://www.networkacademy.io/ccna/ipv6/stateless-address-autoconfiguration-slaac
deemed that the lower 64 bits is a *host* address, android phones don't do DHCPv6 only SLAAC.
I think is to ban the misers.

still too many 'guru/wizard' level stuff to figure out :pi
if the miser really give you 1 out of 340,282,366,920,938,463,463,374,607,431,768,211,456 ( even toto is more generous) address, then you need to do
NAT66 whoa another 'guru/wizard' level stuff to figure out
https://docs.fortinet.com/document/...tion-guide/627219/nat66-nat46-nat64-and-dns64
in the infant days of internet there is only NAT64, i.e. bridging the new ipv6 internet to the 'old' ipv4 'galaxy' which is the whole of the internet today. with IPv6 everyone can have their own galaxy (not just a planet or solar system) :)
 
Last edited:

xiaofan

High Supremacy Member
Joined
Sep 16, 2018
Messages
32,662
Reaction score
10,204
No issues to get native Singtel IPv6 working on my side.

/56 on the WAN side.

But then LAN delegation does not work, other than the default one, so basically it is no different from /64 in the end.

When I was using SingTel ONT, LAN side delegation worked fine. I could use two /64 on two different LAN ports of the main router. I could also delegate /60 to the sub-router (using Double NAT in that case). This was back in late 2023. I could get the thing working with different main routers as well, with Asus RT-AX86U, OpenWRT, pfSense and OPNsense.

After upgrading to SingTel 5Gbps plan and getting the ZTE F8648P XGS-PON ONR in August 2024, I can no longer get any thing better than /64 on the LAN side. And the issue is there no matter with unbridged ONR or bridged ONR.

I can only have one default /64 delegation to single LAN port. The other LAN port can get another /64 delegation and correct IPv6 address, but could not access the Internet. It is as if SingTel side bLocked it. I asked for help in this forum and I could not get it working. I am using OpenWRT now.

It still does not work now.

Not so sure if users of Nokia XS-240X-A XGS-PON ONR got better lucks or not.
 

andrew_g

Member
Joined
Oct 12, 2007
Messages
153
Reaction score
5
*very bad news*, singtel didn't seem to support prefix delegation, *ridiculous* because all android devices and many IPv6 devices is based on SLAAC which requires a /64 for the host part of the network address.
And a /64 is *mandatory as a minimum delegation to support IPv6* !!!!!!!!!!!!!!!!
https://www.networkacademy.io/ccna/ipv6/stateless-address-autoconfiguration-slaac

https://en.wikipedia.org/wiki/IPv6_address#Stateless_address_autoconfiguration_(SLAAC)

Interface identifier​

The lower 64 bits of these addresses are populated with a 64-bit interface identifier. This should be a pseudo-random number for privacy reasons. Also for privacy reasons, the interface identifier is different for each automatically configured address of that interface. This has the disadvantage that multiple multicast groups need to be joined for neighbor discovery. For this, the solicited-node multicast address is used, formed from the network prefix ff02::1:ff00:0/104 and the 24 least significant bits of the address.

IP Version 6 Addressing Architecture
https://datatracker.ietf.org/doc/html/rfc4291#page-7
2.5.1. Interface Identifiers
For all unicast addresses, except those that start with the binary
value 000, Interface IDs are required to be 64 bits long and to be
constructed in Modified EUI-64 format.

Modified EUI-64 format-based interface identifiers may have universal
scope when derived from a universal token (e.g., IEEE 802 48-bit MAC
or IEEE EUI-64 identifiers [EUI64]) or may have local scope where a
global token is not available (e.g., serial links, tunnel end-points)
or where global tokens are undesirable (e.g., temporary tokens for
privacy [PRIV]).


IPv6 Stateless Address Autoconfiguration
https://datatracker.ietf.org/doc/html/rfc4862#page-18
5.5.3. Router Advertisement Processing
form an address (and add it to the list) by
combining the advertised prefix with an interface identifier of
the link as follows:

| 128 - N bits | N bits |
+---------------------------------------+------------------------+
| link prefix | interface identifier |
+----------------------------------------------------------------+-
-----
so yes 64 bits for the host address

random tests not confirmed yet
 
Last edited:

andrew_g

Member
Joined
Oct 12, 2007
Messages
153
Reaction score
5
No issues to get native Singtel IPv6 working on my side.

/56 on the WAN side.

But then LAN delegation does not work, other than the default one, so basically it is no different from /64 in the end.

When I was using SingTel ONT, LAN side delegation worked fine. I could use two /64 on two different LAN ports of the main router. I could also delegate /60 to the sub-router (using Double NAT in that case). This was back in late 2023. I could get the thing working with different main routers as well, with Asus RT-AX86U, OpenWRT, pfSense and OPNsense.

After upgrading to SingTel 5Gbps plan and getting the ZTE F8648P XGS-PON ONR in August 2024, I can no longer get any thing better than /64 on the LAN side. And the issue is there no matter with unbridged ONR or bridged ONR.

I can only have one default /64 delegation to single LAN port. The other LAN port can get another /64 delegation and correct IPv6 address, but could not access the Internet. It is as if SingTel side bLocked it. I asked for help in this forum and I could not get it working. I am using OpenWRT now.

It still does not work now.

Not so sure if users of Nokia XS-240X-A XGS-PON ONR got better lucks or not.
I tested using isc dhcp client which is 'defacto' standard for dhcpv6
Siingtel's dhcp server didn't seem to provide a prefix delegation

the lease file looks like this
> dhclient -6 -v -N -P --prefix-len-hint 64 eno1.10 ... XMT: Forming Rebind, 1040 ms elapsed. XMT: X-- IA_NA c7:e9:84:05 XMT: | X-- Requested renew +3600 XMT: | X-- Requested rebind +5400 XMT: | | X-- IAADDR 2400:d802:xxxx XMT: | | | X-- Preferred lifetime +7200 XMT: | | | X-- Max lifetime +7500 XMT: V IA_NA appended. XMT: X-- IA_PD c7:e9:84:05 XMT: | X-- Request renew in +3600 XMT: | X-- Request rebind in +5400 XMT: | | X-- Request prefix ::/64. cat /var/lib/dhcp/dhclient6.leases default-duid "\000\001\xxxxx"; lease6 { interface "eno1.10"; ia-na xxxx { <- this tag marks the issued dhcp address section starts 1757xxxxx; renew 43200; rebind 75600; iaaddr 2400:d802:xxxxx { <- this is the ip address given starts 1757694064; preferred-life 86400; max-life 86400; } } option dhcp6.client-id 0:1:0:1:xxxx; option dhcp6.server-id 0:1:0:1:xxxxx; option dhcp6.name-servers 2400:d800::1,2400:d800::2; <- the dns servers provided }

that ia-na is the address info, what is missing is ia-pd which is the prefix delegation
https://kb.isc.org/docs/isc-dhcp-44-manual-pages-dhcp-options#standard-dhcpv6-options
option dhcp6.ia-pd string;

The ia-pd option is manufactured by clients and servers to create a Prefix Delegation binding - to delegate an IPv6 prefix to the client. It is not directly edited in dhcpd.conf(5) or dhclient.conf(5), but rather is manufactured and consumed by the software.

https://www.isc.org/blogs/dhcpv6-prefix-length-mode/
 
Last edited:

andrew_g

Member
Joined
Oct 12, 2007
Messages
153
Reaction score
5
there are 'solutions' (e.g. NAT66) but this is so far bad, because SLAAC, and IPv6 among the aims is to avoid all that NAT (network address translation) because IPv6 is purposefuly designed to avoid NAT
https://en.wikipedia.org/wiki/IPv6
340,282,366,920,938,463,463,374,607,431,768,211,456 total addresses
is practically enough for 'the universe' and 'a galaxy for everyone' :)

https://en.wikipedia.org/wiki/IPv6_address#General_allocation
By design, only a small fraction of the address space will be used actively. The large address space ensures that addresses are almost always available, which makes the use of network address translation (NAT) for the purposes of address conservation unnecessary. NAT has been increasingly used for IPv4 networks to help alleviate IPv4 address exhaustion.
 
Last edited:

andrew_g

Member
Joined
Oct 12, 2007
Messages
153
Reaction score
5
oh a more technical note, the 'default' concept is like such:

- the ISPs (SIngtel included) should at least give /64 delegation required by IIPv6 specs, (even in DHCPv6) (one ipv6 address is *ridiculous* giving only 1 out of 340,282,366,920,938,463,463,374,607,431,768,211,456 addresses
- then on the router side it needs to configure router advertisement e.g.
https://github.com/radvd-project/radvd
configuration looks like such
https://github.com/radvd-project/radvd/blob/master/radvd.conf.example
interface wifi { # # example of a standard prefix # prefix 2001:db8:1:0::/64 { AdvOnLink on; AdvAutonomous on; AdvRouterAddr off; };
it is always based on 64 bits, so the prefix given by the dhcp delegation should go into that prefix xxyy::/64 field

so the downstream clients will ask the router what is the prefix.
then all the downstream clients e.g. all the iphones, android phones, pc etc simply take their own low 64 bits address, paste the prefix in-front and that forms an internet routable IPv6 address.

the router also need to confiigure routing based on the delegated prefix, this is mainly to receive the traffic from downstream clients (e.g. iphones, android phones, pc etc) and forward it to the ISP router

but the gist of /64 (64 bits host address doesn't change)
this is in a simple form described SLAAC
https://www.networkacademy.io/ccna/ipv6/stateless-address-autoconfiguration-slaac
 
Last edited:

andrew_g

Member
Joined
Oct 12, 2007
Messages
153
Reaction score
5
maybe because I'm on the *ancient'*ONT on Singtel and in VLAN10, I've reviewed the various ONT / ONR issues , I tried different dhcp client requests , but each time I'm only seeing a /128 , i.e. there is no /64 delegation etc.
https://forums.hardwarezone.com.sg/threads/ipv6-discussions.6976522/post-157325606
I tried /64 and /56 to the same effect, there are no delegated prefix seen in the lease file nor logs.

I'm not too sure if in the newer ONR setup in 'bridge' mode if the responses may be different.

In theory, if it is /128, even if you patch a /64, the upstream router in ISP (e.g. Singtel) isn't going to forward the packets. so I'm speculating that a possible upstream routing configuration could be

2400:d802::/56 -> that interface (on ISP's big giant router, very speculative oversimplified)

this would give an 'illusion' that one has a /64 or even /56, there is an interesting 'fair' risk of collisions though.
it'd be one of those things I'd try. A catch with this 'approach' , as I speculate something like this
https://en.wikipedia.org/wiki/Neighbor_Discovery_Protocol
when upstream has a packet intended for 'someone' (a downstream) in 2400:d802::/56,
it needs to do Neighbor Solicitation (Type 135) (e.g. who has 2400:d802::xxyy ), and the router (e.g. wan box' if configured to receive 2400:d802::/56, may answer Neighbor Advertisement (Type 136) "yes here".
possibly multiple answers if ''everyone" say "yes I'm 2400:d802::/56.
shhh , implied 'neighbours' traffic received. It is a *bad* and 'good' thing.

the 'logic' is that if *stingy* ISP gives 1 /128 address sequentially, that for sure would route at the router.
but if it is a 'catch all' route upstream, the local router can answer "yes I'm 2400:d802::/56.
so do 'everybody' else (router).
if the notion is that with SLAAC, 'everyone' invents their own /64 address (the lower 64 bits)
https://www.networkacademy.io/ccna/ipv6/stateless-address-autoconfiguration-slaac
chances are that it would 'just works' without collisions.
but the catch is 'everyone' is sharing the same prefix.

this is pure speculation, unproven.

the other possibility could be that the ISP (e.g. singtel ) actually give /64 , but that the prefix and netmask is not provided in the dhcp response, this by default means /128. that'd be a 'misconfiguration' issue, a bit strange.

It is bad if local ISPs after all miser about IPv6 addresses when the internet is going mainstream with IPv6.
An unacceptable status quo where the standard is after all SLAAC 64 bit host addresses.
 
Last edited:

xiaofan

High Supremacy Member
Joined
Sep 16, 2018
Messages
32,662
Reaction score
10,204
@andrew_g

Not an IPv6 expert and no longer using SingTel ONT so I cannot help you much.

I can only tell you I had no issues with native /56 IPv6 prefix delegation when I was using SingTel ONT (VLAN 10 for Internet and VLAN 20 for SingTel TV), from Nov 2023 to August 2025.

Initially I could only get Asus and OpwnWRT working but not pfSense/OPNsense. But later magically pfSense/OPNsense also worked.

After upgrading to SingTel 5Gbps plan in August 2025 and changing to SingTel XGS-PON ONR, I can get /56 on the WAN side (one /128 IPv6 and then /56 prefix delegation). However I could only get single /64 prefix delegation to work on single LAN port and not the other LAN port. Effectively it becomes /64 for me.

You can search this thread for more information.

Basically there are no special settings for me.
1) WAN side: DHCPv6 and /56
2) LAN side: /64, DHCPv6 and SLAAC.

In fact default OpenWRT IPv6 settings work just fine, no matter when I was using SingTel GPON ONT, or now SingTel XGS-PON ONR. The only difference is tgat I have problems when I want to add the second LAN port to the OpenWRT router. The second LAN port will get the /64 prefix delegation but will have no Internet access. DNS is fine but no IPv6 Gateway to the internet.

You may have to provide the details of your setup and then IPv6 experts like @bert64 can help you.
 
Last edited:

xiaofan

High Supremacy Member
Joined
Sep 16, 2018
Messages
32,662
Reaction score
10,204
Just post my Singtel native IPv6 related configurations here for references.

You can see that I do not even specify /56 on the WAN side, but it does get /56 from DHCPv6-PD.
I specify /60 for the LAN side and it does get /60.

LAN clients will get two IPv6 addresses if they support both DHCPv6 and SLAAC.
DHCPv6 --> 2400:d802:dxx:xx00::xxxx
SLAAC --> 2400:d802:dxx:xx00:xxxx:xxxx:xxxx:xxxx

Android client will only get IPv6 address from SLAAC.
SLAAC --> 2400:d802:dxx:xx00:xxxx:xxxx:xxxx:xxxx

xoKh40r.png


Lm0IUlB.png


qiABBPK.png


JnHIHw2.png


IIjlHPt.png


4noUEok.png


Bash:
PS C:\work> ssh root@192.168.50.1
root@192.168.50.1's password:


BusyBox v1.36.1 (2025-06-23 20:40:36 UTC) built-in shell (ash)

  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 -----------------------------------------------------
 OpenWrt 24.10.2, r28739-d9340319c6
 -----------------------------------------------------
root@openwrt18:~# 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 'fd27:5332:6682::/48'
        option packet_steering '1'

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

config interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option ipaddr '192.168.50.1'
        option netmask '255.255.255.0'
        option ip6assign '60'

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

config interface 'wan6'
        option device 'eth1'
        option proto 'dhcpv6'

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

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

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

config dnsmasq
        option domainneeded '1'
        option localise_queries '1'
        option rebind_protection '1'
        option rebind_localhost '1'
        option local '/lan/'
        option expandhosts '1'
        option cachesize '1000'
        option authoritative '1'
        option readethers '1'
        option leasefile '/tmp/dhcp.leases'
        option localservice '1'
        option ednspacket_max '1232'
        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'
        list server '127.0.0.1#5055'
        option domain 'myop1ddns.duckdns.org'
        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'
        list doh_server '127.0.0.1#5055'
        option serversfile '/var/run/adblock-fast/dnsmasq.servers'

config dhcp 'lan'
        option interface 'lan'
        option start '50'
        option limit '250'
        option leasetime '12h'
        option dhcpv4 'server'
        option dhcpv6 'server'
        option ra 'server'
        list ra_flags 'managed-config'
        list ra_flags 'other-config'

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'
 

xiaofan

High Supremacy Member
Joined
Sep 16, 2018
Messages
32,662
Reaction score
10,204
LAN client IPv6 Test result: Windows Laptop.

I have also tested Android and iOS clients, as well as macOS, Linux and FreeBSD/OpenBSD/NetBSD clients.
https://test-ipv6.com/

wtKOpNn.png


The issue I am facing is that any other non-default /64 prefix does not work, for example, the following does not work (no Internet Access).
DHCPv6 --> 2400:d802:dxx:xx08::xxxx
SLAAC --> 2400:d802:dxx:xx08:xxxx:xxxx:xxxx:xxxx

So I cannot get sub-router's clients to work with IPv6 other than using IPv6 Passthrough on the subrouter (behind main OpenWRT router, Double NAT).

NAT66 is of course another way since IPv6 passthrough may not be guaranteed to work. So far I have good lucks with IPv6 passthrough with Asus, TP-Link, Xiaomi China, ZTE China, Huawei China and TP-Link China wireless routers. I can also use NAT66 with OpenWRT. No dice with pfSense/OPNsense router behind the main OpenWRT router (Double NAT). Both do not work with either NAT66 or IPv6 Passthrough.

But I have mostly flattened out the network and changed my wireless router behind the main OpenWRT router to run in AP mode (Asus RT-AX86U and Asus TUF-BE6500 now). I still run my TP-Link Archer BE805 in router mode (Double NAT) but it is not always ON. In the end I may want to change it to AP mode as well.
 
Last edited:

xiaofan

High Supremacy Member
Joined
Sep 16, 2018
Messages
32,662
Reaction score
10,204
I tried setting up my router (actually a pc runninig linux) ,

I will suggest that you use a easier-to-use router OS like OpenWRT, pfSense, OPNsense and try that first.

For example, I am not so sure if your Linux machine has the proper firewall settings to get IPv6 working properly.

The following shows OpenWRT's default firewall settings.

Bash:
root@openwrt18:~# cat /etc/config/firewall

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

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

config zone 'wan'
        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'

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'

...
 

xiaofan

High Supremacy Member
Joined
Sep 16, 2018
Messages
32,662
Reaction score
10,204
The issue I am facing is that any other non-default /64 prefix does not work, for example, the following does not work (no Internet Access).
DHCPv6 --> 2400:d802:dxx:xx08::xxxx
SLAAC --> 2400:d802:dxx:xx08:xxxx:xxxx:xxxx:xxxx

So I cannot get sub-router's clients to work with IPv6 other than using IPv6 Passthrough on the subrouter (behind main OpenWRT router, Double NAT).

Example OpenWRT sub-router behind the main OpenWRT router.

OpenWRT main router LAN address: 192.168.38.1, 2400:d802:0dxx:xx00::1.
OpenWRT sub-router LAN address: 192.168.48.1, 2400:d802:0dxx:xx08::1.

Then I can see that the LAN clients of the sub-router can not access the internet. It seems to me somehow it Singtel side blocks the access.

Bash:
root@debian12ct21:~# mtr dns.google.com
                                My traceroute  [v0.95]
debian12ct21 (2400:d802:dxx:xx08::4b7) -> dns.google.com (20012025-09-14T14:09:45+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:xx08::1                    0.0%    15    0.3   0.3   0.2   0.4   0.1
 2. 2400:d802:dxx:xx00::1                    0.0%    15    0.8   0.6   0.4   0.8   0.1
 3. (waiting for reply)

LAN clients of the main router, including the sub-router itself, have internet access.

Bash:
root@OpenWrt:~# mtr dns.google.com

                                                 My traceroute  [v0.95]
OpenWrt (2400:d802:db6:8300:be24:11ff:fee9:cbc0) -> dns.google.com (2001:4860:4860::8844)      2025-09-14T14:08:51+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:xx00::1                                                     0.0%    20    0.5   0.5   0.3   0.6   0.1
 2. 2400:d801:4001:611::                                                      0.0%    20    1.8   2.0   1.4   2.3   0.2
 3. 2001:c20:3c00::6                                                          0.0%    20    3.6   4.7   2.2  18.1   4.4
 4. 2001:c20:3c00::7                                                          0.0%    19    2.3   6.2   2.2  29.7   7.2
 5. 2001:c20:0:3::35                                                         21.1%    19   10.0  16.5   1.9  67.2  17.8
 6. 2001:c20:0:3::a                                                           0.0%    19    2.0   2.1   1.3   2.6   0.3
 7. 2001:4860:1:1::2606                                                       5.3%    19    2.1   2.3   1.8   2.7   0.3
 8. 2404:6800:8099::1                                                        21.1%    19    3.9   3.8   3.2   4.4   0.3
 9. dns.google                                                                0.0%    19    3.0   2.8   2.3   3.2   0.3
 
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