Hi,
My apologies if this has been covered before. If this isn't the right
place then let me know.

I work for a largish ISP - we've started rolling out IPv6 to customers
and at some point will be offering dual stack broadband. One of the
issues is working out how to do generic IPv6 forward and reverse
mappings.

Currently for IP pools on our LNSes we just populate generic entries
for forward/reverse like:

w-x-y-z.lnsA.popB.ourdomain.net

BIND has some support for this in IPv4 with the $GENERATE directive
which allows quick and easy population of forward/reverse mappings.

Obviously handing our subnets (/64s or whatever becomes the answer) to
customers means this becomes more complex - we don't really want most
customers dynamically updating these (99% of customers don't want to,
don't care or don't have the skills to anyway) and it represents a
scaling issue as we're talking 150k+ ranges. So I want to be able to
have a similar directive for AAAA and ip6.arpa ranges so that I can
populate our reverse mapping files quickly, easily and without burning
large amounts of disk. (Please don't start and argument about
customers being able to have static ranges and delegate it themselves
- we've got solutions for those customers, this is for the mum and dad
customers who don't care and don't want to know - they want to not
care and have us do the work).

eg.

If an LNS has a /48 then I want to be able to specify something like:

$GENERATE6 <#bits> lhs [ttl] [class] type rhs [comment]

So instead of the range being a simple decimal increment it's a fill
of nibbles upto X bits. I know that forward mappings might be nice to
be quads, but this keeps it to one directive.

So, we could do reverse mappings for a /64 with:

$ORIGIN c.b.a.9.8.7.6.5.4.3.2.1.1.0.0.2.ip6.arpa
$GENERATE6 64 $ IN PTR $.lns1.pop1.myisp.net.

and we'd get entries like:

1.2.3.4.5.6.7.8.9.10.a.b.c.d.e.f.c.b.a.
9.8.7.6.5.4.3.2.1.1.0.0.2.ip6.arpa. IN PTR
1.2.3.4.5.6.7.8.9.10.a.b.c.d.e.f.lns1.pop1.myisp.n et.

(Sorry if I've got the nibbles wrong - it's not important really to
the story here :-)

And hopefully just the directive would be stored in memory and a "hit"
on a covered IP address would cause it to be looked up and resolved
appropriately.

Best Regards,
Matthew