(you missed some stuff.)
> (let me put it this way: A6/DNAME was shot down because of
> complexity, and it was simpler than this.)
I am not convinced A6/DNAME would have solved all problems, not even
all of the ones you pointed out.
the property of a6/dname that wasn't widely understood was its intrinsic
multihoming support. the idea was that you could go from N upstreams to
N+1 (or N-1) merely by adding/deleting DNAME RRs. so if you wanted to
switch from ISP1 to ISP2 you'd start by adding a connection to ISP2, then
add a DNAME for ISP2, then delete the DNAME for ISP1, then disconnect ISP1.
the DNAME was expected to be inside your own zone. presto, no lock-in.
my theory at the time, bitter and twisted i admit, was that we had too
many ISP employees in positions of power inside IETF, and that A6/DNAME
was seen as shifting too much power to the endsystems. i've since learned
that it was just another case of FID (fear, ignorance, and doubt).
naturally this presumed that you could add and delete ipv6 supernets from
a LAN, which appeared to be the case at that time, though now with dhcp6
and static addressing making a comeback that's no longer clear. in any
case there was a need for a TCP option for endpoint-renumber, which was
killed in a committee somewhere (i don't know which one, or where or when.)
given that ipv6 is now somewhat deployed without rapid renumbering, and
that rapid renumbering could have required logic in "both endpoints" of
every flow, but that there are now a lot of "other endpoints" without any
such logic, it seems to me that MULTI6's only option is to make NAT work,
even if you call it "site local addressing" or even "ULA's". (show me.)