who gets a /32 [Re: IPV6 renumbering painless?]

Mon Nov 22 19:20:51 UTC 2004

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."