On Fri, Jun 22, 2007 at 08:13:23PM +0100, Jeroen Massar wrote: > IMHO then again, if you are requiring reverse DNS you clearly are connecting > some way or another to the at large Internet, thus then you come back to the > point of asking these folks how one can reach that at-large Internet from > those blocks that are 'local'. Saying "we will just put global unicast IPs for > the reverse DNS servers and route them inside" means you have global unicast > IPs, and I sure hope they won't change, thus clearly there is also some other > form of addresses involved there.
why does wanting to provide PTRs for ULA-C addresses imply they have any sort of global connectivity? machines can reach a recursive server that is able to reach another ULA-C delegation's NS. why can't the servers delegated ULA-C prefixes change addresses? i update my arpa delegation NS glue occasionally without problems. why should all the partner companies who i peer with and use our collective ULA-C prefixes to communicate also have to setup some half-baked DNS "peering" (read: selective slaving) when there is a perfectly good way of them finding those PTR records through a decades-long proven service? how does slaving scale when i have hundreds of partners? why does a host having both a ULA-C address and a global unicast address cause you grief? i may have entirely different routing policies for traffic based on their addressing (global unicast is dumped out local transit links, ULA[-C] to ULA[-C] addressing is carried on my backbone, VPN network, framerelay cloud, etc). > And please don't say NAT. If one is going > the NAT way, please stick to IPv4, I don't want to program code for that. NAT boogeyman! NAT boogeyman! everyone run, the idea must be bad! (this has nothing to do with NAT, but way to try to get blood pressure rising). > Thus the next iteration: where do those global unicast addresses that are very > stable and can be used for reverse DNS come from? Need some "PI" folks? :) they can be run from servers in that org's PI allocation. they can run their own from a PA allocation from that organization's ISP. they can be slaved by that organization's ISP and NS pointed at the ISP. they can come from a company (ultradns, everydns, easydns) who provides such services. just like any other reverse delegation works. if we're going to actually delegate ULA-C blocks to orgs it makes sense to also delegate reverse to them. we always say (in RIR-land) that addressing and routing are completely different. i'd argue that addressing and DNS are not completely similar. don't cause people to come up with ideas ranging from zany to stupid to dangerous to difficult when the standard way of operating will do just fine. giving recursive servers some NS glue for recursives to follow and go knocking on will reduce load on the IANA/RIR run ip6.arpa NS servers. -- - bill fumerola / [EMAIL PROTECTED] -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
