Hi,
Now, when connect new Mikrotik product, by default every package is enabled except ipv6.
Is possible ( and interesant ) to enable ipv6 package in future versions by default?

I don't think this is a good idea.
Setting up IPv6 connectivity is not that trivial, and it "features" inherent security risks, since each host will actually get a public IP, which means that correct firewall configurations are crucial. This means that beginners and casual users will have a rough time with this.
So:
- Those that don't know what it is about will not need it.
- Those that do know what they want, will probably not mind to enable a specific package in the list.

With just the IPv6 package enabled (but not configured), it does nothing except providing the ability to configure it.

With just the IPv6 package enabled (but not configured), it does nothing except providing the ability to configure it.

And automatically add link local addresses to the interfaces.
You are right. Actually not a problem by itself.

With just the IPv6 package enabled (but not configured), it does nothing except providing the ability to configure it.

And automatically add link local addresses to the interfaces.
You are right. Actually not a problem by itself.

+1.
If package is enable but not configured isn't a problem.

Mikrotik team, what do you think?

Also, the default firewall entries for only allowing outgoing traffic and related incoming traffic should make this
just as "secure" as a normal IPv4 NAT setup.

I agree. The fact that this is disabled says to me that IPv6 is still somewhat of a "back burner" feature for Mikrotik.
With all of the RIR's being at or very near address exhaustion, one would think that v6 should start to get more focus.

Does Mikrotik's IPv6 dhcp-server support stateless server yet? (so you can assign DNS server, TFTP server, etc in a pure-v6 client that doesn't pay attention to DNS in the RA packets? - i.e. winderz)

I have no experience with that. My ISP has native IPv6 on all accounts, using (unfortunately) PPPoE and DHCP-PD and this works fine. My Linux clients also work fine on SLAAC/RA. I don't use DHCPv6 internally.

But of course I needed to install the IPv6 package to get this working and I agree that by now that should be installed by default.

I have no experience with that. My ISP has native IPv6 on all accounts, using (unfortunately) PPPoE and DHCP-PD and this works fine. My Linux clients also work fine on SLAAC/RA. I don't use DHCPv6 internally.

I'm not even asking for stateful dhcp-v6 host assignment at this point.
My ISP uses dhcpv6-pd as well, and it works great for me, but part of this is because my network is dual stack and the IPv4 portion picks up the DNS server address. Basically, my laptop (win7) uses v4 to do the hostname resolution, and then gets the AAAA reply and connects to the appropriate v6 address.

I configured a test v6-only wlan, and the windows box won't work on it unless I manually configure the IPv6 address of the DNS server. My apple devices seem to pick up the SLAAC/RA information properly.

Anyway, most folks are running dual stack right now, but this is one of those things that needs to get fixed so v6 "just works" for most people's installations.

Another glaringly missing thing is SLAAC client functionality on an interface. SLAAC is mostly useless on a router since you need prefixes to apply to other interfaces, but since PD doesn't specify a default GW, Mikrotik has that workaround to use the DHCP address as the default GW..... this happens to work with my ISP, but I could see a scenario where the DHCP service comes from a different host than the router, so it should at least be possible to run an instance of SLAAC on an interface just for picking up the default GW information.

I haven't yet tried plugging my laptop directly into the cablemodem to see if SLAAC is even available on their access segment, though.

Does Mikrotik's IPv6 dhcp-server support stateless server yet?

Supposedly it does and for a long time, unless I'm misinterpreting it somehow. But I did not have any luck with that so far. Not that I tried too much.

I very quickly retested it now with CHR 6.34rc30 as server, Windows (7 and 10) as client and Wireshark to let me see what's going on. Windows send DHCPv6 info request, but RouterOS does not like it, it says "invalid packet: does not contain serverid". I didn't have time yet, to find out who's wrong here, so that I could send proper bug report.

But even if it did work, it's probably still not good enough, because you can't configure anything. I assume it would just take the address from /ip dns, the same way it's done for DNS in RA.

Today I thought about this question.
One posible solution is enable ipv6 by default and configure a small firewall protection.
For example, in ether1-gateway ( or wlan1-gateway ) protect any input and forward package to user's LAN with DROP rules.
If administrator select "remove default configuration" ipv6 package go to disable state and remove all ipv6 rules.
Feedback is welcome

hell, no !!
i hope there wouldn't be other "opened by default vulnerabilities".
ever without actively exploited RA/NDP - IPv6 "enabled by default" - quickly become pain in ... .

hell, no !!
i hope there wouldn't be other "opened by default vulnerabilities".
ever without actively exploited RA/NDP - IPv6 "enabled by default" - quickly become pain in ... .

