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

Wed May 2 12:49:59 EDT 2012

Note the language in 8.3:

"...can demonstrate the need for such resources in the amount which they 
can justify under current ARIN policies..."
-----------------^^^^^^^^^^^^^^^^^^^^^^^^^^^

Current ARIN policies are that small allocations (/24s, /23s) be 
aggregated.  Section 8.3 thus does not give a "free pass" to 
transferring bodies to subvert the aggregation policy - depending on
your point of view, that is.

The real problem is that (in my humble opinion) the AC has moved in
the direction in recent years of approving these very broad, generalized
changes to the NRPM rather than specific changes.

Take for example section 3.6.1.  The AC only permitted that to be passed
AFTER we inserted the clause "...If ARIN staff deems a POC to be..."
because that effectively gives ARIN staff the ability to short-circuit
the entire section - they can decide that an obviously unreachable POC
(obvious to everyone else, that is) is in fact reachable - and thus
excluded from requirements of 3.6.1

The AC seems to find specific restrictions in the NRPM to be a hindrance
to the operation of the RIR and so constantly pushes for more 
generalized language that contains trap-doors that allow the Hostmaster 
more and more discretion to pretty much ignore the NRPM when they feel
like it.  I don't know when they started this policy but it's pretty
obvious when you look at the NRPM history - the sections which are
clear and specific - like 4.3.6.2 - are older.  The Hostmaster has less
leeway there to make exceptions.  But newer sections, like 8.3,
are very wishy-washy and lack specificity and are quite subject to a
variety of interpretations, many of which are contrary to what the
community wanted when the section was put in.  Those sections allow the
Hostmaster a free hand to say this and that about whatever they want.

In essence, power is being transferred from the community to the RIR.
Things like the "emergency action" which got transfers into the NRPM
in the first place, show who holds the real power.

I suppose the answer is "run for AC and then change it if you get on 
there" but it appears to be a requirement of being on the AC to get a
frontal lobotomy. ;-)  Seriously, it seems that once people get on there
they abandon the very principles of doing what is right, for the
principles of doing what "works" or what "pisses off the fewest number 
of people"  even if it's a band-aid that will cause obvious problems 
later.  Kicking the can down the IPv4 road seems to be in style these days.

Section 8.3 is shameful, and I cannot believe that the ARIN community
would have written much less supported something so wishy-washy and
subjective 10 years ago.  A decade ago the RIR actually cared about good
stewardship of IPv4 - today the feeling seems to be to allow IPv4 to get
so messed up that it's unusable and that will force people to switch to 
IPv6.

Ted

On 5/2/2012 7:48 AM, Alexander, Daniel wrote:
> Kevin,
>
> I think your last point is very relevant to this proposal. If
> organizations can obtain /24's through section 8.3 without any renumbering
> requirement, it seems like the goal of aggregation is greatly diminished.
> There is a subtle lever applied here, where it forces those who do not
> want to renumber through section 4.3.6.2 to the transfer market where they
> have to pay for that pass, but it would be interesting to hear if people
> think whether that should be the intended behavior.
>
> If aggregation is so important to require renumbering in section 4.3.6.2,
> why is it not a big deal in section 8.3 which will shortly become the more
> frequently used option?
>
> -Dan Alexander
>
>
> On 4/30/12 9:13 PM, "Kevin Blumberg"<kevinb at thewire.ca>  wrote:
>
>> Jimmy,
>>
>> 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.
>>
>> There is also the issue of compatibility with 8.3 transfers. If an end
>> user were to go to the market for a /24 would they have
>> to return the initial allocation and search for a /23 instead?
>>
>> Thanks,
>>
>> Kevin Blumberg
>>
>>
>>> -----Original Message-----
>>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>>> Behalf Of Jimmy Hess
>>> Sent: Monday, April 30, 2012 7:49 PM
>>> To: ARIN
>>> Cc: arin-ppml at arin.net
>>> Subject: Re: [arin-ppml] ARIN-prop-167 Removal of Renumbering
>>> Requirement for Small Multihomers
>>>
>>> On 4/30/12, ARIN<info at arin.net>  wrote:
>>>
>>> I am opposed to the proposal  that  removes the requirement to renumber,
>>> without also changing the minimum allocation size for small multi-homers
>>> back to /22.
>>>
>>> The "freezing" of ARIN additional assignments is not  an unintended
>>> effect, it
>>> is the express intent of the policy that changed the minimum allocation
>>> from
>>> /22 to /24; those organizations who obtained a
>>> /24 under this policy were aware, or should have been aware of the
>>> restriction,  and had  the option of obtaining address space from an
>>> upstream provider, if renumbering  out of a /24   within a 1 year
>>> period  would be an undue burden for that provider.
>>>
>>> The requirement to renumber  should not be removed from existing /24s
>>> allocated under this policy;   it is a provision that is relevant to
>>> serious concerns about routing table prefix count growth.
>>>
>>>
>>>
>>>
>>>> Rationale:
>>>>
>>>> The policy has had the unintended effect of freezing small multi homed
>>>> end users from being able to return to ARIN for additional
>>> assignments.
>>>> The requirement to renumber out of space is unique and is applying an
>>>> undue burden of renumbering what would be an organization's core
>>>> infrastructure.
>>>
>>>
>>> --
>>> -JH
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to the ARIN
>>> Public Policy Mailing List (ARIN-PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact info at arin.net if you experience any issues.
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.