Allora ho chiesto un pò di cose al gentilissmo Richard Patterson:
Se serve una traduzione fatemi sapere 
Ciao Nicolo,
We have noticed that a user appears to be in MAP-T 1:1, perhaps he is one of the user in the test phase (blue green approach)?
He does not seems to be in the "designed pool" for MAP-T 1:1 clients. he in in the 2a0e:0410::/29.
We were expeting him to be in the range 2a0e:0468::/29 2a0e:0470::/29.We have several MAP-T "domains" broken down in to distinct DHCPv6 pools. Currently there's 1x DHCPv6 pool for MAP-T 16:1 and 1x for 1:1 on each BNG, but that will grow over time.
Are you planning to work with third-party router manufacturers to add MAP-T support?
I am referring mostly to the more consumer ones, so AVM, Netgear, Asus, TP-Link, D-Link.Re: 3rd party CPEs, I've been engaged by only one vendor so far, I believe due to your forum thread. I'd be happy to discuss things with others, if they'd also reach out, but we're not proactively trying to engage with vendors.
Our Sky Hub is built on the opensource RDK-B platform, and we have plans to push MAP-T feature support upstream, so other vendors can get the benefit if they also build using RDK-B.We also have creted a patch for the IA_PD prefix on Opewrt. before it was only possible to specify a PD prefix length and not the whole prefix.
Good stuff re: the OpenWRT patch to include prefix in the Solicit as a hint. Hopefully that will further reduce the likelihood of prefix changes.
Another question concerns the PSID offset, why did you decide to generate multiple sets of ports instead of a single larger range?
PSID Offset, we intentionally chose the default recommendation of 6 bits, which excludes the privileged ports 0-1024. It has been observed that there are firewalls and other such appliances out on the internet that don't like seeing flows sourced from these privileged ports. The side-effect of this design decision, is that the port ranges are carved up in to several non-contiguous blocks. You could also say there's a marginal privacy benefit of this as well, that flows are less identifiable based on source ports (unless the destination has visibility of the MAP rule being used)
Is it possible to opt in for MAP-T 1:1 testing?
If you can give me your current IPv6 prefix, I can request that you're put on MAP-T 1:1 if you'd like. We're currently migrating all customers with Sky Hubs connected over to MAP-T, those with 3rd party CPE are being excluded for the time being, but we will have to migrate them eventually. We'll be sending them communications first. Those that have DMZ or port forwarding enabled, will be opted out. Currently we're opting out back to dual stack, but then manually rolling those over to MAP-T 1:1. Eventually the automated opt-out process will go direct from 16:1 -> 1:1
