My ISP supports v6 via 6RD, and I see that my ISP router has been assigned a v6 prefix. Apparently it does not support statefuf assignment, as configuring my attached MT router (via ether1) with DHCPv6, it does not get an address. Configuring accept-router-advertisements=yes I see a v6 address configured on ether1, but with the advertise flag = no, and I cannot change that.
How do I get the MT router to advertise the prefix on its interfaces?

Use DHCPv6 client and configure it to receive a prefix on WAN interface. Also configure it with pool name. After you receive a pool into the pool named in configuration, you'll be able to assign IPv6 addresses from this pool to router's LAN interfaces. This will in turn allow router to announce appropriate prefix enabling attached devices to "construct" a SLAAC address.

Hi,
Thanks for the reply. I tried configuring the DHCPv6, as I mentioned. And a pool.
What do you mean by "After you receive a pool into the pool named in configuration". What is it that I should see happen?

I also gave an address to the bridge (::2/64), as I saw you suggested in another discussion, with label advertise=yes.
Do I need to do the same by hand for all the LAN interfaces too?

Use DHCPv6 client and configure it to receive a prefix on WAN interface.

Admittedly OP was a little ambiguous about this, but he did already mention he had tried to set up a DHCPv6 client. The ambiguity is that OP did not make it clear whether this client had been configured to attempt to acquire an address, or a prefix. If it was only configured to try address, and if the upstream gateway doesn't run a DHCPv6 server that can do /128s, then obvs. that won't work.

Even though we lack enough information to make a definitive conclusion, there are, however, enough clues in the original post to suggest that what you are advising will likely not actually work in this case (though it's worth trying, if it hasn't been already). OP mentions "6RD", as well as an "ISP router" that the MT is downstream of. Most ISPs have moved on from using 6RD as a transitional overlay/tunneling tech, but if this ISP is still using it, if their largest contiguous address space from their RIR is a /32, and if they implemented 6RD by embedding all 32 bits of the client IPv4 address (not uncommon in its heyday), then the *most* sizable prefix they would be able to allocate to end-users would be a /64 (though once the 6RD tunnel was up, they could in theory also point a larger prefix down the tunnel, & one that was unrelated to the 6RD address space, I suppose).

@jnob, you need to find out some more details from your ISP about their IPv6 deployment. Specifically, what is the size of the prefix you should expect to get from them...is it more than a /64's worth? And if larger than a /64, is their router running a DHCPv6 server and capable of PD (prefix delegation)? If they provide an initial /64 allocation, do they also provide a secondary & potentially larger allocation in addition to that, routed to you via the first? If all are "yes", then as @mkx said, you need to create a DHCPv6 client that runs on the WAN interface of your MT, configured to run in "prefix" mode. When you create it, you will need to give it a Pool Name; this can be any uniquely arbitrary string of your choice. You will know it worked if you see a value for "prefix" and a countdown starts for "prefix expires". At that point, you go to IPv6 > Addresses, Add, set Interface to your LAN interface (likely bridge), easiest is to check "EUI64" and "Advertise", and set From Pool to be whatever you set Pool Name to be in your DHCPv6 client. Voila.

If, however, your ISP does *not* (as I suspect) offer anything more than a single /64, nor does their router run a DHCPv6 server, then I'm afraid your options are extremely limited. Some of these options would require the cooperation of your ISP, and virtually all of them are what I'd categorize as "expert mode". Your ISP likely expects you just to connect directly to their router and doesn't expect you to stick another one downstream of theirs. Ideally, RouterOS would run a Neighbor Discovery Proxy (NDP) for scenarios exactly like yours, in which case you could just make this work without having to talk to anyone at the ISP; unfortunately, ROS lacks this extremely crucial feature.

If you have the option of replacing the ISP router with the MT, in theory you can get it to talk to your ISP's 6RD gateway directly. (ROS doesn't actually have native 6RD support, but since 6RD is just built atop SIT, it's possible to wire things up manually with what ROS calls "6to4", which is a bit of a misnomer since the term "6to4" carries additional historical baggage, and what ROS means by that is not what everybody else means. Anyway, this is easiest to accomplish if your IPv4 address from your ISP is static; if it is not, then some creative RouterOS scripting is going to be required.) But if the ISP only directly wires up a single /64 to the SIT tunnel & doesn't route a second prefix over that tunnel to you, then you are still left with the same problem of how to get that single /64 to work on your LAN without proxying the ND messages back to the ISP over the tunnel.

