[ipv6-wg@ripe.net] 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 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
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 (9)
-
Axel Pawlik -
Carlos Morgado -
Gert Doering -
Iljitsch van Beijnum -
Kurt Erik Lindqvist -
leo vegoda -
Pekka Savola -
Pim van Pelt -
Randy Bush