Re: [ipv6-wg@ripe.net] New IPv6 Address Block Allocated to RIPE NCC
Hi, On Mon, Jun 14, 2004 at 05:33:41AM -0700, william(at)elan.net wrote:
On Mon, Jun 14, 2004 at 02:18:01PM +0200, leo vegoda wrote:
The RIPE NCC received the IPv6 address range 2001:4000::/23 from the IANA in June 2004. Unbelievable. Morons. Why?
Because man-months of argueing that "/23 allocations are needlessly fragmenting the RIR address blocks, please allocate a decent size (like a /8)" are just plainly ignored by the ICANN folks. See the RIPE-IPv6 mailing list archives. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On Mon, 14 Jun 2004, Gert Doering wrote:
Hi,
On Mon, Jun 14, 2004 at 05:33:41AM -0700, william(at)elan.net wrote:
On Mon, Jun 14, 2004 at 02:18:01PM +0200, leo vegoda wrote:
The RIPE NCC received the IPv6 address range 2001:4000::/23 from the IANA in June 2004. Unbelievable. Morons. Why?
Because man-months of argueing that "/23 allocations are needlessly fragmenting the RIR address blocks, please allocate a decent size (like a /8)" are just plainly ignored by the ICANN folks.
I'll try to scan through archives when I get a chance, but I've been on this list for some time and have not seen much activity... Personally I don't see anything wrong with IANA reserving /8 for RIPE and specifying so on its page, but I really don't see why it should immedialy allocate that much space, as /8 would be what RIPE needs if half of its current membership requested ipv6 and somehow i dont think this is what is happening, you dont even have 10% of your membership doing it yet... -- William Leibzon Elan Networks william@elan.net
On Mon, Jun 14, 2004 at 05:56:19AM -0700, william(at)elan.net wrote:
Personally I don't see anything wrong with IANA reserving /8 for RIPE and specifying so on its page, but I really don't see why it should immedialy allocate that much space, as /8 would be what RIPE needs if half of its current membership requested ipv6 and somehow i dont think this is what is happening, you dont even have 10% of your membership doing it yet...
I wouldn't see anything wrong with it either except IANA is allocating sequential /23s, not reserving larger blocks for each RIR. (http://www.iana.org/assignments/ipv6-tla-assignments) Now, consider one of the reasons IPv6 hasn't take off yet is there's a bunch of problems created by the geographical aggregation goals. Regards -- 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.
Hi, On Mon, Jun 14, 2004 at 05:56:19AM -0700, william(at)elan.net wrote:
Personally I don't see anything wrong with IANA reserving /8 for RIPE and specifying so on its page, but I really don't see why it should immedialy allocate that much space, as /8 would be what RIPE needs if half of its current membership requested ipv6 and somehow i dont think this is what is happening, you dont even have 10% of your membership doing it yet...
The big advantage of using decent-size blocks is that the respective RIRs can use more efficient distribution algorithms (binary-chop, for example, see RIPE-261) inside their block. Also there is no *reason* for this, except "job security by introducing needless bureaucracy". Conservation is not an issue (there are 64 /8s inside FP 001 - giving each RIR a /8 will leave 59 /8s, with a high chance that the RIRs will not ever come back asking for more), and "we need to make sure that the RIRs know what they are doing" is also a non-issue, regarding the given clue distribution at the ICANN / RIR level. Nobody has ever given a good reason for this insistence on /23 allocations, except that, years ago, the IESG had recommended this (for the initial ICANN -> RIR allocations). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Giving /8's now seems quite practical. On Mon, Jun 14, 2004 at 03:19:37PM +0200, Gert Doering wrote:
Hi,
On Mon, Jun 14, 2004 at 05:56:19AM -0700, william(at)elan.net wrote:
Personally I don't see anything wrong with IANA reserving /8 for RIPE and specifying so on its page, but I really don't see why it should immedialy allocate that much space, as /8 would be what RIPE needs if half of its current membership requested ipv6 and somehow i dont think this is what is happening, you dont even have 10% of your membership doing it yet...
The big advantage of using decent-size blocks is that the respective RIRs can use more efficient distribution algorithms (binary-chop, for example, see RIPE-261) inside their block.
Also there is no *reason* for this, except "job security by introducing needless bureaucracy".
Conservation is not an issue (there are 64 /8s inside FP 001 - giving each RIR a /8 will leave 59 /8s, with a high chance that the RIRs will not ever come back asking for more), and "we need to make sure that the RIRs know what they are doing" is also a non-issue, regarding the given clue distribution at the ICANN / RIR level.
Nobody has ever given a good reason for this insistence on /23 allocations, except that, years ago, the IESG had recommended this (for the initial ICANN -> RIR allocations).
Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081)
SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Hello, /8, /9, /10, /11 or /12, but undoubtably something bigger than /23 is needed *now*! Please look at (these "unusual" assignments): 2001:1600::/31 [NL-LIBERTEL-20030902] 2001:1700::/27 [CH-SUNRISE-20031124] 2001:2000::/20 [EU-TELIANET-20040510] Some guys really did their homework planning their future IPv6 networks and came up with numbers that generated those assignments. When some more people start doing the same task, and achieve the same conclusions, will the RIRs get a new /23 block every week? It really doesnt seem right that the RIRs have to be constantly asking for more space -- and moreover unaggregated blocks, making everybody to mess up with their filters frequently... :-( Regards, Carlos On Mon, 14 Jun 2004, Tim Chown wrote:
Giving /8's now seems quite practical.
On Mon, Jun 14, 2004 at 03:19:37PM +0200, Gert Doering wrote:
Hi,
On Mon, Jun 14, 2004 at 05:56:19AM -0700, william(at)elan.net wrote:
Personally I don't see anything wrong with IANA reserving /8 for RIPE and specifying so on its page, but I really don't see why it should immedialy allocate that much space, as /8 would be what RIPE needs if half of its current membership requested ipv6 and somehow i dont think this is what is happening, you dont even have 10% of your membership doing it yet...
The big advantage of using decent-size blocks is that the respective RIRs can use more efficient distribution algorithms (binary-chop, for example, see RIPE-261) inside their block.
Also there is no *reason* for this, except "job security by introducing needless bureaucracy".
Conservation is not an issue (there are 64 /8s inside FP 001 - giving each RIR a /8 will leave 59 /8s, with a high chance that the RIRs will not ever come back asking for more), and "we need to make sure that the RIRs know what they are doing" is also a non-issue, regarding the given clue distribution at the ICANN / RIR level.
Nobody has ever given a good reason for this insistence on /23 allocations, except that, years ago, the IESG had recommended this (for the initial ICANN -> RIR allocations).
Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081)
SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-06-14, at 15.43, Carlos Friacas wrote:
It really doesnt seem right that the RIRs have to be constantly asking for more space -- and moreover unaggregated blocks, making everybody to mess up with their filters frequently... :-(
So after a hallway discussion yesterday with some people at the NAv6TF meeting, why don't RIPE just apply for a /8 from IANA. From what we could figure there is nothing that prevents RIPE from doing this,p and that would force the discussion. I am all for it. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNCCCKarNKXTPFCVEQKk0gCePMaog9M3iOdYXsxlg3i5JdxDrHAAn11u 2wdgqtYoGEzuIZV5NzZiccpl =bVJ1 -----END PGP SIGNATURE-----
On Wed, 2004-06-16 at 19:23, Kurt Erik Lindqvist wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2004-06-14, at 15.43, Carlos Friacas wrote:
It really doesnt seem right that the RIRs have to be constantly asking for more space -- and moreover unaggregated blocks, making everybody to mess up with their filters frequently... :-(
So after a hallway discussion yesterday with some people at the NAv6TF meeting, why don't RIPE just apply for a /8 from IANA. From what we could figure there is nothing that prevents RIPE from doing this,p and that would force the discussion.
I am all for it.
Or like NIKE says: Just do it. And give ARIN + APNIC + LACNIC + AFRINIC a /8 too. AFRINIC and LACNIC won't be able to 'justify' it that easily but they will *never* (I hope ;) run out, even if every single tree that is still standing in the rainforests get a /64 ;) Greets, Jeroen
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-06-17, at 09.18, Jeroen Massar wrote:
Or like NIKE says: Just do it.
And give ARIN + APNIC + LACNIC + AFRINIC a /8 too. AFRINIC and LACNIC won't be able to 'justify' it that easily but they will *never* (I hope ;) run out, even if every single tree that is still standing in the rainforests get a /64 ;)
Well, the point is that there is nothing to justify. Have each of the RIRs request a /8. Have IANA assign it (after all the iterations between IAB, IANA, IESG, IANA, etc). Done. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNFP5qarNKXTPFCVEQJvQwCgpGo82h6+w3wd+yrLWiov37Ushb8An2EB 24sPOrmC9pXUCBDpqxkO6JUU =67vo -----END PGP SIGNATURE-----
On Thu, 17 Jun 2004, Kurt Erik Lindqvist wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2004-06-17, at 09.18, Jeroen Massar wrote:
Or like NIKE says: Just do it.
And give ARIN + APNIC + LACNIC + AFRINIC a /8 too. AFRINIC and LACNIC won't be able to 'justify' it that easily but they will *never* (I hope ;) run out, even if every single tree that is still standing in the rainforests get a /64 ;)
Well, the point is that there is nothing to justify. Have each of the RIRs request a /8. Have IANA assign it (after all the iterations between IAB, IANA, IESG, IANA, etc). Done.
- - kurtis -
What do we need to see this happen *soon*? 200 signatures? ;-) A chain letter supporting it? If someone able to kick-off this process is reading this, please do it... Thanks, ./Carlos -------------- IPv6 -> http://www.ip6.fccn.pt Wide Area Network Workgroup, CMF8-RIPE, CF596-ARIN FCCN - Fundacao para a Computacao Cientifica Nacional http://www.fccn.pt "Internet is just routes (135072/470), naming (millions) and... people!"
Hi all, My take on this ... I talked this week in Santa Monica to Doug Barton (copied) IANA General Manager. If I didn't misunderstood him, the only reason they are allocating /23 blocks to the RIRs is because they can't do anything on that, unless IETF change it. Actually they are following rules that were designed for the initial allocations, expected only for the 1st 2 years. I believe the document being followed for this is RFC2450 (ftp://ftp.rfc-editor.org/in-notes/rfc2450.txt), authored by Bob Hinden (copied). So the only way for IANA to allocate /8 will be to update RFC2450. Is that right Doug ? If this is the case, I will be interested in helping in the process of updating RFC2450, and I guess also Bob as the original author. I'm also sure some other could volunteer in this community. Bob, what is the trigger or showstopper to update this document, if any ? Actually, I think after having updated RFC2374 with RFC3587, makes a lot of sense, right ? Regards, Jordi ----- Original Message ----- From: "Carlos Friacas" <cfriacas@fccn.pt> To: <ipv6-wg@ripe.net> Sent: Thursday, June 17, 2004 3:59 PM Subject: Re: [ipv6-wg@ripe.net] New IPv6 Address Block Allocated to RIPE NCC
On Thu, 17 Jun 2004, Kurt Erik Lindqvist wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2004-06-17, at 09.18, Jeroen Massar wrote:
Or like NIKE says: Just do it.
And give ARIN + APNIC + LACNIC + AFRINIC a /8 too. AFRINIC and LACNIC won't be able to 'justify' it that easily but they will *never* (I hope ;) run out, even if every single tree that is still standing in the rainforests get a /64 ;)
Well, the point is that there is nothing to justify. Have each of the RIRs request a /8. Have IANA assign it (after all the iterations between IAB, IANA, IESG, IANA, etc). Done.
- - kurtis -
What do we need to see this happen *soon*? 200 signatures? ;-) A chain letter supporting it?
If someone able to kick-off this process is reading this, please do it...
Thanks,
./Carlos -------------- IPv6 -> http://www.ip6.fccn.pt Wide Area Network Workgroup, CMF8-RIPE, CF596-ARIN FCCN - Fundacao para a Computacao Cientifica Nacional http://www.fccn.pt
"Internet is just routes (135072/470), naming (millions) and... people!"
********************************** 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.
Hi, On Sun, Jun 20, 2004 at 01:38:29PM +0200, JORDI PALET MARTINEZ wrote:
I talked this week in Santa Monica to Doug Barton (copied) IANA General Manager. [..] I believe the document being followed for this is RFC2450 (ftp://ftp.rfc-editor.org/in-notes/rfc2450.txt), authored by Bob Hinden (copied).
Indeed, this might be the root of all evil. Section 5.1, the "Sub-TLA" stage (which boils down to /23s). The really bad thing about this is twofold: - this document should have never been written - the IETF shouldn't try to micro-manage the whole registry system, and the IANA shouldn't micro-manage the individual RIRs. - and the fact that ICANN is slavishly following a document that was written in December 1998 and says about itself "the proposed TLA and NLA assignment rules described in this document are intended for the first two years of IPv6 TLA address assignments" without actually *telling* people about the problem, and without getting people to actually *update* these guiding rules, somewhere in the years between 2000 and 2004. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-06-20, at 23.02, Gert Doering wrote:
On Sun, Jun 20, 2004 at 01:38:29PM +0200, JORDI PALET MARTINEZ wrote:
I talked this week in Santa Monica to Doug Barton (copied) IANA General Manager. [..] I believe the document being followed for this is RFC2450 (ftp://ftp.rfc-editor.org/in-notes/rfc2450.txt), authored by Bob Hinden (copied).
Indeed, this might be the root of all evil. Section 5.1, the "Sub-TLA" stage (which boils down to /23s).
The really bad thing about this is twofold:
- this document should have never been written - the IETF shouldn't try to micro-manage the whole registry system, and the IANA shouldn't micro-manage the individual RIRs.
- and the fact that ICANN is slavishly following a document that was written in December 1998 and says about itself "the proposed TLA and NLA assignment rules described in this document are intended for the first two years of IPv6 TLA address assignments" without actually *telling* people about the problem, and without getting people to actually *update* these guiding rules, somewhere in the years between 2000 and 2004.
Agreed. PErhaps the best way forward is simply to move 2450 to historic. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNZ0CKarNKXTPFCVEQJ9zQCfbpyyreq+6lB/7AdBpmbfDuAYFucAoPUT edFJPFSNjfVdP13Yl1yJNfW0 =JEWp -----END PGP SIGNATURE-----
On Mon, Jun 21, 2004 at 07:37:06AM +0200, Kurt Erik Lindqvist wrote:
Agreed. PErhaps the best way forward is simply to move 2450 to historic.
That's not such a bad idea... Tim
I guess if the RFC is there is because IANA requires it, so moving this to historic will not work, instead updating it will do. Doug ? Regards, Jordi ----- Original Message ----- From: "Tim Chown" <tjc@ecs.soton.ac.uk> To: "Kurt Erik Lindqvist" <kurtis@kurtis.pp.se> Cc: "Gert Doering" <gert@space.net>; "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>; <barton@iana.org>; <ipv6-wg@ripe.net>; <hinden@iprg.nokia.com> Sent: Monday, June 21, 2004 9:28 AM Subject: Re: [ipv6-wg@ripe.net] New IPv6 Address Block Allocated to RIPE NCC
On Mon, Jun 21, 2004 at 07:37:06AM +0200, Kurt Erik Lindqvist wrote:
Agreed. PErhaps the best way forward is simply to move 2450 to historic.
That's not such a bad idea...
Tim
********************************** 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.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-06-21, at 09.34, JORDI PALET MARTINEZ wrote:
I guess if the RFC is there is because IANA requires it, so moving this to historic will not work, instead updating it will do.
Help me out here. Why would IANA require it? I don't remember there being an RFC telling IANA how to allocate other resources? What's so special about IPv6 addresses? - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNaVwqarNKXTPFCVEQJrbwCgjpe67yC7v0iD6eEYGyDAUwPI3GoAoIaO mYXgpaVzzofUkOMR/r+oElDC =NOOE -----END PGP SIGNATURE-----
what IANA needs is an RFC where the IETF says something like: "this given prefix (eg IPv6 addresses beginning with bits 001) are to be used for unicast IPv6." How the LIRs get to tell IANA and the RIRs should partition the given space for real world deployment should be subject to architectural constraints and ISP business operations. It is not an IETF role. Joao On 21 Jun, 2004, at 10:01, Kurt Erik Lindqvist wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2004-06-21, at 09.34, JORDI PALET MARTINEZ wrote:
I guess if the RFC is there is because IANA requires it, so moving this to historic will not work, instead updating it will do.
Help me out here. Why would IANA require it? I don't remember there being an RFC telling IANA how to allocate other resources? What's so special about IPv6 addresses?
- - kurtis -
-----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3
iQA/AwUBQNaVwqarNKXTPFCVEQJrbwCgjpe67yC7v0iD6eEYGyDAUwPI3GoAoIaO mYXgpaVzzofUkOMR/r+oElDC =NOOE -----END PGP SIGNATURE-----
Jordi, Doug, On Sun, Jun 20, 2004 at 01:38:29PM +0200, JORDI PALET MARTINEZ wrote:
If I didn't misunderstood him, the only reason they are allocating /23 blocks to the RIRs is because they can't do anything on that, unless IETF change it.
I believe the document being followed for this is RFC2450 (ftp://ftp.rfc-editor.org/in-notes/rfc2450.txt), authored by Bob Hinden (copied).
The only thing that the rfc says is: --- The IANA will assign small blocks (e.g., few hundred) of TLA ID's to registries. The registries will assign the TLA ID's to organizations meeting the requirements for TLA ID assignment. When the registries have assigned all of their TLA ID's they can request that the IANA give them another block. The blocks do not have to be contiguous. --- Note that it doesn't define this block to be a /23 at all. Also, please note the title of the document: 'Proposed TLA and NLA Assignment Rules' (proposals are no rules as far as I understand the english language) and then check out: RFC3587 which explicitly says: --- This document makes RFC 2374 and the TLA/NLA structure historic. --- which should implicitly make rfc2450 obsolete too since TLA/NLA don't exist anymore (How can one have assignment rules for something that doesn't exist?).
So the only way for IANA to allocate /8 will be to update RFC2450. Is that right Doug ?
I would also be very interested whether IANA bases it's criteria on an obsolete document that is only called 'a proposal'. In the mean time, we can still make progress if the registries actually ask for bigger blocks. They will either get them, or get rejected by IANA and we will finally know the reasons. I am more then happy to take this up in the IESG if there is some action needed from our side, but in the mean time, let's first try to get the registries to actually ask for the allocation so that we can actually know whether there is a problem in the first place. David Kessens ---
On Thu, Jun 17, 2004 at 09:18:58AM +0200, Jeroen Massar wrote:
Or like NIKE says: Just do it.
IPv6 history is full of such things that Should Just Happen, but take an indefinite time for no apparent reason. ip6.arpa. 6bone reverse. etc. Assume it's just a motivation issue at the right political places. tim
Quoting "william(at)elan.net" <william@elan.net>:
Personally I don't see anything wrong with IANA reserving /8 for RIPE and specifying so on its page, but I really don't see why it should immedialy allocate that much space, as /8 would be what RIPE needs if half of its current membership requested ipv6 and somehow i dont think this is what is happening, you dont even have 10% of your membership doing it yet...
Yet... That was what they thought until we requested and got a /20. -- amar TeliaSonera ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
participants (11)
-
amar＠telia.net -
Carlos Friacas -
Carlos Morgado -
David Kessens -
Gert Doering -
Jeroen Massar -
Joao Damas -
JORDI PALET MARTINEZ -
Kurt Erik Lindqvist -
Tim Chown -
william(at)elan.net