This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[address-policy-wg] new policy proposal (reserve IPv4 space for new architecture)
- Previous message (by thread): [address-policy-wg] new policy proposal (reserve IPv4 space for new architecture)
- Next message (by thread): [address-policy-wg] 2007-06: New Policy Proposal (Global Policy for the Allocationof the Remaining IPv4 Address Space)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Per Heldal
heldal at eml.cc
Tue Jul 31 12:58:22 CEST 2007
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
- Previous message (by thread): [address-policy-wg] new policy proposal (reserve IPv4 space for new architecture)
- Next message (by thread): [address-policy-wg] 2007-06: New Policy Proposal (Global Policy for the Allocationof the Remaining IPv4 Address Space)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]