[ppml] Summary of Trial Balloons for Dealing with IPv4 AddressCountdown

Mon Apr 16 17:34:45 EDT 2007

Dan,

I want to disagree with you on one point... 

> The problem with a size restriction is that is doesn't change demand. It
> will only cause ISP to submit more applications, more often with the end
> result being the same. If you use a million IP for your customers in a
> year, the only difference between two applications in that year or a
> dozen, is the amount of administrative work that is done to process the
> apps.
>
> -Dan

There is another problem, the "end result" is not actually the
same.  While the ISP may end up utilizing the the same amount of space in
both schemes, how it is used internally will be very different.  

When the address space is given out in large blocks, the ISP can divide
up these blocks into reasonably sized pools for each of its internal
regions.  This allows for internal aggregation.  

If instead smaller blocks are given out more frequently, then the regional
pools will be much smaller.  Each subsequent block will be diviided into
regional pools that will not be contiguous with the previous regional
pool.  

This stacking of regional pools will lead to poor internal aggregation,
and thus bloat in the routing and forwarding tables.

__Jason

==========================================================================
Jason Schiller                                               (703)886.6648
Senior Internet Network Engineer                         fax:(703)886.0512
Public IP Global Network Engineering                       schiller at uu.net
UUNET / Verizon                         jason.schiller at verizonbusiness.com

The good news about having an email address that is twice as long is that
it increases traffic on the Internet.

On Fri, 13 Apr 2007, Alexander, Daniel wrote:

> Date: Fri, 13 Apr 2007 14:05:19 -0400
> From: "Alexander, Daniel" <Daniel_Alexander at Cable.Comcast.com>
> To: Iljitsch van Beijnum <iljitsch at muada.com>
> Cc: ppml at arin.net
> Subject: Re: [ppml] Summary of Trial Balloons for Dealing with IPv4
>     AddressCountdown
> 
> Iljitsch,
> 
> Sorry for the late response, but I am having a hard time keeping up with
> this mailing list. I just wanted to clarify a point you made below about
> one of the allocations. Comcast actaully received that address space in
> three installments over an 18 month period. The first was in April of
> 05, with the last piece of the /8 being allocated in 12/06. All ISP,
> regardless of size, are still bound by the timeframe policies in every
> RIR. The size of any ISP's request can only be for what they can
> justifiably use within a certain timeframe. For the ARIN region it is
> currently six months. So while we ended up with the whole /8, we were
> only given it because we actaully put it to use over a now, two year
> time frame.
> 
> The problem with a size restriction is that is doesn't change demand. It
> will only cause ISP to submit more applications, more often with the end
> result being the same. If you use a million IP for your customers in a
> year, the only difference between two applications in that year or a
> dozen, is the amount of administrative work that is done to process the
> apps. 
> 
> -Dan
> 
> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of
> Iljitsch van Beijnum
> Sent: Tuesday, April 03, 2007 2:22 PM
> To: Jim Weyand
> Cc: ppml at arin.net
> Subject: Re: [ppml] Summary of Trial Balloons for Dealing with IPv4
> AddressCountdown
> 
> On 30-mrt-2007, at 23:34, Jim Weyand wrote:
> 
> > I find myself struggling with how to convert the suggestions and 
> > comments on this list into actual policy proposals.
> 
> Perhaps it would be a good idea to see if we can agree on what our goals
> and assumptions are. An important question is whether it's a good idea
> to try and postpone the moment when the RIRs have to turn down requests
> for lack of free address space. Assuming we still have around five
> years, and that a great deal can be accomplished in that time, is it
> worth going through a lot of trouble to buy us a limited number of
> additional years?
> 
> > 4)       Several similar informal proposals to encourage recycling by
> > empowering ARIN to more actively police the use of IPv4 addresses by 
> > various means
> > 6)       An informal proposal to ask holders of unused address IPv4
> > addresses to voluntarily return the addresses
> 
> A "use it or lose it" policy would make sense. Large amounts of address
> space aren't visible on the global internet, so either people aren't
> using it at all, or they're only using it internally. If we set a
> deadline by which address space must be "in use" (hard to
> define) or it will be put at the end of the free list, this gives people
> who are using it for internal purposes a reasonable amount of time to
> move to something else.
> 
> > 7)       Several variants of informal proposals to start assigning  
> > IPv6
> > space with IPv4
> > 8)       An informal proposal to get endusers to demand access to IPv6
> > networks by creating a media storm similar to Y2K.
> 
> The depletion of IPv4 and the adoption of IPv6 are largely orthogonal in
> the short term. Having IPv6 doesn't mean you don't need IPv4 any more,
> not having IPv4 doesn't make IPv6 more useful.
> 
> This is what I suggest:
> 
> In my opinion, it's a problem that the RIRs are giving out extremely
> large blocks of address space to the world's largest ISPs. For instance,
> Softbank has a /8, Comcast got a /8 in two installments and French,
> Deutsche and British Telecom all have multi-million sized blocks. Even
> very large ISPs need some time to put these amounts of address space to
> use, so what happens is that at various intervals, new large blocks are
> requested, so the number of addresses given out in any particular year
> varies widely because one request can be as much as 5 to 10 % of the
> yearly world-wide use. So giving out large blocks makes making
> predictions harder. Another problem is that if and when business stalls,
> a good part of a large block will go unused. For both of these reasons,
> it's a good idea to limit the maximum block size that is given out
> *today*.
> 
> When we start to run out of address space for real, this only gets
> worse, and we run the risk that a large request clears out the remaining
> address space in one go. To avoid this, we should adopt a policy where
> there is a maximum block size, and a minimum interval between obtaining
> address blocks. As the number of addresses left gets smaller, the
> maximum block size is reduced.
> 
> For instance, we could make the maximum block size 2 million and the
> minimum interval 2 months. So if an ISP thinks they need 16 million
> addresses in a year, they'll have request 2 million, wait 2 months,
> request another 2 million and so on.
> 
> In 3 or 4 years, the limit could be half a million, so someone needing
> 16 million addresses would only be able to get 6 x 1/2 million = 3
> million. (Note that people who need smaller blocks still get what they
> need.) The effect is that an ISP who signs up 16 million new users each
> year will then have to share an IPv4 address over several users, where
> the number of users per address increases every year, rather than that
> in year X every user can get their own address and in year Y there's
> nothing left.
> 
> The maximum block size could each year be set to (for instance) the next
> higher CIDR boundary of 0.1% of the remaining IPv4 address space.
> 
> This policy has the important property of being predictable so people
> can plan rolling out new technologies to deal with the IPv4 address
> shortage in ways that fit their business.
> 
> A problem would be that this works per-organization, so it favors
> smaller organizations over larger ones.
> _______________________________________________
> This message sent to you through the ARIN Public Policy Mailing List
> (PPML at arin.net).
> Manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml
> _______________________________________________
> This message sent to you through the ARIN Public Policy Mailing List
> (PPML at arin.net).
> Manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml
> 