Paul Vixie wrote:
As I read RFC 4193 section 4.4, it confirms my previous understanding
that there is no mechanism (and should be no mechanism) for delegating
reverse DNS for a locally generated ULA. To my mind, this is a reason
for adopting draft-ietf-ipv6-ula-central-02.txt: the registration of the
ULA-C blocks allows the registrar
who is the registrar?
The draft under discussion assumes, as do I, that it will be the local
RIR, in my case ARIN.
to delegate reverse DNS authority (to
servers with globally routable non-ULA addresses) while avoiding the
problems outlined in RFC 4193 section 4.4.
none of this explains why it's not a simple RIR policy matter to create a
new kind of PI space that's cheaper/easier to get due to the recommendation
that it not be accepted into the DFZ.
It could be done that way, but if it is, don't expect a "global"
policy. In addition, the netblock for ULA-C is already reserved by
previous RFCs, out of a well known ULA netblock. It seems like a simple
IETF matter to approve a version of draft-ietf-ipv6-ula-central that
directs IANA to assign portions of this netblock to RIRs for them to use
in the manner specified in the draft.
If the IETF decides not to advance draft-ietf-ipv6-ula-central in favor
of allowing RIRs to do something similar on their own, that will likely
be what happens. But if the RIRs were to advance a policy that looks
like ULA-C at this point, they would be accused of doing an end run
around the IETF process. So here we are.
-Scott
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
