IPv6 Pattern Based Forward/Reverse Mappings

[Mark Andrews]

In message <E5750F36-3AFA-4AD2-81C6-E720AF480FE1 at mmc.com.au>, Matthew Moyle-Cro
ft writes:
> 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.

	Mum and dads need this sort of support.  They have networks
	at home today.  Windows already sends the update request
	so you will have to handle the request one way or another.

	IPv6 is not IPv4.  Lots of things have changed since ISP's
	started pre-populating reverse zones.  There was no dynmic
	updates being done by default.  You can have different
	expections with IPv6 than you did with IPv4.

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

	The same way as you deal with 200,000 DHCP requests a minute. :-)

	A sdb module or two which looks at the query name and
	contructs a response would handle this.

> 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

	Your mum and dads already have networks at home. 
 
> > 	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
> 
> 
> 
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org