[arin-ppml] ARIN-prop-167 Removal of Renumbering Requirement for Small Multihomers

Owen DeLong owen at delong.com
Wed May 2 21:37:17 EDT 2012


On Apr 30, 2012, at 6:58 PM, Jimmy Hess wrote:

> On 4/30/12, Kevin Blumberg <kevinb at thewire.ca> wrote:
>> At the last ARIN meeting in Vancouver and prior to that in Philadelphia
>> staff pointed out that almost no one was coming
>> back to ARIN for additional small end user assignment. I believe the number
>> quoted was 1 in Philadelphia and 5 in Vancouver
>> of which many hundreds of people had taken advantage of getting /23 and /24
>> initial allocations.
>> 
>> While I understand the concern with the routing table, this policy has erred
>> too far to one side.
> [snip]
> 
> The policy was implemented September 2010.    That is approximately
> 1.5 years ago.
> The fact hundreds of applicants occured showed success of the policy,
> not a failure or err'ing of the policy.
> 
> If the renumbering requirement were considered too burdensome, no
> organizations would have applied for a /24  multi-homing assignment.
> 
That simply isn't true. The fact that so few have applied for increased space in such a sea of initial applications appears to prove exactly what Kevin stated. I know of a few cases where entities have chosen to create "subordinate" organizations and apply separately for additional multihomed space instead of renumbering in order to work around the limitations in this policy. I would not call what they have done fraudulent since they went to the trouble of creating the actual additional organizations, but, I would say that if the overhead of creating an additional organization is less onerous than the renumbering inflicted by the policy, it's a pretty clear demonstration that the renumbering clause in the policy is problematic.

> Did  ARIN go back  to  the  organizations that received a  /24 under
> 2010-2  more than 12 months ago,  but did not make additional
> allocation requests,   and survey them    to determine if they
> obtained additional IP addresses from another source  following their
> /24 allocation?
> 

I don't believe so, but, this hasn't been done for any other size of assignment, either.

> There is an alternative explanation:  perhaps they did not need more
> IP addresses,
> or   they didn't need them very much.

I know that there are at least some cases where that is not the case.

> 
> If they availed themselves of the new rule and carefully planned for
> the implications, its quite possible they had plans  that would avoid
> the need to renumber within the foreseeable future or make it worth it
> by the time they needed to.
> 

Sure, and I'm sure that's true for SOME organizations, but, definitely not all.

> 
> There really is  no indication the policy has err'd in this case --
> it seems to have been successful,    there is limited routing table
> impact.

Yes, there is indication that the policy erred. Staff provided an indication
from their perspective in the policy experience report. I know of cases where
it has been problematic for organizations personally. I suspect Kevin does
as well, but I will let him speak for himself.

> 
> It is not clear what kind of impact removing the renumbering
> requirement would have on number of applications;   I would anticipate
> the number of  /24  small ISP multihoming applications could increase
> massively,    due to a large number of organizations seeing  removal
> of the renumber requirement as a  reason  to go to ARIN for PI instead
> of upstreams.

If I recall correctly, the renumbering requirement of which we speak is
applied to small multihoming end users and not ISPs, so, I don't think
your argument here holds water.

Yep... Just verified it in NRPM. The requirement in question is contained
in 4.3.2.2 which is part of the 4.3 end user policy. It is not part of the
4.2 ISP policy.

In fact, the ISP policy still requires justification of a /22 to start, even for
small multihomed ISPs. I think there is an exception for the Caribbean,
but, this change would not affect that in any case.

Owen




More information about the ARIN-PPML mailing list