It's not 100% clear how the ISP is getting their own router to offer the (assumed-to-be) singular 6RD /64 on its own LAN-side with SLAAC, unless their router is actually capable of NDP. If you have admin access to the ISP router and if it is sufficiently capable / feature-full, then it *might* be possible to coax it into routing that /64 to your downstream MT, while still having it do whatever "magic" it is already doing to make the WAN > LAN v6 forwarding work as it currently is. You'd do this by removing the IPv6 address from the LAN interface of the ISP router, and instead pointing it at your MT's WAN-side link-local address (while also configuring a static ::/0 default route on the MT pointing at the ISP router's LAN-side link-local). Then you can simply assign that /64 to your LAN interface on the MT.

Because of the missing NDP feature, the "easiest" option, sadly, is simply to use NAT66. Ideally, IPv6 does away with NAT. But because of different ISP deployment strategies coupled with the lack of useful features like NDP, using NAT may be the only way out of your predicament. It's depressing that it has come to this (please, MT: fix the lack of NDP in ROS! It's only 2025, after all!), but hey: at least NAT is possible on ROS with IPv6, which gives you an "out", even if it is the least desirable outcome (next to no IPv6 at all). To make this work, you'd leave accept-router-advertisements=yes, pick some different IPv6 prefix to use on your internal network (strictly speaking, this should be "ULA" address space, though many network clients/hosts may turn their nose up at ULAs and elect to just use IPv4 instead, which isn't ideal, soooo...you may have to pick some GUA that is unlikely to be used by anyone, or at least not ever visited/contacted by you, sigh.), and then configure an IPv6 > Firewall > NAT rule similarly to how you'd do it for IPv4.

Thanks @NathanA very much for this extensive reply and explanation.
MY ISP router (which I have admin access to, but which doesn't provide advanced configurations) is supplied a /64 prefix, which I see reported in its admin interface. Regarding IPv6, there are no other configuration possibilities (enable v6 on LAN -> you see a 6RD prefix assigned, or turn off.) This prefix is advertised to its LAN interfaces, since my MT WAN interface sees the prefix and configures an address (and in the neighbor list I see the ISP's v6 address: prefix::1.) I don't believe the ISP router implements a DHCPv6 server, since the MT DHCPv6 client never gets an address (which was configured by me to get address+prefix.)
So my situations seems to fall under your second hypothesis: "your ISP does *not* (as I suspect) offer anything more than a single /64, nor does their router run a DHCPv6 server".
I suppose I was initially expecting something like NDP to work after seeing the WAN interface succesfully receive the prefix...

Regarding IPv6, there are no other configuration possibilities (enable v6 on LAN -> you see a 6RD prefix assigned, or turn off.)

There is no IPv6 static route screen?

Are you able to divulge the make and model of this router? I would also be curious who your ISP is...

I suppose I was initially expecting something like NDP to work after seeing the WAN interface succesfully receive the prefix...

Unfortunately not. Unless we can coax the ISP router into routing the prefix to your MT, the only option MT provides to deal with this scenario where it accepts upstream RAs is to configure NAT66. Yes, it is a shame.

No, no v6 info.
The fiber router is a MediaAccess FGA2130FWB, commonly called FASTgate by the ISP, from Technicolor.
The ISP is Fastweb Italy.

So, I am not 100% clear how this is working, but I just ran an experiment with Hurricane Electric Tunnel Broker (which also uses SIT encapsulation, same as 6RD), where instead of using the separate routed prefix they assign to my tunnel, I took the /64 assigned directly on the tunnel itself, and on the "6to4" interface on my MikroTik, I assigned the client side address (::2) as /126 instead of /64, and then assigned some other address within the /64 block to my LAN interface, ...

...and it works. I can SLAAC to devices in my LAN and the addresses that they self-assign are reachable from the internet, and they can talk to other IPv6 hosts without a problem!

I'm guessing that on Hurricane's side, they must just indiscriminately point the whole tunnel /64 prefix at the SIT interface, instead of directly to the ::2 address on my side that they have hard-coded as the gateway on my side for the other prefixes. Since the tunnel is technically a point-to-point interface, I suppose their side does not care about ND and does not track neighbors, so NDP proxy is not actually necessary?

