My IPv6 Triage List for ROS

RouterOS General
1

While RouterOS has supported IPv6 for years now, I think we can all say that the capabilities of ROS in this protocol are pretty vanilla when compared with the rich functionality available in IPv4.

Whenever a new RC is announced here, the thing I scan for first is ipv6 features / bugfixes, because our organization has a heavy deployment of Mikrotiks as CPE, and it’s still my opinion that ROS is lagging behind in IPv6 to the point where I’m having to plan our production roll-out of the protocol based heavily on the behavior of Mikrotik.

Obviously, there are a million potential features that we could all wish for / fixes we may need, but time is money, and effort spent on IPv6 functionality is effort taken away from other enhancements / fixes that we may be waiting for as well. To that end, I would like to post a list of what I feel are the features which are glaringly missing / under-developed in order to improve the functionality of the Mikrotik platform, allowing it to be more useful in a wider variety of scenarios, focusing on (seemingly) simple enhancements and new features which shouldn’t require tons of effort, but would make life a lot better in the IPv6 universe for Mikrotik users.

Here is my list of IPv6 enhancements that I feel would benefit the most users, regardless of whether I would use them personally or professionally at my current company.
(In no particular order)

DHCPv6 stateful host addressing server
Stateful host leasing: For those who wish to have full control over each and every LAN client, SLAAC is a freakin’ nightmare scenario. My former boss would rather be punched in the face every second for a year than let all devices join the network at their own will without any kind of audit trail as to who they are, when they joined, when they left, etc. He is far from being alone in this regard.

Stateless DHCPv6 server
Stateless DHCP is equally important because there are some vendors (cough Microsoft cough) whose paradigm is DHCP primarily because of enterprise customers who share my former boss’s view of network management. To that end, they have not (to my knowledge) yet, nor do they intend to implement the feature of learning DNS server address or domain suffix list from SLAAC. Besides this, there are other devices which we may wish to migrate to v6-only, and it sure would be nice to not need to stay dual-stack on these devices when the only need for IPv4 is for good ol’ reliable DHCPv4 to hand out info options such as TFTP server, NTP server, DNS server, etc… ESPECIALLY when many of these cannot even specify IPv6 addresses using DHCPv4. Can we live without stateless? yeah, but when this is the last shingle to finish the roof over basic LAN assignment mechanisms, it would be great to have it completely working for all paradigms.

Dynamic host<–>IPv6 DNS cache entries for DHCPv6 clients
If driving stateful client addressing with IPv6, it could be an easy option to auto-add the client’s hostname to the DNS cache so that a rudimentary LAN naming space is accomplished - because it sure is hard to remember all 16 nibbles of your devices’ host-IDs while allowing them to remain dynamically configured.

Add AAAA record support to DynDNS updater client
Okay - so this isn’t really a “high priority” triage type of feature, but it seems like something that would be almost effortless to implement, and would allow us poor souls doomed to having dynamic IPv6 prefixes to find our routers whenever we’re away from home and have IPv6 access… or be able to run servers from home with dynamic IPv6 space… etc.

RA Listener
Without NAT66, being a client to RA seems a low priority for a router, but there is value that these messages bring to the table other than being a component of SLAAC address configuration. RA may be the only mechanism that an ISP assigns default GW / DNS information (ahem - Mikrotik routers? lol). Even without NAT, Mikrotik could implement RA client as a sort of “IPv6 dynamic routing protocol” - You could add/disable/remove/edit the interfaces and set administrative distance to enable an RA listener which will assign the highest-priority router’s link-local address as a default GW with the distance determined in the above configuration. RA could be utilized on links as a straight replacement for VRRP with this one simple feature. Furthermore, if the ISP is statically routing blocks to clients, but wants to use RA to provide automatic redundancy, it sure would be nice if Mikrotik routers could play ball in that arena.

RA send on link-local-only segments
As for sending, ROS should be able to send RA messages onto links with only link-local addressing. (where it is not also configured as an RA listener). I’m participating in another thread where it was found that some consumer-grade routers require learning their IPv6 default GW via RA messages. If planning to use link-local-only attachment circuits for customers, this becomes much more important if customers may also BYOD…

Configurable DNS/domain suffix delivery to SLAAC clients
There has been a great proposal in another recent thread here whereby “advertise DNS” is not just a checkbox - it should be at the very least accompanied by another checkbox “advertise self as DNS server” and ideally accompanied by a list-box where you can specify one or more IPv6 resolver hosts / domain suffixes to advertise.

Manually-configurable link-local address on an interface
Manipulating the MAC address of an interface to kinda-sorta assign the fe80:: address is NOT good enough, especially if you want your router to be fe80::1 on all interfaces…

