[ppml] FYI: LACNIC micro-allocation policy approved and implemented

[Forrest]

The rationale behind having a micro-allocation policy for multi-homed 
organizations has been discussed quite a bit on this mailing list in the 
past.  Search through the archives for posts relating to policy 
2002-7.  Here are the key points that stick out in my mind in support of 
it.

- It would reduce waste of IP addresses from people mis-using IP 
addresses, or just plain lying in their justification to get a /20.  I've 
seen web hosting companies assign 50-100 IP addresses to a single 
webserver, even when name based virtual hosting would have worked just 
fine.  Perhaps their customers are demanding their own IP address for 
their website, but I think it's more likely a ploy to show justification 
for a portable allocation.  

- If you're multihomed announcing your routes, you're already adding to 
the number of routes in the global table.  One argument I've heard is that 
a micro-allocation policy will create a new swamp full of space that can't 
be aggregated.  These routes can't be aggregated anyway, otherwise it'll 
basically make multihoming pointless.  Suppose you've got a /24 assigned 
to you from AT&T's 12/8 block.  If providers filter out prefixes longer 
than /20 then it makes your multihoming pretty pointless since they won't 
hear your route.  Create a block of addresses specifically for 
micro-allocations, that everyone will accept /24 and shorter from and 
everyone wins.  Providers can still filter out the garbage more specifics 
from other blocks, while still accepting the longer routes from the 
micro-allocation block.

- It would protect the small multi-homed company from their provider going 
bankrupt and out of business and having to renumber, or from their 
provider "holding them hostage" and charging higher fees, giving poorer 
service, whatever, simply because they know the customer won't leave 
because it's a pain to renumber.  

Nobody is saying that all customers would have to get their allocation 
from the registry.  It would just be nice to at least have the option to 
do so if you're multihomed.  

Forrest


On Mon, 19 May 2003, Einar Bohlin wrote:

> Part of me says this could be interesting to allow
> to happen and watch the results.  But I have think
> about the customers.  I deal with a lot of them.  And the
> overwhelming majority of them do not mind or complain about
> getting nets from us, especially since those nets work just
> fine.  The last time a customer wanted to get their own
> "Class C" from the registry was in 2000 or 2001. This
> includes multihomed customers.
> 
> I think it would be awful for them to consider getting
> nets directly from ARIN.  And it would be even worse for
> them to get nets and subsequently have routing problems that
> we'd have to explain.  And then we'd probably have to renumber these
> guys into our nets anyway for them to get the full routing that
> they want and expect to get.
> 
> It'd be a great disservice to endusers to lead them to ARIN 
> to get nets that are sure to have have routing problems.
> 
> Today endusers have thankfully gotten used to getting their
> nets from their providers.  Assuming we eventually move
> to v6, that won't change.
> 
> I'm open to change, but why change this now?  To me this
> is a giant step backwards.
> 
> Regards,
> 
> Einar Bohlin, IP Analyst
> IP Team - Ashburn Virginia - MCI/UUNET
> 703 886-7362 (VNET 806-7362)
> einar.bohlin at mci.com
> 
> 
> 
> On Mon, 19 May 2003 william at elan.net wrote:
> 
> > From http://lacnic.net/Micro_Asignacion_ipv4_UF_ENG.PDF :
> > 
> > "Micro allocations IPv4 to final users:
> > LACNIC shall micro allocate blocks to end users who prove
> > -Be multi-homed organizations. It is possible to request micro
> > allocation to those users that are to be multi-homed within a month. In
> > this case contract copies should be provided.
> > -(*) Have a sub allocation of a /25 block from it's providers.
> > - Agree to renumber all the assigned blocks within a period of 3
> > months and return all sub allocated space to its original providers.
> > -Provide the subnetworking plans for the next 12 months, including
> > sub-net masks and host numbers on each subnet. Use of VLSM is required.
> > - Description of network topology.
> > - Description of network routing plans including routing protocols to
> > be used and any existing limitations.
> > The minimum block to be allocated will be /24 and the maximum /21. For
> > larger allocations existing policies should be applied. For additional
> > allocations existing policies should be applied.
> > REMARKS: An organization is multi-homed if it receives full-time
> > connectivity from more than one provider, each of them independent from
> > the other. Independent providers are those who provide connectivity
> > independently from the other provider."
> > 
> > For ratification information see http://lacnic.net/en/ratification.html
> > - because the policy is so important to lacnic community LACNIC has 
> > decided for IMMEDIATE implementation of this policy starting May 19th.
> > 
> > Its interesting how this was one of the first policies they approved since 
> > they became independent from ARIN and it took them less then year to do this.
> > And BTW congratulations to ARIN for again becoming the only RIR that does 
> > not have general end-user micro-assignment/allocation policy!
> > 
> > So are we going to wait for now AfriNIC recognition and only then setup 
> > microassignment policy or should we join every other RIR and (in the 
> > spirit of creating unified policies and procedures for all RIRs) actually 
> > adapt an micro-assignment policy - it has been discussed long enough by 
> > now - 10 times longer then at LACNIC for sure :) 
> > 
> > In fact at the last meeting the proposal for micro-assignment policy 2002-3
> > has been presented and afterwards in the vote that followed (vote = show 
> > of hands) an overwhelming majority (something like 10:1 for) have expressed
> > their support in having ARIN adapt such a micro-assignment policy.
> > 
> > So would everybody here like to know what happened and how Advisory Counsil
> > reacted to the vote and to above proposal? Well, I'm going to tell you anyway...
> > 
> > Apparently AC decided that ARIN is not ready to assign even /22 blocks to
> > end users (we aren't like other RIRs you know ...) instead they decided to 
> > completely abandon the policy 2002-3 (!!! After almost full consensus at 
> > the meeting !!!)
> > 
> > Instead AC proposed their own ideas, such as that the current policy where
> > multihomed company that has utilized /22 can request /20 be modified so as 
> > to instead such a company would receive /21 and that this be considered a 
> > micro-assignment to satisify those who want ARIN to do micro-assignments.
> > So let me summarize again - if AC proposal goes through instead of receiving
> > /20 same qualifying companies would instead receive smaller /21 block (!!!)
> > 
> > Consider the above situation carefully when you're voting for next AC (maybe we
> > should just invite LACNIC back into ARIN and vote only lacnic members into AC
> > - they sure know how to get popular proposals approved and implemented fast!).
> > 
> > But since we cant really bring lacnic people and companies back and I do not
> > have much faith that AC would change that much, I would ask you to consider
> > even more the actual proposals that would be presented at the next meeting.
> > I would not be surprised if micro-assignment proposal is back and then it 
> > would be an interesting challenge for BoT to deny a proposal supported at 
> > multiple ARIN meeting and by general public, especially since it seems by
> > next meeting BoT would have legal way of approving a proposal even without 
> > support of AC.
> > 
> > ----
> > William Leibzon
> > (yours truly ppml subsriber who is also at anuncios#lacnic.net list and is 
> >  trying to keep you well informed about important policies announced there
> >  in the spirit of all RIRs having generally unified policies, of course)
> > 
> > 
> 

-- 
Visit my Commodore 64 Website
http://almighty.c64.org/