From webmaster at ripe.net Thu May 1 16:01:03 2003 From: webmaster at ripe.net (RIPE NCC WebMaster) Date: Thu, 01 May 2003 16:01:03 +0200 Subject: [lir-wg] General Meeting 2003 announcement Message-ID: <200305011401.h41E13Ss025355@birch.ripe.net> [Apologies for duplicate mails] Dear Colleagues, The RIPE NCC Executive Board has announced that the 2003 annual General Meeting will be held adjacent to the RIPE 46 Meeting in Amsterdam from 14.00 to 17.00 on Friday, 5 September 2003. It is hoped that this new date will enable more of the RIPE NCC membership to attend, and participate in, the annual General Meeting. For more information about RIPE NCC annual General Meetings, please see: http://www.ripe.net/ripencc/about/gm/ Regards, Axel Pawlik, Managing Director RIPE NCC From peter.galbavy at knowtion.net Thu May 1 17:33:04 2003 From: peter.galbavy at knowtion.net (Peter Galbavy) Date: Thu, 1 May 2003 16:33:04 +0100 Subject: [lir-wg] Re: [local-ir@ripe.net]General Meeting 2003 announcement References: <200305011401.h41E13Ss025355@birch.ripe.net> Message-ID: <00e101c30ff6$f5762d00$2029a8c0@cblan.mblox.com> RIPE NCC WebMaster wrote: > The RIPE NCC Executive Board has announced that the 2003 annual > General Meeting will be held adjacent to the RIPE 46 Meeting in > Amsterdam from 14.00 to 17.00 on Friday, 5 September 2003. Thanks for listening on the matter of co-hosting the AGM with a RIPE meeting. Now, could someone please point me, off list, to the rules and processes that govern how the RIPE AGM is undertaken ? As per my previous e-mails, I intend - if personal circumstances allow - to attend this year and to express my (and others) opposition to the current charging model and pricing. I want to make sure that any points, motions etc. are done correctly before hand, so that technicalities will not get in the way of the matter at hand. I am not a civil servant, professional beauracrat or academic, so I would appreciate a 'laymans guide' to the RIPE AGM process. rgds, -- Peter Galbavy Knowtion Ltd. From daniel.karrenberg at ripe.net Thu May 1 22:37:57 2003 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 1 May 2003 22:37:57 +0200 Subject: [lir-wg] Re: [local-ir@ripe.net]General Meeting 2003 announcement In-Reply-To: <00e101c30ff6$f5762d00$2029a8c0@cblan.mblox.com> References: <200305011401.h41E13Ss025355@birch.ripe.net> <00e101c30ff6$f5762d00$2029a8c0@cblan.mblox.com> Message-ID: <20030501203757.GB8867@guest-wv-56.ripe.net> On 01.05 16:33, Peter Galbavy wrote: > > Now, could someone please point me, off list, to the rules and processes > that govern how the RIPE AGM is undertaken ? ... > > I am not a civil servant, professional beauracrat or academic, so I would > appreciate a 'laymans guide' to the RIPE AGM process. [On-list so that everyone can benefit] The 'laymens guide' is http://www.ripe.net/ripe/docs/ripe-161.html The 'lawyer version' is http://www.ripe.net/ripe/docs/ripe-176.html Daniel From andrea at inet.it Mon May 5 10:00:15 2003 From: andrea at inet.it (Andrea Borgato) Date: Mon, 05 May 2003 10:00:15 +0200 Subject: [lir-wg] Draft Agenda for RIPE 45 Message-ID: <5.1.0.14.2.20030505092343.10c5f120@pop.inet.it> Dear Working Group, I apologize for delay to post draft agenda for the upcoming working group. Please get in touch with me as soon as possible, if I missed out some items on the Agenda. Thanks to Leo for supporting us in Agenda composing process. Best Regards, Andrea Borgato lir-wg co-chair -- Draft Agenda for RIPE 45 Tuesday, 13 16:00 - 17:30 Wednesday, 14 09:00 - 10:30 Chair: Hans Peter Hollen Co-chairs: Gert Doring, Andrea Borgato A. Session start and welcome - the mobile telephones are switched to vibrate B. Agenda Bashing C. RIPE 44 mins + Actions D. Report from RIPE NCC Registration Services presentation by Leo Vegoda E. ICAN ASO Address Council Report F. Working Group name - Rob Blokzijl proposal: Replace LIR WG into "RIPE address policy WG" and "RIPE NCC services WG" G. Policy Issues - The Policy Development Process - PI Address Policy - report from PI-TF - Discussion of ripe-261 "IPv6 Address Space Management" - Discussion of changes to the common IPv6 policy H. Status attribute values (hope to have a draft document for discussion) I. Presentation of PKI infrastructure for secure communication between members and RIPE NCC (Shane Kerr). X. AOB Y. Summary of actions arising from this meeting. Z. Open Microphone ----------------------------------------------------------------------- For current issues, please turn to the LIR Working Group mailing list archives at: http://www.ripe.net/ripe/mail-archives/lir-wg/index.html More information about this working group is located at: http://www.ripe.net/ripe/wg/lir/index.html ----------------------------------------------------------------------- From andrea at inet.it Tue May 6 10:54:12 2003 From: andrea at inet.it (Andrea Borgato) Date: Tue, 06 May 2003 10:54:12 +0200 Subject: [lir-wg] Update - Draft Agenda for RIPE 45 Message-ID: <5.1.0.14.2.20030506105130.126c17f0@pop.inet.it> Dear Working Group, an update on G.3 point Paul Wilson of APNIC volunteered to do the presentation on ripe-261. Best Regards, Andrea Borgato lir-wg co-chair -- Draft Agenda for RIPE 45 Tuesday, 13 16:00 - 17:30 Wednesday, 14 09:00 - 10:30 Chair: Hans Peter Hollen Co-chairs: Gert Doring, Andrea Borgato A. Session start and welcome - the mobile telephones are switched to vibrate B. Agenda Bashing C. RIPE 44 mins + Actions D. Report from RIPE NCC Registration Services presentation by Leo Vegoda RIPE NCC E. ICAN ASO Address Council Report F. Working Group name - Rob Blokzijl proposal: Replace LIR WG into "RIPE address policy WG" and "RIPE NCC services WG" G. Policy Issues - The Policy Development Process - PI Address Policy - report from PI-TF - Discussion of ripe-261 "IPv6 Address Space Management" Presentation by Paul Wilson APNIC. - Discussion of changes to the common IPv6 policy H. Status attribute values (hope to have a draft document for discussion) I. Presentation of PKI infrastructure for secure communication between members and RIPE NCC (Shane Kerr). X. AOB Y. Summary of actions arising from this meeting. Z. Open Microphone ----------------------------------------------------------------------- For current issues, please turn to the LIR Working Group mailing list archives at: http://www.ripe.net/ripe/mail-archives/lir-wg/index.html More information about this working group is located at: http://www.ripe.net/ripe/wg/lir/index.html ----------------------------------------------------------------------- -- Andrea Borgato E-Mail: a.borgato at inet.it I.NET - Registration Services Operations Manager Phone : +39 02 32863.1 Via Darwin, 85 I-20019 Sett.mo Milanese, Milan, Italy Fax : +39 02 32863.7701 From leo at ripe.net Tue May 6 15:30:24 2003 From: leo at ripe.net (leo vegoda) Date: Tue, 6 May 2003 15:30:24 +0200 Subject: [lir-wg] Summary of PI Task Force Discussion Message-ID: <1FADACcwj7t+Ew+p@ripe.net> Dear Colleagues, At RIPE 44, earlier this year, the LIR WG formed a Task Force to investigate possible changes to the current policy for assigning Provider Independent (PI) IPv4 address space. The Task Force's discussion is summarised below. The discussion started with a provocative statement that the concept of PI address space is broken. It was also noted that the current policy requires assignment of space that may not be globally routeable as the prefix length will be filtered. This space may be suitable for networks that do not need to be globally routed but can be inconvenient for others. There was support for the continued availability of PI address space to End Users - and a recognition that IXPs and root DNS servers do require PI address space. Nonetheless, there were worries that liberalising the policy by having a minimum prefix length for PI assignments could result in an increase in the number of requests for PI address space and a consequent increase in the size of the IPv4 DFZ. One particular concern was that those not qualifying for a /24 of PA may would request a /24 of PI, instead. Finally, it was noted that if the policy for assigning PI address space is changed the usage hurdle for new LIRs to receive a first allocation should be reviewed, too. No consensus for a recommendation to change the existing policy was reached. Regards, -- leo vegoda RIPE NCC Registration Services From axel.pawlik at ripe.net Wed May 7 16:49:38 2003 From: axel.pawlik at ripe.net (Axel Pawlik) Date: Wed, 07 May 2003 16:49:38 +0200 Subject: [lir-wg] New Functionality on the LIR Portal Message-ID: <5.2.0.9.2.20030507164658.03f21590@localhost> [Apologies for duplicate mails.] Dear Colleagues, We are pleased to announce added functionality to the LIR Portal, the web interface that provides LIRs with increased access to the RIPE NCC. As part of an ongoing commitment to security and reliability we have deployed our own Public Key Infrastructure (PKI) within the LIR Portal. Members can generate an X.509 certificate and then use it to access the LIR Portal in a secure and seamless manner. More information on PKI can be found in the draft document "Improved Secure Communication System for RIPE NCC Members" found at: http://www.ripe.net/ripe/draft-documents/pki-20030429.html The LIR Portal also includes an Allocation Editor. The Allocation Editor allows an LIR to update specific fields, including contact information, within an allocation inetnum object without having to contact a RIPE NCC Hostmaster. This feature will allow LIRs to make these changes much faster than in the past. Finally, you will find a new section on the LIR Portal entitled "Tools" that presents a collection of useful member tools and utilities. This section includes: Online Meeting Registration Whois Queries Online Bill Payment Ticket Information and Status IPCount Password Encryption RIS Queries Online Training Registration More features will be added to the LIR Portal to enhance ease of use, manipulation of data and easy access to the RIPE NCC's services. We welcome your feedback. Comments on these and other features of the LIR Portal should be sent to . Kind regards, Axel Pawlik From andrea at inet.it Wed May 7 18:16:53 2003 From: andrea at inet.it (Andrea Borgato) Date: Wed, 07 May 2003 18:16:53 +0200 Subject: [lir-wg] Update - Draft Agenda for RIPE 45 Message-ID: <5.1.0.14.2.20030507181336.02187c00@pop.inet.it> Dear Working Group, I add one more issue on G. point: Presentation by David Kessens on the IPv6 policy editorial commitee short Discussion Best Regards, Andrea Borgato lir-wg co-chair -- Draft Agenda for RIPE 45 Tuesday, 13 16:00 - 17:30 Wednesday, 14 09:00 - 10:30 Chair: Hans Peter Holen Co-chairs: Gert Doring, Andrea Borgato A. Session start and welcome - the mobile telephones are switched to vibrate B. Agenda Bashing C. RIPE 44 mins + Actions D. Report from RIPE NCC Registration Services presentation by Leo Vegoda RIPE NCC E. ICAN ASO Address Council Report F. Working Group name - Rob Blokzijl proposal: Replace LIR WG into "RIPE address policy WG" and "RIPE NCC services WG" G. Policy Issues - The Policy Development Process - PI Address Policy - report from PI-TF - Discussion of ripe-261 "IPv6 Address Space Management" Presentation by Paul Wilson APNIC. - Discussion of changes to the common IPv6 policy - Presentation by David Kessens on the IPv6 policy editorial commitee short Discussion H. Status attribute values (hope to have a draft document for discussion) I. Presentation of PKI infrastructure for secure communication between members and RIPE NCC (Shane Kerr). X. AOB Y. Summary of actions arising from this meeting. Z. Open Microphone ----------------------------------------------------------------------- For current issues, please turn to the LIR Working Group mailing list archives at: http://www.ripe.net/ripe/mail-archives/lir-wg/index.html More information about this working group is located at: http://www.ripe.net/ripe/wg/lir/index.html ----------------------------------------------------------------------- -- Andrea Borgato E-Mail: a.borgato at inet.it I.NET - Registration Services Operations Manager Phone : +39 02 32863.1 Via Darwin, 85 I-20019 Sett.mo Milanese, Milan, Italy Fax : +39 02 32863.7701 -- Andrea Borgato E-Mail: a.borgato at inet.it I.NET - Registration Services Operations Manager Phone : +39 02 32863.1 Via Darwin, 85 I-20019 Sett.mo Milanese, Milan, Italy Fax : +39 02 32863.7701 From chapuis at ip-plus.net Wed May 7 20:14:46 2003 From: chapuis at ip-plus.net (Andre Chapuis) Date: Wed, 7 May 2003 20:14:46 +0200 Subject: [lir-wg] Allocations editor Message-ID: <008401c314c4$8ad5f890$82f380a4@dede> Axel, cool stuff ! However, the field i would like to update is the descr: one. (Company name change, ISP1 gone bankrupt, ISP2 bought by ISP3, etc...) I think adding that field would be appreciated and useful. Cheers, Andr? From leo at ripe.net Wed May 7 21:07:52 2003 From: leo at ripe.net (leo vegoda) Date: Wed, 7 May 2003 21:07:52 +0200 Subject: [lir-wg] Allocations editor In-Reply-To: <008401c314c4$8ad5f890$82f380a4@dede> References: <008401c314c4$8ad5f890$82f380a4@dede> Message-ID: <20030507190752.GA14834@ripe.net> Hi Andre, On Wed, May 07, 2003 at 08:14:46PM +0200, Andre Chapuis wrote: > Axel, cool stuff ! > However, the field i would like to update is the descr: one. (Company name change, ISP1 gone bankrupt, ISP2 bought by ISP3, etc...) > > I think adding that field would be appreciated and useful. We're glad you like the new features. The reason the "descr:" attribute values cannot be updated via the LIR Portal is that we need to know when the situations you describe occur. That way we can make sure all our internal records are kept up to date, too. When you need to update the "descr:" attribute please mail us at and we'll make the changes for you. Incidentally, if you want to add free text comments you can add and edit "remarks:" attributes via the Allocation Editor. Many thanks, -- leo vegoda RIPE NCC Registration Services From hank at att.net.il Thu May 8 08:13:59 2003 From: hank at att.net.il (Hank Nussbacher) Date: Thu, 08 May 2003 08:13:59 +0200 Subject: [lir-wg] New Functionality on the LIR Portal In-Reply-To: <5.2.0.9.2.20030507164658.03f21590@localhost> Message-ID: <5.1.0.14.2.20030508081202.01048b30@max.att.net.il> At 04:49 PM 07-05-03 +0200, Axel Pawlik wrote: Can someone point me to where the tools section is located? I am not finding it. Thanks, -Hank >Finally, you will find a new section on the LIR Portal entitled "Tools" >that presents a collection of useful member tools and utilities. This >section includes: > >Online Meeting Registration >Whois Queries >Online Bill Payment >Ticket Information and Status >IPCount >Password Encryption >RIS Queries >Online Training Registration From leo at ripe.net Thu May 8 10:20:24 2003 From: leo at ripe.net (leo vegoda) Date: Thu, 8 May 2003 10:20:24 +0200 Subject: [lir-wg] New Functionality on the LIR Portal In-Reply-To: <5.1.0.14.2.20030508081202.01048b30@max.att.net.il> References: <5.2.0.9.2.20030507164658.03f21590@localhost> <5.1.0.14.2.20030508081202.01048b30@max.att.net.il> Message-ID: Hi Hank, Hank Nussbacher writes: >At 04:49 PM 07-05-03 +0200, Axel Pawlik wrote: > >Can someone point me to where the tools section is located? I am not >finding it. It is the button below "Tickets" in the column of buttons on the left of the page. There is a gap below it and then the "Change Password" button. Kind regards, -- leo vegoda RIPE NCC Registration Services From augustas at balt.net Fri May 9 11:09:10 2003 From: augustas at balt.net (Augustas Gutautas) Date: Fri, 9 May 2003 12:09:10 +0300 Subject: [lir-wg] Allocation Editor Message-ID: <200305091209.10873.augustas@balt.net> Hello, is there a possibility to add an additional mnt-lower attribute in an allocation inetnum object through lirportal`s Allocation Editor? Can`t I find this or should RIPE-NCC team add it? -- Augustas Gutautas UAB "Baltnetos komunikacijos" Galvyd?io g. 5, Vilnius Tel. 2745444 Fax. 2745440 Mob. 8614 63487 http://www.balt.net From leo at ripe.net Fri May 9 13:22:31 2003 From: leo at ripe.net (leo vegoda) Date: Fri, 9 May 2003 13:22:31 +0200 Subject: [lir-wg] Allocation Editor In-Reply-To: <200305091209.10873.augustas@balt.net> References: <200305091209.10873.augustas@balt.net> Message-ID: Hi Augustas, Augustas Gutautas writes: >Hello, > >is there a possibility to add an additional mnt-lower attribute in an >allocation inetnum object through lirportal`s Allocation Editor? >Can`t I find this or should RIPE-NCC team add it? The Allocation Editor does let you add multiple mnt-lower attributes if you want to do so. Below is a link to the help page for the Allocation Editor that explains how to go through the steps to update an allocation object (once you've logged into the Portal): https://lirportal.ripe.net/lirportal/liruser/resource_editor/help.html I hope this helps you. Best regards, -- leo vegoda RIPE NCC Registration Services From lance at uklinux.net Fri May 9 14:34:53 2003 From: lance at uklinux.net (Lance Davis) Date: Fri, 9 May 2003 13:34:53 +0100 (BST) Subject: [lir-wg] lir-portal In-Reply-To: Message-ID: I just tried to create an X.509.PKI cert, using ie version 5, when I have selected ie as the browser, it then comes up with a popup for the 'cryptographic provider' that is empty, and the button to generate certificate gives an error - Object doesnt support this property or method 'encoder.HashAlgorithm' The offending line is :- encoder.HashAlgorithm = "MD5" Any ideas ??? Regards Lance -- uklinux.net - The ISP of choice for the discerning Linux user. From leo at ripe.net Fri May 9 14:46:32 2003 From: leo at ripe.net (leo vegoda) Date: Fri, 9 May 2003 14:46:32 +0200 Subject: [lir-wg] Re: lir-portal In-Reply-To: References: Message-ID: Hi Lance, Lance Davis writes: > >I just tried to create an X.509.PKI cert, using ie version 5, when I have >selected ie as the browser, it then comes up with a popup for the >'cryptographic provider' that is empty, and the button to generate >certificate gives an error - Object doesnt support this property or method >'encoder.HashAlgorithm' > >The offending line is :- > >encoder.HashAlgorithm = "MD5" We'll contact you off list to help resolve your problem. If you have feature requests or support need then please send them to . Thanks, -- leo vegoda RIPE NCC Registration Services From manuel at ripe.net Fri May 9 16:31:10 2003 From: manuel at ripe.net (Manuel Valente) Date: Fri, 9 May 2003 16:31:10 +0200 Subject: [lir-wg] lir-portal In-Reply-To: References: Message-ID: <20030509163110.26e2e503.manuel@ripe.net> Lance, On Fri, 9 May 2003 13:34:53 +0100 (BST) Lance Davis wrote: > > I just tried to create an X.509.PKI cert, using ie version 5, when I > have selected ie as the browser, it then comes up with a popup for the > 'cryptographic provider' that is empty, and the button to generate > certificate gives an error - Object doesnt support this property or > method 'encoder.HashAlgorithm' > > The offending line is :- > > encoder.HashAlgorithm = "MD5" > > Any ideas ??? This is a known error of IE. Microsoft Hotfix Q323172 or equivalent is required to use IE to request your certificate. See Microsoft Security Bulletin MS02-048 for details. http://www.microsoft.com/technet/security/bulletin/MS02-048.asp Please proceed with caution - RIPE NCC does not assume any responsability over the consequences of applying this patch. Regards, -- Manuel Valente - Software Manager - RIPE NCC From meeting at ripe.net Tue May 13 15:50:08 2003 From: meeting at ripe.net (RIPE NCC Meeting Registration) Date: Tue, 13 May 2003 15:50:08 +0200 Subject: [lir-wg] Webcast RIPE 45 Announcement Message-ID: <200305131350.h4DDo8A0010960@birch.ripe.net> Dear Colleages, Please note that several sessions at RIPE 45 are being webcast. These sessions include the following: - - EOF - - Routing Working Group - - LIR Working Group - - Tools Working Group - - The RIPE NCC Services BoF - - IPv6 Working Group - - Database Working Group - - Plenary To see the meeting in real time, please use one of the following URLs. As we have limited bandwith to the meeting venue, we ask that you choose a server that is physically closer to you: - - RIPE Meeting Attendees only: mms://webcast.ripemtg.ripe.net/ripemtg - - Spain Mirror: mms://media.rediris.es/ripelive - - Portugal Mirror: mms://wms.fccn.pt/ripelive - - Italy Mirror: mms://stream1-wg.cineca.it/ripelive - - Denmark Mirror: mms://wmslave.fsknet.dk/ripelive - - Czech Republic Mirror: mms://server1.streaming.cesnet.cz/ripemtg - - United Kingdom Mirror: mms://ccs-web2k.brynmill.swan.ac.uk/ripelive - - Netherlands Mirror: mms://stream-ripe.wind.surfnet.nl/ripelive - - Amsterdam Mirror (RIPE NCC Office): mms://webcast.ripe.net/ripemtg Please note that the webcastings are technical trials only and the broadcasts should not be regarded as an official implementation of a webcasting service. More information on the webcastings with detailed instructions can be found at: http://www.ripe.net/ripe/meetings/ripe-45/webcast.html We welcome your feedback on these trials. Please send your comments to . Regards, RIPE Meeting Coordination Team From andrius at andrius.org Tue May 13 16:01:21 2003 From: andrius at andrius.org (Andrius Kasparavicius) Date: Tue, 13 May 2003 17:01:21 +0300 (GMT-3) Subject: [lir-wg] Re: [ipv6-wg@ripe.net] Webcast RIPE 45 Announcement In-Reply-To: <200305131350.h4DDo8A0010960@birch.ripe.net> Message-ID: Is there any software for linux(or freeware) for watching mms:// ? Andrius On Tue, 13 May 2003, RIPE NCC Meeting Registration wrote: > To see the meeting in real time, please use one of the following URLs. As > we have limited bandwith to the meeting venue, we ask that you choose a > server that is physically closer to you: > > - - RIPE Meeting Attendees only: mms://webcast.ripemtg.ripe.net/ripemtg > - - Spain Mirror: mms://media.rediris.es/ripelive > - - Portugal Mirror: mms://wms.fccn.pt/ripelive > - - Italy Mirror: mms://stream1-wg.cineca.it/ripelive > - - Denmark Mirror: mms://wmslave.fsknet.dk/ripelive > - - Czech Republic Mirror: mms://server1.streaming.cesnet.cz/ripemtg > - - United Kingdom Mirror: mms://ccs-web2k.brynmill.swan.ac.uk/ripelive > - - Netherlands Mirror: mms://stream-ripe.wind.surfnet.nl/ripelive > - - Amsterdam Mirror (RIPE NCC Office): mms://webcast.ripe.net/ripemtg From jorgen at hovland.cx Tue May 13 16:08:23 2003 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Tue, 13 May 2003 16:08:23 +0200 Subject: [lir-wg] Re: [ipv6-wg@ripe.net] Webcast RIPE 45 Announcement References: Message-ID: <008801c31959$1e673590$1b29b3d5@klimax> ----- Original Message ----- From: "Andrius Kasparavicius" To: "RIPE NCC Meeting Registration" Cc: ; Sent: Tuesday, May 13, 2003 4:01 PM Subject: [lir-wg] Re: [ipv6-wg at ripe.net] Webcast RIPE 45 Announcement > > Is there any software for linux(or freeware) for watching mms:// ? > > Andrius mplayer Joergen Hovland From ulrich.kiermayr at univie.ac.at Tue May 13 16:11:18 2003 From: ulrich.kiermayr at univie.ac.at (Ulrich Kiermayr) Date: Tue, 13 May 2003 16:11:18 +0200 Subject: [lir-wg] Re: [ipv6-wg@ripe.net] Webcast RIPE 45 Announcement In-Reply-To: References: Message-ID: <3EC0FD06.7080504@univie.ac.at> Andrius Kasparavicius wrote: > Is there any software for linux(or freeware) for watching mms:// ? I use xine (xine.sf.net) and it works great. lG uk -- ------------------------------------------------------------------------ Ulrich Kiermayr Zentraler Informatikdienst der Universitaet Wien Network Security Universitaetsstrasse 7, 1010 Wien, Austria ------------------------------------------------------------------------ eMail: ulrich.kiermayr at univie.ac.at Tel: (+43 1) 4277 / 14104 Hotline: security.zid at univie.ac.at Fax: (+43 1) 4277 / 9140 ------------------------------------------------------------------------ GPG Key fingerprint = BF0D 5749 4DC1 ED74 AB67 7180 105F 491D A8D7 64D8 From matthew.ford at bt.com Tue May 13 16:23:02 2003 From: matthew.ford at bt.com (matthew.ford at bt.com) Date: Tue, 13 May 2003 15:23:02 +0100 Subject: [lir-wg] RE: [ipv6-wg@ripe.net] Webcast RIPE 45 Announcement Message-ID: Could whoever is operating the camera please drink less coffee..... just point the thing at the screen and be done with it .... I'm getting motion sickness ;-) Mat -----Original Message----- From: RIPE NCC Meeting Registration [mailto:meeting at ripe.net] Sent: Tue 13/05/2003 14:50 To: local-ir at ripe.net; ripe-list at ripe.net; ripecast at ripe.net; lir-wg at ripe.net; routing-wg at ripe.net; db-wg at ripe.net; ipmt-dev at ripe.net; ipv6-wg at ripe.net Cc: meeting at ripe.net Subject: [ipv6-wg at ripe.net] Webcast RIPE 45 Announcement Dear Colleages, Please note that several sessions at RIPE 45 are being webcast. These sessions include the following: - - EOF - - Routing Working Group - - LIR Working Group - - Tools Working Group - - The RIPE NCC Services BoF - - IPv6 Working Group - - Database Working Group - - Plenary To see the meeting in real time, please use one of the following URLs. As we have limited bandwith to the meeting venue, we ask that you choose a server that is physically closer to you: - - RIPE Meeting Attendees only: mms://webcast.ripemtg.ripe.net/ripemtg - - Spain Mirror: mms://media.rediris.es/ripelive - - Portugal Mirror: mms://wms.fccn.pt/ripelive - - Italy Mirror: mms://stream1-wg.cineca.it/ripelive - - Denmark Mirror: mms://wmslave.fsknet.dk/ripelive - - Czech Republic Mirror: mms://server1.streaming.cesnet.cz/ripemtg - - United Kingdom Mirror: mms://ccs-web2k.brynmill.swan.ac.uk/ripelive - - Netherlands Mirror: mms://stream-ripe.wind.surfnet.nl/ripelive - - Amsterdam Mirror (RIPE NCC Office): mms://webcast.ripe.net/ripemtg Please note that the webcastings are technical trials only and the broadcasts should not be regarded as an official implementation of a webcasting service. More information on the webcastings with detailed instructions can be found at: http://www.ripe.net/ripe/meetings/ripe-45/webcast.html We welcome your feedback on these trials. Please send your comments to . Regards, RIPE Meeting Coordination Team From gert at space.net Thu May 15 09:13:18 2003 From: gert at space.net (Gert Doering) Date: Thu, 15 May 2003 09:13:18 +0200 Subject: [lir-wg] Archives of LIR WG sessions available Message-ID: <20030515091318.I78586@Space.Net> Hi LIR WG readers, for those of you that are not aware of it already: the LIR WG meeting yesterday was recorded and is now available online, via the following URLs: mms://webcast.ripe.net/ripe45/lir-1.wmv mms://webcast.ripe.net/ripe45/lir-2.wmv (visible via windows media player and mplayer under Linux) regards, Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 54495 (54267) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From Marcus.Ruchti at colt.de Wed May 21 15:16:41 2003 From: Marcus.Ruchti at colt.de (Marcus.Ruchti at colt.de) Date: Wed, 21 May 2003 14:16:41 +0100 Subject: [lir-wg] Problems with route object update Message-ID: Hi all, I've recognized that we have massive problems in the last weeks with RIPE database updates by other ISP's. e.g. a new customer wants that we will announce a PI network used by him but it is maintained by another LIR. I've asked for creating a route object with our maintainer several times without success. I think all this happens with intention to constrain the business activity of the competitor ! Is there a possibility to insert the RIPE-NONE Maintainer in the whole PI blocks (e.g. /16). In this step I won't mention the names of those ISP's... regards, Marcus Ruchti COLT Telecom GmbH From chr at jay.net Wed May 21 15:33:46 2003 From: chr at jay.net (Christian Rasmussen) Date: Wed, 21 May 2003 15:33:46 +0200 Subject: [lir-wg] Problems with route object update In-Reply-To: Message-ID: Hi Marcus, We have had the same situation a few times. The problem seems to be that "Provider Independent" IP addresses are not at all provider independent since the LIR is usually the maintainer of the inetnum object, so the customer will not be able to take the PI net to another LIR unless the previous LIR agrees to release the object. A solution could be to make the customer maintainer of the inetnum, that way the customer could simply add the new LIR's maintainer to MNT-ROUTES. Med venlig hilsen/Best regards Christian Rasmussen Hosting manager, jay.net a/s Smedeland 32, 2600 Glostrup, Denmark Email: noc at jay.net Personal email: chr at corp.jay.net Tlf./Phone: +45 3336 6300, Fax: +45 3336 6301 Produkter / Products: http://hosting.jay.net > -----Original Message----- > From: lir-wg-admin at ripe.net [mailto:lir-wg-admin at ripe.net]On Behalf Of > Marcus.Ruchti at colt.de > Sent: 21. maj 2003 15:17 > To: lir-wg at ripe.net > Subject: [lir-wg] Problems with route object update > > > Hi all, > > I've recognized that we have massive problems > in the last weeks with RIPE database updates by > other ISP's. > > e.g. a new customer wants that we will announce a PI network > used by him but it is maintained by another LIR. > > I've asked for creating a route object with our maintainer several times > without success. > > I think all this happens with intention to constrain > the business activity of the competitor ! > > Is there a possibility to insert the RIPE-NONE Maintainer > in the whole PI blocks (e.g. /16). > > In this step I won't mention the names of those ISP's... > > regards, > > Marcus Ruchti > COLT Telecom GmbH > From leo at ripe.net Wed May 21 16:50:19 2003 From: leo at ripe.net (leo vegoda) Date: Wed, 21 May 2003 16:50:19 +0200 Subject: [lir-wg] Problems with route object update In-Reply-To: References: Message-ID: Hi Christian, Christian Rasmussen writes: >Hi Marcus, > > >We have had the same situation a few times. The problem seems to be that >"Provider Independent" IP addresses are not at all provider independent >since the LIR is usually the maintainer of the inetnum object, so the >customer will not be able to take the PI net to another LIR unless the >previous LIR agrees to release the object. > >A solution could be to make the customer maintainer of the inetnum, that way >the customer could simply add the new LIR's maintainer to MNT-ROUTES. We recommend that End Users maintain their PI inetnum themselves if they want to do so. However, they are free to have their provider maintain it for them if they want that, instead. If a maintainer is unable to update the object for the End User then please contact the RIPE NCC and we will try to help. Also, it is worth noting that where two maintainers need to agree to the creation of a route object then both authentications can be passed to the database in the same e-mail. We have a graphical representation of the authentication rules at this page: Kind regards, -- leo vegoda RIPE NCC Registration Services From chr at jay.net Thu May 22 13:34:42 2003 From: chr at jay.net (Christian Rasmussen) Date: Thu, 22 May 2003 13:34:42 +0200 Subject: [lir-wg] Problems with route object update In-Reply-To: Message-ID: Hi Leo, > >We have had the same situation a few times. The problem seems to be that > >"Provider Independent" IP addresses are not at all provider independent > >since the LIR is usually the maintainer of the inetnum object, so the > >customer will not be able to take the PI net to another LIR unless the > >previous LIR agrees to release the object. > > > >A solution could be to make the customer maintainer of the > inetnum, that way > >the customer could simply add the new LIR's maintainer to MNT-ROUTES. > > We recommend that End Users maintain their PI inetnum themselves if they > want to do so. However, they are free to have their provider maintain it > for them if they want that, instead. Yes, I understand, the problem is if the LIR decides not to inform the customer of this option, but if it was not an option for the LIR to be maintainer of the customers PI assignment (end user mandatory maintainer) it would solve the problem. > > If a maintainer is unable to update the object for the End User then > please contact the RIPE NCC and we will try to help. As I understand its not normal procedure for Ripe NCC to contact end users, so Ripe NCC would have to determine which of the LIRs the customer had chosen by speaking to each of the competitors (LIRs). Instead it would be much easier if it was always the customer who was maintainer of the inetnum object. > > Also, it is worth noting that where two maintainers need to agree to the > creation of a route object then both authentications can be passed to > the database in the same e-mail. We have a graphical representation of > the authentication rules at this page: Yes, the representation is actually quite nice, but the issue is not technically how to create the route object. Med venlig hilsen/Best regards Christian Rasmussen Hosting manager, jay.net a/s Smedeland 32, 2600 Glostrup, Denmark Email: noc at jay.net Personal email: chr at corp.jay.net Tlf./Phone: +45 3336 6300, Fax: +45 3336 6301 Produkter / Products: http://hosting.jay.net From woeber at cc.univie.ac.at Thu May 22 15:15:50 2003 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 22 May 2003 15:15:50 +0200 Subject: [lir-wg] Problems with route object update Message-ID: <00A203FD.7E1D738E.1@cc.univie.ac.at> >> We recommend that End Users maintain their PI inetnum themselves if they >> want to do so. However, they are free to have their provider maintain it >> for them if they want that, instead. > >Yes, I understand, the problem is if the LIR decides not to inform the >customer of this option, This sounds like a business relation (ethics?) issue, rather than a registry or database issue. >but if it was not an option for the LIR to be >maintainer of the customers PI assignment (end user mandatory maintainer) it >would solve the problem. 2 problems here: - the LIR has to "donate" its resources to apply for the PI block with the NCC. So there may be a reason (in some cases) for protecting the object with the LIR's maintainer; - in our case (for customers with legacy addresses) we have an agreement in place to jointly manage and protect the inetnum objects. Some may even choose to have us do that as a service. For that reason, blocking this would be undesirable from my point of view. Wilfried. _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber at CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From leo at ripe.net Thu May 22 17:00:01 2003 From: leo at ripe.net (leo vegoda) Date: Thu, 22 May 2003 17:00:01 +0200 Subject: [lir-wg] Problems with route object update In-Reply-To: References: Message-ID: <4heAplbxXOz+EwdW@ripe.net> Hi Christian, Christian Rasmussen writes: [...] >> If a maintainer is unable to update the object for the End User then >> please contact the RIPE NCC and we will try to help. > >As I understand its not normal procedure for Ripe NCC to contact end users, >so Ripe NCC would have to determine which of the LIRs the customer had >chosen by speaking to each of the competitors (LIRs). Instead it would be >much easier if it was always the customer who was maintainer of the inetnum >object. There are some advantages to this. However, there are also disadvantages. End Users may well have a steep learning curve with regard to their maintainer. They may not use it frequently, and consequently lose the password or PGP key associated with it. This would then require them to contact the RIPE NCC to regain control of the maintainer. Nonetheless, End Users that want to maintain their own inetnum objects may do so if they so wish. The RIPE NCC will create a maintainer for them, if they request it, when the address space is assigned. They can also request a maintainer at a later date, if they want. Best regards, -- leo vegoda RIPE NCC Registration Services From md at ncuk.net Thu May 22 15:20:10 2003 From: md at ncuk.net (Sebastien Lahtinen) Date: Thu, 22 May 2003 14:20:10 +0100 (BST) Subject: [lir-wg] Problems with route object update In-Reply-To: <00A203FD.7E1D738E.1@cc.univie.ac.at> References: <00A203FD.7E1D738E.1@cc.univie.ac.at> Message-ID: On Thu, 22 May 2003, Wilfried Woeber, UniVie/ACOnet wrote: > >but if it was not an option for the LIR to be maintainer of the > >customers PI assignment (end user mandatory maintainer) it would solve > >the problem. > > 2 problems here: > > - the LIR has to "donate" its resources to apply for the PI block with > the NCC. So there may be a reason (in some cases) for protecting the > object with the LIR's maintainer; > > - in our case (for customers with legacy addresses) we have an agreement > in place to jointly manage and protect the inetnum objects. Some may > even choose to have us do that as a service. > For that reason, blocking this would be undesirable from my point of > view. I couldn't agree more. We've done PI for clients on their own maintainer if that's what they want, but creating extra maintainers "for the sake of it" seems pointless because half the PI users may not understand how to use their maintainer anyway! Sebastien. --- NetConnex Broadband Ltd. tel. +44 870 745 4830 fax. +44 870 745 4831 Court Farm Lodge, 1 Eastway, Epsom, Surrey, KT19 8SG. United Kingdom. From Marcus.Ruchti at colt.de Fri May 23 10:28:11 2003 From: Marcus.Ruchti at colt.de (Marcus.Ruchti at colt.de) Date: Fri, 23 May 2003 09:28:11 +0100 Subject: AW: [lir-wg] Problems with route object update Message-ID: that's true, I've made the same experiences. Mostly we request an own maintainer for a customer when we request a new PI network, but the majority of the users hasn't the knowledge or they don't want to build up knowledge to create or to update the RIPE database... Marcus -----Urspr?ngliche Nachricht----- Von: Sebastien Lahtinen [mailto:md at ncuk.net] Gesendet am: Donnerstag, 22. Mai 2003 15:20 An: Wilfried Woeber, UniVie/ACOnet Cc: lir-wg at ripe.net Betreff: RE: [lir-wg] Problems with route object update On Thu, 22 May 2003, Wilfried Woeber, UniVie/ACOnet wrote: > >but if it was not an option for the LIR to be maintainer of the > >customers PI assignment (end user mandatory maintainer) it would solve > >the problem. > > 2 problems here: > > - the LIR has to "donate" its resources to apply for the PI block with > the NCC. So there may be a reason (in some cases) for protecting the > object with the LIR's maintainer; > > - in our case (for customers with legacy addresses) we have an agreement > in place to jointly manage and protect the inetnum objects. Some may > even choose to have us do that as a service. > For that reason, blocking this would be undesirable from my point of > view. I couldn't agree more. We've done PI for clients on their own maintainer if that's what they want, but creating extra maintainers "for the sake of it" seems pointless because half the PI users may not understand how to use their maintainer anyway! Sebastien. --- NetConnex Broadband Ltd. tel. +44 870 745 4830 fax. +44 870 745 4831 Court Farm Lodge, 1 Eastway, Epsom, Surrey, KT19 8SG. United Kingdom. From chr at jay.net Fri May 23 13:23:02 2003 From: chr at jay.net (Christian Rasmussen) Date: Fri, 23 May 2003 13:23:02 +0200 Subject: [lir-wg] Problems with route object update In-Reply-To: Message-ID: Agreed, it would not be very flexible if the LIR's were not allowed to sell the service of maintaining customers PI net registrations, thats definitely a disadvantage. But that doesn't change the fact that some LIRs have problems getting the previous LIR to properly update the objects of a former customer. The reason for this problem could be ethical related as previously suggested - but it could also simply be that the previous LIR can/will not allocate the necessary ressources for the update task within the given timeframe. But as I understand the LIR is obligated to perform the necessary update at some point in order to have the objects correctly registered. It would be preferable if the end user somehow had authority over the inetnum object, but I understand that a solution with the end user as mandatory maintainer might be a disadvantage to the majority of the LIRs. > -----Original Message----- > From: lir-wg-admin at ripe.net [mailto:lir-wg-admin at ripe.net]On Behalf Of > Marcus.Ruchti at colt.de > Sent: 23. maj 2003 10:28 > To: md at ncuk.net; woeber at cc.univie.ac.at > Cc: lir-wg at ripe.net > Subject: AW: [lir-wg] Problems with route object update > > > that's true, I've made the same experiences. > Mostly we request an own maintainer for a customer when we > request a new PI > network, > but the majority of the users hasn't the knowledge or they don't want to > build up knowledge > to create or to update the RIPE database... > > Marcus > Med venlig hilsen/Best regards Christian Rasmussen Hosting manager, jay.net a/s Smedeland 32, 2600 Glostrup, Denmark Email: noc at jay.net Personal email: chr at corp.jay.net Tlf./Phone: +45 3336 6300, Fax: +45 3336 6301 Produkter / Products: http://hosting.jay.net From gert at Space.Net Fri May 23 14:01:14 2003 From: gert at Space.Net (Gert Doering) Date: Fri, 23 May 2003 14:01:14 +0200 Subject: [lir-wg] Discussion about RIPE-261 Message-ID: <20030523140114.A69579@Space.Net> Hi, those of you that have been to Barcelona have heard the presentation by Paul Wilson from APNIC concerning the RIPE-261 document. In short, it's a proposal how to reorganize distributing IPv6 allocations "from the root" to the LIRs, fixing the way it's done now (ICANN allocating /23 fragments to the RIRs, and the RIRs having to fill them quite thoroughly, not leaving space for an ISP to grow past a /29). Technically, this is a matter between the RIRs and ICANN, but as this proposal affects routing and filtering as well, it would be useful to have consensus among the members that it's a good thing. So: please read the document (ftp://ftp.ripe.net/ripe/docs/ripe-261.txt) and comment on it. Note: this e-mail goes to ipv6-wg and lir-wg, but please don't followup to ipv6-wg - keep all of the discussion in the lir-wg mailing list. Speaking as "me personally" (this is not the official WG chair speaking here, just a concerned IPv6 user!), I have the following comments: - The /23 allocations ICANN -> RIRs are bad, because they lead to address space fragmentation, and the blocks are too small to do useful allocation towards the LIRs. Something NEEDS to be changed here. - Nevertheless, I do NOT like the idea of a "common address pool". People want to be able to see the "region" that a prefix is coming from by looking at the address. This is working fine now in v4 (except for the swamp and part of ERX) and in the so-far IPv6 allocations (except that due to the /23s it's getting messy), but would be broken by the CAP. - As a technical reason: people want to be able to filter IPv6 prefixes by region, like "I only have one uplink that provides me with US connectivity, so there's no need to carry any US prefixes in my routing table, I just point a summary down that line". This is not yet done, but I am convinced that we shouldn't break routing hierarchy without good need. - If people *really* go into "multiple /48s per site" multihoming, source address selection works by doing a longest-match check, and this will work better if same-region addresses have something like a common prefix, instead of "everythins smeared everywhere". So my personal recommendation would be: - change the /23 allocation boundary ICANN -> RIR to something more useful, like a /12 or so (a /12 means "512 of them are available, so we're not yet burning bridges - but a /8 would work as well. A /16 is already somewhat tight). - every RIR still gets its own allocation from where RIR->LIR allocations are taken - inside that RIR allocation, use the binary chop algorithm described in RIPE-261 for the RIR->LIR distribution. So - let the discussion start now! Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 54837 (54495) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From webmaster at keyworld.net Fri May 23 14:04:46 2003 From: webmaster at keyworld.net (webmaster at keyworld.net) Date: Fri, 23 May 2003 14:04:46 +0200 Subject: Autoreply: [lir-wg] Discussion about RIPE-261 Message-ID: Hi, I am out of the office till the 9th of June 2003. --> If you have a technical issue please send an e-mail to support at keyworld.net. --> If you have a query on the Vegastream products please send an e-mail to sales at keyworld.net. --> If you have a query on website hosting or require changes to one currently hosted with us please contact Mr. Alton Costa on email alton at keyworld.net Thank you for choosing KeyWORLD as your communications partner. Best Regards, Christian Ransley B.Sc. Web & Technical Services Manager Keyworld Ltd. UB42, Industrial Zone San Gwann SGN 09 Tel: (+356) 2540 2540 Fax: (+356) 2540 9999 Email: webmaster at keyworld.net Website: http://www.keyworld.net From michel at arneill-py.sacramento.ca.us Sun May 25 22:59:59 2003 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Sun, 25 May 2003 13:59:59 -0700 Subject: [lir-wg] RE: [ipv6-wg@ripe.net] Discussion about RIPE-261 Message-ID: <963621801C6D3E4A9CF454A1972AE8F5067127@server2000.arneill-py.sacramento.ca.us> Gert, > Gert Doering wrote: > - The /23 allocations ICANN -> RIRs are bad, because they lead to > address space fragmentation, and the blocks are too small to do useful > allocation towards the LIRs. Something NEEDS to be changed here. Agree. > So my personal recommendation would be: > - change the /23 allocation boundary ICANN -> RIR to something more > useful, like a /12 or so (a /12 means "512 of them are available, > so we're not yet burning bridges - but a /8 would work as well. > A /16 is already somewhat tight). I don't find this very flexible. If you look at what happened with LACNIC, countries from ARIN were transferred to LACNIC. I expect that when AFRINIC is activated, countries from both RIPE and ARIN will be transferred to AFRINIC. I agree with this goal: > - As a technical reason: people want to be able to filter IPv6 > prefixes by region, like "I only have one uplink that provides me > with US connectivity, so there's no need to carry any US prefixes > in my routing table, I just point a summary down that line". If you want to do this, you might as well do it right in the first place. IMHO, delegating space to a RIR as a single block is a mistake. It would be much more flexible to assign space to countries, and simply say that RIRs have stewardship of the space assigned to countries belonging to them. If a country changes RIRs like we have seen for LACNIC and like we will likely see for AFRINIC, no change in addresses and the geographical summary is preserved. Below is an example interpolated from the work we have done on geographic assignments: http://arneill-py.sacramento.ca.us/ipv6mh/geov6.txt Quick notes: - We are presently talking about PA space; the document mentioned above refers to PI space. However the geographic cutoff collapsed to the country level would not change. - I chose to assign a /8 to the entire world, which can be discussed. This means that after we colonize 255 other planets we have a problem :-) can someone help me with that warp drive please? - What could also be discussed are the details of how this was generated, but I would like to get the _concept_ across then we can talk about the details. Zone Population %G Pop. IANA ---------------- ---------- ------- -------------- China 1284971000 20.91% 2346:0000::/11 Continental Asia 673454413 10.96% 2346:2000::/11 India 1025096000 16.68% 2346:4000::/12 Northern Africa 565854163 9.21% 2346:5000::/12 Asian Islands 488468000 7.95% 2346:6000::/12 Western Europe 423412058 6.89% 2346:7000::/12 North America 318243350 5.18% 2346:8000::/12 South America 350724557 5.71% 2346:9000::/13 Eastern Europe 307858000 5.01% 2346:9800::/13 Middle East 258577000 4.21% 2346:A000::/13 Southern Africa 242566332 3.95% 2346:A800::/13 Central America 175719760 2.86% 2346:B000::/14 Oceania 30568053 0.50% 2346:B400::/16 ---------------- ---------- ------- -------------- World 6145512686 100.00% 2346:0000::/8 Example of one zone: Country Population %Z Pop. %G Pop. IANA ------------------- ---------- ------- ------- -------------- United States 285926000 89.85% 4.65% 2346:8000::/13 Canada 1015000 9.75% 0.50% 2346:8800::/17 Hawaii 1224398 0.38% 0.02% 2346:8880::/21 Bermuda 60000 0.02% 0.00% 2346:8888::/24 Greenland 12483 0.00% 0.00% 2346:8889::/24 -------------------- ---------- ------- ------- -------------- Zone: North America 318243350 100.00% 5.18% 2346:8000::/12 Implementing such a system would change the way large(global) LIRs request space from RIRs. As of today, they would typically request one /32 per RIR. For people the size of Sprint, they would then have to request a /32 per country they service and assign space to customers from the correct prefix. What this means to large LIRs is a large initial number of prefixes, but it's not fundamentally worse than an always-growing number of /32s when IPv6 finally takes off IMHO. For smaller LIRs that service only one country, there would be no change. There would be some impact on the GRT as there would be a "SPRINT-USA" block, an "ATT-USA" block, a "SPRINT-GERMANY" block, an "ATT-GERMANY" block, etc. In other words, what we are looking at is one /32 prefix per country per large LIR, opposed to as many /32s a large LIR would need in the long run anyway. Comments welcome. > - inside that RIR allocation, use the binary chop algorithm > described in RIPE-261 for the RIR->LIR distribution. I'm not familiar with this; would that be something like RFC3531? Michel. From hank at att.net.il Mon May 26 08:01:43 2003 From: hank at att.net.il (Hank Nussbacher) Date: Mon, 26 May 2003 08:01:43 +0200 Subject: [lir-wg] RE: [ipv6-wg@ripe.net] Discussion about RIPE-261 In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F5067127@server2000.arneill- py.sacramento.ca.us> Message-ID: <5.1.0.14.2.20030526075343.00fbe8c0@max.att.net.il> At 01:59 PM 25-05-03 -0700, Michel Py wrote: Can you explain "%G Pop."? How is it calculated? I assume it has to do with GDP but please explain the calculation as well as the source of the numbers (the exact UN stats page would help). Needless to say, your numbers do not seem to take in any socio-economic factors. Assigning a /12 to North America as well as to Northern Africa and India might make socialistic sense as well as being "politically correct", but from a reality standpoint, it just don't fly. -Hank >Below is an example interpolated from the work we have done on >geographic assignments: >http://arneill-py.sacramento.ca.us/ipv6mh/geov6.txt > >Quick notes: >- We are presently talking about PA space; the document mentioned above >refers to PI space. However the geographic cutoff collapsed to the >country level would not change. > >- I chose to assign a /8 to the entire world, which can be discussed. >This means that after we colonize 255 other planets we have a problem >:-) can someone help me with that warp drive please? > >- What could also be discussed are the details of how this was >generated, but I would like to get the _concept_ across then we can talk >about the details. > >Zone Population %G Pop. IANA >---------------- ---------- ------- -------------- >China 1284971000 20.91% 2346:0000::/11 >Continental Asia 673454413 10.96% 2346:2000::/11 >India 1025096000 16.68% 2346:4000::/12 >Northern Africa 565854163 9.21% 2346:5000::/12 >Asian Islands 488468000 7.95% 2346:6000::/12 >Western Europe 423412058 6.89% 2346:7000::/12 >North America 318243350 5.18% 2346:8000::/12 >South America 350724557 5.71% 2346:9000::/13 >Eastern Europe 307858000 5.01% 2346:9800::/13 >Middle East 258577000 4.21% 2346:A000::/13 >Southern Africa 242566332 3.95% 2346:A800::/13 >Central America 175719760 2.86% 2346:B000::/14 >Oceania 30568053 0.50% 2346:B400::/16 >---------------- ---------- ------- -------------- >World 6145512686 100.00% 2346:0000::/8 > > >Example of one zone: > >Country Population %Z Pop. %G Pop. IANA >------------------- ---------- ------- ------- -------------- >United States 285926000 89.85% 4.65% 2346:8000::/13 >Canada 1015000 9.75% 0.50% 2346:8800::/17 >Hawaii 1224398 0.38% 0.02% 2346:8880::/21 >Bermuda 60000 0.02% 0.00% 2346:8888::/24 >Greenland 12483 0.00% 0.00% 2346:8889::/24 >-------------------- ---------- ------- ------- -------------- >Zone: North America 318243350 100.00% 5.18% 2346:8000::/12 > >Implementing such a system would change the way large(global) LIRs >request space from RIRs. As of today, they would typically request one >/32 per RIR. For people the size of Sprint, they would then have to >request a /32 per country they service and assign space to customers >from the correct prefix. > >What this means to large LIRs is a large initial number of prefixes, but >it's not fundamentally worse than an always-growing number of /32s when >IPv6 finally takes off IMHO. > >For smaller LIRs that service only one country, there would be no >change. > >There would be some impact on the GRT as there would be a "SPRINT-USA" >block, an "ATT-USA" block, a "SPRINT-GERMANY" block, an "ATT-GERMANY" >block, etc. In other words, what we are looking at is one /32 prefix per >country per large LIR, opposed to as many /32s a large LIR would need in >the long run anyway. > >Comments welcome. > > > > - inside that RIR allocation, use the binary chop algorithm > > described in RIPE-261 for the RIR->LIR distribution. > >I'm not familiar with this; would that be something like RFC3531? > >Michel. From leo at ripe.net Mon May 26 08:36:43 2003 From: leo at ripe.net (leo vegoda) Date: Mon, 26 May 2003 08:36:43 +0200 Subject: [lir-wg] RE: [ipv6-wg@ripe.net] Discussion about RIPE-261 In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F5067127@server2000.arneill-py.sacramento.ca.us> References: <963621801C6D3E4A9CF454A1972AE8F5067127@server2000.arneill-py.sacramento.ca.us> Message-ID: Hi Michel, Michel Py writes: [...] >If you want to do this, you might as well do it right in the first >place. IMHO, delegating space to a RIR as a single block is a mistake. >It would be much more flexible to assign space to countries, and simply >say that RIRs have stewardship of the space assigned to countries >belonging to them. If a country changes RIRs like we have seen for >LACNIC and like we will likely see for AFRINIC, no change in addresses >and the geographical summary is preserved. How would such a system cope with networks crossing international boundaries? Also, if an enterprise LIR moved from country A to country B, would they have to renumber? Regards, -- leo vegoda RIPE NCC Registration Services From kurtis at kurtis.pp.se Mon May 26 08:50:08 2003 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Mon, 26 May 2003 08:50:08 +0200 Subject: [lir-wg] RE: [ipv6-wg@ripe.net] Discussion about RIPE-261 In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F5067127@server2000.arneill-py.sacramento.ca.us> Message-ID: <4A18F89E-8F46-11D7-857A-000393A638B2@kurtis.pp.se> > In other words, what we are looking at is one /32 prefix per > country per large LIR, opposed to as many /32s a large LIR would need > in > the long run anyway. Actually what you are looking at is one /32 per LIR + one /32 per country per large LIR. Without tweaking routing, a more efficient way would be to use the fact that IPv6 blocks are a lot larger than IPv4 blocks and simply give one /32 to every LIR. I guess this would only work with RIPE who have the concepts of LIRs but anyway. - kurtis - From joao at psg.com Mon May 26 09:30:36 2003 From: joao at psg.com (Joao Luis Silva Damas) Date: Mon, 26 May 2003 09:30:36 +0200 Subject: [lir-wg] RE: [ipv6-wg@ripe.net] Discussion about RIPE-261 In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F5067127@server2000.arneill-py.sacramento.c a.us> References: <963621801C6D3E4A9CF454A1972AE8F5067127@server2000.arneill-py.sacramento.c a.us> Message-ID: Michel, using countries as the delimiter for any sort of network design seems a bit strange. Isn't the natural boundary closer to be an ISP, wherever its network is? You talk about colonising planets. I would think that is much more probable you would have to worry about some European countries merging in a few decades. The opposite can also happen, as it has in recent history. Regional definitions also change. Form instance, would you care to explain the concept of Western Europe vs Eastern Europe, particularly beyond 2004? Last time I checked, Hawaii was still part of the USA. And so on... Even if every user becomes multi-homed, as is a common scenario quoted by IPv6 visionaries, would the focus change from the ISP towards the user as the reference point for routing and network operations? I really don't think so. Just like today you would get to talk to your cable TV company, the electricity company, the gas company, the water supply company, etc. Each of them, and a few new ones, would operate some sort of IP network to read your meters, provide "extra" service, etc and each is likely to have different policies because that would be the factor providing them with a way of differentiating their service. Geography is not that important, network topology and autonomous policies are. Joao At 13:59 -0700 25/5/03, Michel Py wrote: >Gert, > > >> Gert Doering wrote: >> - The /23 allocations ICANN -> RIRs are bad, because they lead to >> address space fragmentation, and the blocks are too small to do >useful >> allocation towards the LIRs. Something NEEDS to be changed here. > >Agree. > > >> So my personal recommendation would be: >> - change the /23 allocation boundary ICANN -> RIR to something more >> useful, like a /12 or so (a /12 means "512 of them are available, >> so we're not yet burning bridges - but a /8 would work as well. >> A /16 is already somewhat tight). > >I don't find this very flexible. If you look at what happened with >LACNIC, countries from ARIN were transferred to LACNIC. I expect that >when AFRINIC is activated, countries from both RIPE and ARIN will be >transferred to AFRINIC. > >I agree with this goal: > >> - As a technical reason: people want to be able to filter IPv6 >> prefixes by region, like "I only have one uplink that provides me >> with US connectivity, so there's no need to carry any US prefixes >> in my routing table, I just point a summary down that line". > >If you want to do this, you might as well do it right in the first >place. IMHO, delegating space to a RIR as a single block is a mistake. >It would be much more flexible to assign space to countries, and simply >say that RIRs have stewardship of the space assigned to countries >belonging to them. If a country changes RIRs like we have seen for >LACNIC and like we will likely see for AFRINIC, no change in addresses >and the geographical summary is preserved. > >Below is an example interpolated from the work we have done on >geographic assignments: >http://arneill-py.sacramento.ca.us/ipv6mh/geov6.txt > >Quick notes: >- We are presently talking about PA space; the document mentioned above >refers to PI space. However the geographic cutoff collapsed to the >country level would not change. > >- I chose to assign a /8 to the entire world, which can be discussed. >This means that after we colonize 255 other planets we have a problem >:-) can someone help me with that warp drive please? > >- What could also be discussed are the details of how this was >generated, but I would like to get the _concept_ across then we can talk >about the details. > >Zone Population %G Pop. IANA >---------------- ---------- ------- -------------- >China 1284971000 20.91% 2346:0000::/11 >Continental Asia 673454413 10.96% 2346:2000::/11 >India 1025096000 16.68% 2346:4000::/12 >Northern Africa 565854163 9.21% 2346:5000::/12 >Asian Islands 488468000 7.95% 2346:6000::/12 >Western Europe 423412058 6.89% 2346:7000::/12 >North America 318243350 5.18% 2346:8000::/12 >South America 350724557 5.71% 2346:9000::/13 >Eastern Europe 307858000 5.01% 2346:9800::/13 >Middle East 258577000 4.21% 2346:A000::/13 >Southern Africa 242566332 3.95% 2346:A800::/13 >Central America 175719760 2.86% 2346:B000::/14 >Oceania 30568053 0.50% 2346:B400::/16 >---------------- ---------- ------- -------------- >World 6145512686 100.00% 2346:0000::/8 > > >Example of one zone: > >Country Population %Z Pop. %G Pop. IANA >------------------- ---------- ------- ------- -------------- >United States 285926000 89.85% 4.65% 2346:8000::/13 >Canada 1015000 9.75% 0.50% 2346:8800::/17 >Hawaii 1224398 0.38% 0.02% 2346:8880::/21 >Bermuda 60000 0.02% 0.00% 2346:8888::/24 >Greenland 12483 0.00% 0.00% 2346:8889::/24 >-------------------- ---------- ------- ------- -------------- >Zone: North America 318243350 100.00% 5.18% 2346:8000::/12 > >Implementing such a system would change the way large(global) LIRs >request space from RIRs. As of today, they would typically request one >/32 per RIR. For people the size of Sprint, they would then have to >request a /32 per country they service and assign space to customers >from the correct prefix. > >What this means to large LIRs is a large initial number of prefixes, but >it's not fundamentally worse than an always-growing number of /32s when >IPv6 finally takes off IMHO. > >For smaller LIRs that service only one country, there would be no >change. > >There would be some impact on the GRT as there would be a "SPRINT-USA" >block, an "ATT-USA" block, a "SPRINT-GERMANY" block, an "ATT-GERMANY" >block, etc. In other words, what we are looking at is one /32 prefix per >country per large LIR, opposed to as many /32s a large LIR would need in >the long run anyway. > >Comments welcome. > > >> - inside that RIR allocation, use the binary chop algorithm >> described in RIPE-261 for the RIR->LIR distribution. > >I'm not familiar with this; would that be something like RFC3531? > >Michel. From michel at arneill-py.sacramento.ca.us Mon May 26 10:29:41 2003 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Mon, 26 May 2003 01:29:41 -0700 Subject: [lir-wg] Discussion about RIPE-261 Message-ID: <963621801C6D3E4A9CF454A1972AE8F504F81E@server2000.arneill-py.sacramento.ca.us> Joao / Hans / Leo / Kurtis [consolidated answers] First, allow me to apologize for posting bogus numbers; I forgot to change the base and the increment. Below at the end are pasted the right numbers. > Joao Luis Silva Damas wrote: > using countries as the delimiter for any sort of network > design seems a bit strange. Isn't the natural boundary > closer to be an ISP, wherever its network is? I am not using countries as a delimiter for network design. What we are talking about here is allocation from the root to RIRs. Each RIR would be delegated a set of countries like today, and RIRs would assign prefixes to LIRs like today as well. The changes this induces for LIRs are: For small LIRs, this changes nothing. For medium LIRs, they might have a few prefixes instead of a single one. For large LIRs, it does mean a large number of prefixes to deal with in the short term, but not that big of a deal in the long run as a large LIR present in dozen of countries will need more than one /32 anyway. > You talk about colonising planets. I would think that is > much more probable you would have to worry about some > European countries merging in a few decades. I would say a few generations. And then what? We'll have a few more prefixes than what would be really needed. > The opposite can also happen, as it has in recent history. There is ample room for new countries. > Regional definitions also change. Form instance, would > you care to explain the concept of Western Europe vs > Eastern Europe, particularly beyond 2004? It does not really matter, at least not for political reasons. The reason there are zones is to provide a higher level of aggregation than the country and also to provide some unused space. If you don't like the cutout, feel free to propose one. > Last time I checked, Hawaii was still part of the USA. This was a voluntary decision given the unique geographical situation of Hawaii. Most other islands that are thousand of miles away from the mainland got promoted to the status of "country", look in the Central America zone there is a country called Netherland Antilles for example. This makes sense as obviously the fiber plant for these islands has nothing to do with the mainland they depend on. > Even if every user becomes multi-homed, as is a common > scenario quoted by IPv6 visionaries, would the focus > change from the ISP towards the user as the reference > point for routing and network operations? I really don't > think so. Me neither. Remember that we are talking PA space here. This system is compatible with multihoming systems that use PI identifiers _and_ PA locators at the same time. > Just like today you would get to talk to your cable TV company, > the electricity company, the gas company, the water supply > company, etc. Each of them, and a few new ones, would operate > some sort of IP network to read your meters, provide "extra" > service, etc and each is likely to have different policies > because that would be the factor providing them with a way > of differentiating their service. Agree, what is your point here? > Geography is not that important, network topology and > autonomous policies are. Agree too, what does my proposal change to these regards? > Hank Nussbacher wrote: > Can you explain "%G Pop."? % of the global population. > How is it calculated? These are year 2000 numbers and they should not be (they should be a future projection some years down the road). I could not find a public data set with a projection for free. If this was to go real, I would need a better data set; however for the sake of the example these numbers are good enough. > I assume it has to do with GDP Nope. These numbers are population only, so it considers that Ethiopia is granted the same numbers of IPv6 addresses than silicon valley per capita. > as well as the source of the numbers. There are census numbers adjusted by predicted short-term growth as census are not taken in every country the same year. It means that for some countries the number might be actual 2000 census data while for other countries the numbers might be 1990 census data individually extrapolated to 2000. > (the exact UN stats page would help). They took it away unfortunately and I can't find a cache. > Needless to say, your numbers do not seem to take in any > socio-economic factors. Assigning a /12 to North America > as well as to Northern Africa and India might make > socialistic sense as well as being "politically correct", > but from a reality standpoint, it just don't fly. It's politically impossible to assign socio-economic factors such as wealth. Who am I to pick a number and decide that Ethiopia gets 16 times less addresses that the US? If it is true that in the short term it would work, this would generate endless debates, which is why I picked that an Ethiopian gets the same number of IP addresses than an American. > Leo Vegoda wrote: > How would such a system cope with networks crossing > international boundaries? The general rule is that a multinational enterprise will obtain address space from the LIR that provides services to it in each country. Example: Enterprise Acme is present in 4 countries. In the Netherlands it receives connectivity from LIR A and LIR B. In France it receives connectivity from LIR C. In Japan it receives connectivity from LIR A and LIR D. It gets 5 /48s: Netherlands: - from LIR A's Netherland block - from LIR B's Netherland block France: - from LIC C's France block Japan: - from LIR A's Japan block - from LIR D's Japan block Also, it is clear that LIR A is a large multinational LIR so it has a /32 for the Netherlands and a /32 for Japan. Hope this answers the question, if not please be more specific. > Also, if an enterprise LIR moved from country A to country B, > would they have to renumber? I would say yes (doing otherwise would break the geographical aggregation we are discussing). In reality, this never happens though. A LIR does not pack their bags on a Friday evening, put the M160 in the plane and deploy the next day in another country. What happens is that the new network is deployed before the old one is taken down (in the real world with in-house spares :-( and that the two address blocks would be active at the same time, then if the LIR really completely moves out of a country the old block should be given back to the RIR. >> Michel Py wrote: >> In other words, what we are looking at is one /32 prefix per >> country per large LIR, opposed to as many /32s a large LIR >> would need in the long run anyway. > Kurt Erik Lindqvist wrote: > Actually what you are looking at is one /32 per LIR + one /32 > per country per large LIR. Of course, a small LIR still needs a /32. > Without tweaking routing, a more efficient way would be to > use the fact that IPv6 blocks are a lot larger than IPv4 > blocks and simply give one /32 to every LIR. Then explain me how you achieve Gert's goal? > I guess this would only work with RIPE who have the > concepts of LIRs but anyway. I don't know how to parse this? All RIRs have the concept of LIR? Finally, here are the correct (I hope) numbers. Zone Population %G Pop. IANA ---------------- ---------- ------- --------- China 1284971000 20.91% 3000::/11 Continental Asia 673454413 10.96% 3020::/11 India 1025096000 16.68% 3040::/12 Northern Africa 565854163 9.21% 3050::/12 Asian Islands 488468000 7.95% 3060::/12 Western Europe 423412058 6.89% 3070::/12 North America 318243350 5.18% 3080::/12 South America 350724557 5.71% 3090::/13 Eastern Europe 307858000 5.01% 3098::/13 Middle East 258577000 4.21% 30A0::/13 Southern Africa 242566332 3.95% 30A8::/13 Central America 175719760 2.86% 30B0::/14 Oceania 30568053 0.50% 30B4::/16 ---------------- ---------- ------- --------- World 6145512686 100.00% 3000::/8 Example of one zone: Country Population %Z Pop. %G Pop. IANA ------------------- ---------- ------- ------- -------------- United States 285926000 89.85% 4.65% 3080:0000::/13 Canada 1015000 9.75% 0.50% 3088:0000::/17 Hawaii 1224398 0.38% 0.02% 3088:8000::/21 Bermuda 60000 0.02% 0.00% 3088:8800::/24 Greenland 12483 0.00% 0.00% 3088:8900::/24 -------------------- ---------- ------- ------- -------------- Zone: North America 318243350 100.00% 5.18% 3080:0000::/12 Michel. From hank at att.net.il Mon May 26 11:38:03 2003 From: hank at att.net.il (Hank Nussbacher) Date: Mon, 26 May 2003 11:38:03 +0200 Subject: [lir-wg] Discussion about RIPE-261 In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F504F81E@server2000.arneill- py.sacramento.ca.us> Message-ID: <5.1.0.14.2.20030526113255.01008900@max.att.net.il> At 01:29 AM 26-05-03 -0700, Michel Py wrote: > > Needless to say, your numbers do not seem to take in any > > socio-economic factors. Assigning a /12 to North America > > as well as to Northern Africa and India might make > > socialistic sense as well as being "politically correct", > > but from a reality standpoint, it just don't fly. > >It's politically impossible to assign socio-economic factors such as >wealth. Who am I to pick a number and decide that Ethiopia gets 16 times >less addresses that the US? If it is true that in the short term it >would work, this would generate endless debates, which is why I picked >that an Ethiopian gets the same number of IP addresses than an American. So don't assign wealth. Use some number that has direct influence on IPv6 usage. Among the possibilities: - # of computer per capita - # of cellphones per capita - % of homes with electricity - % of homes with phone/cable - % of of homes with more than 5 electrical appliances Each would have a direct bearing on IPv6 usage. Pick any of the above or all of the above. -Hank From cfriacas at fccn.pt Fri May 23 14:18:54 2003 From: cfriacas at fccn.pt (Carlos Friacas) Date: Fri, 23 May 2003 13:18:54 +0100 (WEST) Subject: [lir-wg] Re: [ipv6-wg@ripe.net] Discussion about RIPE-261 In-Reply-To: <20030523140114.A69579@Space.Net> Message-ID: On Fri, 23 May 2003, Gert Doering wrote: > Hi, Hi. (...) > Speaking as "me personally" (this is not the official WG chair speaking > here, just a concerned IPv6 user!), I have the following comments: > > - The /23 allocations ICANN -> RIRs are bad, because they lead to > address space fragmentation, and the blocks are too small to do useful > allocation towards the LIRs. Something NEEDS to be changed here. > > - Nevertheless, I do NOT like the idea of a "common address pool". People > want to be able to see the "region" that a prefix is coming from by > looking at the address. Yes. At this point in IPv6 mainly to judge which path its best... through tunnels (reaching far, but higher rtts) or native (short reach, but better rtts) (...) > - If people *really* go into "multiple /48s per site" multihoming, > source address selection works by doing a longest-match check, and > this will work better if same-region addresses have something like > a common prefix, instead of "everythins smeared everywhere". Agree. > So my personal recommendation would be: > > - change the /23 allocation boundary ICANN -> RIR to something more > useful, like a /12 or so (a /12 means "512 of them are available, > so we're not yet burning bridges - but a /8 would work as well. A > /16 is already somewhat tight). Agree. Bigger ICANN->RIR allocs, fewer (and aggregated) prefixes to memorize. (...) One thing we should perhaps consider about this (/8s, /12s or /16s) is seeing the % of LIRs that ask/get v6 addresses, in order to make some growth calculation... (For my country, i've recently seen this figure and it is < 20%) Regards, ./Carlos "Networking is fun!" -------------- [http://www.ip6.fccn.pt] http://www.fccn.pt , CMF8-RIPE, CF596-ARIN, Wide Area Network Workgroup F.C.C.N. - Fundacao para a Computacao Cientifica Nacional fax: +351 218472167 From michel at arneill-py.sacramento.ca.us Fri May 23 19:02:30 2003 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Fri, 23 May 2003 10:02:30 -0700 Subject: [lir-wg] RE: [ipv6-wg@ripe.net] Discussion about RIPE-261 Message-ID: <963621801C6D3E4A9CF454A1972AE8F504F81A@server2000.arneill-py.sacramento.ca.us> Gert, > Gert Doering wrote: > - The /23 allocations ICANN -> RIRs are bad, because they lead to > address space fragmentation, and the blocks are too small to do useful > allocation towards the LIRs. Something NEEDS to be changed here. Agree. > So my personal recommendation would be: > - change the /23 allocation boundary ICANN -> RIR to something more > useful, like a /12 or so (a /12 means "512 of them are available, > so we're not yet burning bridges - but a /8 would work as well. > A /16 is already somewhat tight). I don't find this very flexible. If you look at what happened with LACNIC, countries from ARIN were transferred to LACNIC. I expect that when AFRINIC is activated, countries from both RIPE and ARIN will be transferred to AFRINIC. I agree with this goal: > - As a technical reason: people want to be able to filter IPv6 > prefixes by region, like "I only have one uplink that provides me > with US connectivity, so there's no need to carry any US prefixes > in my routing table, I just point a summary down that line". If you want to do this, you might as well do it right in the first place. IMHO, delegating space to a RIR as a single block is a mistake. It would be much more flexible to assign space to countries, and simply say that RIRs have stewardship of the space assigned to countries belonging to them. If a country changes RIRs like we have seen for LACNIC and like we will likely see for AFRINIC, no change in addresses and the geographical summary is preserved. Below is an example interpolated from the work we have done on geographic assignments: http://arneill-py.sacramento.ca.us/ipv6mh/geov6.txt Quick notes: - We are presently talking about PA space; the document mentioned above refers to PI space. However the geographic cutoff collapsed to the country level would not change. - I chose to assign a /8 to the entire world, which can be discussed. This means that after we colonize 255 other planets we have a problem :-) can someone help me with that warp drive please? - What could also be discussed are the details of how this was generated, but I would like to get the _concept_ across then we can talk about the details. Zone Population %G Pop. IANA ---------------- ---------- ------- -------------- China 1284971000 20.91% 2346:0000::/11 Continental Asia 673454413 10.96% 2346:2000::/11 India 1025096000 16.68% 2346:4000::/12 Northern Africa 565854163 9.21% 2346:5000::/12 Asian Islands 488468000 7.95% 2346:6000::/12 Western Europe 423412058 6.89% 2346:7000::/12 North America 318243350 5.18% 2346:8000::/12 South America 350724557 5.71% 2346:9000::/13 Eastern Europe 307858000 5.01% 2346:9800::/13 Middle East 258577000 4.21% 2346:A000::/13 Southern Africa 242566332 3.95% 2346:A800::/13 Central America 175719760 2.86% 2346:B000::/14 Oceania 30568053 0.50% 2346:B400::/16 ---------------- ---------- ------- -------------- World 6145512686 100.00% 2346:0000::/8 Example of one zone: Country Population %Z Pop. %G Pop. IANA ------------------- ---------- ------- ------- -------------- United States 285926000 89.85% 4.65% 2346:8000::/13 Canada 1015000 9.75% 0.50% 2346:8800::/17 Hawaii 1224398 0.38% 0.02% 2346:8880::/21 Bermuda 60000 0.02% 0.00% 2346:8888::/24 Greenland 12483 0.00% 0.00% 2346:8889::/24 -------------------- ---------- ------- ------- -------------- Zone: North America 318243350 100.00% 5.18% 2346:8000::/12 Implementing such a system would change the way large(global) LIRs request space from RIRs. As of today, they would typically request one /32 per RIR. For people the size of Sprint, they would then have to request a /32 per country they service and assign space to customers from the correct prefix. What this means to large LIRs is a large initial number of prefixes, but it's not fundamentally worse than an always-growing number of /32s when IPv6 finally takes off IMHO. For smaller LIRs that service only one country, there would be no change. There would be some impact on the GRT as there would be a "SPRINT-USA" block, an "ATT-USA" block, a "SPRINT-GERMANY" block, an "ATT-GERMANY" block, etc. In other words, what we are looking at is one /32 prefix per country per large LIR, opposed to as many /32s a large LIR would need in the long run anyway. Comments welcome. > - inside that RIR allocation, use the binary chop algorithm > described in RIPE-261 for the RIR->LIR distribution. I'm not familiar with this; would that be something like RFC3531? Michel. From clive at demon.net Mon May 26 10:54:27 2003 From: clive at demon.net (Clive D.W. Feather) Date: Mon, 26 May 2003 09:54:27 +0100 Subject: [lir-wg] Discussion about RIPE-261 In-Reply-To: <5.1.0.14.2.20030526113255.01008900@max.att.net.il> References: <963621801C6D3E4A9CF454A1972AE8F504F81E@server2000.arneill-py.sacramento.ca.us> <5.1.0.14.2.20030526113255.01008900@max.att.net.il> Message-ID: <20030526085427.GR7609@finch-staff-1.thus.net> Hank Nussbacher said: >>> Needless to say, your numbers do not seem to take in any >>> socio-economic factors. > So don't assign wealth. Use some number that has direct influence on IPv6 > usage. Among the possibilities: > - # of computer per capita [...] IPv6 is supposed to last for what, 20 years? 30 years? 40 years? None of these assumptions is going to be valid in this timescale because you have no idea where the economies of countries are going to go. After all, in 1985 none of us would have assumed either the Soviet Union or China would have wanted any IP addresses at all. And people wouldn't even have heard of Kazakhstan. Either population or land area is about the best indicator you're going to get of *eventual* *long-term* demand. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | *** NOTE CHANGE *** Demon Internet | WWW: http://www.davros.org | Fax: +44 870 051 9937 Thus plc | | Mobile: +44 7973 377646 From mansaxel at sunet.se Mon May 26 11:41:30 2003 From: mansaxel at sunet.se (=?ISO-8859-1?Q?M=E5ns_Nilsson?=) Date: Mon, 26 May 2003 11:41:30 +0200 Subject: [lir-wg] RE: [ipv6-wg@ripe.net] Discussion about RIPE-261 In-Reply-To: <4A18F89E-8F46-11D7-857A-000393A638B2@kurtis.pp.se> References: <4A18F89E-8F46-11D7-857A-000393A638B2@kurtis.pp.se> Message-ID: <777180000.1053942090@localhost.besserwisser.org> --On Monday, May 26, 2003 08:50:08 +0200 Kurt Erik Lindqvist wrote: > Without tweaking routing, a more efficient way would be to use the fact > that IPv6 blocks are a lot larger than IPv4 blocks and simply give one > /32 to every LIR. I guess this would only work with RIPE who have the > concepts of LIRs but anyway. Yes, it would be very convenient. I might want to advocate extending it to be "one /32 per 16-bit AS" and have the routing table grow to a whopping 2^16 routes. That must be painful. Surely. 32-bit AS numbers is something I see taken care of by Moore, if we do not find a new routing model, which of course is the elegant way, but for now, brute force does it. -- M?ns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE We're sysadmins. To us, data is a protocol-overhead. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From gert at space.net Mon May 26 14:32:42 2003 From: gert at space.net (Gert Doering) Date: Mon, 26 May 2003 14:32:42 +0200 Subject: [lir-wg] RE: [ipv6-wg@ripe.net] Discussion about RIPE-261 In-Reply-To: <777180000.1053942090@localhost.besserwisser.org>; from mansaxel@sunet.se on Mon, May 26, 2003 at 11:41:30AM +0200 References: <4A18F89E-8F46-11D7-857A-000393A638B2@kurtis.pp.se> <777180000.1053942090@localhost.besserwisser.org> Message-ID: <20030526143242.I67740@Space.Net> Hi, On Mon, May 26, 2003 at 11:41:30AM +0200, M?ns Nilsson wrote: > Yes, it would be very convenient. I might want to advocate extending it to > be "one /32 per 16-bit AS" and have the routing table grow to a whopping > 2^16 routes. That must be painful. Surely. And it doesn't *solve* the policy issue - it will just move it to "who is entitled to get a 16-bit AS number". So I'd be very careful about this "solution". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 54837 (54495) 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 May 26 14:35:33 2003 From: gert at space.net (Gert Doering) Date: Mon, 26 May 2003 14:35:33 +0200 Subject: [lir-wg] Discussion about RIPE-261 In-Reply-To: <20030526085427.GR7609@finch-staff-1.thus.net>; from clive@demon.net on Mon, May 26, 2003 at 09:54:27AM +0100 References: <963621801C6D3E4A9CF454A1972AE8F504F81E@server2000.arneill-py.sacramento.ca.us> <5.1.0.14.2.20030526113255.01008900@max.att.net.il> <20030526085427.GR7609@finch-staff-1.thus.net> Message-ID: <20030526143533.J67740@Space.Net> Hi, On Mon, May 26, 2003 at 09:54:27AM +0100, Clive D.W. Feather wrote: > Either population or land area is about the best indicator you're going to > get of *eventual* *long-term* demand. I second that. (Hank, why are you opposing/questioning this approach? Are you worried about IPv6 space running out for the "high tech" countries?) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 54837 (54495) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From pekkas at netcore.fi Mon May 26 14:44:27 2003 From: pekkas at netcore.fi (Pekka Savola) Date: Mon, 26 May 2003 15:44:27 +0300 (EEST) Subject: [lir-wg] RE: [ipv6-wg@ripe.net] Discussion about RIPE-261 In-Reply-To: <20030526143242.I67740@Space.Net> Message-ID: On Mon, 26 May 2003, Gert Doering wrote: > On Mon, May 26, 2003 at 11:41:30AM +0200, M?ns Nilsson wrote: > > Yes, it would be very convenient. I might want to advocate extending it to > > be "one /32 per 16-bit AS" and have the routing table grow to a whopping > > 2^16 routes. That must be painful. Surely. > > And it doesn't *solve* the policy issue - it will just move it to "who is > entitled to get a 16-bit AS number". > > So I'd be very careful about this "solution". Totally agree -- in the sense, that IMHO, the registries need to start putting better policies in place to prevent AS number starvation. On the other hand, if we have good policies for ASN's, we could get easy address allocation too with little overheard and additional paperwork.. If we need to go for 32bit ASN's, I consider it a very bad policy failure.. :-( -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From oppermann at pipeline.ch Mon May 26 15:03:24 2003 From: oppermann at pipeline.ch (Andre Oppermann) Date: Mon, 26 May 2003 15:03:24 +0200 Subject: [lir-wg] Discussion about RIPE-261 References: <963621801C6D3E4A9CF454A1972AE8F504F81E@server2000.arneill-py.sacramento.ca.us> <5.1.0.14.2.20030526113255.01008900@max.att.net.il> <20030526085427.GR7609@finch-staff-1.thus.net> Message-ID: <3ED2109C.CB625692@pipeline.ch> "Clive D.W. Feather" wrote: > > Hank Nussbacher said: > >>> Needless to say, your numbers do not seem to take in any > >>> socio-economic factors. > > > So don't assign wealth. Use some number that has direct influence on IPv6 > > usage. Among the possibilities: > > - # of computer per capita > [...] > > IPv6 is supposed to last for what, 20 years? 30 years? 40 years? None of > these assumptions is going to be valid in this timescale because you have > no idea where the economies of countries are going to go. After all, in > 1985 none of us would have assumed either the Soviet Union or China would > have wanted any IP addresses at all. And people wouldn't even have heard of > Kazakhstan. > > Either population or land area is about the best indicator you're going to > get of *eventual* *long-term* demand. Am I the only one who thinks that geographical/population distribution of IP[v6] addresses is a flawed and evil concept in itself? The problem of IPv6 is that is has become an utopian kitchen sink. The current discussion about how to distribute the address space the "right" way is symptomatic for that. Why should an IP address have *any* kind of specific geographic meaning? Is it even smart to have that? Oh, you've got an IP address from Germany, we don't allow access to this server. Oh, you've got an IP address from China, we don't allow access to China critcal information (BBC server)... Can anyone tell me why an IP address should be geograhically significant in this way? Doesn't this open a can of worms of potential abuse all over the place? Why do we try to fix an engineering problem (scaling global routing mesh (BGP)) with unworkable IP address distribution policies??? Even countries change from time to time. See the split from .su to a whole bunch of .ru and so on. When does a "country" deserve it's own IP segement? Is for example Nothern Ireland a country is the sense of IPv6 address assignment? What about East-Timor? What if in 10 years northern Iraq is going to be the Republic of the Kurdes? Do they have to renumber from Iraq and Turkish addresses? What if in 20 years the European Union countries vote to become one nation? Do they have to renumber? Or will you assign by "federal state"? Why don't we just take the E.164 telephony numbering scheme and make IP addresses out of it? It's already country based! Not! What point does it make that we have got an IP address space so large so we can assign an IP number to every grain of sand on this planet if it can't keep the number? IPv6 has a number of fundamental design (I call it over-eager- engineering) flaws. All it should have done is to extend the address length, make the header fields fixed length and aligned. All the other stuff of creating a whole new way of doing networking like header stacking and so on is evil. Especially this does not belong into this layer. We've already got MPLS et al. Don't even get me started on putting routing information into DNS (IPv6 prefix in DNS)... shudder... -- Andre From gert at space.net Mon May 26 15:42:28 2003 From: gert at space.net (Gert Doering) Date: Mon, 26 May 2003 15:42:28 +0200 Subject: [lir-wg] Discussion about RIPE-261 In-Reply-To: <3ED2109C.CB625692@pipeline.ch>; from oppermann@pipeline.ch on Mon, May 26, 2003 at 03:03:24PM +0200 References: <963621801C6D3E4A9CF454A1972AE8F504F81E@server2000.arneill-py.sacramento.ca.us> <5.1.0.14.2.20030526113255.01008900@max.att.net.il> <20030526085427.GR7609@finch-staff-1.thus.net> <3ED2109C.CB625692@pipeline.ch> Message-ID: <20030526154228.L67740@Space.Net> Hi, On Mon, May 26, 2003 at 03:03:24PM +0200, Andre Oppermann wrote: > Can anyone tell me why an IP address should be geograhically > significant in this way? Doesn't this open a can of worms of > potential abuse all over the place? One motivation I can see for it is to permit more-specific announcements inside a region (because it's interesting to find "the shortest way" to the destination network) but to summarize the routing information "from the outside". For us, as a small german ISP, it's not really important who is hooked up where in the US or in the AP region - so a summary route "all this stuff is in the US, send this to our upstream" (simplified) is likely to suit us fine. [..] > Why do we try to fix an engineering problem (scaling global routing > mesh (BGP)) with unworkable IP address distribution policies??? Because nobody came up with a fix to the BGP scalability issues yet...? [..] > What point does it make that we have got an IP address space so > large so we can assign an IP number to every grain of sand on this > planet if it can't keep the number? IPv6 routing, using todays technology, is only going to work if you can have enough hierarchy in the routing system. And yes, this means "renumber". (Apart from that, IPv6 is not about numbering grains of sand :) ) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 54837 (54495) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From hank at att.net.il Mon May 26 16:14:48 2003 From: hank at att.net.il (Hank Nussbacher) Date: Mon, 26 May 2003 17:14:48 +0300 (IDT) Subject: [lir-wg] Discussion about RIPE-261 In-Reply-To: <20030526143533.J67740@Space.Net> Message-ID: On Mon, 26 May 2003, Gert Doering wrote: > Hi, > > On Mon, May 26, 2003 at 09:54:27AM +0100, Clive D.W. Feather wrote: > > Either population or land area is about the best indicator you're going to > > get of *eventual* *long-term* demand. > > I second that. > > (Hank, why are you opposing/questioningthis approach?Are you worried > about IPv6 space running out for the "high tech" countries?) Reverse: are you worried that IPv6 space won't be available for non- "high-tech" countries when they will need it? -Hank > > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations:54837 (54495) > > 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 May 26 16:25:37 2003 From: gert at space.net (Gert Doering) Date: Mon, 26 May 2003 16:25:37 +0200 Subject: [lir-wg] Discussion about RIPE-261 In-Reply-To: ; from hank@att.net.il on Mon, May 26, 2003 at 05:14:48PM +0300 References: <20030526143533.J67740@Space.Net> Message-ID: <20030526162537.P67740@Space.Net> Hi, On Mon, May 26, 2003 at 05:14:48PM +0300, Hank Nussbacher wrote: > > (Hank, why are you opposing/questioningthis approach?Are you worried > > about IPv6 space running out for the "high tech" countries?) > > Reverse: are you worried that IPv6 space won't be available for non- > "high-tech" countries when they will need it? Not acutely worried. But then, *if* we decide to do some kind of distribution on the geographic level, we need to setup "chunks" in advance (to avoid having more than one high-level prefix per "region"). So this scheme should take future development into account - and who are we to say that a country X "will always be poor and under-developed"? Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 54837 (54495) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From chbm at cprm.net Mon May 26 16:29:10 2003 From: chbm at cprm.net (Carlos Morgado) Date: Mon, 26 May 2003 15:29:10 +0100 Subject: [lir-wg] Discussion about RIPE-261 In-Reply-To: <20030526154228.L67740@Space.Net> References: <963621801C6D3E4A9CF454A1972AE8F504F81E@server2000.arneill-py.sacramento.ca.us> <5.1.0.14.2.20030526113255.01008900@max.att.net.il> <20030526085427.GR7609@finch-staff-1.thus.net> <3ED2109C.CB625692@pipeline.ch> <20030526154228.L67740@Space.Net> Message-ID: <20030526142910.GA18229@cprm.net> On Mon, May 26, 2003 at 03:42:28PM +0200, Gert Doering wrote: > Hi, > > On Mon, May 26, 2003 at 03:03:24PM +0200, Andre Oppermann wrote: > > Can anyone tell me why an IP address should be geograhically > > significant in this way? Doesn't this open a can of worms of > > potential abuse all over the place? > > One motivation I can see for it is to permit more-specific announcements > inside a region (because it's interesting to find "the shortest way" > to the destination network) but to summarize the routing information > "from the outside". > So it should be a topological distinction, not geographical. If the Internet has taught us something so far it's geo space means *nothing*. Traffic from USA to Africa will likely go through Europe and in some cases be under EU IP space. However, in other cases with will be under ARIN IP space and go directly to Africa. How does that work with summarizing based on geo region ? Closer to home, I may have a LINX peering with Foo ISP but not with Bar ISP so my traffic goes Europe -> US West -> Europe. I am 4000km from both and they are spaced 20m. > For us, as a small german ISP, it's not really important who is hooked > up where in the US or in the AP region - so a summary route "all this > stuff is in the US, send this to our upstream" (simplified) is likely > to suit us fine. > However for us, a smallish portuguese transit provider, it makes a whole of diference details like "where is hotmail.com connected" or "did google move ?" For small, simple setups where IPv4 0/0 is fairly enough this whole aggregation thing is just another detail. For people who actually do traffic engineering stuff like aggregation and geo-localization and (*gar*!) end-to-end route selection is just idiotic. > [..] > > Why do we try to fix an engineering problem (scaling global routing > > mesh (BGP)) with unworkable IP address distribution policies??? > > Because nobody came up with a fix to the BGP scalability issues yet...? > isn't "memory is cheap" the mantra nowadays ? > [..] > > What point does it make that we have got an IP address space so > > large so we can assign an IP number to every grain of sand on this > > planet if it can't keep the number? > > IPv6 routing, using todays technology, is only going to work if you can > have enough hierarchy in the routing system. And yes, this means > "renumber". > Ah. Yes, do tell 500000 customer and 4 diferent billing/provisioning system type ISPs to renumber if they change upstream provider. That will make you popular :) Now really, I rather have IPv6 now, evaluate the real practical problems and fix them than spending years not having IPv6 cause the fix to a would-be problem introduces unworkable problems itself. -- 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 dr at cluenet.de Mon May 26 16:32:14 2003 From: dr at cluenet.de (Daniel Roesen) Date: Mon, 26 May 2003 16:32:14 +0200 Subject: [lir-wg] Discussion about RIPE-261 In-Reply-To: <20030526154228.L67740@Space.Net>; from gert@space.net on Mon, May 26, 2003 at 03:42:28PM +0200 References: <963621801C6D3E4A9CF454A1972AE8F504F81E@server2000.arneill-py.sacramento.ca.us> <5.1.0.14.2.20030526113255.01008900@max.att.net.il> <20030526085427.GR7609@finch-staff-1.thus.net> <3ED2109C.CB625692@pipeline.ch> <20030526154228.L67740@Space.Net> Message-ID: <20030526163214.A8431@homebase.cluenet.de> On Mon, May 26, 2003 at 03:42:28PM +0200, Gert Doering wrote: > For us, as a small german ISP, it's not really important who is hooked > up where in the US or in the AP region - so a summary route "all this > stuff is in the US, send this to our upstream" (simplified) is likely > to suit us fine. But you will still need to carry the routes in order to support your BGP customers. I doubt that they will be happy with upstream's vision of aggregation at all times... Best regards, Daniel From hank at att.net.il Mon May 26 16:25:48 2003 From: hank at att.net.il (Hank Nussbacher) Date: Mon, 26 May 2003 17:25:48 +0300 (IDT) Subject: [lir-wg] RE: [ipv6-wg@ripe.net] Discussion about RIPE-261 In-Reply-To: Message-ID: On Mon, 26 May 2003, Pekka Savola wrote: > Totally agree -- inthe sense, that IMHO, the registries need to start > putting better policies in place to prevent AS number starvation. > > On the other hand, if we have good policies for ASN's, we could get easy > address allocation too with little overheard and additional paperwork.. > > If we need to go for 32bit ASN's, I consider it a very bad policy > failure.. :-( > I tried to oppose 32 bit ASN in the IETF BGP group. I was ignored by those that felt 32 bit ASNs will happen no matter what. I felt the reason we need 32 bit ASN is only due to LIR laziness in not reclaiming defunct ASNs. I reclaim 10-15 ASNs per year and it is work - many hours of work to reclaim each ASN. The easier path is to just let the defunct ASN or single homed ASN to just continue and ignore it and just ask for more ASNs. That appears to be what the IETF has decided. > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -Hank From gert at space.net Mon May 26 16:35:09 2003 From: gert at space.net (Gert Doering) Date: Mon, 26 May 2003 16:35:09 +0200 Subject: [lir-wg] Discussion about RIPE-261 In-Reply-To: <20030526142910.GA18229@cprm.net>; from chbm@cprm.net on Mon, May 26, 2003 at 03:29:10PM +0100 References: <963621801C6D3E4A9CF454A1972AE8F504F81E@server2000.arneill-py.sacramento.ca.us> <5.1.0.14.2.20030526113255.01008900@max.att.net.il> <20030526085427.GR7609@finch-staff-1.thus.net> <3ED2109C.CB625692@pipeline.ch> <20030526154228.L67740@Space.Net> <20030526142910.GA18229@cprm.net> Message-ID: <20030526163509.Q67740@Space.Net> Hi, On Mon, May 26, 2003 at 03:29:10PM +0100, Carlos Morgado wrote: > Ah. Yes, do tell 500000 customer and 4 diferent billing/provisioning system > type ISPs to renumber if they change upstream provider. That will make you > popular :) If you have 500000 customers, there's no discussion that you can get your own address block (and keep it). The interesting problem is how to make end user (!) multihoming work without putting the burden on everybody *else*. I am NOT interested in seeing 20.000 small multihomed end customers in my routing tables, because in the end everything goes over one of two possible links anyway. > Now really, I rather have IPv6 now, evaluate the real practical problems and fix > them than spending years not having IPv6 cause the fix to a would-be problem > introduces unworkable problems itself. So go and get an allocation :-) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 54837 (54495) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From mansaxel at sunet.se Mon May 26 15:41:35 2003 From: mansaxel at sunet.se (=?ISO-8859-1?Q?M=E5ns_Nilsson?=) Date: Mon, 26 May 2003 15:41:35 +0200 Subject: [lir-wg] RE: [ipv6-wg@ripe.net] Discussion about RIPE-261 In-Reply-To: References: Message-ID: <1009830000.1053956495@localhost.besserwisser.org> --On Monday, May 26, 2003 15:44:27 +0300 Pekka Savola wrote: > On Mon, 26 May 2003, Gert Doering wrote: >> On Mon, May 26, 2003 at 11:41:30AM +0200, M?ns Nilsson wrote: >> > Yes, it would be very convenient. I might want to advocate extending >> > it to be "one /32 per 16-bit AS" and have the routing table grow to a >> > whopping 2^16 routes. That must be painful. Surely. >> >> And it doesn't *solve* the policy issue - it will just move it to "who is >> entitled to get a 16-bit AS number". >> >> So I'd be very careful about this "solution". The only thing that speaks for it, and that is a heavy reason, imho, is that it would get a sizable chunk of native v6 address space deployed, and people could actually use v6, instead of lying to their RIR as they have to do now. Most of the organisations also would manage nicely on only one assignment (ie. one route per AS) unless they were insanely large. It would be a nice "fresh start" of the routing table, but with only known components. It might be that this is enough to make the real issues surface, those we only find by trying.. > Totally agree -- in the sense, that IMHO, the registries need to start > putting better policies in place to prevent AS number starvation. > > On the other hand, if we have good policies for ASN's, we could get easy > address allocation too with little overheard and additional paperwork.. Yup. > If we need to go for 32bit ASN's, I consider it a very bad policy > failure.. :-( Agree. But people seem to vividly state that they are inevitable as soon as I open my mouth about handing out /32 slices to all AS numbers. With 15500 or so ASen visible now, I'd be hard pressed to call them a scarce resource in the short term... -- M?ns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE We're sysadmins. To us, data is a protocol-overhead. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From gert at space.net Mon May 26 16:38:19 2003 From: gert at space.net (Gert Doering) Date: Mon, 26 May 2003 16:38:19 +0200 Subject: [lir-wg] Discussion about RIPE-261 In-Reply-To: <20030526163214.A8431@homebase.cluenet.de>; from dr@cluenet.de on Mon, May 26, 2003 at 04:32:14PM +0200 References: <963621801C6D3E4A9CF454A1972AE8F504F81E@server2000.arneill-py.sacramento.ca.us> <5.1.0.14.2.20030526113255.01008900@max.att.net.il> <20030526085427.GR7609@finch-staff-1.thus.net> <3ED2109C.CB625692@pipeline.ch> <20030526154228.L67740@Space.Net> <20030526163214.A8431@homebase.cluenet.de> Message-ID: <20030526163819.R67740@Space.Net> Hi, On Mon, May 26, 2003 at 04:32:14PM +0200, Daniel Roesen wrote: > On Mon, May 26, 2003 at 03:42:28PM +0200, Gert Doering wrote: > > For us, as a small german ISP, it's not really important who is hooked > > up where in the US or in the AP region - so a summary route "all this > > stuff is in the US, send this to our upstream" (simplified) is likely > > to suit us fine. > > But you will still need to carry the routes in order to support > your BGP customers. I doubt that they will be happy with upstream's > vision of aggregation at all times... Well, yes. If you move up high enough in the routing hierarchy, your downstream customers might want that information, and then you have to carry full tables. Nevertheless I see no good reason to take this option away from people that might benefit from it. If you don't want to use it, there's no big difference in doing the allocations "by regions" (however they might look in the end - I'm not talking about countries, and yes, some border line problems exist) or "just across all regions". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 54837 (54495) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From dr at cluenet.de Mon May 26 16:40:47 2003 From: dr at cluenet.de (Daniel Roesen) Date: Mon, 26 May 2003 16:40:47 +0200 Subject: [lir-wg] Discussion about RIPE-261 In-Reply-To: <20030526142910.GA18229@cprm.net>; from chbm@cprm.net on Mon, May 26, 2003 at 03:29:10PM +0100 References: <963621801C6D3E4A9CF454A1972AE8F504F81E@server2000.arneill-py.sacramento.ca.us> <5.1.0.14.2.20030526113255.01008900@max.att.net.il> <20030526085427.GR7609@finch-staff-1.thus.net> <3ED2109C.CB625692@pipeline.ch> <20030526154228.L67740@Space.Net> <20030526142910.GA18229@cprm.net> Message-ID: <20030526164047.B8431@homebase.cluenet.de> On Mon, May 26, 2003 at 03:29:10PM +0100, Carlos Morgado wrote: > > > Why do we try to fix an engineering problem (scaling global routing > > > mesh (BGP)) with unworkable IP address distribution policies??? > > > > Because nobody came up with a fix to the BGP scalability issues yet...? > > isn't "memory is cheap" the mantra nowadays ? RAM is only a problem for some vendor's gear. The main problem is route convergence. BGP is designed with two assumptions in mind: - many routes - fairly stable topology The more routes, the higher the convergence times... and this is does not scale linear. > Ah. Yes, do tell 500000 customer and 4 diferent billing/provisioning system > type ISPs to renumber if they change upstream provider. That will make you > popular :) :-) Regards, Daniel From chbm at cprm.net Mon May 26 16:56:36 2003 From: chbm at cprm.net (Carlos Morgado) Date: Mon, 26 May 2003 15:56:36 +0100 Subject: [lir-wg] Discussion about RIPE-261 In-Reply-To: <20030526163509.Q67740@Space.Net> References: <963621801C6D3E4A9CF454A1972AE8F504F81E@server2000.arneill-py.sacramento.ca.us> <5.1.0.14.2.20030526113255.01008900@max.att.net.il> <20030526085427.GR7609@finch-staff-1.thus.net> <3ED2109C.CB625692@pipeline.ch> <20030526154228.L67740@Space.Net> <20030526142910.GA18229@cprm.net> <20030526163509.Q67740@Space.Net> Message-ID: <20030526145636.GA18301@cprm.net> On Mon, May 26, 2003 at 04:35:09PM +0200, Gert Doering wrote: > Hi, > > On Mon, May 26, 2003 at 03:29:10PM +0100, Carlos Morgado wrote: > > Ah. Yes, do tell 500000 customer and 4 diferent billing/provisioning system > > type ISPs to renumber if they change upstream provider. That will make you > > popular :) > > If you have 500000 customers, there's no discussion that you can get > your own address block (and keep it). > Granted, that example was a bit extreme :) However, most ISPs/networks tend to fiercely opose renumbering. > The interesting problem is how to make end user (!) multihoming work > without putting the burden on everybody *else*. I am NOT interested in > seeing 20.000 small multihomed end customers in my routing tables, because > in the end everything goes over one of two possible links anyway. > That's cause you only have 2 links. Some people have 20. With 3 diferent routing policies. And that's not even counting costumer links. Geting the Americas, Africa, Europe and Asia routes blows dead bears in that situation. > > Now really, I rather have IPv6 now, evaluate the real practical problems and fix > > them than spending years not having IPv6 cause the fix to a would-be problem > > introduces unworkable problems itself. > > So go and get an allocation :-) > Aparently I'm not big enough. My costumers are though. I'm supposed to get a /48 from one my 5 or 6 upstream providers and then announce it to a number of IXs. It's got to be a brave new Internet when in the name of aggregation upstream providers can't get address space. (but that's another flamewar ;)) -- 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 oppermann at pipeline.ch Mon May 26 16:59:02 2003 From: oppermann at pipeline.ch (Andre Oppermann) Date: Mon, 26 May 2003 16:59:02 +0200 Subject: [lir-wg] Discussion about RIPE-261 References: <963621801C6D3E4A9CF454A1972AE8F504F81E@server2000.arneill-py.sacramento.ca.us> <5.1.0.14.2.20030526113255.01008900@max.att.net.il> <20030526085427.GR7609@finch-staff-1.thus.net> <3ED2109C.CB625692@pipeline.ch> <20030526154228.L67740@Space.Net> Message-ID: <3ED22BB6.5F9BF632@pipeline.ch> Gert Doering wrote: > > Hi, > > On Mon, May 26, 2003 at 03:03:24PM +0200, Andre Oppermann wrote: > > Can anyone tell me why an IP address should be geograhically > > significant in this way? Doesn't this open a can of worms of > > potential abuse all over the place? > > One motivation I can see for it is to permit more-specific announcements > inside a region (because it's interesting to find "the shortest way" > to the destination network) but to summarize the routing information > "from the outside". How often did your routing policy change over the last seven years? How often do you point a default route towards one of your upstreams? Does is matter if only a holy batch of ISPs are allowed to run real routing at all? Since when has geography anything to do with network topology? Routing is not about the shortest path, it's about the cheapest path along the policies of the AS it is passing through? > For us, as a small german ISP, it's not really important who is hooked > up where in the US or in the AP region - so a summary route "all this > stuff is in the US, send this to our upstream" (simplified) is likely > to suit us fine. Yes, not every ISP is a small german ISP... You try to fix an routing protocol issue at the network level. Major mistake. Things like this are normally not handled on the data plane, they are handled on the control plane. Which means routing protocol. So we are back at BGP. > [..] > > Why do we try to fix an engineering problem (scaling global routing > > mesh (BGP)) with unworkable IP address distribution policies??? > > Because nobody came up with a fix to the BGP scalability issues yet...? Hmmm... Moore's law? If I remember correctly ten years ago your average (backbone) router had a Mbyte of RAM. Today 128MB is average and more 256MB is quite commmon. CPUs have also come a great way since then. Effectively there is nothing preventing a global BGP routing system from having 500'000 prefixes and 65'000 AS (except of course the price tag of a Cisco box with some old M68k processor). We don't have a BGP scalability issue as such at all. We are now at BGPv4, which means there have been some previous iterations in the matrix. What do we need for BGPv5? More AS numbers. What else? More CPU and more RAM to store more AS number and IP prefixes. > [..] > > What point does it make that we have got an IP address space so > > large so we can assign an IP number to every grain of sand on this > > planet if it can't keep the number? > > IPv6 routing, using todays technology, is only going to work if you can > have enough hierarchy in the routing system. And yes, this means > "renumber". And how is that different from IPv4 + NAT? I hardly see any IPv6 "routing system" at all. You are making a very big mistake by just looking at today's structure and needs. Going from there is never giving you a scaleable and adaptive network for the future. Why don't you take your current IPv6 ideas and (virtually) put them on top of the Internet ten years ago? See what happens? Keep everything on it's level and don't move routing policy from the policy level to the forwarding level. It won't work. Also have a look at every month of the last 10 years. Watch how the Internet, the link capacity, the CPU power, the memory sizes and so on have developed. How many times had the harddisk bus IDE/ATA to be extended to acomodate the new drive capacities? In 1993 I was the proud owner of a i386sx16MHz PC with 1MB of RAM. Today I've got two GB of RAM in the very PC I'm writing this email on. What the heck, I've could even stick four GB in there, it's only ?320 nowadays. About the price of an average high level 3d graphics card for gaming. The hardest thing is always to stick to the simplest principles. That is why so many greatly engineered things fail. What has made the current IPv4 Internet scale to the level we see today? I'm not only talking about the routing but also new applications like WWW/HTTP, Napster, Peer-to-Peer and so on. Think about it and see how many of those simple principles are being broken by todays IPv6 state of affairs (plus all the nice proposals out there for fixing problems we didn't even had before)? > (Apart from that, IPv6 is not about numbering grains of sand :) ) Ok, but what is it about then? I haven't found an advantage of IPv6 over IPv4 yet that would gain me anything (easy of use, cheaper, less work, etc). -- Andre From gert at space.net Mon May 26 17:03:32 2003 From: gert at space.net (Gert Doering) Date: Mon, 26 May 2003 17:03:32 +0200 Subject: [lir-wg] Discussion about RIPE-261 In-Reply-To: <20030526145636.GA18301@cprm.net>; from chbm@cprm.net on Mon, May 26, 2003 at 03:56:36PM +0100 References: <963621801C6D3E4A9CF454A1972AE8F504F81E@server2000.arneill-py.sacramento.ca.us> <5.1.0.14.2.20030526113255.01008900@max.att.net.il> <20030526085427.GR7609@finch-staff-1.thus.net> <3ED2109C.CB625692@pipeline.ch> <20030526154228.L67740@Space.Net> <20030526142910.GA18229@cprm.net> <20030526163509.Q67740@Space.Net> <20030526145636.GA18301@cprm.net> Message-ID: <20030526170331.T67740@Space.Net> Hi, On Mon, May 26, 2003 at 03:56:36PM +0100, Carlos Morgado wrote: [..] > > The interesting problem is how to make end user (!) multihoming work > > without putting the burden on everybody *else*. I am NOT interested in > > seeing 20.000 small multihomed end customers in my routing tables, because > > in the end everything goes over one of two possible links anyway. > > That's cause you only have 2 links. Some people have 20. With 3 diferent > routing policies. And that's not even counting costumer links. > Geting the Americas, Africa, Europe and Asia routes blows dead bears in > that situation. As I've already replied to Daniel Roesen: if you're big enough, you might need to carry even the far-distant more specifics. But then you need to buy "the big routers" anyway, just due to interface speed reasons. And again: not wanting to do something doesn't mean you have to take away the possibility to do so from everybody else, unless there is good technical reason against it. [..] > > So go and get an allocation :-) > > Aparently I'm not big enough. My costumers are though. Have you sent in a formal request to the RIPE hostmasters? > I'm supposed to get a /48 from one my 5 or 6 upstream providers and > then announce it to a number of IXs. > It's got to be a brave new Internet when in the name of aggregation > upstream providers can't get address space. > (but that's another flamewar ;)) I'm not going to revive that discussion - this *is* why we're working on the policy (on the global-v6 list) and have the proposal to change the "200 customers" requirement. Right now we're talking about a specific proposal (RIPE-261) and should try to keep the discussion focused. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 54837 (54495) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From leo at ripe.net Mon May 26 17:19:14 2003 From: leo at ripe.net (leo vegoda) Date: Mon, 26 May 2003 17:19:14 +0200 Subject: [lir-wg] RE: [ipv6-wg@ripe.net] Discussion about RIPE-261 In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F504F81A@server2000.arneill-py.sacramento.ca.us> References: <963621801C6D3E4A9CF454A1972AE8F504F81A@server2000.arneill-py.sacramento.ca.us> Message-ID: <4wZQd8qyBj0+Ew0T@ripe.net> Michel Py writes: [...] >Implementing such a system would change the way large(global) LIRs >request space from RIRs. As of today, they would typically request one >/32 per RIR. For people the size of Sprint, they would then have to >request a /32 per country they service and assign space to customers >from the correct prefix. It is worth noting that the current IPv6 policy is not restricted to allocating /32s. LIRs moving large numbers of IPv4 customers to IPv6 can receive shorter prefixes: 4.4. Consideration of IPv4 infrastructure Where an existing IPv4 service provider requests IPv6 space for eventual transition of existing services to IPv6, the number of present IPv4 customers may be used to justify a larger request than would be justified if based solely on the IPv6 infrastructure. For this reason, it probably makes sense to take account of existing IPv4 usage when considering this issue. Regards, -- leo vegoda RIPE NCC Registration Services From dr at cluenet.de Mon May 26 17:46:53 2003 From: dr at cluenet.de (Daniel Roesen) Date: Mon, 26 May 2003 17:46:53 +0200 Subject: [lir-wg] Discussion about RIPE-261 In-Reply-To: <20030526170331.T67740@Space.Net>; from gert@space.net on Mon, May 26, 2003 at 05:03:32PM +0200 References: <963621801C6D3E4A9CF454A1972AE8F504F81E@server2000.arneill-py.sacramento.ca.us> <5.1.0.14.2.20030526113255.01008900@max.att.net.il> <20030526085427.GR7609@finch-staff-1.thus.net> <3ED2109C.CB625692@pipeline.ch> <20030526154228.L67740@Space.Net> <20030526142910.GA18229@cprm.net> <20030526163509.Q67740@Space.Net> <20030526145636.GA18301@cprm.net> <20030526170331.T67740@Space.Net> Message-ID: <20030526174653.A8926@homebase.cluenet.de> On Mon, May 26, 2003 at 05:03:32PM +0200, Gert Doering wrote: > As I've already replied to Daniel Roesen: if you're big enough, you might > need to carry even the far-distant more specifics. But then you need to > buy "the big routers" anyway, just due to interface speed reasons. No, more or less every BGP customer wants full routes. You assume that BGP customers with smallish bandwidths don't have a need for really _full_ routes. I think quite the contrary is true... the smaller the customer, the more he wants/needs to do traffic engineering. Best regards, daniel From gert at space.net Mon May 26 18:56:58 2003 From: gert at space.net (Gert Doering) Date: Mon, 26 May 2003 18:56:58 +0200 Subject: [lir-wg] Discussion about RIPE-261 In-Reply-To: <20030526174653.A8926@homebase.cluenet.de>; from dr@cluenet.de on Mon, May 26, 2003 at 05:46:53PM +0200 References: <963621801C6D3E4A9CF454A1972AE8F504F81E@server2000.arneill-py.sacramento.ca.us> <5.1.0.14.2.20030526113255.01008900@max.att.net.il> <20030526085427.GR7609@finch-staff-1.thus.net> <3ED2109C.CB625692@pipeline.ch> <20030526154228.L67740@Space.Net> <20030526142910.GA18229@cprm.net> <20030526163509.Q67740@Space.Net> <20030526145636.GA18301@cprm.net> <20030526170331.T67740@Space.Net> <20030526174653.A8926@homebase.cluenet.de> Message-ID: <20030526185658.W67740@Space.Net> Hi, On Mon, May 26, 2003 at 05:46:53PM +0200, Daniel Roesen wrote: [..] > No, more or less every BGP customer wants full routes. You > assume that BGP customers with smallish bandwidths don't have a > need for really _full_ routes. I think quite the contrary is > true... the smaller the customer, the more he wants/needs to do > traffic engineering. I'm not going to argue that now, because that's a decision everybody has to do for his network - and if his customers do not like that, they will go to the competition. Nevertheless, let's get back to the basic question - how shall we go ahead: [ ] continue the IANA->RIR->LIR allocation as it is now [ ] accept RIPE-261 [ ] allocate bigger chunks IANA->RIR (/8 ?) and inside those chunks, use a binary chop algorithm similar to the one described in RIPE-261 [ ] go for a full multi-level regional distribution, down to "one /32 per LIR per country" (as detailed by Michael Py) [ ] something else I do like a good rant as much as anybody else, but "BGP is broken" and "you don't understand the way the Internet will work in 10 years" will not really help us *get there*. So please try to confine the discussion to this topic, and try to get consensus how to move on. There's no way to solve all problems in one big step. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 54837 (54495) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From michel at arneill-py.sacramento.ca.us Mon May 26 19:38:02 2003 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Mon, 26 May 2003 10:38:02 -0700 Subject: [lir-wg] Discussion about RIPE-261 Message-ID: <963621801C6D3E4A9CF454A1972AE8F506712A@server2000.arneill-py.sacramento.ca.us> Folks, [consolidated answers] > Hank Nussbacher wrote: > So don't assign wealth. I never did. > Use some number that has direct influence on IPv6 > usage. Among the possibilities: > - # of computer per capita This would definitely have a direct bearing on IPv6 usage, but is subject to change a lot more rapidly than population. In China for example, I have seen some projections that say the number of connected computers per capita will be multiplied by 100 in the next 10 years. Compare this with the growth of the Chinese population. I don't remember you giving specific reasons why allocation based on population is bad. > Clive D.W. Feather wrote: > Either population or land area is about the best indicator you're > going to get of *eventual* *long-term* demand. I agree. I picked population because IPv6 usage is tied to human activity. The fact of the matter is that unless there are tremendous changes I don't see a lot of human activity in deserts, oceans and ice caps. >> Andre Oppermann wrote: >> Can anyone tell me why an IP address should be geograhically >> significant in this way? Doesn't this open a can of worms of >> potential abuse all over the place? > Gert Doering wrote: > One motivation I can see for it is to permit more-specific > announcements inside a region (because it's interesting to > find "the shortest way" to the destination network) but to > summarize the routing information "from the outside". > For us, as a small german ISP, it's not really important who > is hooked up where in the US or in the AP region - so a > summary route "all this stuff is in the US, send this to > our upstream" (simplified) is likely to suit us fine. I agree and I will add to this that even if you don't have the more-specific announcements the geography could be used to take an educated guess at traffic engineering. Example: - You buy transit from to bigger ISPs, A and B. ISP A has dark fiber all over the place but not too much L3 infrastructure and they backhaul your circuit to Paris which is their main hub. You know that ISP B has a large number of peers in an IXP in Germany where lots of ISPs also peer. - If you have no specific route to a prefix, it makes sense to send all traffic to German prefixes to ISP B, because the likeliness of ISP B having a shorter connection is greater. > But then, *if* we decide to do some kind of distribution on > the geographic level, we need to setup "chunks" in advance > (to avoid having more than one high-level prefix per "region"). > So this scheme should take future development into account - > and who are we to say that a country X "will always be poor > and under-developed"? Agree. > Leo Vegoda wrote: > It is worth noting that the current IPv6 policy is not > restricted to allocating /32s. LIRs moving large numbers > of IPv4 customers to IPv6 can receive shorter prefixes: > [..] > For this reason, it probably makes sense to take account > of existing IPv4 usage when considering this issue. It does indeed. Michel. From chbm at cprm.net Mon May 26 19:58:19 2003 From: chbm at cprm.net (Carlos Morgado) Date: Mon, 26 May 2003 18:58:19 +0100 Subject: [lir-wg] Discussion about RIPE-261 In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F506712A@server2000.arneill-py.sacramento.ca.us> References: <963621801C6D3E4A9CF454A1972AE8F506712A@server2000.arneill-py.sacramento.ca.us> Message-ID: <20030526175819.GA22414@cprm.net> On Mon, May 26, 2003 at 10:38:02AM -0700, Michel Py wrote: > Folks, > [consolidated answers] > > > Hank Nussbacher wrote: > > So don't assign wealth. > > I never did. > > > Use some number that has direct influence on IPv6 > > usage. Among the possibilities: > > - # of computer per capita > > This would definitely have a direct bearing on IPv6 usage, but is > subject to change a lot more rapidly than population. In China for > example, I have seen some projections that say the number of connected > computers per capita will be multiplied by 100 in the next 10 years. > Compare this with the growth of the Chinese population. > Even computers per capita may be an understatement. I believe at some point GSM people will wake up and realize how easy IPv6 makes the upcoming data services as oposed to 10 million users NAT setups. > > I agree and I will add to this that even if you don't have the > more-specific announcements the geography could be used to take an > educated guess at traffic engineering. Example: > > - You buy transit from to bigger ISPs, A and B. ISP A has dark fiber all > over the place but not too much L3 infrastructure and they backhaul your > circuit to Paris which is their main hub. You know that ISP B has a > large number of peers in an IXP in Germany where lots of ISPs also peer. > > - If you have no specific route to a prefix, it makes sense to send all > traffic to German prefixes to ISP B, because the likeliness of ISP B > having a shorter connection is greater. > This is very valid. However there's the counter example of doing engineering by looking at matrixes of pretty much anonymous traffic flows. And then there's trying to influence the downstream which is hard-to-impossible in the agregated world. And the downstream is what most ISPs traffic engineer - not the upstream. cheers -- 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 michel at arneill-py.sacramento.ca.us Mon May 26 20:18:09 2003 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Mon, 26 May 2003 11:18:09 -0700 Subject: [lir-wg] Discussion about RIPE-261 Message-ID: <963621801C6D3E4A9CF454A1972AE8F504F821@server2000.arneill-py.sacramento.ca.us> My comments about RIPE-261: - I like the fact that the three big RIRs are working together up front. It is full of good intentions. - The "sparse allocation algorithm" or "binary chop algorithm" is trying to re-invent the wheel. Please refer to RFC3531 instead. It is a good idea though. - I don't like the idea of the CAP. > Gert Doering wrote: > Nevertheless, let's get back to the basic question - how > shall we go ahead: My order of preference is (with notes) | [1] go for a full multi-level regional distribution, down to | "one /32 per LIR per country" (as detailed by Michael Py) This still requires some work to be done but has finer aggregation capabilities than the one below. In essence, it is an enhancement of the one below. | [2] allocate bigger chunks IANA->RIR (/8?) and inside those | chunks, use a binary chop algorithm similar to the one | described in RIPE-261 This looks a good option to me. If going this way I would advise including AFRINIC up front in the process even though they have not started yet. | [3] continue the IANA->RIR->LIR allocation as it is now It's not good but it's not bad. | [4] accept RIPE-261 The main reason I put list as my last choice is because I think the size of the CAP (/3) is too big. If we want any special-purpose application we'll have to get out of FP001 which is going to be politically very difficult. If the CAP was a /5 I would have put this option as #3. Michel. From michel at arneill-py.sacramento.ca.us Mon May 26 20:29:19 2003 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Mon, 26 May 2003 11:29:19 -0700 Subject: [lir-wg] Discussion about RIPE-261 Message-ID: <963621801C6D3E4A9CF454A1972AE8F504F822@server2000.arneill-py.sacramento.ca.us> Carlos, > Carlos Morgado wrote: > Even computers per capita may be an understatement. Which is why I propose something based on x times capita. > I believe at some point GSM people will wake up and > realize how easy IPv6 makes the upcoming data services > as oposed to 10 million users NAT setups. No argument here. > And the downstream is what most ISPs traffic engineer > - not the upstream. Mmmm. Hot potato routing is all about traffic engineering the upstream and there still is a lot of this. Michel. From chbm at cprm.net Mon May 26 21:06:00 2003 From: chbm at cprm.net (Carlos Morgado) Date: Mon, 26 May 2003 20:06:00 +0100 Subject: [lir-wg] Discussion about RIPE-261 In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F504F822@server2000.arneill-py.sacramento.ca.us> References: <963621801C6D3E4A9CF454A1972AE8F504F822@server2000.arneill-py.sacramento.ca.us> Message-ID: <20030526190600.GA22556@cprm.net> On Mon, May 26, 2003 at 11:29:19AM -0700, Michel Py wrote: > > > And the downstream is what most ISPs traffic engineer > > - not the upstream. > > Mmmm. Hot potato routing is all about traffic engineering the upstream > and there still is a lot of this. > And keeping your multiple links at an happy 80% is all about being able to announce fragments of your space with diferent prepends. I still think a big chunck of the internet does care about which route is best for them from the PoV of some particular networks. Here I go again straying from the path, sorry Gert :) cheers -- 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 kurtis at kurtis.pp.se Tue May 27 13:03:45 2003 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Tue, 27 May 2003 13:03:45 +0200 Subject: [lir-wg] Discussion about RIPE-261 In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F504F81E@server2000.arneill-py.sacramento.ca.us> Message-ID: >> Without tweaking routing, a more efficient way would be to >> use the fact that IPv6 blocks are a lot larger than IPv4 >> blocks and simply give one /32 to every LIR. > > Then explain me how you achieve Gert's goal? I didn't say I would. > >> I guess this would only work with RIPE who have the >> concepts of LIRs but anyway. > > I don't know how to parse this? All RIRs have the concept of LIR? Well in one way or the other - yes. But every-time I use the term LIR in Asia or the US people get confused and I get told that there is no such thing as a LIR in APNIC/LACNIC/ARIN. - kurtis - From kurtis at kurtis.pp.se Tue May 27 13:05:37 2003 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Tue, 27 May 2003 13:05:37 +0200 Subject: [lir-wg] RE: [ipv6-wg@ripe.net] Discussion about RIPE-261 In-Reply-To: <777180000.1053942090@localhost.besserwisser.org> Message-ID: <254D4F1E-9033-11D7-BACC-000393A638B2@kurtis.pp.se> >> Without tweaking routing, a more efficient way would be to use the >> fact >> that IPv6 blocks are a lot larger than IPv4 blocks and simply give one >> /32 to every LIR. I guess this would only work with RIPE who have the >> concepts of LIRs but anyway. > > Yes, it would be very convenient. I might want to advocate extending > it to > be "one /32 per 16-bit AS" and have the routing table grow to a > whopping > 2^16 routes. That must be painful. Surely. This has been proposed a number of times... > > 32-bit AS numbers is something I see taken care of by Moore, if we do > not > find a new routing model, which of course is the elegant way, but for > now, > brute force does it. ...but the counter argument is that 32-bits are just around the corner. The problem here is that they should be, but if they where we still are looking at at least 3-5 years of deployment. - kurtis - From kurtis at kurtis.pp.se Tue May 27 13:13:50 2003 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Tue, 27 May 2003 13:13:50 +0200 Subject: [lir-wg] Discussion about RIPE-261 In-Reply-To: <3ED2109C.CB625692@pipeline.ch> Message-ID: <4B15C66B-9034-11D7-BACC-000393A638B2@kurtis.pp.se> On m?ndag, maj 26, 2003, at 15:03 Europe/Stockholm, Andre Oppermann wrote: > > Why do we try to fix an engineering problem (scaling global routing > mesh (BGP)) with unworkable IP address distribution policies??? Well said. The problem is that IPv6 doesn't address the problems we are having and we are trying to patch and paint it over with complex allocation policies. Let's fix the problem instead. - kurtis - From kurtis at kurtis.pp.se Tue May 27 13:17:43 2003 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Tue, 27 May 2003 13:17:43 +0200 Subject: [lir-wg] Discussion about RIPE-261 In-Reply-To: <20030526154228.L67740@Space.Net> Message-ID: >> Can anyone tell me why an IP address should be geograhically >> significant in this way? Doesn't this open a can of worms of >> potential abuse all over the place? > > One motivation I can see for it is to permit more-specific > announcements > inside a region (because it's interesting to find "the shortest way" > to the destination network) but to summarize the routing information > "from the outside". > > For us, as a small german ISP, it's not really important who is hooked > up where in the US or in the AP region - so a summary route "all this > stuff is in the US, send this to our upstream" (simplified) is likely > to suit us fine. The problem is then just moved to a) Maintaining your filters b) Maintaining the allocations at the RIR level c) Renumbering d) What happens if you want to tweak your routing policies? e) Your upstream need to carry all the routes if you want to achieve d) > > [..] >> Why do we try to fix an engineering problem (scaling global routing >> mesh (BGP)) with unworkable IP address distribution policies??? > > Because nobody came up with a fix to the BGP scalability issues yet...? With multi6 chair hat on I would say the problem is the opposite. However, we have yet to start working on the overall architecture. But that looks like it might start to happen as well. - kurtis - From kurtis at kurtis.pp.se Tue May 27 13:30:08 2003 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Tue, 27 May 2003 13:30:08 +0200 Subject: [lir-wg] Discussion about RIPE-261 In-Reply-To: <20030526185658.W67740@Space.Net> Message-ID: <91F5316A-9036-11D7-BACC-000393A638B2@kurtis.pp.se> > [ ] continue the IANA->RIR->LIR allocation as it is now No. > [ ] accept RIPE-261 Yes. > [ ] allocate bigger chunks IANA->RIR (/8 ?) and inside those chunks, > use a binary chop algorithm similar to the one described in > RIPE-261 Yes. > [ ] go for a full multi-level regional distribution, down to > "one /32 per LIR per country" (as detailed by Michael Py) No. > I do like a good rant as much as anybody else, but "BGP is broken" and > "you don't understand the way the Internet will work in 10 years" will > not > really help us *get there*. So please try to confine the discussion to > this topic, and try to get consensus how to move on. Agreed. The flaws of IPv6 comes down to not solving the multihomign/routing scaling/world starvation problem. That is an IETF problem, and there is a WG for it. (Ok, so I took the opportunity to do some marketing). - kurtis - From michel at arneill-py.sacramento.ca.us Tue May 27 16:46:01 2003 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Tue, 27 May 2003 07:46:01 -0700 Subject: [lir-wg] Discussion about RIPE-261 Message-ID: <963621801C6D3E4A9CF454A1972AE8F504F828@server2000.arneill-py.sacramento.ca.us> > Kurt Erik Lindqvist wrote: > Agreed. The flaws of IPv6 comes down to not solving the > multihomign/routing scaling/world starvation problem. > That is an IETF problem, and there is a WG for it. For the record, and the following are verifiable _facts_: the IRTF and the IETF have been working on this problem for the last ten years. One of the Area Directors responsible for the multi6 WG has called it the "Titanic". By Kurtis' own account it is going to be 5 to 10 more years before they find a solution, if they do. The WG that Kurtis co-chairs has not even agreed to _requirements_ that were due two years ago; they are calling it recommendations now with zero proposals on the table. Anyone that wants to have a glimpse of what the IETF is going to do for them is encouraged to read Kurtis' own draft: http://www.ietf.org/internet-drafts/draft-kurtis-multihoming-longprefix- 00.txt Which basically says that we should allow /48 prefixes punched from PA space in the Global Routing Table. I am sure the educated reader that subscribes to this list will appreciate, especially smaller LIRs that can't afford a c12416 or M160 to hold a huge routing table. Michel. From chbm at cprm.net Tue May 27 18:34:21 2003 From: chbm at cprm.net (Carlos Morgado) Date: Tue, 27 May 2003 17:34:21 +0100 Subject: [lir-wg] Discussion about RIPE-261 In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F504F828@server2000.arneill-py.sacramento.ca.us> References: <963621801C6D3E4A9CF454A1972AE8F504F828@server2000.arneill-py.sacramento.ca.us> Message-ID: <20030527163421.GA24793@cprm.net> On Tue, May 27, 2003 at 07:46:01AM -0700, Michel Py wrote: (i'm replying here as Kurtis is on this list) > > Anyone that wants to have a glimpse of what the IETF is going to do for > them is encouraged to read Kurtis' own draft: > http://www.ietf.org/internet-drafts/draft-kurtis-multihoming-longprefix- > 00.txt > Which basically says that we should allow /48 prefixes punched from PA > space in the Global Routing Table. I am sure the educated reader that I don't think this is a workable solution. Because: * it doesn't actually solve the problem - in fact it gets worse as you de-aggregate PA space and force it throughout the Internet. I don't see the advantage of announcing PA /48s under other providers as oposed to giving people PI space, I see however problems in a future where /48s starts getting filtered and multihoming is silently broken. * it depends on what ASs 2 hops away from me do. If somewhere along the way someone summarizes my "main" provider's routes sudenly the chunk of Internet behind him will start using the more specific. Don't forget we're talking about selling service here and with this scenario I can't garantee my clients the connectivity I'm selling them will actually be used. * it makes it particularly hard to change providers quickly. By all means this is lock-in to the primary provider. Summing, I think this despite masking the problem in the short run it has enough problems of its own to not be adopted commercially. The document claims, "The third advantage of this model is that this mirrors existing operating practices in the IPv4 world.", not quite - if I allocate a /24 to a costumer they will not announce it to another provider. If they do, the other provider will most likely filter it based on whois/registrar database entries. This could probably be solved for the proposed scenario but it seems like a kludge. The document also mentions RPF - RPF is almost unworkable for multihomed situations where assymetric flow are common. Even in the case of multiple links to the same provider it may not work as traffic engineering will likely create assymetries. > subscribes to this list will appreciate, especially smaller LIRs that > can't afford a c12416 or M160 to hold a huge routing table. > Other people have already mentioned on the list memory/cpu isn't an issue on this day and age. You definitly don't need a c12k to carry a full routing table today. cheers -- 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 michel at arneill-py.sacramento.ca.us Tue May 27 19:14:00 2003 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Tue, 27 May 2003 10:14:00 -0700 Subject: [lir-wg] Discussion about RIPE-261 Message-ID: <963621801C6D3E4A9CF454A1972AE8F504F82A@server2000.arneill-py.sacramento.ca.us> Carlos, > Carlos Morgado wrote: > Other people have already mentioned on the list memory/cpu isn't > an issue on this day and age. You definitly don't need a c12k to > carry a full routing table today. This is not what vendors are saying. I presented just after Jeff Doyle from Juniper 3 weeks ago and he was very specific about this. I extracted that one slide here: http://arneill-py.sacramento.ca.us/ipv6mh/j.ppt Let's face it: I'm sure that Juniper would love to keep selling big routers. They are telling us they can't guarantee they will keep up increasing memory and CPU, so we do have an issue with memory/cpu. Michel. From chbm at cprm.net Tue May 27 19:26:17 2003 From: chbm at cprm.net (Carlos Morgado) Date: Tue, 27 May 2003 18:26:17 +0100 Subject: [lir-wg] Discussion about RIPE-261 Message-ID: <20030527172617.GB24906@cprm.net> On Tue, May 27, 2003 at 10:14:00AM -0700, Michel Py wrote: > > Let's face it: I'm sure that Juniper would love to keep selling big > routers. They are telling us they can't guarantee they will keep up > increasing memory and CPU, so we do have an issue with memory/cpu. > Yeah, that's part of the problem! Now in reality a c7500 will happilly handle full routing. So will a 7200. Even a 3600 given enough memory (and some tender loving care). An old PeCe with a 64M DIMM and zebra will take full routing. But that doesn't sell 512M upgrades for line cards ;) -- 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 oppermann at pipeline.ch Tue May 27 19:56:15 2003 From: oppermann at pipeline.ch (Andre Oppermann) Date: Tue, 27 May 2003 19:56:15 +0200 Subject: [lir-wg] Discussion about RIPE-261 References: <963621801C6D3E4A9CF454A1972AE8F504F82A@server2000.arneill-py.sacramento.ca.us> Message-ID: <3ED3A6BF.CD9C677@pipeline.ch> Michel Py wrote: > > Carlos, > > > Carlos Morgado wrote: > > Other people have already mentioned on the list memory/cpu isn't > > an issue on this day and age. You definitly don't need a c12k to > > carry a full routing table today. > > This is not what vendors are saying. I presented just after Jeff Doyle > from Juniper 3 weeks ago and he was very specific about this. I > extracted that one slide here: > http://arneill-py.sacramento.ca.us/ipv6mh/j.ppt > > Let's face it: I'm sure that Juniper would love to keep selling big > routers. They are telling us they can't guarantee they will keep up > increasing memory and CPU, so we do have an issue with memory/cpu. Haha!! A little bit a weak argument, isn't it? What if a router vendor would tell you he couldn't guarantee to keep up with PPS performance if we are going to introduce 10Gig Ethernet??? No way. Also the Internet doesn't get more instable with more prefixes. (In)stability is dependent on the number and stability of links carrying the prefixes. So you have to measure instablity in percent of the of the entire prefix pool. I don't think we are doing worse than ten years ago despite an increase of 12'000 percent in prefixes. Actually the transit network seems to be very stable. There are some problems with leaf customers who've got BGP but are imcompetent at it and shoot themselfes in the foot. But that is a competence problem. (Maybe we a BGP drivers license?) Convergence time is not dependent on the number of prefixes either. It's dependent on the min, mean and max radius/diameter of the network (in terms of hops which carry the full table modulo the intra-AS BGP reflector mesh). Ok, maybe some vendors implementation gets instable with more prefixes but that's a bug and thus an engineering problem. -- Andre From gert at space.net Tue May 27 21:07:05 2003 From: gert at space.net (Gert Doering) Date: Tue, 27 May 2003 21:07:05 +0200 Subject: [lir-wg] Discussion about RIPE-261 In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F504F828@server2000.arneill-py.sacramento.ca.us>; from michel@arneill-py.sacramento.ca.us on Tue, May 27, 2003 at 07:46:01AM -0700 References: <963621801C6D3E4A9CF454A1972AE8F504F828@server2000.arneill-py.sacramento.ca.us> Message-ID: <20030527210705.S67740@Space.Net> Hi, On Tue, May 27, 2003 at 07:46:01AM -0700, Michel Py wrote: > Which basically says that we should allow /48 prefixes punched from PA > space in the Global Routing Table. I am sure the educated reader that > subscribes to this list will appreciate, especially smaller LIRs that > can't afford a c12416 or M160 to hold a huge routing table. While I'm not sure whether it's "the perfect solution" (it isn't), I disagree with you on the "evilishness" of it. There are two dangers with it: - it might blow up the IPv6 table to the number of currently active IPv4 ASes. That would be about 15.000, and shouldn't hurt any decent router (yes, my 2503 will not like it, but then, I always knew that it's not a proper core router anymore). - if there really starts a big run to IPv6 multihoming, it will increase pressure on the AS allocation/conservation policy (and we'll eventually run out of 16 bit ASNs, which would hurt). Also, it might not even be sufficient - some companies might still want to be "really, really independent" and get their own address block. The *benefit* of "/48 multihoming" is that you can filter those routes if you don't want to see them - then your routers will send packets down the /32 road, and eventually hit a router that knows about the /48 (which is why I consider this approach superior to "everybody gets a independent prefix", which I can't properly aggregate). Which brings us back to "why I want ONE regional block per RIR" - that's why. (I do not think we need to discuss this - I won't be able to convince you, you won't be able to convince me - I just wanted to point out that there are more points of view to this) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 54837 (54495) 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 Tue May 27 21:15:11 2003 From: gert at space.net (Gert Doering) Date: Tue, 27 May 2003 21:15:11 +0200 Subject: [lir-wg] Discussion about RIPE-261 In-Reply-To: <3ED3A6BF.CD9C677@pipeline.ch>; from oppermann@pipeline.ch on Tue, May 27, 2003 at 07:56:15PM +0200 References: <963621801C6D3E4A9CF454A1972AE8F504F82A@server2000.arneill-py.sacramento.ca.us> <3ED3A6BF.CD9C677@pipeline.ch> Message-ID: <20030527211511.U67740@Space.Net> Hi, On Tue, May 27, 2003 at 07:56:15PM +0200, Andre Oppermann wrote: > Also the Internet doesn't get more instable with more prefixes. Can you back that claim by some facts or research studies? I know that people at a couple of universities are researching into this right now, and currently the primary assumption is "yes, it does" (because the sheer size of the lists is longer, routers *need* more time to process them, delaying convergence, plus every now and then you hit a boundary that causes BGP flaps due to out-of-memory and/or necessary router upgrades). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 54837 (54495) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From michel at arneill-py.sacramento.ca.us Tue May 27 22:14:27 2003 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Tue, 27 May 2003 13:14:27 -0700 Subject: [lir-wg] Discussion about RIPE-261 Message-ID: <963621801C6D3E4A9CF454A1972AE8F504F82B@server2000.arneill-py.sacramento.ca.us> Gert, > Gert Doering wrote: > The *benefit* of "/48 multihoming" is that you can filter those > routes if you don't want to see them - then your routers will > send packets down the /32 road, and eventually hit a router > that knows about the /48 (which is why I consider this approach > superior to "everybody gets a independent prefix", which I can't > properly aggregate). This does _not_ work in at least two cases: - If someone implements RPF checks and someone else filters. - If the primary ISP (the one that announces the /32) dies. The site is dead as well. This is the #1 reason why organizations do multihome: they want to be up even if their primary ISP tanks. Please look at the following (4 slides, very short) http://arneill-py.sacramento.ca.us/ipv6mh/pa_holes.ppt Then come back to me and tell me that PA holes and filtering work together. The slides should be self-explanatory but they were designed for live presentation. I do welcome questions. Michel. From gert at space.net Tue May 27 23:32:39 2003 From: gert at space.net (Gert Doering) Date: Tue, 27 May 2003 23:32:39 +0200 Subject: [lir-wg] Discussion about RIPE-261 In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F504F82B@server2000.arneill-py.sacramento.ca.us>; from michel@arneill-py.sacramento.ca.us on Tue, May 27, 2003 at 01:14:27PM -0700 References: <963621801C6D3E4A9CF454A1972AE8F504F82B@server2000.arneill-py.sacramento.ca.us> Message-ID: <20030527233239.V67740@Space.Net> hi, On Tue, May 27, 2003 at 01:14:27PM -0700, Michel Py wrote: > > The *benefit* of "/48 multihoming" is that you can filter those > > routes if you don't want to see them - then your routers will > > send packets down the /32 road, and eventually hit a router > > that knows about the /48 (which is why I consider this approach > > superior to "everybody gets a independent prefix", which I can't > > properly aggregate). > > This does _not_ work in at least two cases: > > - If someone implements RPF checks and someone else filters. Strict RPF check will break as soon as you have asymmetric routing, which you usually can't avoid if you filter on upstream/peering lines. So doing that in the first place is a bad idea. The RPF filter belongs on the customer line (and will not hurt in this case). > - If the primary ISP (the one that announces the /32) dies. The site is > dead as well. This is the #1 reason why organizations do multihome: they > want to be up even if their primary ISP tanks. If the ISP dies hard enough so that their prefix will disappear, they won't be visible to people that filter on /32 boundaries and have no fallback default route to one of their upstreams. But so what. If one of their upstream ISPs messes up seriously enough, they can always hurt their downstream customers' routing (by announcing the prefix and then blackholing internally, for example). > Please look at the following (4 slides, very short) > http://arneill-py.sacramento.ca.us/ipv6mh/pa_holes.ppt > Then come back to me and tell me that PA holes and filtering work > together. > The slides should be self-explanatory but they were designed for live > presentation. I do welcome questions. Can't check those slides right now, now proprietary-file-format-viewer available, sorry. Will check tomorrow. But besides your slides, experience from "what's out there" (in IPv4 land) shows that the concept of PA holes works pretty well - for certain kinds of problems. It's not a panacea, but neither is any other approach. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 54837 (54495) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From oppermann at pipeline.ch Tue May 27 23:46:46 2003 From: oppermann at pipeline.ch (Andre Oppermann) Date: Tue, 27 May 2003 23:46:46 +0200 Subject: [lir-wg] Discussion about RIPE-261 References: <963621801C6D3E4A9CF454A1972AE8F504F82A@server2000.arneill-py.sacramento.ca.us> <3ED3A6BF.CD9C677@pipeline.ch> <20030527211511.U67740@Space.Net> Message-ID: <3ED3DCC6.FFB77770@pipeline.ch> Gert Doering wrote: > > Hi, > > On Tue, May 27, 2003 at 07:56:15PM +0200, Andre Oppermann wrote: > > Also the Internet doesn't get more instable with more prefixes. > > Can you back that claim by some facts or research studies? No, but by mathematical logic. Can you claim otherwise? > I know that people at a couple of universities are researching into > this right now, and currently the primary assumption is "yes, it does" > (because the sheer size of the lists is longer, routers *need* more time > to process them, delaying convergence, plus every now and then you > hit a boundary that causes BGP flaps due to out-of-memory and/or > necessary router upgrades). The "assumption" that it hurts does not count because I "assume" that it does not hurt. Please provide scientific facts as you have asked me to. Longer lists are fine. You just need more processing power. That's why we have Moore's law. If I look at the advantages (see IEEE and ACM magazines) forwarding table implementations in soft- as well as hardware which have been made because of higher PPS needs/wants I don't have any worries that all these well-paid bright people come up with some optimisations which will take us well beyond one million active prefixes and triple the path. Simple engineering again. If they can do it with PPS and wirespeed they should be able to do it with BGP processing as well. A router that has a bug or runs out of memory will always happen. There is no silver bullet against that. It's the percentage of the entire prefix/path base that matters. If you are looking at absolute number you will definatly see an increase, no doubt. If I remember correctly a Juniper has got a Mobile-PII 450MHz CPU as control processor. Hardly on par with today's available processing power. You could have said your same stuff five years ago when we had 70'000 prefixes. But now we have 127'000 prefixes it still works fine as before. My "assumptions" are based on the mathematical properties of the BGP distance vector routing protocol. Of course the larger the mean AS distance grows, the more "instable" in itself it gets. But that is normal Internet growth. Or do you want stop the Internet to grow? Is it large enough? Do we need more ISPs? We see a very common occurence here. The moment an open and very competitive market has matured, the (remaining) players start (whether implicit or explicit) to hinder new entrancies into the market. This is either done by denial of (direct) access or policy barriers. Do we have enough ISPs? Do we have enough parties with routable IP address space? All the "technical" arguments I've heard so far simply define the status quo (currently available and deployed routers developed three to five years ago) as end of all means. From which the rational of no more space for significant growth (prefixes/ASs) is derived from. This is wrong. If we would have applied the same rational at a time when a T3 backbone was gigantic, then we'd never been here to have this conversation today. Do we? -- Andre Oppermann From michel at arneill-py.sacramento.ca.us Wed May 28 00:20:07 2003 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Tue, 27 May 2003 15:20:07 -0700 Subject: [lir-wg] Discussion about RIPE-261 Message-ID: <963621801C6D3E4A9CF454A1972AE8F504F82F@server2000.arneill-py.sacramento.ca.us> Andre, > Andre Oppermann wrote: > We see a very common occurence here. The moment an open > and very competitive market has matured, the (remaining) > players start (whether implicit or explicit) to hinder > new entrancies into the market. This is either done by > denial of (direct) access or policy barriers. You get it backwards. It is in the best interest of the router cartel to continue riding Moore's law forever and end up with a billion entries in the routing table which would allow them to keep renewing the installed router base every other year because naturally they cap memory and CPU in every model for the sole of being able to sell you a stinkin' new one two years later. And yes I am a stockholder of the router cartel. The reason they say they can't guarantee being able to ride Moore's law is because they see a risk that it happens. The very fact that they are actually looking at alternatives to Moore is worrisome. Michel. From oppermann at pipeline.ch Wed May 28 01:00:50 2003 From: oppermann at pipeline.ch (Andre Oppermann) Date: Wed, 28 May 2003 01:00:50 +0200 Subject: [lir-wg] Discussion about RIPE-261 References: <963621801C6D3E4A9CF454A1972AE8F504F82F@server2000.arneill-py.sacramento.ca.us> Message-ID: <3ED3EE22.ACEBDA1D@pipeline.ch> Michel Py wrote: > > Andre, > > > Andre Oppermann wrote: > > We see a very common occurence here. The moment an open > > and very competitive market has matured, the (remaining) > > players start (whether implicit or explicit) to hinder > > new entrancies into the market. This is either done by > > denial of (direct) access or policy barriers. > > You get it backwards. It is in the best interest of the router cartel to > continue riding Moore's law forever and end up with a billion entries in > the routing table which would allow them to keep renewing the installed > router base every other year because naturally they cap memory and CPU > in every model for the sole of being able to sell you a stinkin' new one > two years later. And yes I am a stockholder of the router cartel. > > The reason they say they can't guarantee being able to ride Moore's law > is because they see a risk that it happens. The very fact that they are > actually looking at alternatives to Moore is worrisome. No, it's only hot air. Why don't they claim to look at alternatives to 10Gig (and 100Gig) Ethernet? After all it's a damn high packet per second rate they have to sustain to do wirespeed... And doing just 1Gig is so much easier and don't have to develope any new chips. It's all already done. Yea, why not just fire all engineers. We don't need them anyway. There is nothing new to be developed. The limit is reached! There is no freaking way that a limit on routing table processing table power has been reached when no such limit is claimed for the packet forwarding rate. I don't care if they have to develop ASICs for that purpose too. BTW, you've shown me one statement (actually it's more of a thought, and we don't see the context of the slide) from one little Juniper engineer. I might get just remotely worried if all CTOs of all router manufactors (who claim to have real backbone/core routers with full ISP useable BGP) write in an SEC filing for their company that they've reached the end and limit of router development (or at least of the control plane functionality). Take a deep breath and then hold it... until... until... until... you take another one... -- Andre From michel at arneill-py.sacramento.ca.us Wed May 28 02:14:27 2003 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Tue, 27 May 2003 17:14:27 -0700 Subject: [hm-staff] Re: [lir-wg] Discussion about RIPE-261 Message-ID: <963621801C6D3E4A9CF454A1972AE8F504F832@server2000.arneill-py.sacramento.ca.us> >>> Michel Py wrote: >>> I don't know how to parse this? All RIRs have the concept of LIR? >> Kurt Erik Lindqvist wrote: >> Well in one way or the other - yes. But every-time I use the >> term LIR in Asia or the US people get confused and I get told that >> there is no such thing as a LIR in APNIC/LACNIC/ARIN. > Anne Lord wrote: > Just for the record... > The term LIR is used in the APNIC region and is documented > in the APNIC IPv4 policy document in Section 4.1.3. > http://www.apnic.net/docs/policy/add-manage-policy.html Just for the record too... The acronym LIR is also used and documented by ARIN at the link below and in many other documents (do a search on the main page...) http://www.arin.net/policy/ipv6_policy.html If my memory is correct, the IPv6 policy quoted above is actually common to all RIRs. Michel. From michel at arneill-py.sacramento.ca.us Wed May 28 02:41:11 2003 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Tue, 27 May 2003 17:41:11 -0700 Subject: [lir-wg] Discussion about RIPE-261 Message-ID: <963621801C6D3E4A9CF454A1972AE8F504F831@server2000.arneill-py.sacramento.ca.us> > BTW, you've shown me one statement (actually it's more of > a thought, and we don't see the context of the slide) The entire slide set is here: http://arneill-py.sacramento.ca.us/ipv6mh/IPv6%20Transition.ppt http://arneill-py.sacramento.ca.us/ipv6mh/IPv6%20Transition.pdf Single slide we were talking about: http://arneill-py.sacramento.ca.us/ipv6mh/j.ppt http://arneill-py.sacramento.ca.us/ipv6mh/j.pdf > from one little Juniper engineer. Who are you to say this? Jeff Doyle is not one little Juniper engineer. Michel. From dr at cluenet.de Wed May 28 02:42:29 2003 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 28 May 2003 02:42:29 +0200 Subject: [lir-wg] Discussion about RIPE-261 In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F504F82F@server2000.arneill-py.sacramento.ca.us>; from michel@arneill-py.sacramento.ca.us on Tue, May 27, 2003 at 03:20:07PM -0700 References: <963621801C6D3E4A9CF454A1972AE8F504F82F@server2000.arneill-py.sacramento.ca.us> Message-ID: <20030528024229.C21691@homebase.cluenet.de> On Tue, May 27, 2003 at 03:20:07PM -0700, Michel Py wrote: > You get it backwards. It is in the best interest of the router cartel to > continue riding Moore's law forever and end up with a billion entries in > the routing table which would allow them to keep renewing the installed > router base every other year because naturally they cap memory and CPU > in every model for the sole of being able to sell you a stinkin' new one > two years later. And yes I am a stockholder of the router cartel. This depends of your choice of vendor. Vendor J's routers took "only" a 266MHz CPU and 256M RAM (please correct me if I'm wrong here with the historic data) a couple of years back, but now you can put a new routing engine with 600MHz and 2G RAM into them without buying a whole new router and interfaces. And I guess when the next generation of REs comes out, you can put them into all boxes down to the smallest one [of the series] as well. People might want to consider such things in their shopping checklist. Not every vendor plays those games (to this extend). Regards, Daniel From michel at arneill-py.sacramento.ca.us Wed May 28 02:47:53 2003 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Tue, 27 May 2003 17:47:53 -0700 Subject: [lir-wg] Discussion about RIPE-261 Message-ID: <963621801C6D3E4A9CF454A1972AE8F504F833@server2000.arneill-py.sacramento.ca.us> Gert, > Gert Doering wrote: > If the ISP dies hard enough so that their prefix will disappear, Which is the #1 reason to multihome. > they won't be visible to people that filter on /32 boundaries > and have no fallback default route to one of their upstreams. Which is precisely why long prefixes with filtering do NOT work. > Can't check those slides right now, now proprietary-file > format-viewer available, sorry. Will check tomorrow. Even hard-core pro-unix Microsoft haters use powerpoint, but I did make a pdf too. http://arneill-py.sacramento.ca.us/ipv6mh/pa_holes.pdf http://arneill-py.sacramento.ca.us/ipv6mh/pa_holes.ppt Michel. From gert at space.net Wed May 28 09:28:12 2003 From: gert at space.net (Gert Doering) Date: Wed, 28 May 2003 09:28:12 +0200 Subject: [lir-wg] Discussion about RIPE-261 In-Reply-To: <3ED3EE22.ACEBDA1D@pipeline.ch>; from oppermann@pipeline.ch on Wed, May 28, 2003 at 01:00:50AM +0200 References: <963621801C6D3E4A9CF454A1972AE8F504F82F@server2000.arneill-py.sacramento.ca.us> <3ED3EE22.ACEBDA1D@pipeline.ch> Message-ID: <20030528092812.X67740@Space.Net> Hi, On Wed, May 28, 2003 at 01:00:50AM +0200, Andre Oppermann wrote: [..] > There is no freaking way that a limit on routing table processing > table power has been reached when no such limit is claimed for the > packet forwarding rate. I don't care if they have to develop ASICs > for that purpose too. OK, so you have made your point known. All the technical worries people have been voicing are just lies driven by ugly monopolistic tendencies. How exactly does this help us in the current context? What are your answers to the question on the table: RIPE-261? What are your answers to how a global IPv6 policy and an AS number policy should look like? Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 54837 (54495) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From chbm at cprm.net Wed May 28 11:45:44 2003 From: chbm at cprm.net (Carlos Morgado) Date: Wed, 28 May 2003 10:45:44 +0100 Subject: [lir-wg] Discussion about RIPE-261 In-Reply-To: <20030527210705.S67740@Space.Net> References: <963621801C6D3E4A9CF454A1972AE8F504F828@server2000.arneill-py.sacramento.ca.us> <20030527210705.S67740@Space.Net> Message-ID: <20030528094544.GE26210@cprm.net> On Tue, May 27, 2003 at 09:07:05PM +0200, Gert Doering wrote: > The *benefit* of "/48 multihoming" is that you can filter those routes > if you don't want to see them - then your routers will send packets > down the /32 road, and eventually hit a router that knows about the /48 This is exactly why providers will have an hard time selling this to customers. 'It may work, it might not, depends, you have no control and neither do we'. -- 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 chbm at cprm.net Wed May 28 11:55:48 2003 From: chbm at cprm.net (Carlos Morgado) Date: Wed, 28 May 2003 10:55:48 +0100 Subject: [lir-wg] Discussion about RIPE-261 In-Reply-To: <20030527233239.V67740@Space.Net> References: <963621801C6D3E4A9CF454A1972AE8F504F82B@server2000.arneill-py.sacramento.ca.us> <20030527233239.V67740@Space.Net> Message-ID: <20030528095548.GF26210@cprm.net> On Tue, May 27, 2003 at 11:32:39PM +0200, Gert Doering wrote: > If the ISP dies hard enough so that their prefix will disappear, they > won't be visible to people that filter on /32 boundaries and have no > fallback default route to one of their upstreams. > > But so what. If one of their upstream ISPs messes up seriously enough, > they can always hurt their downstream customers' routing (by announcing > the prefix and then blackholing internally, for example). > (short, that's not how stuff works) Again, I thought the point was making commercial IPv6 multihoming work. This is all fine and dandy on 6bone but my clients will not pay me for a backup link that won't work when the primary provider goes down. No pay, no multihoming. No multihoming no commercial offering. No commercial offering, no happy fun end-to-end IPv6. Game set and match. (and yes, this is even more true for hosting than home users) > Total number of prefixes smaller than registry allocations: 54837 (54495) > I'm sorry, you were talking about PA holes ? cheers -- 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 Wed May 28 13:07:08 2003 From: gert at space.net (Gert Doering) Date: Wed, 28 May 2003 13:07:08 +0200 Subject: [lir-wg] Discussion about RIPE-261 In-Reply-To: <20030528094544.GE26210@cprm.net>; from chbm@cprm.net on Wed, May 28, 2003 at 10:45:44AM +0100 References: <963621801C6D3E4A9CF454A1972AE8F504F828@server2000.arneill-py.sacramento.ca.us> <20030527210705.S67740@Space.Net> <20030528094544.GE26210@cprm.net> Message-ID: <20030528130708.D67740@Space.Net> Hi, On Wed, May 28, 2003 at 10:45:44AM +0100, Carlos Morgado wrote: > On Tue, May 27, 2003 at 09:07:05PM +0200, Gert Doering wrote: > > > The *benefit* of "/48 multihoming" is that you can filter those routes > > if you don't want to see them - then your routers will send packets > > down the /32 road, and eventually hit a router that knows about the /48 > > This is exactly why providers will have an hard time selling this to > customers. 'It may work, it might not, depends, you have no control and > neither do we'. One of us us confused about this, and it's not me. A /48 from an aggregate is MUCH MORE reliable than a /48 that has no fallback aggregate. If the latter is filtered (or flap-dampened, or "lost" due to bad as-path filters, or however), you're dead. If the former is lost, you can always send packets in the direction of the aggregate, and at a certain proximity, the /48 will be visible again and be used for proper packet delivery. Besides this, I hope you're not selling *any* service related to Internet connectivity to your customers with the claim that you have any control about things more than two AS hops away from your network...? Because you haven't. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 54837 (54495) 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 Wed May 28 14:02:52 2003 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Wed, 28 May 2003 14:02:52 +0200 Subject: [lir-wg] Discussion about RIPE-261 In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F504F828@server2000.arneill-py.sacramento.ca.us> Message-ID: <4EEBDCB2-9104-11D7-A9CA-000393A638B2@kurtis.pp.se> >> This is way off-topic and I apologies for this. >> Kurt Erik Lindqvist wrote: >> Agreed. The flaws of IPv6 comes down to not solving the >> multihomign/routing scaling/world starvation problem. >> That is an IETF problem, and there is a WG for it. > > For the record, and the following are verifiable _facts_: the IRTF and > the IETF have been working on this problem for the last ten years. No one will disagree with you. The multi6 WG have certainly not delivered and that is not a secret. There are a number of reasons for that. However, I took over as co-chair with one of the goals to make it move forward, and we seem to be starting. In order to make your mail somewhat fair, it is also worth pointing out that to my knowledge Michel disagrees with multi6, and thinks it should be closed down. I am not clear on what you want to do instead to solve the problem except your own MHAP proposal. Michel started his own mailinglist, which AFAI can tell have not reach any more consensus than multi6 have. > One > of the Area Directors responsible for the multi6 WG has called it the > "Titanic". By Kurtis' own account it is going to be 5 to 10 more years > before they find a solution, if they do. You are now putting words in my mouth. I said that it would take us 5-10 years before we have a solution widely deployed. The same goes for most solutions I have seen proposed. > The WG that Kurtis co-chairs > has not even agreed to _requirements_ that were due two years ago; they > are calling it recommendations now with zero proposals on the table. I am not sure we have been reading the same mailinglist, but the current discussions are around how to limit the number of proposals and how to group them. If you like it or not, a solution to the multi6 problem will require an overall architecture. And that needs to fit with the rest of the Internet and what is going on in genereal. > > Anyone that wants to have a glimpse of what the IETF is going to do for > them is encouraged to read Kurtis' own draft: > http://www.ietf.org/internet-drafts/draft-kurtis-multihoming- > longprefix- > 00.txt > Picking out one single personal draft does not say anything about what the IETF will do for anyone. I have never said this proposal is perfect, far from it. Michel have his own personal opinion and agenda. That is fine. I prefer disagreeing with Michel working on his own proposal outside the IETF and getting it implemented and not standardized instead of people not working on this problem at all. - kurtis - -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 174 bytes Desc: not available URL: From chbm at cprm.net Wed May 28 15:24:02 2003 From: chbm at cprm.net (Carlos Morgado) Date: Wed, 28 May 2003 14:24:02 +0100 Subject: [lir-wg] Discussion about RIPE-261 In-Reply-To: <20030528130708.D67740@Space.Net> References: <963621801C6D3E4A9CF454A1972AE8F504F828@server2000.arneill-py.sacramento.ca.us> <20030527210705.S67740@Space.Net> <20030528094544.GE26210@cprm.net> <20030528130708.D67740@Space.Net> Message-ID: <20030528132402.GA26556@cprm.net> On Wed, May 28, 2003 at 01:07:08PM +0200, Gert Doering wrote: > Hi, > > On Wed, May 28, 2003 at 10:45:44AM +0100, Carlos Morgado wrote: > > On Tue, May 27, 2003 at 09:07:05PM +0200, Gert Doering wrote: > > > > > The *benefit* of "/48 multihoming" is that you can filter those routes > > > if you don't want to see them - then your routers will send packets > > > down the /32 road, and eventually hit a router that knows about the /48 > > > > This is exactly why providers will have an hard time selling this to > > customers. 'It may work, it might not, depends, you have no control and > > neither do we'. > > One of us us confused about this, and it's not me. > > A /48 from an aggregate is MUCH MORE reliable than a /48 that has no > fallback aggregate. If the latter is filtered (or flap-dampened, or > "lost" due to bad as-path filters, or however), you're dead. If the > former is lost, you can always send packets in the direction of the > aggregate, and at a certain proximity, the /48 will be visible again > and be used for proper packet delivery. > Ok, I wasn't clear - I was strictly speaking about broken up PA space, not PA /48 vs. PI /48. You're right, if people per rule filter at /32 PI /48 is worse. If people per rule filter at /48 (which seems to be a requirement for this scheme to work) then /48 PI is better as it permits traffic engineering by the multihomed network. I mean, if you multihome and know for a fact at least half of the internet won't see one of your links (either because of filters or sumarization) what's the point ? If you do know /48s will indeed be visible by most of the internet using PI results in the same number of entries as PA, allows better control by the multihomed network and given a carefull allocation policy (now that IPv6 space is plenty and sparse) allows to grow the /48(s) into bigger allocations with minimal disruption. > Besides this, I hope you're not selling *any* service related to Internet > connectivity to your customers with the claim that you have any control > about things more than two AS hops away from your network...? Because > you haven't. > No, I'm selling in technical good faith. I currently take steps to maximize the quality of the transit I sell considering the current IPv4 framework and current practices. In my opinion however with the /48 PA method I can't in good faith sell the same level of service. cheers -- 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 plzak at arin.net Wed May 28 18:25:53 2003 From: plzak at arin.net (Ray Plzak) Date: Wed, 28 May 2003 12:25:53 -0400 Subject: [lir-wg] RE: [ipv6-wg@ripe.net] Discussion about RIPE-261 In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F504F81A@server2000.arneill-py.sacramento.ca.us> Message-ID: <001001c32535$cf6e42b0$668888c0@arin.net> > > I don't find this very flexible. If you look at what happened with > LACNIC, countries from ARIN were transferred to LACNIC. I expect that > when AFRINIC is activated, countries from both RIPE and ARIN will be > transferred to AFRINIC. In general this did not happen with LACNIC. ARIN had been allocating IPv4 space out of 200 /8. The remainder of the /8 was transferred to LACNIC at activation. ARIN tried to get a separate /23 of v6 space for LACNIC allocations but was refused by ICANN/IANA, hence allocation were made from an ARIN /23. LACNIC has since recieved their own /23 and are working with those ISPs to renumber. In regards to AfriNIC, ARIN has tried to allocate out of a block for just AfriNIC for v4. ARIN requested a separate /23 for v6 but was refused by ICANN/IANA. Ray From michel at arneill-py.sacramento.ca.us Wed May 28 20:15:24 2003 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Wed, 28 May 2003 11:15:24 -0700 Subject: [lir-wg] Discussion about RIPE-261 Message-ID: <963621801C6D3E4A9CF454A1972AE8F504F83E@server2000.arneill-py.sacramento.ca.us> Carlos, > Carlos Morgado wrote: > Again, I thought the point was making commercial IPv6 > multihoming work. This is all fine and dandy on 6bone but > my clients will not pay me for a backup link that won't > work when the primary provider goes down. No pay, no > multihoming. No multihoming no commercial offering. No > commercial offering, no happy fun end-to-end IPv6. Game > set and match. (and yes, this is even more true for > hosting than home users) I could not agree more. > No, I'm selling in technical good faith. I currently take steps > to maximize the quality of the transit I sell considering the > current IPv4 framework and current practices. In my opinion > however with the /48 PA method I can't in good faith sell the > same level of service. Absolutely. Total ISP collapses do happen. All the time. When they do: If you're and ISP, there is nothing worse than the customer getting on your behind asking why the backup solution he has been paying you to provide for over a year did not work. Not only you're going to loose the customer but you're lucky if you don't get sued (in the US at least). If you're the network manager for a customer, you look like an idiot in front of senior management when they ask why the backup did not work. What are you going to tell them? The redundancy solution that I bought was crud in the first place? Michel. From kurtis at kurtis.pp.se Thu May 29 08:06:32 2003 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Thu, 29 May 2003 08:06:32 +0200 Subject: [lir-wg] Discussion about RIPE-261 In-Reply-To: <20030527210705.S67740@Space.Net> Message-ID: > it might blow up the IPv6 table to the number of currently active > IPv4 ASes. That would be about 15.000, and shouldn't hurt any ...and currently that would be a good thing. > decent router (yes, my 2503 will not like it, but then, I always > knew that it's not a proper core router anymore). I've got a Linux kernel for it...;-) > - if there really starts a big run to IPv6 multihoming, it will > increase > pressure on the AS allocation/conservation policy (and we'll > eventually > run out of 16 bit ASNs, which would hurt). We will run out of them anyway, but this might speed things up. But it would also help speed up deployment of IPv6. > Also, it might not even be sufficient - some companies might still want > to be "really, really independent" and get their own address block. Agreed. > > The *benefit* of "/48 multihoming" is that you can filter those routes > if you don't want to see them - then your routers will send packets > down the /32 road, and eventually hit a router that knows about the /48 > (which is why I consider this approach superior to "everybody gets a > independent prefix", which I can't properly aggregate). Which brings > us back to "why I want ONE regional block per RIR" - that's why. Yup. - kurtis - -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 174 bytes Desc: not available URL: From kurtis at kurtis.pp.se Thu May 29 07:59:08 2003 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Thu, 29 May 2003 07:59:08 +0200 Subject: [lir-wg] Discussion about RIPE-261 In-Reply-To: <20030527163421.GA24793@cprm.net> Message-ID: >> Anyone that wants to have a glimpse of what the IETF is going to do >> for >> them is encouraged to read Kurtis' own draft: >> http://www.ietf.org/internet-drafts/draft-kurtis-multihoming- >> longprefix- >> 00.txt >> Which basically says that we should allow /48 prefixes punched from PA >> space in the Global Routing Table. I am sure the educated reader that > > I don't think this is a workable solution. Because: > * it doesn't actually solve the problem - in fact it gets worse as you > Absolutely! > de-aggregate PA space and force it throughout the Internet. I don't > see the advantage of announcing PA /48s under other providers as > oposed to > giving people PI space, I see however problems in a future where /48s > starts getting filtered and multihoming is silently broken. That is one possible scenario. The draft is written from the outset that I am currently more worried that we will never reach 1k routes of IPv6, and that this is a sign of no wider adoption. Trends from Gerts data are showing some improvement, but there is still quite a bit to go. > * it depends on what ASs 2 hops away from me do. If somewhere along the > way someone summarizes my "main" provider's routes sudenly the chunk > of > Internet behind him will start using the more specific. Don't forget > we're > talking about selling service here and with this scenario I can't > garantee > my clients the connectivity I'm selling them will actually be used. Agreed. > * it makes it particularly hard to change providers quickly. By all > means this is lock-in to the primary provider. Agreed. > Summing, I think this despite masking the problem in the short run > it has enough problems of its own to not be adopted commercially. Yes. But it's approach. Seriously I think that what will help us get out of the current dead-lock is a agreed path to a final solution. As I recently said on the multi6 list, I used to believe in a phased approach, but I have shifted and come to realize that the only thing that will work in the end is that we from the start work on the permanent solution. Otherwise we will keep adding patches forever. > > The document claims, > "The third advantage of this model is that this mirrors existing > operating practices in the IPv4 world.", > not quite - if I allocate a /24 to a costumer they will not announce > it to > another provider. If they do, the other provider will most likely > filter > it based on whois/registrar database entries. This could probably be > solved for the proposed scenario but it seems like a kludge. This is not true. This is done quite regularly. - kurtis - -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 174 bytes Desc: not available URL: From kurtis at kurtis.pp.se Thu May 29 08:00:33 2003 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Thu, 29 May 2003 08:00:33 +0200 Subject: [lir-wg] Discussion about RIPE-261 In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F504F82A@server2000.arneill-py.sacramento.ca.us> Message-ID: >> Other people have already mentioned on the list memory/cpu isn't >> an issue on this day and age. You definitly don't need a c12k to >> carry a full routing table today. > > This is not what vendors are saying. I presented just after Jeff Doyle > from Juniper 3 weeks ago and he was very specific about this. I > extracted that one slide here: > http://arneill-py.sacramento.ca.us/ipv6mh/j.ppt > > Let's face it: I'm sure that Juniper would love to keep selling big > routers. They are telling us they can't guarantee they will keep up > increasing memory and CPU, so we do have an issue with memory/cpu. > Other vendors are saying different things. If we stopped overloading BGP with all these other features it would most likely also last a lot longer. - kurtis - -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 174 bytes Desc: not available URL: From kurtis at kurtis.pp.se Thu May 29 09:07:35 2003 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Thu, 29 May 2003 09:07:35 +0200 Subject: [lir-wg] Discussion about RIPE-261 In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F504F82B@server2000.arneill-py.sacramento.ca.us> Message-ID: <3962F0F0-91A4-11D7-8FD0-000393A638B2@kurtis.pp.se> >> The *benefit* of "/48 multihoming" is that you can filter those >> routes if you don't want to see them - then your routers will >> send packets down the /32 road, and eventually hit a router >> that knows about the /48 (which is why I consider this approach >> superior to "everybody gets a independent prefix", which I can't >> properly aggregate). > > This does _not_ work in at least two cases: > > - If someone implements RPF checks and someone else filters. RPF will most likely break with most of the proposed multi6 solutions. > - If the primary ISP (the one that announces the /32) dies. The site is > dead as well. This is the #1 reason why organizations do multihome: > they > want to be up even if their primary ISP tanks. You mean if /48s where filtered? So don't filter ;-) That was the original idea with the proposal... - kurtis - -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 174 bytes Desc: not available URL: From kurtis at kurtis.pp.se Thu May 29 09:12:06 2003 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Thu, 29 May 2003 09:12:06 +0200 Subject: [hm-staff] Re: [lir-wg] Discussion about RIPE-261 In-Reply-To: Message-ID: > Hi! >>>> I guess this would only work with RIPE who have the >>>> concepts of LIRs but anyway. >>> >>> I don't know how to parse this? All RIRs have the concept of LIR? >> >> Well in one way or the other - yes. But every-time I use the term LIR >> in Asia or the US people get confused and I get told that there is no >> such thing as a LIR in APNIC/LACNIC/ARIN. > > Just for the record... > > The term LIR is used in the APNIC region and is documented in the > APNIC IPv4 policy document in Section 4.1.3. I have actually never checked this, but people have repeatedly told me that they didn't know the terminology so I just assumed this. I guess I should have checked. Thanks for telling me though! Best regards, - kurtis - -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 174 bytes Desc: not available URL: From nils at druecke.strg-alt-entf.org Thu May 29 10:26:00 2003 From: nils at druecke.strg-alt-entf.org (Nils Ketelsen) Date: Thu, 29 May 2003 10:26:00 +0200 Subject: [lir-wg] Discussion about RIPE-261 In-Reply-To: ; from kurtis@kurtis.pp.se on Thu, May 29, 2003 at 08:06:32AM +0200 References: <20030527210705.S67740@Space.Net> Message-ID: <20030529102600.A29214@bug> On Thu, May 29, 2003 at 08:06:32AM +0200, Kurt Erik Lindqvist wrote: > > The *benefit* of "/48 multihoming" is that you can filter those routes > > if you don't want to see them - then your routers will send packets > > down the /32 road, and eventually hit a router that knows about the /48 > > (which is why I consider this approach superior to "everybody gets a > > independent prefix", which I can't properly aggregate). Which brings > > us back to "why I want ONE regional block per RIR" - that's why. > Yup. Gert pointed me to this list and I lurked for a while now. But now I want to take my chance and say something about this: I'm on the customers side (not being a LIR, but rather seing it from the other perspective). We currently have our internetaccess at one provider and are quite happy with this most of the time. The only problem is the disaterous commercial situation of some providers. This forced us to change providers a few times now and we are just currently thinking of implementing multihoming. Not because its a better technical solution (this is a nice sideeffect, but not the main reason), but rather to be indepent from the next bankrupt. This is exactly what mutihoming with PA Address Space will not solve. Though I see the technical advantages Gert pointed out (especially bein reachable from an AS filtering small netblocks, this does not provide any solution to the commercial challenges providers are currently facing. So, what we really want is PI addresses. And with the current pratices they just do not aggregate which also is a bad thing. This is why I think the geographical approach already mentioned on the list (one netblock per country, different sizes depending on population) currently is the approach which fits that need best, I believe. Just my 0.02EUR, Nils From chbm at cprm.net Thu May 29 11:32:19 2003 From: chbm at cprm.net (Carlos Morgado) Date: Thu, 29 May 2003 10:32:19 +0100 Subject: [lir-wg] Discussion about RIPE-261 In-Reply-To: <3962F0F0-91A4-11D7-8FD0-000393A638B2@kurtis.pp.se> References: <963621801C6D3E4A9CF454A1972AE8F504F82B@server2000.arneill-py.sacramento.ca.us> <3962F0F0-91A4-11D7-8FD0-000393A638B2@kurtis.pp.se> Message-ID: <20030529093219.GA30097@cprm.net> On Thu, May 29, 2003 at 09:07:35AM +0200, Kurt Erik Lindqvist wrote: > >- If the primary ISP (the one that announces the /32) dies. The site is > >dead as well. This is the #1 reason why organizations do multihome: > >they > >want to be up even if their primary ISP tanks. > > You mean if /48s where filtered? So don't filter ;-) That was the > original idea with the proposal... > You mean, ask google.com upstream provider to not filter you ? Or your provider's provider to not filter google ? :) -- 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 oppermann at pipeline.ch Thu May 29 11:36:16 2003 From: oppermann at pipeline.ch (Andre Oppermann) Date: Thu, 29 May 2003 11:36:16 +0200 Subject: [lir-wg] Discussion about RIPE-261 References: <20030527210705.S67740@Space.Net> <20030529102600.A29214@bug> Message-ID: <3ED5D490.669AD78@pipeline.ch> Nils Ketelsen wrote: > > On Thu, May 29, 2003 at 08:06:32AM +0200, Kurt Erik Lindqvist wrote: > > > > The *benefit* of "/48 multihoming" is that you can filter those routes > > > if you don't want to see them - then your routers will send packets > > > down the /32 road, and eventually hit a router that knows about the /48 > > > (which is why I consider this approach superior to "everybody gets a > > > independent prefix", which I can't properly aggregate). Which brings > > > us back to "why I want ONE regional block per RIR" - that's why. > > Yup. > > Gert pointed me to this list and I lurked for a while now. But now I want to > take my chance and say something about this: I'm on the customers side (not > being a LIR, but rather seing it from the other perspective). > > We currently have our internetaccess at one provider and are quite happy > with this most of the time. The only problem is the disaterous commercial > situation of some providers. This forced us to change providers a few times > now and we are just currently thinking of implementing multihoming. Not > because its a better technical solution (this is a nice sideeffect, but not > the main reason), but rather to be indepent from the next bankrupt. > > This is exactly what mutihoming with PA Address Space will not solve. Though > I see the technical advantages Gert pointed out (especially bein reachable > from an AS filtering small netblocks, this does not provide any solution to > the commercial challenges providers are currently facing. > > So, what we really want is PI addresses. And with the current pratices they > just do not aggregate which also is a bad thing. This is why I think the > geographical approach already mentioned on the list (one netblock per > country, different sizes depending on population) currently is the approach > which fits that need best, I believe. How do you come to that conclusion? Every other PI space will be with another ISP. So even thought you might have everything close together on a "human logic" level there is no way to aggregate the prefixes together in the routing system. Unless of course you want to do it PTT style where one is the one who routes this block. Other than your last paragraph I fully agree on what you describe. Unless there is a convincing way for this independence IPv6 won't fly. -- Andre From nils at druecke.strg-alt-entf.org Thu May 29 12:44:08 2003 From: nils at druecke.strg-alt-entf.org (Nils Ketelsen) Date: Thu, 29 May 2003 12:44:08 +0200 Subject: [lir-wg] Discussion about RIPE-261 In-Reply-To: <3ED5D490.669AD78@pipeline.ch>; from oppermann@pipeline.ch on Thu, May 29, 2003 at 11:36:16AM +0200 References: <20030527210705.S67740@Space.Net> <20030529102600.A29214@bug> <3ED5D490.669AD78@pipeline.ch> Message-ID: <20030529124408.A29837@bug> On Thu, May 29, 2003 at 11:36:16AM +0200, Andre Oppermann wrote: > Nils Ketelsen wrote: > > So, what we really want is PI addresses. And with the current pratices they > > just do not aggregate which also is a bad thing. This is why I think the > > geographical approach already mentioned on the list (one netblock per > > country, different sizes depending on population) currently is the approach > > which fits that need best, I believe. > > How do you come to that conclusion? Every other PI space will be with > another ISP. So even thought you might have everything close together > on a "human logic" level there is no way to aggregate the prefixes > together in the routing system. Unless of course you want to do it > PTT style where one is the one who routes this block. I think in most cases the "human logic level" also works for routing. So I guess many people will carry the complete routingtable for those countries they communicate a lot with (mostly this will be the own country and some nearby, but YMMV) and just have a few aggregates like "send all traffic to $farcountry1 to uplink A, send all for $farcountry2 via uplink B etc". Communication mostly happens in the same way "human logic" does, because in the end its humans initiating the communication. I think this could be a good compromise between every multihomed user has to be in every routing table and ongoing provider dependance. Nils -- Please let us know if your SunSolve visit saved you a call to Sun Support! Access Denied [komplette Auskunft zu einem Patch auf http://sunsolve.sun.com/] From oppermann at pipeline.ch Thu May 29 14:43:42 2003 From: oppermann at pipeline.ch (Andre Oppermann) Date: Thu, 29 May 2003 14:43:42 +0200 Subject: [lir-wg] Discussion about RIPE-261 References: <20030527210705.S67740@Space.Net> <20030529102600.A29214@bug> <3ED5D490.669AD78@pipeline.ch> <20030529124408.A29837@bug> Message-ID: <3ED6007E.79063E54@pipeline.ch> Nils Ketelsen wrote: > > On Thu, May 29, 2003 at 11:36:16AM +0200, Andre Oppermann wrote: > > Nils Ketelsen wrote: > > > > So, what we really want is PI addresses. And with the current pratices they > > > just do not aggregate which also is a bad thing. This is why I think the > > > geographical approach already mentioned on the list (one netblock per > > > country, different sizes depending on population) currently is the approach > > > which fits that need best, I believe. > > > > How do you come to that conclusion? Every other PI space will be with > > another ISP. So even thought you might have everything close together > > on a "human logic" level there is no way to aggregate the prefixes > > together in the routing system. Unless of course you want to do it > > PTT style where one is the one who routes this block. > > I think in most cases the "human logic level" also works for routing. So No, it does not. And that is exactly the point. It never has and probably never will as long as we don't have monopolies in each country. BTW have a look at how the country based E.164 telephony system is implementing number portability... > I guess many people will carry the complete routingtable for those countries > they communicate a lot with (mostly this will be the own country and some > nearby, but YMMV) and just have a few aggregates like "send all traffic to > $farcountry1 to uplink A, send all for $farcountry2 via uplink B etc". No. This could only hold true for maybe a leaf node (non-transit) with two upstreams. Everyone else who is doing any kind of transit will have to carry the full table. I ask you where are the savings? Which network engineer wants to define for each and every $forcountry where it goes? BTW we have that already today. For example you can have a primary uplink (default route) and a secondary uplink with a smaller ISP in your country from where you only import his and his peer prefixes. Under these circumstances even an obsolete 2500 can do BGP routing. > Communication mostly happens in the same way "human logic" does, because in > the end its humans initiating the communication. To decouple exactly this human logic from the technical implementation we have DNS and BGP. For example I'm in Switzerland. Interestingly the website with most hits (blick.ch) is physically placed in Germany and connected with a German ISP who does not even have a single line to Switzerland. This is just one case where your "human logic" assumptions breaks. And the Internet has exactly been designed to separate these layers from each other. It should, it must not matter where your resource is located. > I think this could be a good compromise between every multihomed user has to > be in every routing table and ongoing provider dependance. Nope. It looks like you have never done BGP before. Until you have got some significant experience, I'm sorry to say, you are not fully qualified for discussion on this level. (What about me? Have a look at AO6-RIPE, AS8271 and AS8235). -- Andre From chbm at cprm.net Thu May 29 15:10:34 2003 From: chbm at cprm.net (Carlos Morgado) Date: Thu, 29 May 2003 14:10:34 +0100 Subject: [lir-wg] Discussion about RIPE-261 In-Reply-To: <20030529124408.A29837@bug> References: <20030527210705.S67740@Space.Net> <20030529102600.A29214@bug> <3ED5D490.669AD78@pipeline.ch> <20030529124408.A29837@bug> Message-ID: <20030529131034.GA30396@cprm.net> On Thu, May 29, 2003 at 12:44:08PM +0200, Nils Ketelsen wrote: > > Communication mostly happens in the same way "human logic" does, because in > the end its humans initiating the communication. > I think you put too much faith in www.foo.xy being actually located in XY when in fact it's probably hosted in USA, the images are served by Akamai acording to their own load algorithm and the shop form is submited to a server in the company HQ at country WZ. -- 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 ncc at ripe.net Fri May 30 09:00:49 2003 From: ncc at ripe.net (Paul Rendek) Date: Fri, 30 May 2003 09:00:49 +0200 Subject: [lir-wg] ASO AC - Call for Nominations 2003 - RIPE Region Message-ID: <200305300700.h4U70nIR031865@birch.ripe.net> Call for Nominations: RIPE Representative to the ASO Address Council ___________________________________________________________ This is a call for nominations of individuals from the RIPE region to serve on the ASO Address Council. On 31 December 2003, one RIPE Address Council seat will become vacant and will be filled for the next three years by an individual nominated through this open call. The selection process will involve an open election to be held during the RIPE 46 Meeting in Amsterdam, the Netherlands, being held from 1 - 5 September 2003. * Deadline for nominations: 3 June 2003 * Election scheduled for: 4 September 2003 For full details on the position and how to make a nomination, please refer to: http://www.ripe.net/ripencc/about/regional/aso2003/ and http://www.ripe.net/ripe/wg/lir/adress_council-election.html Best regards, Paul Rendek RIPE NCC From ncc at ripe.net Fri May 30 14:45:21 2003 From: ncc at ripe.net (Paul Rendek) Date: Fri, 30 May 2003 14:45:21 +0200 Subject: [lir-wg] Correction of previous Notice Message-ID: <200305301245.h4UCjLWq015499@birch.ripe.net> CORRECTION TO PREVIOUS NOTICE Call for Nominations: RIPE Representative to the ASO Address Council Dear Colleagues, On 30 May 2003, an announcement from our office regarding the ASO Address Council elections incorrectly stated that the deadline for nominations was 3 June 2003. Please note that the deadline for nominations is 2 August 2003. * Deadline for nominations: 2 August 2003 * Election scheduled for: 4 September 2003 The selection process will involve an open election to be held during the RIPE 46 Meeting in Amsterdam, the Netherlands, being held from 1 - 5 September 2003. For full details on the position and how to make a nomination, please refer to: http://www.ripe.net/ripencc/about/regional/aso2003/ and http://www.ripe.net/ripe/wg/lir/adress_council-election.html We appreciate your understanding and apologise for any confusion caused by the previous notice. Best regards, Paul Rendek RIPE NCC