IPv6 Pattern Based Forward/Reverse Mappings

[Matthew Moyle-Croft]

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

>
> In message <E770E412-04F7-4591-9883-3E6D2BE8F41E at mmc.com.au>,  
> 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.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
>>
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org