Feature Request: 464XLAT

RouterOS
1

A Case for Full 464XLAT Implementation in Mikrotik RouterOS

In an era of accelerating IPv4 address exhaustion, the transition to IPv6 is no longer a distant prospect but a present-day necessity for network operators worldwide. While Mikrotik's RouterOS has long been a favorite for its flexibility and rich feature set, its current lack of comprehensive support for 464XLAT puts it at a disadvantage compared to competitors like Juniper and even open-source solutions like OpenWRT. This document outlines a compelling case for Mikrotik to embrace 464XLAT at all levels—CLAT, NAT64/PLAT, and DNS64—to maintain its competitive edge and meet the evolving needs of its user base.

The Writing on the Wall: IPv6-Only is the Future

Internet Service Providers (ISPs) and large network operators are increasingly moving towards IPv6-only infrastructures to overcome the limitations and costs associated with scarce IPv4 addresses. In such environments, translation mechanisms are crucial to ensure that IPv6-only clients can still access the legacy IPv4 internet. 464XLAT has emerged as a standardized and efficient solution for this challenge, providing seamless compatibility for applications that do not yet support IPv6.

However, Mikrotik's RouterOS currently lacks native support for the key components of 464XLAT:

  • CLAT (Customer-Side Translator): This function is essential on customer premises equipment (CPE) to translate IPv4 traffic from local devices into IPv6 for transport over the ISP's IPv6-only network.

  • NAT64/PLAT (Provider-Side Translator): On the provider side, this component translates the IPv6 traffic back to IPv4 to reach legacy servers. While RouterOS has some NAT capabilities, it does not officially support NAT64.[1]

  • DNS64: This DNS service works in concert with NAT64 to synthesize AAAA records from A records, allowing IPv6-only clients to discover and connect to IPv4 destinations.

The Voice of the Community: A Clear Demand for Change

A review of the Mikrotik community forums reveals a long-standing and persistent demand for 464XLAT support. Users, particularly from the WISP and small ISP sectors, have been requesting these features for years to deploy scalable and future-proof IPv6-only networks.[2][3][4][5] The lack of a native solution forces these loyal customers to seek alternatives, including:

  • Flashing Mikrotik hardware with OpenWRT: It is a testament to the quality of Mikrotik's hardware that users are willing to replace its operating system to gain necessary functionalities. However, this also represents a failure of RouterOS to meet user needs.[2][6]

  • Migrating to other vendors: Competitors that offer robust 464XLAT support are becoming increasingly attractive to network operators who require these features.

The community's message is clear: the absence of native 464XLAT is a significant gap in RouterOS that is hindering their ability to modernize their networks.

The Competitive Landscape: Keeping Pace with the Industry

The networking industry is not standing still. Juniper Networks has long supported the necessary components for 464XLAT, and the open-source community, through projects like OpenWRT/LEDE, has demonstrated that efficient and reliable implementations are readily achievable.[6] By not offering a native 464XLAT solution, Mikrotik risks being perceived as lagging behind current industry standards and best practices for IPv6 transition.

The Path Forward: A Call for Action

To address this critical need and reaffirm its commitment to its user base, Mikrotik is urged to prioritize the development and implementation of a complete 464XLAT solution within RouterOS. This should include:

  1. Full-featured CLAT support for a wide range of RouterBOARD devices, enabling them to serve as capable CPEs in IPv6-only environments.

  2. A robust and scalable NAT64/PLAT implementation to allow service providers to build out their IPv6-only access networks with confidence.

  3. Integrated DNS64 functionality to provide a seamless and transparent experience for end-users.

By embracing 464XLAT, Mikrotik will not only satisfy a significant and vocal segment of its user base but also solidify its position as a forward-thinking and competitive player in the networking industry. The ease of deployment demonstrated by other platforms shows that this is an achievable goal, and its implementation will be a welcome and necessary evolution for the RouterOS platform. The time for Mikrotik to act is now.

Sources help

  1. mikrotik.com
  2. mikrotik.com
  3. mikrotik.com
  4. mikrotik.com
  5. mikrotik.com
  6. brocktice.com
2

Pamatojums pilnīgai 464XLAT ieviešanai Mikrotik RouterOS

Laikmetā, kad IPv4 adrešu izsīkums paātrinās, pāreja uz IPv6 vairs nav tāla perspektīva, bet gan mūsdienu nepieciešamība tīkla operatoriem visā pasaulē. Lai gan Mikrotik RouterOS jau sen ir iecienīts tā elastības un bagātīgā funkciju komplekta dēļ, tā pašreizējais visaptverošā 464XLAT atbalsta trūkums to nostāda neizdevīgākā stāvoklī salīdzinājumā ar konkurentiem, piemēram, Juniper un pat atvērtā koda risinājumiem kā OpenWRT. Šis dokuments izklāsta pārliecinošu pamatojumu, kādēļ Mikrotik būtu jāievieš 464XLAT visos līmeņos — CLAT, NAT64/PLAT un pat DNS64 —, lai saglabātu savu konkurētspēju un apmierinātu lietotāju bāzes mainīgās vajadzības.

