In message , Matthew Moyle-Cro
ft writes:
> 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.

This is one area where IPv4 think is not a solution. Let
the end user machines update their PTR records. Vista
already does this.

BIND 9.6 has "tcp-self" and "6to4-self" to provide weak
authenication (tcp connection) to prevent third party abuse.


> Currently for IP pools on our LNSes we just populate generic entries
> for forward/reverse like:
> 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 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:
> $GENERATE6 64 $ IN PTR $
> and we'd get entries like:

> 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

Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: