[arin-ppml] support for 2014-1 (out of region use)

David Farmer farmer at umn.edu
Mon Feb 10 10:02:13 EST 2014

On 2/7/14, 22:58 , William Herrin wrote:
> On Fri, Feb 7, 2014 at 7:40 PM, David Farmer <farmer at umn.edu> 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;


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.


David Farmer               Email: farmer at umn.edu
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

More information about the ARIN-PPML mailing list