Option to add IPv6 addresses to bridge interface

[meliodas]

Hi, the current state of Merlin only allows you to set an IPv4 address on the bridge/LAN interface. Would be useful to also have the option to set IPv6 local addresses on the same interface. If there are other solutions, do inform thanks.

 

[dave14305]

I tested manually adding a ULA address to br0 a few months ago. dnsmasq.conf had to be adjusted to properly serve the prefix to clients. There was an oddity with dnsmasq’s default tag system that was different for this scenario, such as the lan tag did not apply, but a br0 tag had to be added for the ULA range. Specific details (and my memory) are sketchy, but I ultimately dropped the idea.

 

[ColinTaylor]

What is the use case here? If you enable IPv6 on the WAN then the bridge interface already gets a link local IPv6 address (IIRC).

 

[ZebMcKayhan]

What is the use case here? If you enable IPv6 on the WAN then the bridge interface already gets a link local IPv6 address (IIRC).

And if you set DHCP-PD to Disabled you get to put in your own ip for br0, which could be a ULA If so wishes. It wouldn't work for internet (unless firewall rules for ipv6 nat is added) but that's another story.
Unless we know the use case as @ColinTaylor says, it's hard to give proper answer.

 

[meliodas]

And if you set DHCP-PD to Disabled you get to put in your own ip for br0, which could be a ULA If so wishes. It wouldn't work for internet (unless firewall rules for ipv6 nat is added) but that's another story.
Unless we know the use case as @ColinTaylor says, it's hard to give proper answer.

The use case is that my network is IPv6-only and when the router reboots, it's only accessable by it's IPv4 LAN address. So having a ULA address there makes the router accessable over IPv6 as well, even when the net is down..

 

[ZebMcKayhan]

The use case is that my network is IPv6-only and when the router reboots, it's only accessable by it's IPv4 LAN address. So having a ULA address there makes the router accessable over IPv6 as well, even when the net is down..

I have a vague memory of router already giving out ula alongside your public ip... or maybe that was just my setup, I don't use ipv6 on my lan anymore, last time was on 386 fw so things could have changed.

But if it don't, I agree that it should be something you set in the gui, you wouldn't want to use your ever-changing public ip internally.

 

[Crimliar]

Now we know the use case, with the right (ipv6) DDNS you can always use the host.domain.tld such so that could be something like https://c3po.thesearentthesitesyourelookingfor.com:8443

 

[ColinTaylor]

Now we know the use case, with the right (ipv6) DDNS you can always use the host.domain.tld such so that could be something like https://c3po.thesearentthesitesyourelookingfor.com:8443

I think you're missing the point.

The use case is that my network is IPv6-only and when the router reboots, it's only accessable by it's IPv4 LAN address. So having a ULA address there makes the router accessable over IPv6 as well, even when the net is down..

Are you sure you don't already have an IPv6 address? I've just looked at my old RT-AC68U and with IPv6 enabled but the WAN down it has a link local address (EUI-64).

 

[ZebMcKayhan]

The use case is that my network is IPv6-only and when the router reboots, it's only accessable by it's IPv4 LAN address. So having a ULA address there makes the router accessable over IPv6 as well, even when the net is down..

I really hate reading man pages of dnsmasq. Somehow I always have more questions after reading then before. But

--dhcp-range=::1,::400,constructor:eth0
will look for addresses on eth0 and then create a range from <network>::1 to <network>::400. If the interface is assigned more than one network, then the corresponding ranges will be automatically created,

To me sounds like dnsmasq directive would announce all available addresses on the interface.

So perhaps a simple:

ip -6 address add dev br0 your:e:uniq:e:ula::1/64

Would be sufficient. I could not find a way to force a new ra, so perhaps a

service restart_dnsmasq

Would be needed.

I've just looked at my old RT-AC68U and with IPv6 enabled but the WAN down it has a link local address (EUI-64).

Me to... but I somehow cannot use this to access the router gui, neither can I connect via ssh, can you?
But I can ping it...

 

[meliodas]

I think you're missing the point.


Are you sure you don't already have an IPv6 address? I've just looked at my old RT-AC68U and with IPv6 enabled but the WAN down it has a link local address (EUI-64).

