Jeroen Massar wrote:
Scott Leibrand wrote:
ULA-C and PI space will likely both cost about the same, and your
brother could likely afford either. The issue isn't so much dollar cost
as availability: your brother likely doesn't qualify for PI space
(unless he can justify efficient use of a /22), but he could get ULA-C
just by asking.
Wow, a /22 IPv6 space, that is a big chunk. But I assume you mean /22
IPv4. What has IPv4 to do with IPv6?
Yes, I was referring to a /22 of IPv4 space. Current ARIN policy
requires that, in order to get IPv6 PI space, you meet the same
qualifications as for IPv4 PI space. (You needn't actually get the IPv4
space, but that was the least controversial method of justification
available, which avoids going down the controversial rat-hole of
justifying by "sites", "nodes", or "subnets" and specifying HD ratios
within an end-user's network.)
and moreover why is that ARIN policy
being forced upon the IETF thus leading to ULA-C and then leading to
heavily hinting ARIN to provide ULA-C as a way out.
I don't think there's any forcing going on. See below.
Clearly ULA-C is just "cheap address space", nothing more nothing less.
And the sole reason for a possible existence seems to be that the
policies in RIR land do not allow everybody to get address space the way
they want to. Instead of changing the RIR policies, ULA-C gets invented.
Do you have a proposed change to RIR policies? If so, I invite you to
make a policy proposal. I also invite you to read the archives of the
discussion surrounding previous similar policy proposals.
Which is also what you write in the 2 emails before this one, but in
between the lines.
The RIR community effectively blocks people from getting address space
on the premise that "but that costs routing slots", even though the
minimum allocation is /48 either way, and then on top of that basing
that decision on IPv4 address space usage, wow.
I don't know about you, but I help run a network that provides those
routing slots, and doing so costs real money. Right now we're in the
process of upgrading a large number of routers, at significant cost,
simply to provide enough routing slots to support the growth in the BGP
table.
The RIRs currently require small networks to get provider aggregatable
(PA) space from their provider(s). This ensures that any more-specific
routes originated from such space can be safely filtered, while
maintaining reachability via the provider's aggregate. PI space cannot
be filtered this way, so there is a higher bar for getting such space.
The height of that bar can be adjusted (as was recently done for IPv4 by
changing from a /19 to a /22 for multihomed networks.) In fact, the IETF
originally specified that all IPv6 space should be PA, leading to fears
that ULA-C space would become the only de facto PI space. With recent
action by the RIRs to create IPv6 PI space, those fears have been mostly
alleviated.
I think that ULA-C is a really really bad idea because of this.
Perhaps. But just as "Democracy is the worst form of government there
is, except for all the others we've tried", I think ULA-C is better than
what's available now, and more practical in the near term than a
PI-for-everyone utopia.
The fact that IPv6 PI space exists at all is due to the action of
individuals working through the RIR public policy process to create it.
Some of the same individuals, recognizing they've pushed as far as they
can toward liberalizing PI for now, would like to create additional
flexibility for small networks to use IPv6 in a way that suits their
needs. In order to avoid creating an IPv6 "swamp", those individuals
have asked the IETF to standardize a new form of registered private IP
space out of a single common global netblock, and allow the RIRs to
begin allocating/assigning that space to registrants. Their attempts to
do so are being met with cries of "why don't you just liberalize PI."
Do you see the irony here?
-Scott
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
