Community discussions

MikroTik App

Should MikroTik focus on IPv6 rather than other features?

Yes! IPv6 is more important than any other feature at the moment.
17 (53%)
No! I don't care about IPv6, other features are more important to me.
2 (6%)
MikroTik should hire more engineers and developers (even non-Latvian) to speedup development on all ROS features.
13 (41%)
 
Total votes: 32
 
User avatar
Cha0s
Forum Guru
Forum Guru
Topic Author
Posts: 1026
Joined: Tue Oct 11, 2005 4:53 pm

IPv6 feature development speedup.

Mon Nov 25, 2019 5:06 pm

Today we got this announcement from RIPE.
Dear colleagues,

Today, at 15:35 UTC+1 on 25 November 2019, we made our final /22 IPv4 allocation from the last remaining addresses in our available pool. We have now run out of IPv4 addresses.

Our announcement will not come as a surprise for network operators - IPv4 run-out has long been anticipated and planned for by the RIPE community. In fact, it is due to the community's responsible stewardship of these resources that we have been able to provide many thousands of new networks in our service region with /22 allocations after we reached our last /8 in 2012.

----------------------------------------------------------------
Recovered IPv4 Addresses and the Waiting List
----------------------------------------------------------------

Even though we have run out, we will continue to recover IPv4 addresses in the future. These will come from organisations that have gone out of business or whose LIR accounts are closed, or from networks that return addresses they no longer need. They will be allocated to our members according to their position on a new waiting list that is now active.

While we therefore expect to be allocating IPv4 for some time, these small amounts will not come close to the many millions of addresses that networks in our region need today. Only LIRs that have never received an IPv4 allocation from the RIPE NCC (of any size) may request addresses from the waiting list, and they are only eligible to receive a single /24 allocation.

LIRs that have submitted an IPv4 request can see their position on the waiting list in the LIR Portal. A new graph has also been published that shows the number of requests on the waiting list and the number of days that the LIR at the front of the queue has been waiting:
https://www.ripe.net/manage-ips-and-asn ... iting-list

----------------------------------------------------------------
Call for Greater Progress on IPv6
----------------------------------------------------------------

This event is another step on the path towards global exhaustion of the remaining IPv4 addressing space. In recent years, we have seen the emergence of an IPv4 transfer market and greater use of Carrier Grade Network Address Translation (CGNAT) in our region. There are costs and trade-offs with both approaches and neither one solves the underlying problem, which is that there are not enough IPv4 addresses for everyone.

Without wide-scale IPv6 deployment, we risk heading into a future where the growth of our Internet is unnecessarily limited - not by a lack of skilled network engineers, technical equipment or investment, but by a shortage of unique network identifiers. There is still a long way to go, and we call on all stakeholders to play their role in supporting the IPv6 roll-out.

At the RIPE NCC, we are here to support our membership and the wider RIPE community in this work. Aside from allocating the IPv6 resources that will be required, we will continue to provide advice, training, measurements and tools to help network operators as they put their deployment plans into action.

We are optimistic and excited to see what the next chapter will bring. So let's get to work - and together, let's shape the future of the Internet.


Best regards,

Everyone at the RIPE NCC
It is now, more than ever, that we need serious IPv6 support in ROS.
Right now it's beta at best. There is no feature parity with IPv4, and in general is only usable in simple/small networks.
DHCPv6 developments are nice for the SOHO market, but irrelevant to the ISP, Enterprise, Datacenter, etc, markets.

Without the ability to get any more IPv4 prefixes, more and more IPv6 only services will start to appear on the Internet, and we will no longer be able to postpone a full migration to IPv6.

I would argue that IPv6 development is more necessary than v7 or even BGP at this point!

To put it simply, we cannot reliably provide IPv6 over ROS. And if MikroTik will not address this soon, sadly we will have to look for other vendors.
Last edited by Cha0s on Mon Nov 25, 2019 6:46 pm, edited 1 time in total.
 
paulct
Member
Member
Posts: 326
Joined: Fri Jul 12, 2013 5:38 pm

Re: IPv6 feature development speedup.

Mon Nov 25, 2019 6:05 pm

IPv6 + routing engine = :)
 
romihg
newbie
Posts: 38
Joined: Tue Jun 24, 2014 9:07 am
Location: SLOVENIA

Re: IPv6 feature development speedup.

Mon Nov 25, 2019 8:56 pm

First need all ISP give IPv6 to users. In our country all bigger ISP have enabled IPv6 for users. But some users are afraid of IPv6 beacuse they do not know anything about it. Firewalls are not much diferent for IPv6. But now you need take care of all computers on network not just router to do his job.
 
User avatar
nz_monkey
Forum Guru
Forum Guru
Posts: 1896
Joined: Mon Jan 14, 2008 1:53 pm
Location: Over the Rainbow
Contact:

Re: IPv6 feature development speedup.

Tue Nov 26, 2019 9:25 am

IPv6 + routing engine = :)
This x1000
http://thebrotherswisp.com/ | Mikrotik MTCNA, MTCRE, MTCINE | Fortinet NSE7 | Extreme Networks ENA
 
bluenobbe
newbie
Posts: 33
Joined: Wed Jan 26, 2005 1:04 pm
Location: Germany

Re: IPv6 feature development speedup.