NAT66 prefix translation
We’re not all lucky enough to have forward-thinking ISPs willing to statically assign our address blocks to us. Some of us have a different routing prefix every other day, and it sure sucks if your print driver has a static IPv6 address for a network-attached printer, and that address becomes invalid every other Tuesday. Prefix translation would be immensely useful for users in this boat, as well as those who wish to multi-home their connection. As things stand today with Mikrotik, multihoming is impossible on IPv6 unless you use BGP - and I dare say that I couldn’t qualify for my own personal /48 to take with me the rest of my life, and I 100% certainly will never get any ISP to offer me BGP routing on a broadband service. They don’t even want end users running websites out of their houses. And it’s obviosuly insane to think we could unleash the public onto the global BGP table… No, some other mechanism must be available, and until MPTCP, SCTP, etc make significant penetration (routers would only need policy routing in this case), Prefix-translation NAT is the immediately-obvious choice. Furthermore, NAt66-PT is stateless, so it will not break as many things as stateful NAT does.

Ability to specify which interfaces get which subnets assigned to them from a pool of IPv6 space
I have not found a way to do this - e.g. if I were to receive a /56 from dhcpv6-pd, it would be nice to say: “MyPool:ff::1/64 → GuestBridge”
If this is doable, I’d love to know how.

Fixed major routing protocol glitches in IPv6.
IPArchitects could better speak to these glitches than I can because it’s been a while since I’ve read threads reporting bugs in these, but I recall seeing some definite show-stoppers from my ever deploying a CCR in a core IPv6 routing capacity until they’re fixed. (OSPFv3 adjacencies not forming with other vendors’ gear due to certain flags not being set in SAs on their loopback interfaces, recursive next-hop lookup failure crippling iBGPv6, etc). I understand that these are most likely in the “fixed in v7” category, but for those who cannot deploy IPv6 until those glitches are fixed, or at least cannot use Mikrotik at the core of their IPv6 topology until fixed - well, that’s a problem that might be well addressed sooner rather than later for both customers and Mikrotik themselves alike.

With the exception of this last one, I feel that these features should not be hard to implement or improve in RouterOS 6.x and I feel that these few enhancents would go a long way to improving the experience those of us who’re adopting IPv6 have with RouterOS, and make the platform more useful going forward.

Oh, and finally…

Enable the protocol by default
This one fact alone (IMO) shows Mikrotik’s lack of priority handling for IPv6. Google has almost reached 20% utilization via IPv6 (the peak was 19.76% on June 27 as of this writing).

2

One status update: Microsoft finally did it and started supporting DNS from RA. But before anyone starts to celebrate, it’s only in latest Windows 10 update, and I don’t think there will be any backports. So give it another 5-10 years and you can start to rely on that. But better late than never.

3

Great thread!

I agree with everything and I want to also add the need for IPv6 Policy Routing (using routing marks and routing tables)

mrz mentioned back in 2012 that this would require a rewrite of the routing so I guess we’d have to wait until v7 for this.

4

I will add:
1.Support Radius “Delegated-IPv6-Prefix” attribute for PPPoE
2.IPv6 accounting

5

The last line is very important, if Mikrotik users are not actively using IPv6 - then there is no great push/need from Mikrotik regarding the points above. It is almost like IPv6 is in beta - try it out - but don’t expect it to work well.

6

Bummer… and I really do not understand why that would be. Maybe it is the integration with the automatic routing protocols?
I would be happy to live without that and see an implementation that allows route marks and different route tables but does not include the capability for BGP and others to update a separate table for each instance.
Just being able to select a different static default route (by lookup in a table with different route mark) depending on source address would already be great.
And as this appear to be possible in distributions/kernels of the same age as RouterOS 6 (using “ip -6 rule”) I would think this can be added without rework of the routing.

7

Excellent thread.

I would like to add:

IPv6 route rules and VRF
The ability to do /ipv6 route rule routing-mark=“foo” … (and corresponding /ipv6 route routing-mark=“foo” …) would be fantastic. Even older Linux kernels support this already (3.2.0 test box seems to have it), so we just need a way to do it on RouterOS?

Edit: just saw the comment above :frowning:

Stateful NAT
I know that we all hate having state in our network. And we all hate running out of addresses. And IPv6 is going to solve that. But NAT in IPv6 would be useful for e.g. transparent HTTP/HTTPS proxies; or DNS filtering (maybe you are a broadband provider for schools); etc. It’s in the Linux kernel from 3.9.0.

8

[quote=“maznu”]Excellent thread.

I would like to add:

IPv6 route rules and VRF
The ability to do /ipv6 route rule routing-mark=“foo” … (and corresponding /ipv6 route routing-mark=“foo” …) would be fantastic. Even older Linux kernels support this already (3.2.0 test box seems to have it), so we just need a way to do it on RouterOS?

