IPv6 and Mikrotik, how best to deploy right now?


I need to re-do my Mikrotik enabled distribution of customer IPv6, like today.

Does anyone (Simon) have a suggestion for the best current method to do that, knowing v2 is coming soon and we want to dual stack integration with Sonar?


Other than using PPPoE and DHCPv6 over the PPP tunnel so you can use the RADIUS username to identify the customer, I don’t know of a great way today. Someone mentioned that MikroTik has improved their AAA accounting for IPv6 recently, but I haven’t checked yet. Going to look into it more once 2.0 is public. There isn’t really anything new yet in 2.0 for IPv6, but I’ll devote some time to building out some concrete solutions soon.


I have an IPv6 binding script that manipulates address lists by looking for a matching MAC address in IPv4 DHCP, which is a hack. Really hoping to see proper support soon.


What we do (PPPoE+IPv6) is use RADIUS groups to control rate limiting (instead of address lists), and then we use an interface list for delinquent/inactive customers. Sonar adds the customer to the interface list when they are delinquent or inactive, and the interface list has IPv6 firewall rules associated to block the customer from getting online. That way it doesn’t matter that Sonar doesn’t know the customers IPv6 block. Of course, that also means you need to send CoA on delinquency/active status change, but I don’t think that is a big deal for most people. We’ve been running this for about a year now and it is a nice simple reliable workaround until the support improves.


Thanks for your tips guys.
Looks like we are going down the Freeradius server (v3) -> PPPoE IPv4/IPv6 with rate limiting using simple queues on the tunnel to combine the v4/v6 bandwidth to the customer.

Question: currently sonar doesn’t seem to support getting the v6 address’ back into sonar (as far as I can tell). Anyone have any experience with this? sent in a support ticket but haven’t heard back yet…


I think the guys are investigating the issue as IPv6 is not something we deal with regularly. As far as I know dynamic V6 addresses do not come back to Sonar and IPv6 option is only there for record keeping but I could be wrong on this.


so what you are saying is that sonar doesn’t really support IPv6?


Sonar supports IPv6 just fine… you can add IPv6 addresses onto any item. There is no way to do this through DHCP currently as there’s no standard mechanism to identify the devices.

I’m working on a way to make this easier with PPPoE and DHCPv6 over PPP, but it’s not available right now.


My thoughts were a script based in the ppp profile of the PPPoE “OnUP:” that grabbed the lease based on the mac address and tossed it as a JSON post to a ‘Batcher/Poller or other relay’ that could push that info back to sonar for logging purposes.

Would something like that work?


Technically yes, I’m not sure of the specifics. The reason I’m looking at PPPoE and DHCPv6 is you can link the RADIUS profile to the assigned IP in that case.

Honestly I just haven’t had time to dig into this with the push to v2, but it’s on the horizon to at least publish some kind of standardized easy way. Today you can submit anything to the API and get it on the account, you just have to figure out the assignment somehow. It’s not a simple problem.


If I write this to an existing v1 endpoint, will that endpoint still exist when we eventually upgrade to v2?


Depends which one it is and when you upgrade. The plan eventually is to wrap every single v1 API endpoint so that they point to the appropriate GraphQL call. But that won’t be there day 1. That being said, it would be a pretty trivial change to update it to GraphQL.


What is the reason you need it in Sonar? We decided to live without this for now until IPv6 RADIUS accounting is working properly.


We want preseem to be able to do the speedlimiting properly with ipv6 they won’t be able to accomplish that until they support ipv6, they can’t do that until we can get the addresses into sonar.

Just a multifactor problem. Hitting it on all fronts.


Ahh, gotcha. We don’t use Preseem so we are fine limiting with just the Simple Queues on the MikroTik.

Still, our IPv6 DHCP make-static script may be of use to you (we run it scheduled every 5 minutes):

/ipv6 dhcp-server binding;
:foreach i in=[find server~"pppoe"] do={
  make-static $i;
  set $i comment=[get $i server];
  set $i server=all;


My DHCPv6 binding script that cribs from IPv4 address lists and bindings is published now, would love some feedback. It’s still not a proper solution though. For that we need Sonar to step up and take IPv6 seriously.


If Sonar would just allow us to assign the address to a radius account, then write the address to the relevant radius account as a framed-ip-address (as it does already do with IPv4 addresses) then you would have at least one more working model for deploying IPv6.

We were able to successfully dual stack our subscribers but we had to write our own middleware to do it. Our middleware listens to a webhook from Sonar (triggered when an address is added to an account), then makes some API calls back to Sonar to validate it, inserts those IPv6 addresses into our radius database, and then provides feedback to the Sonar operator by adding a comment onto the address assignment.
Of course, writing all the code to do this robustly and consistently, day in day out, while handling all the edge cases (and minor inconsistencies in Sonar’s webhooks/API) was non-trivial.

All of the above would be unnecessary if Sonar would just allow IPv6 addresses to be written to the radius tables in the same way as IPv4 - then all customers using radius and PPPoE could roll out IPv6.

In our case rolling out IPv6 was absolutely mission critical so we bit the bullet and built a custom solution, but we are quite fortunate to be able to employ several full time developers, and I imagine many smaller shops would find this too great a hurdle.


This is exactly the functionality we need to complete our roll out in IPv6. Preseem can’t limit our IPv6 users if it cant get the data from Sonar. Chicken meet egg.

Lets join the 30%!


Took a quick look at that script, but not in detail.

Does it just scan for same MAC on IPv4 and IPv6 and then, what?


I think it’s documented reasonably well in the comments at the top of the code. Please let me know if you have any questions after reading those.