There's an interesting thing that happens when using a Mikrotik router with Comcast and requesting a /60 prefix using the prefix-hint option.

By default, Comcast returns a /64 prefix to clients requesting IA-PD (prefix delegation) assignments with dhcpv6.
If you specify a prefix-hint of ::/60, it will supply a /60 as requested, but here's something interesting-

The server sends both the recently-held /64 and a /60 as two separate Advertise messages having the same XID, but different server DUID values.
(I've attached a packet capture)

So who's dropping the ball here? Is it valid to send two replies, but Mikrotik is just accepting the first and ignoring the subsequent prefix, or should Comcast only be sending the /60?

If I disable dhcpv6 client until the /64 prefix expires on Comcast's side, and re-enable the client with the prefix hint, I will only get the /60 response, but if it's supposed to accept multiple leases, shouldn't it work without my having to do this?

It looks to me like two different DHCPv6 servers. There's only one source address, but I think different DUID means different server (at least "logical server").

They both reply to client's solicit request, but one of them is too late, because client already went with first one. But even if it was the other way around in terms or reply speed, the /60 one has preference 0 and /64 has 255, so the latter would win anyway.

I'd tend to blame Comcast. Either they should send only one reply, or at least not assign the absolutely highest preference to /64 prefix.

I'd tend to blame Comcast.

I pretty much always feel this is true. I was surprised to see good IPv6 services available at home, though - even with this goofy flaw.
(I'm having to static-assign my address and disable DHCP client for a few days so I can get my /60 back)

I figured it was two servers - probably being done via dhcp relay on the local zone's router, hence the consistent source address and source MAC address. I didn't notice the priority value - that's interesting. I wonder if I can concoct a firewall rule that blocks the /64 reply but allows the /60 reply, just long enough for the Mikrotik to bind the /60 and ignore the /64....

Hi-ho, Hi-ho, it's off to the firewall I go...

I wanted to suggest using the "wrong" server DUID as unique value for L7 filter and drop the packet, but it looks like someone stole "/ipv6 firewall layer7-protocol" from my RouterOS.

I wanted to suggest using the "wrong" server DUID as unique value for L7 filter and drop the packet, but it looks like someone stole "/ipv6 firewall layer7-protocol" from my RouterOS.

I was thinking of using the content= filter, but using a lot of very specific criteria such as udp, srcmac, etc - because the content filter runs a regex on every packet and really can bog a router down... but then I got to wondering whether it would match binary data in packets....

EDIT - I didn't think I'd be able to use DUID because it also includes a timestamp value, right? I guess if I just specified the Link-layer ID of the wrong server, that would match anyway.... so long as you can match binary values in content= filtering.

Update - I tried using content=\xx\xx\xx\xx\xx\xx to match the DUID but got no hits with this rule.

I've just disabled DHCPv6-client for now and will wait until Sunday evening to re-activate IPv6.

DUID is supposed to be sort of static, generated once and then used. It can be changed, if you really want to, I guess it's what the timestamp part is for, because it's still based on MAC address, but additional timestamp allows you to create different DUIDs from same MAC. MikroTik could support that, but it doesn't look like it's possible now. It might also help you, because the client would look as different one.
In fact, it would probably not hurt anything (although I don't think it would be the best idea), if it was possible to use any sequence of bytes, because first requirement for DUID is that clients and servers must not try to interpret it in any way, and they also have to be open to different future types, so they must accept pretty much anything.

About using content=\xx\xx..., what did you use to set it, WinBox or CLI? I just played with that and "\xx" only works when set from CLI and when it's outside of printable range, it shows as garbage in WinBox. If you set \xx in WinBox, you get \\xx in CLI, so it's looking for literal string "\xx". One more catch, CLI likes hex characters in upper case.
I tested it with DNS packets and it works fine, my first impression is that it might be a nice upgrade for old L7 hack used for per-domain forwarding (until MikroTik finally, after all those years, add proper support for that), because matching simple string should be considerably faster than regexp.

Yep, I used Winbox - I'll try it later from terminal when I have time to mess with it again. Pretty sure it'll work, given what you've said about how Winbox escapes the \ character.

I'm basically just trying to block incoming IA-PD adverts from the DUID of the server that's giving the /64 so that only the /60 will make it through and get bound. (I'll just leave the /64 unaswered so it will continue to timeout on the server side)

As for layer-7 vs. content - I personally don't like the idea of using these in any kind of permanent setup because of the overhead they cause, especially the content= filter, because it matches all packets of a socket, where layer-7 stops inspecting after the first few packets go by (I forget the exact amount, but it's small). I kind of view them as hacks, at least in the way most people attempt to use them.

Using either one as a "per-server" redirect isn't feasible because the TCP socket must open and establish before any host headers can be sent to the server, and by that point, it's too late to redirect anywhere else - even if you did it, the new server would just see the packets as invalid state TCP (i.e. first packet of new connection is not a SYN handshake). It really takes a reverse proxy to do this. (supposing that I'm correctly following what you mean by "per site redirect")

I meant this old hack for DNS (original post from 2008... sigh). I'm not the biggest fan, because it's just that, a hack. But DNS packets are short, mostly UDP and since there's no better way to do it...

I've just disabled DHCPv6-client for now and will wait until Sunday evening to re-activate IPv6.

That will work. Or, go to the Comcast Direct support and request they release that /64.
https://www.dslreports.com/forum/comcastdirect
I have done that before. IIRC, they can do it by just giving them the cable modem MAC.

With that said, I'm pretty certain I have changed from a Comcast /64 to a /60 by just sending a release from the MT DHCPv6 Client. Make sure the hint is set to /60, then send a release/renew.

With that said, I'm pretty certain I have changed from a Comcast /64 to a /60 by just sending a release from the MT DHCPv6 Client. Make sure the hint is set to /60, then send a release/renew.

That happened several times over the course of me getting packet captures to analyze.
No dice.

The thing that's behind all of this was a bug in 6.34.1 where the prefix hint wasn't being sent, and over time, I lost my /60 and didn't notice - I wasn't really using the extra prefixes anymore, but me being a network guy, it's nice to have the extra segments if I want to spin one up for one reason or other. Strangely, I found my router had rebooted to the backup partition today and I was back on 6.34.1 - not sure why that happened, but I re-activated the primary partition and it's been running 6.35.1 again.

UPDATE: I've figured out the deal with the Comcast situation where I'm receiving a /64 AND a /60 as replies.

Comcast always sends two advertisements - it's just that normally, you'd get a /60 from both servers (or a /64 from both if you didn't specify a prefix hint). Basically, this is their redundancy on the DHCP side of the house so that if server A fails, server B is also offering prefixes, and if A happens to be dead, then B's offer will still make it through and the customers won't know the difference.

It's just that people aren't usually scrutinizing this whenever things are working, so whenever you're getting the /64 from the "lease that won't die" - you're pulling out the sniffer and discovering a /64 from the main server and a /60 from the backup server that doesn't have you bound to anything at the moment.

I guess it's nice that they try to keep you using the same prefix, but if you switch from a /64 to a /60, it should stop trying to give you the same /64.

Also, I was able to match the DUID of the primary server with a content="\78\9A\BC\DE" rule entered on the terminal. I suppose that setting a different MAC address on the WAN interface would get you a fresh lease too, without having to break out the packet sniffer and the hexadecimal filtering rule.