On 2007-06-20 19:22, Scott Leibrand wrote:
Leo Vegoda wrote:
On 20 Jun 2007, at 12:36am, Scott Leibrand wrote:
[...]
Is this not already possible with a /48 PI assignment from ARIN?
Yes, but only if you "qualify for an IPv4 assignment or allocation
from ARIN under the IPv4 policy currently in effect." That currently
means you must either be a large network (qualifying for a /20), or
you must be large enough to run BGP, be multi-homed, and be large
enough to justify a /22.
Is ULA-C a new solution for a problem that's already been solved
with PI assignments or does it solve a new problem?
I believe there is a gap between the current PI policy, which is
targeted at organizations large enough to qualify for a routing slot,
and the need many smaller organizations have for their own IP space
for various internal uses. Some of those organizations will be happy
to use ULA-L, but some will need a guarantee of uniqueness and the
ability to list their IP space in DNS (.arpa) and in whois. If we
can meet the needs of those organizations without having to relax the
requirements for PI space, we can reduce future pressure on the DFZ.
So am I right in reading your answer as saying that the advantage of
ULA-C is that it solves the same problem that ARIN's IPv6 PI policy
solves but better. In effect, developing ULA-C helps side-step ARIN's
policy development process?
No, it solves a similar problem for a different (though possibly
partially overlapping) set of networks, and reduces the pressure to
apply a hammer when a screwdriver is what's really needed.
I would anticipate that for ULA-C to be implemented, RIR policy would
need to be updated to codify how the RIRs would administer ULA-C. As an
active member of ARIN's policy process, I see ULA-C as something that
should be administered by the RIRs, not by a separate registry, so that
the RIRs can direct applicants to the appropriate resources (PI for
large or multihomed networks, ULA-C for private, non-routed space for
those who don't qualify for PI, etc.)
This is the place for me to say that I believe the draft is wrong in
delegating this as an RIR policy matter. Like existing ULAs, ULA-C
should be treated as *technical* address space, and we should specify
that assignments will be made and recorded by a single instance of
a robot, operated by a trusted party. Designation of that trusted party
could certainly be a matter for IANA to negotiate with the community.
I see only downsides (unnecessary costs and useless policy discussions)
in treating this as anything but a purely technical matter. Let's leave
the policy discussions for matters where fairness and route scaling
are at stake. ULAs are plentiful (so there is no fairness issue) and
not WAN-routeable (so there is no route scaling issue).
If we don't do this, ULA-C has no noticeable advantage over PI
and we should just forget it IMHO.
Brian
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
