[arin-discuss] IPv4 allocation conundrum

Sat Apr 17 10:56:49 EDT 2010

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.

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

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.
>>     
>
>   

-- 
Sent from Home (Mac Pro)

Jacob Epstein, Chief Technology Officer
RECOL, LLC - An Internet Solutions Provider
555 Long Wharf Drive, 12th Floor, New Haven, CT 06511
phone: 203.776.4874 fax: 203.776.4943
web: http://www.recol.net
email: jake at recol.com