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).

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.

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.

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

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.

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.

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.

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 :-(

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.

[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

+1

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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

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)

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.

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.)

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.

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.)

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).

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

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)

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...

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

+9999999999999999999

the radio should know at any given moment how much bandwidth it has to work with.
...
Also, there is no bridge filter match rule for DSCP...

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.

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.

This was essentially my point - that the router has little to do with a multi-prefixed deployment. It's just going to forward both prefixes per the rules you specify, no questions asked. It's the end-nodes that must all be savvy with juggling the multiple prefixes and knowing when to use which one as the source address / dest address.

For instance, I found that my installation of Ubuntu 16.04 wanted to use its ULA prefix when attempting to open sockets to google, even though it had a unique global prefix as well. Perhaps if I'd configured my router to send ICMP unreachable messages whenever the ULA prefix attempted to go out, the Ubuntu box would've tried the unique global prefix immediately....

Meanwhile, I was sad to notice that neither my bank's secure website nor my Chase card's secure website have any AAAA records in DNS....

About the prefix usage and whether NAT66 has a place. I'm not totally sure what to think to be honest. I think we're in a bit of a chicken and egg situation. I feel the folks that wrote up IPv6 wanted auto-configuration to be the focus. It is my feeling that they wanted that to extend past just assigning addresses. It's likely why we see things like mDNS / Bonjour. While they definitely make service discovery possible in IPv4 they also can be used in IPv6. Looking at the printer, say you have 2 Internet connections, even if it can only configure one at a time. The presumption is that during an outage the RA ICMPv6 messages should be stopped for that prefix. The printer should then hear the other RA and configure itself a new address with SLAAC. The entire time it will still have a link-local address and will still function on the local LAN just fine with a discovery protocol (mDNS - Bonjour, SSDP). Now the tricky part, are we ready both on the device front and the router / DNS front to support auto-registration of service records for the things of the Internet (printers) so that we can cross network boundaries and they still work?

These are things I'm actively labbing up. The question of what to do with 2 ISPs when you are not in a situation to register for an ASN and perform BGP with the upstreams is one that we'll be facing soon as IPv6 becomes more mainstream and services continue to be driven into the cloud. In IPv4 this was easy peasy, a little NAT and a tracking route and you were largely good to go for active / passive. I'm not sold that ULA with NAT66 is a good way to go but source-address selection related issues in multiple prefixes has to be well understood along with reliable service discovery. Are the days of statically assigning IP's to those network resources gone? We'll see.

Meanwhile, I was sad to notice that neither my bank's secure website nor my Chase card's secure website have any AAAA records in DNS....

^^ Sadly this is all too true. That said, they company I work for has shifted their policy from "No IPv6 needed" to "IPv6 for any edge services." We're a multi-national consulting company so hopefully that shift filters into actions for more sites and services run by our customers. I'm not saying it's the silver bullet but it never hurts. A lot of our larger customers are already using load-balancer products like F5's BigIP and in those cases it's stupid simple to present a AAAA and have the load-balancer translate the IPv6 traffic back to IPv4 servers. It gives customers an excuse to get us in and configure their routing and security products to get IPv6 over to at least the load-balancers. That said I've also been knighted the IPv6 evangelist so I'm probably the one screaming the loudest

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.

This is possible on Linux with ip token

DESCRIPTION
IPv6 tokenized interface identifer support is used for assigning well-known host-part addresses to nodes
whilst still obtaining a global network prefix from Router advertisements. The primary target for tokenized
identifiers are server platforms where addresses are usually manually configured, rather than using DHCPv6 or
SLAAC. By using tokenized identifiers, hosts can still determine their network prefix by use of SLAAC, but
more readily be automatically renumbered should their network prefix change [1]. Tokenized IPv6 Identifiers
are described in the draft [1]: <draft-chown-6man-tokenised-ipv6-identifiers-02>.

https://www.linux.org/docs/man8/ip-token.html

So maybe MT could fairly easy implement that in RouterOS as well. I agree this would be useful.

This is possible on Linux with ip token
https://www.linux.org/docs/man8/ip-token.html
So maybe MT could fairly easy implement that in RouterOS as well. I agree this would be useful.

That's how Cisco lets you do it as well. When I saw "from pool" in RouterOS, I thought it would work the same way.

It didn't.

So, I saw forum.mikrotik.com has a AAAA now. I'm pretty sure that's new. I thought I checked it within at least two months ago and it was IPv4 only. Feel free to correct me. Either kudos to your ops guys MikroTik.

Not so new I think. I'm using a browser plugin called IPvFox (I think) and it immediately shows IPv6 or IPv4 for whatever site you're on. This one has been IPv6 for at least a few months, but I'm thinking more like 6 or so.