Nākotnes vīzija: tikai IPv6

Interneta pakalpojumu sniedzēji (ISP) un lieli tīkla operatori arvien vairāk pāriet uz tikai IPv6 infrastruktūrām, lai pārvarētu ierobežojumus un izmaksas, kas saistītas ar ierobežoto IPv4 adrešu skaitu.[1] Šādās vidēs tulkošanas mehānismi ir būtiski, lai nodrošinātu, ka tikai IPv6 klienti joprojām var piekļūt mantotajam IPv4 internetam.[2][3] 464XLAT ir kļuvis par standartizētu un efektīvu risinājumu šim izaicinājumam, nodrošinot netraucētu saderību lietojumprogrammām, kuras vēl neatbalsta IPv6.

Tomēr Mikrotik RouterOS pašlaik trūkst iebūvēta atbalsta galvenajiem 464XLAT komponentiem:

  • CLAT (Customer-Side Translator): Šī funkcija ir būtiska klienta puses iekārtās (CPE), lai tulkotu IPv4 trafiku no lokālām ierīcēm uz IPv6 transportēšanai pa ISP tikai IPv6 tīklu.[4][5]

  • NAT64/PLAT (Provider-Side Translator): Pakalpojumu sniedzēja pusē šis komponents tulko IPv6 trafiku atpakaļ uz IPv4, lai sasniegtu mantotos serverus. Lai gan RouterOS ir dažas NAT iespējas, tas oficiāli neatbalsta NAT64.[6]

  • DNS64: Šis DNS pakalpojums darbojas kopā ar NAT64, lai sintezētu AAAA ierakstus no A ierakstiem, ļaujot tikai IPv6 klientiem atklāt un izveidot savienojumu ar IPv4 galamērķiem.

Sabiedrības balss: skaidrs pieprasījums pēc pārmaiņām

Pārskatot Mikrotik kopienas forumus, atklājas ilgstošs un pastāvīgs pieprasījums pēc 464XLAT atbalsta. Lietotāji, īpaši no bezvadu interneta pakalpojumu sniedzēju (WISP) un mazo ISP sektoriem, jau gadiem ilgi pieprasa šīs funkcijas, lai ieviestu mērogojamus un nākotnes drošus tikai IPv6 tīklus.[7][8][9] Vietējā risinājuma trūkums liek šiem lojālajiem klientiem meklēt alternatīvas, tostarp:

  • Mikrotik aparatūras pārprogrammēšana ar OpenWRT: Tas liecina par Mikrotik aparatūras kvalitāti, ka lietotāji ir gatavi aizstāt tās operētājsistēmu, lai iegūtu nepieciešamās funkcionalitātes. Tomēr tas arī norāda uz RouterOS nespēju apmierināt lietotāju vajadzības.

  • Pāreja uz citiem piegādātājiem: Konkurenti, kas piedāvā stabilu 464XLAT atbalstu, kļūst arvien pievilcīgāki tīkla operatoriem, kuriem nepieciešamas šīs funkcijas.

Kopienas vēstījums ir skaidrs: iebūvēta 464XLAT trūkums ir būtisks robs RouterOS, kas kavē viņu spēju modernizēt savus tīklus.

Konkurences ainava: iet kopsolī ar nozari

Tīklošanas nozare nestāv uz vietas. Juniper Networks jau sen atbalsta nepieciešamās sastāvdaļas 464XLAT, un atvērtā koda kopiena, izmantojot tādus projektus kā OpenWRT/LEDE, ir pierādījusi, ka efektīvas un uzticamas implementācijas ir viegli sasniedzamas. Nepiedāvājot vietējo 464XLAT risinājumu, Mikrotik riskē tikt uztverts kā atpalicis no pašreizējiem nozares standartiem un labākajām praksēm IPv6 pārejai.

Ceļš uz priekšu: aicinājums rīkoties

