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.
This makes some sense, however, how does the client system know which address it should use? what lets the client know that the path from client->server-address-ATT is better/worse/same as the path from client->server-address-MFN or client->server-address-uu ? I would think that the 'best' solution for all parties would be 'one' address for an end system, or one path to the end system.
Because when it matters, the administrator of the zone has the option of removing the DNAME records for the provider that is sucking at the moment. Not a panacea, but, at least help. Single address may or may not be the best solution. One path to end system is definitely NOT the right answer for everyone. More paths is less failure.
Perhaps this is just 'normal' technology acceptance process, and perhaps I'm missing a great many things in 'the v6-way', but if the multihoming can't be worked out in a sane manner I can't see rollout and acceptance of v6 coming any time soon.
Apparently, you are, because, the whole DNAME/A6 thing was deprecated and we were lamenting that it's existence would have made this somewhat simpler to administer.
there are, and will be in the future, folks that WANT NAT, regardless of the perceived 'badness' of it...
Why? You still have yet to justify this position. Owen -- If it wasn't crypto-signed, it probably didn't come from me.