My ISP changed the IPv6 WAN type from DHCPv6 to PPPoEv6, since then,my rb5009(with routeros v7.17.2) can not get any IPv6 prefixes. when I replaced rb5009 with the router from the ISP, then everything is ok.
I searched the docs of the ISP, and found these requirements for home routers:
On the WAN side, it is necessary to support RA messages based on upstream network elements, and obtain IPv6 address prefixes/addresses and DNS and other configuration parameters through SLAAC, DHCPv6, RDNSS and other technologies.
On the WAN side, it is necessary to support PAP/CHAP authentication and obtain interface ID as a PPPoEv6 client in accordance with the RFC5072 protocol specification.
On the WAN side, it is necessary to support the DHCPv6-PD mechanism, accept the address prefix of the LAN side issued by the DHCPv6 Server through IAPD, and announce it to the access terminal, and support setting the LAN side global v6 address according to the address prefix given to the LAN side.
On the LAN side, SLAAC and DHCPv6 server should be supported to announce IPv6 address prefixes for home network devices, allocate IPv6 addresses and other configuration parameters.
Does routeros v7 support PPPoEv6 client？ Or any other suggestions? Thanks!
I’ve not tried that new a version but certainly older ones are fine.
What is your IPv6 configuration? Common mistakes are not changing the IPv6 settings from the default to accept-router-advertisements=yes, and having the DHCPv6 client set to add a default gateway and/or requesting an address in addtion to a prefix.
Is it any different from a regular PPPoE tunnel that negotiates an IPv4 address via PPP LCP, negotiates an IPv6 link-local address via PPP IPV6CP, and then performs DHCPv6-PD inside the PPPoE tunnel? I’m refering to something like this:
Because, to be honest, that’s the only way that I’m aware of and also have working just fine with a configuration like this one:
Thanks for your advices.
I guess there is something related to authentication. According to the ISP’s technical specifications, the router must fully comply with RFC5072.
I’ll try to capture the packets and make a comparison.
That, in essence, means that the DHCPv6 Server address is not link-local and thus cannot be used as the default gateway.
I usually recommend to people to configure the DHCPv6 Client to add a default route (add-default-route=yes), but with a higher administrative distance (that equals to lower priority, like default-route-distance=3) than the default route obtained via Router Advertisement, which means it can still serve as a fallback in case the ISP messes up the timers in the Router Advertisements, for example. But in your case, since the DHCPv6 Server is not located in the same link-local space, you’re better off not adding the default route (add-default-route=no).
Thanks for your comment, it helps me a lot. The post you referenced list a case nearly the same as me. I’m not sure whether My ISP changed for DHCPv6 relay, but the IPv6 firewall Tuning ideas in the post looks great.
Setting a DHCPv6 client add-default-route=yes is just wrong as the DHCPv6 protocol has no concept of a default route. Faking one from the source address of the DHCPv6 replies often works, but can easily fail if the ISP has different devices providing the DHCPv6 service and the gateway.
The Mikrotik default firewall rules are also incorrect, whilst link-local addresses are the most common for DHCPv6 messages GUA and ULA are also valid. Instead of:
add chain=input action=accept protocol=udp dst-port=546 src-address=fe80::/10 comment=“defconf: accept DHCPv6-Client prefix delegation.”
accepting DHCPv6 replies would be better:
add chain=input action=accept protocol=udp dst-port=546 src-port=547 comment=“accept DHCPv6 server-to-client replies”
