[arin-discuss] IPv4 allocation conundrum

Sat Apr 17 12:45:09 EDT 2010

On 04/17/2010 07:56 AM, Jacob Epstein wrote:
> Hi Owen,
> 
> Application is also a consideration. For example we assign single or
> ranges of IP and not subnets. This save a lot of space but requires
> larger subnet allocation to application to simplify our core and
> distribution routing.
> 
> For example, our solutions are sold to business so our broadband
> customers receive single static IP via pppoe or pppoa. We then assign
> additional blocks as required. (/30, /29 or /28)
> 
> Our competors assign /29 with their business class. This wasts up to 50%
> or more of space.

I think you're using the term waste quite a bit to liberally. They are
not wasted they are utilized.

> /29 - (gateway, wire, broadcast) = 5 usable. If only one static
> addresses is needed, 7 are wasted.

if you do vrrp you're going to need more than a /30

> Jake
> 
> 
> Owen DeLong wrote:
>> Lee,
>>     In general, the configuration file generator won't help much. The
>> main cost/difficulty of renumbering is not reconfiguring the devices you
>> control. The main cost/difficulty is the number of places where your
>> addresses appear in configuration files not under your control.
>>
>>     Examples include: Firewalls of your partners, VPN terminations at
>> suppliers or customers, etc.
>>
>>     These costs are not in any way linear with address space size.
>> For example, if I have 100 subnets of desktop machines all attached
>> to routers I control, I can trivially renumber those subnets (in IPv6)
>> in a day or two.  OTOH, if I have a subnet that contains 5 VPN
>> concentrators, each of which terminates 100 VPNs, the coordination
>> and cooperation required to renumber one concentrator could
>> take weeks. Renumbering all of them could take months.
>>
>>     To further complicate the matter, renumbering an ISP means
>> renumbering each and every customer of said ISP. Customers
>> generally regard that as a reason to switch to a more stable ISP.
>>
>> Owen
>>
>> On Apr 17, 2010, at 5:15 AM, Lee Howard wrote:
>>
>>  
>>> Thanks to you both for bringing this to the mailing list.  If we need
>>> to make
>>> policy changes, we should move it to the PPML.
>>>
>>> Randy, I'm interested to understand if the upstream providers told
>>> you any
>>> reason for not providing address space?  In North America, that's
>>> unusual.
>>>
>>> Jacob, I'm interested in your topology.  I don't understand your need
>>> for
>>> /23 and /24.
>>>
>>> Generally, renumbering needs to be easier.  It's a major point in
>>> this thread,
>>> in the IPv6 NAT thread, and in many proposals for smaller
>>> Provider-Independent
>>> allocations.  I see a business opportunity for someone to write an
>>> address
>>> management system that will provide updated configuration files for
>>> common
>>> firewalls, DNS servers (forward and reverse), ACLs, VPN consoles, and
>>> monitoring systems.
>>>
>>> Lee
>>>
>>>
>>>
>>> ----- Original Message ----
>>>    
>>>> From: Jacob Epstein <jake at recol.com>
>>>> To: Randy Carpenter <rcarpen at network1.net>
>>>> Cc: arin-discuss at arin.net
>>>> Sent: Sat, April 17, 2010 5:28:26 AM
>>>> Subject: Re: [arin-discuss] IPv4 allocation conundrum
>>>>
>>>> Hi Randy,
>>>>       
>>> I am in a similar situation, but already have a /20 allocation.    
>>>> I can use more public space, but due to our applications which need
>>>> large blocks (/23 and /24) we end up with open space that we can not
>>>> chop up and reallocate. For example our broadband Static IP Space or
>>>> hosting space which are flat and not subnetted. Although we have
>>>> returned /21 of space to our upstreames since our first allocation
>>>> in 2003, we have been denied based on the 80% use of all IP space
>>>> versus allocations based on routing and application.
>>>>       
>>> FYI, we    
>>>> orginally applied for a /19 but were advised to return /21 of space
>>>> and reaply which we did but we denied due to change in policies. So
>>>> is life!
>>>>       
>>> My    
>>>> understanding is that your client should be able qualify for their
>>>> first Arin allocation. They should then work on moving upstream
>>>> provided IP over to the Allocation so that they can return upstream
>>>> space. I haven't seen a rule on this, but its is wise to do so in
>>>> case you lose or want to change upstream providers. Many of us
>>>> change upstream providers to get better deals or move into an
>>>> Exchange Point (IX) peering arrangement.
>>>>       
>>> Has your customer looked at    
>>>> the end user allocation process. Here is a link
>>>>       
>>>    
>>>> href="https://www.arin.net/resources/request/ipv4_initial_assign.html"
>>>> target=_blank      
>>>>> https://www.arin.net/resources/request/ipv4_initial_assign.html
>>>>>         
>>> I    
>>>> did try this in order to open a new datacenter with a /23, and could
>>>> not get that based on utilization of the current /20. It seems the
>>>> process doesn't care about the need. So to get us going, I requested
>>>> a /23 from a new upstream provider to get our business. Later on
>>>> after we are operational, we will migrate some of our /20
>>>> allocation, but its not going to be easy on current customers that
>>>> will have to be assigned new IP addresses. (DNS Changes, VPN
>>>> Changes, Security (Access Control) changes. One customer has 80
>>>> remote offices!
>>>>       
>>> But it seems to me that there has to be a way for smaller    
>>>> providers with no allocations to obtain blocks and then retun
>>>> upstream blocks as part of the process.
>>>>       
>>> Seems that if not, smaller providers starting up or    
>>>> in our case focused on conservation should go away while the large
>>>> telcos and broadband provides either "suck the pool dry" or rest on
>>>> large allocations they got years ago.
>>>>       
>>> So something sounds strange since need upstream blocks to    
>>>> get into the business. The Arin contact seems to be saying no one
>>>> gets their first allocation based on your customer's scenario as I
>>>> read it which is to get the first allocation. Maybe they do not
>>>> qualify for /19 but could for /20 or /21.
>>>>       
>>> FYI, we have been working on IPv6. The new data center will be    
>>>> native IPv6.
>>>>       
>>> Good Luck,
>>>
>>>
>>> Jake
>>>
>>> -- Jacob Epstein, Chief    
>>>> Technology Officer
>>>>       
>>> RECOL, LLC - An Internet Solutions Provider
>>> web:    
>>>> http://www.recol.net
>>>>       
>>> email:    
>>>> href="mailto:jake at recol.com">jake at recol.com
>>>>       
>>>
>>> Randy Carpenter    
>>>> wrote:
>>>> I am working with a new customer who is in a bit of a pickle...
>>>>
>>>> They are an ISP and VoIP provider whose upstream provider wouldn't
>>>> (or couldn't) give them many addresses.
>>>> They resorted to using NATed private IPs for most of their network,
>>>> which is causing problems for their end user customers.
>>>>
>>>> Now that we are working with them, I am trying to find a solution to
>>>> get them public IPs. They are also soon to be multi-homed (They have
>>>> 2 connections, but no BGP yet). As an ISP, it would be best for them
>>>> to have PI space.
>>>>
>>>> The issue is that one of the requirements for getting PI space from
>>>> ARIN is that you are already using Public space that was assigned to
>>>> you from an upstream provider. I spoke with someone from ARIN who
>>>> says there is no way around this. The need around a /19 of space,
>>>> and I cannot find any way to get it for them. The upstream providers
>>>> refuse to give them any.
>>>>
>>>> What can be done about this?  Would would there be a requirement of
>>>> already using someone else's IP space to get your own? That seems
>>>> like a complete waste of time, effort, money, and IPs!
>>>>
>>>>
>>>> -Randy
>>>>
>>>> -- 
>>>> | Randy Carpenter
>>>> | V.P., IT Services
>>>> | First Network Group, Inc.
>>>> | RHCE
>>>> | (419)739-9240, x1
>>>> -- 
>>>>
>>>>
>>>> _______________________________________________
>>>> ARIN-Discuss
>>>> You are receiving this message because you are subscribed to
>>>> the ARIN Discussion Mailing List (
>>>> href="mailto:ARIN-discuss at arin.net">ARIN-discuss at arin.net).
>>>>
>>>> Unsubscribe or manage your mailing list subscription at:
>>>>
>>>> http://lists.arin.net/mailman/listinfo/arin-discuss
>>>> Please contact ymailto="mailto:info at arin.net"
>>>> href="mailto:info at arin.net">info at arin.net if you experience any issues.
>>>>
>>>>
>>>>       
>>> _______________________________________________
>>> ARIN-Discuss
>>> You    
>>>> are receiving this message because you are subscribed to
>>>>       
>>> the ARIN Discussion    
>>>> Mailing List (
>>>> href="mailto:ARIN-discuss at arin.net">ARIN-discuss at arin.net).
>>>>       
>>> Unsubscribe    
>>>> or manage your mailing list subscription at:
>>>>       href="http://lists.arin.net/mailman/listinfo/arin-discuss"
>>>> target=_blank      
>>>>> http://lists.arin.net/mailman/listinfo/arin-discuss
>>>>>         
>>> Please contact    
>>>> ymailto="mailto:info at arin.net"
>>>> href="mailto:info at arin.net">info at arin.net if you experience any issues.
>>>>       
>>>
>>> _______________________________________________
>>> ARIN-Discuss
>>> You are receiving this message because you are subscribed to
>>> the ARIN Discussion Mailing List (ARIN-discuss at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-discuss
>>> Please contact info at arin.net if you experience any issues.
>>>     
>>
>>   
> 
> 