About RIPE | Contact  | Search | Sitemap    
Homepage RIPE  
RIPE Community Mail Archives
search  
     
RIPE Navigation Ends
About RIPE Maillists
Maillists Archive
Global Lists
Non Active Lists
RIPE NCC Navigation Ends
Next Section

Re: [address-policy-wg] new policy proposal (reserve IPv4 space for new architecture)

  • To: Robin Whittle rw@localhost
  • From: Per Heldal heldal@localhost
  • Date: Tue, 31 Jul 2007 12:58:22 +0200
  • Cc: Address Policy WG address-policy-wg@localhost

On Tue, 2007-07-31 at 10:56 +1000, Robin Whittle wrote:
> Hi Gert,
> 
> Thanks for your response and for changing the subject line.
> 
> I agree this is a difficult proposal to make at present.
> 
> It is early days regarding a "new architecture", but the only
> proposals which involve no host changes and which work for both
> IPv4 and IPv6 are in two classes.  Firstly BGP improvements.
> Secondly,  ITR-ETR tunneling schemes, as a form of "locator-ID
> separation, which are IP-based have nothing directly to do with BGP.
> 
> Unless someone invents a dramatic (several orders of magnitude)
> improvement to BGP regarding the number of prefixes the global
> system can handle, and unless someone invents a totally different
> solution for BGP-less multihoming, portability etc. than the
> ITR-ETR tunneling schemes, then I think one of these IP-based
> ITR-ETR tunneling schemes will be built.
> 
> I guess that some time in the next year or so the BGP proposals
> and one of the IP-based schemes will be given to IETF WGs for
> serious development.

Too little too late. It's awfully hard to operate networks on hot air
and promises;) Even if there was a completed and universally accepted
RFC today we'd probably face at least 5 years until the technology is
widely deployed. 


Has anybody in the RIR community done research and and/or created
statistics about:

How many of those who have recently received v4 allocations were in
possession of under-utilised blocks when the last allocation was made?
(current policies should already prevent that)

What are recently allocated addresses used for (%age of addresses
consumed for end-user-termination, hosting, network infrastructure and
other purposes)?


My point is that I don't think it will make a significant difference to
the overall consumption of addresses if we were able to hand out the
remaining space in smaller chunks. Better utilisation of previously
allocated blocks is always an issue, but there is effectively no
incentive for those with under-utilised blocks to contribute parts of
their resources back to the community. Even if the community would agree
on how to handle previous allocations we don't have the (operational)
mechanism that can be used to impose the same (draconian) rules on all
resource-holders (e.g. route-certificates).


> 
> I imagine that most people would think that these schemes are not
> yet well developed enough to justify locking up address space to
> await their completion.  However, if nothing is done soon, then
> there won't be any fresh space left when the new scheme is ready
> to run.
> 
> I think that the chosen IP-based ITR-ETR tunneling scheme will
> still be used to greatly improve the utilisation of IPv4 space,
> using space which is currently assigned.  So it is not disastrous
> for long-term efficient use of the IPv4 space if no fresh space is
> reserved.  Over time, if the scheme works as well as I think it
> will, a lot of the currently assigned address space would be
> assigned to the new scheme without any need for incentives.

I agree that improved IDR scalability might provide some relief when
there is no more fresh space to allocate from. But do you seriously
expect anyone with say a /16 who only need a /22 or maybe even less to
voluntarily give up the parts they don't use?

> 
> Roque Gagliano wrote:
> 
> > What about using the Class E for this use?
> 
> Can anyone comment on how the installed base of operating systems
> is likely to handle 240.0.0.0/4?  It is not 224.0.0.0/4 multicast,
> but it has never been used.  So I guess there has been no testing
> of how it would be handled.


http://lists.arin.net/pipermail/ppml/2007-April/006679.html

(that thread on the ppml-list spans at least april and may archives)


//per




 

Next Section
     About RIPE | Site Map | LIR Portal | About the RIPE NCC | Contact | © RIPE Community. All rights reserved.
RIPE.NET Homepage LIR Portal RIPE Community