From leo at ripe.net Wed Aug 1 14:01:15 2001 From: leo at ripe.net (leo vegoda) Date: Wed, 1 Aug 2001 14:01:15 +0200 Subject: 90 IPv6 sub-TLA allocations made Message-ID: <20010801140115.A5144@ripe.net> Dear Colleagues, In 1999 The RIPE NCC and the other Regional Internet Registries (RIRs), ARIN and APNIC, began allocating IPv6 sub-TLAs. According to current policy[1] the bootstrap phase "will only apply until 100 requesting organisations have received allocations of sub-TLA address space". To date, the three RIRs have made 90 sub-TLA allocations[2]. At RIPE 39 in Bologna it was suggested to prolong the bootstrap phase until RIPE 40 if 100 allocations are reached. We will inform the community as soon as 100 IPv6 allocations have been made. Other IPv6 information is available on our web site at . Regards, -- leo vegoda Senior Hostmaster RIPE NCC [1] The Global Provisional IPv6 Assignment and Allocation Policy document is available at [2] Details of the allocations are available from the IPv6 section at . From Andreas.Roehling at lambdanet.net Thu Aug 2 09:40:25 2001 From: Andreas.Roehling at lambdanet.net (Roehling, Andreas) Date: Thu, 2 Aug 2001 09:40:25 +0200 Subject: One question about RIPE Message-ID: <39F27E3F569FD4119EF200508BAF85B9017EBA21@CCGNT30> Hello, We have a customer that has got a range of IP addresses from one Provider (say X) and he now would like to use these addresses via our network. Our sales representatives say it is possible to do it 1) If Provider X is OK 2) If we have got the agreement from RIPE Is it correct ? Would you know which RIPE's form would be used then? Thanks Andreas From gert at space.net Fri Aug 3 10:33:12 2001 From: gert at space.net (Gert Doering) Date: Fri, 3 Aug 2001 10:33:12 +0200 Subject: One question about RIPE In-Reply-To: <39F27E3F569FD4119EF200508BAF85B9017EBA21@CCGNT30>; from Andreas.Roehling@lambdanet.net on Thu, Aug 02, 2001 at 09:40:25AM +0200 References: <39F27E3F569FD4119EF200508BAF85B9017EBA21@CCGNT30> Message-ID: <20010803103312.M19200@Space.Net> Hi, On Thu, Aug 02, 2001 at 09:40:25AM +0200, Roehling, Andreas wrote: > We have a customer that has got a range of IP addresses from one Provider > (say X) and he now would like to use these addresses via our network. > > Our sales representatives say it is possible to do > it > 1) If Provider X is OK > 2) If we have got the agreement from RIPE > > Is it correct ? No. There are two things to distinguish: PA ("provider aggregateable") address space - this can NOT be used with a different ISP. The customer can use it for a transition period, and then it has to be returned to the old ISP. You can see this if you do a whois -h whois.ripe.net
and it returns "status: ASSIGNED PA". PI ("provider independent") address space - this could theoretically be used. You do not have to ask the old ISP or RIPE for permission. You just register the routes in the RIPE database, ask the old ISP to stop announcing them, and start announcing them via BGP. PI space has other disadvantages, though, like "much harder to debug if some goal in the Internet cannot be reached", so we usually recommend to the customer to return his PI space to RIPE and accept PI space from us (unless the PI block is very large and the customer network so complex that it would make renumbering too hard). PI space appears as "status: ASSIGNED PI". > Would you know which RIPE's form would be used then? It might be a good idea to send one of your hostmasters to a RIPE training - all those questions are covered in deep detail there (and it's free!), so you don't have to ask your *sales* people about technical procedures. Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From secondo.gentili at gplvpartners.com Fri Aug 3 10:37:06 2001 From: secondo.gentili at gplvpartners.com (Secondo Gentili) Date: Fri, 3 Aug 2001 10:37:06 +0200 Subject: One question about RIPE References: <39F27E3F569FD4119EF200508BAF85B9017EBA21@CCGNT30> Message-ID: <001f01c11bf7$87897850$011010ac@GENTILI> Andreas, I don't know whether it's possible or not, but you have to consider the effects. Your network will announce the specific (customer) network (e.g. /24), you can't summarize, while provider X, is announcing a summary address for that network since he has the whole block (e.g. /20). This way all the traffic for that customer will flow through your network, because of more specific announce you made. In the other way around (cust. --> internet) your customer can make some load balancing. Hope this help, Secondo ----- Original Message ----- From: "Roehling, Andreas" To: Sent: Thursday, August 02, 2001 9:40 AM Subject: One question about RIPE > Hello, > > We have a customer that has got a range of IP addresses from one Provider > (say X) and he now would like to use these addresses via our network. > > Our sales representatives say it is possible to do > it > 1) If Provider X is OK > 2) If we have got the agreement from RIPE > > Is it correct ? > > Would you know which RIPE's form would be used then? > > Thanks > > Andreas > From ripe-ml at cyberstrider.net Fri Aug 3 10:43:03 2001 From: ripe-ml at cyberstrider.net (Denesh Bhabuta) Date: Fri, 03 Aug 2001 09:43:03 +0100 Subject: One question about RIPE Message-ID: <5.1.0.14.2.20010803094253.02da7d18@mail.own.cyberstrider.net> Andreas At 08:40 02/08/2001, Roehling, Andreas wrote: >We have a customer that has got a range of IP addresses from one Provider >(say X) and he now would like to use these addresses via our network. >Our sales representatives say it is possible to do >it >1) If Provider X is OK >2) If we have got the agreement from RIPE >Is it correct ? This is only correct if the customer is using PI space. If the other provider has assigned PA space to the customer, then they will have to get a new set of addresses from you and renumber their network when they start a service with you. If the customer does have PI space from the other provider then you have to consider the size of the address space the customer is bringing in and whether it is worth *your* effort to route that size of block (say if the customer has a /24) through your network and whether it would be beneficial to the customer. HTH Regards Denesh From gert at space.net Fri Aug 3 10:51:50 2001 From: gert at space.net (Gert Doering) Date: Fri, 3 Aug 2001 10:51:50 +0200 Subject: One question about RIPE In-Reply-To: <20010803103312.M19200@Space.Net>; from gert@space.net on Fri, Aug 03, 2001 at 10:33:12AM +0200 References: <39F27E3F569FD4119EF200508BAF85B9017EBA21@CCGNT30> <20010803103312.M19200@Space.Net> Message-ID: <20010803105150.A39435@Space.Net> Hi, On Fri, Aug 03, 2001 at 10:33:12AM +0200, Gert Doering wrote: > PI ("provider independent") address space - this could theoretically > be used. You do not have to ask the old ISP or RIPE for permission. You > just register the routes in the RIPE database, ask the old ISP to > stop announcing them, and start announcing them via BGP. PI space has > other disadvantages, though, like "much harder to debug if some goal > in the Internet cannot be reached", so we usually recommend to the > customer to return his PI space to RIPE and accept PI space from us This should read "and accept PA space from us". Sorry for the typo. (I've exchanged a few more mails with Andreas in between, and it seems that the issue isn't explained clearly enough in the RIPE LIR course - but in any case it's documented in the "policies and procedures" RIPE document. The network in question is PA space, and the answer is "you can route it for a certain time, if both ISPs agree, but then the PA space HAS to be returned to the ISP it belongs to"). Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From sam.bradford at demon.net Fri Aug 3 10:39:49 2001 From: sam.bradford at demon.net (Sam Bradford) Date: Fri, 3 Aug 2001 09:39:49 +0100 Subject: One question about RIPE In-Reply-To: <39F27E3F569FD4119EF200508BAF85B9017EBA21@CCGNT30>; from Andreas.Roehling@lambdanet.net on Thu, Aug 02, 2001 at 09:40:25AM +0200 References: <39F27E3F569FD4119EF200508BAF85B9017EBA21@CCGNT30> Message-ID: <20010803093949.B80936@demon.net> Andreas.Roehling at lambdanet.net wrot: > We have a customer that has got a range of IP addresses from one Provider > (say X) and he now would like to use these addresses via our network. > > Our sales representatives say it is possible to do > it > 1) If Provider X is OK > 2) If we have got the agreement from RIPE > > Is it correct ? If the address space originates from the RIPE NCC, it depends upon whether the space is Provider Independent (PI) or Provider Aggregatable (PA) address space. (Have a look @ RIPE-217: http://www.ripe.net/ripe/docs/pi-pa.html .) If it's PI address space, then it's your decision as to whether you want to announce it, which may not be advisable depending upon the size of the assignment. (Speak to your Networks team...) > Would you know which RIPE's form would be used then? Not applicable, as the Provider X made the assignment and should have already completed a RIPE-141/219. You wouldn't be making an assignment, therefore no need for any RIPE 'form.' You would need to amend the RIPE db record for the assignment though (route object, maintainter, etc.). HTH. What's the IP assignment? Sam ----------------------------------------------------------------- sam bradford, hostmaster team leader sam.bradford at demon.net Demon Internet / Thus plc . hostmaster at demon.net Tel: +44-845-272-0666 . . http://www.demon.net/ Fax: +44-20-8371-1285 t h u s http://www.thus.net/ From denesh at cyberstrider.net Fri Aug 3 10:39:03 2001 From: denesh at cyberstrider.net (Denesh Bhabuta) Date: Fri, 03 Aug 2001 09:39:03 +0100 Subject: One question about RIPE In-Reply-To: <39F27E3F569FD4119EF200508BAF85B9017EBA21@CCGNT30> Message-ID: <5.1.0.14.2.20010803093453.0256cbe0@mail.own.cyberstrider.net> Andreas At 08:40 02/08/2001, Roehling, Andreas wrote: >We have a customer that has got a range of IP addresses from one Provider >(say X) and he now would like to use these addresses via our network. >Our sales representatives say it is possible to do >it >1) If Provider X is OK >2) If we have got the agreement from RIPE >Is it correct ? This is only correct if the customer is using PI space. If the other provider has assigned PA space to the customer, then they will have to get a new set of addresses from you and renumber their network when they start a service with you. If the customer does have PI space from the other provider then you have to consider the size of the address space the customer is bringing in and whether it is worth *your* effort to route that size of block (say if the customer has a /24) through your network and whether it would be beneficial to the customer. HTH Regards Denesh -- Denesh Bhabuta Chairman, CEO and Principal Consultant Cyberstrider Limited www.cyberstrider.net Internet and E-Commerce: Strategy, Consultancy and Solutions From woeber at cc.univie.ac.at Fri Aug 3 10:59:01 2001 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Fri, 03 Aug 2001 10:59:01 +0200 Subject: One question about RIPE Message-ID: <009FFF93.C4467A74.15@cc.univie.ac.at> Hi Gert, >PI ("provider independent") address space - this could theoretically >be used. You do not have to ask the old ISP or RIPE for permission. You >just register the routes in the RIPE database, ask the old ISP to >stop announcing them, and start announcing them via BGP. PI space has >other disadvantages, though, like "much harder to debug if some goal >in the Internet cannot be reached", so we usually recommend to the >customer to return his PI space to RIPE and accept PI space from us ^^ I guess this should be "PA" here !? ______________/ >(unless the PI block is very large and the customer network so complex >that it would make renumbering too hard). Cheers, 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A catholic church ad sign near Maryborough, QLD:"Where Miracles Happen" From nurani at ripe.net Fri Aug 3 11:42:41 2001 From: nurani at ripe.net (Nurani Nimpuno) Date: Fri, 03 Aug 2001 11:42:41 +0200 Subject: One question about RIPE In-Reply-To: Message from "Roehling, Andreas" of "Thu, 02 Aug 2001 09:40:25 +0200." <39F27E3F569FD4119EF200508BAF85B9017EBA21@CCGNT30> Message-ID: <200108030942.f739gfH22596@birch.ripe.net> Hi Andreas, I'll try to shed some light on this. First of all. There are no forms needed for routing addresses. Only if you are *requesting addresses* on behalf of your customer you need to fill in the IP request form at: http://www.ripe.net/ripe/docs/iprequestform.html Your routing decisions do not fall under RIPE NCC's responsibility. There are some recommendations however that can be found in the current Policy Document: http://www.ripe.net/ripe/docs/ir-policies-procedures.html Recommendations specific to Provider Independent (PI) and Provider Aggregatable (PA) address space are outlined in RIPE-127: http://www.ripe.net/ripe/docs/pi-pa.html In short, a PA Assignment is a range within a larger aggregate (a PA Allocation). A PI Assignment is an address range separately assigned to an end-user. If the customer has Provider Independent address space, it is your decision whether you want to route the addresses. As for PA Address space, ISPs are recommended to make contractual agreements with their customers, clarifying that the customers are required to renumber, should they change providers. Respecting these agreements, another ISP should naturally not accept to announce their PA address range separately to the Internet. However, it is also possible to multi-home by having a PA address range announced through two providers. If the PA addresses come from ISP A's allocation, the customer would have to agree with ISP B to announce that range separately. ISP A would also have to announce the range as a more specific route together with their aggregate. I hope this clarified the issue. If you have any further questions, please don't hesitate to write to . Kind regards, Nurani +------------------------------------+ | Nurani Nimpuno | | Internet Address Policy Manager | | RIPE Network Co-ordination Centre | | http://www.ripe.net | +------------------------------------+ "Roehling, Andreas" writes: * Hello, * * We have a customer that has got a range of IP addresses from one Provider * (say X) and he now would like to use these addresses via our network. * * Our sales representatives say it is possible to do * it * 1) If Provider X is OK * 2) If we have got the agreement from RIPE * * Is it correct ? * * Would you know which RIPE's form would be used then? * * Thanks * * Andreas * * From tim at rdsnet.ro Fri Aug 3 12:53:47 2001 From: tim at rdsnet.ro (Bogdan Surdu) Date: Fri, 3 Aug 2001 13:53:47 +0300 (EEST) Subject: selling PA as PI Message-ID: Hi, I'm working for a ISP in Romania which is also a LIR. The biggest LIR in Romania RNC (ro.rnc) received a /15 PA block from RIPE last month. They are selling prefixes (yes selling, they charge different amounts for different space: $50 for a /28 up to $230 for a /24) to almost anyone who wants IPs, even they are not connected to RNC. Basically they sell the PA space as PI, since they are not advertising the PA block and the prefixes are announced in Internet by other ISPs. 80.96/15 is not the only block sold as PI space, they have many PA blocks distributed to customers connected to other ISPs (for example our customers have about 60 * /24 prefixes from 217.156/17 PA block allocated to RNC). What can we do to stop this practice? inetnum: 80.96.0.0 - 80.97.255.255 netname: RO-RNC-20010705 descr: National Institute for R|&D in Informatics descr: Provider Local Registry country: RO admin-c: ES16 tech-c: CH7396-RIPE status: ALLOCATED PA mnt-by: RIPE-NCC-HM-MNT mnt-lower: AS3233-MNT mnt-routes: AS3233-MNT changed: hostmaster at ripe.net 20010705 source: RIPE -- Bogdan Surdu Romania Data Systems S.A. E-mail: tim at rdsnet.ro Tel: +40 1 30 10 850 Fax: +40 1 30 10 851 -------------------------------------------------------------------------- Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such a case, you should destroy this message and kindly notify the sender by reply e-mail. From nurani at ripe.net Fri Aug 3 13:52:46 2001 From: nurani at ripe.net (Nurani Nimpuno) Date: Fri, 03 Aug 2001 13:52:46 +0200 Subject: selling PA as PI In-Reply-To: Message from Bogdan Surdu of "Fri, 03 Aug 2001 13:53:47 +0300." Message-ID: <200108031152.f73BqkH16814@birch.ripe.net> Dear Bogdan, Thank you for bringing this to our attention. The RIPE NCC has an auditing service that we provide to the community. The auditing activity was set in place to promote the consistent and fair application of IP Address policies. The activity is focused around helping the LIRs to understand and follow the correct policies and procedures. The RIPE NCC will first discuss the issue with the LIR involved and outline the correct policies and procedure. Most audits are done by random selection, but there is also the possibility of requesting an audit. LIRs can approach the RIPE NCC if they suspect that another LIR is violating the address policies set in place by the Internet community. For more information about the Audit Activity, please refer to: http://www.ripe.net/rs/audit/ and RIPE Document: "RIPE NCC Consistency and Auditing Activity" at: http://www.ripe.net/ripe/docs/auditing.html As you already know, IP Addresses are not to be considered property as stated in RIPE Document:" Charging by Local Internet Registries": http://www.ripe.net/ripe/docs/ripe-152.html Again, thank you for bringing this to our attention. The RIPE NCC will look into the matter and contact the LIR in question. For any other issues of this kind, please write to . Kind regards, Nurani -- +------------------------------------+ | Nurani Nimpuno | | Internet Address Policy Manager | | RIPE Network Co-ordination Centre | | http://www.ripe.net | +------------------------------------+ Bogdan Surdu writes: * * Hi, * * I'm working for a ISP in Romania which is also a LIR. The biggest LIR in * Romania RNC (ro.rnc) received a /15 PA block from RIPE last month. They * are selling prefixes (yes selling, they charge different amounts for differe * nt * space: $50 for a /28 up to $230 for a /24) to almost anyone who wants IPs, * even they are not connected to RNC. Basically they sell the PA space as * PI, since they are not advertising the PA block and the prefixes are * announced in Internet by other ISPs. * 80.96/15 is not the only block sold as PI space, they have many PA * blocks distributed to customers connected to other ISPs (for example our * customers have about 60 * /24 prefixes from 217.156/17 PA block allocated * to RNC). * What can we do to stop this practice? * * * inetnum: 80.96.0.0 - 80.97.255.255 * netname: RO-RNC-20010705 * descr: National Institute for R|&D in Informatics * descr: Provider Local Registry * country: RO * admin-c: ES16 * tech-c: CH7396-RIPE * status: ALLOCATED PA * mnt-by: RIPE-NCC-HM-MNT * mnt-lower: AS3233-MNT * mnt-routes: AS3233-MNT * changed: hostmaster at ripe.net 20010705 * source: RIPE * * * -- * Bogdan Surdu * * Romania Data Systems S.A. * E-mail: tim at rdsnet.ro * Tel: +40 1 30 10 850 * Fax: +40 1 30 10 851 * * ------------------------------------------------------------------- ------- * Privileged/Confidential Information may be contained in this message. If * you are not the addressee indicated in this message (or responsible for * delivery of the message to such person), you may not copy or deliver this * message to anyone. In such a case, you should destroy this message and * kindly notify the sender by reply e-mail. * * * From hostmaster at bw.nextra.de Fri Aug 3 13:46:21 2001 From: hostmaster at bw.nextra.de (Hostmaster/Elmar K. Bins) Date: Fri, 3 Aug 2001 13:46:21 +0200 Subject: selling PA as PI In-Reply-To: ; from tim@rdsnet.ro on Fri, Aug 03, 2001 at 01:53:47PM +0300 References: Message-ID: <20010803134621.A25133@detebe.org> tim at rdsnet.ro (Bogdan Surdu) wrote: > > Hi, > > I'm working for a ISP in Romania which is also a LIR. The biggest LIR in > Romania RNC (ro.rnc) received a /15 PA block from RIPE last month. They > are selling prefixes (yes selling, they charge different amounts for different > space: $50 for a /28 up to $230 for a /24) to almost anyone who wants IPs, > even they are not connected to RNC. Basically they sell the PA space as > PI, since they are not advertising the PA block and the prefixes are > announced in Internet by other ISPs. > 80.96/15 is not the only block sold as PI space, they have many PA > blocks distributed to customers connected to other ISPs (for example our > customers have about 60 * /24 prefixes from 217.156/17 PA block allocated > to RNC). > What can we do to stop this practice? Filter the prefixes. Elmar. -- -- http://www.nextra.de/ -- [ What's next. ] --- hostmaster at nextra.de -- Nextra Germany | Hostmaster Dept. | Hostmaster-of-the-day Communication Service | Bornheimer Str. 26a | Tel +49 228 96929-0 Provider GmbH & Co. KG | D-53111 Bonn | Fax +49 69 638 09090 ------------------------------------------------------------------------ From jhma at KPNQwest.net Mon Aug 6 16:08:12 2001 From: jhma at KPNQwest.net (James Aldridge) Date: Mon, 06 Aug 2001 16:08:12 +0200 Subject: 90 IPv6 sub-TLA allocations made In-Reply-To: Your message of "Wed, 01 Aug 2001 14:01:15 +0200." <20010801140115.A5144@ripe.net> Message-ID: leo vegoda wrote: > Dear Colleagues, > > In 1999 The RIPE NCC and the other Regional Internet Registries > (RIRs), ARIN and APNIC, began allocating IPv6 sub-TLAs. > > According to current policy[1] the bootstrap phase "will only > apply until 100 requesting organisations have received allocations > of sub-TLA address space". > > To date, the three RIRs have made 90 sub-TLA allocations[2]. > > At RIPE 39 in Bologna it was suggested to prolong the bootstrap > phase until RIPE 40 if 100 allocations are reached. > > We will inform the community as soon as 100 IPv6 allocations > have been made. > > Other IPv6 information is available on our web site at > . Of course, there would be at least one more sub-TLA allocated if the IPv4 rules for supernational registries were to be applied to IPv6 instead of restricting these to only having a single sub-TLA allocation... :-( James -- James Aldridge, Senior Network Engineer (IP Architecture) KPNQwest, Singel 540, 1017 AZ Amsterdam, NL Tel: +31 70 379 37 03; GSM: +31 65 370 87 07 From woeber at cc.univie.ac.at Wed Aug 8 13:04:10 2001 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 08 Aug 2001 13:04:10 +0200 Subject: 90 IPv6 sub-TLA allocations made Message-ID: <00A00393.143817E2.6@cc.univie.ac.at> James, I think we were talking about increasing the size of a sTLA (when the requirement for that can be documented), rather than allocating another sTLA?! Also, I seem to remember that the NCC reserves some space in the address tree for that, so you might be able to obtain a "2nd" sTLA back-to-back with the original one, which is equivalent to decreasing the prefix length. I guess you would be free to structure that (combined/extended) address space internally (for distribution to customers by more than one operational unit). But probably I am missing something essential here. Wilfried. ______________________________________________________________________ Of course, there would be at least one more sub-TLA allocated if the IPv4 rules for supernational registries were to be applied to IPv6 instead of restricting these to only having a single sub-TLA allocation... :-( James -- James Aldridge, Senior Network Engineer (IP Architecture) KPNQwest, Singel 540, 1017 AZ Amsterdam, NL Tel: +31 70 379 37 03; GSM: +31 65 370 87 07 -------------------------------------------------------------------------------- _________________________________:_____________________________________ 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ First things first, but not necessarily in that order.... From jhma at KPNQwest.net Wed Aug 8 15:49:21 2001 From: jhma at KPNQwest.net (James Aldridge) Date: Wed, 08 Aug 2001 15:49:21 +0200 Subject: 90 IPv6 sub-TLA allocations made In-Reply-To: Your message of "Wed, 08 Aug 2001 13:04:10 +0200." <00A00393.143817E2.6@cc.univie.ac.at> Message-ID: "Wilfried Woeber, UniVie/ACOnet" wrote: > I think we were talking about increasing the size of a sTLA (when the > requirement for that can be documented), rather than allocating another > sTLA?! OK, my last mail was maybe a bit terse. Some background might help. We (KPNQwest, formerly EUnet) are a "supernational" registry. In the IPv4 world this is much like having 6 individual large registries with the corresponding number of open allocations that implies. Now, in the IPv6 world I'm told that we can't get an IPv6 sTLA for our direct backbone customers or for any of our other national networks because KPNQwest Finland (covered by the eu.eunet supernational registry) already has our one sub-TLA. Of course, that one sub-TLA gives us a total amount of address space which is adequate for our current requirements for the whole network but once this is split over each of about 20 separate autonomous systems, each with their own routing policy, this is hardly going to result in optimally aggregatable routing... James > Also, I seem to remember that the NCC reserves some space in the address > tree for that, so you might be able to obtain a "2nd" sTLA back-to-back > with the original one, which is equivalent to decreasing the prefix > length. > > I guess you would be free to structure that (combined/extended) address > space internally (for distribution to customers by more than one > operational unit). > > But probably I am missing something essential here. > > Wilfried. > ______________________________________________________________________ > > Of course, there would be at least one more sub-TLA allocated if the IPv4 > rules for supernational registries were to be applied to IPv6 instead of > restricting these to only having a single sub-TLA allocation... :-( > > James > > -- > James Aldridge, Senior Network Engineer (IP Architecture) > KPNQwest, Singel 540, 1017 AZ Amsterdam, NL > Tel: +31 70 379 37 03; GSM: +31 65 370 87 07 > > ----------------------------------------------------------------------------- --- > _________________________________:_____________________________________ > 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 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > First things first, but not necessarily in that order.... From huberman at gblx.net Wed Aug 8 16:28:32 2001 From: huberman at gblx.net (David R Huberman) Date: Wed, 8 Aug 2001 07:28:32 -0700 (MST) Subject: 90 IPv6 sub-TLA allocations made In-Reply-To: Message-ID: > Of course, that one sub-TLA gives us a total amount of address space which is > adequate for our current requirements for the whole network but once this is > split over each of about 20 separate autonomous systems, each with their own > routing policy, this is hardly going to result in optimally aggregatable > routing... And when you explain this to RIPE, how do they respond? If you can make a bona fide engineering argument for obtaining more than one sub-TLA, it seems to me that any RIR is obliged to seriously consider that argument. /david From huberman at gblx.net Wed Aug 8 16:28:32 2001 From: huberman at gblx.net (David R Huberman) Date: Wed, 8 Aug 2001 07:28:32 -0700 (MST) Subject: 90 IPv6 sub-TLA allocations made Message-ID: <200108081436.f78EaiQ73310@phil.wplus.net> To: lists-lir-wg-out at lists.ripe.net To: James Aldridge Reply-To: > Of course, that one sub-TLA gives us a total amount of address space which is > adequate for our current requirements for the whole network but once this is > split over each of about 20 separate autonomous systems, each with their own > routing policy, this is hardly going to result in optimally aggregatable > routing... And when you explain this to RIPE, how do they respond? If you can make a bona fide engineering argument for obtaining more than one sub-TLA, it seems to me that any RIR is obliged to seriously consider that argument. /david From huberman at gblx.net Wed Aug 8 16:28:32 2001 From: huberman at gblx.net (David R Huberman) Date: Wed, 8 Aug 2001 07:28:32 -0700 (MST) Subject: 90 IPv6 sub-TLA allocations made Message-ID: <200108081436.f78EaiQ73310@phil.wplus.net> To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: James Aldridge Reply-To: > Of course, that one sub-TLA gives us a total amount of address space which is > adequate for our current requirements for the whole network but once this is > split over each of about 20 separate autonomous systems, each with their own > routing policy, this is hardly going to result in optimally aggregatable > routing... And when you explain this to RIPE, how do they respond? If you can make a bona fide engineering argument for obtaining more than one sub-TLA, it seems to me that any RIR is obliged to seriously consider that argument. /david From huberman at gblx.net Wed Aug 8 16:28:32 2001 From: huberman at gblx.net (David R Huberman) Date: Wed, 8 Aug 2001 07:28:32 -0700 (MST) Subject: 90 IPv6 sub-TLA allocations made Message-ID: <200108081436.f78EaiQ73310@phil.wplus.net> To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: James Aldridge Reply-To: > Of course, that one sub-TLA gives us a total amount of address space which is > adequate for our current requirements for the whole network but once this is > split over each of about 20 separate autonomous systems, each with their own > routing policy, this is hardly going to result in optimally aggregatable > routing... And when you explain this to RIPE, how do they respond? If you can make a bona fide engineering argument for obtaining more than one sub-TLA, it seems to me that any RIR is obliged to seriously consider that argument. /david From huberman at gblx.net Wed Aug 8 16:28:32 2001 From: huberman at gblx.net (David R Huberman) Date: Wed, 8 Aug 2001 07:28:32 -0700 (MST) Subject: 90 IPv6 sub-TLA allocations made Message-ID: <200108081436.f78EaiQ73310@phil.wplus.net> To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: James Aldridge Reply-To: > Of course, that one sub-TLA gives us a total amount of address space which is > adequate for our current requirements for the whole network but once this is > split over each of about 20 separate autonomous systems, each with their own > routing policy, this is hardly going to result in optimally aggregatable > routing... And when you explain this to RIPE, how do they respond? If you can make a bona fide engineering argument for obtaining more than one sub-TLA, it seems to me that any RIR is obliged to seriously consider that argument. /david From huberman at gblx.net Wed Aug 8 16:28:32 2001 From: huberman at gblx.net (David R Huberman) Date: Wed, 8 Aug 2001 07:28:32 -0700 (MST) Subject: 90 IPv6 sub-TLA allocations made Message-ID: <200108081436.f78EaiQ73310@phil.wplus.net> To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: James Aldridge Reply-To: > Of course, that one sub-TLA gives us a total amount of address space which is > adequate for our current requirements for the whole network but once this is > split over each of about 20 separate autonomous systems, each with their own > routing policy, this is hardly going to result in optimally aggregatable > routing... And when you explain this to RIPE, how do they respond? If you can make a bona fide engineering argument for obtaining more than one sub-TLA, it seems to me that any RIR is obliged to seriously consider that argument. /david From huberman at gblx.net Wed Aug 8 16:28:32 2001 From: huberman at gblx.net (David R Huberman) Date: Wed, 8 Aug 2001 07:28:32 -0700 (MST) Subject: 90 IPv6 sub-TLA allocations made Message-ID: <200108081436.f78EaiQ73310@phil.wplus.net> To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: James Aldridge Reply-To: > Of course, that one sub-TLA gives us a total amount of address space which is > adequate for our current requirements for the whole network but once this is > split over each of about 20 separate autonomous systems, each with their own > routing policy, this is hardly going to result in optimally aggregatable > routing... And when you explain this to RIPE, how do they respond? If you can make a bona fide engineering argument for obtaining more than one sub-TLA, it seems to me that any RIR is obliged to seriously consider that argument. /david From huberman at gblx.net Wed Aug 8 16:28:32 2001 From: huberman at gblx.net (David R Huberman) Date: Wed, 8 Aug 2001 07:28:32 -0700 (MST) Subject: 90 IPv6 sub-TLA allocations made Message-ID: <200108081436.f78EaiQ73310@phil.wplus.net> To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: James Aldridge Reply-To: > Of course, that one sub-TLA gives us a total amount of address space which is > adequate for our current requirements for the whole network but once this is > split over each of about 20 separate autonomous systems, each with their own > routing policy, this is hardly going to result in optimally aggregatable > routing... And when you explain this to RIPE, how do they respond? If you can make a bona fide engineering argument for obtaining more than one sub-TLA, it seems to me that any RIR is obliged to seriously consider that argument. /david From huberman at gblx.net Wed Aug 8 16:28:32 2001 From: huberman at gblx.net (David R Huberman) Date: Wed, 8 Aug 2001 07:28:32 -0700 (MST) Subject: 90 IPv6 sub-TLA allocations made Message-ID: <200108081436.f78EaiQ73310@phil.wplus.net> To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: James Aldridge Reply-To: > Of course, that one sub-TLA gives us a total amount of address space which is > adequate for our current requirements for the whole network but once this is > split over each of about 20 separate autonomous systems, each with their own > routing policy, this is hardly going to result in optimally aggregatable > routing... And when you explain this to RIPE, how do they respond? If you can make a bona fide engineering argument for obtaining more than one sub-TLA, it seems to me that any RIR is obliged to seriously consider that argument. /david From huberman at gblx.net Wed Aug 8 17:02:44 2001 From: huberman at gblx.net (David R Huberman) Date: Wed, 8 Aug 2001 08:02:44 -0700 (MST) Subject: 90 IPv6 sub-TLA allocations made In-Reply-To: Message-ID: > The last reply from the RIPE NCC hostmasters said, "Because Supernational > Registries may not receive multiple IPv6 allocations you would need to have > allocated 80% of the networks in your current sTLA before we could issue more > address space." Please forgive my ignorance and allow me to ask, "where is it written that Supernational Registries may not receive multiple sub-TLAs?" Is this a RIPE NCC interpretation of the bootstrap criteria or is it actually written down somewhere? /david From huberman at gblx.net Wed Aug 8 16:28:32 2001 From: huberman at gblx.net (David R Huberman) Date: Wed, 8 Aug 2001 07:28:32 -0700 (MST) Subject: 90 IPv6 sub-TLA allocations made Message-ID: <200108081436.f78EaiQ73310@phil.wplus.net> To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: James Aldridge Reply-To: > Of course, that one sub-TLA gives us a total amount of address space which is > adequate for our current requirements for the whole network but once this is > split over each of about 20 separate autonomous systems, each with their own > routing policy, this is hardly going to result in optimally aggregatable > routing... And when you explain this to RIPE, how do they respond? If you can make a bona fide engineering argument for obtaining more than one sub-TLA, it seems to me that any RIR is obliged to seriously consider that argument. /david From huberman at gblx.net Wed Aug 8 17:02:44 2001 From: huberman at gblx.net (David R Huberman) Date: Wed, 8 Aug 2001 08:02:44 -0700 (MST) Subject: 90 IPv6 sub-TLA allocations made Message-ID: <200108081506.f78F6ZZ74043@phil.wplus.net> To: lists-lir-wg-out at lists.ripe.net To: James Aldridge Reply-To: > The last reply from the RIPE NCC hostmasters said, "Because Supernational > Registries may not receive multiple IPv6 allocations you would need to have > allocated 80% of the networks in your current sTLA before we could issue more > address space." Please forgive my ignorance and allow me to ask, "where is it written that Supernational Registries may not receive multiple sub-TLAs?" Is this a RIPE NCC interpretation of the bootstrap criteria or is it actually written down somewhere? /david From huberman at gblx.net Wed Aug 8 16:28:32 2001 From: huberman at gblx.net (David R Huberman) Date: Wed, 8 Aug 2001 07:28:32 -0700 (MST) Subject: 90 IPv6 sub-TLA allocations made Message-ID: <200108081436.f78EaiQ73310@phil.wplus.net> To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: James Aldridge Reply-To: > Of course, that one sub-TLA gives us a total amount of address space which is > adequate for our current requirements for the whole network but once this is > split over each of about 20 separate autonomous systems, each with their own > routing policy, this is hardly going to result in optimally aggregatable > routing... And when you explain this to RIPE, how do they respond? If you can make a bona fide engineering argument for obtaining more than one sub-TLA, it seems to me that any RIR is obliged to seriously consider that argument. /david From huberman at gblx.net Wed Aug 8 17:02:44 2001 From: huberman at gblx.net (David R Huberman) Date: Wed, 8 Aug 2001 08:02:44 -0700 (MST) Subject: 90 IPv6 sub-TLA allocations made Message-ID: <200108081506.f78F6ZZ74043@phil.wplus.net> To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: James Aldridge Reply-To: > The last reply from the RIPE NCC hostmasters said, "Because Supernational > Registries may not receive multiple IPv6 allocations you would need to have > allocated 80% of the networks in your current sTLA before we could issue more > address space." Please forgive my ignorance and allow me to ask, "where is it written that Supernational Registries may not receive multiple sub-TLAs?" Is this a RIPE NCC interpretation of the bootstrap criteria or is it actually written down somewhere? /david From huberman at gblx.net Wed Aug 8 16:28:32 2001 From: huberman at gblx.net (David R Huberman) Date: Wed, 8 Aug 2001 07:28:32 -0700 (MST) Subject: 90 IPv6 sub-TLA allocations made Message-ID: <200108081436.f78EaiQ73310@phil.wplus.net> To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: James Aldridge Reply-To: > Of course, that one sub-TLA gives us a total amount of address space which is > adequate for our current requirements for the whole network but once this is > split over each of about 20 separate autonomous systems, each with their own > routing policy, this is hardly going to result in optimally aggregatable > routing... And when you explain this to RIPE, how do they respond? If you can make a bona fide engineering argument for obtaining more than one sub-TLA, it seems to me that any RIR is obliged to seriously consider that argument. /david From huberman at gblx.net Wed Aug 8 17:02:44 2001 From: huberman at gblx.net (David R Huberman) Date: Wed, 8 Aug 2001 08:02:44 -0700 (MST) Subject: 90 IPv6 sub-TLA allocations made Message-ID: <200108081506.f78F6ZZ74043@phil.wplus.net> To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: James Aldridge Reply-To: > The last reply from the RIPE NCC hostmasters said, "Because Supernational > Registries may not receive multiple IPv6 allocations you would need to have > allocated 80% of the networks in your current sTLA before we could issue more > address space." Please forgive my ignorance and allow me to ask, "where is it written that Supernational Registries may not receive multiple sub-TLAs?" Is this a RIPE NCC interpretation of the bootstrap criteria or is it actually written down somewhere? /david From huberman at gblx.net Wed Aug 8 16:28:32 2001 From: huberman at gblx.net (David R Huberman) Date: Wed, 8 Aug 2001 07:28:32 -0700 (MST) Subject: 90 IPv6 sub-TLA allocations made Message-ID: <200108081436.f78EaiQ73310@phil.wplus.net> To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: James Aldridge Reply-To: > Of course, that one sub-TLA gives us a total amount of address space which is > adequate for our current requirements for the whole network but once this is > split over each of about 20 separate autonomous systems, each with their own > routing policy, this is hardly going to result in optimally aggregatable > routing... And when you explain this to RIPE, how do they respond? If you can make a bona fide engineering argument for obtaining more than one sub-TLA, it seems to me that any RIR is obliged to seriously consider that argument. /david From huberman at gblx.net Wed Aug 8 17:02:44 2001 From: huberman at gblx.net (David R Huberman) Date: Wed, 8 Aug 2001 08:02:44 -0700 (MST) Subject: 90 IPv6 sub-TLA allocations made Message-ID: <200108081506.f78F6ZZ74043@phil.wplus.net> To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: James Aldridge Reply-To: > The last reply from the RIPE NCC hostmasters said, "Because Supernational > Registries may not receive multiple IPv6 allocations you would need to have > allocated 80% of the networks in your current sTLA before we could issue more > address space." Please forgive my ignorance and allow me to ask, "where is it written that Supernational Registries may not receive multiple sub-TLAs?" Is this a RIPE NCC interpretation of the bootstrap criteria or is it actually written down somewhere? /david From huberman at gblx.net Wed Aug 8 16:28:32 2001 From: huberman at gblx.net (David R Huberman) Date: Wed, 8 Aug 2001 07:28:32 -0700 (MST) Subject: 90 IPv6 sub-TLA allocations made Message-ID: <200108081436.f78EaiQ73310@phil.wplus.net> To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: James Aldridge Reply-To: > Of course, that one sub-TLA gives us a total amount of address space which is > adequate for our current requirements for the whole network but once this is > split over each of about 20 separate autonomous systems, each with their own > routing policy, this is hardly going to result in optimally aggregatable > routing... And when you explain this to RIPE, how do they respond? If you can make a bona fide engineering argument for obtaining more than one sub-TLA, it seems to me that any RIR is obliged to seriously consider that argument. /david From huberman at gblx.net Wed Aug 8 17:02:44 2001 From: huberman at gblx.net (David R Huberman) Date: Wed, 8 Aug 2001 08:02:44 -0700 (MST) Subject: 90 IPv6 sub-TLA allocations made Message-ID: <200108081506.f78F6ZZ74043@phil.wplus.net> To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: James Aldridge Reply-To: > The last reply from the RIPE NCC hostmasters said, "Because Supernational > Registries may not receive multiple IPv6 allocations you would need to have > allocated 80% of the networks in your current sTLA before we could issue more > address space." Please forgive my ignorance and allow me to ask, "where is it written that Supernational Registries may not receive multiple sub-TLAs?" Is this a RIPE NCC interpretation of the bootstrap criteria or is it actually written down somewhere? /david From huberman at gblx.net Wed Aug 8 16:28:32 2001 From: huberman at gblx.net (David R Huberman) Date: Wed, 8 Aug 2001 07:28:32 -0700 (MST) Subject: 90 IPv6 sub-TLA allocations made Message-ID: <200108081436.f78EaiQ73310@phil.wplus.net> To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: James Aldridge Reply-To: > Of course, that one sub-TLA gives us a total amount of address space which is > adequate for our current requirements for the whole network but once this is > split over each of about 20 separate autonomous systems, each with their own > routing policy, this is hardly going to result in optimally aggregatable > routing... And when you explain this to RIPE, how do they respond? If you can make a bona fide engineering argument for obtaining more than one sub-TLA, it seems to me that any RIR is obliged to seriously consider that argument. /david From huberman at gblx.net Wed Aug 8 17:02:44 2001 From: huberman at gblx.net (David R Huberman) Date: Wed, 8 Aug 2001 08:02:44 -0700 (MST) Subject: 90 IPv6 sub-TLA allocations made Message-ID: <200108081506.f78F6ZZ74043@phil.wplus.net> To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: James Aldridge Reply-To: > The last reply from the RIPE NCC hostmasters said, "Because Supernational > Registries may not receive multiple IPv6 allocations you would need to have > allocated 80% of the networks in your current sTLA before we could issue more > address space." Please forgive my ignorance and allow me to ask, "where is it written that Supernational Registries may not receive multiple sub-TLAs?" Is this a RIPE NCC interpretation of the bootstrap criteria or is it actually written down somewhere? /david From huberman at gblx.net Wed Aug 8 16:28:32 2001 From: huberman at gblx.net (David R Huberman) Date: Wed, 8 Aug 2001 07:28:32 -0700 (MST) Subject: 90 IPv6 sub-TLA allocations made Message-ID: <200108081436.f78EaiQ73310@phil.wplus.net> To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: James Aldridge Reply-To: > Of course, that one sub-TLA gives us a total amount of address space which is > adequate for our current requirements for the whole network but once this is > split over each of about 20 separate autonomous systems, each with their own > routing policy, this is hardly going to result in optimally aggregatable > routing... And when you explain this to RIPE, how do they respond? If you can make a bona fide engineering argument for obtaining more than one sub-TLA, it seems to me that any RIR is obliged to seriously consider that argument. /david From huberman at gblx.net Wed Aug 8 17:02:44 2001 From: huberman at gblx.net (David R Huberman) Date: Wed, 8 Aug 2001 08:02:44 -0700 (MST) Subject: 90 IPv6 sub-TLA allocations made Message-ID: <200108081506.f78F6ZZ74043@phil.wplus.net> To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: James Aldridge Reply-To: > The last reply from the RIPE NCC hostmasters said, "Because Supernational > Registries may not receive multiple IPv6 allocations you would need to have > allocated 80% of the networks in your current sTLA before we could issue more > address space." Please forgive my ignorance and allow me to ask, "where is it written that Supernational Registries may not receive multiple sub-TLAs?" Is this a RIPE NCC interpretation of the bootstrap criteria or is it actually written down somewhere? /david From huberman at gblx.net Wed Aug 8 16:28:32 2001 From: huberman at gblx.net (David R Huberman) Date: Wed, 8 Aug 2001 07:28:32 -0700 (MST) Subject: 90 IPv6 sub-TLA allocations made Message-ID: <200108081436.f78EaiQ73310@phil.wplus.net> To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: James Aldridge Reply-To: > Of course, that one sub-TLA gives us a total amount of address space which is > adequate for our current requirements for the whole network but once this is > split over each of about 20 separate autonomous systems, each with their own > routing policy, this is hardly going to result in optimally aggregatable > routing... And when you explain this to RIPE, how do they respond? If you can make a bona fide engineering argument for obtaining more than one sub-TLA, it seems to me that any RIR is obliged to seriously consider that argument. /david From huberman at gblx.net Wed Aug 8 17:02:44 2001 From: huberman at gblx.net (David R Huberman) Date: Wed, 8 Aug 2001 08:02:44 -0700 (MST) Subject: 90 IPv6 sub-TLA allocations made Message-ID: <200108081506.f78F6ZZ74043@phil.wplus.net> To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: postmaster1 at wplus.net To: lists-lir-wg-out at lists.ripe.net To: James Aldridge Reply-To: > The last reply from the RIPE NCC hostmasters said, "Because Supernational > Registries may not receive multiple IPv6 allocations you would need to have > allocated 80% of the networks in your current sTLA before we could issue more > address space." Please forgive my ignorance and allow me to ask, "where is it written that Supernational Registries may not receive multiple sub-TLAs?" Is this a RIPE NCC interpretation of the bootstrap criteria or is it actually written down somewhere? /david From jhma at KPNQwest.net Wed Aug 8 16:53:00 2001 From: jhma at KPNQwest.net (James Aldridge) Date: Wed, 08 Aug 2001 16:53:00 +0200 Subject: 90 IPv6 sub-TLA allocations made In-Reply-To: Your message of "Wed, 08 Aug 2001 07:28:32 PDT." Message-ID: David R Huberman wrote: > > > Of course, that one sub-TLA gives us a total amount of address space which is > > adequate for our current requirements for the whole network but once this i s > > split over each of about 20 separate autonomous systems, each with their ow n > > routing policy, this is hardly going to result in optimally aggregatable > > routing... > > And when you explain this to RIPE, how do they respond? If you can make a > bona fide engineering argument for obtaining more than one sub-TLA, it > seems to me that any RIR is obliged to seriously consider that argument. The last reply from the RIPE NCC hostmasters said, "Because Supernational Registries may not receive multiple IPv6 allocations you would need to have allocated 80% of the networks in your current sTLA before we could issue more address space." So we can have a /35 fragmented among something like 20 different networks but can't get any additional address space until 80% of the current /35 is used. James -- James Aldridge, Senior Network Engineer (IP Architecture) KPNQwest, Singel 540, 1017 AZ Amsterdam, NL Tel: +31 70 379 37 03; GSM: +31 65 370 87 07 From arnold.nipper at de-cix.net Wed Aug 8 17:15:55 2001 From: arnold.nipper at de-cix.net (Nipper, Arnold) Date: Wed, 8 Aug 2001 17:15:55 +0200 Subject: 90 IPv6 sub-TLA allocations made References: Message-ID: <011801c1201d$05acddc0$0190a8c0@nipper.de> James schrieb: > > Now, in the IPv6 world I'm told that we can't get an IPv6 sTLA for our direct > backbone customers or for any of our other national networks because KPNQwest > Finland (covered by the eu.eunet supernational registry) already has our one > sub-TLA. > > Of course, that one sub-TLA gives us a total amount of address space which is > adequate for our current requirements for the whole network but once this is > split over each of about 20 separate autonomous systems, each with their own > routing policy, this is hardly going to result in optimally aggregatable > routing... > Actually, you have a /34, haven't you? EU-EUNET-20000403 and DE-XLINK-20000510. Very interesting that KQDE got an assignment as at that time they already where 100% KQ. -- Arnold From jhma at KPNQwest.net Wed Aug 8 17:21:00 2001 From: jhma at KPNQwest.net (James Aldridge) Date: Wed, 08 Aug 2001 17:21:00 +0200 Subject: 90 IPv6 sub-TLA allocations made In-Reply-To: Your message of "Wed, 08 Aug 2001 08:02:44 PDT." Message-ID: David R Huberman wrote: > > > The last reply from the RIPE NCC hostmasters said, "Because Supernational > > Registries may not receive multiple IPv6 allocations you would need to have > > allocated 80% of the networks in your current sTLA before we could issue mo re > > address space." > > Please forgive my ignorance and allow me to ask, "where is it written that > Supernational Registries may not receive multiple sub-TLAs?" > > Is this a RIPE NCC interpretation of the bootstrap criteria or is it > actually written down somewhere? As far as I can see from a quick scan of rfc2928, it refers to "registries" only in terms of the RIRs and not as local IRs or other customers of the RIRs. Thus, I can only assume that restriction is the RIPE NCCs interpretation of the criteria. I intend to raise this issue at the LIR WG (which I co-chair) at RIPE40 in Prague in October. Any clarification from RIPE NCC staff prior to RIPE40 would be appreciated. James From stephenb at uk.uu.net Thu Aug 9 10:36:15 2001 From: stephenb at uk.uu.net (Stephen Burley) Date: Thu, 9 Aug 2001 09:36:15 +0100 Subject: 90 IPv6 sub-TLA allocations made References: Message-ID: <07aa01c120ae$5a6ee560$f006bf3e@eu.frd.uu.net> I would like to add although we are not a supernational registry and all that implies ;) we have the same issue. We have been allocated our start up space in IPv6 which is fine for now but would it not be better to be more forward thinking when allocating IPv6 space and allocate enough space to aggregate fully throughout the EMEA region and so implement the best possible aggregation. This is not just a cry for more space because we are big so we deserve it, we are seriously looking to a time when IPv6 is used in anger and we have to do real aggregation throughout EMEA. We do not want to assign IPv6 on a per LIR basis, rather sub-allocate IPv6 space to our current LIR structure since we are all in the same network it makes sense. BTW we are currently writing our internal IPv6 deployment policy. Regards, Stephen Burley UUNET EMEA Hostmaster ----- Original Message ----- From: "James Aldridge" To: "Wilfried Woeber, UniVie/ACOnet" Cc: ; Sent: Wednesday, August 08, 2001 2:49 PM Subject: Re: 90 IPv6 sub-TLA allocations made > "Wilfried Woeber, UniVie/ACOnet" wrote: > > I think we were talking about increasing the size of a sTLA (when the > > requirement for that can be documented), rather than allocating another > > sTLA?! > > OK, my last mail was maybe a bit terse. Some background might help. > > We (KPNQwest, formerly EUnet) are a "supernational" registry. In the IPv4 > world this is much like having 6 individual large registries with the > corresponding number of open allocations that implies. > > Now, in the IPv6 world I'm told that we can't get an IPv6 sTLA for our direct > backbone customers or for any of our other national networks because KPNQwest > Finland (covered by the eu.eunet supernational registry) already has our one > sub-TLA. > > Of course, that one sub-TLA gives us a total amount of address space which is > adequate for our current requirements for the whole network but once this is > split over each of about 20 separate autonomous systems, each with their own > routing policy, this is hardly going to result in optimally aggregatable > routing... > > James > > > > Also, I seem to remember that the NCC reserves some space in the address > > tree for that, so you might be able to obtain a "2nd" sTLA back-to-back > > with the original one, which is equivalent to decreasing the prefix > > length. > > > > I guess you would be free to structure that (combined/extended) address > > space internally (for distribution to customers by more than one > > operational unit). > > > > But probably I am missing something essential here. > > > > Wilfried. > > ______________________________________________________________________ > > > > Of course, there would be at least one more sub-TLA allocated if the IPv4 > > rules for supernational registries were to be applied to IPv6 instead of > > restricting these to only having a single sub-TLA allocation... :-( > > > > James > > > > -- > > James Aldridge, Senior Network Engineer (IP Architecture) > > KPNQwest, Singel 540, 1017 AZ Amsterdam, NL > > Tel: +31 70 379 37 03; GSM: +31 65 370 87 07 > > > > -------------------------------------------------------------------------- --- > --- > > _________________________________:_____________________________________ > > 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 > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > First things first, but not necessarily in that order.... > From stephenb at uk.uu.net Thu Aug 9 11:07:10 2001 From: stephenb at uk.uu.net (Stephen Burley) Date: Thu, 9 Aug 2001 10:07:10 +0100 Subject: Question about RIPE-183 Message-ID: <088001c120b2$ac427ab0$f006bf3e@eu.frd.uu.net> Hi Quick question is RIPE-183 still valid or has it been superceded. The reason i am asking is would the automaton support self generated ticket numbers, we havea need for this and would like to use the facilities mentioned in the document. Regards, Stephen Burley UUNET EMEA Hostmaster From gert at space.net Thu Aug 9 11:18:15 2001 From: gert at space.net (Gert Doering) Date: Thu, 9 Aug 2001 11:18:15 +0200 Subject: 90 IPv6 sub-TLA allocations made In-Reply-To: <07aa01c120ae$5a6ee560$f006bf3e@eu.frd.uu.net>; from stephenb@uk.uu.net on Thu, Aug 09, 2001 at 09:36:15AM +0100 References: <07aa01c120ae$5a6ee560$f006bf3e@eu.frd.uu.net> Message-ID: <20010809111815.X39182@Space.Net> Hi, On Thu, Aug 09, 2001 at 09:36:15AM +0100, Stephen Burley wrote: > I would like to add although we are not a supernational registry and all > that implies ;) we have the same issue. We have been allocated our start up > space in IPv6 which is fine for now but would it not be better to be more > forward thinking when allocating IPv6 space and allocate enough space to > aggregate fully throughout the EMEA region and so implement the best > possible aggregation. This is not just a cry for more space because we are > big so we deserve it, we are seriously looking to a time when IPv6 is used > in anger and we have to do real aggregation throughout EMEA. We do not want > to assign IPv6 on a per LIR basis, rather sub-allocate IPv6 space to our > current LIR structure since we are all in the same network it makes sense. > BTW we are currently writing our internal IPv6 deployment policy. As far as I remember the IPv6 policy discussions on the last RIPE meetings, one thing that was voiced repeatedly was "if we have to hand out /48's to customers, a /35 for the LIR itself is not enough" (considering hierarchical strutures - either due to multinational networks, or due to hierarchies of resellers having re-selling customers themselves - 13 bits to work in is just not enough). Also, it hasn't really been shown why we need slow-start *in slow-start space*(!). It's not like we want our own TLA, but I think the RIRs are being way too conservative. Old IPv4 habits...? Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From djp-ripe-lists at djp.net Thu Aug 9 14:48:24 2001 From: djp-ripe-lists at djp.net (Dave Pratt) Date: Thu, 9 Aug 2001 14:48:24 +0200 (MET DST) Subject: 90 IPv6 sub-TLA allocations made In-Reply-To: <20010809111815.X39182@Space.Net> Message-ID: Hiya Folks, I would like to confirm what Gert wrote. Myself and *many* others stated 13 bits is not enough. There was definitely concensus on this point. There were other comments about "H-ratio's" and why only 13 bits for a Global ISP when a single user gets 80 bits and the RIR's 35. Other comments about Old IPv4 habits were also made. A separate issue of avoiding non-4 bit boundaries was also made. Even ripe is affected here since TWO reverse domain delegations are needed for each current sub-TLA. As a result, various persons (Randy,and I think Mirjam or Nurani) said the TLA issues were going to be re-worked, and that RFC2928 would be made obselete. This is essential in my view. However, either nothing is happening, or it is all happening behind closed doors both of which are wrong in my opinion. Cheers Dave (normally djp at djp.net but posting might be faster from this subscribed address) On Thu, 9 Aug 2001, Gert Doering wrote: ->Hi, -> ->As far as I remember the IPv6 policy discussions on the last RIPE meetings, ->one thing that was voiced repeatedly was -> -> "if we have to hand out /48's to customers, a /35 for the LIR itself -> is not enough" -> ->(considering hierarchical strutures - either due to multinational ->networks, or due to hierarchies of resellers having re-selling customers ->themselves - 13 bits to work in is just not enough). -> ->Also, it hasn't really been shown why we need slow-start *in slow-start ->space*(!). It's not like we want our own TLA, but I think the RIRs are ->being way too conservative. Old IPv4 habits...? -> ->Gert Doering -> -- NetMaster From david at IPRG.nokia.com Thu Aug 9 15:02:44 2001 From: david at IPRG.nokia.com (David Kessens) Date: Thu, 9 Aug 2001 06:02:44 -0700 Subject: 90 IPv6 sub-TLA allocations made In-Reply-To: <20010809111815.X39182@Space.Net> References: <07aa01c120ae$5a6ee560$f006bf3e@eu.frd.uu.net> <20010809111815.X39182@Space.Net> Message-ID: <20010809060244.C32384@iprg.nokia.com> On Thu, Aug 09, 2001 at 11:18:15AM +0200, Gert Doering wrote: > > As far as I remember the IPv6 policy discussions on the last RIPE meetings, > one thing that was voiced repeatedly was > > "if we have to hand out /48's to customers, a /35 for the LIR itself > is not enough" For your information: We are currently planning a joint session for ipv6 allocation policy issues for the next RIPE meeting. It would be really nice if we can get volunteers from the community who can give a brief presentation on possible solutions. The problem description is pretty clear by now, however, I have not seen any (public) proposals yet on how to solve it. Obviously, there are multiple ways to deal with the issue and it would be nice to discuss advantages and disadvantages of different solutions. David K. --- From gert at space.net Thu Aug 9 15:55:48 2001 From: gert at space.net (Gert Doering) Date: Thu, 9 Aug 2001 15:55:48 +0200 Subject: 90 IPv6 sub-TLA allocations made In-Reply-To: <200108091352.f79Dq0u77351@givry.rennes.enst-bretagne.fr>; from Francis.Dupont@enst-bretagne.fr on Thu, Aug 09, 2001 at 03:52:00PM +0200 References: <20010809111815.X39182@Space.Net> <200108091352.f79Dq0u77351@givry.rennes.enst-bretagne.fr> Message-ID: <20010809155548.D76399@Space.Net> Hi, On Thu, Aug 09, 2001 at 03:52:00PM +0200, Francis Dupont wrote: > Also, it hasn't really been shown why we need slow-start *in slow-start > space*(!). It's not like we want our own TLA, but I think the RIRs are > being way too conservative. Old IPv4 habits...? > > => protection of a business... (if this is not the case someone can > believe this). There are rumors to that extent, yep. But it's unlikely that IPv4 requests will stop so suddenly that RIPE hostmasters will all lose their jobs... Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From alain.bidron at francetelecom.com Thu Aug 9 16:45:24 2001 From: alain.bidron at francetelecom.com (BIDRON Alain BRX/DAP) Date: Thu, 09 Aug 2001 16:45:24 +0200 Subject: 90 IPv6 sub-TLA allocations made References: <07aa01c120ae$5a6ee560$f006bf3e@eu.frd.uu.net> <20010809111815.X39182@Space.Net> <20010809060244.C32384@iprg.nokia.com> Message-ID: <3B72A204.9CD014C2@francetelecom.com> During the January meeting in Amsterdam we had presentions from Bernard Tuy (Renater), and from Stuart Prevost (BT), and first consensus on this issue. During the April meeting in Bologna, a very comprehensive document, with the problem description and with clear proposals was presented by Nial Murphy, and again converging views were expressed. See Nial Murphy presentation : http://www.ripe.net/ripe/mail-archives/ipv6-wg/20010101-20010401/msg00035.html http://www.enigma.ie/articles/global-ipv6-alteration.html ETNO expressed supports to Nial's proposals and introduced a common ETNO position on this issue (See: http://www.ripe.net/ripe/mail-archives/ipv6-wg/20010401-20010701/msg00016.html http://www.etno.belbone.be/site/positions.htm) Do we really need to explore solutions again or do we need a new Draft from the RIRs taking into account those proposals and the consensus expressed around, and able to be approved by the community ? Alain Bidron. David Kessens a ?crit : > > On Thu, Aug 09, 2001 at 11:18:15AM +0200, Gert Doering wrote: > > > > As far as I remember the IPv6 policy discussions on the last RIPE meetings, > > one thing that was voiced repeatedly was > > > > "if we have to hand out /48's to customers, a /35 for the LIR itself > > is not enough" > > For your information: > > We are currently planning a joint session for ipv6 allocation policy > issues for the next RIPE meeting. > > It would be really nice if we can get volunteers from the community > who can give a brief presentation on possible solutions. The problem > description is pretty clear by now, however, I have not seen any > (public) proposals yet on how to solve it. Obviously, there are > multiple ways to deal with the issue and it would be nice to discuss > advantages and disadvantages of different solutions. > > David K. > --- -------------- next part -------------- A non-text attachment was scrubbed... Name: alain.bidron.vcf Type: text/x-vcard Size: 198 bytes Desc: Carte pour BIDRON Alain BRX/DAP URL: From sabrina at ripe.net Thu Aug 9 18:15:48 2001 From: sabrina at ripe.net (Sabrina Waschke) Date: Thu, 09 Aug 2001 18:15:48 +0200 Subject: 90 IPv6 sub-TLA allocations made Message-ID: <200108091615.f79GFmH17235@birch.ripe.net> James, Your request for a subsequent sub-TLA allocation was evaluated according to the Provisional IPv6 Assignment and Allocation Policy (4.2.5. Criteria for Subsequent Sub-TLA Allocations). Please see: http://www.ripe.net/ipv6 As you know this policy is under revision and the current discussions on these two mailing lists are encouraged. All three Regional Internet Registries receive input from their communities and based on this a new draft of the policy document will be presented at the upcoming RIPE 40 meeting in Prague. The presentation "IPv6 Bootstrap Phase" given at the last RIPE meeting in Bologna can be found at: http://www.ripe.net/ripe/meetings/archive/ripe-39/presentations/ipv6develop/ A Supernational Registry is a special case. You may want to use this presentation as a starting point to discuss the minimum allocation size. Kind regards, Sabrina Waschke -- o------------------------------------------o | Sabrina Waschke sabrina at ripe.net | | Registration Services Operations Manager | | | | RIPE NCC tel +31 20 535 4444 | | www.ripe.net fax +31 20 535 4445 | o------------------------------------------o From djp-ripe-lists at djp.net Thu Aug 9 20:38:04 2001 From: djp-ripe-lists at djp.net (Dave Pratt) Date: Thu, 9 Aug 2001 20:38:04 +0200 (MET DST) Subject: 90 IPv6 sub-TLA allocations made In-Reply-To: <3B72A204.9CD014C2@francetelecom.com> Message-ID: Hiya all, There were also many concrete proposals in my mail of 8.2.2001 to these lists and available for browsing at: http://www.djp.net/ipv6/proposal.html for those who do not wish to access the mail archives. It's time this and the other proposals, which are all approximately in agreement, were put into a revised allocation policy. We already have 166 routes in the IPv6 routing table. The sooner we adopt the revised allocation policy the less likely it is the wrongly sized routes will need to hang around for ever - Cisco memory is very expensive - IPv6 addresses are plentiful. Cheers Dave On Thu, 9 Aug 2001, BIDRON Alain BRX/DAP wrote: ->During the January meeting in Amsterdam we had presentions from Bernard ->Tuy (Renater), and from Stuart Prevost (BT), and first consensus on this ->issue. -> ->During the April meeting in Bologna, a very comprehensive document, ->with the problem description and with clear proposals was presented by ->Nial Murphy, and ->again converging views were expressed. -> ->See Nial Murphy presentation : ->http://www.ripe.net/ripe/mail-archives/ipv6-wg/20010101-20010401/msg00035.html ->http://www.enigma.ie/articles/global-ipv6-alteration.html -> ->ETNO expressed supports to Nial's proposals and introduced a common ->ETNO position ->on this issue ->(See: ->http://www.ripe.net/ripe/mail-archives/ipv6-wg/20010401-20010701/msg00016.html ->http://www.etno.belbone.be/site/positions.htm) -> ->Do we really need to explore solutions again or do we need a new Draft ->from the RIRs taking into account those proposals and the consensus ->expressed around, and able to be approved by the community ? -> ->Alain Bidron. -> ->David Kessens a ?crit : ->> ->> On Thu, Aug 09, 2001 at 11:18:15AM +0200, Gert Doering wrote: ->> > ->> > As far as I remember the IPv6 policy discussions on the last RIPE meetings, ->> > one thing that was voiced repeatedly was ->> > ->> > "if we have to hand out /48's to customers, a /35 for the LIR itself ->> > is not enough" ->> ->> For your information: ->> ->> We are currently planning a joint session for ipv6 allocation policy ->> issues for the next RIPE meeting. ->> ->> It would be really nice if we can get volunteers from the community ->> who can give a brief presentation on possible solutions. The problem ->> description is pretty clear by now, however, I have not seen any ->> (public) proposals yet on how to solve it. Obviously, there are ->> multiple ways to deal with the issue and it would be nice to discuss ->> advantages and disadvantages of different solutions. ->> ->> David K. ->> --- From stephenb at uk.uu.net Fri Aug 10 13:02:18 2001 From: stephenb at uk.uu.net (Stephen Burley) Date: Fri, 10 Aug 2001 12:02:18 +0100 Subject: 90 IPv6 sub-TLA allocations made References: <200108091615.f79GFmH17235@birch.ripe.net> Message-ID: <007301c1218b$ec0759c0$2e04bf3e@eu.frd.uu.net> ----- Original Message ----- From: "Sabrina Waschke" To: "James Aldridge" Cc: ; Sent: Thursday, August 09, 2001 5:15 PM Subject: Re: 90 IPv6 sub-TLA allocations made > > James, > > Your request for a subsequent sub-TLA allocation was evaluated > according to the Provisional IPv6 Assignment and Allocation > Policy (4.2.5. Criteria for Subsequent Sub-TLA Allocations). > Please see: > > http://www.ripe.net/ipv6 > > As you know this policy is under revision and the current > discussions on these two mailing lists are encouraged. > > All three Regional Internet Registries receive input from their > communities and based on this a new draft of the policy document > will be presented at the upcoming RIPE 40 meeting in Prague. > > The presentation "IPv6 Bootstrap Phase" given at the last RIPE > meeting in Bologna can be found at: > > http://www.ripe.net/ripe/meetings/archive/ripe-39/presentations/ipv6develop/ > > A Supernational Registry is a special case. You may want to use > this presentation as a starting point to discuss the minimum > allocation size. Sorry i do not agree, we are not a supernational registry and the only reason we have not become one is because of the 80% usage rule, but we are still in the same boat as James. We are not looking at now, and what we need now, we are trying to be forward thinking and address routing problems we see now with IPv4 so we do not see them in IPv6. I think the likes of very large registries should be handled diferently, i do not mean given special dispensation but looking at the internet as a whole apply what will benefit the community at large. One thing which will benefit the internet at large is smaller routing tables especialy since for some time to come IPv4 routes will have to live next to IPv6 routes. So what i see as a workable solution is to use a middle structure. Remeber if we do not get it right now then our errors will be around for as long as IPv6 is. The middle ground i see as a workable solution is RIR > MIR > LIR. MIR is multi-national registry which is basicly a group of registries all belonging to the same AS but with diferant CIDR for their customers. The MIR would be bound by all RIPE policy apart from the 80% usage. Rather than relying on the 80% rule which in a supernational registry or a group of registries like ours is almost impossible to work with aggregation it is based on other critearia. This critearia could be a solid aggregation plan and projected usage based on current trends. The MIR would disribute to the LIR based on aggregation and projected growth. This would mean fewer internal routes and better summary at the borders and easy filtering. The reason we have not become a supernational is simply we could not live with the 80% rule especialy when you look at how fast dial uses address space compared with others. The LIR could still be responsible to RIPE (though i do not see why as customers all get /48 or /64) but rather the LIR is responsible to the MIR but it is the job of the MIR to control the IP addressing in the most efficiant manner ( i am not talking about conservation). Lets face it conservation is not a problem with IPv6 and as was shown at RIPE 37 (i think) will not be for a good 50 years and the sooner we lose this conservation mind set the better. IPv6 if not approached correctly will be our undoing, if we have to go with the current structure of LIRs getting their own chunks we will have internaly now 250,000 routes, mutliply that by the world and cisco is very happy as their memory sales goes through the roof. IPv6 have enough oveheads already with neighbot discover and ipsec built in lets lower the burden or our routers. Before everyone stands up and starts shouting about doing away with RIPE and all that implies let me say i am not suggesting this. We do need a regional governing body and the amount MIR's needed in the RIPE region is not great and will be the exception rather than the rule. There will still be LIR's who report directly to RIPE and as has already been stated IPv4 is not dead yet. The MIR will still have its work cut out justifying its aggregation policy to RIPE and RIPE will have its work cut out understanding an EMEA wide routing plan but then thats why we need an MIR. I will now don my flame proof suit and await the verbal roasting this will create ;). I await your comments. Regards, Stephen Burley UUNET EMEA Hostmaster > > > Kind regards, > > Sabrina Waschke > > -- > > o------------------------------------------o > | Sabrina Waschke sabrina at ripe.net | > | Registration Services Operations Manager | > | | > | RIPE NCC tel +31 20 535 4444 | > | www.ripe.net fax +31 20 535 4445 | > o------------------------------------------o > > From mir at ripe.net Fri Aug 10 15:05:45 2001 From: mir at ripe.net (Mirjam Kuehne) Date: Fri, 10 Aug 2001 13:05:45 +0000 Subject: 90 IPv6 sub-TLA allocations made In-Reply-To: Your message of Fri, 10 Aug 2001 13:43:55 +0100. <5104D4DBC598D211B5FE0000F8FE7EB20D42482E@mbtlipnt02.btlabs.bt.co.uk> Message-ID: <200108101305.PAA05823@kantoor.ripe.net> Stuart, The RIRs had extensive discussions about the revised IPv6 policies during the IETF this week. We hope to have a new draft out during the next two weeks, certainly before the RIPE40 Meeting. Please take into account that the APNIC had no chance yet to discuss this with their community. The next APNIC meeting will take place during the last week of August. I will attend that meeting to give the same presentation you have seen at RIPE39. As we agreed that we will do our best to develop IPv6 allocation policy that is applicable globally, the process needs to include all RIR communities. However, the current discussion on the list is more than welcome to support that process. Recommendations and suggestions made by the RIPE community can then already be take into consideration for the discussions at the APNIC meeting. Regards, Mirjam Kuehne RIPE NCC stuart.prevost at bt.com writes: * Sabrina, * * It would be nice if the new draft could be mailed to the relevant lists * before the RIPE 40 meeting so people can have a meaningful discussion. * Please can you indicate if/when a new version of the policy document will b * e * published? * * Thanks, * Stuart * * > -----Original Message----- * > From: Sabrina Waschke [mailto:sabrina at ripe.net] * > Sent: 09 August 2001 17:16 * > To: James Aldridge * > Cc: lir-wg at ripe.net; ipv6-wg at ripe.net * > Subject: Re: 90 IPv6 sub-TLA allocations made * > * > * > * > James, * > * > Your request for a subsequent sub-TLA allocation was evaluated * > according to the Provisional IPv6 Assignment and Allocation * > Policy (4.2.5. Criteria for Subsequent Sub-TLA Allocations). * > Please see: * > * > http://www.ripe.net/ipv6 * > * > As you know this policy is under revision and the current * > discussions on these two mailing lists are encouraged. * > * > All three Regional Internet Registries receive input from their * > communities and based on this a new draft of the policy document * > will be presented at the upcoming RIPE 40 meeting in Prague. * > * > The presentation "IPv6 Bootstrap Phase" given at the last RIPE * > meeting in Bologna can be found at: * > * > http://www.ripe.net/ripe/meetings/archive/ripe-39/presentation * s/ipv6develop/ * * A Supernational Registry is a special case. You may want to use * this presentation as a starting point to discuss the minimum * allocation size. * * * Kind regards, * * Sabrina Waschke * * -- * * o------------------------------------------o * | Sabrina Waschke sabrina at ripe.net | * | Registration Services Operations Manager | * | | * | RIPE NCC tel +31 20 535 4444 | * | www.ripe.net fax +31 20 535 4445 | * o------------------------------------------o * From manuel at ripe.net Fri Aug 10 17:22:23 2001 From: manuel at ripe.net (Manuel Valente) Date: Fri, 10 Aug 2001 17:22:23 +0200 Subject: Question about RIPE-183 In-Reply-To: <088001c120b2$ac427ab0$f006bf3e@eu.frd.uu.net> References: <088001c120b2$ac427ab0$f006bf3e@eu.frd.uu.net> Message-ID: <20010810172223.49eca418.manuel@ripe.net> Hi, On Thu, 9 Aug 2001 10:07:10 +0100 "Stephen Burley" wrote: > Quick question is RIPE-183 still valid or has it been superceded. The > reason i am asking is would the automaton support self generated ticket > numbers, we havea need for this and would like to use the facilities > mentioned in the document. RIPE-183 is still valid in the description of the ticketing system format - although we went from 8-digit tickets to 10-digits. Support for self-generated ticket numbers is not implemented. However, the RIPE-NCC ticketing system allows you to insert your own ticket numbers in your mail messages, and these should be kept during the correspondance between you and the hostmasters, allowing software on your side to keep track of the mail exchange. Regards, -- Manuel Valente - Software Manager - RIPE NCC From djp-ripe-lists at djp.net Mon Aug 13 10:48:21 2001 From: djp-ripe-lists at djp.net (Dave Pratt) Date: Mon, 13 Aug 2001 10:48:21 +0200 (MET DST) Subject: 90 IPv6 sub-TLA allocations made In-Reply-To: Message-ID: Hiya all, In my view it is not so ambitious to be recommending /16 allocations to "supernational" organisations as this is the policy originally recommended in RFC2374 and elsewhere. On the other hand: "Will these supernational organisations be advertising parts of this /16 into the global routing table". If the answer is yes, then I think they should be making multiple regional or national requests, and receiving multiple /20 or /24 allocations according to their likely longterm requirements in each region. Everytime an LIR requests and gets additional addresses because of an insufficiently small original allocation (whether through the 80% rule, or 90% according to RFC2450 !! or my suggested 10% rule), the RIR's have effectively made a mistake as this means one unnecessary route in the routing table. I'm not suggesting the RIR's give a /16 (or /20,/24,/28,/32, for that matter) to anybody who asks. The requester must justify that such an allocation is appropriate (with the RIR's taking a much more generous stance in contrast to what they need to do with IPv4). Cheers Dave BT Ignite GmbH, On Sun, 12 Aug 2001, Tim Chown wrote: ->As a group, we have not discussed more ambitious suggestions such as those ->at http://www.djp.net/ipv6/proposal.html where a /16 is suggested for the ->"supernational" organisations. ->Tim From Francis.Dupont at enst-bretagne.fr Thu Aug 9 15:52:00 2001 From: Francis.Dupont at enst-bretagne.fr (Francis Dupont) Date: Thu, 09 Aug 2001 15:52:00 +0200 Subject: 90 IPv6 sub-TLA allocations made In-Reply-To: Your message of Thu, 09 Aug 2001 11:18:15 +0200. <20010809111815.X39182@Space.Net> Message-ID: <200108091352.f79Dq0u77351@givry.rennes.enst-bretagne.fr> In your previous mail you wrote: Also, it hasn't really been shown why we need slow-start *in slow-start space*(!). It's not like we want our own TLA, but I think the RIRs are being way too conservative. Old IPv4 habits...? => protection of a business... (if this is not the case someone can believe this). Francis.Dupont at enst-bretagne.fr From david at IPRG.nokia.com Thu Aug 9 17:20:18 2001 From: david at IPRG.nokia.com (David Kessens) Date: Thu, 9 Aug 2001 08:20:18 -0700 Subject: 90 IPv6 sub-TLA allocations made In-Reply-To: <3B72A204.9CD014C2@francetelecom.com> References: <07aa01c120ae$5a6ee560$f006bf3e@eu.frd.uu.net> <20010809111815.X39182@Space.Net> <20010809060244.C32384@iprg.nokia.com> <3B72A204.9CD014C2@francetelecom.com> Message-ID: <20010809082018.A32736@iprg.nokia.com> Alain, On Thu, Aug 09, 2001 at 04:45:24PM +0200, BIDRON Alain BRX/DAP wrote: > > Do we really need to explore solutions again or do we need a new Draft > from the RIRs taking into account those proposals and the consensus > expressed around, and able to be approved by the community ? I think that the problem description is quite clear. I think that it is also clear that a majority of the people would like to have a larger initial allocation. However, it is not clear how big such an allocation should be, whether there should be a uniform size of the initial allocation, whether multi-national registries should be able to get more than one allocation etc. Next, we will also need to take a look at the definition of 80% utilization, when people can come back to the regional registries for more address space and how much address space they will get when they come back and qualify for more address space. It's up to us as the RIPE community to identify these issues and to advise the RIPE NCC on how to fix the current policy. So far, we have done quite a good job in identifying the issues, it's now time to go in more detail in order to define a workable allocation policy. David K. --- From david at IPRG.nokia.com Thu Aug 9 17:46:25 2001 From: david at IPRG.nokia.com (David Kessens) Date: Thu, 9 Aug 2001 08:46:25 -0700 Subject: 90 IPv6 sub-TLA allocations made Message-ID: <20010809084625.A385@iprg.nokia.com> Alain, On Thu, Aug 09, 2001 at 04:45:24PM +0200, BIDRON Alain BRX/DAP wrote: > > Do we really need to explore solutions again or do we need a new Draft > from the RIRs taking into account those proposals and the consensus > expressed around, and able to be approved by the community ? I think that the problem description is quite clear. I think that it is also clear that a majority of the people would like to have a larger initial allocation. However, it is not clear how big such an allocation should be, whether there should be a uniform size of the initial allocation, whether multi-national registries should be able to get more than one allocation etc. Next, we will also need to take a look at the definition of 80% utilization, when people can come back to the regional registries for more address space and how much address space they will get when they come back and qualify for more address space. It's up to us as the RIPE community to identify these issues and to advise the RIPE NCC on how to fix the current policy. So far, we have done quite a good job in identifying the issues, it's now time to go in more detail in order to define a workable allocation policy. David K. --- From stuart.prevost at bt.com Fri Aug 10 14:43:55 2001 From: stuart.prevost at bt.com (stuart.prevost at bt.com) Date: Fri, 10 Aug 2001 13:43:55 +0100 Subject: 90 IPv6 sub-TLA allocations made Message-ID: <5104D4DBC598D211B5FE0000F8FE7EB20D42482E@mbtlipnt02.btlabs.bt.co.uk> Sabrina, It would be nice if the new draft could be mailed to the relevant lists before the RIPE 40 meeting so people can have a meaningful discussion. Please can you indicate if/when a new version of the policy document will be published? Thanks, Stuart > -----Original Message----- > From: Sabrina Waschke [mailto:sabrina at ripe.net] > Sent: 09 August 2001 17:16 > To: James Aldridge > Cc: lir-wg at ripe.net; ipv6-wg at ripe.net > Subject: Re: 90 IPv6 sub-TLA allocations made > > > > James, > > Your request for a subsequent sub-TLA allocation was evaluated > according to the Provisional IPv6 Assignment and Allocation > Policy (4.2.5. Criteria for Subsequent Sub-TLA Allocations). > Please see: > > http://www.ripe.net/ipv6 > > As you know this policy is under revision and the current > discussions on these two mailing lists are encouraged. > > All three Regional Internet Registries receive input from their > communities and based on this a new draft of the policy document > will be presented at the upcoming RIPE 40 meeting in Prague. > > The presentation "IPv6 Bootstrap Phase" given at the last RIPE > meeting in Bologna can be found at: > > http://www.ripe.net/ripe/meetings/archive/ripe-39/presentation s/ipv6develop/ A Supernational Registry is a special case. You may want to use this presentation as a starting point to discuss the minimum allocation size. Kind regards, Sabrina Waschke -- o------------------------------------------o | Sabrina Waschke sabrina at ripe.net | | Registration Services Operations Manager | | | | RIPE NCC tel +31 20 535 4444 | | www.ripe.net fax +31 20 535 4445 | o------------------------------------------o From pjw at ip-engineering.bt.com Tue Aug 14 18:27:02 2001 From: pjw at ip-engineering.bt.com (Peter Willis) Date: Tue, 14 Aug 2001 17:27:02 +0100 Subject: 90 IPv6 sub-TLA allocations made In-Reply-To: Your message of "Mon, 13 Aug 2001 10:48:21 +0200." Message-ID: <200108141627.RAA20315@celiborn.ip-engineering.bt.com> Colleagues, I've just done some calculations that shows the maximum theoritical utilisation that can be achieved is 75% whilst maintaining the minimum size of routing table. That is if you take a large number of subnets, each subnet containing a random number of hosts, and assign to each subnet the nearest power of 2 larger than the number of hosts, the utilisation you get is 75%. This is a 75% utilisation per level of network hierarchy. So if we assume 3 levels of network hierarchy and each level doing perfect routing aggregation and perfect address allocation we will get an overall utilisation of 0.75^3 = 0.422 == 42% overall utilisation for the TLA. I'd like to bet that if we have a network with enough hosts to justify 64 bits of address space it'll also be large enough to require more than 3 levels of network hierarchy. Any requirements to get high address space utilisation out of IPv6 can simply be demonstrated to lack scaling qualities. Regards, ------------------------------------------------------------------------------- Peter Willis | E-mail: peter.j.willis at bt.com IP Technology Strategist | Phone: 01473 645178 Fax: 01473 644506 BTexact Technologies CTO | ------------------------------------------------------------------------------- From pjw at ip-engineering.bt.com Wed Aug 15 15:40:44 2001 From: pjw at ip-engineering.bt.com (Peter Willis) Date: Wed, 15 Aug 2001 14:40:44 +0100 Subject: 90 IPv6 sub-TLA allocations made In-Reply-To: Your message of "Wed, 15 Aug 2001 10:30:12 BST." <122501c1256c$e2281d60$2e04bf3e@eu.frd.uu.net> Message-ID: <200108151340.OAA29271@celiborn.ip-engineering.bt.com> > This is not including the needed aggregation for multi-national registries, > its fine for a single network but, still would tie your hands when > sub-allocating to multiple LIR's. This is simply accomodated by mutliplying the maximum utilisation figure by 0.75 for every layer of hierarchy or aggregation in the network. So for a 3 layer network plus another layer for international aggregation the maximum utilisation falls to 0.75^4=0.316 == 32%. This is the theoritical maximum address utilisation that can be achieved without breaking aggregates. I think we should penalize anyone who gets a better address utilisation than this because they are obviously announcing more routes than they need to ;-) Peter. From joao at ripe.net Wed Aug 15 16:03:50 2001 From: joao at ripe.net (Joao Luis Silva Damas) Date: Wed, 15 Aug 2001 16:03:50 +0200 Subject: 90 IPv6 sub-TLA allocations made In-Reply-To: <200108141627.RAA20315@celiborn.ip-engineering.bt.com> References: <200108141627.RAA20315@celiborn.ip-engineering.bt.com> Message-ID: Hi, I think the RIR staff working on the new policy draft understand the issue. I believe the new draft will reflect this by moving away from a fixed percentage to using the huitema/durand ratio which is meant to give a consistent view of space utilization when using variable levels of hierarchy. Joao Damas RIPE NCC At 17:27 +0100 14/8/01, Peter Willis wrote: >Colleagues, > >I've just done some calculations that shows the maximum theoritical >utilisation that can be achieved is 75% whilst maintaining the minimum size of >routing table. That is if you take a large number of subnets, each subnet > containing a random number of hosts, and assign to each subnet the nearest > power of 2 larger than the number of hosts, the utilisation you get is 75%. > >This is a 75% utilisation per level of network hierarchy. > >So if we assume 3 levels of network hierarchy and each level doing perfect > routing aggregation and perfect address allocation we will get an overall > utilisation of > 0.75^3 = 0.422 == 42% overall utilisation for the TLA. > >I'd like to bet that if we have a network with enough hosts to justify 64 bits >of address space it'll also be large enough to require more than 3 levels of >network hierarchy. Any requirements to get high address space utilisation out >of IPv6 can simply be demonstrated to lack scaling qualities. > >Regards, > > >------------------------------------------------------------------------------- >Peter Willis | E-mail: peter.j.willis at bt.com >IP Technology Strategist | Phone: 01473 645178 Fax: 01473 644506 >BTexact Technologies CTO | >------------------------------------------------------------------------------- -- From stephenb at uk.uu.net Wed Aug 15 16:39:56 2001 From: stephenb at uk.uu.net (Stephen Burley) Date: Wed, 15 Aug 2001 15:39:56 +0100 Subject: 90 IPv6 sub-TLA allocations made References: <200108141627.RAA20315@celiborn.ip-engineering.bt.com> Message-ID: <131401c12598$273117b0$2e04bf3e@eu.frd.uu.net> Will the new draft include the priciple of MIR's which i detailed on the list (which stangly got no negative response) and will it also understand the concept of sub-allocation? Regards, Stephen Burley UUNET EMEA Hostmaster ----- Original Message ----- From: "Joao Luis Silva Damas" To: "Peter Willis" ; "Dave Pratt" Cc: "lir-wg" ; "ipv6-wg" Sent: Wednesday, August 15, 2001 3:03 PM Subject: Re: 90 IPv6 sub-TLA allocations made > Hi, > > I think the RIR staff working on the new policy draft understand the > issue. I believe the new draft will reflect this by moving away from > a fixed percentage to using the huitema/durand ratio which is meant > to give a consistent view of space utilization when using variable > levels of hierarchy. > > Joao Damas > RIPE NCC > > At 17:27 +0100 14/8/01, Peter Willis wrote: > >Colleagues, > > > >I've just done some calculations that shows the maximum theoritical > >utilisation that can be achieved is 75% whilst maintaining the minimum size of > >routing table. That is if you take a large number of subnets, each subnet > > containing a random number of hosts, and assign to each subnet the nearest > > power of 2 larger than the number of hosts, the utilisation you get is 75%. > > > >This is a 75% utilisation per level of network hierarchy. > > > >So if we assume 3 levels of network hierarchy and each level doing perfect > > routing aggregation and perfect address allocation we will get an overall > > utilisation of > > 0.75^3 = 0.422 == 42% overall utilisation for the TLA. > > > >I'd like to bet that if we have a network with enough hosts to justify 64 bits > >of address space it'll also be large enough to require more than 3 levels of > >network hierarchy. Any requirements to get high address space utilisation out > >of IPv6 can simply be demonstrated to lack scaling qualities. > > > >Regards, > > > > > >--------------------------------------------------------------------------- ---- > >Peter Willis | E-mail: peter.j.willis at bt.com > >IP Technology Strategist | Phone: 01473 645178 Fax: 01473 644506 > >BTexact Technologies CTO | > >--------------------------------------------------------------------------- ---- > > > -- From joao at ripe.net Wed Aug 15 16:54:14 2001 From: joao at ripe.net (Joao Luis Silva Damas) Date: Wed, 15 Aug 2001 16:54:14 +0200 Subject: 90 IPv6 sub-TLA allocations made In-Reply-To: <131401c12598$273117b0$2e04bf3e@eu.frd.uu.net> References: <200108141627.RAA20315@celiborn.ip-engineering.bt.com> <131401c12598$273117b0$2e04bf3e@eu.frd.uu.net> Message-ID: At 15:39 +0100 15/8/01, Stephen Burley wrote: >Will the new draft include the priciple of MIR's which i detailed on the >list (which stangly got no negative response) and will it also understand >the concept of sub-allocation? I can't answer this directly as I haven't seen the latest version, but Mirjam's keyboard is on fire from all the typing going on, so I think the new draft is coming real soon now. Joao >Regards, >Stephen Burley >UUNET EMEA Hostmaster > -- From gert at space.net Wed Aug 15 20:25:07 2001 From: gert at space.net (Gert Doering) Date: Wed, 15 Aug 2001 20:25:07 +0200 Subject: 90 IPv6 sub-TLA allocations made In-Reply-To: <131401c12598$273117b0$2e04bf3e@eu.frd.uu.net>; from stephenb@uk.uu.net on Wed, Aug 15, 2001 at 03:39:56PM +0100 References: <200108141627.RAA20315@celiborn.ip-engineering.bt.com> <131401c12598$273117b0$2e04bf3e@eu.frd.uu.net> Message-ID: <20010815202507.S76399@Space.Net> Hi, On Wed, Aug 15, 2001 at 03:39:56PM +0100, Stephen Burley wrote: > Will the new draft include the priciple of MIR's which i detailed on the > list (which stangly got no negative response) and will it also understand > the concept of sub-allocation? Without knowing anything about that draft :-) I can only speculate. On the concept of MIRs - I don't think they are necessary. This is something that a LIR should do internally - and this means the concept of sub-allocation should be legalized (and formalized) now. LIRs already do sub-allocations, because it's necessary. The hostmasters know this, but frown on it, because it's not in the official policies. So let's change 'em (at least for IPv6, where aggregation is MUCH more important than conservation). Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From stuart.prevost at bt.com Mon Aug 13 12:53:49 2001 From: stuart.prevost at bt.com (stuart.prevost at bt.com) Date: Mon, 13 Aug 2001 11:53:49 +0100 Subject: 90 IPv6 sub-TLA allocations made Message-ID: <5104D4DBC598D211B5FE0000F8FE7EB20D424838@mbtlipnt02.btlabs.bt.co.uk> David, Whilst I agree with what you are saying in that the RIPE community has identified issues, and that it is time to go into more detail to define a workable allocation policy. It would help if we had insight into what the 3 RIR thoughts are regarding these issues. I know that a new policy document will be published very shortly, and we should hopefully see what progress has been made towards a workable allocation policy. Personally I feel that it has taken far to long for a revised allocation policy to materialize, since review of the current document started in October 1999. Almost two years on we don't have new draft-policy we can even discuss let alone implement. Anyway I'll stop going on about it and look forward to reading the new draft :) Regards, Stuart > -----Original Message----- > From: David Kessens [mailto:david at IPRG.nokia.com] > Sent: Thursday, August 09, 2001 4:46 PM > To: BIDRON Alain BRX/DAP > Cc: Stephen Burley; lir-wg at ripe.net; ipv6-wg at ripe.net > Subject: Re: 90 IPv6 sub-TLA allocations made > > > > Alain, > > On Thu, Aug 09, 2001 at 04:45:24PM +0200, BIDRON Alain > BRX/DAP wrote: > > > > Do we really need to explore solutions again or do we need > a new Draft > > from the RIRs taking into account those proposals and the consensus > > expressed around, and able to be approved by the community ? > > I think that the problem description is quite clear. I think that it > is also clear that a majority of the people would like to have a > larger initial allocation. > > However, it is not clear how big such an allocation should be, whether > there should be a uniform size of the initial allocation, whether > multi-national registries should be able to get more than one > allocation etc. > > Next, we will also need to take a look at the definition of 80% > utilization, when people can come back to the regional registries for > more address space and how much address space they will get when they > come back and qualify for more address space. > > It's up to us as the RIPE community to identify these issues and to > advise the RIPE NCC on how to fix the current policy. So far, we have > done quite a good job in identifying the issues, it's now time to go > in more detail in order to define a workable allocation policy. > > David K. > --- > From stephenb at uk.uu.net Wed Aug 15 11:30:12 2001 From: stephenb at uk.uu.net (Stephen Burley) Date: Wed, 15 Aug 2001 10:30:12 +0100 Subject: 90 IPv6 sub-TLA allocations made References: <200108141627.RAA20315@celiborn.ip-engineering.bt.com> Message-ID: <122501c1256c$e2281d60$2e04bf3e@eu.frd.uu.net> This is not including the needed aggregation for multi-national registries, its fine for a single network but, still would tie your hands when sub-allocating to multiple LIR's. Regards Stephen Burley UUNET EMEA Hostmaster > Colleagues, > > I've just done some calculations that shows the maximum theoritical > utilisation that can be achieved is 75% whilst maintaining the minimum size of > routing table. That is if you take a large number of subnets, each subnet > containing a random number of hosts, and assign to each subnet the nearest > power of 2 larger than the number of hosts, the utilisation you get is 75%. > > This is a 75% utilisation per level of network hierarchy. > > So if we assume 3 levels of network hierarchy and each level doing perfect > routing aggregation and perfect address allocation we will get an overall > utilisation of > 0.75^3 = 0.422 == 42% overall utilisation for the TLA. > > I'd like to bet that if we have a network with enough hosts to justify 64 bits > of address space it'll also be large enough to require more than 3 levels of > network hierarchy. Any requirements to get high address space utilisation out > of IPv6 can simply be demonstrated to lack scaling qualities. > > Regards, > > > -------------------------------------------------------------------------- ----- > Peter Willis | E-mail: peter.j.willis at bt.com > IP Technology Strategist | Phone: 01473 645178 Fax: 01473 644506 > BTexact Technologies CTO | > -------------------------------------------------------------------------- ----- > > From nurani at ripe.net Fri Aug 17 09:38:48 2001 From: nurani at ripe.net (Nurani Nimpuno) Date: Fri, 17 Aug 2001 09:38:48 +0200 Subject: IPv6 request form for Internet Exchange Points Message-ID: <200108170738.JAA29075@kantoor.ripe.net> Dear all, Following the consensus reached in the community on assigning IPv6 address space to Internet Exchange Points, the RIPE NCC is now starting to make IPv6 assignments to requesting Internet Exchange Points. A specific request form has been created for this purpose, "IPv6 Request Form for Internet Exchange Points" which can be obtained at the RIPE document store at: http://www.ripe.net/ripe/docs/ipv6request-exchangepoint.html Pending requestors will be asked to complete this form in order to receive an IPv6 assignment from the RIPE NCC. We wish to thank all participants of this discussion for the constructive input in this matter. Kind regards, Nurani Nimpuno *--------------------------------------------------------* | Nurani Nimpuno | | Internet Address Policy Manager | | RIPE Network Co-ordination Centre | | http://www.ripe.net | *--------------------------------------------------------* From fm at st-kilda.org Tue Aug 21 13:37:44 2001 From: fm at st-kilda.org (Fearghas McKay) Date: Tue, 21 Aug 2001 12:37:44 +0100 Subject: IPv6 request form for Internet Exchange Points In-Reply-To: <200108170738.JAA29075@kantoor.ripe.net> References: <200108170738.JAA29075@kantoor.ripe.net> Message-ID: Nurani, On Fri, Aug 17, 2001 at 09:38:48AM +0200, Nurani Nimpuno wrote: > > Following the consensus reached in the community on assigning IPv6 > address space to Internet Exchange Points, the RIPE NCC is now > starting to make IPv6 assignments to requesting Internet Exchange > Points. We don't really think that consensus has been reached yet. We have discussed lot's of details at the mailing list, but the community at large did not have a chance yet to approve a final proposal. As chairpeople of two of the respective working groups, we asked the RIPE NCC to schedule a slot at the next meeting in order to have a final discussion regarding this very topic. We invite you to do a presentation on the next meeting of what you think that the status of the discussion is so far and to send a document to the mailing list some time before the meeting that describes the proposed policy based on the input from the discussions that we had on the mailing list. >From there, we the chairpeople can ask the RIPE community at the next meeting whether they approve and possibly make some small adjustments or whether we have to go back to the drawing board and need more discussion. We would like to ask you to suspend the proposed policy until we have had a chance to ask the RIPE community for approval. Meanwhile we suggest that discussion continues on the LIR-WG list. Thanks, Fearghas McKay, chairperson eix wg David Kessens, chairperson ipv6 wg At 9:38 am +0200 17/8/01, Nurani Nimpuno wrote: >Dear all, > >Following the consensus reached in the community on assigning IPv6 >address space to Internet Exchange Points, the RIPE NCC is now >starting to make IPv6 assignments to requesting Internet Exchange >Points. > >A specific request form has been created for this purpose, "IPv6 >Request Form for Internet Exchange Points" which can be obtained at >the RIPE document store at: > >http://www.ripe.net/ripe/docs/ipv6request-exchangepoint.html > >Pending requestors will be asked to complete this form in order to >receive an IPv6 assignment from the RIPE NCC. > >We wish to thank all participants of this discussion for the >constructive input in this matter. > >Kind regards, > >Nurani Nimpuno > >*--------------------------------------------------------* >| Nurani Nimpuno | >| Internet Address Policy Manager | >| RIPE Network Co-ordination Centre | >| http://www.ripe.net | >*--------------------------------------------------------* From Robert.Kiessling at de.easynet.net Tue Aug 21 14:02:05 2001 From: Robert.Kiessling at de.easynet.net (Robert Kiessling) Date: Tue, 21 Aug 2001 14:02:05 +0200 (MEST) Subject: IPv6 request form for Internet Exchange Points In-Reply-To: References: <200108170738.JAA29075@kantoor.ripe.net> Message-ID: <15234.19901.93914.119269@doncamillo.local.easynet.de> Fearghas McKay writes: > We don't really think that consensus has been reached yet. We have > discussed lot's of details at the mailing list, but the community at > large did not have a chance yet to approve a final proposal. Erm, the community did have many chances to disapprove, and in the end only mostly minor details were still discussed, apart from voices which would like to have allocations made to exchanges. If that's really wanted, then this path is still open, but that would take more effort. > As chairpeople of two of the respective working groups, we asked the RIPE NCC > to schedule a slot at the next meeting in order to have a final > discussion regarding this very topic. And then there's a summary on the mailing list, and then some more exchange on the mailing ist, and then again some discussion on the next meeting ... This has gone on for too long already, and many people want to see it implemented and get started. The issue is nothing fundamental - it's basically that RIPE itself does what anyone else could do, to assign address space to IXPs. > We would like to ask you to suspend the proposed policy until we have > had a chance to ask the RIPE community for approval. Please don't! Robert From stevew at xchangepoint.net Tue Aug 21 14:18:18 2001 From: stevew at xchangepoint.net (Steve Walker) Date: Tue, 21 Aug 2001 13:18:18 +0100 Subject: IPv6 request form for Internet Exchange Points References: <200108170738.JAA29075@kantoor.ripe.net> <15234.19901.93914.119269@doncamillo.local.easynet.de> Message-ID: <3B82518A.DA6AEDE2@xchangepoint.net> Robert Kiessling wrote: > > This has gone on for too long already, and many people want to see it > implemented and get started. The issue is nothing fundamental - it's > basically that RIPE itself does what anyone else could do, to assign > address space to IXPs. I completely agree. We are in a situation where the only reason for us *not* to be switching v6 traffic is this application process - we have customers who *want* the service - to say this is frustrating is an understatement. > > We would like to ask you to suspend the proposed policy until we have > > had a chance to ask the RIPE community for approval. > > Please don't! Agreed!!! I understand the need to ensure complete consensus regarding allocation, but *please* can we aim for a temporary work around to allow us to get an allocation using the existing document. We could review the interim allocations once the consensus is finally reached, and supply any new information then _if_ needed. But as Robert says, this has gone on far too long already! Regards, Steve. From gert at space.net Tue Aug 21 14:36:22 2001 From: gert at space.net (Gert Doering) Date: Tue, 21 Aug 2001 14:36:22 +0200 Subject: IPv6 request form for Internet Exchange Points In-Reply-To: <3B82518A.DA6AEDE2@xchangepoint.net>; from stevew@xchangepoint.net on Tue, Aug 21, 2001 at 01:18:18PM +0100 References: <200108170738.JAA29075@kantoor.ripe.net> <15234.19901.93914.119269@doncamillo.local.easynet.de> <3B82518A.DA6AEDE2@xchangepoint.net> Message-ID: <20010821143622.W80940@Space.Net> Hi, On Tue, Aug 21, 2001 at 01:18:18PM +0100, Steve Walker wrote: > Robert Kiessling wrote: > > This has gone on for too long already, and many people want to see it > > implemented and get started. The issue is nothing fundamental - it's > > basically that RIPE itself does what anyone else could do, to assign > > address space to IXPs. > > I completely agree. We are in a situation where the only reason for us > *not* to be switching v6 traffic is this application process - we have > customers who *want* the service - to say this is frustrating is an > understatement. Seconded for DECIX in Germany. We're now using addresses from SpaceNet's IPv6 block, but this is something that can only be a workaround. Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From beri at kpnqwest.net Tue Aug 21 16:46:40 2001 From: beri at kpnqwest.net (Berislav Todorovic) Date: Tue, 21 Aug 2001 16:46:40 +0200 (CEST) Subject: New RIPE-147 needed! Message-ID: Maybe this will sound like a hassle, but ... ... Everytime I receive a ripe-147 form from teh customer I have to "patch" it myself, to make it compliant with the new RPSL syntax. Any chance to get the new, RPSL-capable form in place (but as a NEW RIPE document, please!)? Here's what should be changed: * Add "as-name:" attribute. * Replace "as-in:" with "import:" and "as-out:" with "export:". * Check to see if RPSL syntax is honored. * Check the examples and make them compliant with RPSL syntax. Regards, Beri --------- Berislav Todorovic, Network Engineer --------- ------- KPNQwest N.V. - IP NOC (formerly EUnet NOC) ------- ---- Wilhelmina van Pruisenweg 78, 2595 AN Den Haag, NL ---- --- Phone: +31-70-379-3990; Mobile: +31-651-333-641 --- -- Email: beri at kpnqwest.net <=> beri at EU.net -- --- _ _ ____ _ .--. ____ ____ __/_ --- ----- /__/ /___/ /\ / / / | / /___/ /___ / ------ ------ _/ \_ / _/ \/ (__.\ |/\/ /___ ____/ (__. ----- From mir at ripe.net Tue Aug 21 19:15:32 2001 From: mir at ripe.net (Mirjam Kuehne) Date: Tue, 21 Aug 2001 17:15:32 +0000 Subject: Global IPv6 Policy Document Message-ID: <200108211715.f7LHFW607021@birch.ripe.net> Dear LIRs, I am happy to inform you that the first draft of the Global IPv6 policies document is ready for a collective review by the RIRs. This draft incorporates the results of discussions that took place at open policy meetings and intensive meetings among the RIRs and the IETF. This review will also allow time for APNIC to present some of the new developments already discussed in the ARIN and RIPE community to its community at the upcoming APNIC open policy meeting on 28 - 31 August. As agreed at RIPE 39, following the RIR revision, the document will be sent to an editorial team for review. We hope to have a final draft ready to publish to the LIR-WG approximately 3 weeks prior to the RIPE 40 Meeting. However, this relies on the reactions from both the APNIC community and the editorial team. Thank you for all the useful contributions made so far. Regards, Mirjam Kuehne RIPE NCC From david at IPRG.nokia.com Tue Aug 21 20:07:10 2001 From: david at IPRG.nokia.com (David Kessens) Date: Tue, 21 Aug 2001 11:07:10 -0700 Subject: IPv6 request form for Internet Exchange Points In-Reply-To: <3B82518A.DA6AEDE2@xchangepoint.net>; from Steve Walker on Tue, Aug 21, 2001 at 01:18:18PM +0100 References: <200108170738.JAA29075@kantoor.ripe.net> <15234.19901.93914.119269@doncamillo.local.easynet.de> <3B82518A.DA6AEDE2@xchangepoint.net> Message-ID: <20010821110710.B27620@iprg.nokia.com> Steve, On Tue, Aug 21, 2001 at 01:18:18PM +0100, Steve Walker wrote: > > > > We would like to ask you to suspend the proposed policy until we have > > > had a chance to ask the RIPE community for approval. > > > > Please don't! > > Agreed!!! I understand the need to ensure complete consensus regarding > allocation, but *please* can we aim for a temporary work around to allow > us to get an allocation using the existing document. > > We could review the interim allocations once the consensus is finally > reached, and supply any new information then _if_ needed. But as Robert > says, this has gone on far too long already! Please don't get us wrong. We are not aiming for complete consensus. The problem that we had was that we didn't had a final proposal submitted to the mailing list. We did have a draft and lot's of comments. What we usualy do in this kind of situations is that RIPE NCC submits a final proposal to the workinggroup that incorporates the comments. The working group then gets a final chance to voice major objections, and if no major problems are uncovered, the policy becomes effective and gets published as a RIPE document (there is a RIPE document for the request form but no document that describes the actual policy on how you will be judged when you submit a request). The problem this time was that there was no final proposal on the list with the actual policy and I didn't see a RIPE document either. We didn't feel that this is a good way to introduce new policy. We already asked for a slot on the next RIPE meeting for closure on this topic. However, we have heard your comments loud and clear :-) so we are working with the RIPE NCC to get a final proposal out much quicker and get approval from the community by asking for approval on the mailing list before the next meeting. I hope that addresses your concerns. David K. --- From stevew at xchangepoint.net Tue Aug 21 21:03:46 2001 From: stevew at xchangepoint.net (Steve Walker) Date: Tue, 21 Aug 2001 20:03:46 +0100 Subject: IPv6 request form for Internet Exchange Points References: <200108170738.JAA29075@kantoor.ripe.net> <15234.19901.93914.119269@doncamillo.local.easynet.de> <3B82518A.DA6AEDE2@xchangepoint.net> <20010821110710.B27620@iprg.nokia.com> Message-ID: <3B82B092.BA6004B6@xchangepoint.net> David, David Kessens wrote: > > We already asked for a slot on the next RIPE meeting for closure on this topic. > However, we have heard your comments loud and clear :-) Hope I wasen`t too noisy! > so we are working > with the RIPE NCC to get a final proposal out much quicker and get approval > from the community by asking for approval on the mailing list before > the next meeting. We greatly appreciate these efforts, and understand the need to stick to procedure. Look forward to the final proposal going through. Regards, Steve. From djp-ripe-lists at djp.net Wed Aug 22 14:24:08 2001 From: djp-ripe-lists at djp.net (Dave Pratt) Date: Wed, 22 Aug 2001 14:24:08 +0200 (MET DST) Subject: Global IPv6 Policy Document In-Reply-To: <200108211715.f7LHFW607021@birch.ripe.net> Message-ID: Hiya folks, Am I the only one who is beginning to feel that the word "open", as used here is not what is meant by open in the common sense ? Is there a good reason why the draft cannot immediately be presented to the RIR members/funders who will chose to actually implement this policy ? While appreciating the support work of the RIPE NCC here, I must ask: is it the LIR Working group(s) who make policy or the RIR NCCs ? I would hate it for the same or similar policy mistakes to be made again. Last time (RIPE 195,196) I remember thinking, "this policy seems all wrong, but it's better to have this than nothing at all". I suspect lack of openness and consultation with ISPs was the cause then. Let's get it done correctly this time - IPv6 users are waiting. The sooner RIR members and the LIR group(s) get to see this and contribute the better in my view. Concensus on the mailing lists is very close so this should not be too hard a task. Cheers Dave On Tue, 21 Aug 2001, Mirjam Kuehne wrote: -> ->Dear LIRs, -> ->I am happy to inform you that the first draft of the Global IPv6 ->policies document is ready for a collective review by the RIRs. This ->draft incorporates the results of discussions that took place at open ->policy meetings and intensive meetings among the RIRs and the IETF. -> ->This review will also allow time for APNIC to present some of the new ->developments already discussed in the ARIN and RIPE community to its ->community at the upcoming APNIC open policy meeting on 28 - 31 August. -> ->As agreed at RIPE 39, following the RIR revision, the document will be ->sent to an editorial team for review. -> ->We hope to have a final draft ready to publish to the LIR-WG ->approximately 3 weeks prior to the RIPE 40 Meeting. However, this ->relies on the reactions from both the APNIC community and the ->editorial team. -> ->Thank you for all the useful contributions made so far. -> ->Regards, -> ->Mirjam Kuehne ->RIPE NCC -> -> -> From hph at online.no Wed Aug 22 21:55:00 2001 From: hph at online.no (Hans Petter Holen) Date: Wed, 22 Aug 2001 21:55:00 +0200 Subject: IPv6 request form for Internet Exchange Points References: <200108170738.JAA29075@kantoor.ripe.net> Message-ID: <00b401c12b44$543f9c70$0300000a@hph> | As chairpeople of two of the respective working groups, we asked the RIPE NCC | to schedule a slot at the next meeting in order to have a final | discussion regarding this very topic. Maybe it would have helped avoiding this unfortunate situation if the chairpersons in questions (me beeing one of them) had shared this intention with the respective mailinglists in the form of a draft agenda or some such at an earlier time... -hph From hph at online.no Wed Aug 22 21:58:11 2001 From: hph at online.no (Hans Petter Holen) Date: Wed, 22 Aug 2001 21:58:11 +0200 Subject: IPv6 request form for Internet Exchange Points References: <200108170738.JAA29075@kantoor.ripe.net> <15234.19901.93914.119269@doncamillo.local.easynet.de> <3B82518A.DA6AEDE2@xchangepoint.net> Message-ID: <00b501c12b44$c91631d0$0300000a@hph> | Agreed!!! I understand the need to ensure complete consensus regarding | allocation, but *please* can we aim for a temporary work around to allow | us to get an allocation using the existing document. | | We could review the interim allocations once the consensus is finally | reached, and supply any new information then _if_ needed. But as Robert | says, this has gone on far too long already! Would this be a way to proceede; introduce the procedure proposed by Nurani as an interim procedure in order to get this thing rolling ? Nothing is worse than technology and customers waiting for politicians to make up their mind... -hph From hph at online.no Wed Aug 22 22:17:43 2001 From: hph at online.no (Hans Petter Holen) Date: Wed, 22 Aug 2001 22:17:43 +0200 Subject: a Proposal to replacing RIPE 185 Message-ID: <00f801c12b47$802279e0$0300000a@hph> Dear Working Group. Last year we set up the 17th of May task force to help the RIPE NCC identify potential improvements to the handeling of requests sent to hostmaster at ripe.net. May of theese have been implemented with success. The continuing growth of the number of LIRs does however call for other meassures to be taken. One of the suggestions by the task force and by the RIPE NCC hostmasters was to improve the IP address request form. A fruther analysis of the underlying problems seems to indicate that the shortcomings of the form is merely a symptom. There are clear indications that the whole policy and procedure document, RIPE 185, would benefit from an overhaul. After studying this document which was created when CIRD was still young and unknow to large parts of our community, we have found that it cotains a lot of usefull information, which is strictly speaking not Policies or Procedures. Rewriten in a clearer and more concise way we may archive a much better common understanding between the individual LIRs and the RIPE NCCC hostmasters. Our hypothesis is therefore that by creating a new strucure for documenting policy and procedures with better examples, and work on clearifying the language in the policy statements the work load of the RIPE NCC hostmasters may be reduced drasticaly. This is due to the fact that for a large propotion of the requests handeled by the RNH's there is lacking information the NRH's. By making it clear to the LIRs that it is the LIRs responsibility to request from the customer and make sure all relevant information is in the application before it is submittet to the RNH, we belive the total time spent, both by RNH's, and by LIR staff will be significantly reduced. We have therefor proposed the following structure for a replacement of RIPE 185: "Addressing Policies and Procedures for the RIPE NCC service region" (Abstract, Introduction, Scope) Internet Address Space and the Internet Registry System Policy framework Policies Glossary References Appendices (bitboundary chart, examples etc) Remove the following sections: All instructions on how to fill out an IP or ASN request form (in separate "supporting notes" ripe docs) PA vs PI (Is described in ripe-127) RIPE NCC RS (mailboxes, ticketing system, robot etc) (Instructions on website) Inaddr procedures (policy to be left in) (separate ripe doc will be created) Routing considerations Our proposal is that the RIPE NCC will present a first draft by doing the ground work on the document, re-writing some sections in a more clear and concise manner. This will then be presented to the lir-wg and the editorial committe for comments and input. We also belive that there is a strong need to publish all policy changes as RIPE document. If there is a need to reduce the administrative overhead of changing the procedures and policies document for every policy document, the changes and amenedments could be made in a single (not more than one at a time !) "Amendments to Policies and procedures. I have spent some days with Nurani and Sabrina at the RIPE NCC and discussed various ways to do this, and our proposal is to form a RIPE-185bis editorial team to facilitate discussion on the lir-wg mailing list and working group meetings and summarise the community consensus. ----- Hans Petter Holen, http://hph.home.online.no Phone: +47 40 20 39 16, Stalsberggt 28 B, 2010 Str?mmen, Norway From hph at online.no Wed Aug 22 22:25:33 2001 From: hph at online.no (Hans Petter Holen) Date: Wed, 22 Aug 2001 22:25:33 +0200 Subject: Draft: Charter & Call for paticipation RIPE-185bis References: <00f801c12b47$802279e0$0300000a@hph> Message-ID: <011b01c12b48$9850db00$0300000a@hph> Please indicate your interest to participate in this editorial team to me or to the list. Please suggest improvements to the mandate to the list. Proposed mandate: Facilitate discussion on the lir-wg mailing list and working group meetings and summarise the community consensus. Ensure that the community consensus on what IP addressing policies is to be in the RIPE NCC service region is documented in a concise and simple language. Proposed Timeline: 2208 Call for participation 2908 First draft to be published based on RIPE 185 discussion at mailinglist 0509 Formation of the group, freeze mandate 1002 1st workshop 1003 discussion at lir-wg meeting 1004 2nd workshop 1015 Second draft to be published Note that this timeline is quite agressive, and that it suggests that we do quite a bit of work at the upcoming RIPE meeting. I do however belive that this timeline is relatively realistic. In my oppinion it is better to revise this timeline. ----- Hans Petter Holen, http://hph.home.online.no Phone: +47 40 20 39 16, Stalsberggt 28 B, 2010 Str?mmen, Norway From hph at online.no Thu Aug 23 00:44:35 2001 From: hph at online.no (Hans Petter Holen) Date: Thu, 23 Aug 2001 00:44:35 +0200 Subject: Call for Nominations for Representatives to the ASO Address Council - RIPE region References: <003301c0fcff$c8878ac0$0a00000a@hph> Message-ID: <01ec01c12b5c$04f1b6e0$0300000a@hph> Just a short reminder, as the deadline approaches: ----- Original Message ----- From: "Hans Petter Holen" To: ; Cc: Sent: Monday, June 25, 2001 12:48 AM Subject: Call for Nominations for Representatives to the ASO Address Council - RIPE region | Dear colleagues, | | This is a call for nominations of individuals from the RIPE region to | serve on the ASO Address Council. During October 2001, one RIPE region | Address Council seat will become vacant and will be filled for the | next three years by an individual nominated through this open call. | | This document describes the functions of the ASO and the Address | Council, as well as the nomination and selection processes. If you are | interested in nominating an individual, or if you are interested in | being nominated as a member of the Address Council, please read this | document carefully. | | | 1. The Address Supporting Organisation | - -------------------------------------- | | The ASO was formed in August 1999 as a consensus-based advisory body | within the ICANN Framework, though a Memorandum of Understanding (MoU) | signed by the current Regional Internet Registries and ICANN. | | The ICANN Bylaws (http://www.icann.org/general/bylaws.htm#VI-A) assign | to the ASO the responsibility for the development of global policies | relating to the distribution and registration of Internet address | space, inter-domain routing identifiers and that part of the DNS name | space that is used to name these addresses and identifiers. | | More information about the ASO is available at: http://www.aso.icann.org | | | 2. The Address Council | - ---------------------- | | The ASO Address Council co-ordinates the process of policy development | in areas within the responsibility of the ASO, according to procedures | defined within the MoU and by the AC itself. Specifically, these | include the hosting of an annual open General Assembly meeting, and | attending regular meetings by teleconference or in person at which | policy issues and submissions may be considered. | | The other major responsibility of the Address Council is the | appointment of individuals to fill ASO seats on the ICANN Board of | Directors, according to procedures defined within the MoU. | | More information on the Address Council is available at: | http://www.aso.icann.org/ac | | | 3. The Role of Members of the Address Council | - --------------------------------------------- | | Members of the Address Council do not represent any RIR, nor do they | act as representatives of any other body. They are appointed in their | individual capacity, and their membership cannot be proxied by any | other individual or organisation. | | No member of the Address Council is entitled to any compensation from | the ASO. No member can be indemnified by the ASO, nor can the ASO | obtain insurance coverage relating to the liability of the actions of | members of the Address Council. | | | 4. Address Council Nominations Process | - -------------------------------------- | | Through this nomination process, one individual from the RIPE region | will be selected to serve on the Address Council for three years, | replacing Hans Petter Holen who has served as an initial AC member for | the past 2 years. The selection will be made though an open election | from the set of individuals who have been nominated within this | process. | | Any individual may be nominated, with the exception of any staff | member of any Regional Internet Registry. Self-nominations are | permitted. | | Nominations should be sent by email to , by | midnight UTC on 5 September 2001. | | The information included with the nomination is to be in English and | should include: | | Name of Nominee: | Country of residence: | Organisation: | Email Address: | Postal Address: | Biographical information: | Motivation for nomination: | | Name of nominating individual: | Organisation: | Email Address: | | All nominees will be contacted via email to confirm their willingness | to serve on the Address Council. If a nominee is not contactable via | email, or does not respond, then their nomination will not be | confirmed and they will not be eligible for election to the Address | Council. | | All confirmed nominations will be listed on the RIPE web site after | they are confirmed. All nominees will have the opportunity to submit a | written statement in support of their nomination, for publication on | the web site. In addition, others may express support for nominated | individuals simply by completing and submitting the nomination form | provided above. | | | 5. Address Council Selection Process | - ------------------------------------ | | The process for selection of the nominee to serve on the Address | Council will involve an open election to be held during the plenary | session of the RIPE 40 Meeting, in Prague, Czech Republic, on 5 October | 2001. See the following URL for details about the selection procedure: | http://www.ripe.net/ripe/wg/lir/adress_council-election.html | | More information about RIPE 40 will be available shortly at: | | http://www.ripe.net/ripe/meetings | | http://www.ripe.net/ripe/meetings/current/ripe-40/ | | Important Dates: | | 5 September 2001 - deadline for Address Council nominations | | | Regards, | Hans Petter Holen | Local IR WG chair | | From nurani at ripe.net Thu Aug 23 19:28:08 2001 From: nurani at ripe.net (Nurani Nimpuno) Date: Thu, 23 Aug 2001 19:28:08 +0200 Subject: IPv6 request form for Internet Exchange Points In-Reply-To: Message from "Hans Petter Holen" of "Wed, 22 Aug 2001 21:58:11 +0200." <00b501c12b44$c91631d0$0300000a@hph> Message-ID: <200108231728.TAA24771@office.ripe.net> All, When concluding the discussion on IPv6 addresses for IXPs, the RIPE NCC were under the impression that participants in the discussion felt that they had had ample time to discuss the final proposed policy. Mirjam sent out a summary on the lists 28 June 2001 after the intense discussion both at the last RIPE meeting and on the mailing lists. (http://www.ripe.net/ripe/mail-archives/lir-wg/20010401-20010701/msg00 228.html) There were a few comments on actual wording that Mirjam took into account, but no further discussion. No objections were raised to the proposed definition. The RIPE NCC has several pending requests for IPv6 address space from IXPs that have been waiting since April. After such lengthy discussion and no further input from the community, we therefore felt that it would be appropriate to move forward and implement the concluded policy in order to meet the need of these LIRs. We do of course recognise the great importance of ensuring that the policy that the RIPE NCC implements is the one agreed upon by the community. This is essential. We also recognise the need for improving the co-ordination between the working group chairs and the RIPE NCC. We hope to discuss this further with the chairs. Some comments have been made on the list suggesting the RIPE NCC to not further postpone the evaluation of the currently pending IXP requests. If this reflects the general feeling in the community, then the RIPE NCC is ready to move forward and do so. If however, there is a need for further discussion, then we wish to encourage everyone to actively contribute with their comments. I hope that there is no need to postpone this discussion until the RIPE 40 meeting in October. I trust the working group chairs to propose a way forward that will ensure a fair and correct conclusion of this discussion. Kind regards, Nurani *--------------------------------------------------------* | Nurani Nimpuno | | Internet Address Policy Manager | | RIPE Network Co-ordination Centre | | http://www.ripe.net | *--------------------------------------------------------* "Hans Petter Holen" writes: * | Agreed!!! I understand the need to ensure complete consensus regarding * | allocation, but *please* can we aim for a temporary work around to allow * | us to get an allocation using the existing document. * | * | We could review the interim allocations once the consensus is finally * | reached, and supply any new information then _if_ needed. But as Robert * | says, this has gone on far too long already! * * Would this be a way to proceede; * introduce the procedure proposed by Nurani as an interim procedure * in order to get this thing rolling ? * * Nothing is worse than technology and customers waiting for politicians * to make up their mind... * * * -hph * From sabrina at ripe.net Thu Aug 23 18:49:17 2001 From: sabrina at ripe.net (Sabrina Waschke) Date: Thu, 23 Aug 2001 18:49:17 +0200 Subject: New RIPE-147 needed! In-Reply-To: Message from Berislav Todorovic of "Tue, 21 Aug 2001 16:46:40 +0200." Message-ID: <200108231649.f7NGnH615249@birch.ripe.net> Berislav, Thank you for your comments regarding the AS Number request form. You are correct in that the RIPE-147 document needs updating due to the new RPSL syntax. Over the last couple of months the RIPE NCC has been working hard on writing new documentation, developing training material and updating current documents to adjust to the new database software. RIPE-147 is on our to-do list and you should be able to expect a new version in the near future. Kind regards, Sabrina Waschke -- o------------------------------------------o | Sabrina Waschke sabrina at ripe.net | | Registration Services Operations Manager | | | | RIPE NCC tel +31 20 535 4444 | | www.ripe.net fax +31 20 535 4445 | o------------------------------------------o Berislav Todorovic writes: * Maybe this will sound like a hassle, but ... * * ... Everytime I receive a ripe-147 form from teh customer I have to "patch" * it myself, to make it compliant with the new RPSL syntax. * * Any chance to get the new, RPSL-capable form in place (but as a NEW RIPE * document, please!)? Here's what should be changed: * * * Add "as-name:" attribute. * * Replace "as-in:" with "import:" and "as-out:" with "export:". * * Check to see if RPSL syntax is honored. * * Check the examples and make them compliant with RPSL syntax. * * Regards, * Beri * * --------- Berislav Todorovic, Network Engineer --------- * ------- KPNQwest N.V. - IP NOC (formerly EUnet NOC) ------- * ---- Wilhelmina van Pruisenweg 78, 2595 AN Den Haag, NL ---- * --- Phone: +31-70-379-3990; Mobile: +31-651-333-641 --- * -- Email: beri at kpnqwest.net <=> beri at EU.net -- * --- _ _ ____ _ .--. ____ ____ __/_ --- * ----- /__/ /___/ /\ / / / | / /___/ /___ / ------ * ------ _/ \_ / _/ \/ (__.\ |/\/ /___ ____/ (__. ----- * From stevew at xchangepoint.net Wed Aug 29 16:45:20 2001 From: stevew at xchangepoint.net (Steve Walker) Date: Wed, 29 Aug 2001 15:45:20 +0100 Subject: IPv6 request form for Internet Exchange Points References: <200108170738.JAA29075@kantoor.ripe.net> <15234.19901.93914.119269@doncamillo.local.easynet.de> <3B82518A.DA6AEDE2@xchangepoint.net> <20010821110710.B27620@iprg.nokia.com> Message-ID: <3B8D0000.D12D12F5@xchangepoint.net> David, David Kessens wrote: > > We already asked for a slot on the next RIPE meeting for closure on this topic. > However, we have heard your comments loud and clear :-) so we are working > with the RIPE NCC to get a final proposal out much quicker and get approval > from the community by asking for approval on the mailing list before > the next meeting. Could you indicate when the final proposal is going to be submitted to the mailing list? Thanks, Steve. From nurani at ripe.net Wed Aug 29 19:40:13 2001 From: nurani at ripe.net (Nurani Nimpuno) Date: Wed, 29 Aug 2001 19:40:13 +0200 Subject: policy changes since ripe-185 Message-ID: <200108291740.TAA29378@office.ripe.net> Dear all, As requested by the lir-wg chair, I have below composed a list of the policy discussions taking place since the publication of the RIPE Document ripe-185 (European Internet Registry Policies and Procedures). I have listed the discussions that have resulted in policy changes and that should be incorporated in the new version of the policy document. Kind regards, Nurani Nimpuno RIPE NCC Policy Changes since the publication of ripe-185 --------------------------------------------------- - Removal of the Maximum Allocation Size "Proposal to raise the maximum allocation to a single LIR", Guy Davies (02 Feb 1999) http://www.ripe.net/ripe/mail-archives/lir-wg/19990101-19990401/msg00010.html - Removal of the Maximum assignment window "Lowering maximum assignment window", Paula Caslav (10 Feb 1999) http://www.ripe.net/ripe/mail-archives/lir-wg/19990101-19990401/msg00019.html - Changes in Static Assignment policy ("Always-on connections") "static verification methods", Paula Caslav (23 Feb 1999) http://www.ripe.net/ripe/mail-archives/lir-wg/19990101-19990401/msg00018.html - Admin-c not mandatory on-site "admin-c in inetnum", Paula Caslav (15 Jun 1999) http://www.ripe.net/ripe/mail-archives/lir-wg/19990401-19990701/msg00011.html - IP-based webhosting strongly discouraged "IP assignment for virtual webhosting", Nurani Nimpuno (17 Nov 1999) http://www.ripe.int/ripe/mail-archives/lir-wg/19991001-20000101/msg00020.html IP assignment for virtual webhosting, Nurani Nimpuno (RIPE36 Budapest) - Lowering of Minimal allocation from /19 to /20 "Minimal allocation /20", Nurani Nimpuno (RIPE 36 Budapest) http://www.ripe.net/ripe/mail-archives/lir-wg/20000401-20000701/msg00187.html - PA Allocation Criteria "PA Allocation Criteria", Nurani Nimpuno (RIPE 39, Bologna) Presentation at RIPE 39: http://www.ripe.net/ripe/meetings/archive/ripe-39/index.html Conclusion by lir-wg chair: http://www.ripe.net/ripe/mail-archives/lir-wg/current/msg00004.html From nurani at ripe.net Thu Aug 30 05:32:29 2001 From: nurani at ripe.net (Nurani Nimpuno) Date: Thu, 30 Aug 2001 05:32:29 +0200 Subject: Fwd: a Proposal to replacing RIPE 185 Message-ID: <4.3.1.2.20010830053124.00c03760@localhost> Dear all, As you all know, the RIPE NCC was actioned to review the current IP& ASN policy document, ripe-185 (European Internet Registry Policy and Procedures) and to present a raw first draft to the lir-wg August 29, 2001. Please find this draft attached. As outlined in Hans Petter's mail below, the task was to update the current policy document with policy changes implemented since the publication of ripe-185. Based on feedback from the membership, the objective was also to create a more condensed, clear and concise policy document that would make it easier for new LIRs and End Users to learn relevant IPv4 and ASN policies and procedures. Experience with the previous policy document clearly showed that new members found ripe-185 very complex. There was a clearly expressed need for a simpler and clearer document that could be used on a daily basis as a reference document for the LIRs. I have followed the structure in Hans Petter's mail below and have produced a first draft for the lir-wg to revise. The changes between this document and ripe-185 are the following: - Structure The structure has been completely revised in order to improve readability and making the information easy to find. - Update of policy The policy changes that have taken place since the last published version of the policy document have been incorporated in this draft. In addition to this, the document has been shortened to make it easier for readers to find the relevant information. Some sections have been completely removed as they are either covered elsewhere and/or not within the scope of a concise policy document. The sections that have been removed are: - Reverse Delegation procedures - Separate RIPE Document will be published (Reverse Delegation Policy distilled and kept) - Mergers, transfers & Closures - Separate RIPE Document will be published - RIPE NCC Registration Services - information available on the web (not policy nor procedure) - Request documentation - Available in the Supporting notes document (Currently ripe-220) (Sections pertaining to policy kept) - Obtaining an AS Number - Available in ASN request form and supporting notes (currently ripe-147) (ASN Policy kept however) - Routing considerations - (not policy nor procedure) As explained, this is a first draft produced by the RIPE NCC to facilitate the writing of this document as requested by the lir-wg. We are now welcoming the feedback on the community and the work of the editorial commitee to finalise this policy document. Kind regards, Nurani *--------------------------------------------------------* | Nurani Nimpuno | | Internet Address Policy Manager | | RIPE Network Co-ordination Centre | | http://www.ripe.net | *--------------------------------------------------------* ------- Forwarded Message >From: "Hans Petter Holen" >To: lir-wg at ripe.net >Subject: a Proposal to replacing RIPE 185 >Date: Wed, 22 Aug 2001 22:17:43 +0200 > >Dear Working Group. >Last year we set up the 17th of May task force to help the RIPE NCC identify >potential improvements to the handeling of requests sent to >hostmaster at ripe.net. May of theese have been implemented with success. The >continuing growth of the number of LIRs does however call for other >meassures to be taken. > >One of the suggestions by the task force and by the RIPE NCC hostmasters was >to improve the IP address request form. A fruther analysis of the >underlying problems seems to indicate that the shortcomings of the form is >merely a symptom. There are clear indications that the whole policy and >procedure document, RIPE 185, would benefit from an overhaul. > >After studying this document which was created when CIRD was still >young and unknow to large parts of our community, we have found that it >cotains a lot of usefull information, which is strictly speaking not >Policies or Procedures. Rewriten in a clearer and more concise way we may >archive a much better common understanding between the individual LIRs and >the RIPE NCCC hostmasters. > >Our hypothesis is therefore that by creating a new strucure for documenting >policy and procedures with better examples, and work on clearifying the >language in the policy statements the work load of the RIPE NCC hostmasters >may be reduced drasticaly. This is due to the fact that for a large >propotion of the requests handeled by the RNH's there is lacking information >the NRH's. By making it clear to the LIRs that it is the LIRs responsibility >to request from the customer and make sure all relevant information is in >the application before it is submittet to the RNH, we belive the total time >spent, both by RNH's, and by LIR staff will be significantly reduced. > >We have therefor proposed the following structure for a replacement of RIPE >185: "Addressing Policies and Procedures for the RIPE NCC service region" > >(Abstract, Introduction, Scope) >Internet Address Space and the Internet Registry System >Policy framework >Policies >Glossary >References >Appendices (bitboundary chart, examples etc) > >Remove the following sections: >All instructions on how to fill out an IP or ASN request form > (in separate "supporting notes" ripe docs) >PA vs PI > (Is described in ripe-127) >RIPE NCC RS (mailboxes, ticketing system, robot etc) > (Instructions on website) >Inaddr procedures (policy to be left in) > (separate ripe doc will be created) >Routing considerations > >Our proposal is that the RIPE NCC will present a first draft by doing >the ground work on the document, re-writing some sections >in a more clear and concise manner. This will then be presented to the >lir-wg and the editorial committe for comments and input. > >We also belive that there is a strong need to publish all policy changes as >RIPE document. If there is a need to reduce the administrative overhead of >changing the procedures and policies document for every policy document, the >changes and amenedments could be made in a single (not more than one at a >time !) "Amendments to Policies and procedures. > >I have spent some days with Nurani and Sabrina at the RIPE NCC and discussed >various ways to do this, and our proposal is to form a RIPE-185bis editorial >team to facilitate discussion on the lir-wg mailing list and working group >meetings and summarise the community consensus. > >----- >Hans Petter Holen, http://hph.home.online.no >Phone: +47 40 20 39 16, Stalsberggt 28 B, 2010 Strxmmen, Norway -------------- next part -------------- IPv4 and ASN Policies in the RIPE NCC Service Region Document ID: ripe-[insert number here] Date Published: [insert date here] Obsoletes: ripe-104, ripe-105, ripe-136, ripe-140, ripe-159, ripe-185 ABSTRACT This document describes the current RIPE NCC policies and procedures associated with IPv4 address space and Autonomous System Number management applicable in the RIPE NCC service region. They are to be implemented by the RIPE NCC and the Local Internet Registries in the RIPE NCC service region. Table of Contents Abstract 1.0 Introduction 1.1 Scope 2.0 Internet Address Space 3.0 The Internet Registry System 3.1 Goals of Public Address Space Distribution 4.0 Policy Framework 5.0 IPv4 and ASN Policies 5.1 General 5.1.1 Validity of assignment 5.1.2 Documentation 5.1.3 Registration requirements 5.2.4 Reservations not supported 5.1.5 Administrative ease 5.1.6 Utilisation 5.1.7 Provider Independent vs Provider Aggregatable addresses 5.1.8 Private address space 5.1.9 Static assignments 5.1.10 Web hosting 5.1.11 Assignments within allocations 5.1.12 IP Address Space Replacement Procedures 5.1.13 Assignment Window 5.2 Rules and Guidelines for Allocations 5.2.1 First allocation 5.2.2 Slow-start mechanism 5.2.3 Further allocations 5.2.4 No guarantee of contiguous allocations 5.2.5 Assignments to other providers 5.3 Operating an LIR 5.3.1 Establishing a new LIR 5.3.2 LIR Operations 5.3.3 Record keeping 5.3.4 Contact persons 5.3.5 Publishing LIR policy 5.3.6 Mergers, take-overs, and closures of LIRs 5.3.7 External Quality Assurance 5.3.8 When an LIR is closed by the RIPE NCC 5.4 Reverse Delegation responsibilities 5.5 Autonomous System Numbers 6.0 Glossary 7.0 References 8.0 Appendices I. RIPE Database procedures II. Assignment Window III. Useful URLs IV. Bit Boundary Chart 1.0 Introduction The RIPE Network Coordination Centre, established as an independent association, serves as one of three existing Regional Internet Registries (RIRs). Its service region covers Europe, the Middle East, Central Asia, and African countries north of the equator. As an RIR, it is responsible for the assignment and allocation of IP address space, Autonomous System Numbers and the management of reverse domain name space. The distribution of IP address space follows the hierarchical scheme described in section 3.0. The RIPE NCC allocates address space to Local Internet Registries (LIRs) that assign it to End Users. In this document, we describe the policies and procedures associated with address space management that must be followed by LIRs. The policies described in this document have been developed by the RIPE community, through the open consensus process facilitated by the RIPE NCC. 1.1 Scope This document describes the policies for the responsible management of the globally unique Internet address space and Autonomous System Numbers (ASNs) in the RIPE NCC service region. Particularly, it describes the rules and guidelines governing the distribution of this address space. The rules set forth in this document are binding for all address space allocated and assigned via the RIPE NCC. This document does not describe specific addressing policies related to IPv6, multicast, or private Internet address space. This document does not describe allocation and assignment rules used by other RIRs. 2.0 Internet Address Space IP addresses, for the purposes of this document, are 32-bit binary numbers used as addresses in the IPv4 protocol. There are three main types of IP addresses: Public Addresses The public IP addresses make up the Internet address space. They are assigned to be globally unique according to the goals described in Section 3.1. The main purpose of this address space is to allow communication, using IPv4 over the Internet. One can currently distinguish two kinds of public addresses: Provider Independent (PI) and Provider Aggregatable (PA) addresses. . More information about PI and PA address space can be found in the RIPE document: " Provider Independent versus Provider Aggregatable Address Space" at: http://www.ripe.net/ripe/docs/pi-pa.html Private Addresses Some address ranges have been set aside for the operation of private networks using IP. Anyone can use these addresses in their private networks without any registration or coordination. Hosts using these addresses cannot be reached from the Internet. For a thorough description of private address space, please refer to RFC 1918 [Rekhter96b]. Special and Reserved Addresses There are a number of address ranges reserved for applications like multicasting. These are described elsewhere (cf RFC 1112 [Deering89a]) and are beyond the scope of this document. 3.0 The Internet Registry System The Internet Registry System consists of the following levels of hierarchy: Internet Assigned Numbers Authority (IANA), Regional Internet Registries (RIRs), Local Internet Registries (LIRs). The Registry System been established to achieve the goals of public address space distribution: uniqueness, aggregation, conservation, and registration. IANA has authority over all IP number spaces used in the Internet. IANA allocates address space to RIRs, such as the RIPE NCC, to be redistributed to LIRs. The LIRs assign address space to End Users under the guidance of the RIRs, and in accordance with the policies and procedures described in this document. End Users are those organisations operating networks in which the address space is used. 3.1 Goals of Public Address Space Distribution In this document, we are primarily concerned with the management of public Internet address space, as defined in the previous section. Public Internet address space assignments should be made with the following three goals in mind. Uniqueness Each public Internet address worldwide must be unique. This is an absolute requirement that guarantees that every host on the Internet can be uniquely identified. Aggregation Public Internet addresses must be distributed in a hierarchical manner, permitting the aggregation of routing information. This is necessary to ensure proper operation of Internet routing. This goal could also be called Routability. Conservation Public Internet address space must be fairly distributed, according to the operational needs of the End Users' operating networks using this address space. To maximize the lifetime of the public Internet address space resource, addresses must be distributed according to need, and stockpiling must be prevented. Registration The provision of a public registry documenting address space allocations and assignments must exist. This is necessary to ensure uniqueness and to provide information for Internet trouble shooting at all levels. It is in the interest of the Internet community as a whole that these goals are pursued. It is worth noting that "conservation" and "aggregation" are often conflicting goals and, therefore, that each assignment must be evaluated carefully. Moreover, the above goals may occasionally be in conflict with the interests of individual End Users or Internet Service Providers (ISPs). Careful analysis and judgement are necessary in each individual case to find an appropriate compromise. The rules and guidelines in this document are intended to help LIRs and End Users in their search for equitable compromises. Definitions Regional Internet Registries RIRs operate in large, geopolitical regions that are continental in scope. Currently, there are three RIRs established: ARIN, serving North America, South America, the Caribbean, and sub-Saharan Africa; APNIC, serving the Asia Pacific region; and the RIPE NCC, serving Europe, Central Asia, the Middle East, and the Northern part of Africa. The duties of an RIR include the co-ordination and representation of its members in its region. Additional RIRs may be established in the future, although their number will remain relatively low. Local Internet Registries LIRs are established under the authority of an RIR. LIRs are typically operated by Internet Service Providers - and serve the customers of those ISPs as well as the customers of smaller ISPs that are connected to the rest of the Internet through the larger ISP. Other organisations such as large enterprises can also operate LIRs. Much of this document is concerned with the responsibility of the LIR in the assignment process. In some cases, the LIR assigning the address space is not run by the ISP that will provide connectivity. It is important to note that the maintenance of the administrative information regarding the assigned address space is the responsibility of the LIR that makes the assignment and not of the ISP providing the connectivity. Furthermore, only RIRs and LIRs can hold address allocations. End User An entity that uses IP address space for its network only and does not provide IP/ASN services to customers. Strictly speaking, End Users are not part of the Internet Registry System. They do, however, play an important role with respect to the goals defined above. In order to achieve the conservation goal, for example, End Users should plan their networks to use a minimum amount of address space. They must document their addressing and deployment plans to the LIR and furnish any additional information required by the LIR for making assignment decisions. To achieve the aggregation goal, an End User should choose an appropriate LIR. End Users should be aware that changing ISPs may require replacing addresses in their networks. Finally, End Users must provide and update registration data for the address space assigned to them. Allocation A block of address space held by an RIR or an LIR from which further allocations or assignments will be made. The RIPE NCC makes allocations to LIRs, from which the LIR can make address space assignments to End Users or to the LIR's own network. Only RIRs can make allocations. An LIR is not allowed to sub-allocate their allocation to any other organisation, it can only make assignments to End Users. Assignment Address space distributed to an End User entity by a RIR or LIR for use in their network, and not to be further distributed. 4.0 Policy framework IP addresses not to be considered property Address space is a finite resource with no intrinsic value and direct costs cannot be ascribed to it. While they may not charge for address space as such, LIRs may charge for their administrative and technical services. For further information on charging for services by LIRs and acceptable practice for such charging please refer to RIPE Document: "Charging by Local Internet Registries", at: http://www.ripe.net/ripe/docs/chargingbylirs.html Impartiality The RIPE NCC represents the interests of the Internet community in general and the Internet community of the RIPE region in particular. As such, it will apply its policies fairly and equitably with respect to all RIPE NCC members, without regard to the size or geographic location of the organisation, or any other factor. Confidentiality Information collected by an RIR or LIR in the registration process must be kept in strict confidence. It is to be used for registration and request evaluation purposes only. The LIR is responsible for protecting the End User's privacy. Aside from the data that is published in the RIR database, the information gathered must be kept in strict confidence. It must be transmitted only to higher level registries and/or IANA upon request, but will not be transmitted to any other party unless explicitly requested in writing by the End User. Registration Every assignment and allocation of public Internet address space must be registered in a publicly accessible registry. Registration of objects pertaining to an assignment in the RIPE Database makes it possible to track the use of address space, support operational contacts, and facilitate studies of address allocation. These activities are essential to the effective maintenance of the Internet. Stockpiling discouraged RIPE NCC policies discourage the stockpiling of IP addresses as it conflicts with the goals of conservation and fairness. Efficient deployment of address space on the basis of demonstrated immediate need is encouraged. Documentation To make appropriate assignment decisions, relevant information must be gathered about the network in question. First, the information is required to make address assignment decisions with respect to the aggregation and conservation goals. Second, the information is required for registration purposes. Good faith The RIPE NCC recognises that its relationships with its members should be based on an implicit trust that the information, network plans, and other documentation provided by LIRs and their customers are genuine and accurate. 5.0 IPv4 and ASN Policies 5.1 General One can currently distinguish two kinds of globally unique, unicast IPv4 addresses: Provider Independent (PI) and Provider Aggregatable (PA) addresses. Provider Independent Addresses IP addresses which are assigned directly to the End User by the RIR. PI addresses are not part of an LIR's allocated block. Provider Aggregatable (PA) Addresses IP addresses that are part of a bigger block of addresses allocated to an LIR (or an RIR). The policies in this section is applicable to all globally unique, unicast IPv4 addresses. Specific policies and guidelines for PA and PI address space are covered later in this section. 5.1.1 Validity of assignment Assignments of any kind of address space are valid as long as the original criteria on which the assignment was based are still valid. If an assignment is made for a specific purpose and the purpose no longer exists, then the assignment is no longer valid. If an assignment is based on information that turns out to be invalid, so is the assignment. 5.1.2 Documentation To make appropriate assignment decisions, relevant information must be gathered about the network in question. Such information may include organisation, addressing requirements, network infrastructure, current address space usage, and future plans of the End User requesting address space. This information is essential to the assignment process, and is formally required by the LIRs. The LIR must assure that the required information is complete before proceeding with the request. For gathering the required information, the RIPE NCC provides a set of forms and supporting notes to fill them in. All information required by the RIPE NCC should be in English. IP address requests requiring evaluation by the RIPE NCC must, however, be submitted on a current version of the "European IP Address Space Request Form" in English: http://www.ripe.net/ripe/docs/iprequestform.html For complete instructions on how to fill out the "European IP Address Request Form", please refer to: http://www.ripe.net/ripe/docs/iprequestsupport.html 5.1.3 Registration requirements Every assignment and allocation of public Internet address space must be registered in a publicly accessible database. This is necessary to ensure uniqueness and to provide information for Internet trouble shooting at all levels. Allocations and assignments in the RIPE NCC service region are registered in the RIPE Database. Only allocations and assignments registered in the RIPE Database are considered valid. Submission of objects to the database is the final and required step in making an assignment. This step makes the assignment definite, and makes public information regarding the assignment available to anyone seeking it. Care should therefore be taken to assure the correctness of the assignment number and of all relevant data prior to completing this step. For further instructions on how to register objects in the database, please see the appendix, section I. 5.1.4 Reservations not supported In accordance with the conservation goal, End Users are not permitted to reserve address space. Evaluation of IP address space requests must be based on demonstrated need. Address space assigned in the past should be used to meet the current request, if possible. Once an organisation has used its assigned address space, it can request additional address space based on an updated estimate of growth in its network. 5.1.5 Administrative ease The current rate of consumption of the remaining unassigned IPv4 address space does not permit the assignment of addresses for administrative ease. (Examples of this include, but are not limited to, ease of billing administration and network management .) 5.1.6 Utilisation Unless there are special circumstances, immediate utilisation should be at least 25% of the assigned address space, and the utilisation rate one year later should be at least 50%. Assignments must be based solely on realistic expectations as specified in the addressing plan and the current address space usage. End Users are not permitted to reserve addresses based on long term plans, because it fragments the address space. 5.1.7 Provider Independent vs. Provider Aggregatable addresses Provider Aggregatable Address Space LIRs operated by Internet Service Providers are allocated Provider Aggregatable (PA) address space that they assign to their End Users. If an End User changes service providers, their PA address space will have to be replaced. The End User will need to obtain a new address space assignment and return the previously assigned address space. Provider Independent Address Space In contrast to PA address space, PI address space can remain assigned to its user as long as the criteria for the original assignment are met. The apparent advantage of PI address space is that a User's hosts and routers need not be reconfigured if the user decides to change service providers. However, PI addresses are expensive to route because no use can be made of aggregation. LIRs must make it clear to the user which type of address space is assigned. Clear contractual arrangements that specify the duration of the address space assignment are mandatory for every assignment of PA address space. Although not strictly required, it is strongly recommended that contractual arrangements are made when assigning PI space as well. With respect to aggregation, the clear advantages of assigning PA space mandate that LIRs recommend its use whenever possible. End Users should, therefore, be advised to use PA space if it appears to be sufficient for their situation. For further information and more detailed recommendations concerning PI and PA addresses, please refer to the RIPE document: "Provider Independent versus Provider Aggregatable Address Space" at: http://www.ripe.net/ripe/docs/pi-pa.html 5.1.8 Private address space Using private addresses helps to meet the conservation goal. For this reason, users should always be informed that private addresses might be a viable option. For a thorough description of private address space, please refer to RFC 1918 [Rekhter96b]. 5.1.9 Static assignments Due to constraints on the available free pool of IPv4 address space, the use of static IP address assignments (e.g., one address per customer) for dial-up users is strongly discouraged. Organisations considering the use of static IP address assignment are expected to investigate and implement dynamic assignment technologies whenever possible. If assignments for static assignments are indeed made, special verification procedures apply. However, for services that are permanently connected to the Internet, static one-to-one connections is considered acceptable. Verification of usage will in these cases take place when the LIR is requesting approval for additional assignments. Please contact the RIPE NCC for details on applicable verification methods. 5.1.10 Web hosting Recent developments in some protocols (for example HTTP 1.1) have eliminated the need for one-to-one mapping of IP addresses to web sites. In accordance with the goal of conservation, the RIPE NCC policy strongly encourages the deployment of name-based web hosting versus IP-based web hosting. The RIPE NCC does acknowledge the need for IP-based web hosting for certain applications. Special verification methods apply for IP-based web hosting. 5.1.11 Assignment guidelines LIRs make assignments from its allocated address block. If the addresses are to be assigned from a range of address space allocated to the LIR making the assignment, then care must be taken to prevent fragmentation of the allocated space. Specifically, each set of address space assigned should start on a CIDR (bit) boundary. This helps to achieve the aggregation goal in address space assignments. Suppose an assignment request can be satisfied with either a number of small chunks of address space or with a single large one. For example, if 384 addresses are sufficient to satisfy a request, but no more than 256 will be used in a single physical subnet, then the user can be assigned a /24 and a /25 rather than a /23. This results in saving a /25 for another user. In general, and in accordance with the conservation goal, LIRs are encouraged to assign multiple ranges of addresses rather than a single large range. LIRs are always welcome to request advice from the RIPE NCC in making assignment decisions. Assignments larger than those which the LIR is authorised to make must be approved by the RIPE NCC in advance. The assignment size that an LIR is autorised to make without prior approval is based on the LIR's experience and is reflected in the LIR's assignment window. (See section 5.1.13.) 5.1.12 IP address space replacement procedures In general, address space should be replaced on a one-to-one basis. An assignment of PA space to replace previously assigned PI space can be made if the original assignment criteria are still met and if the address space to be replaced is currently used for the End User's network. Only if a large percentage of the original assignment is not in use (50%) will an End User be required to submit the usual documentation to the new LIR. This part of the request is then treated like any other request for assignment of additional addresses. The address space to be replaced (the individual address ranges and the total size) must be properly documented with the standard IP address space assignment request forms. For address space that was allocated by LIRs established within the framework of the RIPE NCC, a copy of the documentation is forwarded to the LIR or LIRs that assigned the address space being replaced. Before assigning the new address space, an agreement (preferably contractual) should be reached regarding the maximum period within which the previously assigned addresses will be returned to the original LIR or to the RIR for eventual reassignment. After the renumbering is complete, the RIPE database must be updated to reflect the changes. In general, a period of three months should be allowed for the End User to complete the transition to the new addresses. RFC 2008, "Implications of Various Address Allocation Policies for Internet Routing" [Rekhter96a], recommends a grace period of at least 30 days and no longer than six months. For exceptional cases, where the End User requests to keep both assignments for more than six months, agreement should be obtained for the proposed time frame from the RIPE NCC. For those addresses that have not been assigned by an LIR, or which were assigned by an LIR that has since closed, the RIR will act in lieu of the original LIR. 5.1.13 Assignment Window An Assignment Window (AW) refers to the maximum number of addresses that can be assigned by the LIR to an End User without prior approval by the RIPE NCC within a 12 month period. The Assignment Window procedure was put in place to achieve various levels of support, based on the level of experience of the LIR and to ensure that assignment criteria and procedures are properly applied by the LIRs. To assure that the conservation, aggregation, and registration goals are met, the assignment criteria and procedures need to be properly applied by all LIRs. All new LIRs start with an Assignment Window of zero (0). This means that every assignment requires prior approval by the RIPE NCC before becoming effective. The Assignment Window is not only applied to individual assignments, but to multiple assignments to the same End User in a 12 month period. If an LIR makes more than one assignment to an organisation in any 12 month period, the total amount of address space assigned may not exceed the LIR's assignment window. This also applies to address space used by the LIR for their internal network. Additional address space may be assigned to that organisation only upon approval by the RIPE NCC. Address space assignments larger than the LIR's Assignment Window is formally invalid until explicit approval is acquired from the RIPE NCC. Without this approval, the address space cannot be used as it may result in a failure to meet the uniqueness requirement for Internet addresses at a later date. The AW is regularly reviewed by the RIPE NCC Hostmasters, based on the proficiency of the LIR staff. The Assignment Window may be raised as the proficiency of the LIR staff increases and it can also be lowered if erroneous assignments are made by the LIR or if new LIR staff needs additional support. It should be noted that LIRs may approach the RIPE NCC for an evaluation of its Assignment Window. Additionally, LIRs are always welcome to approach the RIPE NCC for a second opinion on requests that fall within the LIR's Assignment Window. For further explanation of the Assignment Window procedures, please see Appendix, section II. 5.2 Policies and Guidelines for Allocations All LIRs that receive address space from the RIPE NCC shall adopt allocation and assignment policies that are consistent with the policies formulated by the RIPE community, as described in this document. An LIR cannot have more than one "open" (less than 80% assigned) allocation. The RIPE NCC is the only organisation permitted to allocate address space in its service region. An LIR is not allowed to re-allocate part of its allocation to any other organisation. An LIR can only make assignments. Moreover, without prior approval by the RIPE NCC, LIRs are not permitted to exchange or transfer allocated address space among them. 5.2.1 First allocation The minimum allocation size allocated to LIRs is a /20 (4096 addresses), according to the slow-start mechanism described below. It is expected that this prefix is announced as one aggregate. Allocations are made to LIRs that meet one of the following criteria: A. The LIR must demonstrate previous efficient utilisation of at least a /22 (1024 addresses). Or B. The LIR must demonstrate an immediate address space need of at least a /22 (1024 addresses.) Additionally, if current address space held by the LIR amounts to a /22 or less, then the LIR is required to renumber its address space into the allocation it receives from the RIPE NCC. As only assignments registered in the RIPE Database are considered valid, verification of previous utilisation by an organisation is based on the assignments registered in the database. 5.2.1 Slow-start mechanism The slow-start mechanism was put in place by the RIRs to ensure a consistent and fair policy for every LIR with respect to allocations. The slow-start mechanism was also introduced to prevent allocating large blocks of address space that will not be used. The idea is to allocate address space to LIRs at the rate it will be assigned. The minimum size of an individual address space allocation is /20 (4096 addresses). 5.2.2 Further allocations An LIR is eligible for additional address space allocation when at least eighty (80) percent of the currently allocated address space is assigned, or if a single assignment will require a larger set of addresses than can be satisfied with the allocated address space. Reservations are not counted as assignments. An LIR can set aside (or "reserve") address space in their allocation for customers, if they think the customers will grow beyond their assignments. However, once the LIR's allocation reaches depletion and the LIR starts running out of address space, they should reuse these "reserved" blocks by giving them to other customers. The RIPE NCC will consider "reservations" as free address space when evaluating an allocation request. The size of further allocations mainly depends on the assignment rate of previous allocations. To obtain a new allocation, an LIR should submit a request to the RIPE NCC that includes a complete list of the assignments made from their last allocation. However, all previous allocations made to the LIR also need to show a utilisation rate of at least 80%. The RIPE NCC will verify the LIR's utilisation rate, compare it with assignments registered in the database, and may request further information (such as documentation of some of the assignments) to determine the need for a new allocation. Additional address space will be allocated only after the information supplied with the request has been verified and a new allocation has been deemed necessary. 5.2.3 No guarantee of contiguous allocations A new allocation to an LIR cannot be expected to be contiguous with past allocations. While the RIPE NCC always aims to further the aggregation goal by allocate contiguous space, multiple allocations made to the same LIR can not be guaranteed to be contiguous and aggregatable with previous allocations. Contiguous allocations are merely done on a best effort basis. 5.2.4 Assignments to other providers In some cases, an LIR makes address space assignments for the customers of another ISP that, itself, does not operate an LIR. The LIR is responsible for all assignments from its allocation, even if there is an agreed involvement of the staff from the other ISP. Whereas the staff of the other ISP can and should be involved in processing the End User's request, local agreements regarding shared responsibility in the registration process are not recognised by the RIR and are strongly discouraged. If, at some point, an ISP decides to establish an LIR rather than using an existing LIR to obtain address space, then all subsequent assignments it makes should be from address space allocated to it from the RIPE NCC. Furthermore, any address space used by the ISP's customers that was acquired from a transit provider's allocations should be returned to the transit provider as soon as possible, and new assignments should be made to the End Users from the ISP's allocated address space. In the following subsections, we describe how an LIR can obtain an allocation and how allocated address space should be managed. 5.3 Operating an LIR LIRs process the vast majority of address space assignments to End Users. Most LIRs are operated by ISPs and offer IP registration services to the customers of the ISP. In this section, we describe a number of services offered by the RIPE NCC to facilitate the uniform implementation of the policies outlined in this document. We also outline procedures associated with IP registration services that LIRs are expected to follow in order to ensure that the policies are applied in a fair and impartial manner throughout the RIPE NCC service area. 5.3.1 Establishing a new LIR An LIR is established after submitting a request to the RIPE NCC that includes assurances that the relevant rules and guidelines defined in this and related documents are known and a commitment that the rules and guidelines will be followed. The process of setting up a new LIR is explained in detail in the RIPE Document, "Guidelines for Setting up a Local Internet Registry at the RIPE NCC": http://www.ripe.net/ripe/docs/new-lir.html 5.3.2 LIR operations In this section, we outline a number of practices that should be followed when running an LIR. Most have been established traditionally by consensus among the LIRs in the RIPE community. LIRs should adhere to the established practices, or move to have them modified by starting discussions on the mailing list, and actively participate in the LIR working group. 5.3.3 Record keeping LIRs must maintain proper records about all address assignments made by them. Every LIR should keep all information collected from those customers who are in the process of making a request for an IP address space and ASN assignment. This data is needed for the evaluation of subsequent requests for the same customers, for audits by the RIR, and for the resolution of any questions that may arise regarding assignments. The records must include: * The original request * All supporting documentation * All related correspondence between the LIR and the customer * The assignment decision, including: * Reasons behind any unusual decision * The person responsible for making the decision The chronology of events and the persons responsible should be stated clearly in the records. In order to facilitate the exchange of information, it is highly recommended that documents are kept electronically and that they are readily accessible. If requested, any of this information should be made available to the RIPE NCC in English. 5.3.4 Contact persons Every LIR must provide the RIPE NCC with a list of contact persons. The contact persons should be those who submit address space and AS number requests for the LIR. The contact information should be kept up to date. Address space and AS number requests will only be accepted from LIR staff members that are registered as contact persons for an LIR. This is necessary to ensure confidentiality. 5.3.5 Publishing LIR policy The core business of an LIR is to assign IP addresses. These have no intrinsic value, although they are essential for Internet connectivity. They must be assigned judiciously with regard to volume; strategically with regard to aggregation; and equitably as between different ISPs. The best assurance of these objectives is "perfect knowledge" by the market of the policies of LIRs. For this reason, every LIR must publish its policies regarding LIR operations. LIRs must register their policies with the RIPE NCC, which will publish them. The information to be published should include at least the following: 1) The Community Served An LIR should provide a concise description of the community it serves. The following description is sufficient: "We serve customers of company, an ISP with mostly type customers based in countries NN AA BB and CC". The LIR should also indicate whether it will provide IP address space registration services to those not buying other services from them. 2) Charging Policies An LIR must publish its charging policy. The policy is defined in the RIPE Document: "Charging by Local Internet Registries". http://www.ripe.net/ripe/docs/chargingbylirs.html Address space is a finite resource with no intrinsic value and direct costs cannot be ascribed to it. While they may not charge for address space as such, LIRs may charge for their administrative and technical services. LIRs must publish their operating procedures and details of the services they offer and the conditions and terms that apply, including scales of tariffs if applicable." 3) Terms of Assignment The LIR must publish its policy about assigning Provider Aggregatable (PA) and Provider Independent (PI) address space, and the terms and conditions that apply. 5.3.6 Mergers, take-overs, and closures of LIRs If an LIR changes ownership (e.g. merger, sale, or take-over), then the new entity must register with the RIPE NCC any changes to its network usage and contact personnel. If the effect of a take-over, sale, or merger is that the LIR changes its name, then the LIR must provide to the RIPE NCC relevant legal documentation supporting the name change. For further information on change of LIR ownership and closures, please refer to the RIPE Document: [Insert RIPE Document Name & Link here] 5.3.7 External Quality Assurance In order to promote consistent and fair application of assignment criteria, with regard to conservation and registration of address space and aggregation of routing information, the RIPE NCC checks consistency of registry data and performs auditing of LIRs. To ensure that LIRs are following the assignment criteria, and entering assignments into the database correctly, the RIPE NCC may contact an LIR to ask for documentation or for more information about certain requests or database entries. If the RIPE NCC finds problems, it will work with the LIR to correct these. If necessary, the RIPE NCC may take corrective actions, such as lowering the LIR's Assignment Window. This activity is described in detail in the RIPE Document, "RIPE NCC Consistency and Auditing Activity", which can be found at: http://www.ripe.net/ripe/docs/auditing.html For further information on the RIPE NCC auditing activity, please refer to: http://www.ripe.net/audit 5.3.8 When an LIR is closed by the RIPE NCC The RIPE NCC may decide to close an LIR that stops paying its bills to the RIPE NCC and/or cannot be contacted by the RIPE NCC for a significant period of time. Moreover, if an LIR consistently violates the policies established by IANA, or within the RIPE NCC community, in spite of multiple warnings, then it may be closed. The RIPE NCC will send the LIR a message to notify it of its closure. The LIR must then provide documentation to the RIPE NCC regarding its allocated address space and follow the other procedures for closing an LIR outlined in RIPE Document: [Insert RIPE Document Name & Link here] If the LIR does not provide the RIPE NCC with the proper documentation, the RIPE NCC will determine which address space and ASNs should be returned to the public pool of IP address space. 5.4 Reverse Delegation responsibilities The RIRs are responsible for maintaining IN-ADDR.ARPA records only for the parent blocks of IP addresses issued directly to the ISPs and for CIDR blocks smaller than /16. LIRs with a prefix length of /16 or shorter will be responsible for maintaining all IN-ADDR.ARPA resource records for their customers. IN-ADDR.ARPA resource records for networks not associated with a specific LIR will continue to be maintained by the RIRs. Internet Providers and End Users with address blocks must verify their own internal networks are properly represented in IN-ADDR records, either by providing that service themselves, or delegating it to others. For details on the RIPE NCC Reverse Delegation procedures, please refer to: [Insert RIPE Document Name & Link here] 5.5 Autonomous System Numbers Autonomous System (AS) Numbers are assigned to organisations that are multihomed and have a single, clearly defined routing policy that is different from their providers' routing policies. AS Numbers should be requested in accordance with the guidelines expressed in RFC 1930, "Guidelines for the creation, selection, and registration of an Autonomous System". In order to help decrease global routing complexity, a new AS Number should be created only if a new routing policy is required. Autonomous System Numbers should be requested through the European Autonomous System Number Application Form that can be found at: http://www.ripe.net/ripe/docs/asrequest.html The RIPE NCC assigns AS numbers for Autonomous Systems that are located in the RIPE NCC service region. As for IP address requests, the RIPE NCC accepts requests for AS numbers only from LIRs that contribute to the RIPE NCC. Returning an AS Number If an organisation has an AS Number that is no longer in use, it can be returned to the public pool of AS Numbers by sending a message to . It can then be re-assigned to another Autonomous System by the RIPE NCC. 6.0 Glossary (This section provides a brief description of important terms used in this document.) Address Space -- Specific to global, unicast IPv4 and IPv6 addresses, a unique numeric address used to identify a machine on the Internet (i.e., 123.456.789.012). An address space represents an extent of storage available to a program. Aggregation --- One of the main goals of Internet administration, aggregation refers to the distribution of public Internet addresses in a hierarchical manner that permits the "combining" of routing information and limiting the number of routing entries advertised in the Internet. This is necessary to ensure the proper operation of Internet routing. Allocation -- The range of addresses made available by the RIPE NCC to an LIR, which in turn is used by the LIR in assigning address space to End Users. The LIR is not allowed to sub-allocate its allocation to any other organisation. It can only make assignments to End Users. The minimum size of the first allocation to an LIR is a /20 (4096 addresses). The RIRs get their allocations from the Internet Assigned Numbers Authority (IANA). Assignment ---Address space provided to an End User entity by an RIR or LIR for use on their own network, not to be further distributed to customers. The LIR guarantees that no other End User will be assigned the same address space during the validity of the assignment. Assignments of any kind of address space are valid for as long as the original criteria on which the assignment was based are still valid. Assignment Window (AW) -- The maximum number of addresses that can be assigned by an LIR to an End User without prior approval by the RIPE NCC. The AW for new LIRs is zero (0); every assignment requires prior approval by the RIPE NCC. As the LIR staff becomes familiar with policies, procedures, and makes less errors, the AW size is increased to match the size of requests sent by the LIR. Autonomous System (AS) -- Group of IP networks run by one or more network operators that has a single and clearly defined external routing policy. The term "AS" is often confused and even misused as a convenient way of grouping together a set of networks that belong under the same administrative umbrella, even if within that group of networks there are various routing policies. The RIPE NCC provides the "community" concept for such use. Autonomous Systems can, strictly speaking, have only one external routing policy. Autonomous System Number -- A unique number associated with an Autonomous System that is used both in exchange of exterior routing information and as an identifier of the AS itself. Exterior routing protocols such as Border Gateway Protocol (BGP) and Exterior Gateway Protocol (EGP) are used to exchange routing information between Autonomous Systems. Conservation --- One of the main goals of Internet administration, it refers to the fair distribution of globally unique Internet address space according to the operational needs of the End Users and ISPs operating networks using this address space. This aids in the prevention of stockpiling in order to maximise the lifetime of Internet address space. Contiguous Allocation -- An additional address block that can be combined with another allocated address range to a larger aggregate. End User -- An entity that uses IP address space for its own network only and does not provide services to customers. First Allocation -- An address block allocated to an LIR upon the first address space assignment request the RIPE NCC receives from that LIR. Internet Community -- An open, collaborative community of organisations and individuals, operating wide area IP networks. In this document we refer mainly to the RIPE community. Internet Registry System -- Created through membership-based associations, the Registry System exists to provide IP address allocations and registration services. It consists of the following levels of hierarchy as seen from the top, down: IANA, RIRs, LIRs, End Users. It was established some 10 years ago to achieve the goals of public address space distribution, which are uniqueness, aggregation, conservation, and registration. Local Internet Registry (LIR) -- An organisation, established under the authority of a Regional Internet Registry, that assigns IP addresses and Autonomous System Numbers to End Users. LIRs are mostly operated by ISPs and serve their customers and - smaller ISPs. The maintenance of administrative information regarding assigned address space is the responsibility of the LIR making the assignment, not the ISP providing connectivity. Only LIRs can hold IP address allocations that they assign to their End Users. Private Addresses -- Addresses assigned to hosts that: 1) do not require access to hosts in other enterprises or the Internet at large, or, 2) need access to a limited set of outside services (e.g., e-mail, FTP, netnews, remote login) which can be handled by mediating gateways (e.g., application layer gateways). (See RFC 1918) Provider Aggregatable Address Space -- PA address space is Provider Aggregatable, meaning that the addresses are part of a bigger block of addresses allocated to the upstream provider. In contrast, Provider Independent (PI) addresses are not part of an LIR's allocated block. More information about PI and PA address space is explained in the RIPE Document, "Provider Independent versus Provider Aggregatable Address Space". Provider Independent Address Space -- PI address space can remain assigned with its End Users even if they move to another ISP, unlike with PA address space. The duration of the assignment is independent of the use of a particular ISP's services. The advantage is that the End Users' hosts and routers need not be reconfigured. However, the RIPE community discourages the use of PI address space because they may not be routed on certain parts of the Internet where routing tables grow too big. PI ranges are usually small, so they are the first candidates to be dropped from routing tables. PI users cannot receive more addresses for routing reasons. More information about PI address space is explained in the RIPE Document "Provider Independent versus Provider Aggregatable Address Space". Public Addresses -- Addresses assigned to hosts that need network layer access outside the enterprise (provided via IP connectivity). These hosts require IP addresses that are globally unambiguous. (See RFC 1918) Regional Internet Registry -- RIRs are established under the authority of the Internet Assigned Numbers Authority (IANA). They operate in large geopolitical regions, such as continents, and among their duties are the coordination and representation of LIRs in their respective regions, allocation and assignment of IPv4 and IPv6 address space, AS Numbers, and maintenance of public databases. There are three existing RIRs in the world: RIPE NCC, ARIN, and APNIC. Registration -- One of the main goals of the Internet, it is the provision of a public registry documenting address space allocations and assignments. This is necessary to ensure uniqueness and to provide information for Internet troubleshooting at all levels. (See RFC 2050) Renumbering a Network -- - Changing the IP host addresses, and perhaps the network mask, of each device within the network that has an address associated with it. (See RFC 2071) RIPE Community -- Made up of organisations and individuals with an interest in the operation of wide area networks or Internet administration. RIPE is a collaborative organisation open to all parties. The objective of RIPE is to ensure the administrative and technical coordination necessary to enable the operation of an IP network in the RIPE region. There are no membership requirements for participation in RIPE and activities are performed on a voluntary basis. The RIPE community is an important source of public input for the RIPE NCC. RIPE Database -- A public Whois Database that contains information about allocations and assignments of IP address space, Internet routing, and related objects in the RIPE region. It is known as the RIPE Network Management Database or, more usually, the "RIPE Database". The information in the database is available to the public for agreed Internet operational purposes. This supports Network Information Centres and Network Operation Centres all over Europe and beyond to perform their respective tasks. Slow-Start Mechanism: -- The first allocation that an LIR receives will be the size of the minimum practical allocation. The slow-start policy is used by all Regional Internet Registries to prevent allocations of large blocks of address space that may then remain substantially unassigned. Uniqueness: One of the main goals of the Internet, it is the insurance of IP addresses being globally unique. 7.0 References To be completed 8.0 Appendices I. RIPE Database procedures Registration of objects pertaining to an assignment in the RIPE Database makes it possible to track the use of address space, facilitate operational contacts, and facilitate studies of address allocation. These activities are essential for the effective maintenance of the Internet. Submission of objects to the Database is the final and required step in making an assignment. This step makes the assignment definite, and makes public information regarding the assignment available to anyone seeking it. Care should, therefore, be taken to assure the correctness of the assignment and of all relevant data prior to completing this step. The information collected about the User's organisation in the Network Template (see http://www.ripe.net/ripe/docs/iprequestsupport.html) is used to construct an inetnum database object. The range of addresses assigned to the User is also entered in the inetnum object, and is specified in dotted quad notation. For example, if an organisation is assigned a /22 address set for 1024 network addresses, the range will be something like: 193.1.192.0 - 193.1.195.255. Unless up-to-date objects are already available in the RIPE Database, in addition to the inetnum object, a person object must be submitted for each person specified in the tech-c and admin-c fields of the inetnum object. The person object needs to reference a nic-handle. The information should remain in the Database for as long as the original assignment is valid. If the address space is returned, the LIR that made the assignment must remove the old entry from the Database. Assuming the assigning LIR has properly stored information gathered in the assignment process for future reference, submission of the objects described above completes the assignment process. The LIR can now provide the End User with the assigned address range and any other data relevant to its use. The type of assigned address space must be registered in the status attribute of the inetnum object within the RIPE Database by the assigning LIR. The possible values of this attribute are: ASSIGNED PA This is used for PA address space that has been assigned to an End User. ASSIGNED PI This is used for PI address space that has been assigned to an End User. Every new address space assignment must be marked as PA or PI in the RIPE Database. Moreover, to improve registration of old assignments, LIRs are encouraged to mark past assignments in the RIPE Database with PA or PI as appropriate. Any assigned address space without an explicit type in the status attribute is assumed to be PI space. Priority should, therefore, be given to marking PA space as such. Allocation registration Allocations are registered in the RIPE Database by the RIPE NCC using inetnum objects. Information about the LIR, which is similar to that for an End User receiving an assignment, is stored together with the range of allocated address space and its type. The range of addresses is stored in the inetnum field in dotted quad notation. The type of address is stored in the status field and can have one of the following values: ALLOCATED PA This address space has been allocated to an LIR or an RIR, and all assignments made from it are provider aggregatable. This is the most common allocation type for LIRs. ALLOCATED PI This address space has been allocated to an LIR, and all assignments made from it are provider independent. ALLOCATED UNSPECIFIED This address space has been allocated to an LIR, and assignments made from it may be either provider aggregatable or provider independent. This type of allocation is obsolete, and will not be applied to future allocations. Some older allocations have been used for both PA and PI assignments, and as such receive this allocation type. These objects are maintained by the RIPE NCC. When hierarchical authorisation is implemented, authorisation can be used for the creation of inetnum objects "under" the allocation objects. ASN registration Aut-num objects are registered in the RIPE Database by the RIPE NCC upon approval of an AS Number request, using the aut-num template provided in the request form by the requesting LIR. It is important to note that once the aut-num object is entered into the Database, it is the LIR's responsibility to maintain the object. It is also the LIR's responsibility to keep the information in the aut-num object up-to-date. For information and instructions on the use of the RIPE Database, please refer to the RIPE Document: "RIPE Database Reference Manual" at: http://www.ripe.net/ripe/docs/databaseref-manual.html II. Assignment Window As explained in Section 5.1.13, the Assignment Window is the maximum number of addresses that can be assigned by the LIR to an End User without prior approval by the RIPE NCC. This is expressed in "/nn" notation. Therefore, an LIR with an Assignment Window of /23 is allowed to assign up to and including 512 addresses to an End User without prior approval of the RIPE NCC. All new LIRs start with an Assignment Window of "0". This means that every assignment requires prior approval by the RIPE NCC before becoming effective. Ex. 1: The LIR has an Assignment Window of "0". The LIR has to send in every assignment to the RIPE NCC for approval. Ex. 2. The LIR has an Assignment Window of /26. The LIR can assign up to 64 addresses per customer in a 12 month period. Larger assignments need to be sent to the RIPE NCC for approval. Any additional assignments exceeding 64 addresses also need to be sent to the RIPE NCC for approval. The AW is regularly reviewed by the RIPE NCC Hostmasters. Raising of the Assignment Window As the proficiency of the LIR staff increases, the size of their Assignment Window may be raised. This is determined based on whether assignment documentation presented to the RIPE NCC is correctly completed; whether good judgement is shown in the evaluation of address space requests; whether past assignments have been properly registered; and on the experience of the LIR with handling larger assignments. An LIR can also approach the RIPE NCC if they believe they are eligible for a raise of its Assignment Window. Lowering of the Assignment Window An established LIR is responsible to train new staff to handle address space assignments, according to the policies and procedures described in this document. Sometimes, due to time constraints on experienced LIR staff, the training is not performed sufficiently. As well, new staff members of a well-established LIR may make errors both in judgement and procedure before they are properly trained to make assignments. If such errors are noticed by the RIPE NCC, the LIR will be notified. If errors happen repeatedly, the Assignment Window of the LIR may be decreased to prevent the new staff members from making erroneous assignments involving large amounts of address space. The Assignment Window may again be increased, based on the criteria stated above. The Assignment Window may be lowered as a result of an audit where erroneous assignments are noted, or to enforce overdue payment. In some cases, LIRs may request a temporary lowering of their Assignment Window as a method to train new staff. III. Useful URLs RIPE NCC Registration Services information http://www.ripe.net/rs/ RIPE NCC E-mail contacts http://www.ripe.net/ripencc/about/contact.html RIPE NCC Frequently Asked Questions http://www.ripe.net/ripencc/faq/index.html Quick Tips for IP and AS Requests http://www.ripe.net/ripencc/tips/tips.html IPv6 Allocation and Assignment Information http://www.ripe.net/ipv6 IV. Bit Boundary Chart Historically, IP addresses have been assigned in the form of network numbers of class A, B, or C. With the advent of classless inter-domain routing (CIDR) this classful restrictions are no longer valid. Address space is now allocated and assigned on bit boundaries. The following table illustrates this: +----------------------------------------------+ |addrs bits pref class mask | +----------------------------------------------+ | 1 0 /32 255.255.255.255 | | 2 1 /31 255.255.255.254 | | 4 2 /30 255.255.255.252 | | 8 3 /29 255.255.255.248 | | 16 4 /28 255.255.255.240 | | 32 5 /27 255.255.255.224 | | 64 6 /26 255.255.255.192 | | 128 7 /25 255.255.255.128 | | 256 8 /24 1C 255.255.255 | | 512 9 /23 2C 255.255.254 | | 1K 10 /22 4C 255.255.252 | | 2K 11 /21 8C 255.255.248 | | 4K 12 /20 16C 255.255.240 | | 8K 13 /19 32C 255.255.224 | | 16K 14 /18 64C 255.255.192 | | 32K 15 /17 128C 255.255.128 | | 64K 16 /16 1B 255.255 | | 128K 17 /15 2B 255.254 | | 256K 18 /14 4B 255.252 | | 512K 19 /13 8B 255.248 | | 1M 20 /12 16B 255.240 | | 2M 21 /11 32B 255.224 | | 4M 22 /10 64B 255.192 | | 8M 23 /9 128B 255.128 | | 16M 24 /8 1A 255 | | 32M 25 /7 2A 254 | | 64M 26 /6 4A 252 | | 128M 27 /5 8A 248 | | 256M 28 /4 16A 240 | | 512M 29 /3 32A 224 | |1024M 30 /2 64A 192 | +----------------------------------------------+ 'bits' The size of the allocation/assignment in bits of address space. 'addrs' The number of addresses available; note that the number of addressable hosts normally is 2 less than this number because the host parts with all equal bits (all 0s, all 1s) are reserved. 'pref' The length of the route prefix covering this address space. This is sometimes used to indicate the size of an allocation/assignment. 'class' The size of the address space in terms of classful network numbers. 'mask' The network mask defining the routing prefix in dotted quad notation. Throughout this document, we refer to the size of allocation and assignments in terms of 'bits of address space' and add the length of the route prefix in parentheses wherever appropriate. From bortzmeyer at gitoyen.net Thu Aug 30 10:47:44 2001 From: bortzmeyer at gitoyen.net (Stephane Bortzmeyer) Date: Thu, 30 Aug 2001 10:47:44 +0200 Subject: SSL and IP-based Web hosting (Was: policy changes since ripe-185 In-Reply-To: <200108291740.TAA29378@office.ripe.net>; from nurani@ripe.net on Wed, Aug 29, 2001 at 07:40:13PM +0200 References: <200108291740.TAA29378@office.ripe.net> Message-ID: <20010830104744.A19459@internatif.org> On Wed, Aug 29, 2001 at 07:40:13PM +0200, Nurani Nimpuno wrote a message of 55 lines which said: > - IP-based webhosting strongly discouraged > "IP assignment for virtual webhosting", Nurani Nimpuno (17 Nov 1999) > http://www.ripe.int/ripe/mail-archives/lir-wg/19991001-20000101/msg00020.html > IP assignment for virtual webhosting, Nurani Nimpuno (RIPE36 Budapest) This proposal, unless it is rewritten with some comments, do not mention the main reason people use IP-based webhosting: SSL. http://www.modssl.org/docs/2.8/ssl_faq.html#ToC47 From nurani at ripe.net Thu Aug 30 11:27:50 2001 From: nurani at ripe.net (Nurani Nimpuno) Date: Thu, 30 Aug 2001 11:27:50 +0200 Subject: SSL and IP-based Web hosting (Was: policy changes since ripe-185 In-Reply-To: Your message of Thu, 30 Aug 2001 10:47:44 +0200. <20010830104744.A19459@internatif.org> References: <20010830104744.A19459@internatif.org> Message-ID: <200108300927.LAA21032@office.ripe.net> Dear Stephane, First, I simply wish to clarify that the list sent out was a list of policy decisions made in the community through discussions in the last years. These policy changes were all reached through consensus in the lir-wg. If you read the discussion on the mailing list and the minutes from the lir-wg at RIPE 36 last year, you will find that several technical restraints were brought forward for the use of name-based webhosting. This is the reason why it was agreed that name-based webhosting should not be made mandatory. It was agreed in the community to not compile a list of services, applications etc that require IP-based webhosting as this would be a rather difficult task. However, it was (and is) recognised that these technical restraints exist and are valid. This is reflected in the section describing the webhosting policy, in the raw draft of the new policy document sent out yesterday. Kind regards, Nurani *--------------------------------------------------------* | Nurani Nimpuno | | Internet Address Policy Manager | | RIPE Network Co-ordination Centre | | http://www.ripe.net | *--------------------------------------------------------* Stephane Bortzmeyer writes: * On Wed, Aug 29, 2001 at 07:40:13PM +0200, * Nurani Nimpuno wrote * a message of 55 lines which said: * * > - IP-based webhosting strongly discouraged * > "IP assignment for virtual webhosting", Nurani Nimpuno (17 Nov 1999) * > http://www.ripe.int/ripe/mail-archives/lir-wg/19991001-20000101/msg00020.h * tml * > IP assignment for virtual webhosting, Nurani Nimpuno (RIPE36 Budapest) * * This proposal, unless it is rewritten with some comments, do not * mention the main reason people use IP-based webhosting: SSL. * * http://www.modssl.org/docs/2.8/ssl_faq.html#ToC47 * From fm at st-kilda.org Fri Aug 31 13:12:48 2001 From: fm at st-kilda.org (Fearghas McKay) Date: Fri, 31 Aug 2001 12:12:48 +0100 Subject: Interim Policy proposal for IPv6 Address Assignment Policy for Internet Exchange Points Message-ID: Following discussion between the WG-Chairs and the NCC we have the following proposed draft. To enable allocations to be made as soon as possible we are soliciting comments over the next few days but unless there are any issues we would like to start making allocations by the end of next week, ie 7th September 2001. Please send any comments to the LIR-WG list We propose a joint session to be held at RIPE40 where we can discuss the initial size allocations, information required in the forms and other issues raised by the community after which we will formalise the proposal. Thanks Fearghas EIX-WG Chair -- IPv6 Address Assignment Policy for Internet Exchange Points =========================================================== 1. Abstract ----------- This document describes a policy for Internet Exchange Points (IXPs) under which unique IPv6 address space to be used for the infrastructure of the Internet Exchange Point can be obtained from a Regional Internet Registry (RIR). 2. Background ------------- It has been recognised that there are scenarios in which it is not desirable for IXPs to obtain address space from one of the Internet Service Providers (ISPs) connecting at the IXP. In these cases it is viable to have unique IPv6 address space assigned directly from an RIR. This address space is needed to adress the Exchange fabric. This issue has been brought forward to the RIPE community in May 2000 and has subsequently been discussed at RIPE Meetings and on public RIPE mailing lists. The conclusions of these discussions are described in this document. It is expected that the same policy will be accepted in the ARIN and the APNIC region at which point it will be incorporated in the Global IPv6 Policy document. 3. Definition ------------- An Internet Exchange Point is defined as a physical network infrastructure (layer 2) operated by a single entity with the purpose to facilitate the exchange of Internet traffic between Internet service providers. The number of Internet Service providers connected should at least be three and there must be a clear and open policy for others to join. Addresses needed for other purposes (e.g. additional services provided to the members) should be aquired through other appropriate means ( e.g. an upstream ISP). 4. Policy --------- An IXP that seeks to obtain an IPv6 address assignment by the RIR in its region, needs to submit a request to that RIR. IXPs operating in the RIPE NCC service region should use the 'IPv6 Request Form for Internet Exchange Points' (http://www.ripe.net/ripe/docs/ipv6request-exchangepoint.html). After approval of the request, the RIR will make the assignment. Since the address space does not need to be routable globally and an IXP is expected to only have one subnet, a /64 (64 bits of address space) will be assigned in most cases. In the case the IXP is using multiple fabrics (e.g. unicast separated for multicast), multiple /64s can be assigned to the IXP. IP Address requests can only be handled if the requestor is a Local Internet Registry (LIR) or if the request made through an existing LIR. 5. Other Considerations ----------------------- It should be noted that ISPs usually do not announce address space used on the IXP mesh itself to their peers. That means the address space assigned under this policy is likely not to be routable globally. From pekkas at netcore.fi Fri Aug 31 14:58:04 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 31 Aug 2001 15:58:04 +0300 (EEST) Subject: Interim Policy proposal for IPv6 Address Assignment Policy for Internet Exchange Points In-Reply-To: Message-ID: On Fri, 31 Aug 2001, Fearghas McKay wrote: > Please send any comments to the LIR-WG list > > 5. Other Considerations > ----------------------- > > It should be noted that ISPs usually do not announce address space > used on the IXP mesh itself to their peers. That means the address > space assigned under this policy is likely not to be routable > globally. Care to explain how traceroute through these IX's is supposed to work, if the node performing traceroute, ping, or whatever, is not a small-scale customer (ie. default route) of the IX participants? As far as I can see, this is impossible. Moreover, as the scope of these addresses is global, the routers responding to ping, traceroute etc. cannot select a better source address (e.g. a truly global address assigned to loopback device) for the response packets. The only way to deal with this, as far as I can see, is just assign like /35's or equivalent to IX's too (it's not like there are thousands of them!), or make the assignments from a special block which MUST be exempted from BGP DFZ aggregation filtering rules. Or, you could define this allocation policy only for a specific kind of exchange points (client organizations of the IX participants must not participate in DFZ so that there wouldn't be aggregation filtering; often this could mean only bi-lateral peering of "small-scale" DFZ, or smaller, organizations). Practically, I suppose, this excludes IX's where there are upstream/long-haul (e.g. trans-atlantic) operators present. Practically, the address assignment seems equivalent of adding no-export BGP community to some /35 prefix, using it for point-to-point links and announcing it everywhere. With some IX configurations, the results might not be pretty for tracerouters. I guess the easiest approach here might be to clarify (e.g. by giving examples) which kind of IX's should/should not adopt this approach based on the routability arguments. (if this is not done, the IX's that can't adopt this approach might be given cold treatment when they apply for another kind of addresses, and be pointed out that there is already a scheme for IX's) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From gert at space.net Fri Aug 31 15:06:52 2001 From: gert at space.net (Gert Doering) Date: Fri, 31 Aug 2001 15:06:52 +0200 Subject: Interim Policy proposal for IPv6 Address Assignment Policy for Internet Exchange Points In-Reply-To: ; from pekkas@netcore.fi on Fri, Aug 31, 2001 at 03:58:04PM +0300 References: Message-ID: <20010831150652.E80940@Space.Net> Hi, On Fri, Aug 31, 2001 at 03:58:04PM +0300, Pekka Savola wrote: > On Fri, 31 Aug 2001, Fearghas McKay wrote: > > Please send any comments to the LIR-WG list > > > > 5. Other Considerations > > ----------------------- > > > > It should be noted that ISPs usually do not announce address space > > used on the IXP mesh itself to their peers. That means the address > > space assigned under this policy is likely not to be routable > > globally. > > Care to explain how traceroute through these IX's is supposed to work, if > the node performing traceroute, ping, or whatever, is not a small-scale > customer (ie. default route) of the IX participants? For a traceroute *through* the IX you don't need the route to that /64. It might get filtered if you do RPF filtering (but multihomed customers usually don't, because it doesn't work), but reachability of the hosts *behind* the IX is not a problem. Whether it's desireable to be able to traceroute *to* an IX address is debateable (but that's not different from today), this is what wouldn't work. Gert Doering -- NetMaster -- 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 Fri Aug 31 15:17:19 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 31 Aug 2001 16:17:19 +0300 (EEST) Subject: Interim Policy proposal for IPv6 Address Assignment Policy for Internet Exchange Points In-Reply-To: <20010831150652.E80940@Space.Net> Message-ID: On Fri, 31 Aug 2001, Gert Doering wrote: > On Fri, Aug 31, 2001 at 03:58:04PM +0300, Pekka Savola wrote: > > Care to explain how traceroute through these IX's is supposed to work, if > > the node performing traceroute, ping, or whatever, is not a small-scale > > customer (ie. default route) of the IX participants? > > For a traceroute *through* the IX you don't need the route to that /64. > It might get filtered if you do RPF filtering (but multihomed customers > usually don't, because it doesn't work), but reachability of the hosts > *behind* the IX is not a problem. RPF is an additional issue, granted, but not the point here. Traceroute will skip a hop or two, ie. those p-t-p links where these internal addresses are used; these might be crucial when debugging or tracing where the traffic goes. This might make (depending on the topology) a 15 second wait for the magic '* * *' combination. After and before these, it will continue in a normal fashion. But boy, would this be annoying.. > Whether it's desireable to be able to traceroute *to* an IX address is > debateable (but that's not different from today), this is what wouldn't > work. Different from today how? Not necessarily. One can use global addresses where you can traceroute to without problems. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From gert at space.net Fri Aug 31 15:25:19 2001 From: gert at space.net (Gert Doering) Date: Fri, 31 Aug 2001 15:25:19 +0200 Subject: Interim Policy proposal for IPv6 Address Assignment Policy for Internet Exchange Points In-Reply-To: ; from pekkas@netcore.fi on Fri, Aug 31, 2001 at 04:17:19PM +0300 References: <20010831150652.E80940@Space.Net> Message-ID: <20010831152519.F80940@Space.Net> Hi, On Fri, Aug 31, 2001 at 04:17:19PM +0300, Pekka Savola wrote: > > It might get filtered if you do RPF filtering (but multihomed customers > > usually don't, because it doesn't work), but reachability of the hosts > > *behind* the IX is not a problem. > > RPF is an additional issue, granted, but not the point here. > > Traceroute will skip a hop or two, ie. those p-t-p links where these > internal addresses are used; these might be crucial when debugging or > tracing where the traffic goes. No, it won't. Unless you're RPF-filtering, you won't be able to "ping" those IPs, but traceroute will show them just fine, including DNS. > This might make (depending on the topology) a 15 second wait for the magic > '* * *' combination. No. As with a traceroute showing RFC1918 IPs today - unless you explicitely filter those packets, the non-reachability won't harm traceroute. [..] > > Whether it's desireable to be able to traceroute *to* an IX address is > > debateable (but that's not different from today), this is what wouldn't > > work. > > Different from today how? Not necessarily. One can use global addresses > where you can traceroute to without problems. Quite a number of IXPs do not want their transit network to be announced into the global table. So that's what you will have with IPv6 as well. If an IXP wants to use globally routed addresses, he can always become a LIR and apply for a /35. What we're talking about is for those IXPs that need a /64 and do not want to see / need to have it routed globally. Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From he at uninett.no Fri Aug 31 15:24:02 2001 From: he at uninett.no (Havard Eidnes) Date: Fri, 31 Aug 2001 15:24:02 +0200 (CEST) Subject: Interim Policy proposal for IPv6 Address Assignment Policy for Internet Exchange Points In-Reply-To: <20010831150652.E80940@Space.Net> References: <20010831150652.E80940@Space.Net> Message-ID: <20010831.152402.86540044.he@uninett.no> > For a traceroute *through* the IX you don't need the route to that /64. > It might get filtered if you do RPF filtering (but multihomed customers > usually don't, because it doesn't work), [...] The less-strict "reachable-via-any" (I forget its exact syntax, but should be usable by multihomed sites) unicast RPF checking will however also break the traceroute if the /64 isn't announced as reachable in the DFZ. Regards, - H?vard From djp-ripe-lists at djp.net Fri Aug 31 15:30:39 2001 From: djp-ripe-lists at djp.net (Dave Pratt) Date: Fri, 31 Aug 2001 15:30:39 +0200 (CEST) Subject: Interim Policy proposal for IPv6 Address Assignment Policy for Internet Exchange Points In-Reply-To: Message-ID: Hiya all, Unfortunately, I must respond against the proposal as it stands with use of a /64 allocation. Allocations of /64 for the peering LAN can be obtained already from a separate block (I forget the details - but I think from a US based ISP only block managed by David Huberman). I fail to see therefore what this proposal helps with. This does not solve the problem as I see it, which is how to reliably, and independently of a particular ISP, multihome the infrastructure associated with the exchange point. From which range do the addresses for www.IXP.net or lg.IXP.net or term-serv.IXP.net come from ? For this I propose globaly routable allocations be made, with a size of at least /48. The IXP can then decide whether to use part of that for the exchange LAN, or whether to get a separate /64. Cheers Dave On Fri, 31 Aug 2001, Fearghas McKay wrote: ->Since the address space does not need to be routable globally and an ->IXP is expected to only have one subnet, a /64 (64 bits of address ->space) will be assigned in most cases. -> ->In the case the IXP is using multiple fabrics (e.g. unicast separated ->for multicast), multiple /64s can be assigned to the IXP. From fm at st-kilda.org Fri Aug 31 15:45:28 2001 From: fm at st-kilda.org (Fearghas McKay) Date: Fri, 31 Aug 2001 14:45:28 +0100 Subject: Interim Policy proposal for IPv6 Address Assignment Policy for Internet Exchange Points In-Reply-To: References: Message-ID: Hi Dave At 3:30 pm +0200 31/8/01, Dave Pratt wrote: >Hiya all, > >Unfortunately, I must respond against the proposal as it stands with use of a >/64 allocation. > >Allocations of /64 for the peering LAN can be obtained already from a separate >block (I forget the details - but I think from a US based ISP only block >managed by David Huberman). I fail to see therefore what this proposal helps >with. > >This does not solve the problem as I see it, which is how to reliably, and >independently of a particular ISP, multihome the infrastructure associated >with the exchange point. From which range do the addresses for www.IXP.net or >lg.IXP.net or term-serv.IXP.net come from ? > >For this I propose globaly routable allocations be made, with a size of at >least /48. The IXP can then decide whether to use part of that for the >exchange LAN, or whether to get a separate /64. The initial allocations will be made with a boundary of /48 to allow for a change to be made if the consensus in Prague is for /48 rather than /64. The address allocation is for infrastructure - so it is likely to filtered, and it will all come from a /35 to ease filter writing. For external facing services the address allocation comes from members/customers rather than this allocation. f From david at IPRG.nokia.com Fri Aug 31 18:39:21 2001 From: david at IPRG.nokia.com (David Kessens) Date: Fri, 31 Aug 2001 09:39:21 -0700 Subject: Interim Policy proposal for IPv6 Address Assignment Policy for Internet Exchange Points In-Reply-To: ; from Dave Pratt on Fri, Aug 31, 2001 at 03:30:39PM +0200 References: Message-ID: <20010831093921.B22569@iprg.nokia.com> For your information: On Fri, Aug 31, 2001 at 03:30:39PM +0200, Dave Pratt wrote: > > Allocations of /64 for the peering LAN can be obtained already from a separate > block (I forget the details - but I think from a US based ISP only block > managed by David Huberman). I fail to see therefore what this proposal helps > with. Dave is referring to allocations being made by Bill Manning out of a 6bone pTLA that he uses. For example: the Palo Alto Internet Exchange Point in the bay area in california uses addresses provided by Bill. David K. --- From randy at psg.com Fri Aug 31 19:19:19 2001 From: randy at psg.com (Randy Bush) Date: Fri, 31 Aug 2001 10:19:19 -0700 Subject: Interim Policy proposal for IPv6 Address Assignment Policy for Internet Exchange Points References: Message-ID: >> It should be noted that ISPs usually do not announce address space >> used on the IXP mesh itself to their peers. That means the address >> space assigned under this policy is likely not to be routable >> globally. > Care to explain how traceroute through these IX's is supposed to work, if > the node performing traceroute, ping, or whatever, is not a small-scale > customer (ie. default route) of the IX participants? works quite well, actually. each participating isp routes the mesh in their internal and customer networks, just does not hand it to peers. this is quite common in v4 exchanges. see my nanog presentation in feb '97. randy From david at IPRG.nokia.com Fri Aug 31 23:47:38 2001 From: david at IPRG.nokia.com (David Kessens) Date: Fri, 31 Aug 2001 14:47:38 -0700 Subject: Interim Policy discussion Message-ID: <20010831144738.C24150@iprg.nokia.com> This is a request to keep our discussion focused: - let's try to keep the discussion on lir-wg. - the proposed policy is an interim policy, that means further changes can be and will made to the policy after it has been approved. we don't have to discuss all those changes right now, *unless* you cannot live with the interim policy at all without such changes. - the policy is not intended to solve all problems to everybody. I hope this helps, David K. --- From jhma at KPNQwest.net Fri Aug 31 17:15:41 2001 From: jhma at KPNQwest.net (James Aldridge) Date: Fri, 31 Aug 2001 17:15:41 +0200 Subject: Interim Policy proposal for IPv6 Address Assignment Policy for Internet Exchange Points In-Reply-To: Your message of "Fri, 31 Aug 2001 16:17:19 +0300." Message-ID: Pekka Savola wrote: > On Fri, 31 Aug 2001, Gert Doering wrote: > > On Fri, Aug 31, 2001 at 03:58:04PM +0300, Pekka Savola wrote: > > > Care to explain how traceroute through these IX's is supposed to work, if > > > the node performing traceroute, ping, or whatever, is not a small-scale > > > customer (ie. default route) of the IX participants? > > > > For a traceroute *through* the IX you don't need the route to that /64. > > It might get filtered if you do RPF filtering (but multihomed customers > > usually don't, because it doesn't work), but reachability of the hosts > > *behind* the IX is not a problem. > > RPF is an additional issue, granted, but not the point here. > > Traceroute will skip a hop or two, ie. those p-t-p links where these > internal addresses are used; these might be crucial when debugging or > tracing where the traffic goes. > > This might make (depending on the topology) a 15 second wait for the magic > '* * *' combination. > > After and before these, it will continue in a normal fashion. But boy, > would this be annoying.. That depends on how your particular traceroute works. The common approach is to send packets (typically UDP to high-numbered ports) to the _destination_ address with increasing TTLs and look for the ICMP TTL Exceeded message to come back from each intermediate hop -- no traceroute packets are addressed _to_ the intermediate routers. So, unless you're explicitly filtering packets sourced from unrouted address space (e.g. RPF), you'll still get a useful(?) traceroute output. James