> > by asking for a use case, i'm pointing out that if you can't be reached by > > an ip packet from "there", then your need to look up a PTR corresponding to > > an address in "there" is unfathomable. > > I get that. But just because I *do* have IP reachability to "there", that > doesn't mean my local resolver is configured to go "there" for DNS > resolution. That's why I need to have a delegation chain pointing to the > appropriate name server over "there".
it sounds like what you want to propose is "something like BGP for DNS stubs" then. if you have a private relationship to other networks, then you should be able to express that relationship in both routing and DNS technologies. i guess this means i should add "stub zones" to my "metazones" work and publish that, since it would obviate this entire use case and perhaps many others. > > a global RIR policy to support this "private network" use case would > > suggest that each RIR lay aside a /32 worth of space that was meant to be > > carved up in /48 chunks for folks who needed smaller chunks of address > > space for private networking, with advice to the community that no address > > space in these /32's be advertised to the DFZ, and that it be filtered out > > if seen in the DFZ. an RIR could theoretically come up with a "private > > space only" membership class with lower fees. whois and PTR-space NS > > RRsets would be managed normally. > > You just did an excellent job of describing ULA-C. The only difference is > that ULA-C is being specified top-down through the RFC process, rather than > being put together in an ad-hoc bottom-up process that may be different for > each RIR. my only reason for quoting my own text above yours up there is so you can go back and see the word "global" before the words "RIR policy". are we done? > It is true that someone who can get a PI allocation can use it for internal > use just as they would with ULA-C. However, since someone who can get a PI > allocation can easily put it in the DFZ, the RIR membership has made > restricting the distribution of PI space an RIR concern through the policy > process. which is, perhaps, the reason i'm suggesting a new global RIR policy on this. > The RIRs could elect to allocate private-use-only PI out of a special block, > but such space is less likely to remain out of the DFZ, because the > designation of it as not-to-be-routed would not carry the force of an RFC > standard, you have got to be kidding me. have you not been watching the snippets of RFC1918-sourced traffic that i've been forwarding to nanog@ all these years? there is no "force of", either for an RFC "standard" or for an RIR policy. everything leaks, all the time. however, as Enigo Montoya said in The Princess Bride, "i know something you do not." which is that due in part to the endless route-theft by spammers and phishers and ddos'ers, RPKI is afoot. this may or may not stop bad guys from doing bad things, but it will certainly stop good guys from doing bad things. none of which matters, since from an RIR policy point of view, the recommendation of unroutability is meant to make the policy self-consistent and edible. it will have no more or less force than the similar recommendation made in RFC 1918, and everybody knows that. > and there would not be a single block (FC00::/7) to filter, but several > different blocks, one from each RIR who chose to create private-use PI > space. As such, I believe that the IETF should designate ULA-C and hand it > off to IANA and the RIRs to manage, rather than having the RIRs designate > private-use-only PI space. i could live with that if i had to. it's the "iana runs a PTR registration robot" and the "enduser selects their own prefix" elements of prior proposals i havn't been able to sit with. i see this as something every RIR ought to do, and that every ISP ought to follow. the RIR policy process is quintessentially regional and bottom-up, and i believe it will work fine for this application. the addresses described by ULA-C are uniquely global, and to assume that only the IETF, not the RIRs, can allocate "private" ones is counter to my understanding of the mission of every RIR. if IETF is to act, let it be to recommend that IANA reserve FC00 and allocate /32's to the RIRs if a request from an RIR comes in with the magic "RFC WXYZ" box checked. the *only* advantage to this is that DFZ participants who want to filter FC00 can avoid tracking per-RIR bogon lists. but please note, as you consider these matters, that any RIR at any time could declare a /32 for this purpose and start doing regional allocations out of it, and all DFZ participants are already prepared, process-wise, to track this and implement if it happens. -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
