[ipv6-wg@ripe.net] New Document available: RIPE-343
[apologies for duplicate e-mails] New RIPE Document Announcement -------------------------------------- A revised document is available from the RIPE document store. Ref: ripe-343 Title: IPv6 Address Space Management Author: Paul Wilson, Raymond Plzak, Axel Pawlik Date: 22 February 2005 Format: PS=53986 TXT=13567 Obsoletes: ripe-261 Short content description ------------------------- This document provides the management process for IPv6 global unicast address space whereby address allocations are made from a single global pool according to a "sparse allocation" algorithm. In this version, previously published as ripe-261, we fixed an error in the 6-bit address space table. Accessing the RIPE document store --------------------------------- You can access the RIPE documents in HTML format via our website at the following URL:. http://www.ripe.net/docs/ipv6-sparse.html The RIPE Document Store is also available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-343.pdf PDF version ftp://ftp.ripe.net/ripe/docs/ripe-343.txt plain text version Kind Regards, RIPE NCC Document Announcement Service
[apologies for duplicate e-mails]
New RIPE Document Announcement -------------------------------------- A revised document is available from the RIPE document store.
Ref: ripe-343 Title: IPv6 Address Space Management Author: Paul Wilson, Raymond Plzak, Axel Pawlik Date: 22 February 2005 Format: PS=53986 TXT=13567 Obsoletes: ripe-261
as this document is far from new, and did not fly well the last time it tried to take off, is there something i am missing about why it is being republished now? randy
On Wed, 23 Feb 2005, Randy Bush wrote:
New RIPE Document Announcement Ref: ripe-343 Title: IPv6 Address Space Management Author: Paul Wilson, Raymond Plzak, Axel Pawlik Date: 22 February 2005
as this document is far from new, and did not fly well the last time it tried to take off,
At first reaction, this seems like an improvement over the idea of IANA hoarding the enormous space while an RIR has to achieve 80% use of its allocation. (Improvement in that it favours the primary goal of promoting aggregation - while not, in a way that is obvious to me, harming the other goals of the allocation policy.) A couple of questions : 1) Which parts of the community rejected the doc in its previous incarnation and why? 2) Why is IANA not a co-author - only the RIRs? Best regards. -- David Corking Principal, Corking Project http://www.ecademy.com/account.php?id=42611
Hi, On Wed, Feb 23, 2005 at 12:35:52PM +0000, David Corking wrote:
On Wed, 23 Feb 2005, Randy Bush wrote:
New RIPE Document Announcement Ref: ripe-343 Title: IPv6 Address Space Management Author: Paul Wilson, Raymond Plzak, Axel Pawlik Date: 22 February 2005
as this document is far from new, and did not fly well the last time it tried to take off,
At first reaction, this seems like an improvement over the idea of IANA hoarding the enormous space while an RIR has to achieve 80% use of its allocation. (Improvement in that it favours the primary goal of promoting aggregation - while not, in a way that is obvious to me, harming the other goals of the allocation policy.)
A couple of questions :
1) Which parts of the community rejected the doc in its previous incarnation and why?
It was mostly disliked because of the use of a global common address pool, which means that you give up any chance to be able to filter/aggregate on region boundaries ("why do I need to know any details about ASes located outside my region?") - whether or not someone is doing this today doesn't matter, but it was felt that it shouldn't be made impossible right from the start. The consensus was to that we want ICANN to hand over reasonable chunks of address space (/12, /8, ...) to the individual RIRs, but that we don't want a "common pool". There is a new proposal out there since last summer, which tries to get consensus in all regions about the specifics, and then change the policy. The whole discussion can be found in the mailing list archives of the address policy mailing list, on www.ripe.net.
2) Why is IANA not a co-author - only the RIRs?
ICANN/IANA has been very passive and very resistive regarding any attempts to make the IANA->RIR allocations more reasonable. For many years now. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
On 23-feb-05, at 14:14, Gert Doering wrote:
1) Which parts of the community rejected the doc in its previous incarnation and why?
It was mostly disliked because of the use of a global common address pool, which means that you give up any chance to be able to filter/aggregate on region boundaries ("why do I need to know any details about ASes located outside my region?") - whether or not someone is doing this today doesn't matter, but it was felt that it shouldn't be made impossible right from the start.
I'm sorry, but I have to object here. The notion that divvying up the globe into four or five parts in order to save on routing table expenditures in nonsense. Either filtering out "far away" information is a good idea, and then we should do it right, or it isn't, and then we don't need to do it at all. By doing it right I mean putting several layers of geographical hierarchy into addresses. In Europe, this would mean at least the country level, in large countries like the US, China and India the state/province level.
2) Why is IANA not a co-author - only the RIRs?
ICANN/IANA has been very passive and very resistive regarding any attempts to make the IANA->RIR allocations more reasonable. For many years now.
They've been hesitant to change things in the absence of a new policy. Now that the IANA is more closely related to the ICANN they're probably getting an overdose of lawyer exposure... About the new document: this is unnecessarily complex, and it suffers from terrible end-game properties: when the space starts to run out (which isn't as unthinkable as it seems with the H/R thing, especially if we end up with several new RIRs and/or a middle layer of NIRs) the space will be fragmented very badly. Just give RIRs tightly stacked /12 allocations, or at most /10s. That's 2048 - 8192 times more than they were getting until recently. If this turns out unworkably small at less than 1000 IPv6 ASes then there is a bug in the system somewhere that we'd better fix before the other 17000 ASes start doing v6 too.
On Wed, 23 Feb 2005, Iljitsch van Beijnum wrote:
On 23-feb-05, at 14:14, Gert Doering wrote:
1) Which parts of the community rejected the doc in its previous incarnation and why?
It was mostly disliked because of the use of a global common address pool, which means that you give up any chance to be able to filter/aggregate on region boundaries ("why do I need to know any details about ASes located outside my region?") - whether or not someone is doing this today doesn't matter, but it was felt that it shouldn't be made impossible right from the start.
I'm sorry, but I have to object here.
The notion that divvying up the globe into four or five parts in order to save on routing table expenditures in nonsense. Either filtering out "far away" information is a good idea, and then we should do it right, or it isn't, and then we don't need to do it at all.
By doing it right I mean putting several layers of geographical hierarchy into addresses. In Europe, this would mean at least the country level, in large countries like the US, China and India the state/province level.
Geo-addressing, I think it would be a great idea! next step would be geographical based routing... even better. -- ------------------------------ Roger Jorgensen | rogerj@stud.cs.uit.no | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no -------------------------------------------------------
hi, On Wed, Feb 23, 2005 at 02:41:19PM +0100, Iljitsch van Beijnum wrote: [..]
The notion that divvying up the globe into four or five parts in order to save on routing table expenditures in nonsense.
Thanks for your kind words.
Either filtering out "far away" information is a good idea, and then we should do it right, or it isn't, and then we don't need to do it at all.
By doing it right I mean putting several layers of geographical hierarchy into addresses. In Europe, this would mean at least the country level, in large countries like the US, China and India the state/province level.
That's not contradicting what I said: "People did not like RIPE-261 because of the common address pool". whether you dislike the CAP because you want continental, country level, or whatever other distribution system, doesn't really change the statement "people didn't like the CAP, and so there was consensus against 261". Which is all this thread is about. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Feb 23, 2005, at 13:35, David Corking wrote:
2) Why is IANA not a co-author - only the RIRs?
Why would they be? The IANA does not decide on policy AFAIK. Actually they implement the policy that is defined for them in RFC an alike. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQiDL1qarNKXTPFCVEQL5PACg3UrktYrSokbOykp1A02VVdX2tI4AoKti Ir/u/hceAPWsdHxFLNcpLWxY =Aqz8 -----END PGP SIGNATURE-----
Hi Randy! You asked:
is there something i am missing about why it is being republished now?
The following diff may shed some light. You will see that only one character has changed! --- ripe-261.txt 2005-02-23 12:49:18.000000000 +0000 +++ ripe-343.txt 2005-02-23 12:48:11.000000000 +0000 @@ -4,8 +4,9 @@ Raymond Plzak Axel Pawlik -Document ID: ripe-261 -Date: 31 October 2002 +Document ID: ripe-343 +Date: 22 February 2005 +Obsoletes: ripe-261 Abstract @@ -116,7 +117,7 @@ 1 000000 00 2 100000 32 3 010000 16 - 4 110000 38 + 4 110000 48 5 001000 08 6 101000 40 7 011000 24 -- David Corking Principal, Corking Project "Total Project Management for your supply chain technology" http://www.ecademy.com/account.php?id=42611
Hi, On Tue, Feb 22, 2005 at 01:06:09PM +0100, RIPE NCC Document Announcement Service wrote:
New RIPE Document Announcement -------------------------------------- A revised document is available from the RIPE document store.
Ref: ripe-343 Title: IPv6 Address Space Management Author: Paul Wilson, Raymond Plzak, Axel Pawlik Date: 22 February 2005 Format: PS=53986 TXT=13567 Obsoletes: ripe-261
I am with Randy in this - why on earth is the NCC bothering in re-releasing this document, if only a single line has changed, and people do not *want* this document anyway? It will create quite some confusion, and create the illusion that this is something "new", something people will need to read, think about, comment about, and so on - which just wastes precious brain cycles. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
participants (7)
-
David Corking -
Gert Doering -
Iljitsch van Beijnum -
Kurt Erik Lindqvist -
Randy Bush -
RIPE NCC Document Announcement Service -
Roger Jorgensen