Thanks guys for all the replies. LLA is indeed there when IPv6 is enabled. But that's not something you can use for accessing the GUI. ULA's, the RFC1918 equivalent is recommended so that's the common setup most people go with + the address doesn't change just like it's private IPv4 counterpart.

So having the option to set it in the GUI would benefit alot of people that want to use it, me included. Heck, maybe also have an option to auto-generate/auto-populate a ULA address block when ULA is enabled.

 

[prp2]

Thanks guys for all the replies. LLA is indeed there when IPv6 is enabled. But that's not something you can use for accessing the GUI. ULA's, the RFC1918 equivalent is recommended so that's the common setup most people go with + the address doesn't change just like it's private IPv4 counterpart.

So having the option to set it in the GUI would benefit alot of people that want to use it, me included. Heck, maybe also have an option to auto-generate/auto-populate a ULA address block when ULA is enabled.

I do this exact thing.

/jffs/scripts/ula contains:
#!/bin/sh
ip -6 addr add MyULA::1/64 dev br0

Which gets called by /jffs/scripts/services-start so it'll kick in upon reboot:
/jffs/scripts/ula # Assign ULA on boot

And since for some reason the GT-BE98 Pro removes the ULA randomly even when the WAN hasn't dropped, I also have this cron job added in services-start to keep it persistent:
cru a ula '*/1 * * * * /jffs/scripts/ula' # Ensure ULA cronjob runs every minute persistently after boot

Works perfectly. ifconfig br0 confirms all the addressing is there and properly kept assigned.

Also, unrelated to this exactly but I do a similar thing to blackhole all of Google's DNS, /jffs/scripts/blackholes contains:
#!/bin/sh
# Add blackhole routes for Google's DNS servers

# IPv4
ip route add blackhole 8.8.4.4
ip route add blackhole 8.8.8.8

# IPv6
ip -6 route add blackhole 2001:4860:4860::8844
ip -6 route add blackhole 2001:4860:4860::8888

I run two pi-holes locally with unbound as well so don't want hard-coded devices sneaking past. This forces them to behave.

 

[Tvlz]

LLA is indeed there when IPv6 is enabled. But that's not something you can use for accessing the GUI.

Enclose IPv6 LLA in [ ]
http://[fe80::xxxx:xxxx:xxxx:xxxx] works for me

 

[meliodas]

I do this exact thing.

/jffs/scripts/ula contains:
#!/bin/sh
ip -6 addr add MyULA::1/64 dev br0

Which gets called by /jffs/scripts/services-start so it'll kick in upon reboot:
/jffs/scripts/ula # Assign ULA on boot

And since for some reason the GT-BE98 Pro removes the ULA randomly even when the WAN hasn't dropped, I also have this cron job added in services-start to keep it persistent:
cru a ula '*/1 * * * * /jffs/scripts/ula' # Ensure ULA cronjob runs every minute persistently after boot

Works perfectly. ifconfig br0 confirms all the addressing is there and properly kept assigned.

Also, unrelated to this exactly but I do a similar thing to blackhole all of Google's DNS, /jffs/scripts/blackholes contains:
#!/bin/sh
# Add blackhole routes for Google's DNS servers

# IPv4
ip route add blackhole 8.8.4.4
ip route add blackhole 8.8.8.8

# IPv6
ip -6 route add blackhole 2001:4860:4860::8844
ip -6 route add blackhole 2001:4860:4860::8888

I run two pi-holes locally with unbound as well so don't want hard-coded devices sneaking past. This forces them to behave.

Thanks. This does help temporarily. If I recall, when restarting the wan from the GUI, it removes any additional IPv6 addresses on br0, which I have 2 of them and will have to wait till the WAN re-establishes itself so it executes the wan0-connected script and adds back the addresses. A little tedious but a temporary workaround.

Would be great if the devs could add the option to add IPv6 addresses under the LAN section of the GUI.

 

[meliodas]

Enclose IPv6 LLA in [ ]
http://[fe80::xxxx:xxxx:xxxx:xxxx] works for me

I added fe80::1 to br0 and that is advertise as the default gateway to the clients.

 

