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
Re: Testing v7, no need for ipv6
You can't remove it but it can be disabled /ipv6 settings set disable-ipv6=yes
Re: Testing v7, no need for ipv6
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.
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.
Re: Testing v7, no need for ipv6
What exactly consumes resources? Why do you think that IPv6 consumes resources when it is disabled?
Re: Testing v7, no need for ipv6
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.
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.
Re: Testing v7, no need for ipv6
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.
So no risk of an unknown exploit activating and exploiting the unneeded code.
Re: Testing v7, no need for ipv6
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.
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.
Re: Testing v7, no need for ipv6
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?
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?
Re: Testing v7, no need for ipv6
Shocking story there, Shoka.
Got your tin-foil hat ready for when IPv4 will be deprecated?
Got your tin-foil hat ready for when IPv4 will be deprecated?
Re: Testing v7, no need for ipv6
But that is exactly what /ipv6/settings/set disable-ipv6=yes is doing
Re: Testing v7, no need for ipv6
Amen to that!Shocking story there, Shoka.
Got your tin-foil hat ready for when IPv4 will be deprecated?
Re: Testing v7, no need for ipv6
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.
Code: Select all
[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
..
Re: Testing v7, no need for ipv6
Maybe you should bring the "enable IPv6 once it is disabled" under the "need to press button within a minute" dance?But that is exactly what /ipv6/settings/set disable-ipv6=yes is doing
That would maybe satisfy him that a remote hacker cannot re-enable IPv6 when he has disabled it.
Re: Testing v7, no need for ipv6
Yes FTP can be disabled. But dccp, sctp and udplite cannot.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.Code: Select all[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 ..
Re: Testing v7, no need for ipv6
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.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.
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:
1. make minimal connection to internet (preferably behind another router, e.g. connect ether1 to a LAN that has DHCP and NAT access to internet)
2. login and set password
3. enable IPv6 package
4. perform upgrade to latest stable release (reboot)
5. upgrade firmware too
6. do a full reset to defaults except user info (reboot)
7. only now, start real configuration work
But that is not what it says on the short leaflet in the box, so who is going to do it that way?
Re: Testing v7, no need for ipv6
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.Yes FTP can be disabled. But dccp, sctp and udplite cannot.
Re: Testing v7, no need for ipv6
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...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.Yes FTP can be disabled. But dccp, sctp and udplite cannot.
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".
Re: Testing v7, no need for ipv6
I'm just giving the explanation why, the documentation is also updated.
Re: Testing v7, no need for ipv6
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- ... g_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- ... g_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_ ... l_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.
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- ... g_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- ... g_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_ ... l_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.
Re: Testing v7, no need for ipv6
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.
About udplite, sctp, dccp see my previous posts.
Re: Testing v7, no need for ipv6
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.Yes FTP can be disabled. But dccp, sctp and udplite cannot.
No need to unload a `ct` extension, unload the corresponding kernel modules.
If Mikrotik refuses to "listen" to its clients requirements, maybe the STIGs recommandations from the DoD may have more weight ? They recommand to disable SCTP on RedHat [1] and since then RedHat does it by defautl, they recommand the same with dccp on Oracle linux [2]. Further, the ansible hardening role disables both DCCP and SFTP since january 2021 [3,4], why wouldn't mikrotik be able to do it ?
If the modules are blacklisted then even if `ct` is "able to" track them, it "won't do" it (this is what is achieved with IPv6), or am I missing something about RouterOS ?
As for UDPLite... You could handle this by just adding a drop rule to iptables input firewall ruleset [5]. Just add a non-removable rule at the begining of the chain (you already automatically add rules for various reasons based on user configuration, why wouldn't you do it to block udplite this way?)
[1] https://www.stigviewer.com/stig/red_hat ... g/V-230496
[2] https://www.stigviewer.com/stig/oracle_ ... g/V-221713
[3] https://github.com/konstruktoid/ansible ... b17fdb3436
[4] https://github.com/konstruktoid/ansible ... /issues/27
[5] https://www.stigviewer.com/stig/vmware_ ... ng/V-88555
Re: Testing v7, no need for ipv6
The handlers for these protocols are not modules. No idea why, I checked it on my Debian install and they are not modules either. So you cannot unload them.
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.
No need to unload a `ct` extension, unload the corresponding kernel modules.
On the other hand, it has been a recommendation for a decade or so to no longer use the default mapping of the helper modules but instead use explicit firewall rules with the CT target to map traffic to helpers. When doing it that way, it can be enabled/disabled in the firewall rules.
Of course it would mean a change of the user interface and configuration, something MikroTik may hesitate to do. Doing it in v7 should be possible, there are other big changes in how thing work that are handled by the v6->v7 upgrade.
Re: Testing v7, no need for ipv6
When I go to [1] and search for sctp or dccp, I find corresponding modules to add support to the kernel. Their availability is confirmed with "modinfo" command on Devuan with kernel 5.10 (also checked a Mint box with kernel 5.13 with the same result). If you remove the support of sctp and dccp from the kernel, it should do the job isn't it ? (or am I missing something)The handlers for these protocols are not modules. No idea why, I checked it on my Debian install and they are not modules either. So you cannot unload them.
Edit: on my boxes, the modules sctp and dccp are installed. You can check it with :
Code: Select all
find /lib/modules/$(uname -r)/kernel/net -iname dccp
find /lib/modules/$(uname -r)/kernel/net -iname sctp
Re: Testing v7, no need for ipv6
Those are not the connection tracking helper modules, but the protocol implementation.
The helper modules are installed in /lib/modules/$(uname -r)/kernel/net/netfilter/nf_conntrack_xxxx.ko
There is no nf_conntrack_dccp.ko nor nf_conntrack_sctp.ko
The helper modules are installed in /lib/modules/$(uname -r)/kernel/net/netfilter/nf_conntrack_xxxx.ko
There is no nf_conntrack_dccp.ko nor nf_conntrack_sctp.ko
Re: Testing v7, no need for ipv6
I know, but if you disable sctp and sccp protocol implementation modules from the kernel (as you do with ipv6) should'nt be sctp and dccp simply "unusable" ?Those are not the connection tracking helper modules, but the protocol implementation.
The helper modules are installed in /lib/modules/$(uname -r)/kernel/net/netfilter/nf_conntrack_xxxx.ko
There is no nf_conntrack_dccp.ko nor nf_conntrack_sctp.ko
Re: Testing v7, no need for ipv6
I think they are not in use anyway. This is not about the router using those protocols, it is about a helper being present for NAT of those protocols as used by clients on the network.
Re: Testing v7, no need for ipv6
But you can already do that, just add appropriate rules to whatever you want to dropAs for UDPLite... You could handle this by just adding a drop rule to iptables input firewall ruleset [5]
/ip/firewall/filter> add protocol=udp-lite action=drop
Re: Testing v7, no need for ipv6
You need to be smoking some high grade crack to think that disabling ALG/NAT Traversal helpers for DCCP, UDP-Lite, SCTP and even Multi-Path TCP in some NOSes is a wise idea when the very first thing you do is NAT.
The same applies to SIP+FTP, simply change the ports to reflect the actual ports you use in either TX/RX direction instead of disabling.
The amount of network engineering “experts” out there is disheartening.
@OP I think you haven't done a lot of real life CGNAT/NAT deployments to understand what it does to underlay traffic and what headaches it creates for devs behind WebRTC/STUN/TURN/ICE.
I suggest you pick up a book, start learning, deploy IPv4+NAT the right way and migrate to IPv6.
The same applies to SIP+FTP, simply change the ports to reflect the actual ports you use in either TX/RX direction instead of disabling.
The amount of network engineering “experts” out there is disheartening.
@OP I think you haven't done a lot of real life CGNAT/NAT deployments to understand what it does to underlay traffic and what headaches it creates for devs behind WebRTC/STUN/TURN/ICE.
I suggest you pick up a book, start learning, deploy IPv4+NAT the right way and migrate to IPv6.
Re: Testing v7, no need for ipv6
Oh boy...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.
How long will v6 be supported?
Most of your post is simply wrong, the other parts are not wrong because they just don't make sense.
How long will IPv6 be supported? It is built/made to be used between colonized planets.. It is/was designed to replace IPv4.
IPv6 is more efficient than IPv4, not less. More complex? How so?
IPv4 can be thought of as just an experiment, it worked, so everybody said, "it is working, don't touch it".. IPv6 was thought over, discussed, and debated by multiple committees for a long time..
I used to do that, just disable IPv6 in any system I interacted with, but that is just a crutch.. Every "issue" you have with IPv6, already has a solution, every annoyance is there for a good reason.
The biggest security issue with IPv6 is that if you are not using it, turning it off on your routers for example, that it becomes easy to setup a MITM router on your LAN to capture lots of traffic.
All OS's default and prefer IPv6 over IPv4.. If you have an office of people accessing a mainframe using telnet, a network device can advertise IPv6 addresses and an IPv6 address for the mainframe's FQDN, workstations will automatically start using and prefer it.. All it has to do is then forward the traffic to the IPv4 address and nobody would notice for a period of time. Especially *you* on the router, ignoring any/all IPv6 traffic.
If you had setup IPv6, you would have the tools and knowedge to notice.
IPv6 isn't going away, IPv4 is. I strongly suggest you learn it.
The time to voice your complaints and suggestions for IPv6 has long past (20+ years ago).. A speak-now-or-forever-hold-your-peace situation.. It was published in 1996 and updated in 1998.. I don't agree with all (just one actually) the updates/changes done in 1998, but that is my opinion.