Tue Nov 26, 2019 1:01 pm

I'm trying to configure a Mikrotik router to use a DS-Lite (dual stack lite) internet connection as defined in RFCs 6333 and 6334.

DS-Lite combines a native IPv6 connection with a IPIPv6 tunnel to a CGNAT gateway called AFTR (Address Family Transition Router). The router learns the remote tunnel endpoint through DHCP option 64, which contains a fully qualified domain name in the format defined by RFC 3315. The client needs to request this option in order to receive it. IPv4 traffic is sent through the IPv4-in-IPv6 tunnel unmodified: The remote endpoint (AFTR) operated by the ISP performs NAT.

It appears to me that RouterOS does not currently support DS-Lite. Is that correct? DS-Lite is a widely used IPv6 transition mechanism in Germany.

What I'm trying to figure out now is if this functionality can be implemented through scripting. Is there a way to get the DHCPv6 client to request option 64 and provide the resulting FQDN to a script, which could then set up the IPIPv6 tunnel accordingly?
 
pe1chl
Forum Guru
Forum Guru
Posts: 7052
Joined: Mon Jun 08, 2015 12:09 pm

Re: IPv6 feature development speedup.

Tue Nov 26, 2019 3:05 pm

I am not in the position to judge if MikroTik need to (and can afford) to hire more engineers, and if they should continue only with Latvian engineers.
However, I think it is important that the IPv6 support in RouterOS comes on par with IPv4 support as soon as possible.

Unfortunately, at MUM events it appears that the typical MikroTik customer does not care about IPv6 (either because of the "my ISP does not offer it" syndrome that already appeared above or because everything just works for them using IPv4 and any change to add IPv6 is just a risk that can only result in problems and does not yet have any benefits).
It is often said that "when you need IPv6 you need to be vocal about it towards your local distributor". Apparently demands from distributors are more highly valued than from direct customer requests, probably because the people present on the forum and on MUMs are a small subset of the customers that actually buy their equipment, and these people are always very demanding but not representative for the demands from the entire customer base.
 
idlemind
Forum Guru
Forum Guru
Posts: 1148
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: IPv6 feature development speedup.

Tue Nov 26, 2019 5:55 pm

Not a perfect survey from a questions and functionality stand-point. I do feel MikroTik is rapidly getting outpaced in this area. I personally have been using UniFi hardware in my deployments since shortly after the bridging and VLAN rework. I really like that feature and would love to see it ubiquitously adopted in all of the product lines to isolate the switch chip configuration away from the user. That paired with the complete and utter stagnation of feature development around IPv6 is why I've been speaking with my wallet to both my distributors and MikroTik. My slice of the pie might be incredibly small but it's still a slice.

It's positive to see a bump in RouterOS, I really like their approach to licensing the product and I do hope they can bring their IPv6 stack up to speed with the market. If the don't they risk losing their positions in their traditional markets like ISPs, small and medium businesses and home users. Their competitors on price over at Ubiquiti have delivered a fairly functional IPv6 stack, more importantly they've demonstrated the ability to respond to community requirements with functional if incremental code improvements. The entire software industry has been moving to a give me less a lot more frequently in-place of massive dumps years apart. This is a difference MikroTik can act in w/the pipeline they already create with the RC releases by shifting focus to delivering on IPv6.
 
User avatar
Cha0s
Forum Guru
Forum Guru
Topic Author
Posts: 1026
Joined: Tue Oct 11, 2005 4:53 pm

Re: IPv6 feature development speedup.

Thu Nov 28, 2019 9:10 pm

"my ISP does not offer it"
To me this is kind of a chicken and egg problem.

If ROS doesn't fully support it, then yes, ISPs based on ROS won't offer it, and then users won't use it, which in turn translates to "low demand" in MUMs, etc.

IPv6 doesn't bring much benefit to the end user. Yeah they will no longer have NAT, and they will have 18,446,744,073,709,551,616 public IPs available to use in their LAN, but 99% of end users don't care.
So it is only logical that end users won't push for it. This will only ever be the case, when a killer-app or service runs only on IPv6, so there is a demand to be able to access the service (still the end user won't care if it's over IPv6 or anything else, just as long as it works).

In other words, in my opinion, IPv6 is something that ISPs need to push for support from vendors. Not end users. End users don't know what IPv6 is and don't even care.
 
pe1chl
Forum Guru
Forum Guru
Posts: 7052
Joined: Mon Jun 08, 2015 12:09 pm

Re: IPv6 feature development speedup.

Thu Nov 28, 2019 9:16 pm

So it is only logical that end users won't push for it. This will only ever be the case, when a killer-app or service runs only on IPv6, so there is a demand to be able to access the service (still the end user won't care if it's over IPv6 or anything else, just as long as it works).
Maybe the last "legitimate" service that still relies on peer-to-peer networking, online gaming, has to take the lead.
It appears there always are issues with the NAT port forwarding required for online gaming, especially when there is more than one gamer behind the same external address (which is even more likely when the ISP internally uses NAT due to address shortage).
IPv6, of course with proper solutions for the firewalling, could overcome that.

But probably the game developers won't risk a game becoming a failure because it requires IPv6 and the majority of their userbase cannot get it, so it will be difficult.

Who is online

Users browsing this forum: ashoka, cyb, Google [Bot] and 185 guests