Testing upgrade to v7
Somewhat dismayed by the single package, including ipv6.
I have no need of ipv6, and would like to avoid it completely.
Ideally I’d like a download package without ipv6, or if that is not possible, a process to remove the ipv6 package post install.
Harry
You can’t remove it but it can be disabled /ipv6 settings set disable-ipv6=yes
Yes, I recognize that it can be disabled. It still consumes resources, as far as I can tell.
I also wonder what other modules are now compiled in, such as calea, that I definitely do not want anywhere near any system of mine.
One of the nicer features or RouterOS was its configurability. This change does not seem a positive move.
What exactly consumes resources? Why do you think that IPv6 consumes resources when it is disabled?
I think he’s just saying that when certain things were modular they were presumably guaranteed to not be loaded into RAM, whereas when they are built into the kernel on v7 (or whatever the appropriate term is for how they’re included, baked in, non-optional, etc) then they are implicitly taking up some RAM that might otherwise be saved. Maybe he’s on an older device or on that is more RAM-limited.
I would say to the OP that HeX (750Gr3) routers are extremely cheap (~$50 in the US, probably similarly cheap elsewhere) and have 256GB of RAM, a glut even for many Mikrotik devices, since they can run The Dude. Even with Dude running in most instances it still has a lot of RAM to spare.
More precisely, they could not be loaded, at all, as the code was not present in the box.
So no risk of an unknown exploit activating and exploiting the unneeded code.
I’m pretty sure that even in ROS v6, where IPv6 was separate package, kernel shiped in system package had IPv6 support included[*]. What ipv6.npk package added were configuration parsers and utilities … and perhaps change in kernel boot parameters and/or sysctl settings. Which can be (or even are) handled by setting mentioned by @tdw above. So the only benefit of having separate ipv6 package is inability to configure IPv6, but if there’s exploit in the wild that can compromise router without relying on configuration tools, it could do its job even in ROS v6 without ipv6.npk installed.
OTOH it’s about time for just everybody to support dual stack (IPv4 and IPv6) and security (through obscurity) should not be excuse. Specially so as installing ipv6 package on ROS v6 after initial deployment meant big hassle to get decent IPv6 firewall in place (there are different ways, none of them are easy). Having IPv6 installed by default makes this part much easier, specially for less experienced MT users.
[*] I might be wrong and ipv6 kernel module is actually included in ipv6.npk … feel free to verify and prove my thinking wrong. Personally I don’t care and thus won’t check myself.
Basic tenet of security. Enable what you use, disable what you don’t.
Every unnecessary function you enable adds potential vulnerability’s.
IPv6 evangelists aside, the need for IPv6 is dubious at best. For me at least it is absolutely unnecessary.
It’s less efficient than ipv4. It’s more complex than ipv4. ipv6 tunneled over IPv4 is the worst of both worlds.
It offers as its justification “universal connectivity”.
That is simply an alternative statement of “universal vulnerability”.
Worse it builds in auto configuration. So if some device on the network tries to bypass the blocks that exist to limit “universal vulnerability” the ipv6 functions will actively assist in bypassing those blocks.
On ipv4 those “features” are add-ons to the protocol and can be disabled.
If the kernel command line was an accessible property of routeros, I’d be less unhappy, since Linux does properly honer ip6disable=1 on the kernel command line, and will block
attempts to start ipv6. Other “blocks” can be overwritten from the running system.
I’m also disgusted to note that the service ports menu on ip firewall is now effectively useless, as any attempt to disable a service port simply gets the message that that is a built in and cannot be disabled.
Wonderful
How long will v6 be supported?
Shocking story there, Shoka.
Got your tin-foil hat ready for when IPv4 will be deprecated?
But that is exactly what /ipv6/settings/set disable-ipv6=yes is doing
Amen to that!
[admin@CCR2004_2XS] /ip/firewall/service-port> disable 0
[admin@CCR2004_2XS] /ip/firewall/service-port> print
Flags: X, I - INVALID
Columns: NAME, PORTS
# NAME PORTS
0 X ftp 21
..
Maybe you should bring the “enable IPv6 once it is disabled” under the “need to press button within a minute” dance?
That would maybe satisfy him that a remote hacker cannot re-enable IPv6 when he has disabled it.
Yes FTP can be disabled. But dccp, sctp and udplite cannot.
Yes, indeed it is an irritating bug that installing or enabling an optional package that wasn’t enabled on the first router boot will not apply default configuration.
It mostly affects IPv6. Most users will power-up the router, start configuring it, after some time notice that IPv6 is disabled (in v6), enable it, and then they have no firewall.
Of course the correct sequence of installation of a new device is:
But that is not what it says on the short leaflet in the box, so who is going to do it that way?
Those helpers are not separate modules that can be unloaded like the rest. They are built into connection tracking, so they can be inactive only when connection tracking itself is disabled.
But that is insider technical info for someone who knows how helper modules are enabled/disabled which is not obvious for people like Shoka who simply want to disable everything they do not use or do not understand…
When you think “I do not use dccp, let’s disable that” you do not know beforehand “disabling a service port in the firewall menu means unloading the helper module, and that cannot be done when the helper isn’t a module”.
I’m just giving the explanation why, the documentation is also updated.
udplite - https://en.wikipedia.org/wiki/UDP-Lite
Basically allow damaged data into the system and hope that the upper layers can cope…
Not used anywhere in my network, and any application requiring it probably needs banning as well.
pptp - https://en.wikipedia.org/wiki/Point-to-Point_Tunneling_Protocol
Note the obsolete protocol with known security issues.
Not used anywhere in my network, and again any set up using it probably needs to be banned as well.
Does MikroTik use this protocol internally??
sctp - https://en.wikipedia.org/wiki/Point-to-Point_Tunneling_Protocol
Of interest only in VOIP networks.
I segregate the VOIP network from the general network because of the
dubious security of a slew of voice protocols.
The voice router may need this but the others do not.
irc - https://en.wikipedia.org/wiki/Internet_Relay_Chat
Largely obsolete, replaced by other protocols like https://en.wikipedia.org/wiki/XMPP that use tcp or http as the underlayer.
Commonly used as the command channel for a number of bot-nets. Disable unless you have a “real” need for the protocol.
So far I don’t.
dccp - https://en.wikipedia.org/wiki/Datagram_Congestion_Control_Protocol
Some voice and games traffic. No requirement on my network, never seen it on the uplink. Nothing breaks if I shut it off.
What I’m struggling with, is that Linux provides a pretty strong modularization suite, that v6 used to great effect.
The regression to essentially a monolithic kernel. with all the unneeded shit built in is really really sad.
I’m guessing that race to the bottom is driven by the need to cater to the ignorant newbies.
sigh.
You can still disable irc, pptp and other modules that you were able to disable in ROSv6.
About udplite, sctp, dccp see my previous posts.