So, I saw forum.mikrotik.com has a AAAA now. I'm pretty sure that's new.

Unfortunately the download server for updating and the registration for CHR (trial) licenses do not.
It is still not possible to run a router with only IPv6 connection to internet.
(a friend that I am trying to convince to use MikroTik is trying such a setup as a virtual router on a
VMware ESXi system where he is IPv4-routing only RFC1918 space and has no spare public IPv4 so
he gave it only an IPv6 on internet, without success)

forum.mirkotik.com has the IPv6 address for several years now.

regarding CHR - we will look into it.

About from-pool - what it is missing when comparing to the ip-token?
if you add IPv6 address like this

About from-pool - what it is missing when comparing to the ip-token?
if you add IPv6 address like this

Code: Select all

/ipv6 address add address=::1ee7:t00c:ee/64 from-pool=some-pool interface=lala

E.g. you have a /56 or /48 pool from the provider.
You can set "[64 bits]/64 from pool" but you cannot control WHICH /64 from the pool it will assign to WHICH interface.
It should be possible to select the subnet number (8 or 16 bits in the above cases) for each interface, so every time the
same address is assigned to the interface(s), even after adding an address to another interface and rebooting.
When the pool prefix from the provider is fixed, the entire address will be fixed. When it is variable, only the prefix will
vary but the subnet within the prefix will remain the same.

E.g. you have a /56 or /48 pool from the provider.
You can set "[64 bits]/64 from pool" but you cannot control WHICH /64 from the pool it will assign to WHICH interface.
It should be possible to select the subnet number (8 or 16 bits in the above cases) for each interface, so every time the
same address is assigned to the interface(s), even after adding an address to another interface and rebooting.
When the pool prefix from the provider is fixed, the entire address will be fixed. When it is variable, only the prefix will
vary but the subnet within the prefix will remain the same.

Thanks for explaining it succinctly. I've always found that my explanations for this ended up being 2 paragraphs at minimum -

About from-pool - what it is missing when comparing to the ip-token?
if you add IPv6 address like this

Code: Select all

/ipv6 address add address=::1ee7:t00c:ee/64 from-pool=some-pool interface=lala

What we're asking for in this feature is this:
If the pool MyISP is 2001:db8:cafe:1100::/56, I should be able to specify address:
::c0:0:0:0:1/64 from-pool=MyISP and they will mask together to form 2001:db8:cafe:11c4::1/64
It doesn't have to be too strict since it's getting masked - if I were to specify address 1111:1111:1111:11c4::1/64 with from-pool=MyISP, it would yield the same result.

The current behavior ignores the X bits in the delegated prefix length (usually 64), not the X bits in the pool prefix length (eg 56).
So in my example, even though I specified bits 57-64 to be "c0", the pool would choose some available /64 from the pool and assign it to the interface.
I might get 2001:db8:cafe:1103::1/64 (if 03 was the first available /64 in the pool)

The one check that would be required would be to see if the specified prefix is already assigned from the pool. So if I were to specify ::c0:0:0:0:1/64 from my pool, and it was already assigned to some other interface or dhcpv6-pd client, etc - then this new address should fail, but other than that, it's pretty straightforward.

E.g. you have a /56 or /48 pool from the provider.
You can set "[64 bits]/64 from pool" but you cannot control WHICH /64 from the pool it will assign to WHICH interface.
It should be possible to select the subnet number (8 or 16 bits in the above cases) for each interface, so every time the
same address is assigned to the interface(s), even after adding an address to another interface and rebooting.
When the pool prefix from the provider is fixed, the entire address will be fixed. When it is variable, only the prefix will
vary but the subnet within the prefix will remain the same.

Let me state this differently than the others.
+ I get a /60 from my provider
+That gives me a pool of 16 /64's
+ Each /64 should be given an "index number"
+ That index number is used as the IPv6 address assignment on the interface
+ That way the appropriate /64 will always be assigned to the given interface

With the current "random" implementation, the /64 assignments will change with interface add/delete/change. This is a huge problem because the other /64's are on segments behind the MT router and used in DHCPv6 scope. One interface change on the MT can mess everything up.

MT is the only router platform I have personally worked with that does not implement this or similar addressing method. This issue has come up many times.

Let me state this differently than the others.
+ I get a /60 from my provider
+That gives me a pool of 16 /64's
+ Each /64 should be given an "index number"

That "index number" is what I referred to as the "subnet number".
It would be 0-15 in your case, or 00-0F when written in HEX (probably better as IPv6 addresses are normally written in HEX).

Pe1chl, proximus and ZeroByte - differences noted. now let us see what can be done about them.

