the tyres on this this thread are getting threadbare. let's finish soon.

...

(let me put it this way: A6/DNAME was shot down because of complexity, and it was simpler than this.)

Wasn't it more because a single A6 lookup could cause one (the resolver that is ;) to have to follow a overly long chain of A6/DNAME chains, which thus could cause maybe somewhat infinite lookups?

no.

I rather like DNAME btw: "ip6.int DNAME ip6.arpa", which works quite fine.

see http://www.isc.org/pubs/tn/ for a way to do your own block while you wait for the toplevel ip6.int administrator to see things your way.

A6 is fortunately not supported any more by BIND.

server-side support of A6 doesn't matter since no modern ipv6 client looks for it. just as client-side support of DNAME doesn't matter since the server will synthesize a CNAME whenever it emits a DNAME.

...

1. A6/DNAME were great idea, I'm really disappointed they are not going forward...

It is, except maybe for the above noted 'problem'.

that never was the problem. but the current problem is, AAAA got loose in the client population, so other than by server side A6->AAAA synthesis (which is either very difficult or impossible to do, depending on whom you ask), A6 is just plain dead.

...

What is bad however is that IETF instead of pursuing it as one effort has several of them including MULTI6, HIP, etc.

The fun of politics ;)

this fun is by design, though. ietf does not speak with a single voice; even the periodic pronouncements from that era's IAB are at best advisory in nature. the reason you see several working groups working on unrelated solutions to the same problem is that several groups of people each wanted to work together on unrelated solutions to the same problem. there's no real facility in ietf for saying "no, we've already picked a different solution to this, don't try."