Add that rule as well. But it still showing IPv6 address. Am i missing something?
ip add | grep t6
inet6 ::1/128 scope host
inet6 fe80::exad:e0ff:fxxf:25a7/64 scope link
inet6 fe80::exad:e0ff:fxxf:25aa/64 scope link
inet6 fe80::exad:e0ff:fxxf:25a9/64 scope link
inet6 fe80::exad:e0ff:fxxf:25a8/64 scope link
No, you don't.
The proposed solution does not make any changes to the system settings.
It blocks IPv6 traffic (incoming and routed), making it unnecessary to disable IPv6 tails in various places in the system.
That's not a good reason.
Even if you disable IPv6 at the router level your devices can still talk between them via IPv6 LL addresses.
This question pops up often but nobody gave a good reason to do it on the router level.
As long as you're not handing out addresses from the router via RA or DHCPv6 it sits there silent, you disable those and that's it.
The question has been answered on the Forum many times earlier.
This is for security and maintenance simplification reasons.
OpenWRT firewall (fw3/fw4) generates TWO separate sets of IPTABLES rules -
one for IPv4 and another for IPv6.
You can list them via iptables and ip6tables commands.
Most of the regular OpenWRT users are not aware of such duplication
leading to security issues while configuring restrictive firewall rules.
For security and ease of maintenance reasons some administrators
are not willing to maintain two separate firewall tables simultaneously.
The simplest way to get rid of the second, IPv6 firewall table,
is to add two high-priority traffic blocking rules to the IPv6 firewall table.
Interesting, can you show me these TWO separate sets of rules in fw4 please? I don't see such a thing on mine.
Also I'm not using iptables, fw4 uses nftables x.x
How but mostly why are you using iptables with fw4?
You are absolutely right.
It's perfect that FW4 with nftables as a backend combines both IPv4 and IPv6 netfilter rule sets into one.
My comments above were not technically accurate enough regarding the current OpenWRT versions.
However, the meaning of the proposed actions and the syntax of the proposed commands do not change from this.
Not if you disable IPv6 "completely", as in, even at the kernel level, so that option does nothing.
And the switch will "switch" IPv6 packets just fine in any case.
Bottom line: even for "SOHO" every user should learn how to setup his dual stack network properly even if the main one is IPv4. Burying ones head in the sand when it comes to IPv6 doesn't solve anything.
IPv6 origin for WAN/Internet/ISP IP Addressing. The objective is not for SOHO/Intranet IP Addressing.
IPv4 enough to handle SOHO/Intranet IP Addressing.
Second Its all depends on usability and necessity.
Can we configure SOHO with IPv4? Ans is yes.
Do we need IPv6 to configure SOHO? Ans No, IPv4 enough.
For learning, yes its good to know both but when question is to implement, its all depends on "Requirement". If there is no Necessity of IPv6 why should we implement the same? Its about how to keep things. Simple/Complicate. Which is obviously a choice.
Can you try rephrasing that post? It doesn't make much sense.
I've got the implementation part, but don't worry, you don't have to implement anything as a user, you just have to turn off all IPv6 related options available in LuCI.
Now, each network admin needs to decide for their own network and set the desired policy. But in this context I would argue that going DualStack will allow IPv4-usage as already well known while also allowing small experiments with IPv6 so that once IPv6 becomes less optional the SOHO network does not need to do a cold transition. But again that is a matter of subjective taste and not of right or wrong.
What I personally like about IPv6 is that allowing remote access does not require any port games (one can restrict access to specific ports but one does not need to do so).