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.

Mark

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

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