MikroTik now has support for Delegated-IPv6-Prefix - when will Sonar?

This question is mainly for Simon. As of RouterOS 6.43, MikroTik now officially supports the Delegated-IPv6-Prefix attribute via RADIUS, which allows you to define the prefix that a customer should receive through DHCPv6 prefix delegation and therefore get a static prefix. This is a very important new feature that should make it much easier for WISPs to roll out IPv6 to their customers.

Any chance of getting support for allocating this in Sonar soon? (Similar to the IPv4 Framed-Prefix support)

Ideally, one should be able to add a prefix and choose whether it is associated as a Delegated-IPv6-Prefix or a Framed-IPv6-Prefix, in case both need to be provided to a customer.

2 Likes

Can you link me to the docs?

1 Like

The RFC that explains the attribute and how it functions: https://tools.ietf.org/html/rfc4818

The page that shows that support was added https://wiki.mikrotik.com/wiki/Manual:RADIUS_Client#Access-Accept

And here is a document explaining how to use the feature with DHCPv6 in general (non-PPPoE): https://wiki.mikrotik.com/wiki/Manual:IPv6/DHCP_Server#RADIUS_Support

Unfortunately, it looks like MikroTik hasn’t yet created a detailed how-to on their wiki yet for this attribute with PPPoE.

The feature may be valuable for Sonar users wishing to deploy IPv6 even without PPPoE, in just a regular DHCP environment, since the RADIUS-controlled dual stack queue feature would allow for a single dynamic simple queue to rate limit both IPv4 and IPv6 for a customer in one queue. The current way you do the queueing with PCQ and address lists, each customer will get their own separate rate limit for IPv4 and IPv6, which is obviously not ideal when they are just buying one package.

We haven’t tested 6.43.x yet since it is brand new, and our firmware policies will prevent us from upgrading for a few months at least, but once we do, we would like to begin making use of this attribute almost immediately, so it would be great if Sonar had support.

I believe MikroTik is also currently working on IPv6 RADIUS accounting, but that function isn’t there yet to my knowledge.

1 Like

I support all IPv6 improvements.

4 Likes

Ok, I’ll take a look.

1 Like

@Michael_Ducharme1 Without resorting to manual assignment, can you think of a smart way to differentiate between the Framed and Delegated prefix? It’s fairly easy with IPv4 in Sonar - the pool IP is the prefix and any subnets are set as a Framed-Route, but I can’t think of a clean way to do this with IPv6 assignments.

Secondly, would your preference be to assign these statically like this or just let the MikroTik assign them dynamically and have the batcher pick up those assignments?

@simon Not really, I think you would need manual assignment, except a framed IPv6 prefix should always be a /64 (and never any other subnet size) whereas a delegated prefix will tend to be a larger allocation than a /64 (like a /56 or /48), but it’s still possible for a /64 to be a delegated prefix. You could perhaps have a UI element to choose between Framed-IPv6-Prefix and Delegated-IPv6-Prefix only when the subnet selected is a /64, otherwise you know it is a Delegated-IPv6-Prefix.

As for your second question, it is hard to say really, because some customers may specifically request static prefixes and it would be best to be able to allocate those prefixes, but adding static prefixes to every customer, even those who don’t need them, could be a lot of work depending on the number of customers. So yes it would be good if there could be an automated update process like with DHCPv4 leases.

Also please note that FreeRADIUS 3.0.x now has four new fields in MySQL radacct table to store IPv6 radius accounting (I had submitted that patch myself). Once MikroTik adds IPv6 radius accounting support, those fields should begin getting auto populated with the customer’s current framed-ipv6-prefix and delegated-ipv6-prefix if they are dynamically assigned. Ultimately, once all required support is in place by all vendors, this would presumably show up in Sonar as a “soft assigned” prefix.

We were looking into adding the ipv6 attribute into radius groups.

Right right we use radius groups for each of our data service and we have a "Mikrotik-Rate-Limit += (up/down) ".
We added a 2nd attribute under one of the groups “Delegated-IPv6-Prefix += (ipv6pool)” and it seems to cause radius authentication failures.

Any idea why?

I don’t believe this attribute works with PPPoE yet.

it does. need to put Mikrotik- in front “Mikrotik-Delegated-IPv6-Prefix”

No, it doesn’t. You’re thinking of “Mikrotik-Delegated-IPv6-Pool”, which was always supported. The problem with Mikrotik-Delegated-IPv6-Pool is that if you want to assign a specific prefix for each customer, you have to create a pool for each customer, each of which only has one subnet in it. If there are thousands of customers this solution quickly becomes untenable. Delegated-IPv6-Prefix allows directly specifying what prefix the customer should receive and avoids having to create a pool per customer, but doesn’t yet work with PPPoE to my knowledge. I’m hoping MikroTik addresses that (and the lack of IPv6 RADIUS accounting) very soon.

You would likely need to make different radius groups and assign them to account groups and then you can divide them better. but i understand what your saying.

Me too, it would make coming up with a good solution here a lot easier!

FYI - latest RouterOS 6.48 beta adds Delegated-IPv6-Prefix support for PPPoE. I haven’t tested it yet so I don’t know whether it supports the RADIUS accounting yet, but that is a big step forward.

Update - I tested it. RADIUS accounting is also working for Delegated-IPv6-Prefix over PPPoE.

I set up a test client to get a dynamic IPv6 prefix over PPP, and the RADIUS server was notified of the prefix via an accounting packet with a Delegated-IPv6-Prefix field.

1 Like

image