[short version: why ULA-C, when there is IPv6 "PI" space from RIRs already?]
bill fumerola wrote: > 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. Thus that recursive server is globally connected. As such hosts on the ULA-C network are also able to resolve 'global' addresses and most likely end up trying to send packets there and most likely one day want to connect to it anyway as one day you might just want to use SIP from your network or do something else than playing with your neighbors. > why can't the servers delegated ULA-C prefixes change addresses? i update > my arpa delegation NS glue occasionally without problems. You could, but doesn't that defeat the point of having "your own global unique space that never changes" if you have to contact an external site and have to update those pointers all the time, causing delays in updates etc etc etc. > 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? For the same reasons that you also expect those companies to connect to the global Internet and that they have a recursive name server and handle all their network operations the same way you are doing. Also you are claiming that PTR finding is done with a 'decades-long proven service', you are correct, but that service is for Internet hosts, not for hosts in private (RFC1918) networks. Thus the question is: How do RFC1918-based interconnected networks nowadays lookup these PTR records? Because that is the "decades-long proven method" you are looking for. Somehow I think it does not involve the Internet as it seems that RFC1918 space points to AS112. > why does a host having both a ULA-C address and a global unicast address > cause you grief? You might want to see one of the other replies where I actually mentioned that this might be a possible scenario but that it might cause problems too. > 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) You can also make entirely different routing policies for every /64 or for that matter, take your /48 and split it into a /49 for for local traffic and another /49 for global traffic, filtering off one of the /49 so that it doesn't have Internet access. What is the difference again? >> 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). Does your blood pressure rise already that you need to use exclamation marks? >> 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. So they ALSO need a PI allocation next to the ULA-C allocation, wow talking about wasting address space and doing difficult See above, just split your /48 into two /49's. Or for that matter, request a /47 from a RIR justifying where you need it for. > they can run their own from a PA allocation from that organization's ISP. You mean a PA assignment, but indeed as mentioned above: when you swap ISP's you need to change the reverse DNS entries. Can you be offline that long? > they can be slaved by that organization's ISP and NS pointed at the ISP. Thus requiring you to again contact an external entity to update your stuff, while you wanted to be totally independent of the Internet and not to forget, more importantly from that upstream ISP. What was the point of having this globally unique address space again? Why not use PA space? > they can come from a company (ultradns, everydns, easydns) who provides > such services. And thus having a very tight relationship with that organization. See above. > 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. Looking at current policies, that is far from the case. > 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. What is wrong with that PI block which you mentioned above? Does not solve all your problems already? > 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. Having that space not there at all also reduces it. ULA (RFC4193) doesn't delegate NS reverses either. Nobody seems to have an issue with that (yet :). Greets, Jeroen
signature.asc
Description: OpenPGP digital signature
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
