The IPv6 protocol was created over 25 years ago. And although it’s now older than some established IT professionals, for many it remains something new and unknown. Discussions about switching to IPv6 have been going on for a long time, fueled by panic over the inevitable end of the far-from-infinite IPv4 addresses. But no matter how much humanity resists, learning to work with this seemingly unfriendly protocol will still have to be done. Many providers are still ignoring the need to implement the new protocol. But this hasn’t stopped many enthusiasts from practicing on tunnel brokers, some of which generously hand out prefixes, up to /48, completely free to virtually anyone. As one of these enthusiasts, I more or less grasped the basic concepts and principles of IPv6 and eagerly awaited the day these networks would be offered natively by local providers. And so, in February 2022, Sarkor Telecom became the first provider in Uzbekistan (as far as I know) to announce the imminent launch of IPv6 networks for regular subscribers. It took a considerable amount of time from the announcement for the new feature to reach my node. This is understandable, as implementing IPv6 requires significant changes to network operation and is closely linked to serious consequences if decisions are poorly considered. The main concern here is that in a V6 network, absolutely all devices have their own «public» address, meaning they are visible from the outside world. People accustomed to demilitarized zones behind NAT should take this into account and take their firewall settings very seriously. While previously, a home network could safely protect a storage device or camera with a standard password (or none at all), now, having received a global address, such a device can easily fall victim to an attacker. It’s worth noting, however, that scanning for a vulnerable device in a V6 network isn’t easy, since even the smallest /64 prefix (which is assigned to a subscriber’s home) contains just over 18 quintillion addresses. Simply put—a lot! However, isn’t there a chance your device will automatically contact a malicious server, revealing its address? Well, if you’ve read (or skimmed) this far, then (at least I hope so) you fully understand what you’re doing and why you need it. Let’s get started with the setup itself. I’m running RouterOS 7.6, and it already has IPv6 built in. If you’re using RouterOS 6, you may need to enable the protocol support package of the same name. 1) Enable the DHCPv6 client directly on the PPPOE connection. The checkboxes indicate options for obtaining DNSv6 from the ISP, as well as Rapid Commit, which allows for faster communication with the DHCPv6 server if it also has this option enabled. 
In the interfaces, select your PPPoE connection towards Sarcor. You can enter any name for the pool. The prefix length in my case is /64 bits. If you’re lucky enough to have a larger network, use the corresponding number. We’ll get the default route anyway, so you don’t need to check this box. 2) If everything went as expected, you’ll see Status: bound in the lower right corner of the DHCP client settings window, and in the status tab, you’ll find the prefix assigned by your ISP. Copy this prefix to the clipboard and go to IPv6 > Addresses. 
Add a new address. In the address field, paste the previously copied prefix from the clipboard. In the «From pool» field, select the address pool. If it doesn’t appear, something went wrong in the previous steps. For the interface, select the interface through which your router will distribute addresses to the local network. This method will replace the familiar DHCPv4. Instead of DHCP, we’ll use «Advertising,» which in this case can be translated as announcing addresses to the network. If you want to distribute addresses, check the appropriate box. An alternative is to manually assign them only to the required devices, rather than handing out addresses to just anyone. Keep in mind that our beloved tas-ix isn’t currently fully aware of IPv6, so traffic in this address space will likely bypass any peering connections or local CDNs. Consider carefully whether this is necessary for you. :) 3) If you haven’t changed your mind, go to IPv6 > Neighbor Discovery and make sure ND is enabled for the interface where our network neighborhood resides. By default, this setting is set to allow all interfaces, but I chose to limit myself to my LAN’s bridge, as I have a lot of interfaces, and there’s absolutely no need to assign addresses to them. 
4) Also, just to be on the safe side, it’s worth looking into ipv6 > settings and making sure that protocol support is not disabled and transit (forward) is not prohibited. 
If necessary, you can go to IP > DNS and add any additional v6 DNS server addresses. In my case, I already received them dynamically via DHCPv6. 5) And then there comes a point when everything seems to be working, but then a nasty surprise awaited me. Half the websites don’t open, and the SSH session over IPv6 simply hangs a few seconds after connecting. I tried opening an SSH session directly from the Mikrotik, and surprisingly, it worked fine. Then it occurred to me to check the packet size coming through the network from the router and from the LAN client. Pings with different packet lengths immediately revealed the key: while packets from the router easily reached 1492 bytes (the MTU of the PPPoE connection), the maximum size from the client machine was 1444 bytes. Well, that’s way out of the question! ;) To be honest, I still haven’t figured out the reason for this behavior, so I solved the problem by adding automatic packet size adjustment rules to the firewall. So, go to IPv6 > Firewall > Mangle and click the plus sign. 
The two rules have different directions only, everything else is identical to each other.
In the interfaces, select your PPPoE connection towards Sarcor. You can enter any name for the pool. The prefix length in my case is /64 bits. If you’re lucky enough to have a larger network, use the corresponding number. We’ll get the default route anyway, so you don’t need to check this box. 2) If everything went as expected, you’ll see Status: bound in the lower right corner of the DHCP client settings window, and in the status tab, you’ll find the prefix assigned by your ISP. Copy this prefix to the clipboard and go to IPv6 > Addresses. Add a new address. In the address field, paste the previously copied prefix from the clipboard. In the «From pool» field, select the address pool. If it doesn’t appear, something went wrong in the previous steps. For the interface, select the interface through which your router will distribute addresses to the local network. This method will replace the familiar DHCPv4. Instead of DHCP, we’ll use «Advertising,» which in this case can be translated as announcing addresses to the network. If you want to distribute addresses, check the appropriate box. An alternative is to manually assign them only to the required devices, rather than handing out addresses to just anyone. Keep in mind that our beloved tas-ix isn’t currently fully aware of IPv6, so traffic in this address space will likely bypass any peering connections or local CDNs. Consider carefully whether this is necessary for you. :) 3) If you haven’t changed your mind, go to IPv6 > Neighbor Discovery and make sure ND is enabled for the interface where our network neighborhood resides. By default, this setting is set to allow all interfaces, but I chose to limit myself to my LAN’s bridge, as I have a lot of interfaces, and there’s absolutely no need to assign addresses to them. 4) Also, just to be on the safe side, it’s worth looking into ipv6 > settings and making sure that protocol support is not disabled and transit (forward) is not prohibited. If necessary, you can go to IP > DNS and add any additional v6 DNS server addresses. In my case, I already received them dynamically via DHCPv6. 5) And then there comes a point when everything seems to be working, but then a nasty surprise awaited me. Half the websites don’t open, and the SSH session over IPv6 simply hangs a few seconds after connecting. I tried opening an SSH session directly from the Mikrotik, and surprisingly, it worked fine. Then it occurred to me to check the packet size coming through the network from the router and from the LAN client. Pings with different packet lengths immediately revealed the key: while packets from the router easily reached 1492 bytes (the MTU of the PPPoE connection), the maximum size from the client machine was 1444 bytes. Well, that’s way out of the question! ;) To be honest, I still haven’t figured out the reason for this behavior, so I solved the problem by adding automatic packet size adjustment rules to the firewall. So, go to IPv6 > Firewall > Mangle and click the plus sign. The two rules have different directions only, everything else is identical to each other.
Final stop:
If you did everything correctly, ping my site, and you will see a long and ugly IPv6 address. ;) 
IMPORTANT! I’ll remind you again! Don’t forget about the firewall. Here are the basic rules that will block all external activity while allowing your local network to access the internet. /ipv6 firewall filter Replace the interface name with the name of your PPPoE connection. Add exceptions as needed. Boil for 20 minutes, add salt to taste. ;)
add action=accept chain=input comment="Related, Established" connection-state=\
established,related,untracked
add action=accept chain=input comment="accept from my net" in-interface=bridge
add action=accept chain=input comment="accept ICMPv6" protocol=icmpv6
add action=accept chain=forward comment="Related, established" connection-state=\
established,related,untracked in-interface=sarkor
add action=drop chain=forward comment="DROP fw to my net" connection-state=invalid,new in-interface=\
sarkor
add action=drop chain=input comment="DROP all input" connection-state=invalid,new in-interface=sarkor \
protocol=tcp