[Poul Bak]

Me to... but I somehow cannot use this to access the router gui, neither can I connect via ssh, can you?
But I can ping it...

I agree, the router's web server only responds to ipv4 addresses (at least my old RT-AC68U, might have changed on new routers).

 

[prp2]

Thanks. This does help temporarily. If I recall, when restarting the wan from the GUI, it removes any additional IPv6 addresses on br0, which I have 2 of them and will have to wait till the WAN re-establishes itself so it executes the wan0-connected script and adds back the addresses. A little tedious but a temporary workaround.

Would be great if the devs could add the option to add IPv6 addresses under the LAN section of the GUI.

Well like I said that's why I add the cronjob to constantly add back the ULA every minute. If it already exists, it doesn't add it again, and if it's missing it puts it back. Works like a charm.

 

[Crimliar]

Accessing the WEBUI using IPv6 does work on the GT-AX6000 and I would assume on most newer routers. As does, having just tested this, using IPv6 only DDNS with my own domain, which is the much easier option IMHO!

 

[ColinTaylor]

Accessing the WEBUI using IPv6 does work on the GT-AX6000 and I would assume on most newer routers. As does, having just tested this, using IPv6 only DDNS with my own domain, which is the much easier option IMHO!

The issue is how to access the webUI using a local IPv6 address when there is no WAN connection. DDNS won't help there.

 

[sfx2000]

# Add blackhole routes for Google's DNS servers

# IPv4
ip route add blackhole 8.8.4.4
ip route add blackhole 8.8.8.8

# IPv6
ip -6 route add blackhole 2001:4860:4860::8844
ip -6 route add blackhole 2001:4860:4860::8888

Crazy thing with Google Public DNS - the addresses you mention for IPv4/IPv6 are not the only ones - those go to a load-balancer and then go from there out to their cloud...

Your DNS resolvers are:
Google