Pe1chl, proximus and ZeroByte - differences noted. now let us see what can be done about them.

+1 & Janisk, this was one of the most pronounced and immediate differences I noticed moving from an OpenWRT router to my first MikroTik. If you have something capable of running OpenWRT (GNS3 maybe), fire it up and take a look at the LAN side interfaces (maybe create a couple). You'll be able to give it some values, they use nibbles and assume you're working in 4 bit chunks but I'd be fine with hex too for really fine grained control.

Distribution of prefixes onto downstream interfaces (including size, ID and class hints)

^^ Reference: https://wiki.openwrt.org/doc/uci/network6

Isn't this one of the specific reasons why people run OpenWRT in MetaROUTER? I haven't looked at OpenWRT's IPv6 capabilities.

Isn't this one of the specific reasons why people run OpenWRT in MetaROUTER? I haven't looked at OpenWRT's IPv6 capabilities.

I'd say that it's more common (judging on threads here) that people use it to enhance the services offered by a Mikrotik - Asterisk, etc... or else to run more full-featured services where the built-in is only quite basic, like DNS.

I was looking at using it for DNS64+NAT64. I got frustrated with WRT because the MetaRouter target doesn't appear to be maintained as well as others on the WRT side, and WRT is not maintained on the ROS side either, which would leave me in a "heavy tinkering may be required if either side changes anything during upgrades" position, so I've decided that Metarouter+WRT is a no-go for me in any kind of production environment.

Another probably-easy-to-implement feature that would be quite useful in IPv6 is:

Automatic Null route for IPv6 pool addresses

Well, for starters, Mikrotik would need to implement blackhole-type IPv6 routes, but for the rest of this post, consider type=unreachable to be the functional equivalent.....

I'd say that it's safe to assume that whenever you've been allocated a block of prefixes to use that this block is also routed to your device. Any packets rour router receives which are destined to unassigned prefixes from this block would therefore get forwarded to the default GW which would ping-pong it back to your router, and so forth until TTL expires. To prevent this, you need to sinkhole the block prefix at the router it is assigned to.

So it would be a nice feature to have a checkbox "add null route for prefix" so that your pool would be sunk at your router as a whole, except for any prefixes currently active from that pool. If they add support for blackhole routes, they could just make this a dropdown (ala arp=enabled/disabled/proxy/etc) with choices = "no route added / blackhole / unreachable"
For now, it's easy enough to just add that route manually, but if your pool is dynamic and you forget to change it, then your routing table is discarding the wrong block of addresses while ping-ponging the ones that are actually routed to you.

This would also come in handy for access routers on the ISP side of things if you want to create blocks of addresses to make customer assignments from. Adding a pool to a router would immediately add the unreachable static route to the RIB, which could be picked up by "redistribute static routes" - basically one-touch provisioning.

that certainly sounds killer!

Another probably-easy-to-implement feature that would be quite useful in IPv6 is:

Automatic Null route for IPv6 pool addresses

But it already does that! Doesn't it?
In my IPv6 table there is a "dynamic" null route for my own prefix, and I did not put it there.

DHCPv6 client does it:

Ah - okay. Before posting this, I fired up a CHR and manually configured an IPv6 address pool which didn't create the blackhole route.

It would be nice if manual pools did the same thing, but that's pretty much not a "triage" issue because any manually-defined pool is going to be static, thus you can just as easily create a manual static null route for the block.

Thanks for the clarification.

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...

+1.

we need set-priority for IPv6 firewall too

I wouldn't mind DynDNS update mechanism to invoke to HE DynDNS service (+ others) per stateless IPv6 client change.

I have 7 Mikrotik boxes CCR's and CRS's, there's learning curve but so far loving them.

Cheers,
Naran

IMHO ipv6 is a dead concept.

I will either see ipvx (x>6) or die before ipv4 will be shut down. So it is not worth the effort.

+1 to this thread.
Can't add custom local link IPV6 from my supplier. My ipv6 / 48 i useless now.

Mikrotik wake up.

I don't understand the reasoning behind not allowing to add link local addresses. Not everyone uses RA and certainly this would help us people knowing what we are doing.

Now is end of 2018 and still not possible to set link-local address - at least i cannot do it.

Here is Romania the big ISP RDS&RCS use link-local addresses to route assigned prefixes, concrete:
fe80::<prefix> on wan interface + default route fe80::1%wan.

If MikroTik doesnt start to support this now they loose a complete market... Their choice.

For this resaon i have plan now to replace all ROS based Routers next year and of course i cannot recommend MikroTik anymore.

Regards, Robert

2019 Now and happy new year

Any hope for ipv6 policy route?

Best wish for everyone in 2019

+1.