We use radius Framed-IPv6-Prefix (/64) for CPE WAN and Delegated-IPv6-Prefix (/56) for CPE delegation.
We can see from image bellow that is working. Character '*' before address indicates a single subscriber license.
But many times insted of renew ipv6 address the CPE release to acquire a new one. When this happens juniper keeps the old binding and create a new binding default:default with the same subscriber id and requiring a new license. We can see from image bellow that now we count two subscribers:
I have tried things like delete-binding-on-renegotiation but haven't sucess:
set system services dhcp-local-server dhcpv6 overrides delete-binding-on-renegotiation
set dynamic-profiles PPPOE-PROFILE protocols router-advertisement interface "$junos-interface-name" solicit-router-advertisement-unicastset dynamic-profiles PPPOE-PROFILE protocols router-advertisement interface "$junos-interface-name" prefix $junos-ipv6-ndra-prefix
Is there any way to force only a single binding in terms of license?
I think that Single-Session is availabe just for the same protocol: DHCP/DHCP6.
So PPPoE V4-V6/ DHCP PD requires one aditional subscriber license.
Am I right?
That is correct, Single-Session Dual Stack is currently supported for DHCP protocol model (dhcpv4/dhcpv6).
In terms of license, IP (demux/pp0) sessions are counted towards the scale and scale licenses. The underlying VLANs are not counted towards the Subscriber session count.
In the case of 1:N Service VLAN model the same VLAN is stacked under each for multiple subscribers. And for the 1:1 CVLAN, they are unique. In all cases, the VLAN sessions and flows are not counted towards the scaling limit. Also the number of VLANs are not counted towards the scale license.Examples: DHCPv4 subscriber over CVLAN is counted as 1 license. In the case of dual stack subscribers with DHCPv6 over PPPoE the license is counted as 1 license.
In your case, CPE (per household) should renew rather than acquiring new address from server(MX-BNG) to aviod consuming license resource.
In regards to "delete-binding-on-renegotiation" statement. This should work.
Note that if you added/configure this statement "delete-binding-on-renegotiation", this does NOT apply for the existing subscribers entries but it applies only to new subscriber login.
And in case if subscriber binding is not deleted on renegotiation while statement is present (meaning the subscribers that logged after the statement was configiure), open a ticket with JTAC, will address your issue.