2007-06: New Policy Proposal (Global Policy for the Allocationof the Remaining IPv4 Address Space)
PDP Number: 2007-06 Global Policy for the Allocation of the Remaining IPv4 Address Space Dear Colleagues, A new RIPE Policy has been proposed and is now available for discussion. This policy describes the process for the allocation of the remaining IPv4 space from IANA to the RIRs. When a minimum amount of available space is reached, an identical number of IPv4 allocation units (/8s) will be allocated from IANA to each RIR, replacing the current IPv4 allocation policy. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2007-06.html We encourage you to review this proposal and send your comments to <address-policy-wg@ripe.net> before 27 August 2007. Best regards, Alex Le Heux RIPE NCC Policy Implementation Co-ordinator
I believe that a substantial amount of the remaining IPv4 space should be put aside to be used with whichever new architecture is developed to deal with the routing and addressing problems discussed last year in the IAB RAWS workshop. That new architecture will be able to apply address space much more efficiently in terms of number of end-users, the proportion of IP addresses actually used, and the usefulness of the address space in terms of multihoming and portability without burdening the BGP routing system. This reservation - and perhaps operation of the new system - might best be done by the RIRs. I want to suggest this as part of a debate about how to make best use of the remaining fresh IPv4 space. The RAWS workshop report is: http://tools.ietf.org/html/draft-iab-raws-report http://www.iab.org/about/workshops/routingandaddressing/ Discussions are on the RAM list: http://www1.ietf.org/mail-archive/web/ram/current/ http://www1.ietf.org/mailman/listinfo/ram the IRTF Routing Research Group List: http://psg.com/lists/rrg/2007/ http://www.irtf.org/charter?gtype=rg&group=rrg and a small closed RADIR list with public archives: http://www1.ietf.org/mail-archive/web/radir/current/ http://www3.tools.ietf.org/group/radir/ The central Problem is most frequently summarised as something like: "There needs to be a way many more end-users can do multihoming, traffic engineering and have portable address space without requiring conventional PI space and without adding more advertisements and churn to the global BGP routing table." The urgency now is about IPv4, but IPv6 will have the same troubles whenever it is widely adopted. The solution is most likely to be in two forms, which are quite independent of each other. Firstly some moderate improvements to BGP's scalability and stability are likely to be made. Secondly there is likely to be some IP-level system involving a global network of Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs). These will enable multihoming and portability without involving BGP. The IP-level tunneling proposals to date are LISP-NERD, LISP-CONS, eFIT-APT and my own: Ivip. http://tools.ietf.org/html/draft-farinacci-lisp-01 http://tools.ietf.org/html/draft-lear-lisp-nerd-01 http://tools.ietf.org/html/draft-meyer-lisp-cons-01 http://tools.ietf.org/html/draft-jen-apt-00 http://www.cs.ucla.edu/~lixia/papers/07SIG_IP6WS.pdf http://www.firstpr.com.au/ip/ivip/ These proposals are all intended to apply both to IPv4 and IPv6, not require changes in hosts, and retain reachability from non-upgraded networks. While most of the people in this field are focused on the "multihoming etc. without BGP" problem, I make a direct causal linkage from the limitations of the BGP routing system to the clunky restrictions it places on address allocation (256 address granularity and "Maximise route aggregation!!!"), the consequent low proportion of advertised IPv4 addresses which are actually used and therefore leading to the rapid, premature "exhaustion" of IPv4 space. Each one of these four proposals listed above, if it could be made to work as intended, would enable much finer allocation of address space to end-users, down to single IP addresses (/64s for IPv6 probably). So once one of these systems is operational, IPv4 space will be able to be allocated to end-users in any size, from /32, /31 etc. through /24 etc. with portability, multihoming and no concern whatsoever for "route aggregation". BGP can only do it in /24 granularity - chunks of 256 addresses. Since something like this needs to be built in the next few years, I propose that a substantial amount of the remaining unallocated space be kept for the new system, which can then put it to work, in terms of numbers of end-users and in terms of actual utilisation of IP addresses, *far* more efficiently than BGP can use it. I think many people have become accustomed to the very low rates of utilisation of currently advertised portions of the 3.7 billion address IPv4 space, which is the direct cause of us running out of fresh space well before there are two or three billion IP addresses in use. I don't know how many are used now, but I think it is probably around 200 or maybe 300 million. I found about 108 million respond to ping, which I know has its limitations: http://www.firstpr.com.au/ip/host-density-per-prefix/ Here is my message which proposes some changes to the draft "Problem Statement" from RADIR: http://www1.ietf.org/mail-archive/web/ram/current/msg01773.html along these lines. It considers the IPv4 address shortage as part of the Problem - just as amenable to solution as the "multihoming without BGP" problem. I also think that a new ITR and fast mapping database architecture could provide a tremendous boost to mobile IP, for IPv4 and IPv6, with near optimal path lengths and without requiring changes in correspondent hosts. Of the current proposals, only Ivip could do this. Lack of mobility is not currently a "problem", but I think that since a global ITR network (as all the four IP-level proposals involve) could be used to drastically enhance mobility, that any new architecture should either do this from the start, or at least not preclude extensions in the future which do this. - Robin http://www.firstpr.com.au/ip/ivip/
Hi, (I have changed the subject, as this is a different proposal from 2007-06!) On Mon, Jul 30, 2007 at 11:30:37PM +1000, Robin Whittle wrote:
I believe that a substantial amount of the remaining IPv4 space should be put aside to be used with whichever new architecture is developed to deal with the routing and addressing problems discussed last year in the IAB RAWS workshop.
This is going to be a tough one, for various reasons. - as this is a global change in the way all RIRs are supposed to operate, it needs to be made a global policy - which, in turn, means that all RIR constituencies need to agree to this proposal - which, in turn, means for the RIPE region that you need to submit a formal proposal to the PDP process (http://www.ripe.net/ripe/policies/proposals/index.html) and get consensus that this is the right way to proceed. Adding to this that the "new BGP" is likely not going to happen before the current IPv4 pool has run out, I'm pessimistic whether this proposal will find much support in the communities, or will be seen as "taking away the last remains of IPv4 from those who need/want it". Fortunately, I'm not to judge this, but just to steer the process... Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 113403 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
What about using the Class E for this use? Roque On Mon, 2007-07-30 at 17:43 +0200, Gert Doering wrote:
Hi,
(I have changed the subject, as this is a different proposal from 2007-06!)
On Mon, Jul 30, 2007 at 11:30:37PM +1000, Robin Whittle wrote:
I believe that a substantial amount of the remaining IPv4 space should be put aside to be used with whichever new architecture is developed to deal with the routing and addressing problems discussed last year in the IAB RAWS workshop.
This is going to be a tough one, for various reasons.
- as this is a global change in the way all RIRs are supposed to operate, it needs to be made a global policy
- which, in turn, means that all RIR constituencies need to agree to this proposal
- which, in turn, means for the RIPE region that you need to submit a formal proposal to the PDP process (http://www.ripe.net/ripe/policies/proposals/index.html) and get consensus that this is the right way to proceed.
Adding to this that the "new BGP" is likely not going to happen before the current IPv4 pool has run out, I'm pessimistic whether this proposal will find much support in the communities, or will be seen as "taking away the last remains of IPv4 from those who need/want it".
Fortunately, I'm not to judge this, but just to steer the process...
Gert Doering -- APWG chair --
------------------------------------------------------------- Roque Gagliano ANTEL - URUGUAY rgaglian@antel.net.uy
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. 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. 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. If this space was universally, or almost universally, handled well by operating systems and any other devices (routers, WiFi cameras, NAT software etc.) then it may need only an administrative change to use it for general Internet traffic. But if this is the case, then why wouldn't it be allocated to RIRs in the usual way? Randy Bush wrote:
until the map and encap and other hackers give way to good math folk, we will get nowhere. and there has been zero motion in this direction.
I used to have a gung-ho approach to dragging that slacker protocol BGP into the modern world. Imagine a modern IT system gagging on a few hundred thousand of anything, especially when most of these things don't change from one week to the next! It would be great if you and these bright math people could contribute to the discussion in the Routing Research Group, to soup up BGP or replace it incrementally with something far better. Before doing so, you might like to read my message where I summarise how I came to realise why the performance of the BGP network is unlikely to be drastically improved, at least in terms of the number of prefixes it handles. http://www1.ietf.org/mail-archive/web/ram/current/msg01645.html I try to maintain a list of potential BGP improvements at: http://www.firstpr.com.au/ip/sram-ip-forwarding/#BGP_improvements but the best place to look is the RRG's wiki: http://www3.tools.ietf.org/group/irtf/trac/wiki/RoutingResearchGroup and the IDR WG, for which there are links in my previous message. - Robin http://www.firstpr.com.au/ip/ivip/
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
I believe that a substantial amount of the remaining IPv4 space should be put aside to be used with whichever new architecture is developed to deal with the routing and addressing problems discussed last year in the IAB RAWS workshop.
sure. in a lead-lined concrete vault for our grandchildren. the routing architecture issues the usual suspects are churning have been the same for decades, yes plural. i find the least optimism that they will be resolved by these same folk in my lifetime amusing at best. until the map and encap and other hackers give way to good math folk, we will get nowhere. and there has been zero motion in this direction. randy -- see B. Fortz and M. Thorup. Internet traffic engineering by optimizing OSPF weights. In IEEE INFOCOM, March 2000 for what happens when serious math folk get interested for a few months.
Robin Whittle wrote:
I believe that a substantial amount of the remaining IPv4 space should be put aside to be used with whichever new architecture is developed to deal with the routing and addressing problems discussed last year in the IAB RAWS workshop.
What are the (expected) architectural limitations that (will most likely) prevent deployment of those superiour mechanisms in address space that is in use already? Or the other way 'round, why do we need to set address space aside?
That new architecture will be able to apply address space much more efficiently in terms of number of end-users, the proportion of IP addresses actually used, and the usefulness of the address space in terms of multihoming and portability without burdening the BGP routing system.
Again, I do not grok why unused address space has to be reserved for that regime.
This reservation - and perhaps operation of the new system - might best be done by the RIRs. I want to suggest this as part of a debate about how to make best use of the remaining fresh IPv4 space.
Wilfried.
On Mon, 2007-07-30 at 13:09 +0200, Alex Le Heux wrote:
PDP Number: 2007-06 Global Policy for the Allocation of the Remaining IPv4 Address Space
Dear Colleagues,
A new RIPE Policy has been proposed and is now available for discussion.
This policy describes the process for the allocation of the remaining IPv4 space from IANA to the RIRs. When a minimum amount of available space is reached, an identical number of IPv4 allocation units (/8s) will be allocated from IANA to each RIR, replacing the current IPv4 allocation policy.
The proposal claims to create "certainty on how the remaining space will be allocated". To me it seems the only advantage is to the RIRs with a slow burn-rate who may get space to allocate for 1-2 years longer than the big RIRs. It's not obvious that this makes it easier to predict the exact date of depletion -- for anyone. Nor does it anything to prevent a run on the remaining resources. How can/do you prevent registry-shopping in the period after the first RIRs run out of addresses? To avoid a run between the RIRs to get the last few /8s it might be an idea to hand out at least one /8 to each RIR in the last round. Alternatively one could define a last chunk of /8s to be split between the RIRs according to their burn-rate in the last months leading up to that point. Although impossible, I belive the best would be if all RIRs run out at the exact same time which is the opposite of what the suggested policy aim to achieve. //per
Hi, here my comments. Roque
The proposal claims to create "certainty on how the remaining space will be allocated".
To me it seems the only advantage is to the RIRs with a slow burn-rate who may get space to allocate for 1-2 years longer than the big RIRs. It's not obvious that this makes it easier to predict the exact date of depletion -- for anyone. Nor does it anything to prevent a run on the remaining resources.
It does in the sense that each RIR will know the size of their last allocation.
How can/do you prevent registry-shopping in the period after the first RIRs run out of addresses?
we cant. not just registry shopping but also a secondary market. However when RIRs are involved there are certain policies in place.
To avoid a run between the RIRs to get the last few /8s it might be an idea to hand out at least one /8 to each RIR in the last round.
That is what we are proposing setting N=1. The issue is that as a global policy it needs to be approved by all the RIR, and that takes at least 18 months. If we reach consensus that allocating the last /8s to each RIR make sense, we just need to discuss how big the size of that last allocation should be. We proposed 5x/8, but many people finds that too big. what about N=2 or 3?
Although impossible, I belive the best would be if all RIRs run out at the exact same time which is the opposite of what the suggested policy aim to achieve.
This policy is a global policy only affects how IANA allocates addresses to the RIRs, it does not study each RIR individually. Some RIR allocates a minimum of a /20, other a /22, etc. I believe that if we approved this policy each RIR could discussed more conservative policies and hopefully the RIR pool will never run out (check the "slow landing" proposal at ARIN as an example).
//per
-- ------------------------------------------------------------- Roque Gagliano ANTEL - URUGUAY rgaglian@antel.net.uy
On Mon, 2007-07-30 at 16:35 -0300, Roque Gagliano wrote:
Hi, here my comments. Roque
The proposal claims to create "certainty on how the remaining space will be allocated".
To me it seems the only advantage is to the RIRs with a slow burn-rate who may get space to allocate for 1-2 years longer than the big RIRs. It's not obvious that this makes it easier to predict the exact date of depletion -- for anyone. Nor does it anything to prevent a run on the remaining resources.
It does in the sense that each RIR will know the size of their last allocation.
How can/do you prevent registry-shopping in the period after the first RIRs run out of addresses?
we cant. not just registry shopping but also a secondary market. However when RIRs are involved there are certain policies in place.
To avoid a run between the RIRs to get the last few /8s it might be an idea to hand out at least one /8 to each RIR in the last round.
That is what we are proposing setting N=1. The issue is that as a global policy it needs to be approved by all the RIR, and that takes at least 18 months. If we reach consensus that allocating the last /8s to each RIR make sense, we just need to discuss how big the size of that last allocation should be. We proposed 5x/8, but many people finds that too big. what about N=2 or 3?
The amount of trouble at the time of depletion may turn out to be proportional to N. I.e. the smaller the better. If we are to deviate from the principle of "documented need", I believe it is better to define a last pool of /8s (e.g. 15) that is to be split among the RIRs according to their consumption. Some may get 5 /8s, others only 1, but they'll run out at about the same time. The RIRs provide data wrt their consumption to the NRO which in turn advise IANA/ICANN when it is time to make the final allocation.
Although impossible, I belive the best would be if all RIRs run out at the exact same time which is the opposite of what the suggested policy aim to achieve.
This policy is a global policy only affects how IANA allocates addresses to the RIRs, it does not study each RIR individually. Some RIR allocates a minimum of a /20, other a /22, etc.
The behaviour of individual RIRs is irrelevant unless IANA aspire to dictate RIR policies. If you really want more restrictive policies globally why don't you suggest such directly to each RIR.
I believe that if we approved this policy each RIR could discussed more conservative policies and hopefully the RIR pool will never run out (check the "slow landing" proposal at ARIN as an example).
Suggestions like the "soft landing" proposal in ARIN amount to little more than wishful thinking. Policy-changes may limit the number of smaller blocks and thus affect routing-table-growth. The volume of address-consumption OTOH is tied to growth in the broadband-market on which changes to allocation policies have minimal effect -- unless you go as far as to introduce some form of rationing. //per
Per, On Jul 30, 2007, at 2:11 PM, Per Heldal wrote:
If we are to deviate from the principle of "documented need", I believe it is better to define a last pool of /8s (e.g. 15) that is to be split among the RIRs according to their consumption.
We (actually, Leo) did this exercise internally a while ago. It is a bit challenging to come up with a single answer as the outcome greatly depends on the starting conditions. That is, consumption is quite non-linear and if you choose a recent starting point you'll get a different answer than if you choose a historical starting point. This is further complicated by the fact that it is highly unlikely that current consumption patterns will remain constant over the lifetime of the IPv4 free pool. Of course, we can always close our eyes and pick numbers at semi-random...
I believe that if we approved this policy each RIR could discussed more conservative policies and hopefully the RIR pool will never run out (check the "slow landing" proposal at ARIN as an example).
Suggestions like the "soft landing" proposal in ARIN amount to little more than wishful thinking. Policy-changes may limit the number of smaller blocks and thus affect routing-table-growth. The volume of address-consumption OTOH is tied to growth in the broadband-market on which changes to allocation policies have minimal effect -- unless you go as far as to introduce some form of rationing.
Um. "Soft Landing" is a form of rationing. It increases the requirements for obtaining space as the free pool diminishes, making it harder and harder to obtain new blocks from the registry. In theory, the end effect would be to encourage increased efficiency in the use of IPv4 address space, even amongst broadband providers. Rgds, -drc
participants (8)
-
Alex Le Heux -
David Conrad -
Gert Doering -
Per Heldal -
Randy Bush -
Robin Whittle -
Roque Gagliano -
Wilfried Woeber, UniVie/ACOnet