On 2/7/14, 22:58 , William Herrin wrote:
On Fri, Feb 7, 2014 at 7:40 PM, David Farmer <[email protected]> wrote:
...
Howdy,
You pulled a TLDR on me. Like I said at the end of the message: after
you admit that the reason you (the general you, not you specifically)
don't want this policy is that you've knowingly been doing things
wrong for the last decade plus, you add the following sentence to the
still concise policy.
How do you justify saying they've been doing anything wrong? Nothing in
policy says that its wrong. The only thing in policy, says is ARIN's
primary role is issuing resources for use within the region. So that
means out of region use is a secondary role in my opinion. The only
justification for any regional limitation I can theoretically come up
with, is that the stress on the system created by uneven IPv4 run-out
among the RIRs is creating a temporary conflict between these primary
and secondary roles, and only for the remaining IPv4 free pool
resources. And to be honest, I'm not sure that is really sufficient
justification to change the rules, or that any change can be effective
to prevent the problems created by the uneven run-out among the RIRs.
"ARIN number resources in use outside the region upon enaction of this
policy are grandfathered until recovered from their then-current
assignment."
I think if we are to make any restrictions, they should apply only to
new IPv4 resources from the free pool and not be retroactively applied
to old resources even if they are recovered in the future, or for any
transferred resources. But, I'm still not convinced any restrictions
are needed or justified even because of IPv4 run-out, and I'm even less
convinced they can be effective without significant collateral damage.
We (globally) created a run-out scheme that was going to be uneven.
There was at least one rejected proposal that tried to even out the
run-out across the RIRs. Unfortunately, I think we just need to live
with the consequences of our actions, or inaction in this case.
Now IPv6, this means multinational companies will need separate allocations
from each RIR that they function within that RIR's region. It will be common
for most multinational companies to need 3 or 4 separate allocations then,
that will bloat the IPv6 route table. In IPv6 we are trying to minimize the
number of non-aggregatable prefixes allocated, that is why we are doing
sparse allocation for IPv6.
You make a good point. I'd be satisfied limiting it to "IPv4
addresses" instead of "number resources."
Will you be drafting a global policy to the effect that registrants
are encouraged to get their entire IPv6 allocation from their single
home registry? Once again, it isn't appropriate for a regional
registry to act unilaterally in this regard.
It's not unilateral action, its been the norm all along. The RIR system
is intended to be facilitatory, not restrictive. AfriNIC and LACNIC
have diverged from the norm by putting in place regional use
restrictions. I'm not saying there wasn't reasons, or that they did
anything wrong, but that was not the norm previously.
Please read what Geoff Huston say at the NANOG 59 PPC, toward the end of
the following section;
https://www.arin.net/participate/meetings/reports/ppc_nanog59/ppc_transcript.html#anchor_4
As the problem statement says, I think the real problem is that policy
is ambiguous on the subject of out of region use. Which means there are
some in the community that think out of region use is outside the rules,
as you seem to think. Then others think it is perfectly normal and has
always been allowed, because its never been disallowed in policy. I
think we need to clarify that out of region use was always intended to
be allowed by policy.
Thanks.
--
================================================
David Farmer Email: [email protected]
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: 1-612-626-0815
Minneapolis, MN 55414-3029 Cell: 1-612-812-9952
================================================
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
