On 11/09/2008, at 11:46 AM, Mark Andrews wrote:

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


I wish you'd read my comments below before saying that.

I don't actually want to scale our nameservers to have to cope with an
extra million or so updates per day - what happens if something breaks
and suddenly I get 200,000 update requests in a minute? I don't
necessarily want domestic customers to be able to arbitrarily set
reverse mappings - I want to prepopulate so that no matter how broken
the customer's machines/firewalls/CPE are that they have useful
reverse mappings.

Being an ISP we're not able to enforce policy in the same way a
corporate does - we don't get to choose really how broken customers
own networks are.

MMC


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