On 11/09/2008, at 11:46 AM, Mark Andrews wrote: > > In message <[EMAIL PROTECTED]>, > 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: [EMAIL PROTECTED]