The default firewall config for IPv4 is "block the WAN, allow the LAN" and doing the same in IPv6 doesn't 'open new vulnerabilities per-se. The fact of the matter is that we're all about to have to start learning IPv6 or stop administering routers and become end-users and let others take over for us.

The RA/NDP vulnerabilities you mention are very valid, but they're addressed in access switches (1st hop security) and not routers, and even if your router isn't doing IPv6, a naughty client doing rogue RA can still hijack other LAN clients that listen for IPv6 RA.....

hell, no !!
i hope there wouldn't be other "opened by default vulnerabilities".
ever without actively exploited RA/NDP - IPv6 "enabled by default" - quickly become pain in ... .

The default firewall config for IPv4 is "block the WAN, allow the LAN" and doing the same in IPv6 doesn't 'open new vulnerabilities per-se. The fact of the matter is that we're all about to have to start learning IPv6 or stop administering routers and become end-users and let others take over for us.

The RA/NDP vulnerabilities you mention are very valid, but they're addressed in access switches (1st hop security) and not routers, and even if your router isn't doing IPv6, a naughty client doing rogue RA can still hijack other LAN clients that listen for IPv6 RA.....

that's correct. (but aside that there was plenty of reasons, why im avoid anything in "default config" and feature itself)
as for hijacking for NDP - hardly there was NO way to seriously prevent it, even if you fortressing RA somehow simply because it was "broken by design" and "cryptographic" part of it - intentionally malformed/weakened under NSA supervision/"advice's" which make exploitation slightly less straightforward and bit more resource/time-consuming but as reliable as with RA manipulation.
same about IPv4 - devices still HELPLESS about ARP poisong-alike hijacking, both because hard-wired port-map-ip distributed databases, used by some of ISP's to cover that - not cover all tactics to exploit it.
basically there was two GOOD things in that fields to cover that disaster/big hole in global networking:
1. SEND. Perfect from both "common sense", math and reliability.
flaws: bogus code. implying bit bigger manpower/work in porting to platform.

2. 802.1x designed Specifically for That purpose(aside other features and benefits). ie "port security".
in 802.1x-2008 its had several important appendix RFC, such as macsec, portsec, full port encryption rfc, l2 encryption/signing(quite low-overhead, compared to protecting all traffic) and other goodies, important to.
flaws: almost nobody care to implement it, for more than decade(noted quite few "security-caring" ISP in area and globally), both over copper, fiber and RF(including wif-fi and alikes).
historically thats usual answer from ISP "hey, why you wifi don't support EAP/PEAP ?" "im to busy to properly setup it. never had and not know how to approach RADIUS deployment/usage" or even "i give no fk bout it. give it or take!"/

so my point: there was ironically - no chance for gov't to interfere and enforce something, like happen with say DNSSec and (at lesser scale)IPv4 adoption.
but networking companies - seems pushing 802.1x-relevant 802.11 things(to all three kind of interfaces and devices and SoC, firmware, SDK) bit better. so atleast portsec and macsec itself - already start having HW support(and yeah, some newer(post-2011)features from range of 802.1x - require newer Phy/interfaces, supporting them)for them, which is Cool, i think. question is: how to Motivate networkers to start actually USING them (and "802.1x in general")?
but again, i like SEND idea, code(despite messy documentation and etc) quite much as better solution for specific usage/purpose.
https://en.wikipedia.org/wiki/Secure_Ne ... y_Protocol meant under SEND.
https://github.com/TrustRouter/TrustRouter
http://sourceforge.net/projects/easy-send/
https://code.google.com/p/google-summer ... kec.tar.gz
http://amnesiak.org/NDprotector/
but ARP replacement code/approach(in few obsoleted ports) seens quite incomplete and unusable, yet in SEND, so to cover that - someone had to assemble/write that together for IPv4 aswell. but for IPv6 - its ROCKS !!

so far both L2 things(ARP/NDP) is most broken thing in network stack, aside IPv6 and ipsec in present bogus/messy/broken implementations, themselves.
second only to SMM weakness/backdoor in x86 hosts, perhaps(persistent flaws in TXT, supervisor, IOMMU - are less bumpy, can be(despite pain to) managed, but impose persistent headache too).



p.s.
having more management over NDP/RA without new tech - would b handy aswell in RouterOS.
like various RA-monitoring things/services/packages, like this one https://en.wikipedia.org/wiki/NDPMon
(which is worth considering to ROS inclusion/adoption aswell as SEND (using/supporting 802.1x and affiliated RFC is part of "general recommendations" already)