Edit: just saw the comment above :frowning:

+1

9

Yeah, I think policy routing is pretty important, but I left it out of the triage list because:
a) I was pretty certain that this is a “fixed in 7” type of thing due to the nature of the routing engine overhaul being done
b) This is a somewhat more advanced functionality that is of reduced usefulness without NAT or dynamic routing to make it work in the scenarios people use it for in IPv4

I mentioned ‘wonky routing protocols in IPv6’ even though I knew it was not an easy fix, is almost guaranteed to be addressed only in ROSv7, and certainly is regarding an advanced type of feature. This is because it directly affects the customer base who comes from the other end of the spectrum. Routing protocols are absolutely essential building blocks on core/distribution routing. If that doesn’t work right in IPv6, or has “caveats” which can be avoided by constraining your design to never do that_thing_that_triggers_the_glitch, then it’s going to either hurt Mikrotik in lost sales, or else cause network operators to delay their IPv6 roll-out.

I see big things in the future for IPv6 policy routing if multipath protocols like MPTCP and SCTP achieve full acceptance and get supported on most everything. Multi-homing your network would be as simple as the client devices all obtaining one address from each prefix block, and then bonding the ISPs’ bandwidth themselves with zero interaction on the part of the router, except that it needs a policy-routing rule to force each prefix out via the correct ISP. The endpoints themselves can determine which paths work and which don’t.

10

Good thread!

I’d like to see a DHCPv6 Setup feature like the one available for IPv4. Here’s why. As someone that just started learning IPv6 it’s been a long and difficult journey. It was very frustrating at times considering I was starting from scratch with this new IP protocol. This forum got me through it. Not MT, but other users. MT is going to have many people like me starting from square one in the near future. When I was first learning IPv4 and MT years ago the auto setup feature was very helpful. It gets you started by showing you how it should be, then you can look at the config to see what’s going on. Over the next few years more and more people are going to be heading down this road and any help is a big plus. I’d also love to see more English speaking youtube videos for various configurations. These are the most helpful but also very hard to find. If MT wants to convert more and more people into using their products they should take a proactive step here and not wait for users to devote their own precious time to make these tutorials.

11

Yeah - and I think the Mikrotik guys fall into the camp that advocates that NAT should not ever be implemented in IPv6 because it’s no longer needed and that we should adjust our mindset into the realm of complete abundance of address space eliminating the need for it.

Note that all of your examples are all forms of dstnat.
I agree that these are useful functions that require stateful NAT - well, except DNS filtering. You can implement that in the service itself and block DNS queries to un-approved servers and achieve the same results.

Personally, I see both sides of the coin where stateful srcnat66 is concerned. On the one hand, I’ve read several threads here where the ISP was expecting clients to just get a single host address on a wan-side /64 using SLAAC and have done. That’s all fine and dandy for end devices, but is 100% broken for routers (some would actually consider this a FEATURE). NAT66 is a required tool if you want to use such a connection with a router.

If router vendors all categorically said “no srcnat66 - ever” then this would lead to users complaining to their ISPs, resulting in their being forced to change with the times and grant routable blocks of space to each customer, as they’re SUPPOSED to do. If the majority of routers DOES support it, on the other hand, then the ISPs can just say “buy a better router” and the current state of affairs will be brought into the IPv6 world.

I’m very much against this second scenario. I believe that IPv6 gives us an opportunity to improve things, not just maintain the status quo with more address space.

If I were Mikrotik, I would very begrudgingly implement srcnat66 because I know the “other guys” are all going to implement it, and it would improve my own customers’ capabilities and make them happy that they can just jump onto any “end” network and extend it with NAT as we do in IPv4 today. But I feel like renewing the lease on NAT opens a door that can never be closed again.

Other NAT tech that I would gladly implement in ROS:
NAT64 stateless and stateful both. (this is needed now, and will go away in the future)
NAT66-PT - stateless prefix translation would break almost nothing, and grant all kinds of useful benefits like multi-homing, dynamic-prefix-proof internal addressing, ease of address migration when switching ISPs, etc.

12

This is what Unique Local Addresses (ULA), fc00::/7, are intended for.

It’s perfectly feasible to use both a (static) ULA addressing scheme and distribute the daily changing global prefix through DHCPv6-PD. It has some drawbacks but it can be done today, with MT’s.

13

Why would ISP’s be changing prefix so often? With the sheer number I plan on setting my reservations ridiculously high, like 6 months to a year. Could make tracking old information a bit easier.

14

There appear to be two reasons:

  1. because they want to make it more difficult for users of home accounts to run services on their line. they want those users to have a “business” account which is the same as the home account but without the changing address, and at a higher price. of course “dynamic DNS services” were devised as a workaround for that.
  2. because they want to offer some “non-trackability” to their home users. when the address changes every day, you don’t leave a consistent track all over the world with your fixed address.

