Policy for allocation of IPv6 address space from IANA to RIRs
Dear Colleagues, The Number Resource Organisation (NRO) has published a proposal for a policy for the allocation of IPv6 address space from the IANA to the RIRs. It is intended that this proposed policy should be agreed by all RIRs' open policy fora and then approved by the ASO and ICANN as a global policy. The proposal is available on our web site at: http://www.ripe.net/ripe/draft-documents/ipv6.html Comment on the proposal is sought. Kind regards, -- leo vegoda Registration Services Manager RIPE NCC
leo, can you explain why the rirs need a time window from the iana (36 months) so much larger than lirs need from the rirs? randy
On Monday 09 August 2004 18:42, Randy Bush wrote:
leo,
can you explain why the rirs need a time window from the iana (36 months) so much larger than lirs need from the rirs?
randy
Randy, I read it that IANA don't see RIR's needing more than a /12 in a 36 month period - thus a /12 would at least meet the RIR's needs for the next 36 months. Seems like a much better idea than faffing about handing out a /23 every few months. Jon
I read it that IANA don't see RIR's needing more than a /12 in a 36 month period - thus a /12 would at least meet the RIR's needs for the next 36 months.
Seems like a much better idea than faffing about handing out a /23 every few months.
i'll be blunt. this apnic proposal is still the same geoff and paul land grab. with the doubling algorithm, the proposal would have all of ipv6 space to the rirs in a few short years. they failed to get all of fp=001 allocated to the rirs in a block, so have a new way to get it in a few pieces. given that fp=001 is supposed to last decades, and we don't know decades of internet governance (what once used to be called stewardship) reliability, this seems unwise. randy
On Wednesday 11 August 2004 00:39, Randy Bush wrote:
i'll be blunt. this apnic proposal is still the same geoff and paul land grab. with the doubling algorithm, the proposal would have all of ipv6 space to the rirs in a few short years.
randy
Yes, doubling does seem unwise. It would make sense (to me anyway) that once xx% of a /12 is allocated then another /12 is issued to the RIR. Jon
It would make sense (to me anyway) that once xx% of a /12 is allocated then another /12 is issued to the RIR.
withholding judgement of the wisdom of a /12, and just using it as an example. it would seem sensible that the xx% be 100% less the expected burn rate for the time it takes to allocate a new block, plus some fudge. i.e. if iana can allocate in a week, then 90% would seem reasonable. if it takes the iana a year, then a much smaller percentile. and before we start throwing stones at the iana, it would be interesting to actually know the mean and variance of queue times of the iana and the various rirs over the last decade. my personal experience would not suggest that anyone could be particularly proud. randy
On Wednesday 11 August 2004 09:18, Randy Bush wrote:
It would make sense (to me anyway) that once xx% of a /12 is allocated then another /12 is issued to the RIR.
withholding judgement of the wisdom of a /12, and just using it as an example. it would seem sensible that the xx% be 100% less the expected burn rate for the time it takes to allocate a new block, plus some fudge. i.e. if iana can allocate in a week, then 90% would seem reasonable. if it takes the iana a year, then a much smaller percentile.
and before we start throwing stones at the iana, it would be interesting to actually know the mean and variance of queue times of the iana and the various rirs over the last decade. my personal experience would not suggest that anyone could be particularly proud.
randy
Those figures would probably be useful and would seem a sensible way of deciding the % which must be allocated before a new block was issued. Rather than a /12 perhaps it ought to be that the RIR's apply to iana for a block of /x size. With /x being expected to last the RIR iro 36 months. Jon
On Wed, Aug 11, 2004 at 09:04:21AM +0100, Jon Lawrence wrote:
Yes, doubling does seem unwise. It would make sense (to me anyway) that once xx% of a /12 is allocated then another /12 is issued to the RIR.
Indeed. I see no point in unconditional doubling. I'm pretty confident that /12 blocks are large enough to serve a RIR long enough so that ordering a new /12 is not hampering anything. My suggestion would be to set aside a /8 per RIR (perhaps also a DNS reverse delegation for that) and allocate /12s to the RIRs upon their request. A RIR qualifies for a new /12 block as soon as nn% usage of the current /12 block is reached. nn might be 50% or more. As Randy suggests, the percentage should be low enough so that the RIRs can get new space without delaying allocation to LIRs (as it happens nowadays). Best regards, Daniel
The issue isn't about allocating a bigger netblock to the RIRs or not, the issue are more how big it should be. Anything bigger than /8 is shooting ourself in the foot and limiting our options when we in 10-20years figure out a much better way to use the address space. Even /12 is overkill but it will last for a while and we don't get more fragmentation of the IPv6 space than we have today with those ridiculous /23 allocation. Allocate maximum one /8 for each RIR and give them a /12 _now_, not in 1 years time! Just stop those /23 allocation... I'm still quite Junior and young compared to most of you, and I have no interest in getting into trouble with IPv6 in some years (20+) similar to what there are today with IPv4 due to we thought we could waste _too_ much of the address space:) ...Not to mention the trouble we for sure will have with regards to how to solve one of the unsolved "problems", multihoming.... just my 2 Euro cents:) (that we in 20+ years will face a situation where IPv6 most likely aren't usable, that's a total different story) On Wed, 11 Aug 2004, Daniel Roesen wrote:
On Wed, Aug 11, 2004 at 09:04:21AM +0100, Jon Lawrence wrote:
Yes, doubling does seem unwise. It would make sense (to me anyway) that once xx% of a /12 is allocated then another /12 is issued to the RIR.
Indeed. I see no point in unconditional doubling. I'm pretty confident that /12 blocks are large enough to serve a RIR long enough so that ordering a new /12 is not hampering anything.
My suggestion would be to set aside a /8 per RIR (perhaps also a DNS reverse delegation for that) and allocate /12s to the RIRs upon their request. A RIR qualifies for a new /12 block as soon as nn% usage of the current /12 block is reached. nn might be 50% or more. As Randy suggests, the percentage should be low enough so that the RIRs can get new space without delaying allocation to LIRs (as it happens nowadays).
Best regards, Daniel
-- ------------------------------ Roger Jorgensen | rogerj@stud.cs.uit.no | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no -------------------------------------------------------
On Wed 11 Aug 2004 15:38, Roger Jorgensen wrote:
no interest in getting into trouble with IPv6 in some years (20+) similar to what there are today with IPv4 due to we thought we could waste _too_ much of the address space:)
The trouble with v4 today is not scarcity. This is largely due to the policy, in recent years, of conservation over aggregation but that has resulted in it's own problems, like large routing tables, un-aggregateable prefixes, etc. I somehow find it hard to envision a situation where IPv6 conservation may become an issue, be it in 20 years or 50 - fragmented address space is IMO the far more pressing issue...
...Not to mention the trouble we for sure will have with regards to how to solve one of the unsolved "problems", multihoming....
Not getting in on this one... Regards, Sascha Luck -- DoO Eirconnect
Hi, On Tue, Aug 10, 2004 at 04:39:20PM -0700, Randy Bush wrote:
I read it that IANA don't see RIR's needing more than a /12 in a 36 month period - thus a /12 would at least meet the RIR's needs for the next 36 months.
Seems like a much better idea than faffing about handing out a /23 every few months.
i'll be blunt. this apnic proposal is still the same geoff and paul land grab. with the doubling algorithm, the proposal would have all of ipv6 space to the rirs in a few short years.
"if they manage to get 50% of it distributed to their LIRs". What makes you assume that this will happen? If I look at the IPv4 address distribution rules of the past 5 years, the trend was clearly towards being more and more conservative. Given the (current) IPv6 policy, I hardly see a way to get a /8 filled (this would be 2^24 /32s, and even 2^12=4096 /20s, which is roughly the number of members the RIRs have - and most of them will certainly not qualify for a /20 any time soon).
they failed to get all of fp=001 allocated to the rirs in a block,
RIPE-261 actually had some clever ideas behind (the binary chop algorithm to make sure even the largest ISPs only need one single v6 prefix), but was refused from the community for other reasons (people wanted to *see* which region a prefix belongs to). A large part of the community seems to be trusting the RIRs a *lot* more than ICANN, btw.
so have a new way to get it in a few pieces. given that fp=001 is supposed to last decades, and we don't know decades of internet governance (what once used to be called stewardship) reliability, this seems unwise.
So am I right in interpreting this as "as we don't know whether the way forward is the right way, let's stop moving altogether"? Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 65398 (60210) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On Wed, Aug 11, 2004 at 11:12:15AM +0200, Gert Doering wrote:
so have a new way to get it in a few pieces. given that fp=001 is supposed to last decades, and we don't know decades of internet governance (what once used to be called stewardship) reliability, this seems unwise.
So am I right in interpreting this as "as we don't know whether the way forward is the right way, let's stop moving altogether"?
I interpret it as "we are driving in fog and don't know the road ahead, lets better wear a safety belt". And I do not see why assigning larger blocks to the RIRs would speed up the IPv6 deployment. I see absolutely no need in assigning gigantic netblocks (like /8s) to the RIRs. The few RIRs now do not at all mean, that there will be only few in 20 years. Then we might have NIRs (N=National). In that case we already need around 150 /8s? Or we might have PIRs (P=planetary)? Or we have something that does not end in IR at all? We should keep organizational scalability in mind as much as technical scalability. Both are equally important, so ignoring one of the two seems like a mistake to me. I would even go so far as to say that in the future most likely the technical scalability issues regarding Address assignment will be smaller then they are today (by looking at the technical improvements regarding possible routing table size over the last 20 years). Nils -- [Bananenweizen] Denn es läuft dem einzigen wichtigen Menschenrecht zuwider, das Deutschland hervorgebracht hat, nämlich dem deutschen Reinheitsgebot. [Harald Zils in de.alt.arnooo]
Hi, On Wed, Aug 11, 2004 at 02:50:51PM +0200, Nils Ketelsen wrote:
so have a new way to get it in a few pieces. given that fp=001 is supposed to last decades, and we don't know decades of internet governance (what once used to be called stewardship) reliability, this seems unwise.
So am I right in interpreting this as "as we don't know whether the way forward is the right way, let's stop moving altogether"?
I interpret it as "we are driving in fog and don't know the road ahead, lets better wear a safety belt". And I do not see why assigning larger blocks to the RIRs would speed up the IPv6 deployment.
I see absolutely no need in assigning gigantic netblocks (like /8s) to the RIRs. The few RIRs now do not at all mean, that there will be only few in 20 years. Then we might have NIRs (N=National). In that case we already need around 150 /8s? Or we might have PIRs (P=planetary)? Or we have something that does not end in IR at all?
Nothing in the proposed policy document prevents this. The /6s is *reserved* for a respective RIR, and will be used if it needs to be. If a RIR never outgrows its /12, the remaining 65 /12s inside the /6 will be never touched. The benefit in carving up the space now is that each RIR will effectively work from one contiguous block (ignoring the 2001::/23 swamp), thus enabling people (who *have* expressed interest in this) to be able to apply filters (of any sort) by region. Besides this, I don't really see a "we will have 150 NIRs on global level" structure - maybe NIRs below the RIR (as APNIC does it, which is a can of worms on its own), but not on global level - such a structure will never be able to come up with anything resembling a global policy (see the last IPv6 policy discussion - it's hard enough with 5 communities that need to come up with something common).
We should keep organizational scalability in mind as much as technical scalability. Both are equally important, so ignoring one of the two seems like a mistake to me. I would even go so far as to say that in the future most likely the technical scalability issues regarding Address assignment will be smaller then they are today (by looking at the technical improvements regarding possible routing table size over the last 20 years).
So what do you propose? Keep the /23-allocation process, which is really annoying larger networks today? Please stop argueing "let's not do that!" without proposals how to achieve the goal: fix the current ICANN -> RIR allocation mess, *AND* build a system that can at least try to achieve "one IPv6 block per LIR" even for LIRs that grow over time (and for that, you need *lots* of address space at the RIR level, to keep some space between LIR allocations). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 65398 (60210) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On Wed, Aug 11, 2004 at 03:37:57PM +0200, Gert Doering wrote:
I see absolutely no need in assigning gigantic netblocks (like /8s) to the RIRs. The few RIRs now do not at all mean, that there will be only few in 20 years. Then we might have NIRs (N=National). In that case we already need around 150 /8s? Or we might have PIRs (P=planetary)? Or we have something that does not end in IR at all?
Nothing in the proposed policy document prevents this.
Sorry, I misunderstood you then. I thought you were proposing to assign a /8 to the RIR directly from start on. I actually like the idea of making the assignments for the current RIRs far apart from each other allowing their block to grow or to assign the space in between to other organizations should it move in this direction. And making assignments that will most likely last for the next 3 years seems to be a reasonable value. Planning further ahead is not making sense anyway, as then we are in the area of wild guessing. So if the ripe can show a need for a /12 in the next 3 years give them one. If they can not, make it a /16 or a /20 or whatever the ripe will need. Same goes for the other RIRs. Nils -- Hast du das auch etwas deutlicher, oder bist du das Orakel von Jena? [Joerg Moeller zu Lutz Donnerhacke in de.admin.net-abuse.news]
Hi, On Wed, Aug 11, 2004 at 04:01:32PM +0200, Nils Ketelsen wrote:
On Wed, Aug 11, 2004 at 03:37:57PM +0200, Gert Doering wrote:
I see absolutely no need in assigning gigantic netblocks (like /8s) to the RIRs. The few RIRs now do not at all mean, that there will be only few in 20 years. Then we might have NIRs (N=National). In that case we already need around 150 /8s? Or we might have PIRs (P=planetary)? Or we have something that does not end in IR at all?
Nothing in the proposed policy document prevents this.
Sorry, I misunderstood you then. I thought you were proposing to assign a /8 to the RIR directly from start on. I actually like the idea of making the assignments for the current RIRs far apart from each other allowing their block to grow or to assign the space in between to other organizations should it move in this direction.
OK, so we are actually agreeing here :-) - I like the proposal as it is (with a /12 for a start). The /8 came up because that would be something I'd like *more* - but I am aware that there is no consensus for that, so the whole discussion is sort of moot. [..]
So if the ripe can show a need for a /12 in the next 3 years give them one. If they can not, make it a /16 or a /20 or whatever the ripe will need. Same goes for the other RIRs.
Having *plenty* of space at the RIR level is useful, because it means "the RIR can leave lots of spare space between LIR allocations", so LIRs can grow without needing to get a new address block. There is no benefit in reducing a RIR to a /16 or /20 - there are really enough /12s out there (even if you assume 150 NIRs plus a PIR). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 65398 (60210) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Hi Leo, I've published this at http://www.ist-ipv6.org/modules.php?op=modload&name=News&file=article&sid=676. Hopefully we can get some more inputs. Not sure if the people not subscribed could post, but I guess your admin people will get the email anyway. Regards, Jordi ---- Original Message ---- From: "leo vegoda" <leo@ripe.net> To: <address-policy-wg@ripe.net> Cc: <ipv6-wg@ripe.net> Sent: Monday, August 09, 2004 5:38 PM Subject: [address-policy-wg] Policy for allocation of IPv6 address space from IANA to RIRs
Dear Colleagues,
The Number Resource Organisation (NRO) has published a proposal for a policy for the allocation of IPv6 address space from the IANA to the RIRs. It is intended that this proposed policy should be agreed by all RIRs' open policy fora and then approved by the ASO and ICANN as a global policy.
The proposal is available on our web site at:
http://www.ripe.net/ripe/draft-documents/ipv6.html
Comment on the proposal is sought.
Kind regards,
********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
On Mon, 9 Aug 2004, leo vegoda wrote:
Dear Colleagues,
The Number Resource Organisation (NRO) has published a proposal for a policy for the allocation of IPv6 address space from the IANA to the RIRs. It is intended that this proposed policy should be agreed by all RIRs' open policy fora and then approved by the ASO and ICANN as a global policy.
The proposal is available on our web site at:
Seems like a good idea. We need to get rid of those ridiculous /23 allocations. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
On 9-aug-04, at 17:38, leo vegoda wrote:
The Number Resource Organisation (NRO) has published a proposal for a policy for the allocation of IPv6 address space from the IANA to the RIRs. It is intended that this proposed policy should be agreed by all RIRs' open policy fora and then approved by the ASO and ICANN as a global policy.
Reserving a /6 for each RIR seems like the other extreme to me. In IPv4 we have around 220 /8s that have been given out to RIRs pretty much one at a time in the past. In IPv6 we effectively have 8 /6s. This means that as a percentage of total available space, the RIRs get more than 25 times more IPv6 space than they've been given IPv4 space in the past, even though a v4 /8 will accommodate at most 16.8M end-user assignments (less in practice) while a v6 /6 allows for AT LEAST 4.4T (yes, that's 10^12) end-user assignments. Now I can see SOME value in trying to have relatively large RIR blocks, but cutting up all non-reserved space so aggressively really doesn't have any upsides, and we never know whether we're going to need any really large blocks in the future. Also, doubling every time is ok for a while, but it pretty much guarantees that you're going to have way too much space on your hands at some point. A more reasonable policy would be: - reserve a /12 for each RIR now (a 4 bit boundary makes DNS delegations easier, I think a /8 is too much but that might work also) - then, for every delegation, give RIRs enough space to each to last a year comfortably - evaluate whether a new delegation is needed every 3 or 4 months, making the time of new delegations easy to predict
Hi, On Tue, Aug 10, 2004 at 09:32:58AM +0200, Iljitsch van Beijnum wrote:
Now I can see SOME value in trying to have relatively large RIR blocks, but cutting up all non-reserved space so aggressively really doesn't have any upsides,
The *big* upside is that you can apply reasonable address distribution algorithms *inside* the RIR blocks, effectively avoiding having to give LIRs two or more allocations if they are growing slowly over time. [..]
- reserve a /12 for each RIR now (a 4 bit boundary makes DNS delegations easier, I think a /8 is too much but that might work also) - then, for every delegation, give RIRs enough space to each to last a year comfortably - evaluate whether a new delegation is needed every 3 or 4 months, making the time of new delegations easy to predict
Please don't introduce additional RIR<->ICANN loops that don't serve ANY benefits except pay bureaucrats. If you want to go with /12s, hand out the /12 per RIR *now*. Fully, without any "reservation". /8s would be better. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 65398 (60210) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On Tue, Aug 10, 2004 at 09:55:04AM +0200, Gert Doering wrote:
If you want to go with /12s, hand out the /12 per RIR *now*. Fully, without any "reservation". /8s would be better.
Repeat the mistakes done in IPv4, only this time by assigning everything to the RIRs instead of directly to the user? Good plan. Has nobody learned from the mistaked made in the past? We can not say if there will be another assigment policy then IANA->RIR->LIR in maybe 20 or 30 years (thats the time IPv6 has a realistic chance to gain real speed). Then the RIRs sit on their /8s wihtout really needing it just like the organizations that got direct assignments today. Nils -- "Wenn alle Stricke reißen, dann häng ich mich auf!" [So gesehen an einer Toilettenwand]
Hi, On Tue, Aug 10, 2004 at 02:21:32PM +0200, Nils Ketelsen wrote:
On Tue, Aug 10, 2004 at 09:55:04AM +0200, Gert Doering wrote:
If you want to go with /12s, hand out the /12 per RIR *now*. Fully, without any "reservation". /8s would be better.
Repeat the mistakes done in IPv4, only this time by assigning everything to the RIRs instead of directly to the user? Good plan. Has nobody learned from the mistaked made in the past?
We *have* learned. Fragmentation is a bad thing.
We can not say if there will be another assigment policy then IANA->RIR->LIR in maybe 20 or 30 years (thats the time IPv6 has a realistic chance to gain real speed).
Then the RIRs sit on their /8s wihtout really needing it just like the organizations that got direct assignments today.
So what? If every RIR is wasting a /8, then we have lost 5/64 out of FP001. Even if we completely mess up FP001, we have 6 more prefixes to get it right, based on "20 or 30 years experience". But we need to *get going* to *gain* that experience, instead of standing still, waiting for enlightenment to happen. These "we must do it right or not do it at all" worries have slowed down IPv6 deployment tremendously in the last years, and have resulted in this wonderful /23 ICANN->RIR allocation policy. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 65398 (60210) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Repeat the mistakes done in IPv4, only this time by assigning everything to the RIRs instead of directly to the user? Good plan. Has nobody learned from the mistaked made in the past?
We can not say if there will be another assigment policy then IANA->RIR->LIR in maybe 20 or 30 years (thats the time IPv6 has a realistic chance to gain real speed).
Then the RIRs sit on their /8s wihtout really needing it just like the organizations that got direct assignments today.
bingo! and i do not buy the assumption that the rirs need no oversight, just as i do not buy that the iana does. and i do not buy that these policy fora mailing lists provide that oversight any more than i buy that the equivalent ones in icann provide the same for the iana. randy
and i do not buy the assumption that the rirs need no oversight, just as i do not buy that the iana does. and i do not buy that these policy fora mailing lists provide that oversight any more than i buy that the equivalent ones in icann provide the same for the iana.
randy
so... where does the needed oversight come from? --bill
Hi, On Tue, Aug 10, 2004 at 05:48:48AM -1000, Randy Bush wrote:
and i do not buy the assumption that the rirs need no oversight, just as i do not buy that the iana does. and i do not buy that these policy fora mailing lists provide that oversight any more than i buy that the equivalent ones in icann provide the same for the iana.
So what are your proposals to improve the system, then? I agree with you that ICANN doesn't work. As for the RIPE NCC, at least in the last few years, things have been reasonably well - not perfect, IPv6 things have been too conservative and too slow, but overall "a situation people can live with". Which is pretty much the most that can be expected from such a sort of "sort-of grass-roots buerocracy". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 65398 (60210) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
and i do not buy the assumption that the rirs need no oversight, just as i do not buy that the iana does. and i do not buy that these policy fora mailing lists provide that oversight any more than i buy that the equivalent ones in icann provide the same for the iana. So what are your proposals to improve the system, then?
what's broken? the rirs watch the lirs. iana watches the rirs. icann watches the iana.
I agree with you that ICANN doesn't work.
you are agreeing with a statement i did not make. i may have 'issues' with the icann, but in general they have not managed to break the internet as much as a lot of other players.
As for the RIPE NCC, at least in the last few years, things have been reasonably well
and in the next few years? things go in cycles. that is why we should be relatively conservative and have oversight and cooperation.
IPv6 things have been too conservative
oh, you have run out of space?
and too slow
i thought you said that ripe was working well?
but overall "a situation people can live with". Which is pretty much the most that can be expected from such a sort of "sort-of grass-roots buerocracy".
i just don't buy the 'grass roots' stuff for the rirs any more than i buy it for icann or the government in washington dc. wake up and smell the coffee; this is not the internet of our youth. randy
Hi, On Tue, Aug 10, 2004 at 10:03:57AM -1000, Randy Bush wrote:
and i do not buy the assumption that the rirs need no oversight, just as i do not buy that the iana does. and i do not buy that these policy fora mailing lists provide that oversight any more than i buy that the equivalent ones in icann provide the same for the iana. So what are your proposals to improve the system, then?
what's broken?
The current mess regarding IPv6 allocations to the RIRs is. People have to wait for 8 weeks for their /20s because RIRs can't issue reasonably-sized address blocks on their own, without having to fallback to ICANN (who are hiding behind a 6-year-old RFC without showing any initiative to get the situation clarified or improved). The /23 allocation granularity is plain ridiculous, which has been voiced *very* clearly by the communities, with just no reaction.
the rirs watch the lirs. iana watches the rirs. icann watches the iana.
And who is watching ICANN?
I agree with you that ICANN doesn't work.
you are agreeing with a statement i did not make. i may have 'issues' with the icann, but in general they have not managed to break the internet as much as a lot of other players.
As who, out of the parties in question would that be, if I may ask?
As for the RIPE NCC, at least in the last few years, things have been reasonably well
and in the next few years? things go in cycles. that is why we should be relatively conservative and have oversight and cooperation.
IPv6 policy, as of today, is more than "releatively" conservative.
IPv6 things have been too conservative oh, you have run out of space?
I haven't, but people tell me that I'm supposed to build hierarchy into my network, give every customer an insanely large address block *and* do all this out of a /32. Which will work for smallish ISPs like us, for the foreseeable future - but the question remains: what is gained by handing out /32s? A chance to reach 2^29 routing table entries (which would be the result if all of FP001 is handed out as /32s)? Being too conservative on address block size which *will* lead to additional routing table entries. Note that I'm not advocating to give each ISP a /12 or even a /16 - but something better balanced (a /24, for example) would be, umm, "better balanced".
and too slow i thought you said that ripe was working well?
Don't misunderstand me on purpose, please. I wrote:
but overall "a situation people can live with". Which is pretty
- by which I meant to say "everbody will be unhappy about details, but the amount of unhappiness is low enough so people don't stand up and shout"
much the most that can be expected from such a sort of "sort-of grass-roots buerocracy".
i just don't buy the 'grass roots' stuff for the rirs any more than i buy it for icann or the government in washington dc. wake up and smell the coffee; this is not the internet of our youth.
I'm not *that* old - when I entered into this, the RIR system was already pretty much existing as it is today. So maybe everything was better in your youth, I don't know. I found a system that is bureocratic, slow, and very hard to move - but it *does* move if people find something important enough (<<< now *this* is something to complain about, people that don't care...), and the bureaucracy *can* be contained. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 65398 (60210) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
IPv6 things have been too conservative oh, you have run out of space?
I haven't, but people tell me that I'm supposed to build hierarchy into my network, give every customer an insanely large address block *and* do all this out of a /32. Which will work for smallish ISPs like us, for the foreseeable future - but the question remains: what is gained by handing out /32s? A chance to reach 2^29 routing table entries (which would be the result if all of FP001 is handed out as /32s)?
Being too conservative on address block size which *will* lead to additional routing table entries.
Note that I'm not advocating to give each ISP a /12 or even a /16 - but something better balanced (a /24, for example) would be, umm, "better balanced".
perhaps allocation should be needs-based as opposed to these fixed blocks? both at the rir and the lir levels. after all, why are we paying for all those hostmasters if not to help make some intelligent decisions? randy
Hi, On Tue, Aug 10, 2004 at 04:44:42PM -0700, Randy Bush wrote:
perhaps allocation should be needs-based as opposed to these fixed blocks? both at the rir and the lir levels. after all, why are we paying for all those hostmasters if not to help make some intelligent decisions?
Unless I'm seriously mistaken, quite a number of people, you among them, are complaining about the high amount of bureaucracy. Now, what is it that you want? *More* bureaucrats, or less of them? Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 65398 (60210) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Hi, On Mon, Aug 09, 2004 at 05:38:03PM +0200, leo vegoda wrote:
Very reasonable draft. - starting with a /12 is "big enough" for the near future (there are a couple of /20 allocation requests in the pipeline, but a /12 can fulfill 128 of them before reaching 50%) - adding individual bits, growing into the /6, ensures that the stuff stays aggregateable-by-region - *if* it should become obvious that a couple of special-case-blocks are required in the future (like 6to4's 2002::/16), this can be taken out of 2000::/6 or 3800::/5. - *if* a new RIR pops up in the not-so-far future, it might become necessary to split up the /6s into /7s or /8s, but this will not do any harm (after all: this is only *reserved*, and filled from the bottom - so until the first RIR fills up a /7, the second half of all /6s will still be completely untouched). Personally, I would tend to start with /8s (instead of /12s), but I know that this is way too radical for the conservative minds out there. Based on that, a /12 is a reasonable compromise. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 65398 (60210) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On Tue, Aug 10, 2004 at 10:16:25AM +0200, Gert Doering wrote: | Hi, | | On Mon, Aug 09, 2004 at 05:38:03PM +0200, leo vegoda wrote: | > http://www.ripe.net/ripe/draft-documents/ipv6.html | | Very reasonable draft. I agree. I have two questions though; 1. Are there no expectations on having more RIRs in the lifespan of the 001 segment of IPv6 space ? ie, will we run out of reserved blocks ? I am very worried we may indeed run out. 2. What's the purpose of "various". Please give some detail about what can and can not fit into this /6. I think that reserving /8s is better than /6s. The DNS issue is one thing, the scalability question in (1) is another. A /8 should be enough for a RIR in the midterm future, if a RIR explodes (IP space wise) they can always be plugged into another /8 in the future. I think this will be a more stable situation than scaling down from /6s to /7s (as Gert suggested). -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim@ipng.nl http://www.ipng.nl/ IPv6 Deployment -----------------------------------------------
Hi, On Tue, Aug 10, 2004 at 11:26:57AM +0200, Pim van Pelt wrote:
I think that reserving /8s is better than /6s. The DNS issue is one thing, the scalability question in (1) is another. A /8 should be enough for a RIR in the midterm future, if a RIR explodes (IP space wise) they can always be plugged into another /8 in the future. I think this will be a more stable situation than scaling down from /6s to /7s (as Gert suggested).
However you label it (/8s that can grow into a /6, or /6s that can be shrunk into /7s, if needed) doesn't make a real difference. The important thing about the "/6 approach" is that the initial /12s (growing to /8s) are allocated with so much room in between that you *can* grow to a /7 or /6, if necessary, and don't have to start a second (or even more) block per RIR. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 65398 (60210) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On 10-aug-04, at 11:31, Gert Doering wrote:
The important thing about the "/6 approach" is that the initial /12s (growing to /8s) are allocated with so much room in between that you *can* grow to a /7 or /6, if necessary, and don't have to start a second (or even more) block per RIR.
Why is that important?
Hi, On Tue, Aug 10, 2004 at 12:03:08PM +0200, Iljitsch van Beijnum wrote:
On 10-aug-04, at 11:31, Gert Doering wrote:
The important thing about the "/6 approach" is that the initial /12s (growing to /8s) are allocated with so much room in between that you *can* grow to a /7 or /6, if necessary, and don't have to start a second (or even more) block per RIR.
Why is that important?
Because you want to avoid fragmentation. Please read up the RIPE-161 thread in the mailing list archives. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 65398 (60210) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On 10-aug-04, at 13:19, Gert Doering wrote:
Why is that important?
Because you want to avoid fragmentation. Please read up the RIPE-161 thread in the mailing list archives.
There is this new thing now. It's called hypertext. It's really cool. (In other words: please supply a link, as this is impossible to find.)
On Tue, Aug 10, 2004 at 01:48:12PM +0200, Iljitsch van Beijnum wrote:
On 10-aug-04, at 13:19, Gert Doering wrote:
Why is that important?
Because you want to avoid fragmentation. Please read up the RIPE-161 thread in the mailing list archives.
There is this new thing now. It's called hypertext. It's really cool.
(In other words: please supply a link, as this is impossible to find.)
There is this new thing now. It's called Google. It's really cool. -- Carlos Morgado <chbm@cprm.net> - Internet Engineering - Phone +351 214146594 GPG key: 0x75E451E2 FP: B98B 222B F276 18C0 266B 599D 93A1 A3FB 75E4 51E2 The views expressed above do not bind my employer.
On 10-aug-04, at 14:17, Carlos Morgado wrote:
(In other words: please supply a link, as this is impossible to find.)
There is this new thing now. It's called Google. It's really cool.
You know what? Don't bother with a link. I'm not wasting my time on old discussions. If you have something to say, say it. Don't say you've said it before, I don't care.
At 10/08/2004 13:48, Iljitsch van Beijnum wrote:
On 10-aug-04, at 13:19, Gert Doering wrote:
Why is that important?
Because you want to avoid fragmentation. Please read up the RIPE-161 thread in the mailing list archives.
There is this new thing now. It's called hypertext. It's really cool.
(In other words: please supply a link, as this is impossible to find.)
It is ripe-261, actually, see http://www.ripe.net/ripe/docs/ipv6-sparse.html. You can find the indes to the RIPE documents store at http://www.ripe.net/ripe/docs/ipv6-sparse.html. cheers, Axel
At 10/08/2004 15:22, Axel Pawlik wrote:
You can find the indes to the RIPE documents store at http://www.ripe.net/ripe/docs/ipv6-sparse.html.
Make that http://www.ripe.net/ripe/docs/index.html. Axel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon, Aug 09, 2004 at 05:38:03PM +0200, leo vegoda wrote:
Very reasonable draft.
- starting with a /12 is "big enough" for the near future (there are a couple of /20 allocation requests in the pipeline, but a /12 can fulfill 128 of them before reaching 50%)
- adding individual bits, growing into the /6, ensures that the stuff stays aggregateable-by-region
Agree. And this also more or less reflects the discussions we have had at least in the RIPE region.
Personally, I would tend to start with /8s (instead of /12s), but I know that this is way too radical for the conservative minds out there. Based on that, a /12 is a reasonable compromise.
I don't think that starting with /8s would give much more benefit. What is not needed is strict and good assignment algorithms inside the RIRs. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQRjQZKarNKXTPFCVEQLx3ACeLTE839wgtEVLeTcpe66mTDUTx/wAn1ym upsVmawRGsPvRgQTHNQ5Myd/ =DG57 -----END PGP SIGNATURE-----
participants (13)
-
Axel Pawlik -
bmanning＠vacation.karoshi.com -
Carlos Morgado -
Daniel Roesen -
Gert Doering -
Iljitsch van Beijnum -
Jon Lawrence -
JORDI PALET MARTINEZ -
Kurt Erik Lindqvist -
leo vegoda -
Nils Ketelsen -
Nils Ketelsen -
Pekka Savola -
Pim van Pelt -
Randy Bush -
Roger Jorgensen -
Sascha Luck