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;

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.

Do you have a ticket number?

Do you have a ticket number?

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

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

Is it really that difficult to add the RADIUS Delegated-IPv6-Prefix Attribute to v6? Or should we wait for v7?

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

I Know they have not given any ETA, but atleast it gives all of us a hope.

I Know they have not given any ETA, but atleast it gives all of us a hope.

They gave me this same response a year ago.

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;

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 ?

Use Cisco for IPv6 accounting and Delegated prefix.

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.

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.

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.

• https://www.ripe.net/publications/docs/ ... ed-harmful

• https://www.6connect.com/blog/is-your-i ... pe-router/

Is it possible to assign persistently instead of dynamic when using PPPoE?

Is it possible to assign persistently instead of dynamic when using PPPoE?

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.

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;
}

Can you share the script, please? Does it also work for RouterOS v7?

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:

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;
}

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.

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.

Can you share the script, please? Does it also work for RouterOS v7?

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:

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;
}

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.

Hello DarkNate,

Can you please share us how did you implement DHCP instead of PPPoE.

My Question is:

1. how did you manage to authenticate the users only with DHCP?
2. If someone connects another LAN of their router then how to prevent rogue DHCP Server?

HI DarkNate,

Thank you for sharing this. got some idea about how to implement the same but now some more doubts

can we use BNG<>L2 SWITCH<>OLT ?

is MPLS VPLS must?

Hello DarkNate,

Can you please share us how did you implement DHCP instead of PPPoE.

My Question is:

1. how did you manage to authenticate the users only with DHCP?
2. If someone connects another LAN of their router then how to prevent rogue DHCP Server?

BNG<>P<>PE<>L2 switch<>OLT or wireless AP

OLT/AP VLANs are transported to BNG using MPLS/VPLS over native IPv6, we did not use legacy IPv4 in the MPLS core.

On L2 switch side, we enabled DHCP Snooping and configured uplink port as trusted port. This solves rogue DHCP server issue if you configured DHCP Snooping correctly for a given network topology.
On OLT or AP side, we enabled PON isolation or client isolation.
On BNG side, the layer 3 sub-interface VLAN of each AP or OLT is on top of the VPLS circuit and finally we used local-proxy-arp on the sub-iface VLAN for additional security.
On DHCP server on the BNG, we enabled add-arp-to-leases. Static IP is impossible for a customer to spoof.
Authentication is done via MAC address of CPE. Customers may update their MAC address via their user login dashboard (talk to your AAA vendor to offer this feature).

QinQ is not required as we're using local-proxy-arp + MPLS Transport + PON/Client isolation.