ISP provided 8 ipv4 address, so I can dial up to 8 pppoe connect.
I add pppoe-out1 ~ pppoe-out8 on my RB962 to use all my ip address.
each pppoe link also provided ipv6 /64 ip address, too.
and now I am trying to add ipv6 dhcp client to all my pppoe-out interfaces…
the first one is ok, I can get my ipv6 prefix on pppoe-out1,
and when I am add the second one, it fails (never got an ipv6 prefix), due to the same DUID,
the only way to change DUID is to switch “use interface DUID”, I tried, and seems like I can only got 2 prefix (and I would like to have 8 ).
You can try to add 7 additional MACVLAN interfaces (over the ethernet interface), each will have their own MAC address. Then dial pppoe-out2~8 on those MACVLAN interfaces instead of on the main ethernet interface, and turn on use-interface-duid on those instances.
I tried, but…
(1) I add MACVLANs and dial pppoe-out 2~8 on them.
(2) when I am trying to use DHCPv6 client…if I add DHCPv6 client on pppoe-out interface, they got the same DUID, and if I add DHCPv6 client on macvlan interface, it shows different, but I cannot get my ipv6 prefix.
Does it mean that the DHCPv6 Clients on the different pppoe-out interfaces all have the same DUIDs, but different from when use-interface-duid is unchecked, right?
Edit 2: Well, while trying to create additional PPPoE out instances and adding DHCPv6 clients to them, I have now been hit by this bug :
I am afraid you’ll have to open a support ticket and wait for months. A PPPoE client interface does not inherit the MAC address from the underlying L2 interface as it is itself an L3 one, so use of macvlan interface changes nothing. If you set use-interface-duid to yes, the DUID of any PPPoE interface is always set to 0x0003 (link-layer address) 0x0001 (Ethernet) 0x0000 0x0000 0x0000, which is not nice to say the least (as the hardware type is definitely not Ethernet). If use-interface-duid stays at the default no, it uses the MAC address of ether1 to build the DUID. If you manually define a Client-ID option with some arbitrary DUID value and make the DHCPv6 client use it, it indeed replaces the automatically generated one in the DHCPv6 Solicit message by the user-defined one, but it does not replace the DUID value in its internal data, so it ignores the Reply from the server, which contains a copy of the client ID, with a bad client DUID log message.
Yes, I upgraded to the latest 7.17rc3 and it’s has been fixed as you said. And can confirm that sindy is correct about the DUID being all 0x00030001000000000000 . So what I wrote above won’t be able to solve your problem.