Mikrotik is being used by many ISP Worldwide… And we are requesting this issue form years and years now and still mikroitk has not yet given even a single response.
I think RouterOS is not Capable to execute this attribute thats why mikrotik team is not answering…
Hi guys,
I’m fine with this feature except “Expire Time” which is one minute and I don’t know how to prolong it… I tried RADIUS attributes, pppoe profile, but no effect…
How do you deal with it?
THX
Delegated-IPv6-Prefix RADIUS attribute support for PPPoE server still not working in 6.49.6?
I need static IPv4 addresses / IPv6 prefixes, not dynamic from a pool - freeradius users file has this for each customer:
username Cleartext-Password := "********"
Service-Type = Framed-User,
Framed-Protocol = PPP,
Delegated-IPv6-Prefix = 2001:db8:27b::/56,
Framed-IPv6-Prefix = 2001:db8:27b:100::/64,
Framed-IP-Address = 192.0.2.123
and it works with VyOS PPPoE server, but not with MT.
Or should it work, but I’m doing something wrong?
I’m not brave enough to try ROS v7 yet - or should I?
Even ROSv7 is not supporting… 
`
Passing Delegated-IPv6-Prefix attribute in RADIUS Access-Accept reply works perfectly for me in 6.49.x. I would be kind of surprised if it also did not work in 7.x (though I have not yet tested).
Also please note that this thread was originally about RouterOS not sending Delegated-IPv6-Prefix back in RADIUS Accounting messages. Different issue.
If you can make this work with Vyatta/VyOS but not RouterOS, that is surprising. As I mentioned, I have gotten this to work with RouterOS. But note that it needs to be sent by RADIUS server not as a string, but as the raw binary bits, with the prefix length encoded first, followed by the actual IPv6 prefix (expanded to a fixed length of 128 bits, with the masked-off part set to zeros), as the RFC spells out. If you do not have the appropriate dictionary file loaded into your RADIUS server config (e.g., in the case of FreeRADIUS, make sure to include “dictionary.rfc4818”), then it might not be sending the attribute in the right format, or might not be sending it at all. You should perform a packet capture between RADIUS server and MikroTik to verify. (If your RADIUS server is sending this attribute as a string, perhaps VyOS can accept that, while RouterOS more strictly adheres to the RFC?)
Also just in case it is not explicitly clear, sending Delegated-IPv6-Prefix attribute to RouterOS in Access-Accept reply will only work if your PPPoE client is also running a DHCPv6 client that is requesting a delegated prefix. If you are expecting your RouterOS PPPoE server to just add a route to the local table pointing that static prefix at that customer’s connection without DHCPv6, you should instead use Framed-IPv6-Route instead, which IS sent as a string.
"Hi guys,
I’m fine with this feature except “Expire Time” which is one minute and I don’t know how to prolong it… I tried RADIUS attributes, pppoe profile, but no effect…
How do you deal with it?
THX"
I’m having the same problem here, i get ipv6 and ipv6-pd but the valid_lft is 60 seconds.
Hi,
We are sending the Mikrotik-Delegated-IPv6-Pool (id 22, string) attribute in the Access-Accept and all works as expected. However same deal as with the Delegated-IPv6-Prefix, the allocated prefix from the pool is not sent in Accounting.
Any thoughts on this perhaps?
I can't reproduce this problem, and can have more than one customer with separate Delegated-IPv6-Prefix on the same router, and it works fine. But I'm also using 6.49.6, so maybe this was a bug back in 6.48.x, and it got fixed.
`
I see the same thing: lease time is only 60 seconds long. It would be nice to be able to adjust it, but in practice it doesn’t seem to be causing any problems. Client has to renew every 30 seconds, but oh well…
I’ll also point out that when you assign dynamic prefixes from a pool, those get assigned with 3 day long lease time, which is also not possible to adjust at all (at least that I can find…). Again, would be nice to be able to adjust this as well, but overall it’s not a big deal: when the PPP connection dies, the lease gets instantly released back to the pool anyway.
unfortunately the 60 second lease time causes problems, the ip keeps changing, you will browse it appears right on time network changed, and the android cell phone stops renewing the ip.
At this point, from testing we are able to pass the Mikrotik-Delegated-IPv6-Pool attribute to the DHCPv6 PD, and the IP is allocated just fine.
With MikroTik side showing MT-Delegated-IPv6-Pool = “IPv6_Pool” as intended.
However we are not able to get the “Delegated-IPv6-Prefix = xyz” that Radius Debug log op MikroTik side shows > to go back to Radius.
We are however able to get the radreply back to Radius when using pure DHCPv6 with Use-Radius=yes
So as of current 2022/09/22 we are not able to receive back the Delegated-IPv6-Prefix value back to Radius.
Nothing this is on latest ROS6 and ROS7 and ROS7 Beta builds
Any Mikrotik side update perhaps?
I am on 6.49.6 and passing Delegated-IPv6-Prefix through RADIUS to PPPoE and it’s working fine.
Hi,
Have you tested on several cpe? I have some here that the preferred_life_time only stays at 60 seconds when you put it to receive the radius prefix using the delegated_ipv6_prefix. I tried to adjust using /ipv6 nd prefix default set valid-lifetime=1800 preferred-lifetime=600 but it had no effect.
Hi
Please re-read my post, as I stated that I “am” able to pass the prefix to next hop “client”, but that it is not being sent back to RADIUS with PPP session radreply.
Have observed that IPv4 is sent via PPP radreply but IPv6 is being sent by the DHCPv6 server in seperate radreply with different username (mac address instead of ppp username) and session id, instead of being in the PPP’s radreply.
I am aware of the 60sec lease time issue and reached out to mikrotik support about it. They said they’re working on fix for that in 7.7beta3 (I believe that’s the version they said from memory). They said they will not fix it in 6.x.
`
So, I see now after testing a bit more that there is a problem. It’s actually not a problem with the 60 seconds, though. The problem is that, 10 seconds after lease renewal happens, the IP addresses assigned from the pool briefly go “invalid” and then back to “valid” again. At the same time, “IPv6 address changed” is logged, even if the addresses didn’t change at all. During this brief blip (1-2 seconds), forwarding of v6 traffic for those IPs on those interfaces is briefly interrupted.
This is Bad™. But it doesn’t just happen with the IPs that have 60 second lease time. It happens with any DHCPv6-assigned IPs, right after they are renewed. So even when you have 3 day lease times for PD prefixes, after 36 hours pass, there will be brief 1-2 second outage.
Stupid.
You can avoid the problem by not using IP pools and setting the addresses statically. But of course this is no real solution.
[…accidentally edited this post while trying to merely create a new reply; restoring the original content – ED]
While I agree that is bad behavior, there is a case to be made against using dynamic pools for PD: https://www.ripe.net/publications/docs/ripe-690
What is the current status of this long-requested feature in latest ROS 7?
I assign single static IPv4 addresses and static IPv6 prefixes (framed and delegated), like this in freeradius users file:
username Cleartext-Password := "passw0rd"
Service-Type = Framed-User,
Framed-Protocol = PPP,
Delegated-IPv6-Prefix = 2001:db8:abcd::/56,
Framed-IPv6-Prefix = 2001:db8:abcd:100::/64,
Framed-IP-Address = 192.0.2.100
where “abcd” is different for each customer, so each customer gets a /56 delegated prefix (for their LAN inside) and a separate /64 for the pppoe link itself, with room for expansion up to /48 per customer, in addition to their precious single IPv4 /32. I don’t want to use any IP pools, just static prefixes.
This setup works with VyOS PPPoE server (based on accel-ppp), but I can’t make it work for IPv6 with ROS 7.6 (or even 7.7beta6) on RB5009. Or should it work but I’m just doing something wrong? I see the dynamic DHCPv6 server created on the PPPoE server but without “use RADIUS”, and only framed (not delegated) IPv6 prefix assigned to client.
`
It’s hard to know how to respond to this because it is entirely unclear what part of this very long thread you’re responding to, or whether you read through the whole thing.
Most of us who are implementing Delegated-IPv6-Prefix RADIUS reply attribute are in fact doing so in order to delegate static prefixes to customers. Just doing so centrally from a RADIUS server, rather than within the config of a particular router. So not really sure what the point is of you linking to that article.
`
It works. It even works in ROS v6. So if it’s not working for you, then I’m not sure what to tell you…I’d perhaps take the time to perform some packet captures of the exchange between your RADIUS server and your PPPoE server in order to make sure the right reply attributes are being sent and in the right format, and perhaps also turn on debug or packet level logging on the PPPoE server to see what’s up.
Note that, per previous replies, up until ROS 7.7 (released nearly 2 months after your post, but a beta version was available at the time), RouterOS would create dynamic DHCPv6 servers for users with Delegated-IPv6-Prefix with a lease time of only 1 minute. In 7.7, they increased this to 1 day.
Back on 7 November 2022, I wrote:
`
`
…but it turns out that I’m the one who was (is?) stupid.
I was experiencing this phenomenon because on my test client router, I was using my script to hackishly implement RFC 9096. RouterOS would run my script at every DHCP lease change event, even for a lease renewal where the address did not change. And my script would blindly disable and re-enable the IPv6 address whenever it would run. Since with DHCP most clients typically attempt lease renewal after half of the lease time has gone by, and since the lease time was 1 minute, I was seeing IPv6 internet reachability blips on my LAN every 30 seconds.
But it was my script causing this, not RouterOS.
I have rearchitected my script to not do this, and problem solved. So the lease time being only 60 seconds long is still effectively a non-issue. That said, for those who care about it, it looks like in ROS 7.7 MikroTik changed this so that the lease time is now 1 day for these dynamic DHCPv6 servers created in response to the Delegated-IPv6-Prefix reply attribute.