Hi Normis,Not correct. This feature exists already.
Release 6.45.1 2019-07-01
What's new in 6.45.1 (2019-Jun-27 10:23):
*) dhcpv6-server - added RADIUS accounting support with queue based statistics;
Yes because most of the ISP and WISP is using PPPOE for connecting to Clients, Using DHCPv6 or DHCP Server in ISP Grade network in very difficult.The feature only exists when using DHCPv6 server outside of PPP/PPPoE situations. It is not yet implemented for PPPoE. We really want to see it implemented for PPPoE situations as well.
I had ticket 2018070222004763 for this, but it was in the older OTRS system they used before they moved to JIRA.Do you have a ticket number?
Mikrotik Support Reference No.: SUP-20538Do you have a ticket number?
In Brazil we also have the legislation to keep the Logs of Delegated IPV6 Prefix & Remote IPv6 Prefix, and it is really frustrating the development delay of Mikrotik in relation to IPv6.Hmmm, I Think people are mostly not interested in IPv6 Implementation or am i the only one who is so furious in implementing IPv6....
Well i cant understand!!!
Same Doubt i also have. Mikrotik is used by many ISP around the globe and we are requesting this feature from long time.Is it really that difficult to add the RADIUS Delegated-IPv6-Prefix Attribute to v6? Or should we wait for v7?Hmmm, I Think people are mostly not interested in IPv6 Implementation or am i the only one who is so furious in implementing IPv6....
Well i cant understand!!!
I Know they have not given any ETA, but atleast it gives all of us a hope.Hello
Thank you for contacting us. Yes, it is in our plans to add such functionality when PPP service is authenticated by the RADIUS server. However, unfortunately, I can not provide any ETA for such functionality.
Best regards
They gave me this same response a year ago.I Know they have not given any ETA, but atleast it gives all of us a hope.
Then I think some Mikrotik Support Member will surely answer to this post!They gave me this same response a year ago.I Know they have not given any ETA, but atleast it gives all of us a hope.
@NormisNot correct. This feature exists already.
Release 6.45.1 2019-07-01
What's new in 6.45.1 (2019-Jun-27 10:23):
*) dhcpv6-server - added RADIUS accounting support with queue based statistics;
What's new in 6.48beta48 (2020-Oct-14 10:26):
...
Other changes since v6.47.4:
*) ppp - added support for "Framed-IPv6-Route" RADIUS attribute;
Do this works for PPPoE ?
You Mean Mikrotik is never gona Develop IPv6?Use Cisco for IPv6 accounting and Delegated prefix.
Yes, limits have always been working, that is not the problem. The issue is tracking the prefix that the customer receives, which is often a legal requirement so that if you get a court order that has an IPv6 address on it and a date and time, you can identify who had that prefix at the time. MikroTik has now partially implemented this but has not finished.I think limiting the clients with the PPPOE usernames limits the clients to the Cap specified on the dynamic Queues by radius both for v4 & v6.
Oooh okay.Yes, limits have always been working, that is not the problem. The issue is tracking the prefix that the customer receives, which is often a legal requirement so that if you get a court order that has an IPv6 address on it and a date and time, you can identify who had that prefix at the time. MikroTik has now partially implemented this but has not finished.I think limiting the clients with the PPPOE usernames limits the clients to the Cap specified on the dynamic Queues by radius both for v4 & v6.
In our case we have a script that goes through every dynamic v6 binding every 5 minutes and does a "make static" so it never changes. It is much easier than having to manually assign a prefix to each new customer.Is it possible to assign persistently instead of dynamic when using PPPoE?
Can you share the script, please? Does it also work for RouterOS v7?In our case we have a script that goes through every dynamic v6 binding every 5 minutes and does a "make static" so it never changes. It is much easier than having to manually assign a prefix to each new customer.Is it possible to assign persistently instead of dynamic when using PPPoE?
Sure. I'm not sure if it works on RouterOS v7 but I don't see why not. Here it is - it is pretty simple:Can you share the script, please? Does it also work for RouterOS v7?
/ipv6 dhcp-server binding;
:foreach i in=[find server~"pppoe"] do={
make-static $i;
set $i comment=[get $i server];
set $i server=all;
}
This is a good solution - however if you have many routers acting as a pppoe server - if the client moves you will loose the lease again. Radius solution is required from mikrotik.Sure. I'm not sure if it works on RouterOS v7 but I don't see why not. Here it is - it is pretty simple:Can you share the script, please? Does it also work for RouterOS v7?
The server for the static binding has to be set to "all" as the server is dynamically created when the user connects and destroyed when the user disconnects, so if that is not done, the binding will be using a server that no longer exists and doesn't work. The comment is set to the server so that you know what user it is for - the server name is something like <pppoe-customerusername> and so this gets copied to the comment so you have a permanent record of which customer the lease is for.Code: Select all/ipv6 dhcp-server binding; :foreach i in=[find server~"pppoe"] do={ make-static $i; set $i comment=[get $i server]; set $i server=all; }
Hey, did you find any solution to that? Is this feature still not implemented?There should be somthing which we can do about it. Is there any chance of logging the same using the Traffic Flow IPFIX???
_Hi, I work in a software company that develops a web-based program for managing ISPs.
The PD information in PPPoE accounting is very important to our clients, and they are always asking when will Mikrotik resolve this issue.
Please consider putting some effort in bringing this feature in future updates.
There are laws here too that makes this information mandatory in the PPPoE accouting.
Almost, give the community some information, e.g. if this feature is very difficult to implement and what are the steps that are required to make it work.