Lai risinātu šo kritisko vajadzību un atkārtoti apliecinātu savu apņemšanos pret savu lietotāju bāzi, Mikrotik tiek aicināts prioritāri izstrādāt un ieviest pilnīgu 464XLAT risinājumu RouterOS. Tam vajadzētu ietvert:

  1. Pilnvērtīgu CLAT atbalstu plašam RouterBOARD ierīču klāstam, ļaujot tām darboties kā spējīgām CPE ierīcēm tikai IPv6 vidēs.

  2. Stabilu un mērogojamu NAT64/PLAT implementāciju , lai ļautu pakalpojumu sniedzējiem ar pārliecību izveidot savus tikai IPv6 piekļuves tīklus.

  3. Integrētu DNS64 funkcionalitāti , lai nodrošinātu netraucētu un caurspīdīgu pieredzi galalietotājiem.

Ieviešot 464XLAT, Mikrotik ne tikai apmierinās ievērojamu un vokālu savas lietotāju bāzes daļu, bet arī nostiprinās savu pozīciju kā uz nākotni vērsts un konkurētspējīgs spēlētājs tīklošanas nozarē. Citu platformu demonstrētā vieglā ieviešana liecina, ka tas ir sasniedzams mērķis, un tā ieviešana būs apsveicama un nepieciešama RouterOS platformas evolūcija. Mikrotik ir pienācis laiks rīkoties.

Sources help

  1. hostico.lv
  2. wikipedia.org
  3. cert.lv
  4. ietf.org
  5. ietf.org
  6. lancom-systems.de
  7. wikipedia.org
  8. fiberlight.com
  9. wispa.org
3

Welcome back to the forum Terry, and what a way to make an entrance !

I agree that 464XLAT is sorely needed, hopefully the powers that be will take heed of your request.

4

I have little to add but +++++++++1!

Terry’s request is comprehensive and reasoning is sound. :+1:t3:

5

Guys I hope if you don’t mind asking does the open source implementation of this can scale well or comparable to proprietary solutions? I’ve seen this has been request before but not as comphrehensived as this, kudos to the OP and hope MT will listen

6

LOL, I don’t think I’ve seen a feature request in Latvian before.

+1 … MikroTik seems stuck in dual-stack still.

7

Don’t forget this is already 98% solved by https://www.jool.mx/en/464xlat.html

8

It looks like an AI gnerated post.

9

+1, please add any sort of IPv6 transition mechanism.

10

+1, especially proper NAT64 in RouterOS for the PLAT function.

11

Let's give this a bump.

12

Bump!

IPv6 and NAT - how I changed my mind ← waiting since 2016
NAT64 and DNS64 ← waiting since 2010

13

Please, a general implementation of Tayga or Jool built into routeros would be huge, both the CLAT component and for other variations for implementing ‘duel stack the edge where you must support legacy IP single stack the core’

14

Somebody posted about getting a Tayga container working on RouterOS.

15

Which is interesting for sure and I’ll try it out. Still, official support would be really nice.

16

It’s great that there are NAT64 “Work Arounds” and I hope that is useful at scale.

CLAT support (including UI) would be aweseome, and Jool as a PLAT on big hardware is even better.

The problem will be CPU resources, for sure, as thit is protocol translation.

Router/OS on big bare metal maybe?

17

Before I got ipv6, I used to read all this stuff about translators and tunnels and it scared me shitless. But then one day about 5 years ago I turned on ipv6 in my router [pre Mikrotik days] and discovered my ISP were doing ipv6 and found that my pc's had picked up ipv6 addresses and as far as I could see, I was running ipv6 and ipv4. I have since found the ipvfoo browser addon which confirms this to be the case.

I don't like CGNAT after I had a taste of it for about 2 years when I moved house after discovering ipv6, but I am back on a dual stack ISP. I think that dual stacking by the ISP is the right way to go [and I would not be upset now if my ipv4 went to CGNAT]. So I am about 80% ipv6 - some work on my own systems [vlans on ipv6 awaiting Mikrotik for subnetting plus a very few legacy devices - perhaps 2] - plus external dependencies such as my hosting and the internet which remains on IPv4.

It just strikes me as being so much better if the ISP does dual stack and manages it all on its own estate - rather than taking the support burden of numerous and diversely capable customers all managing Customer Side devices - when probably 70% could not configure their own router even with DHCP.

18

@ductview I love your take on this — ipv6 and ipv4 co-exist, that’s a feature!

Alas, I’m also planning for when ipv4 is too expensive or not available.

Still, I’m sitting on 95% of flows in and out of my network are ipv6.

Just need a little nudge to offload the other 5%.

19

Is your ISP ipv6 only? Or did you nor know that ipv4 and IPv6 can coexist quite seamlessly? I doubt that ISPs will withdraw ipv4 support for a very long time and I think that only begins when all the websites out there go ipv6. And I doubt that home networks will be IPv6 only for a long time after that.

20

I have dual stack, it’s good. But 95% of my traffic is already ipv6 …