There is usually no clear explanation from the ISP because both of these do not really work, and it has become more a matter of existing policy from IPv4 that is just carried over into IPv6.
For example, here in the Netherlands a fixed IP has been the norm on DSL since its introduction, while on Cable a “dynamic” address is customary but it changes only when you swap the modem/router or sometimes when you leave it disconnected for some time. (DHCP method). However in neighboring Germany, it is customary on all home connections to change IPv4 address every night, and of course when that is the established policy and everyone is used to it, it is tempting to just copy it to IPv6 even if it serves no purpose anymore and is just annoying.

15

We need ‘set priority’ rule for IPv6 mangle, otherwise we cannot do QoS except over VPLS tunnels.

16

Do you mean on WlanX interfaces? Over ethernet, you can still use queue trees / simple queues + connection/packet marking to implement qos there.
There’s even an action to set DSCP on IPv6 packets… so you could have a bridge rule that sets dot1p priority based on DSCP and achieve layer2 QoS on ethernet.
(Full disclosure - I haven’t actually tried this in the lab, so there may be some kind of hidden gotcha that I’m not thinking of, but this is all possible)

I agree that this seems to be the most in line with “natless world” IPv6 vision, and was what I also wanted to implement back when I was working at an enterprise shop (moved back to ISP shop for the extra challenges) - but in my experimentation, I found that it was difficult to convince the OS (Linux and Windows both) whether it should use the ULA or the Globally-unique address whenever connecting to a given host. This is because both are seen by the OS as “global” scope. In practice, my test boxes tended to try using the ULA when going to Google, etc.
Another wrinkle in this approach for my enterprise gig was that we would’ve basically needed a unique ULA for each campus in our organization, and the idea of “oh I want to talk to this other host with a ULA” gets stranger when the source/dest aren’t in the same /48. Is “dst fdxx:xxxx:xxxx::/48 reachable from my fdxxxxx/48?” Maybe, maybe not. How does my host know that this dst ULA is on my own network and not some other site that goofed and leaked their ULAs into global DNS?

Furthermore, I knew my boss well enough to know that hell would freeze over before he would allow SLAAC on our network. (heh - and of course he’d first need to learn what SLAAC was, but once he did, he would immediately denounce it as “not on my watch” type of tech.)

17

I implemented ULA’s in my home/office/test network (all MikroTik equipment), so I have limited experience with it. As long as you block (reject) fc00::/7 addresses from leaving the network on your border router, you won’t notice any delay. Between sites you probably have a VPN anyway, so routing different ULA-prefixes between them shouldn’t be a problem. Within your site you route ULA’s the same way like global addresses. (See also RFC 4193: Unique Local IPv6 Unicast Addresses.)

I did however have trouble configuring more than one fixed IPv6 address on my printer (a pretty decent Kyocera multifunctional) and couldn’t get it working on a FreeNAS server either.

Furthermore, with RouterOS you can have only one DHCPv6-server per interface, advertising from only one pool. But since you can’t set fixed subnet id’s anyway, that doesn’t matter really. (And would a client accept more than one address from one or more DHCPv6-servers simultaneously?)

I suppose using ULA’s could be an advantage when securing servers (only allow logins from a specific “local” prefix) but actually I don’t think it’s worth the hassle. At this point I only see added value in small office environments, when you get a new IPv6-prefix every 24 hours (or every reboot of the (cable)modem).

18

Not all possible. I don’t want to have to set up queue trees for radio links (AirFiber and NV2) where the modulation can change and overall throughput fluctuates, and so then you are doing QoS to a moving target. It is better to use the strict priority queueing that the radio offers in each case, b/c the radio should know at any given moment how much bandwidth it has to work with. With AirFiber, it is done with VLAN priority (CoS), which the ‘set priority’ action sets, and in NV2’s case it is similar (‘set priority’ for the traffic). Either way you need set priority, unless you use a bridge filter to do it but then you need extra bridges you wouldn’t need otherwise etc.

Also, there is no bridge filter match rule for DSCP…

19

+9999999999999999999

20

100% agree that queueing based on a moving target is bad, and I guess I just forgot on that last point. Whoops.

In the end, I’m all for pretty much any enhancement / feature that people need, but I think the point of this thread is to name the enhancements that would give the most “bang for the buck” on Mikrotik’s investment of time and effort. Perhaps it makes sense to divide these into two perspectives: CPE space and Core/Transport space. I’d say that QoS is pretty essential for core/transport space as WISPs have tons of this gear out in the wild and inability to do L2 QOS for IPv6 is definitely bad.