• 74.125.181.144ns: ns1.google.comLos Angeles, California, US
• 74.125.181.145ns: ns1.google.comLos Angeles, California, US
• 74.125.181.146ns: ns1.google.comLos Angeles, California, US
• 74.125.181.147ns: ns1.google.comLos Angeles, California, US
• 74.125.181.148ns: ns1.google.comLos Angeles, California, US
• 74.125.181.149ns: ns1.google.comLos Angeles, California, US
• 74.125.181.150ns: ns1.google.comLos Angeles, California, US
• 74.125.181.151ns: ns1.google.comLos Angeles, California, US
• 74.125.181.152ns: ns1.google.comLos Angeles, California, US
• 74.125.181.153ns: ns1.google.comLos Angeles, California, US
• 74.125.181.154ns: ns1.google.comLos Angeles, California, US
• 74.125.181.155ns: ns1.google.comLos Angeles, California, US
• 74.125.181.156ns: ns1.google.comLos Angeles, California, US
• 74.125.181.157ns: ns1.google.comLos Angeles, California, US
• 74.125.181.158ns: ns1.google.comLos Angeles, California, US
• 172.253.0.16ns: ns1.google.comLos Angeles, California, US
• 172.253.0.17ns: ns1.google.comLos Angeles, California, US
• 172.253.0.18ns: ns1.google.comLos Angeles, California, US
• 172.253.0.19ns: ns1.google.comLos Angeles, California, US
• 172.253.0.20ns: ns1.google.comLos Angeles, California, US
• 172.253.0.21ns: ns1.google.comLos Angeles, California, US
• 172.253.0.22ns: ns1.google.comLos Angeles, California, US
• 172.253.0.23ns: ns1.google.comLos Angeles, California, US
• 172.253.0.24ns: ns1.google.comLos Angeles, California, US
• 172.253.0.25ns: ns1.google.comLos Angeles, California, US
• 172.253.0.26ns: ns1.google.comLos Angeles, California, US
• 172.253.0.27ns: ns1.google.comLos Angeles, California, US
• 172.253.0.28ns: ns1.google.comLos Angeles, California, US
• 172.253.0.29ns: ns1.google.comLos Angeles, California, US
• 172.253.0.30ns: ns1.google.comLos Angeles, California, US
• 172.253.1.16ns: ns1.google.comLos Angeles, California, US
• 172.253.1.17ns: ns1.google.comLos Angeles, California, US
• 172.253.1.18ns: ns1.google.comLos Angeles, California, US
• 172.253.1.19ns: ns1.google.comLos Angeles, California, US
• 172.253.1.20ns: ns1.google.comLos Angeles, California, US
• 172.253.1.21ns: ns1.google.comLos Angeles, California, US
• 172.253.1.22ns: ns1.google.comLos Angeles, California, US
• 172.253.1.23ns: ns1.google.comLos Angeles, California, US
• 172.253.1.24ns: ns1.google.comLos Angeles, California, US
• 172.253.1.25ns: ns1.google.comLos Angeles, California, US
• 172.253.1.26ns: ns1.google.comLos Angeles, California, US
• 172.253.1.27ns: ns1.google.comLos Angeles, California, US
• 172.253.1.28ns: ns1.google.comLos Angeles, California, US
• 172.253.1.29ns: ns1.google.comLos Angeles, California, US
• 172.253.1.30ns: ns1.google.comLos Angeles, California, US
• 172.253.9.208ns: ns1.google.comLos Angeles, California, US
• 172.253.9.209ns: ns1.google.comLos Angeles, California, US
• 172.253.9.210ns: ns1.google.comLos Angeles, California, US
• 172.253.9.211ns: ns1.google.comLos Angeles, California, US
• 172.253.9.212ns: ns1.google.comLos Angeles, California, US
• 172.253.9.213ns: ns1.google.comLos Angeles, California, US
• 172.253.9.214ns: ns1.google.comLos Angeles, California, US
• 172.253.9.215ns: ns1.google.comLos Angeles, California, US
• 172.253.9.216ns: ns1.google.comLos Angeles, California, US
• 172.253.9.217ns: ns1.google.comLos Angeles, California, US
• 172.253.9.218ns: ns1.google.comLos Angeles, California, US
• 172.253.9.219ns: ns1.google.comLos Angeles, California, US
• 172.253.9.220ns: ns1.google.comLos Angeles, California, US
• 172.253.9.221ns: ns1.google.comLos Angeles, California, US
• 172.253.9.222ns: ns1.google.comLos Angeles, California, US
• 2607:f8b0:4004:1000::121ns: ns1.google.comLos Angeles, California, US
• 2607:f8b0:4004:1000::122ns: ns1.google.comLos Angeles, California, US
• 2607:f8b0:4004:1000::126ns: ns1.google.comLos Angeles, California, US
• 2607:f8b0:4004:1000::127ns: ns1.google.comLos Angeles, California, US
• 2607:f8b0:4004:1000::12bns: ns1.google.comLos Angeles, California, US
• 2607:f8b0:4004:1002::120ns: ns1.google.comLos Angeles, California, US
• 2607:f8b0:4004:1002::122ns: ns1.google.comLos Angeles, California, US
• 2607:f8b0:4004:1002::126ns: ns1.google.comLos Angeles, California, US
• 2607:f8b0:4004:1002::12cns: ns1.google.comLos Angeles, California, US
• 2607:f8b0:4004:1002::12dns: ns1.google.comLos Angeles, California, US
• 2607:f8b0:4004:1002::12ens: ns1.google.comLos Angeles, California, US
• 2607:f8b0:4004:1007::124ns: ns1.google.comLos Angeles, California, US
• 2607:f8b0:4004:1007::126ns: ns1.google.comLos Angeles, California, US
• 2607:f8b0:4004:1007::127ns: ns1.google.comLos Angeles, California, US
• 2607:f8b0:4004:1009::124ns: ns1.google.comLos Angeles, California, US
• 2607:f8b0:4004:1009::12ans: ns1.google.comLos Angeles, California, US

 

[sfx2000]

Crazy thing with Google Public DNS - the addresses you mention for IPv4/IPv6 are not the only ones - those go to a load-balancer and then go from there out to their cloud...

Handy tool to check what DNS servers are actually being used...

dnscheck.tools - check your dns resolvers

A tool to test for DNS leaks, DNSSEC validation, and more

www.dnscheck.tools