Paul Vixie wrote:
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".
I guess what it comes down to is that the intended use case for ULA-C is to
connect a bunch of companies with private address space on a private
network.
the idea that someone would only need PI for "public networking" is bizarre.
quite a lot of normal IPv4 space is never advertised into the "default free
zone" but it's universally unique and used "privately" with passion & verve,
and there is no reason to expect that IPv6 PI won't be used the same way.
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.
i think the disconnect here is that a lot of folks are assuming that the RIR
system only allocates "public" address space. that's not true today, and it
never has been true (compare historical allocations vs. DFZ advertisements),
and there's no reason to try to make it true or to assume that it ever will
be true. RIRs allocate universally unique space. how it's used (public vs.
private) is not an RIR concern.
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. 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, 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.
-Scott
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
