IPv6 Pattern Based Forward/Reverse Mappings

[Matthew Moyle-Croft]

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

(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