Anyway, if Fastweb's 6RD gateway works similarly, then you might be able to do something similar. The only problem is, you would probably need to get rid of the Fastweb router, and have your MikroTik directly handle the WAN connection to Fastweb. I see that yours has a built-in ONT, though, which might make that a challenge, unless you can perhaps keep it physically in place but put it into bridge mode. This forum thread seems to talk about how this isn't an officially supported configuration but that there might be ways to coax the router into letting you do this. Other solutions discussed include buying a compatible ONT SFP module to populate into a router of your own that has an SFP slot. (I don't know what MT model you have and whether it has one.)

Actually, if you are getting a public IP routed to your MikroTik through the ISP router, you could establish a second, separate 6RD tunnel to Fastweb's gateway, while leaving their router in place. But I'm guessing their router is giving you private IPv4 addresses, and NATting you.

Thanks again.
Substituting the Fastgate with another ONT I considered in the past and for me isn't a practicle solution.
I guess I just need to wait for Fastweb to upgrade their v6 network - or change operator!

@NathanA
In the latest beta MT has added:
*) ipv6 - added support for IPv6 ND proxying of individual addresses
I see this new Proxy section/Webfig tab for ND, and to "add" I need to specify an address. But I don't understand which "individual addresses" I need to specify.
I tried putting my /64, but that is rejected.

@NathanA
In the latest beta MT has added:
*) ipv6 - added support for IPv6 ND proxying of individual addresses
I see this new Proxy section/Webfig tab for ND, and to "add" I need to specify an address. But I don't understand which "individual addresses" I need to specify.
I tried putting my /64, but that is rejected.

Right. The changelog says "individual addresses", so you cannot do a whole prefix.

The sad fact is that, though this new ND proxy is a start, it is nowhere near complete enough of an implementation for your use-case. The Linux kernel also has an NDP proxy feature built into it with this exact restriction (individual hosts, not prefixes), so they likely just built a quick UI that works on top of that. Hopefully they don't stop here, and will expand upon it in the future.

I did test it, and it does work. What you need to do is turn off accept-router-advertisements if it is currently set to "yes", add the /64 on your MT LAN interface, but add an address on the WAN interface that is within that prefix that's next to your ISP router's address using a smaller prefix size (example: your /64 is 2001:db8:dcba:4321::/64, your ISP router has address 2001:db8:dcba:4321::1, then add 2001:db8:dcba:4321::2/126 to the WAN). The LAN-side /64 address on the MT should obviously be outside of that (so ::4 would be fine, or you can just set it to pick one automatically with eui64=yes). Then add a default route (::/0) pointing at the ISP router's address. Finally, under the new ipv6/nd/proxy tab, you need to add each individual address on your LAN that you want to be able to get onto the IPv6 internet, and set "interface" for each entry to be the WAN interface.

What this does is cause your MT router to respond to any IPv6 NDP request from the ISP router for any of those addresses. Now, obviously, having to effectively whitelist each and every IPv6 address that every single device on your LAN uses is just not practical in any sense, so as it stands, the feature is of extremely limited usefulness...for most people, it's not much more than a proof of concept. Though being able to add whole prefixes would be an improvement, that would still leave unaddressed the issue of how to deal with situations where the /64 prefix from your ISP router is dynamic. With IPv4 and ARP, the way MT handles this is with effectively an on/off switch for ARP proxy on a per-interface basis, which removes the need for statically configuring even prefixes entirely. MT probably needs something similar for IPv6 and NDP...either that, or maybe some way of adding dynamic prefixes to the proxy address list. (Honestly, it is kind of nice to have a bit more control than a simple on/off switch can provide, but a whitelist-only solution also comes with its own practical set of problems.)

In the meantime, since I assume this is a home network with not thousands of devices on it, I suppose that one thing you could try to do is run a DHCPv6 server on the MT in address mode with a really small address pool (say, a /120, which would be equivalent to a /24 in IPv4, which is what I'm assuming you are probably using for IPv4 address space on your LAN), and then just make sure to individually add all 256 of the addresses from that address pool into the IPv6 ND prefix list. This will 100% not work, though, for any devices that only support SLAAC addressing and do not do DHCPv6 at all (such as Android). And even for devices that do support DHCPv6, most of them by default will also SLAAC an address for themself *on top of* the address they acquire via DHCPv6, and then they will use the DHCPv6 address for inbound traffic only, and source outbound traffic with their SLAAC address. You'd have to find a way to force all of those to abandon that behavior, which may or may not be possible, depending on the device & platform. So, still far from ideal, and still a giant pain.

A big thanks again! Does sound like a pain, but I will start experimenting with your suggestions.