From leo at ripe.net Mon Jun 14 14:18:01 2004 From: leo at ripe.net (leo vegoda) Date: Mon, 14 Jun 2004 14:18:01 +0200 Subject: [ipv6-wg@ripe.net] New IPv6 Address Block Allocated to RIPE NCC Message-ID: Dear Colleagues, The RIPE NCC received the IPv6 address range 2001:4000::/23 from the IANA in June 2004. You may wish to adjust any filters you have in place accordingly. More information on the IP space administered by the RIPE NCC can be found on our web site at: Regards, -- leo vegoda Registration Services Manager RIPE NCC From gert at space.net Mon Jun 14 14:23:46 2004 From: gert at space.net (Gert Doering) Date: Mon, 14 Jun 2004 14:23:46 +0200 Subject: [ipv6-wg@ripe.net] New IPv6 Address Block Allocated to RIPE NCC In-Reply-To: References: Message-ID: <20040614122346.GC6204@Space.Net> Hi, 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. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From gert at space.net Mon Jun 14 14:42:17 2004 From: gert at space.net (Gert Doering) Date: Mon, 14 Jun 2004 14:42:17 +0200 Subject: [ipv6-wg@ripe.net] New IPv6 Address Block Allocated to RIPE NCC In-Reply-To: References: <20040614122346.GC6204@Space.Net> Message-ID: <20040614124217.GI6204@Space.Net> 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 at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From william at elan.net Mon Jun 14 14:56:19 2004 From: william at elan.net (william(at)elan.net) Date: Mon, 14 Jun 2004 05:56:19 -0700 (PDT) Subject: [ipv6-wg@ripe.net] New IPv6 Address Block Allocated to RIPE NCC In-Reply-To: <20040614124217.GI6204@Space.Net> Message-ID: 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 at elan.net From chbm at cprm.net Mon Jun 14 15:17:01 2004 From: chbm at cprm.net (Carlos Morgado) Date: Mon, 14 Jun 2004 14:17:01 +0100 Subject: [ipv6-wg@ripe.net] New IPv6 Address Block Allocated to RIPE NCC In-Reply-To: References: <20040614124217.GI6204@Space.Net> Message-ID: <20040614131701.GA10424@cprm.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 - 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. From gert at space.net Mon Jun 14 15:19:37 2004 From: gert at space.net (Gert Doering) Date: Mon, 14 Jun 2004 15:19:37 +0200 Subject: [ipv6-wg@ripe.net] New IPv6 Address Block Allocated to RIPE NCC In-Reply-To: References: <20040614124217.GI6204@Space.Net> Message-ID: <20040614131937.GM6204@Space.Net> 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 at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From tjc at ecs.soton.ac.uk Mon Jun 14 15:24:15 2004 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Mon, 14 Jun 2004 14:24:15 +0100 Subject: [ipv6-wg@ripe.net] New IPv6 Address Block Allocated to RIPE NCC In-Reply-To: <20040614131937.GM6204@Space.Net> References: <20040614124217.GI6204@Space.Net> <20040614131937.GM6204@Space.Net> Message-ID: <20040614132415.GD2343@login.ecs.soton.ac.uk> 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 at Space.Net > Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 > 80807 Muenchen Fax : +49-89-32356-299 From cfriacas at fccn.pt Mon Jun 14 15:43:08 2004 From: cfriacas at fccn.pt (Carlos Friacas) Date: Mon, 14 Jun 2004 14:43:08 +0100 (WEST) Subject: [ipv6-wg@ripe.net] New IPv6 Address Block Allocated to RIPE NCC In-Reply-To: <20040614132415.GD2343@login.ecs.soton.ac.uk> References: <20040614124217.GI6204@Space.Net> <20040614131937.GM6204@Space.Net> <20040614132415.GD2343@login.ecs.soton.ac.uk> Message-ID: 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 at Space.Net > > Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 > > 80807 Muenchen Fax : +49-89-32356-299 From amar at telia.net Mon Jun 14 21:55:04 2004 From: amar at telia.net (amar at telia.net) Date: Mon, 14 Jun 2004 21:55:04 +0200 Subject: [ipv6-wg@ripe.net] New IPv6 Address Block Allocated to RIPE NCC In-Reply-To: References: Message-ID: <1087242904.40ce0298b1461@webmail.telia.net> Quoting "william(at)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. From kurtis at kurtis.pp.se Wed Jun 16 19:23:17 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Wed, 16 Jun 2004 19:23:17 +0200 Subject: [ipv6-wg@ripe.net] New IPv6 Address Block Allocated to RIPE NCC In-Reply-To: References: <20040614124217.GI6204@Space.Net> <20040614131937.GM6204@Space.Net> <20040614132415.GD2343@login.ecs.soton.ac.uk> Message-ID: -----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----- From jeroen at unfix.org Thu Jun 17 09:18:58 2004 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 17 Jun 2004 09:18:58 +0200 Subject: [ipv6-wg@ripe.net] New IPv6 Address Block Allocated to RIPE NCC In-Reply-To: References: <20040614124217.GI6204@Space.Net> <20040614131937.GM6204@Space.Net> <20040614132415.GD2343@login.ecs.soton.ac.uk> Message-ID: <1087456738.12356.77.camel@segesta.zurich.ibm.com> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 240 bytes Desc: This is a digitally signed message part URL: From kurtis at kurtis.pp.se Thu Jun 17 10:01:38 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Thu, 17 Jun 2004 10:01:38 +0200 Subject: [ipv6-wg@ripe.net] New IPv6 Address Block Allocated to RIPE NCC In-Reply-To: <1087456738.12356.77.camel@segesta.zurich.ibm.com> References: <20040614124217.GI6204@Space.Net> <20040614131937.GM6204@Space.Net> <20040614132415.GD2343@login.ecs.soton.ac.uk> <1087456738.12356.77.camel@segesta.zurich.ibm.com> Message-ID: <8FA8A978-C034-11D8-8CB7-000A95928574@kurtis.pp.se> -----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----- From tjc at ecs.soton.ac.uk Thu Jun 17 10:54:01 2004 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Thu, 17 Jun 2004 09:54:01 +0100 Subject: [ipv6-wg@ripe.net] New IPv6 Address Block Allocated to RIPE NCC In-Reply-To: <1087456738.12356.77.camel@segesta.zurich.ibm.com> References: <20040614124217.GI6204@Space.Net> <20040614131937.GM6204@Space.Net> <20040614132415.GD2343@login.ecs.soton.ac.uk> <1087456738.12356.77.camel@segesta.zurich.ibm.com> Message-ID: <20040617085401.GD735@login.ecs.soton.ac.uk> 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 From cfriacas at fccn.pt Thu Jun 17 15:59:45 2004 From: cfriacas at fccn.pt (Carlos Friacas) Date: Thu, 17 Jun 2004 14:59:45 +0100 (WEST) Subject: [ipv6-wg@ripe.net] New IPv6 Address Block Allocated to RIPE NCC In-Reply-To: <8FA8A978-C034-11D8-8CB7-000A95928574@kurtis.pp.se> References: <20040614124217.GI6204@Space.Net> <20040614131937.GM6204@Space.Net> <20040614132415.GD2343@login.ecs.soton.ac.uk> <1087456738.12356.77.camel@segesta.zurich.ibm.com> <8FA8A978-C034-11D8-8CB7-000A95928574@kurtis.pp.se> Message-ID: 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!" From jordi.palet at consulintel.es Sun Jun 20 13:38:29 2004 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sun, 20 Jun 2004 13:38:29 +0200 Subject: [ipv6-wg@ripe.net] New IPv6 Address Block Allocated to RIPE NCC References: <20040614124217.GI6204@Space.Net> <20040614131937.GM6204@Space.Net> <20040614132415.GD2343@login.ecs.soton.ac.uk> <1087456738.12356.77.camel@segesta.zurich.ibm.com> <8FA8A978-C034-11D8-8CB7-000A95928574@kurtis.pp.se> Message-ID: <46b701c456bb$2015a8e0$8700000a@consulintel.es> 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" To: Sent: Thursday, June 17, 2004 3:59 PM Subject: Re: [ipv6-wg at 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. From gert at space.net Sun Jun 20 23:02:17 2004 From: gert at space.net (Gert Doering) Date: Sun, 20 Jun 2004 23:02:17 +0200 Subject: [ipv6-wg@ripe.net] New IPv6 Address Block Allocated to RIPE NCC In-Reply-To: <46b701c456bb$2015a8e0$8700000a@consulintel.es> References: <20040614124217.GI6204@Space.Net> <20040614131937.GM6204@Space.Net> <20040614132415.GD2343@login.ecs.soton.ac.uk> <1087456738.12356.77.camel@segesta.zurich.ibm.com> <8FA8A978-C034-11D8-8CB7-000A95928574@kurtis.pp.se> <46b701c456bb$2015a8e0$8700000a@consulintel.es> Message-ID: <20040620210217.GE6204@Space.Net> 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 at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From kurtis at kurtis.pp.se Mon Jun 21 07:37:06 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Mon, 21 Jun 2004 07:37:06 +0200 Subject: [ipv6-wg@ripe.net] New IPv6 Address Block Allocated to RIPE NCC In-Reply-To: <20040620210217.GE6204@Space.Net> References: <20040614124217.GI6204@Space.Net> <20040614131937.GM6204@Space.Net> <20040614132415.GD2343@login.ecs.soton.ac.uk> <1087456738.12356.77.camel@segesta.zurich.ibm.com> <8FA8A978-C034-11D8-8CB7-000A95928574@kurtis.pp.se> <46b701c456bb$2015a8e0$8700000a@consulintel.es> <20040620210217.GE6204@Space.Net> Message-ID: <086B46C7-C345-11D8-BBC1-000A95928574@kurtis.pp.se> -----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----- From tjc at ecs.soton.ac.uk Mon Jun 21 09:28:17 2004 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Mon, 21 Jun 2004 08:28:17 +0100 Subject: [ipv6-wg@ripe.net] New IPv6 Address Block Allocated to RIPE NCC In-Reply-To: <086B46C7-C345-11D8-BBC1-000A95928574@kurtis.pp.se> References: <20040614131937.GM6204@Space.Net> <20040614132415.GD2343@login.ecs.soton.ac.uk> <1087456738.12356.77.camel@segesta.zurich.ibm.com> <8FA8A978-C034-11D8-8CB7-000A95928574@kurtis.pp.se> <46b701c456bb$2015a8e0$8700000a@consulintel.es> <20040620210217.GE6204@Space.Net> <086B46C7-C345-11D8-BBC1-000A95928574@kurtis.pp.se> Message-ID: <20040621072817.GC23590@login.ecs.soton.ac.uk> 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 From jordi.palet at consulintel.es Mon Jun 21 09:34:59 2004 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Mon, 21 Jun 2004 09:34:59 +0200 Subject: [ipv6-wg@ripe.net] New IPv6 Address Block Allocated to RIPE NCC References: <20040614131937.GM6204@Space.Net> <20040614132415.GD2343@login.ecs.soton.ac.uk> <1087456738.12356.77.camel@segesta.zurich.ibm.com> <8FA8A978-C034-11D8-8CB7-000A95928574@kurtis.pp.se> <46b701c456bb$2015a8e0$8700000a@consulintel.es> <20040620210217.GE6204@Space.Net> <086B46C7-C345-11D8-BBC1-000A95928574@kurtis.pp.se> <20040621072817.GC23590@login.ecs.soton.ac.uk> Message-ID: <4dd601c45762$42a0ea30$8700000a@consulintel.es> 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" To: "Kurt Erik Lindqvist" Cc: "Gert Doering" ; "JORDI PALET MARTINEZ" ; ; ; Sent: Monday, June 21, 2004 9:28 AM Subject: Re: [ipv6-wg at 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. From jordi.palet at consulintel.es Mon Jun 21 09:52:52 2004 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Mon, 21 Jun 2004 09:52:52 +0200 Subject: [ipv6-wg@ripe.net] Guidelines for ISPs on IPv6 Assignment to Customers Message-ID: <4e5c01c45764$c203c6b0$8700000a@consulintel.es> Hi all, I guess this is interesting for this group ... Guidelines for ISPs on IPv6 Assignment to Customers (http://www.ist-ipv6.org/modules.php?op=modload&name=News&file=article&sid=604) I drafted this document during the last RIPE meeting and asked for inputs, but nothing .... Inputs still welcome ! Regards, Jordi ********************************** 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. From kurtis at kurtis.pp.se Mon Jun 21 10:01:03 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Mon, 21 Jun 2004 10:01:03 +0200 Subject: [ipv6-wg@ripe.net] New IPv6 Address Block Allocated to RIPE NCC In-Reply-To: <4dd601c45762$42a0ea30$8700000a@consulintel.es> References: <20040614131937.GM6204@Space.Net> <20040614132415.GD2343@login.ecs.soton.ac.uk> <1087456738.12356.77.camel@segesta.zurich.ibm.com> <8FA8A978-C034-11D8-8CB7-000A95928574@kurtis.pp.se> <46b701c456bb$2015a8e0$8700000a@consulintel.es> <20040620210217.GE6204@Space.Net> <086B46C7-C345-11D8-BBC1-000A95928574@kurtis.pp.se> <20040621072817.GC23590@login.ecs.soton.ac.uk> <4dd601c45762$42a0ea30$8700000a@consulintel.es> Message-ID: <2432BC58-C359-11D8-BBC1-000A95928574@kurtis.pp.se> -----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----- From Joao_Damas at isc.org Mon Jun 21 10:12:09 2004 From: Joao_Damas at isc.org (Joao Damas) Date: Mon, 21 Jun 2004 10:12:09 +0200 Subject: [ipv6-wg@ripe.net] New IPv6 Address Block Allocated to RIPE NCC In-Reply-To: <2432BC58-C359-11D8-BBC1-000A95928574@kurtis.pp.se> References: <20040614131937.GM6204@Space.Net> <20040614132415.GD2343@login.ecs.soton.ac.uk> <1087456738.12356.77.camel@segesta.zurich.ibm.com> <8FA8A978-C034-11D8-8CB7-000A95928574@kurtis.pp.se> <46b701c456bb$2015a8e0$8700000a@consulintel.es> <20040620210217.GE6204@Space.Net> <086B46C7-C345-11D8-BBC1-000A95928574@kurtis.pp.se> <20040621072817.GC23590@login.ecs.soton.ac.uk> <4dd601c45762$42a0ea30$8700000a@consulintel.es> <2432BC58-C359-11D8-BBC1-000A95928574@kurtis.pp.se> Message-ID: 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----- > From david.kessens at nokia.com Tue Jun 22 01:38:16 2004 From: david.kessens at nokia.com (David Kessens) Date: Mon, 21 Jun 2004 16:38:16 -0700 Subject: [ipv6-wg@ripe.net] New IPv6 Address Block Allocated to RIPE NCC In-Reply-To: <46b701c456bb$2015a8e0$8700000a@consulintel.es> References: <20040614124217.GI6204@Space.Net> <20040614131937.GM6204@Space.Net> <20040614132415.GD2343@login.ecs.soton.ac.uk> <46b701c456bb$2015a8e0$8700000a@consulintel.es> Message-ID: <20040621233816.GA23119@nokia.com> 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 --- From jordi.palet at consulintel.es Tue Jun 22 07:14:01 2004 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Tue, 22 Jun 2004 07:14:01 +0200 Subject: [ipv6-wg@ripe.net] New IPv6 Address Block Allocated to RIPE NCC References: <20040614131937.GM6204@Space.Net> <20040614132415.GD2343@login.ecs.soton.ac.uk> <1087456738.12356.77.camel@segesta.zurich.ibm.com> <8FA8A978-C034-11D8-8CB7-000A95928574@kurtis.pp.se> <46b701c456bb$2015a8e0$8700000a@consulintel.es> <20040620210217.GE6204@Space.Net> <086B46C7-C345-11D8-BBC1-000A95928574@kurtis.pp.se> <20040621072817.GC23590@login.ecs.soton.ac.uk> <4dd601c45762$42a0ea30$8700000a@consulintel.es> <2432BC58-C359-11D8-BBC1-000A95928574@kurtis.pp.se> <2coend6z07.fsf@oban.autonomica.net> <40D6FFA0.7030206@icann.org> Message-ID: <01af01c45817$bc237930$640a0a0a@consulintel.es> Hi Doug, Thanks for your reply. This means basically that the process should be started by ASO or IAB or any of them ? Updating the RFC isn't an option ? My guess is that the updated could be backed up by the IAB. The main point is HOW to kick-off the process ... Regards, Jordi ---- Original Message ---- From: "Doug Barton" To: "Johan Ihren" Cc: "Kurt Erik Lindqvist" ; "JORDI PALET MARTINEZ" ; ; Sent: Monday, June 21, 2004 5:32 PM Subject: Re: [ipv6-wg at ripe.net] New IPv6 Address Block Allocated to RIPE NCC > Johan Ihren wrote: >> Kurt Erik Lindqvist writes: >> >> >>>> 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? >> >> >> The lesson learned here is that IANA allocation policy based on >> numbers specified in an RFC caused problems once. Then updating the >> RFC to get around the problem is broken. That's just pushing the >> problem out of sight with a clear promise of it coming back to bite us >> sometime in the future. >> >> Moving the RFC to historic is one half of the solution. The other half >> is IANA standing on their own legs (together with the NRO) on these >> matters. > > Thank you for including me in this discussion. Rather than attempting to > correct details of the history described in this thread (and which even > if I was right it wouldn't matter too much since they happened before I > took my current position in December of 2003) I would like to suggest a > way forward. > > The current membership of the Internet Architecture Board (IAB) has > expressed an interest in the direction in which IPv6 allocation policy > proceeds. ICANN thinks that this interest is perfectly reasonable, and > welcomes it, as well as their valuable insight on the relevant issues. > > My position on this issue has been clearly stated on numerous occasions > going back to January of this year. It is not IANA's job to create > policy. We will however be glad to participate in a discussion that is > designed to lead to a policy, offering our unique perspective. > > An excellent example of how this process probably should work is the > IPv4 global allocation policy that was developed in cooperation between > the RIRs and IANA back in July 2003. > http://www.ripe.net/ripe/draft-documents/iana-rir-allocation-policies.html > That policy subsequently went through the policy fora in all 4 regions, > and is currently awaiting finalization through the ASO process. > > A similar process needs to occur in relationship to IPv6 allocation > policy on a global level. ICANN and the IAB stand ready to enter into > such discussions, and eagerly await such an invitation from the RIRs. > > Between now and the time that such a policy is created, IANA's position > is that it is not appropriate for us to attempt to be "creative" in this > area. > > Doug ********************************** 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. From kurtis at kurtis.pp.se Tue Jun 22 07:41:13 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Tue, 22 Jun 2004 07:41:13 +0200 Subject: [ipv6-wg@ripe.net] New IPv6 Address Block Allocated to RIPE NCC In-Reply-To: <01af01c45817$bc237930$640a0a0a@consulintel.es> References: <20040614131937.GM6204@Space.Net> <20040614132415.GD2343@login.ecs.soton.ac.uk> <1087456738.12356.77.camel@segesta.zurich.ibm.com> <8FA8A978-C034-11D8-8CB7-000A95928574@kurtis.pp.se> <46b701c456bb$2015a8e0$8700000a@consulintel.es> <20040620210217.GE6204@Space.Net> <086B46C7-C345-11D8-BBC1-000A95928574@kurtis.pp.se> <20040621072817.GC23590@login.ecs.soton.ac.uk> <4dd601c45762$42a0ea30$8700000a@consulintel.es> <2432BC58-C359-11D8-BBC1-000A95928574@kurtis.pp.se> <2coend6z07.fsf@oban.autonomica.net> <40D6FFA0.7030206@icann.org> <01af01c45817$bc237930$640a0a0a@consulintel.es> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-06-22, at 07.14, JORDI PALET MARTINEZ wrote: > The main point is HOW to kick-off the process ... RIPE NCC sends in the request for a /8. Easy. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA+AwUBQNfGfKarNKXTPFCVEQJIPgCYoagt3FzG/Rwg8STE5pJu+jsIqgCgogIM KabIKcSeBFSxYuFVFYN66f0= =bn9r -----END PGP SIGNATURE----- From barton at icann.org Mon Jun 21 17:32:48 2004 From: barton at icann.org (Doug Barton) Date: Mon, 21 Jun 2004 08:32:48 -0700 Subject: [ipv6-wg@ripe.net] New IPv6 Address Block Allocated to RIPE NCC In-Reply-To: <2coend6z07.fsf@oban.autonomica.net> References: <20040614131937.GM6204@Space.Net> <20040614132415.GD2343@login.ecs.soton.ac.uk> <1087456738.12356.77.camel@segesta.zurich.ibm.com> <8FA8A978-C034-11D8-8CB7-000A95928574@kurtis.pp.se> <46b701c456bb$2015a8e0$8700000a@consulintel.es> <20040620210217.GE6204@Space.Net> <086B46C7-C345-11D8-BBC1-000A95928574@kurtis.pp.se> <20040621072817.GC23590@login.ecs.soton.ac.uk> <4dd601c45762$42a0ea30$8700000a@consulintel.es> <2432BC58-C359-11D8-BBC1-000A95928574@kurtis.pp.se> <2coend6z07.fsf@oban.autonomica.net> Message-ID: <40D6FFA0.7030206@icann.org> Johan Ihren wrote: > Kurt Erik Lindqvist writes: > > >>>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? > > > The lesson learned here is that IANA allocation policy based on > numbers specified in an RFC caused problems once. Then updating the > RFC to get around the problem is broken. That's just pushing the > problem out of sight with a clear promise of it coming back to bite us > sometime in the future. > > Moving the RFC to historic is one half of the solution. The other half > is IANA standing on their own legs (together with the NRO) on these > matters. Thank you for including me in this discussion. Rather than attempting to correct details of the history described in this thread (and which even if I was right it wouldn't matter too much since they happened before I took my current position in December of 2003) I would like to suggest a way forward. The current membership of the Internet Architecture Board (IAB) has expressed an interest in the direction in which IPv6 allocation policy proceeds. ICANN thinks that this interest is perfectly reasonable, and welcomes it, as well as their valuable insight on the relevant issues. My position on this issue has been clearly stated on numerous occasions going back to January of this year. It is not IANA's job to create policy. We will however be glad to participate in a discussion that is designed to lead to a policy, offering our unique perspective. An excellent example of how this process probably should work is the IPv4 global allocation policy that was developed in cooperation between the RIRs and IANA back in July 2003. http://www.ripe.net/ripe/draft-documents/iana-rir-allocation-policies.html That policy subsequently went through the policy fora in all 4 regions, and is currently awaiting finalization through the ASO process. A similar process needs to occur in relationship to IPv6 allocation policy on a global level. ICANN and the IAB stand ready to enter into such discussions, and eagerly await such an invitation from the RIRs. Between now and the time that such a policy is created, IANA's position is that it is not appropriate for us to attempt to be "creative" in this area. Doug -- Doug Barton General Manager, The Internet Assigned Numbers Authority