From peter.galbavy at knowtion.net Wed Jan 1 14:19:22 2003 From: peter.galbavy at knowtion.net (Peter Galbavy) Date: Wed, 1 Jan 2003 13:19:22 -0000 Subject: [lir-wg] Draft Agenda for RIPE 44 (version 0.3) References: <42625968.1041338486@cq> Message-ID: <000e01c2b198$672887d0$35bd10ac@walrus> Can I please request that an item be added for the discussion of memebers annual fees and specifically how RIPE / RIPE-NCC is going to approach the downturning number of memberships in a 'business like' rather than 'academic like' way ? (i.e. descrese in 'business' should result in lower costs, not higher). Peter Galbavy Knowtion Ltd uk.kml ----- Original Message ----- From: "Hans Petter Holen" To: Sent: Tuesday, December 31, 2002 11:41 AM Subject: [lir-wg] Draft Agenda for RIPE 44 (version 0.3) > Dear Working Group, > Please find enclosed a draft agenda for the upcoming working group. As a > matter of procedure I suggest that Policy items to be discussed are to be > discussed at the mailinglist. > > We should aslo be careful not to make policy desicions at the upcoming > meeting _unless_ there is a concrete proposal circulated to the list in > advance of the meeting, we should circulate any policy proposals to this > list after te meeting before making any policy desicions. > > Thanks to leo for preparing the very first draft, looking forward to input > from the rest of you. > > Best Regards, > Hans Petter Holen > lir-wg chair > > --- > Draft Agenda for RIPE 44 (version 0.2) > Wednesday 29 January 2003 > 09:00 - 12:30 > > Chair: Hans Petter Holen > Co-chair: Denesh Bhabuta > > A. Admin: Scribe > Participant List, Charter, Mailing lists > B. Agenda bashing > C. RIPE 43 minutes and actions > > http://www.ripe.net/ripe/wg/lir/r43-minutes.html > http://www.ripe.net/ripe/wg/lir/lir-actions.html > > D. Report from the RIPE NCC Registration Services > Presentation by leo vegoda > E. Report from the Address Council - Presentation > F. Election of new LIR-WG Chairs > G. LIR Portal > > H. Policy issues > -- Mailing list AUP ? > -- EGLOP Multicast policy discussion ? > -- IPv6 policy - experiences ? > -- IP addressing for always on (residential broadband) revisited ? > > X. Any other business > Y. Summary of actions arising from this meeting > Z. Open microphone > > > From baptista at dot-god.com Wed Jan 1 19:53:24 2003 From: baptista at dot-god.com (Joe Baptista) Date: Wed, 1 Jan 2003 13:53:24 -0500 (EST) Subject: [lir-wg] ripe allocation 82.0.0.0/8 and arin allocation 69.0.0.0/8 Message-ID: ARIN recently released blocks from the 69.0.0.0/8 which are causing numerous problems with routing in this block. Some 200 blocks have been issued from 69.0.0.0/8 and i've spoken with at least 15 operators who have complained. I understand the 82.0.0.0/8 block suffers from the same problem. From what I can see RIPE has not yet issued any netblocks from this pool. If RIPE does issues blocks from this pool will RIPE take back the IP if it enconters the same problems or will RIPE follow the ARIN approach of no returns even though ARIN and RIPE are aware of the frustration it is causing. Some operators I have spoken with in 69/8 have suffered damage to thier business operations. Cheers Joe Baptista -- Planet Communications & Computing Facility a division of The dot.GOD Registry, Limited From baptista at dot-god.com Thu Jan 2 09:48:32 2003 From: baptista at dot-god.com (Joe Baptista) Date: Thu, 2 Jan 2003 03:48:32 -0500 (EST) Subject: [lir-wg] ripe allocation 82.0.0.0/8 and arin allocation 69.0.0.0/8 In-Reply-To: <20030102083223.GA3715@finch-staff-1.thus.net> Message-ID: On Thu, 2 Jan 2003, Clive D.W. Feather wrote: > Joe Baptista said: > > ARIN recently released blocks from the 69.0.0.0/8 which are causing > > numerous problems with routing in this block. Some 200 blocks have been > > issued from 69.0.0.0/8 and i've spoken with at least 15 operators who have > > complained. > > > > I understand the 82.0.0.0/8 block suffers from the same problem. > > Pardon me if this seems a dumb question, but what is the problem with these > two blocks that doesn't apply to others? they don't route. problem is related to legacy equipment/bogon lists which have not been updated - in most cases corporations setup their router years ago and no one knows how to update them. this is also a major problem. If you goto nanog and search the archives for 69.0.0.0 you'll get more info there. And so far based on my research every operator of an allocation from a 69/8 who has tried to use it has experienced routing problems. I expect the same will apply to any 82/8 allocations. regards joe baptista From clive at demon.net Thu Jan 2 09:32:23 2003 From: clive at demon.net (Clive D.W. Feather) Date: Thu, 2 Jan 2003 08:32:23 +0000 Subject: [lir-wg] ripe allocation 82.0.0.0/8 and arin allocation 69.0.0.0/8 In-Reply-To: References: Message-ID: <20030102083223.GA3715@finch-staff-1.thus.net> Joe Baptista said: > ARIN recently released blocks from the 69.0.0.0/8 which are causing > numerous problems with routing in this block. Some 200 blocks have been > issued from 69.0.0.0/8 and i've spoken with at least 15 operators who have > complained. > > I understand the 82.0.0.0/8 block suffers from the same problem. Pardon me if this seems a dumb question, but what is the problem with these two blocks that doesn't apply to others? -- Clive D.W. Feather | Work: | Tel: +44 20 8371 1138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | From leo at ripe.net Thu Jan 2 10:13:17 2003 From: leo at ripe.net (leo vegoda) Date: Thu, 2 Jan 2003 10:13:17 +0100 Subject: [lir-wg] ripe allocation 82.0.0.0/8 and arin allocation 69.0.0.0/8 In-Reply-To: References: Message-ID: Good morning, In article , Joe Baptista writes [...] >I understand the 82.0.0.0/8 block suffers from the same problem. From >what I can see RIPE has not yet issued any netblocks from this pool. If >RIPE does issues blocks from this pool will RIPE take back the IP if it >enconters the same problems or will RIPE follow the ARIN approach of no >returns even though ARIN and RIPE are aware of the frustration it is >causing. The RIPE NCC has not yet made any allocations from 82.0.0.0/8. All address space from which the RIPE NCC makes allocations is documented in the "Smallest RIPE NCC Allocation / Assignment Sizes" document. The latest version of this document is always available from the following web page: The RIPE NCC also makes an announcements to various mailing lists when a new block is received from the IANA. The announcement of 82.0.0.0/8 was made on 27 November 2002 and can be viewed in our mail archives at: The RIPE NCC can not guarantee whether any particular route will be accepted by any network operator. Best regards, -- leo vegoda RIPE NCC Registration Services From baptista at dot-god.com Thu Jan 2 13:18:28 2003 From: baptista at dot-god.com (Joe Baptista) Date: Thu, 2 Jan 2003 07:18:28 -0500 (EST) Subject: [lir-wg] ripe allocation 82.0.0.0/8 and arin allocation 69.0.0.0/8 In-Reply-To: Message-ID: On Thu, 2 Jan 2003, leo vegoda wrote: > The RIPE NCC can not guarantee whether any particular route will > be accepted by any network operator. Thats a problem. Question - if one of your customers discovers that an allocation does not route can they have it replaced with one that does. I understand you don't guarantee any particular allocation will route. And in the old days when the charges were minimal for IP allocation - well one could reluctantly accept that. However - under the new policies you boys are charging these people hefty bucks and that means liability and I don't think it prudent to hide behind the routing claim. I have documented over 15 cases in which the 69.0.0.0/8 fiasco has cost these people clients and business that went elsewhere. Have also documented situations in which these recent allocation have resulted in the renumbering of networks out of 69.0.0.0/8 allocations into arpa that works. So you see I think it prudent that there be a policy to allow for returns and replacement of arpa. I don't think you boys should be issuing numbers when you are aware that they don't work and are causing people financial problems to their business operations. So if you do get complaints regarding 82.0.0.0/8 - do you intend to make sure your customers get network that work - or will RIPE be following the ARIN lead and just let these people hang. regards joe baptista From gert at space.net Thu Jan 2 13:25:48 2003 From: gert at space.net (Gert Doering) Date: Thu, 2 Jan 2003 13:25:48 +0100 Subject: [lir-wg] ripe allocation 82.0.0.0/8 and arin allocation 69.0.0.0/8 In-Reply-To: ; from baptista@dot-god.com on Thu, Jan 02, 2003 at 07:18:28AM -0500 References: Message-ID: <20030102132548.Z15927@Space.Net> Hi, On Thu, Jan 02, 2003 at 07:18:28AM -0500, Joe Baptista wrote: > On Thu, 2 Jan 2003, leo vegoda wrote: > > > The RIPE NCC can not guarantee whether any particular route will > > be accepted by any network operator. > > Thats a problem. Question - if one of your customers discovers that an > allocation does not route can they have it replaced with one that does. Not speaking for the RIPE NCC, of course, but knowing the procedures fairly well. The answer is "no", of course. There was a trial phase when blocks from 62.0.0.0/8 was initially handed out (because it wasn't understood what bad effects using a "former A" might have), but that does not apply to any other /8. It is *not* RIPE's responsibility to guarantee routeability of anything. If people mess up their filters, *they* have to fix it. Talk to them, talk to their upstreams, distribute clue. [..] > I understand you don't guarantee any particular allocation will route. > And in the old days when the charges were minimal for IP allocation - well > one could reluctantly accept that. However - under the new policies you > boys are charging these people hefty bucks and that means liability and I > don't think it prudent to hide behind the routing claim. I have > documented over 15 cases in which the 69.0.0.0/8 fiasco has cost these > people clients and business that went elsewhere. I have no idea what you are talking about. RIPE does NOT charge per-allocation. If you have a problem with ARIN, go and complain to them. [..] > So if you do get complaints regarding 82.0.0.0/8 - do you intend to make > sure your customers get network that work - or will RIPE be following the > ARIN lead and just let these people hang. It's RIPE's job to manage the number space, and the number space is limited (!). Before long, *there is no other space* than "former A" to allocate from - and if that space is filtered at some point in the network, it's the responsibility of the person filtering, not the people trying to manage a limited resource in the best possible way. (Not that I am always in 100% agreement with what the RIPE or ARIN people do, but *this* is not something they have influence upon). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 54707 (54686) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From jeroen at unfix.org Thu Jan 2 13:32:44 2003 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 2 Jan 2003 13:32:44 +0100 Subject: [lir-wg] ripe allocation 82.0.0.0/8 and arin allocation 69.0.0.0/8 In-Reply-To: Message-ID: <000901c2b25b$0eddf330$210d640a@unfix.org> Joe Baptista wrote: > On Thu, 2 Jan 2003, leo vegoda wrote: > > > The RIPE NCC can not guarantee whether any particular route will > > be accepted by any network operator. > I understand you don't guarantee any particular allocation will route. Every network operator, enduser etc can choose to accept routes based upon locally defined policies. If they choose not to accept a certain route that is their personal opininion. Eg. Some complete countries will filter anything related to eg CNN or any other American "propaganda" (as that is what they will call it). Now you go tell them as being CNN that they _should_ accept your route and that they should be accepting your 'propaganda'. These are political problems and if you have have problems with those the clients of those ISP's that don't accept the route for those certain netblocks should complain to their uplink. This is all about freedom of choice and it's good we have it. Greets, Jeroen From oppermann at pipeline.ch Thu Jan 2 13:32:54 2003 From: oppermann at pipeline.ch (Andre Oppermann) Date: Thu, 02 Jan 2003 13:32:54 +0100 Subject: [lir-wg] ripe allocation 82.0.0.0/8 and arin allocation 69.0.0.0/8 References: Message-ID: <3E143176.FBDE519C@pipeline.ch> Joe, I fail to see your point. You are crying wolf when in fact there none to be seen at the moment. We went through this a couple of years ago with the 62/8 range and after a couple of month all the bugs were worked out. 80/8 is assigned by RIPE for quite some time now and seems to be working fine. There are always over-zealous networks admins who think it's safe to block everything that wasn't routed five years ago. Unfortunatly they can't remember to update the filters, left the company or got fired. Shit happens. One day one of their users will complain he can't reach this or that site. Eventually one of the expensive consultants will find that stupid filter and remove it. Nothing RIPE can do much about. There is no way RIPE can change that except documenting and educating the people who care to even read the RIPE website. -- Andre Joe Baptista wrote: > > On Thu, 2 Jan 2003, leo vegoda wrote: > > > The RIPE NCC can not guarantee whether any particular route will > > be accepted by any network operator. > > Thats a problem. Question - if one of your customers discovers that an > allocation does not route can they have it replaced with one that does. > > I understand you don't guarantee any particular allocation will route. > And in the old days when the charges were minimal for IP allocation - well > one could reluctantly accept that. However - under the new policies you > boys are charging these people hefty bucks and that means liability and I > don't think it prudent to hide behind the routing claim. I have > documented over 15 cases in which the 69.0.0.0/8 fiasco has cost these > people clients and business that went elsewhere. > > Have also documented situations in which these recent allocation have > resulted in the renumbering of networks out of 69.0.0.0/8 allocations into > arpa that works. > > So you see I think it prudent that there be a policy to allow for returns > and replacement of arpa. I don't think you boys should be issuing numbers > when you are aware that they don't work and are causing people financial > problems to their business operations. > > So if you do get complaints regarding 82.0.0.0/8 - do you intend to make > sure your customers get network that work - or will RIPE be following the > ARIN lead and just let these people hang. > > regards > joe baptista From John.Sweeting at teleglobe.com Thu Jan 2 15:06:11 2003 From: John.Sweeting at teleglobe.com (Sweeting, John) Date: Thu, 2 Jan 2003 09:06:11 -0500 Subject: [lir-wg] ripe allocation 82.0.0.0/8 and arin allocation 69.0. 0.0/8 Message-ID: <170E5E7779BCD3118C2A0008C7F40C1906E9BC8D@usresms03.teleglobe.com> None of the RIR's are going to tell me what routes I will accept or filter in my network.....as simple as that. If I am filtering out networks that my customers wish to get to then that will be fixed as soon as a ticet is opened by them. Also, what is with the "...you boys..." remarks. -----Original Message----- From: Joe Baptista To: leo vegoda Cc: lir-wg at ripe.net Sent: 1/2/03 7:18 AM Subject: Re: [lir-wg] ripe allocation 82.0.0.0/8 and arin allocation 69.0.0.0/8 On Thu, 2 Jan 2003, leo vegoda wrote: > The RIPE NCC can not guarantee whether any particular route will > be accepted by any network operator. Thats a problem. Question - if one of your customers discovers that an allocation does not route can they have it replaced with one that does. I understand you don't guarantee any particular allocation will route. And in the old days when the charges were minimal for IP allocation - well one could reluctantly accept that. However - under the new policies you boys are charging these people hefty bucks and that means liability and I don't think it prudent to hide behind the routing claim. I have documented over 15 cases in which the 69.0.0.0/8 fiasco has cost these people clients and business that went elsewhere. Have also documented situations in which these recent allocation have resulted in the renumbering of networks out of 69.0.0.0/8 allocations into arpa that works. So you see I think it prudent that there be a policy to allow for returns and replacement of arpa. I don't think you boys should be issuing numbers when you are aware that they don't work and are causing people financial problems to their business operations. So if you do get complaints regarding 82.0.0.0/8 - do you intend to make sure your customers get network that work - or will RIPE be following the ARIN lead and just let these people hang. regards joe baptista From m.hallgren at free.fr Thu Jan 2 15:25:35 2003 From: m.hallgren at free.fr (Michael Hallgren) Date: Thu, 2 Jan 2003 15:25:35 +0100 Subject: [lir-wg] ripe allocation 82.0.0.0/8 and arin allocation 69.0.0.0/8 In-Reply-To: Message-ID: > > On Thu, 2 Jan 2003, leo vegoda wrote: > > > The RIPE NCC can not guarantee whether any particular route will > > be accepted by any network operator. Which seems fairly reasonable to me. > > Thats a problem. Question - if one of your customers discovers that an > allocation does not route can they have it replaced with one that does. > Better fix the real problem than escape it? I'd guess main cause of problem being lack of understanding, so propagate know-how to concerned parties rather than provide quick fix. > I understand you don't guarantee any particular allocation will route. > And in the old days when the charges were minimal for IP allocation - well > one could reluctantly accept that. However - under the new policies you > boys are charging these people hefty bucks and that means liability and I > don't think it prudent to hide behind the routing claim. I have > documented over 15 cases in which the 69.0.0.0/8 fiasco has cost these > people clients and business that went elsewhere. Hrm,... charging for what?? mh From chris at easynet.net Fri Jan 3 00:53:12 2003 From: chris at easynet.net (Chris Luke) Date: Thu, 2 Jan 2003 23:53:12 +0000 Subject: [lir-wg] ripe allocation 82.0.0.0/8 and arin allocation 69.0.0.0/8 In-Reply-To: References: Message-ID: <20030102235312.GA12399@easynet.net> Michael Hallgren wrote (on Jan 02): > Better fix the real problem than escape it? I'd guess main cause of problem > being lack of understanding, so propagate know-how to concerned parties > rather than provide quick fix. Or, if some company has an internal policy that unfairly causes you to lose business and is not being cooperative on the technical level, get your legal persons to send them a nice letter about anti- competitive behaviour and work from there. Sometimes, getting your MD to call their MD, fly to their HQ for a tour+coffee or any of a number of other non-technical approach may also work. Once technical means fail, it's no longer a problam technical means can solve. Rewriting the rules of how the IRR's work is not a scalable solution. Clue distribution is always preferrable, but ultimately this is a business world and sometimes you have to revert to the age-tested tools society has developed for resolving disputes. Chris. -- == chris at easynet.net T: +44 845 333 0122 == Global IP Network Engineering Mgr, Easynet Group PLC F: +44 845 333 0122 From axel.pawlik at ripe.net Tue Jan 7 15:15:08 2003 From: axel.pawlik at ripe.net (Axel Pawlik) Date: Tue, 07 Jan 2003 15:15:08 +0100 Subject: [lir-wg] Recent Board Meeting Message-ID: <5.2.0.9.2.20030107125036.01ec61e0@localhost> Dear all, I want to take this opportunity to wish you a very Happy and Successful New Year! ... and to quickly inform you that the Executive Board of the RIPE NCC met on 16 December 2002. During the meeting a number of issues that were brought up on this mailing list some weeks ago were discussed. A major focal point was on easing members' participation in the annual General Meeting of the association. Various possibilities ranging from electronic voting to moving the date of the meeting were considered. Another topic was the presentation of budget lines in documents like the Annual Report and Activity Plan, as well as possible improvements to the current Charging Scheme. No final decisions have been taken yet, as a substantial amount of further discussions and preparations are expected. I will present more details, and give an outlook onto the RIPE NCC actions in the coming year, during the plenary at the upcoming RIPE Meeting. kind regards, hope to see you in Amsterdam, Axel From ripe-lists at stop.me.uk Tue Jan 7 17:39:55 2003 From: ripe-lists at stop.me.uk (Denesh Bhabuta) Date: Tue, 7 Jan 2003 16:39:55 +0000 Subject: [lir-wg] Name of the LIR WG Message-ID: <20030107163955.GA25064@cyberstrider.net> Hi I am sure we all agree that this Working Group is an "open forum where RIPE policy is made". However this is not immediately obvious from the name Local Internet Registry Working Group (LIR WG). There seem to be a couple of apparent problems... 1) The Purpose of the working group is not clear - mainly to newcomers, but also to others. 2) non-LIRs most likely have the impression that the Working Group is not open to them even though it is open to anyone with rational argument. Thus a proposal is to change the name of this working group to "Policy WG" or similar.. if only to remove any implications of the WG being a closed shop. This would also make it clear as to what the WG deals with. So - any comments? Please start a discussion on this in time for the upcoming meeting in Amsterdam where we hope there will be a consensus on this matter. Regards Denesh From roland at linx.net Wed Jan 8 08:44:22 2003 From: roland at linx.net (Roland Perry) Date: Wed, 8 Jan 2003 07:44:22 +0000 Subject: [lir-wg] Name of the LIR WG In-Reply-To: <20030107163955.GA25064@cyberstrider.net> References: <20030107163955.GA25064@cyberstrider.net> Message-ID: In message <20030107163955.GA25064 at cyberstrider.net>, Denesh Bhabuta writes >Thus a proposal is to change the name of this working group to "Policy >WG" or similar.. if only to remove any implications of the WG being a >closed shop. This would also make it clear as to what the WG deals with. Something which at least implied "LIR and potential/applicant LIR" would dispel some of the confusion I encounter out there on the streets. (Not that I'm suggesting the list is used as a helpline...) -- Roland Perry | tel: +44 20 7645 3505 | roland at linx.org Director of Public Policy | fax: +44 20 7645 3529 | http://www.linx.net London Internet Exchange | mbl: +44 7909 68 0005 | /contact/roland From axel.pawlik at ripe.net Wed Jan 8 09:20:27 2003 From: axel.pawlik at ripe.net (Axel Pawlik) Date: Wed, 08 Jan 2003 09:20:27 +0100 Subject: [lir-wg] Name of the LIR WG In-Reply-To: <20030107163955.GA25064@cyberstrider.net> Message-ID: <5.2.0.9.2.20030108091908.01ce10e0@localhost> >I am sure we all agree that this Working Group is an "open forum where >RIPE policy is made". My impression is also that a "policy" in the name would add transparency. Axel From kurtis at kurtis.pp.se Wed Jan 8 13:27:47 2003 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Wed, 8 Jan 2003 13:27:47 +0100 Subject: Fwd: [lir-wg] Re: [lir-wg]Election of chairs to the lir-wg - call for nominations Message-ID: <9848FEC6-2304-11D7-A551-000393AB1404@kurtis.pp.se> Ok, on the request of Hans Petter I resubmit this. Note that I have no idea if Gert is willing or not I just went for someone I think have shown good understanding and reason :) Best regards, - kurtis - Begin forwarded message: > From: Hans Petter Holen > Date: tor jan 2, 2003 21:38:34 Europe/Stockholm > To: Kurt Erik Lindqvist > Subject: Re: [lir-wg] Re: [lir-wg]Election of chairs to the lir-wg - > call for nominations > > Thanks Kurtis, > Were supposed to be open and transparent :-) so could I ask you to > resent the message to the list ? > > -hph > > --On 2. januar 2003 12:21 +0100 Kurt Erik Lindqvist > wrote: > >>> I would think it should be fairly important to the wg to figure out: >>> >>> 1) Who should chair this wg in the future ? >> >> I am not sure if this is supposed to be open or closed so I mail this >> to >> only you. I would nominate yourself. >> >>> 2) Are the current chairs accepting renomination ? (yes I am if you >>> still want me :-) >> >> See above :) >> >>> 3) Does the wg want to have 1 chair and 2 co chairs ? >>> >> >> I suggest two co-chairs. Without discussing this with anyone, I would >> suggest Gert Doering as one, but I would also liek us to find someone >> from the enterprise side as the other. >> >> - kurtis - > > > From webmaster at ripe.net Wed Jan 8 16:22:28 2003 From: webmaster at ripe.net (RIPE NCC Document Announcement Service) Date: Wed, 08 Jan 2003 16:22:28 +0100 Subject: [lir-wg] New Draft Document Message-ID: <200301081522.h08FMSvP022062@birch.ripe.net> New RIPE Draft Document Announcement -------------------------------------- A new draft document is available from the RIPE document store. Draft: IPv4 Sub-allocations Made by Local Internet Registries Operating within the RIPE NCC Service Region Short content description ------------------------- This document specifies the RIPE community policies on allocations made by Local Internet Registries (LIRs) within the unicast IPv4 address space. The draft document is available at: http://www.ripe.net/ripe/draft-documents/sub-allocations.html The deadline for comments on this draft document will be accepted up to and including 29 January 2003. After incorporating any suggested changes to the document, the final document will be published as a RIPE Document. All comments and suggestions should be sent to . Kind Regards, Jeroen Bet RIPE NCC Webmaster From daniel.karrenberg at ripe.net Wed Jan 8 17:40:56 2003 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 8 Jan 2003 17:40:56 +0100 Subject: [lir-wg] Name of the LIR WG In-Reply-To: <5.2.0.9.2.20030108091908.01ce10e0@localhost> References: <20030107163955.GA25064@cyberstrider.net> <5.2.0.9.2.20030108091908.01ce10e0@localhost> Message-ID: <20030108164056.GB4276@reifchen-wave.karrenberg.net> "Registration Policies and Procedures WG" repop-wg ? From gert at space.net Wed Jan 8 17:46:57 2003 From: gert at space.net (Gert Doering) Date: Wed, 8 Jan 2003 17:46:57 +0100 Subject: [lir-wg] Name of the LIR WG In-Reply-To: <20030108164056.GB4276@reifchen-wave.karrenberg.net>; from daniel.karrenberg@ripe.net on Wed, Jan 08, 2003 at 05:40:56PM +0100 References: <20030107163955.GA25064@cyberstrider.net> <5.2.0.9.2.20030108091908.01ce10e0@localhost> <20030108164056.GB4276@reifchen-wave.karrenberg.net> Message-ID: <20030108174657.Y15927@Space.Net> Hi, On Wed, Jan 08, 2003 at 05:40:56PM +0100, Daniel Karrenberg wrote: > "Registration Policies and Procedures WG" repop-wg ? I'm not sure whether people will understand "repop-wg" better than "lir-wg" :-) What about "policy-wg"? Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55180 (54707) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From peter.galbavy at knowtion.net Wed Jan 8 17:49:35 2003 From: peter.galbavy at knowtion.net (Peter Galbavy) Date: Wed, 8 Jan 2003 16:49:35 -0000 Subject: [lir-wg] Name of the LIR WG References: <20030107163955.GA25064@cyberstrider.net> <5.2.0.9.2.20030108091908.01ce10e0@localhost> <20030108164056.GB4276@reifchen-wave.karrenberg.net> <20030108174657.Y15927@Space.Net> Message-ID: <004501c2b735$ed7172a0$4528a8c0@cblan.mblox.com> > I'm not sure whether people will understand "repop-wg" better than > "lir-wg" :-) > > What about "policy-wg"? There appears to be a focus of 'RIPE is the members' so why not 'ripe-wg' ? Peter From daniel.karrenberg at ripe.net Wed Jan 8 17:53:40 2003 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 8 Jan 2003 17:53:40 +0100 Subject: [lir-wg] Name of the LIR WG In-Reply-To: <20030108174657.Y15927@Space.Net> References: <20030107163955.GA25064@cyberstrider.net> <5.2.0.9.2.20030108091908.01ce10e0@localhost> <20030108164056.GB4276@reifchen-wave.karrenberg.net> <20030108174657.Y15927@Space.Net> Message-ID: <20030108165340.GD4276@reifchen-wave.karrenberg.net> On 08.01 17:46, Gert Doering wrote: > I'm not sure whether people will understand "repop-wg" better than > "lir-wg" :-) > > What about "policy-wg"? "RIPE Policy WG" suggests much too broad a charter, policies can be about anything. Also the WG charter is about procedures as much as it is about policy. Daniel From paul.mylotte at bt.com Wed Jan 8 18:10:43 2003 From: paul.mylotte at bt.com (paul.mylotte at bt.com) Date: Wed, 8 Jan 2003 17:10:43 -0000 Subject: [lir-wg] Name of the LIR WG Message-ID: <7497DCA1C240C042B28F6657ADFD8E09E77BE2@i2km11-ukbr.domain1.systemhost.net> I tend to favour the official title of "IP Addressing Policy" WG, which can then be abbreviated to the informal "Policy" WG if necessary Paul -----Original Message----- From: Peter Galbavy [mailto:peter.galbavy at knowtion.net] Sent: 08 January 2003 16:50 To: Gert Doering; Axel Pawlik; Denesh Bhabuta; lir-wg at ripe.net Subject: Re: [lir-wg] Name of the LIR WG > I'm not sure whether people will understand "repop-wg" better than > "lir-wg" :-) > > What about "policy-wg"? There appears to be a focus of 'RIPE is the members' so why not 'ripe-wg' ? Peter From hpholen at tiscali.no Wed Jan 8 18:18:45 2003 From: hpholen at tiscali.no (Hans Petter Holen) Date: Wed, 08 Jan 2003 18:18:45 +0100 Subject: [lir-wg] Name of the LIR WG Message-ID: <176393700.1042049925@[10.47.11.5]> --On 8. januar 2003 17:40 +0100 Daniel Karrenberg wrote: | | "Registration Policies and Procedures WG" repop-wg ? To add the global perspective: ARIN: IP Allocations Policies Working Group policy at arin.net APNIC: Address Policy SIG LACNIC: Politicas -- Lista de discucion de politicas del LACNIC The main works have been named: ripe-246 IPv6 Address Allocation and Assignment Policy ripe-245 Autonomous System (AS) Number Assignment Policies and Procedures ripe-244 Policy for Reverse Address Delegation under in-addr.arpa in the RIPE NCC Service Region ripe-234 IPv4 Address Allocation and Assignment Policies in the RIPE NCC Service Region ripe-127 Provider Independent vs Provider Aggregatable Address Space So so far we have not used the term Registration Policy. I also feel that the game is about how have an address assigned, not how to register the address of my preference. Maybe IP address Policies and Procedures WG: iapp-wg or simply address Policies and Procedures: app-wg But I somehow feel this is just making more cryptic abreviations not adding transparencey to the name. -hph From oliver at bartels.de Wed Jan 8 18:38:26 2003 From: oliver at bartels.de (Oliver Bartels) Date: Wed, 08 Jan 2003 18:38:26 +0100 Subject: [lir-wg] Name of the LIR WG In-Reply-To: <20030107163955.GA25064@cyberstrider.net> Message-ID: <200301081738.h08HcPs18819@alpha.bartels.de> On Tue, 7 Jan 2003 16:39:55 +0000, Denesh Bhabuta wrote: >So - any comments? Please start a discussion on this in time for the >upcoming meeting in Amsterdam where we hope there will be a consensus on >this matter. What about "LIR-policy-WG", which partially continues the old name (as we are really talking about LIR's and RIPE's policy to them and how they propagate it as their policy) and adds the "policy" to open the shop? Best Regards Oliver Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver at bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0 From woeber at cc.univie.ac.at Wed Jan 8 20:10:37 2003 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 08 Jan 2003 20:10:37 +0100 Subject: [lir-wg] Name of the LIR WG Message-ID: <00A19ADA.7909D40A.1@cc.univie.ac.at> Hi Daniel, Gert et.al.! IF we really consider changing things, after a _very_ careful review (I hope), I'd have a strong pref to do it in coordination with the other RIRs' constituencies. >Hi, > >On Wed, Jan 08, 2003 at 05:40:56PM +0100, Daniel Karrenberg wrote: >> "Registration Policies and Procedures WG" repop-wg ? > >I'm not sure whether people will understand "repop-wg" better than >"lir-wg" :-) > >What about "policy-wg"? "policy" -- policy? what (Internet Content ;-) ?? The best thing I can think of at the moment is sort of copying from the APNIC region, ie. [IP] Address Policy SIG. Which (from an ICANN/ASO point of view) still misses the routing identifier issue, somewhat, and/or potentially starts to pull the Routing-WG into the boat as well. And we should be very careful to not _add_ to the confusion in this process, with - policy being the "open-ness" thingy where everyone is welcome and a consensus and/or resource accessibility and distribution decision should be worked out, and - defining the procedures, which should ultimately remain the responsibilty of the NCC and the LIRs in th end, although everyone should still be welcome to observe and contribute as much as possible. We should think pretty careful about - "policy development" for IPv[46] Addresses and Routing Identifiers, - "LIR <-> RIR procedure definitions" and, in the end, - "funding agreement". >Gert Doering > -- NetMaster Food for thought, Wilfried. From hpholen at tiscali.no Wed Jan 8 22:01:40 2003 From: hpholen at tiscali.no (Hans Petter Holen) Date: Wed, 08 Jan 2003 22:01:40 +0100 Subject: [lir-wg] Name of the LIR WG In-Reply-To: <176393700.1042049925@[10.47.11.5]> References: <176393700.1042049925@[10.47.11.5]> Message-ID: <81217593.1042063300@cq> --On 8. januar 2003 18:18 +0100 Hans Petter Holen wrote: > ARIN: IP Allocations Policies Working Group policy at arin.net Even tough I made particular care to only cut and paste from the RIR web sites I didn't get this 100% right: So it has been pointed out to me that: ARIN does not have an active wg designated for addressing policies. The ARIN meeting is not broken up into individual wg sessions. All policy issues are discussed on the ppml (public policy mail list) ppml at arin.net. Sorry for the inaccurate information. -hph From k13 at nikhef.nl Thu Jan 9 10:49:05 2003 From: k13 at nikhef.nl (Rob Blokzijl) Date: Thu, 9 Jan 2003 10:49:05 +0100 (MET) Subject: [lir-wg] Name of the LIR WG In-Reply-To: <004501c2b735$ed7172a0$4528a8c0@cblan.mblox.com> Message-ID: On Wed, 8 Jan 2003, Peter Galbavy wrote: > > I'm not sure whether people will understand "repop-wg" better than > > "lir-wg" :-) > > > > What about "policy-wg"? > > There appears to be a focus of 'RIPE is the members' so why not 'ripe-wg' ? RIPE is more than just the RIPE NCC members, so 'ripe-wg' would be a wrong name. > > Peter > > Rob From matthew at crescent.org.uk Thu Jan 9 13:06:35 2003 From: matthew at crescent.org.uk (Matthew Robinson) Date: Thu, 09 Jan 2003 12:06:35 +0000 Subject: [lir-wg] Name of the LIR WG In-Reply-To: Your message of "Thu, 09 Jan 2003 10:49:05 +0100." Message-ID: Hi all, I'm not convinced that changing the wg name will achieve the desired effect. Perhaps the effort should be put more into education of new (and current) LIR's as to what they can talk about on the lists? I do feel that the lists are greatly under utilised, maybe a monthly "did you know about the ripe mailing lists" could be sent to LIR's by the RIPE? Kind regards Matthew From ripe-lists at stop.me.uk Thu Jan 9 13:37:40 2003 From: ripe-lists at stop.me.uk (Denesh Bhabuta) Date: Thu, 9 Jan 2003 12:37:40 +0000 Subject: [lir-wg] Name of the LIR WG In-Reply-To: References: Message-ID: <20030109123740.GC9709@cyberstrider.net> On Thu, Jan 09, 2003 at 12:06:35PM +0000, Matthew Robinson wrote: > I'm not convinced that changing the wg name will achieve the desired effect. > Perhaps the effort should be put more into education of new (and current) > LIR's as to what they can talk about on the lists? what about the non-LIRs though? Regards Denesh From matthew at crescent.org.uk Thu Jan 9 13:58:23 2003 From: matthew at crescent.org.uk (Matthew Robinson) Date: Thu, 09 Jan 2003 12:58:23 +0000 Subject: [lir-wg] Name of the LIR WG In-Reply-To: Your message of "Thu, 09 Jan 2003 12:37:40 GMT." <20030109123740.GC9709@cyberstrider.net> Message-ID: I think I'm a little concerned that we're in danger of falling into the 'Consignia' trap. For those who aren't in the UK, the Post Office here decided that the way forward was to change it's name to Consignia, which it did at huge expense only to realise that it made no difference to what the public thought of it and it's services. I believe it has since changed it's name back. My point I think is that we can change to name to something fantastic but if people don't know what they can discuss then we'll never get new people to join. Maybe we need a 'Mailing Lists' link on the RIPE website. Currently you have to dig under Working Groups, which I think puts a lot of people off joining. Promoting the working groups as being open and 'hey, come join us' is, in my view, a better use of effort than name changing. All the best Matthew > On Thu, Jan 09, 2003 at 12:06:35PM +0000, Matthew Robinson wrote: > > I'm not convinced that changing the wg name will achieve the desired effect. > > Perhaps the effort should be put more into education of new (and current) > > LIR's as to what they can talk about on the lists? > > what about the non-LIRs though? > > Regards > Denesh > From hpholen at tiscali.no Thu Jan 9 22:12:37 2003 From: hpholen at tiscali.no (Hans Petter Holen) Date: Thu, 09 Jan 2003 22:12:37 +0100 Subject: [lir-wg] Name of the LIR WG In-Reply-To: References: Message-ID: <11776583.1042150357@213.234.102.185.adsl.oeke.tiscali.no> --On 9. januar 2003 12:58 +0000 Matthew Robinson wrote: | I think I'm a little concerned that we're in danger of falling into the | 'Consignia' trap. For those who aren't in the UK, the Post Office here | decided that the way forward was to change it's name to Consignia, which | it did at huge expense only to realise that it made no difference to | what the public thought of it and it's services. I believe it has since | changed it's name back. | | My point I think is that we can change to name to something fantastic but | if people don't know what they can discuss then we'll never get new | people to join. While I have quite some sympathy for this particular point of view, I would like to point out that the cost of changing the name of the wg is not that high. I have experienced quite some confusion over the years since the split between local-ir at ripe.net (now closed list for local-ir's) lir-wg at ripe.net (now open list for matters of concern to local-ir's) now over the last couple of years the wg charter is less "matters of concern" to local-ir's and more "open forum for making policy" whats the harm in reflecting that in the name ? | Maybe we need a 'Mailing Lists' link on the RIPE website. Currently you | have to dig under Working Groups, which I think puts a lot of people off | joining. Promoting the working groups as being open and 'hey, come join | us' is, in my view, a better use of effort than name changing. Why not both ? -hph From hpholen at tiscali.no Thu Jan 9 22:32:28 2003 From: hpholen at tiscali.no (Hans Petter Holen) Date: Thu, 09 Jan 2003 22:32:28 +0100 Subject: [lir-wg] Short Address Council update Message-ID: <12966615.1042151548@213.234.102.185.adsl.oeke.tiscali.no> Dear wg, Just to give you a short update after the Address Council phone meeting last night. As last years AC chair Barbara Rosseman have now left the address council and started working for ICANN our communication channels towards ICANN should be even better than ever. (With both John Crain and Barbara among ICANN staff). Accoding to our internal procedures we had an election for AC chair and after due discussion and election Mark McFadden was elected as AC Chair and Hartmut Glaser and myself co-chairs. As a consequence of the ICANN reform the AC is supposed to appoint a representative on the ICANN nomination committee. The role of the nomcom is to elect some of the future ICANN board members. (The AC still has a task to elect some). Our long term goal is to establish an open and transparent process for this election, just as the ICANN board member elections of the past, but with the given time frames (the nomcom will start its initial work close to february 1st) the AC will elect a representative to the nomcom. Since I am on the AC to serve the RIPE NCC community and the best interest of the internet community, please feel free to give me or other AC-coord representatives input with respect to particular nominations as soon as possible. -hph From hpholen at tiscali.no Fri Jan 10 07:27:01 2003 From: hpholen at tiscali.no (Hans Petter Holen) Date: Fri, 10 Jan 2003 07:27:01 +0100 Subject: [lir-wg] [aso-council] ICANN Quarterly Report to U.S. Department of Commerce (fwd) Message-ID: <45034576.1042183621@213.234.102.185.adsl.oeke.tiscali.no> ------------ Forwarded Message ------------ Date: 9. januar 2003 18:26 -0800 From: "M. Stuart Lynn" To: ASO Council Cc: vint cerf Subject: [aso-council] ICANN Quarterly Report to U.S. Department of Commerce The amendment signed last September to the Memorandum of Understanding with the U.S. Department of Commerce requires ICANN to submit a quarterly progress report detailing our accomplishments towards fulfilling the requirements of that amendment. The report covering the period from the signing of the amendment through December 31, 2002 has been submitted and can be found at http://www.icann.org/general/status-report-08jan03.htm. The report highlights not just all that has been done towards achieving the reform of ICANN, but also the significant progress that has been made in many other important areas. I would like to thank each of you for all of your support and dedicated efforts towards both the reform efforts and some of these other areas of accomplishment. Without your voluntary commitment of your precious time, none of this would have been possible. With best wishes for 2003 and for continuing collaborations! Stuart -- __________________ Stuart Lynn President and CEO ICANN 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 Tel: 310-823-9358 Fax: 310-823-8649 Email: lynn at icann.org * on-line archive: http://aso.icann.org/wilma-bin/wilma/aso-council * * To unsubscribe: send "unsubscribe" to aso-council-request at aso.icann.org * ---------- End Forwarded Message ---------- From peter.galbavy at knowtion.net Fri Jan 10 10:51:18 2003 From: peter.galbavy at knowtion.net (Peter Galbavy) Date: Fri, 10 Jan 2003 09:51:18 -0000 Subject: [lir-wg] Name of the LIR WG References: Message-ID: <005401c2b88d$d2d4dbe0$4528a8c0@cblan.mblox.com> > RIPE is more than just the RIPE NCC members, so 'ripe-wg' would be a > wrong name. Sorry to bring up a previous discussion, but this contradicts what has been said on the thread(s) about membership fees. Can someone (Rob ...) please clarify what RIPE and RIPE-NCC are ? Peter From crain at icann.org Fri Jan 10 20:21:13 2003 From: crain at icann.org (John L Crain) Date: Fri, 10 Jan 2003 11:21:13 -0800 Subject: [lir-wg] Name of the LIR WG In-Reply-To: <005401c2b88d$d2d4dbe0$4528a8c0@cblan.mblox.com> References: <005401c2b88d$d2d4dbe0$4528a8c0@cblan.mblox.com> Message-ID: <1804041611.20030110112113@icann.org> My, I hope reasonably correct and not too long winded comments: On the website there are some definitions that can be helpful. http://www.ripe.net/ripencc/about/ http://www.ripe.net/ripe/about/index.html The fact that they are both often refered to as RIPE and that they share a URL has often caused confusion. I worked there for a long time and often spent my cycles trying to explain the difference to people. RIPE NCC is a "Network Coordination Centre" that, amongst other things, distributes IP addresses and AS#'s to it's members. These are typically the ISP's who need these resources. I personally always try and refer to the organisation as "the NCC" rather than "RIPE". The NCC has members who pay membership fees and gain neutral services for those fees. The services are defined/agreed by membership via activity plans etc. RIPE Meetings, together with the working groups mailing lists and RIPE documents etc. constitute "RIPE". It is a much wider community than the NCC membership, consisting of anyone who wishes to participate. Many NCC members, called "Local Internet Registries" are also participants in RIPE. You "participate" in RIPE rather than being a "member" as it doesn't have a formal organisational structure. RIPE also covers many more topics than NCC related ones, in theory a wg could be created on any topic directly relevant to the Internet community and it's operations. Because of the large amount of NCC members that participate in RIPE and the extension to envelope a wider community, RIPE has traditionally been, and IMHO still is, the logical "place" to discuss and develop the policies that the NCC uses. Hence the lir-wg. The name of the group may, or may not, be an optimal choice but I tend to agree that making the fact that it is an open forum widespread knowledge is I think a more important issue than what we name it. The "NCC" does a lot of work mentioning the lir-wg wherever it sends staff and I think the website is fairly clear. It's important that all of us as a community also let others know about RIPE and it's various working groups to others. If people have good ideas on how to spread "the gospel" about both RIPE and more specifically the Lir-wg I think all of us in the community would be glad to partake. JC >> RIPE is more than just the RIPE NCC members, so 'ripe-wg' would be a >> wrong name. PG> Sorry to bring up a previous discussion, but this contradicts what has been PG> said on the thread(s) about membership fees. PG> Can someone (Rob ...) please clarify what RIPE and RIPE-NCC are ? PG> Peter From Robert.Kiessling at de.easynet.net Mon Jan 13 21:05:38 2003 From: Robert.Kiessling at de.easynet.net (Robert Kiessling) Date: 13 Jan 2003 20:05:38 +0000 Subject: [lir-wg] IPv6 assignments to RIPE itself Message-ID: Hello, RIPE uses addresses which are unassigned: > host -t aaaa ns.ripe.net. ns.ripe.net IPv6 address 2001:610:240:0:193::193 > whois 2001:610:240:0:193::193 inet6num: 2001:0610:0240::/42 netname: RIPE-NCC-IPv6 descr: RIPE NCC status: ALLOCATED-BY-LIR In my understanding, this is not an allowed usage sice RIPE must assign a /48 to themselves before the use the address space. However, I rose this issue with them, and they claim there is not need for this. Could someone please explain to me where my understanding of the allocation and assignment rules is flawed? Thank you, Robert From john at apnic.net Tue Jan 14 02:00:00 2003 From: john at apnic.net (John Tran) Date: Tue, 14 Jan 2003 11:00:00 +1000 (EST) Subject: [lir-wg] APNIC New IPv6 address block Message-ID: Dear colleagues APNIC received the IPv6 address range 2001:0E00::/23 from IANA in January 2003 and will be making allocations from this range in the near future. Please configure your routing filters accordingly. For more information on the resources administered by APNIC, see: http://www.apnic.net/db/ranges.html For information on the minimum allocation sizes within address ranges administered by APNIC, see: http://www.apnic.net/db/ranges.html For information on the minimum allocation sizes within address ranges administered by APNIC, see: http://www.apnic.net/db/min-alloc.html Kind regards Son ____________________________________________________________________ Resources Services Manager Asia Pacific Network Information Centre phone: +61 7 3858 3100 http://www.apnic.net fax: +61 7 3858 3199 Helpdesk phone: +61 7 3858 3188 email: helpdesk at apnic.net Please send Internet Resource Requests to _____________________________________________________________________ * APNIC-ANNOUNCE: Announcements concerning APNIC * * To unsubscribe, send "unsubscribe" to apnic-announce-request at apnic.net * * APNIC-TALK: General APNIC Discussion List * * To unsubscribe: send "unsubscribe" to apnic-talk-request at apnic.net * From gert at space.net Tue Jan 14 10:12:27 2003 From: gert at space.net (Gert Doering) Date: Tue, 14 Jan 2003 10:12:27 +0100 Subject: [lir-wg] IPv6 assignments to RIPE itself In-Reply-To: ; from Robert.Kiessling@de.easynet.net on Mon, Jan 13, 2003 at 08:05:38PM +0000 References: Message-ID: <20030114101227.S15927@Space.Net> Hi, On Mon, Jan 13, 2003 at 08:05:38PM +0000, Robert Kiessling wrote: > RIPE uses addresses which are unassigned: > > > host -t aaaa ns.ripe.net. > ns.ripe.net IPv6 address 2001:610:240:0:193::193 > > > whois 2001:610:240:0:193::193 > inet6num: 2001:0610:0240::/42 > netname: RIPE-NCC-IPv6 > descr: RIPE NCC > status: ALLOCATED-BY-LIR > > In my understanding, this is not an allowed usage sice RIPE must > assign a /48 to themselves before the use the address space. > > However, I rose this issue with them, and they claim there is not need > for this. > > Could someone please explain to me where my understanding of the > allocation and assignment rules is flawed? I tend to agree with you. The /42 has been sub-allocated from Surfnet to the RIPE NCC (the NCC being "Just any Surfnet customer" here, not acting in their function as RIR). Out of that /42, the NCC is using a /48 for "NCC network", and further /48s for "employee home networks". [Personally, I see this as wastive, but I've mentioned before that "/48 per site" is a stupid rule in the context of "employee networks" and "student homes", as it means most companies will then want more than a /48, which is NOT what was intended. But that's a separate discussion]. Following the basic principles of "conservation, aggregation, documentation", I think the usage of the individual /48s inside the /42 really should be documented. On the other hand, the guidelines are not really clear. After all, it's *Surfnet* who has to document what they do inside their /32, and they *have* documented that this /42 is used by the RIPE NCC. Tricky. And setting interesting (and important) precedence. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55593 (55180) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From gert at space.net Tue Jan 14 10:17:11 2003 From: gert at space.net (Gert Doering) Date: Tue, 14 Jan 2003 10:17:11 +0100 Subject: Fwd: [lir-wg] Re: [lir-wg]Election of chairs to the lir-wg - call for nominations In-Reply-To: <9848FEC6-2304-11D7-A551-000393AB1404@kurtis.pp.se>; from kurtis@kurtis.pp.se on Wed, Jan 08, 2003 at 01:27:47PM +0100 References: <9848FEC6-2304-11D7-A551-000393AB1404@kurtis.pp.se> Message-ID: <20030114101711.U15927@Space.Net> Hi, On Wed, Jan 08, 2003 at 01:27:47PM +0100, Kurt Erik Lindqvist wrote: > Ok, on the request of Hans Petter I resubmit this. > > Note that I have no idea if Gert is willing or not I just went for > someone I think have shown good understanding and reason :) I have been thinking about this for nearly a week now, and want to state that I would be willing to help as a co-chair. (I can't resist being drawn into all these policy discussions anyway ;-) ) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55593 (55180) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From pim at bit.nl Tue Jan 14 12:03:41 2003 From: pim at bit.nl (Pim van Pelt) Date: Tue, 14 Jan 2003 12:03:41 +0100 Subject: [lir-wg] IPv6 assignments to RIPE itself In-Reply-To: References: Message-ID: <20030114110341.GC4746@crow.bit.nl> | > whois 2001:610:240:0:193::193 | inet6num: 2001:0610:0240::/42 | netname: RIPE-NCC-IPv6 | descr: RIPE NCC | status: ALLOCATED-BY-LIR | | In my understanding, this is not an allowed usage sice RIPE must | assign a /48 to themselves before the use the address space. | | However, I rose this issue with them, and they claim there is not need | for this. | | Could someone please explain to me where my understanding of the | allocation and assignment rules is flawed? I do not agree with them (RIPE NCC). It is my understanding that everybody that gets an allocation in IPv4, should make assignments from this to their customers/downstream entities. There is common practice to assign /48s to endsites. I think that IPv6 allocation/assignment should not be different from the IPv4 world, so I don't think your understanding is flawed at all. -- __________________ Met vriendelijke groet, /\ ___/ Pim van Pelt /- \ _/ Business Internet Trends BV PBVP1-RIPE /--- \/ __________________ From woeber at cc.univie.ac.at Tue Jan 14 12:27:52 2003 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 14 Jan 2003 12:27:52 +0100 Subject: [lir-wg] IPv6 assignments to RIPE itself Message-ID: <00A19F50.D230372A.15@cc.univie.ac.at> >| > whois 2001:610:240:0:193::193 >| inet6num: 2001:0610:0240::/42 >| netname: RIPE-NCC-IPv6 >| descr: RIPE NCC >| status: ALLOCATED-BY-LIR I think there are 2 questions here that should be discussed, under the premises that SURFnet has set aside a /42 for the NCC from SURFnet's sTLA: a) what is the "correct" status: field for a block bigger than /48 I think in most cases (like /47, /46 for a big site) it should simply be ASSIGNED, even if it is as big as a /42. b) in a more general sense, to what level are we (LIR) and our sites/customers (/64, /48 or bigger) expected to document internal address management? For the moment, the only thing that looks funny _for me_ is the status: "ALLOCATED-BY-LIR". I read that as an indication that the NCC would make _assignments_ from that block, e.g. /64s and /48s - which I think _should_ be registered by the NCC or by SURFnet. Wilfried. From engin at ripe.net Tue Jan 14 12:54:13 2003 From: engin at ripe.net (Engin Gunduz) Date: Tue, 14 Jan 2003 12:54:13 +0100 Subject: [lir-wg] Re: Updated proposal for clean-up of references by name In-Reply-To: <20021220104444.GF5138@x47.ripe.net> References: <20021220104444.GF5138@x47.ripe.net> Message-ID: <20030114115413.GD18835@x47.ripe.net> [Apologies for duplicate messages] Dear Colleagues, On 2002-12-20 11:44:44 +0100, Engin Gunduz wrote: > > [Apologies for duplicate messages] > > Dear Colleagues, > > I'm attaching the updated proposal for automatically > cleaning up the references by name in RIPE Whois Database. > We have incorporated Janos's suggestions to the proposal. > > If no more comments come, we plan to apply the procedure > described in the proposal in the first half of January, 2003. > The operation should not take more than a day. We will notify > the community about the actual date of the operation. We plan to perform the clean-up - on January 15, Wednesday (tomorrow), afternoon (CET) on TEST database, - on January 16, Thursday, afternoon (CET) on RIPE database. The operation will take several hours, however during the operation the queries and updates will continue as normal. Best regards, Engin Gunduz ____________________________ RIPE NCC Database Group > > Regards, > > Engin Gunduz > ____________________________ > RIPE NCC Database Group > > > > -------------- > Proposed solution for cleaning up references by name and other > invalid references in RIPE Whois Database > > Motivation: > > References by name and invalid references cause two main problems: > 1. One reference by name in a single object locks all person > and role objects with that name, that is, they cannot > be deleted, because of referential integrity checks. > 2. Having anything other than a NIC handle as a reference makes > the implementation of whois database software considerably > more complex, since the software needs to deal with these > exceptions. This increases the coding time, maintenance time > and testing time of the software. > > Classification of the inconsistencies we need to solve and proposed > solutions: > > 1. Objects that refer to a person or role object by name. > a. There is only one object with this name. > 1. The referring inconsistent object is not maintained, or > the maintainers of referring inconsistent object and the > person/role object with this name are the same. > Solution: Update the referring inconsistent object so that it > will contain the NIC handle instead of the name. Add > appropriate remarks and changed attributes to the object > to explain the reason for update. > 2. The referring object is maintained, and the maintainers are > different from the maintainers of the object with the > referred name (If the latter object is not maintained, then > the maintainers are by definition different.) > Solution: Create a role object with this name. It will list > the role or person object with this name in its admin-c and > tech-c attributes. Update the inconsistent object to refer > to the NIC handle of this new role object. Add appropriate > remarks and changed attributes to the object to explain the > reason for update. > b. There is no person or role object with this name: > Solution: Create a person object with this name. Clearly > mark this new object putting appropriate remarks attributes > so that users will see it is actually a dummy object. > Update the inconsistent object to refer to the NIC handle > of this new person object. Add appropriate remarks and > changed attributes to the object to explain the reason for > update. Protect it with the inconsistent object's maintainer(s). > c. There are multiple person and role objects with this name. > Solution: Create a role object with this name. It will list > all the other role and person objects with the same name > in its admin-c and tech-c attributes. Update the inconsistent > object to refer to the NIC handle of this new role object. > Add appropriate remarks and changed attributes to the object > to explain the reason for update. > 2. Objects that refer to a non-existent NIC handle. > Solution: Create a person object with that NIC handle. Clearly mark > this new object so that users will see it is actually a dummy > object. Name it "person: Place Holder Object". Protect it with > the inconsistent object's maintainer(s). Note that there is no > need to update the inconsistent object itself. > 3. Objects that refer to a string which is neither a name, nor a NIC > handle. For example, it might be a phone number in admin-c attribute, > or it might be 'Gunduz', a string that can't be a NIC handle, as > it's longer than 4 letters, nor can it be a name as it has only > one word. Another example could be "Mr. Gunduz", which enters this > category because "Mr" can't appear in a name of person/role object. > Solution: Create a person object for each such reference. Name > the object "person: Place Holder Object" and list the object that > refers to it in its remarks attribute. Protect it with inconsistent > object's maintainer(s). Then update the inconsistent object to refer > to the NIC handle of this new place holder person object. > > In each case an object is updated, or created, send appropriate notifications > (determined by "mnt-by" and "notify" attributes, as with all other > updates). > > Please note that this proposal does not actually solve the problem > of invalid contact information-- rather, it makes the data set more > uniform, thus decreases the administration and development time of > the whois database. > From jeroen at unfix.org Tue Jan 14 13:04:42 2003 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 14 Jan 2003 13:04:42 +0100 Subject: [lir-wg] IPv6 assignments to RIPE itself In-Reply-To: <00A19F50.D230372A.15@cc.univie.ac.at> Message-ID: <000e01c2bbc5$201e8e20$534510ac@cyan> Wilfried Woeber, UniVie/ACOnet wrote: > >| > whois 2001:610:240:0:193::193 > >| inet6num: 2001:0610:0240::/42 > >| netname: RIPE-NCC-IPv6 > >| descr: RIPE NCC > >| status: ALLOCATED-BY-LIR > > I think there are 2 questions here that should be discussed, > under the premises that SURFnet has set aside a /42 for > the NCC from SURFnet's sTLA: > > a) what is the "correct" status: field for a block bigger than /48 > I think in most cases (like /47, /46 for a big site) it should > simply be ASSIGNED, even if it is as big as a /42. > > b) in a more general sense, to what level are we (LIR) and our > sites/customers (/64, /48 or bigger) expected to document internal > address management? > > For the moment, the only thing that looks funny _for me_ is > the status: > "ALLOCATED-BY-LIR". I read that as an indication that the > NCC would make > _assignments_ from that block, e.g. /64s and /48s - which I think > _should_ be registered by the NCC or by SURFnet. IMHO the assignments for the /48's should be documented in a local (r)whois database. With at least a referal from the central whois. Anything bigger than one /48 should be documented in the central (whois.ripe.net) database. This should 'lighten' the load on the central whois as there are 2^(128-32-48=48) (a lot) of /48's to be registered in to the database. As for the reason why I think those /48's should be registered: When a spammer/abuser/* is using 1 IP out of the /48 it would be better to contact the onsite administrator then the upstream ISP. And especially as a /48 could hold a major corporation or a big university this is something that IMHO should be very useful. Ofcourse one shouldn't be forced to use the defacto whois software but could integrate it into their backend systems, thus actually allowing a view into their network. Ofcourse this isn't always what is wanted due to various political reasons etc., which is why I said that it _should_ be documented ;) Example: SixXS (www.sixxs.net) has the IPng tunnelbroker which delegates /60's from 3ffe:8114:2000::/48. We used to register every /60 in the 6bone database. But updating this every time an allocation is made and with the number of allocations isn't quite handy especially as the parameters enclosed in the inet6num could change a lot (eg endpoint changes). Thus we created our very own whois server (whois.sixxs.net) from which the data can be accessed, directly and up-to-date. eg: 8<---------------------------------------------- $ whois -h whois.sixxs.net 3ffe:8114:2000:240::/60 % This is the SixXS Whois server. % SixXS - http://www.sixxs.net. % The objects are in RPSL format. % Objects not beginning with SIXXS- % or ending in -SIXXS are % cached responses from remote sources. inet6num: 3ffe:8114:2000:240::/60 netname: SIXXS-NLAMS02-NET-JRM1-6BONE-34 descr: This route goes to an endpoint of JRM1-6BONE. descr: This route is routed to 3ffe:8114:1000::27 / 195.64.92.136. descr: IPng import country: NL admin-c: PBVP1-6BONE admin-c: JRM1-6BONE tech-c: PBVP1-6BONE tech-c: JRM1-6BONE rev-srv: purgatory.unfix.org. remarks: Prefixtype: Route remarks: This object is generated from the SixXS database remarks: Abuse reports should go to abuse at sixxs.net remarks: Information can be found at http://www.sixxs.net/ changed: info at sixxs.net 20020928 changed: info at sixxs.net 20030105 mnt-by: SIXXS-MNT source: SIXXS ---------------------------------------------->8 This allows troubleshooters to see where this prefix leads but it doesn't burden the main (in this case 6bone) database with new creations/updates/deletions. Only problem here is that in the non rwhois databases there is no defacto 'referal' method. At least as far as I know of except for a 'remarks:' field. If somebody can hint me where to find it I would be pleased. Ofcourse all this is just my idea on this small sidesubject. Greets, Jeroen From woeber at cc.univie.ac.at Tue Jan 14 13:15:23 2003 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 14 Jan 2003 13:15:23 +0100 Subject: [lir-wg] IPv6 assignments to RIPE itself Message-ID: <00A19F57.758F6E3A.29@cc.univie.ac.at> Hi Jeroen! >Only problem here is that in the non rwhois databases there is no >defacto 'referal' method. At least as far as I know of except for >a 'remarks:' field. If somebody can hint me where to find it I would >be pleased. Interesting line of thought! In fact there _is_ a referral mechanism - for domain lookups, but not for address lookups. Depending on what the result of this discussion is, we could investigate the merits of a referral mechanism for inet6nums, too. Nevertheless I'd strongly suggest to keep the (minimal) required documentation of resources in the central database, instead of going down the route of rwhois (or the like). Wilfried. From gert at space.net Tue Jan 14 14:06:35 2003 From: gert at space.net (Gert Doering) Date: Tue, 14 Jan 2003 14:06:35 +0100 Subject: [lir-wg] IPv6 assignments to RIPE itself In-Reply-To: <000e01c2bbc5$201e8e20$534510ac@cyan>; from jeroen@unfix.org on Tue, Jan 14, 2003 at 01:04:42PM +0100 References: <00A19F50.D230372A.15@cc.univie.ac.at> <000e01c2bbc5$201e8e20$534510ac@cyan> Message-ID: <20030114140635.Z15927@Space.Net> Hi, On Tue, Jan 14, 2003 at 01:04:42PM +0100, Jeroen Massar wrote: > Example: SixXS (www.sixxs.net) has the IPng tunnelbroker which delegates > /60's from 3ffe:8114:2000::/48. We used to register every /60 in the > 6bone database. Which brings up an interesting problem. According to the official guidelines, you're not supposed to assing anything that is not an /64 or /48. Of course this isn't helpful, as a home/DSL/tunnel user might want to use *two* networks, or *three*, but will never use more than 16 - and such a /60 is just perfect for them (I have considered doing the same for our dialup DSL customers). But the IETF in their infinite wisdom decided that this is not what people will want, so you're supposed to give them a /48. Which, for DSL and Tunnel usage, means "a sizeable chunk of the /32 that a LIR holds". > But updating this every time an allocation is made and with > the number of allocations isn't quite handy especially as the parameters > enclosed in the inet6num could change a lot (eg endpoint changes). Now that part could be automated. Especially with the sync updates, this is fairly easy :-). On the other hand, adding referral mechanism for the inet6num: hierarchy would certainly be less strain to the RIPE DB. It's there for the domain: tree, so it shouldn't be too hard. Item for the working group (LIR or DB)? Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55593 (55180) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From pim at bit.nl Tue Jan 14 14:12:25 2003 From: pim at bit.nl (Pim van Pelt) Date: Tue, 14 Jan 2003 14:12:25 +0100 Subject: [lir-wg] IPv6 assignments to RIPE itself In-Reply-To: <20030114140635.Z15927@Space.Net> References: <00A19F50.D230372A.15@cc.univie.ac.at> <000e01c2bbc5$201e8e20$534510ac@cyan> <20030114140635.Z15927@Space.Net> Message-ID: <20030114131225.GA22997@crow.bit.nl> | On Tue, Jan 14, 2003 at 01:04:42PM +0100, Jeroen Massar wrote: | > Example: SixXS (www.sixxs.net) has the IPng tunnelbroker which delegates | > /60's from 3ffe:8114:2000::/48. We used to register every /60 in the | > 6bone database. | | | Which brings up an interesting problem. According to the official | guidelines, you're not supposed to assing anything that is not | an /64 or /48. [snip] | But the IETF in their infinite wisdom decided that this is not what | people will want, so you're supposed to give them a /48. Which, for | DSL and Tunnel usage, means "a sizeable chunk of the /32 that a LIR | holds". | Luckily, these /60 policies outdated the IETF recommendations by a year or two. And I'm not about to consider changing the pTLA tunnelbroker system at AS8954. The other (newer) deployments of the SixXS software do indeed issue /48s for each homeuser, following RIPE NCC's prior notice that 'if in doubt, allocate a /48' (AIAD oct'02). groet, Pim -- __________________ Met vriendelijke groet, /\ ___/ Pim van Pelt /- \ _/ Business Internet Trends BV PBVP1-RIPE /--- \/ __________________ From bortzmeyer at gitoyen.net Tue Jan 14 14:17:06 2003 From: bortzmeyer at gitoyen.net (Stephane Bortzmeyer) Date: Tue, 14 Jan 2003 14:17:06 +0100 Subject: [lir-wg] IPv6 assignments to RIPE itself In-Reply-To: <20030114140635.Z15927@Space.Net> References: <00A19F50.D230372A.15@cc.univie.ac.at> <000e01c2bbc5$201e8e20$534510ac@cyan> <20030114140635.Z15927@Space.Net> Message-ID: <20030114131706.GA12389@nic.fr> On Tue, Jan 14, 2003 at 02:06:35PM +0100, Gert Doering wrote a message of 44 lines which said: > But the IETF in their infinite wisdom decided that this is not what > people will want, so you're supposed to give them a /48. Which, for RFC 3177 explains in great detail the rationale behind this recommendation. I suggest to read it. From woeber at cc.univie.ac.at Tue Jan 14 14:31:49 2003 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 14 Jan 2003 14:31:49 +0100 Subject: [lir-wg] Name of the LIR WG Message-ID: <00A19F62.230BEC0A.21@cc.univie.ac.at> Thanks, John, >My, I hope reasonably correct and not too long winded comments: I think this was a very well-structured summary. Just one additional clarification: >The NCC has members who pay membership fees and gain neutral services for >those fees. The services are defined/agreed by membership via activity >plans etc. Typically those members (the LIRs) are organisations (ISPs, companies, associations,...) and, depending on their size and thus financial contribution, can control a certain number of votes in the NCC's AGM (the Association's General Assembly). >Many NCC members, called "Local Internet Registries" are also participants in RIPE. >You "participate" in RIPE rather than being a "member" as it doesn't have a formal >organisational structure. However, even if a person happens to be affiliated with an LIR, the person participates in RIPE as an individual! In the sense of one person, one point of view to be considered for consensus development. Right? Wilfried. From gert at space.net Tue Jan 14 14:38:47 2003 From: gert at space.net (Gert Doering) Date: Tue, 14 Jan 2003 14:38:47 +0100 Subject: [lir-wg] IPv6 assignments to RIPE itself In-Reply-To: <20030114131225.GA22997@crow.bit.nl>; from pim@bit.nl on Tue, Jan 14, 2003 at 02:12:25PM +0100 References: <00A19F50.D230372A.15@cc.univie.ac.at> <000e01c2bbc5$201e8e20$534510ac@cyan> <20030114140635.Z15927@Space.Net> <20030114131225.GA22997@crow.bit.nl> Message-ID: <20030114143847.C15927@Space.Net> Hi, On Tue, Jan 14, 2003 at 02:12:25PM +0100, Pim van Pelt wrote: > > Luckily, these /60 policies outdated the IETF recommendations by a year or > two. And I'm not about to consider changing the pTLA tunnelbroker system > at AS8954. The other (newer) deployments of the SixXS software do indeed > issue /48s for each homeuser, following RIPE NCC's prior notice that 'if > in doubt, allocate a /48' (AIAD oct'02). > My rant wasn't actually directed at you. I just noticed that you were having a similar policy issue to the one that came up here recently. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55593 (55180) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From andrei at ripe.net Tue Jan 14 14:53:42 2003 From: andrei at ripe.net (Andrei Robachevsky) Date: Tue, 14 Jan 2003 14:53:42 +0100 Subject: [lir-wg] IPv6 assignments to RIPE itself References: <5.2.0.9.2.20030114134130.065bfd68@localhost> Message-ID: <3E241666.50803@ripe.net> Dear Robert, colleagues, > Hello, > > RIPE uses addresses which are unassigned: > > > host -t aaaa ns.ripe.net. > ns.ripe.net IPv6 address 2001:610:240:0:193::193 > > > whois 2001:610:240:0:193::193 > inet6num: 2001:0610:0240::/42 > netname: RIPE-NCC-IPv6 > descr: RIPE NCC > status: ALLOCATED-BY-LIR > > In my understanding, this is not an allowed usage sice RIPE must > assign a /48 to themselves before the use the address space. > This is our fault that the assignments we made were used before they were registered as inet6num objects with "ASSIGNED" status. This has now been corrected. I would like to note that this space wasn't allocated by the RIPE NCC to the RIPE NCC itself, but rather by SURFnet to their customer - RIPE NCC operations department and then assigned to their customers - RIPE NCC's network, RIPE meeting network and home networks of the NCC's staff. I must also apologise to SURFnet as this might have affected their HD ratio. > However, I rose this issue with them, and they claim there is not need > for this. > > Could someone please explain to me where my understanding of the > allocation and assignment rules is flawed? > > Thank you, > > Robert > Regards, Andrei Robachevsky CTO, RIPE NCC From gert at space.net Tue Jan 14 14:54:50 2003 From: gert at space.net (Gert Doering) Date: Tue, 14 Jan 2003 14:54:50 +0100 Subject: [lir-wg] IPv6 assignments to RIPE itself In-Reply-To: <20030114131706.GA12389@nic.fr>; from bortzmeyer@gitoyen.net on Tue, Jan 14, 2003 at 02:17:06PM +0100 References: <00A19F50.D230372A.15@cc.univie.ac.at> <000e01c2bbc5$201e8e20$534510ac@cyan> <20030114140635.Z15927@Space.Net> <20030114131706.GA12389@nic.fr> Message-ID: <20030114145449.D15927@Space.Net> Hi, On Tue, Jan 14, 2003 at 02:17:06PM +0100, Stephane Bortzmeyer wrote: > > But the IETF in their infinite wisdom decided that this is not what > > people will want, so you're supposed to give them a /48. Which, for > > RFC 3177 explains in great detail the rationale behind this > recommendation. I suggest to read it. The recommendation is pretty useless as it doesn't define what a "site" (or a "single edge network") is. I have been part of the discussions in the RIPE IPv6 WG, and have heard all the arguments in favour of the way it's set up now. Those arguments are pretty convincing, indeed... ...until you start thinking about "large scale assignments to *huge numbers* of DSL users with 1-2 networks each" and "how big shall the network be that a company assigns to their employees for home use" and "how much address space shall a university give to each of their students for at-home usage". None of those questions have any satisfactory answer under the current model. Especially the second one is what we have here right now. Shall a company (being "a site") get a /48? Or shall each of the individual employees of that company (his home network being "a site") get a /48, thus making the company need a /42? How can we assign a /42 to something that's as small (network-wise) as the RIPE NCC? If we accept the argument that "there is no shortage of /48s" and hand out /48s freely to all individual employees of a customer, or to each individual student of a university, then this will deplete the LIRs /32 pretty quickly (a university with 35.000 students might easily use up a /32 on their own). Which is not what people envisioned when the current IPv6 allocation policy was made, obviously. Also, this practice would be violating RFC 3177: - Very large subscribers could receive a /47 or slightly shorter prefix, or multiple /48's. - which makes it pretty clear that an enterprise should not receive a /42 just because their employees want a /48 each. Now how are you going to solve that riddle? (A viable solution would be to give every LIR a /20. But last time I proposed that, people were Not Amused, accused me of wasting address space and flatly refused to accept that as a new policy...) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55593 (55180) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From andrius at andrius.org Tue Jan 14 22:03:43 2003 From: andrius at andrius.org (Andrius Kasparavicius) Date: Tue, 14 Jan 2003 23:03:43 +0200 Subject: [lir-wg] should aut-num object for IPv4 & IPv6 be the same? Message-ID: <20030114210342.GC17240@mail.kalnieciai.lt> hello, IPv6 AS policy can differ from IPv4, should we ignore IPv6 then? Andrius From jeroen at unfix.org Wed Jan 15 01:40:11 2003 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 15 Jan 2003 01:40:11 +0100 Subject: inet6num referral (Was: [lir-wg] IPv6 assignments to RIPE itself) In-Reply-To: <00A19F57.758F6E3A.29@cc.univie.ac.at> Message-ID: <004b01c2bc2e$aa468120$210d640a@unfix.org> Wilfried Woeber, UniVie/ACOnet [mailto:woeber at cc.univie.ac.at] wrote: > Hi Jeroen! > > >Only problem here is that in the non rwhois databases there is no > >defacto 'referal' method. At least as far as I know of except for > >a 'remarks:' field. If somebody can hint me where to find it I would > >be pleased. > > Interesting line of thought! > > In fact there _is_ a referral mechanism - for domain lookups, but not > for address lookups. Depending on what the result of this discussion > is, we could investigate the merits of a referral mechanism for > inet6nums, too. [Maybe this should go into db-wg?] The domain name referral mechanism works using the 'refer' tag. This could be used for inet6nums too, albeit as it isn't defined for inet6num's the whois db won't accept it. Most clients probably won't care much. Marco d'Itri's whois client also handles The refer tag is documented in amongst others http://www.ripe.net/ripe/docs/databaseref-manual.html An (minimal) example of inet6num in this style could look like. 8<------------------------ inet6num: fec0:8114:1000::/40 netname: EXAMPLE-DLG-ONE descr: Example /48 delegation space to endusers. refer: RIPE whois.example.net 43 country: NL remarks: More specific information can be found by quering whois.example.net mnt-by: MNT-EXAMPLE changed: jeroen at unfix.org 20030115 source: EXAMPLE ------------------------>8 Lines 4 and 6 depict the referral, line 6 is simply there to allow humans to know of ther referral too, though it could be left out as line 4 is obvious enough. Line 6 can ofcourse easily be autogenerated in the server side. The "refer" should actually be "longer refer" in that only the subdelegations of the inet6num are referred and not the inet6num documented itself. This way the documentation is always available in RIPE (which should be up 99%) and the more detailed versions should go in the referred server. One thing is that the domain 'refer' attribute does the refer on the RIPE server. Thus the object is fetched from the referred server bij whois.ripe.net which actually could/will cause some extra load on the whois.ripe.net machine. Marco pointed out to me that the 6bone database (whois.6bone.net) has a special piece of code that when a person/maintainer object etc is not found in the local database it outputs a: % referto: whois -h whois.ripe.net -p 43 -s RIPE -T person,role NO17-RIPE Eg as found in http://www.viagenie.qc.ca/cgi-bin/whois.pl?SURFNET The whois-client then connects to the specified server and request the data from there. It would probably be better if these referals are done client side for the inet6num case too. Problem with this is that it isn't an attribute and thus there is no way to control it when filling in your inet6num, unless there comes a exception etc... in which case a correctly specified refer attribute would be better. > Nevertheless I'd strongly suggest to keep the (minimal) required > documentation of resources in the central database, instead of going > down the route of rwhois (or the like). IMHO the whois.ripe.net, with a "longer refer" to whois.example.net fec0:8114:1000::/48 -> whois.example.net (The regional ISP) fec0:8114:1000::/56 -> whois.example.org (The enduser organisation) Which makes it quite flexible, but ofcourse people shouldn't refer to much otherwise this will become DNS. Greets, Jeroen From shane at ripe.net Wed Jan 15 10:09:05 2003 From: shane at ripe.net (Shane Kerr) Date: Wed, 15 Jan 2003 10:09:05 +0100 Subject: [lir-wg] should aut-num object for IPv4 & IPv6 be the same? In-Reply-To: <20030114210342.GC17240@mail.kalnieciai.lt> References: <20030114210342.GC17240@mail.kalnieciai.lt> Message-ID: <20030115090904.GA19923@x17.ripe.net> Andrius, On 2003-01-14 23:03:43 +0200, Andrius Kasparavicius wrote: > > IPv6 AS policy can differ from IPv4, should we ignore IPv6 then? There is a draft document on extending RPSL to allow IPv6 as well as IPv4 policies to be in aut-num objects. This has been discussed on the RPSLng mailing list: http://www.ripe.net/ripe/mail-archives/rpslng/index.html This work was carried out in the RIPE community in the routing, database, and IPv6 working groups. It is an IETF draft: http://www.ietf.org/internet-drafts/draft-damas-rpslng-00.txt The Database department at the RIPE NCC has been following this activity closely, and has committed to implementing this in the RIPE Database and in the IRRToolSet. I'll be giving an estimated timeline of when this new syntax will be available in a couple of weeks at the RIPE 44 meeting. (If you really want the details, you can e-mail me off list and I can give you a full timeline, and possibly offer some pre-release software as it becomes available.) -- Shane Kerr RIPE NCC From adrian.pauling at bt.com Wed Jan 15 10:51:02 2003 From: adrian.pauling at bt.com (adrian.pauling at bt.com) Date: Wed, 15 Jan 2003 09:51:02 -0000 Subject: [lir-wg] should aut-num object for IPv4 & IPv6 be the same? Message-ID: <979C13511BD16947AC758DB50A546B7FA4DA93@i2km10-ukbr.domain1.systemhost.net> we have 'inet6num' objects separate to 'inetnum' to distinguish IPv6 address assignments from IPv4. Is the question should different 'peering-set' 'route' objects etc reflect different peerings for IPv6 from IPv4 that an assigned AS can have? This scenario is real as I can easily give a current (enterprise LIR) example. Regards, Adrian F Pauling BT Ignite Solutions From gall at switch.ch Wed Jan 15 10:14:34 2003 From: gall at switch.ch (Alexander Gall) Date: 15 Jan 2003 10:14:34 +0100 Subject: [lir-wg] IPv6 assignments to RIPE itself In-Reply-To: <20030114145449.D15927@Space.Net> References: <00A19F50.D230372A.15@cc.univie.ac.at> <000e01c2bbc5$201e8e20$534510ac@cyan> <20030114140635.Z15927@Space.Net> <20030114131706.GA12389@nic.fr> <20030114145449.D15927@Space.Net> Message-ID: <9p4r8arczp.fsf@switch.ch> [Probably opening a can of worms here...] On Tue, 14 Jan 2003 14:54:50 +0100, Gert Doering said: > On Tue, Jan 14, 2003 at 02:17:06PM +0100, Stephane Bortzmeyer wrote: >> > But the IETF in their infinite wisdom decided that this is not what >> > people will want, so you're supposed to give them a /48. Which, for >> >> RFC 3177 explains in great detail the rationale behind this >> recommendation. I suggest to read it. > The recommendation is pretty useless as it doesn't define what a "site" > (or a "single edge network") is. The reasoning in that document is heavily based on the statement that there is enough address space to give a /48 to everybody and their dogs. With this assumption (which, I believe, is fairly sound by itself), you don't need a precise definition of a site (``when in doubt, assign a /48''). I think that RFC3177 is self-consistent in that respect. But see below. [snip] > If we accept the argument that "there is no shortage of /48s" and hand > out /48s freely to all individual employees of a customer, or to each > individual student of a university, then this will deplete the LIRs /32 > pretty quickly (a university with 35.000 students might easily use up > a /32 on their own). Which is not what people envisioned when the > current IPv6 allocation policy was made, obviously. I agree. The numerics in section 4 of RFC3177 assume that the top 45 bits in 2000::/3 can be utilized with an H ratio of 0.25 (giving on the order of 10^11 /48). IMHO, the problem with the current allocation policy is that it is a lot more conservative than RFC3177 suggests while still holding on to the /48-for-everybody rule. The relatively small LIR allocations create a level of scarcity in the number of /48's, which is enough to make people believe that giving a student as much address space as her entire University is just crazy. However, the whole point of RFC3177 was that this should be completely irrelevant. > Also, this practice would be violating RFC 3177: > - Very large subscribers could receive a /47 or slightly shorter > prefix, or multiple /48's. > - which makes it pretty clear that an enterprise should not receive a > /42 just because their employees want a /48 each. > Now how are you going to solve that riddle? I think this contradiction exists mainly within the current allocation policy. RFC3177 seems to be flexible (or vague ;-) enough. With a policy in which such an enterprise can act as a (sub-)LIR as well as a site, they could get a large block from which they can assign a /48 to each employee as well as to their own network. Thus, their enterprise network would be as much a site as the homes of the employees, even though it provides transit to them. But this is already done today, isn't it? We (SWITCH) hold a /32 as LIR but our network (which I consider to be a site) is a /48 out of that block. > (A viable solution would be to give every LIR a /20. But last time I > proposed that, people were Not Amused, accused me of wasting address > space and flatly refused to accept that as a new policy...) That seems to be the dilemma: on the one hand, we should be a lot more liberal if we want to implement the recommendations of RFC3177. On the other hand, we are very reluctant to do that as long as we don't have very strong arguments that such a policy will actually work in the long run. Alex -- __________ SWITCH - The Swiss Education and Research Network __________ Alexander Gall, SWITCH, Limmatquai 138, CH-8001 Zurich, Switzerland gall at switch.ch Tel: +41 1 268 1522 Fax: +41 1 268 1568 From Ronald.vanderPol at rvdp.org Wed Jan 15 11:38:40 2003 From: Ronald.vanderPol at rvdp.org (Ronald van der Pol) Date: Wed, 15 Jan 2003 11:38:40 +0100 Subject: [lir-wg] IPv6 assignments to RIPE itself In-Reply-To: <20030114101227.S15927@Space.Net> References: <20030114101227.S15927@Space.Net> Message-ID: <20030115103840.GA5806@rvdp.org> On Tue, Jan 14, 2003 at 10:12:27 +0100, Gert Doering wrote: > I tend to agree with you. The /42 has been sub-allocated from Surfnet > to the RIPE NCC (the NCC being "Just any Surfnet customer" here, not > acting in their function as RIR). But RIPE NCC as RIR did approve it according to 5.4.2 of ripe-246. How many hats does RIPE NCC have in this case :-) rvdp From Ronald.vanderPol at rvdp.org Wed Jan 15 12:11:03 2003 From: Ronald.vanderPol at rvdp.org (Ronald van der Pol) Date: Wed, 15 Jan 2003 12:11:03 +0100 Subject: [lir-wg] IPv6 assignments to RIPE itself In-Reply-To: <20030114140635.Z15927@Space.Net> References: <00A19F50.D230372A.15@cc.univie.ac.at> <000e01c2bbc5$201e8e20$534510ac@cyan> <20030114140635.Z15927@Space.Net> Message-ID: <20030115111103.GB5806@rvdp.org> On Tue, Jan 14, 2003 at 14:06:35 +0100, Gert Doering wrote: > Of course this isn't helpful, as a home/DSL/tunnel user might want to > use *two* networks, or *three*, but will never use more than 16 - and > such a /60 is just perfect for them (I have considered doing the same > for our dialup DSL customers). Be careful about "will never use more than 16" :-) In the future, home users may wish to give each family member a couple of /64s to carry around with them as their personal networks (PANs). There are plenty of /48s. Address conservation is not an issue with IPv6 (although address hierarchy is). xDSL and FTTH customers will get their /48 from an ISP. When that ISP has used up its /32, it can get another address block from the RIR. Companies and universities are another thing. Usually, they are not ISPs. However, if they provide xDSL, fiber or whatever connections to their employees or students, they _are_ ISPs and should have address space to use for that. If they are not ISPs, why would they assign a prefix to their employees or students? Maybe in the short term, when that's the only way to get IPv6 connectivity. But after that? For a VPN? I suppose a single /64 should be enough for that. rvdp From matthew.ford at bt.com Wed Jan 15 12:25:12 2003 From: matthew.ford at bt.com (matthew.ford at bt.com) Date: Wed, 15 Jan 2003 11:25:12 -0000 Subject: [lir-wg] IPv6 assignments to RIPE itself Message-ID: <7497DCA1C240C042B28F6657ADFD8E0963FE72@i2km11-ukbr.domain1.systemhost.net> > -----Original Message----- > From: Alexander Gall [mailto:gall at switch.ch] > Sent: 15 January 2003 09:15 > To: Gert Doering > Cc: Stephane Bortzmeyer; Jeroen Massar; 'Wilfried Woeber, > UniVie/ACOnet'; lir-wg at ripe.net > Subject: Re: [lir-wg] IPv6 assignments to RIPE itself > > > [Probably opening a can of worms here...] Yuk, worms taste bad .... ;-) > I agree. The numerics in section 4 of RFC3177 assume that the top 45 > bits in 2000::/3 can be utilized with an H ratio of 0.25 (giving on > the order of 10^11 /48). IMHO, the problem with the current > allocation policy is that it is a lot more conservative than RFC3177 > suggests while still holding on to the /48-for-everybody rule. The > relatively small LIR allocations create a level of scarcity in the > number of /48's, which is enough to make people believe that giving a > student as much address space as her entire University is just crazy. > However, the whole point of RFC3177 was that this should be completely > irrelevant. It *is* completely irrelevant. Allocate /48s, exhaust existing RIR allocation, get more addresses from RIR. I don't see the problem. -- Mat. From leo at ripe.net Wed Jan 15 12:37:24 2003 From: leo at ripe.net (leo vegoda) Date: Wed, 15 Jan 2003 12:37:24 +0100 Subject: [lir-wg] IPv6 assignments to RIPE itself In-Reply-To: <20030115103840.GA5806@rvdp.org> References: <20030114101227.S15927@Space.Net> <20030115103840.GA5806@rvdp.org> Message-ID: Hi Ronald, Ronald van der Pol writes >On Tue, Jan 14, 2003 at 10:12:27 +0100, Gert Doering wrote: > >> I tend to agree with you. The /42 has been sub-allocated from Surfnet >> to the RIPE NCC (the NCC being "Just any Surfnet customer" here, not >> acting in their function as RIR). > >But RIPE NCC as RIR did approve it according to 5.4.2 of ripe-246. >How many hats does RIPE NCC have in this case :-) This is not the case. Each assignment has been made to a separate organisation. There is a single assignment for the RIPE NCC. There is a separate assignment for the RIPE meeting. RIPE is not the same as the RIPE NCC. Similarly, assignments made to employees' home networks are to separate End Users and not the RIPE NCC. Each assignment within the allocation is to a separate End Site. Regards, -- leo vegoda RIPE NCC Registration Services From shane at ripe.net Wed Jan 15 13:05:46 2003 From: shane at ripe.net (Shane Kerr) Date: Wed, 15 Jan 2003 13:05:46 +0100 Subject: [db-wg] RE: [lir-wg] should aut-num object for IPv4 & IPv6 be the same? In-Reply-To: <979C13511BD16947AC758DB50A546B7FA4DA93@i2km10-ukbr.domain1.systemhost.net> References: <979C13511BD16947AC758DB50A546B7FA4DA93@i2km10-ukbr.domain1.systemhost.net> Message-ID: <20030115120546.GB21492@x17.ripe.net> [ Note that I've changed the "Reply-to:" to rpslng at ripe.net in an effort to move this discussion to the most appropriate list. Further discussion should (hopefully) occur in that forum. ] On 2003-01-15 09:51:02 -0000, adrian.pauling at bt.com wrote: > we have 'inet6num' objects separate to 'inetnum' to distinguish IPv6 > address assignments from IPv4. > > Is the question should different 'peering-set' 'route' objects etc > reflect different peerings for IPv6 from IPv4 that an assigned AS > can have? This scenario is real as I can easily give a current > (enterprise LIR) example. Short answer: You should be able to define different peerings for IPv4 and IPv6 networks with RPSLng. Long answer: When extending RPSL to deal with IPv6 (and multicasting) there were two kinds of objects to consider. For most objects, IP information was encoded in attributes. To handle these, new attributes were added to allow IPv6 and multicast information to be defined in existing objects. RPSL specifies that if there is an unknown attribute it should be ignored - this allows backwards compatibility. These basically work like the old definitions, but they allow for IPv6 and multicast information. So with RPSLng there are these new attributes: mp-import: mp-export: mp-default: mp-members: mp-filter: mp-peering: mp-peer: For route definitions, the IPv4 network advertisement is actually in the key of the class, so it could not be changed without breaking compatibility. Therefore the route6 class was introduced. It is very close to the IPv4 route definition: route6: fe80::2b0:d0ff:feed:39e1/128 . . . origin: AS3333 . . . This is all in the draft: http://www.ietf.org/internet-drafts/draft-damas-rpslng-00.txt -- Shane Kerr RIPE NCC From gert at space.net Wed Jan 15 13:56:18 2003 From: gert at space.net (Gert Doering) Date: Wed, 15 Jan 2003 13:56:18 +0100 Subject: [lir-wg] IPv6 assignments to RIPE itself In-Reply-To: <7497DCA1C240C042B28F6657ADFD8E0963FE72@i2km11-ukbr.domain1.systemhost.net>; from matthew.ford@bt.com on Wed, Jan 15, 2003 at 11:25:12AM -0000 References: <7497DCA1C240C042B28F6657ADFD8E0963FE72@i2km11-ukbr.domain1.systemhost.net> Message-ID: <20030115135618.X15927@Space.Net> Hi, On Wed, Jan 15, 2003 at 11:25:12AM -0000, matthew.ford at bt.com wrote: > Allocate /48s, exhaust existing RIR allocation, get more addresses from RIR. > > I don't see the problem. The current way that the RIRs and IANA allocates space *is* a problem, because it leads to "multiple prefixes per LIR", which is bad bad bad bad. Alexander Gall has summarized it pretty well - if we want to give out /48s freely, then the quite conservative RIR->LIR allocation policy currently in place *hurts*. As for the argument "are universities ISPs"? Yes, at least over here, a fair number of them are providing IP connectivity to the student's hostels via leased line/ethernet, and to all other students via ISDN/Modem dialup. So for all address management purposes, they are ISPs. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55593 (55180) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From Ronald.vanderPol at rvdp.org Wed Jan 15 13:59:35 2003 From: Ronald.vanderPol at rvdp.org (Ronald van der Pol) Date: Wed, 15 Jan 2003 13:59:35 +0100 Subject: [lir-wg] IPv6 assignments to RIPE itself In-Reply-To: References: <20030114101227.S15927@Space.Net> <20030115103840.GA5806@rvdp.org> Message-ID: <20030115125935.GC5806@rvdp.org> On Wed, Jan 15, 2003 at 12:37:24 +0100, leo vegoda wrote: > Hi Ronald, > > Ronald van der Pol writes > >On Tue, Jan 14, 2003 at 10:12:27 +0100, Gert Doering wrote: > > > >> I tend to agree with you. The /42 has been sub-allocated from Surfnet > >> to the RIPE NCC (the NCC being "Just any Surfnet customer" here, not > >> acting in their function as RIR). > > > >But RIPE NCC as RIR did approve it according to 5.4.2 of ripe-246. > >How many hats does RIPE NCC have in this case :-) > > This is not the case. Each assignment has been made to a separate > organisation. There is a single assignment for the RIPE NCC. There is a > separate assignment for the RIPE meeting. RIPE is not the same as the > RIPE NCC. > > Similarly, assignments made to employees' home networks are to separate > End Users and not the RIPE NCC. > > Each assignment within the allocation is to a separate End Site. This all happened when I already left surfnet. So I don't know the details. But this sounds strange. Are you saying surfnet assigned /48s directly to RIPE NCC employees? I suppose surfnet dealt with one customer, RIPE NCC, and assigned several /48s to it. BTW, I agree RIPE* is special. I can understand the need for separate /48s for the RIPE NCC office and the RIPE meetings. However, I would expect RIPE NCC employees to get /64s from the RIPE NCC /48 or get a /48 from their home ISP. rvdp From gert at space.net Wed Jan 15 14:11:14 2003 From: gert at space.net (Gert Doering) Date: Wed, 15 Jan 2003 14:11:14 +0100 Subject: [lir-wg] IPv6 assignments to RIPE itself In-Reply-To: <20030115125935.GC5806@rvdp.org>; from Ronald.vanderPol@rvdp.org on Wed, Jan 15, 2003 at 01:59:35PM +0100 References: <20030114101227.S15927@Space.Net> <20030115103840.GA5806@rvdp.org> <20030115125935.GC5806@rvdp.org> Message-ID: <20030115141114.B15927@Space.Net> Hi, On Wed, Jan 15, 2003 at 01:59:35PM +0100, Ronald van der Pol wrote: > BTW, I agree RIPE* is special. I can understand the need for separate > /48s for the RIPE NCC office and the RIPE meetings. Why? Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55593 (55180) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From Ronald.vanderPol at rvdp.org Wed Jan 15 14:15:42 2003 From: Ronald.vanderPol at rvdp.org (Ronald van der Pol) Date: Wed, 15 Jan 2003 14:15:42 +0100 Subject: [lir-wg] IPv6 assignments to RIPE itself In-Reply-To: <20030115135618.X15927@Space.Net> References: <7497DCA1C240C042B28F6657ADFD8E0963FE72@i2km11-ukbr.domain1.systemhost.net> <20030115135618.X15927@Space.Net> Message-ID: <20030115131541.GD5806@rvdp.org> On Wed, Jan 15, 2003 at 13:56:18 +0100, Gert Doering wrote: > Alexander Gall has summarized it pretty well - if we want to give out > /48s freely, then the quite conservative RIR->LIR allocation policy > currently in place *hurts*. Very true if you mean that you cannot build a reasonable hierarchy. > As for the argument "are universities ISPs"? Yes, at least over here, > a fair number of them are providing IP connectivity to the student's > hostels via leased line/ethernet, and to all other students via ISDN/Modem > dialup. So for all address management purposes, they are ISPs. This is true in the Netherlands too. Yes, I think those should be treated as ISPs, probably getting a prefix (>> /48) from their NRN. rvdp From Ronald.vanderPol at rvdp.org Wed Jan 15 14:21:54 2003 From: Ronald.vanderPol at rvdp.org (Ronald van der Pol) Date: Wed, 15 Jan 2003 14:21:54 +0100 Subject: [lir-wg] IPv6 assignments to RIPE itself In-Reply-To: <20030115141114.B15927@Space.Net> References: <20030114101227.S15927@Space.Net> <20030115103840.GA5806@rvdp.org> <20030115125935.GC5806@rvdp.org> <20030115141114.B15927@Space.Net> Message-ID: <20030115132153.GE5806@rvdp.org> On Wed, Jan 15, 2003 at 14:11:14 +0100, Gert Doering wrote: > Hi, > > On Wed, Jan 15, 2003 at 01:59:35PM +0100, Ronald van der Pol wrote: > > BTW, I agree RIPE* is special. I can understand the need for separate > > /48s for the RIPE NCC office and the RIPE meetings. > > Why? As Leo already explained: RIPE != RIPE NCC. I see the usefulness of a /48 that travels along with the RIPE meetings. As far as I know, this /48 always has the same upstream (the RIPE _NCC_ office) by means of a v6-in-v4 tunnel. When native v6 connectivity will be widely available at meeting sites, this might change. rvdp From aid at vianw.net Wed Jan 15 12:40:09 2003 From: aid at vianw.net (Adrian Bool) Date: Wed, 15 Jan 2003 11:40:09 +0000 (GMT) Subject: [lir-wg] IPv6 assignments to RIPE itself In-Reply-To: <7497DCA1C240C042B28F6657ADFD8E0963FE72@i2km11-ukbr.domain1.systemhost.net> Message-ID: On Wed, 15 Jan 2003 matthew.ford at bt.com wrote: > It *is* completely irrelevant. > > Allocate /48s, exhaust existing RIR allocation, get more addresses from RIR. > > I don't see the problem. We're supposed to be conserving route announcements too... IP address space is not the only issue. aid -- Adrian Bool | http://noc.vianw.net/ Director, Global Core Network | tel://+44.1925.484061/ VIA NET.WORKS Inc. | noc://+49.203.3093.1111/ From woeber at cc.univie.ac.at Wed Jan 15 14:41:13 2003 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 15 Jan 2003 14:41:13 +0100 Subject: [lir-wg] IPv6 assignments to RIPE itself Message-ID: <00A1A02C.9DA312CA.27@cc.univie.ac.at> >> Alexander Gall has summarized it pretty well - if we want to give out >> /48s freely, then the quite conservative RIR->LIR allocation policy >> currently in place *hurts*. > >Very true if you mean that you cannot build a reasonable hierarchy. Actually, this is the thing that makes the use of the /42 block out of SURFnet's sTLA to RIPE (Meeting et.al.), The NCC and the employees interesting: I do see it as people actually trying to _live_ and document that hierarchy - LIR => RIPE NCC (status: ALLOCATED-BY-LIR) => various assignments by the RIPE NCC. >> As for the argument "are universities ISPs"? Yes, at least over here, >> a fair number of them are providing IP connectivity to the student's >> hostels via leased line/ethernet, and to all other students via ISDN/Modem >> dialup. So for all address management purposes, they are ISPs. > >This is true in the Netherlands too. Same here. We even operate our own ADSL gear on-site for connecting hostels, students, etc. >Yes, I think those should be treated >as ISPs, probably getting a prefix (>> /48) from their NRN. That's something we are trying to get a feeling for at the moment. My approach for _now_ is to treat a University's (extended) LAN as one site (i.e. lives within 1 /48), and the hostels and remote customers' (students and faculty) networks as a site (/48 typically or /64 in special circumstances) each. As regards the address distribution procedures I still maintain that there is no technical or logical difference between a university's "customer" which happens to be staff or student as compared to a "regular" customer serviced by a "commercial" ISP. Also, the technology used to ship IPv6 packets should be irrelevant for this discussion, i.e. a native link or an IPv6 in IPv4 tunnel to such a network doesn't make a difference. > rvdp Btw, regarding the discussion of what a "site" is - my current interpretation here is that a "site" is the entity I am talking to with regard to network planning and address space management. And if that entity most probably uses more than a singel subnet, then I usually stick to the /48 recommendation. Wilfried. _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber at CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From gert at space.net Wed Jan 15 14:49:37 2003 From: gert at space.net (Gert Doering) Date: Wed, 15 Jan 2003 14:49:37 +0100 Subject: [lir-wg] IPv6 assignments to RIPE itself In-Reply-To: <20030115131541.GD5806@rvdp.org>; from Ronald.vanderPol@rvdp.org on Wed, Jan 15, 2003 at 02:15:42PM +0100 References: <7497DCA1C240C042B28F6657ADFD8E0963FE72@i2km11-ukbr.domain1.systemhost.net> <20030115135618.X15927@Space.Net> <20030115131541.GD5806@rvdp.org> Message-ID: <20030115144937.C15927@Space.Net> Hi, On Wed, Jan 15, 2003 at 02:15:42PM +0100, Ronald van der Pol wrote: > On Wed, Jan 15, 2003 at 13:56:18 +0100, Gert Doering wrote: > > > Alexander Gall has summarized it pretty well - if we want to give out > > /48s freely, then the quite conservative RIR->LIR allocation policy > > currently in place *hurts*. > Very true if you mean that you cannot build a reasonable hierarchy. Yup. This is mostly the point behind my rantings. Trying to build a resonable hierarchy through some levels of regional aggregation inside my network, and then aggregation through 1-2 levels of resellers. The other point is that one of the main arguments in that RFC is "if a customer changes ISPs, they will always get the same size prefix (a /48)", which is just not working if customers can very liberally get more than a /48 to account for "another-level-down end sites". So we're back to the address space haggling days, just argueing about the number of /48s instead the number of single IPs. So I still think that the concept of "one /48 for each site" without a proper definition of "site" is flawed. And yes, it's arguably pretty impossible to give a working definiton. > > As for the argument "are universities ISPs"? Yes, at least over here, > > a fair number of them are providing IP connectivity to the student's > > hostels via leased line/ethernet, and to all other students via ISDN/Modem > > dialup. So for all address management purposes, they are ISPs. > > This is true in the Netherlands too. Yes, I think those should be treated > as ISPs, probably getting a prefix (>> /48) from their NRN. See above :-) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55593 (55180) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From gert at space.net Wed Jan 15 14:52:34 2003 From: gert at space.net (Gert Doering) Date: Wed, 15 Jan 2003 14:52:34 +0100 Subject: [lir-wg] IPv6 assignments to RIPE itself In-Reply-To: <20030115132153.GE5806@rvdp.org>; from Ronald.vanderPol@rvdp.org on Wed, Jan 15, 2003 at 02:21:54PM +0100 References: <20030114101227.S15927@Space.Net> <20030115103840.GA5806@rvdp.org> <20030115125935.GC5806@rvdp.org> <20030115141114.B15927@Space.Net> <20030115132153.GE5806@rvdp.org> Message-ID: <20030115145234.D15927@Space.Net> Hi, On Wed, Jan 15, 2003 at 02:21:54PM +0100, Ronald van der Pol wrote: > On Wed, Jan 15, 2003 at 14:11:14 +0100, Gert Doering wrote: > > On Wed, Jan 15, 2003 at 01:59:35PM +0100, Ronald van der Pol wrote: > > > BTW, I agree RIPE* is special. I can understand the need for separate > > > /48s for the RIPE NCC office and the RIPE meetings. > > > > Why? > > As Leo already explained: RIPE != RIPE NCC. I see the usefulness of > a /48 that travels along with the RIPE meetings. As far as I know, > this /48 always has the same upstream (the RIPE _NCC_ office) by > means of a v6-in-v4 tunnel. And exactly this is the reason why I don't see the need for a second /48. The only network connectivity of the meeting network is through the RIPE NCC office, which will be the aggregation point for all internal subnetworks, and everything connected through it. As long as we do not use something like a /50 on the RIPE meetings (but more like "one /64"), and there is no native connectivity available locally, I see no compelling reason to go for a separate /48. > When native v6 connectivity will be > widely available at meeting sites, this might change. Indeed, because in those cases, there's even less reason for a statically allocated /48 for "RIPE meeting" - the meeting network should use upstream space. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55593 (55180) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From s.willing at mops.net Wed Jan 15 14:58:25 2003 From: s.willing at mops.net (Sebastian Willing) Date: Wed, 15 Jan 2003 14:58:25 +0100 (CET) Subject: [lir-wg] IPv6 assignments to RIPE itself In-Reply-To: <20030115144937.C15927@Space.Net> from "Gert Doering" at Jan 15, 2003 02:49:37 PM Message-ID: <200301151358.OAA22452@mara.mops.net> Hello! Gert Doering wrote: [...] > The other point is that one of the main arguments in that RFC is "if a > customer changes ISPs, they will always get the same size prefix (a /48)", > which is just not working if customers can very liberally get more than > a /48 to account for "another-level-down end sites". So we're back to > the address space haggling days, just argueing about the number of /48s > instead the number of single IPs. [...] A /48 isn't the same as an v4-IP. Using a /48, one has 65536 different /64-IPs which is really enough for most applications. Less people will request more than one /48 this way and it is and should be the job of the LIR to filter these who want as many IPs as possible just for fun. MfG / Regards, S.Willing ************************************************************************ M / W / S Sebastian Willing http://www.mops.net Technical director Telefon: 01803/684310578 e-Mail: s.willing at mops.net Telefax: 01805/445169111 SW88-RIPE ************************************************************************ From woeber at cc.univie.ac.at Wed Jan 15 15:07:57 2003 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 15 Jan 2003 15:07:57 +0100 Subject: [lir-wg] IPv6 assignments to RIPE itself Message-ID: <00A1A030.59ABCB3A.26@cc.univie.ac.at> Sorry, Gert, >> As Leo already explained: RIPE != RIPE NCC. I see the usefulness of >> a /48 that travels along with the RIPE meetings. As far as I know, >> this /48 always has the same upstream (the RIPE _NCC_ office) by >> means of a v6-in-v4 tunnel. > >And exactly this is the reason why I don't see the need for a second /48. I don't get your point here. What are you trying to salvage? 1x /48 out of SURFnet's sTLA or 1x /48 out of the /42 or ?? Wilfried. From gert at space.net Wed Jan 15 15:27:04 2003 From: gert at space.net (Gert Doering) Date: Wed, 15 Jan 2003 15:27:04 +0100 Subject: [lir-wg] IPv6 assignments to RIPE itself In-Reply-To: <200301151358.OAA22452@mara.mops.net>; from s.willing@mops.net on Wed, Jan 15, 2003 at 02:58:25PM +0100 References: <20030115144937.C15927@Space.Net> <200301151358.OAA22452@mara.mops.net> Message-ID: <20030115152704.E15927@Space.Net> Hi, On Wed, Jan 15, 2003 at 02:58:25PM +0100, Sebastian Willing wrote: > Gert Doering wrote: > [...] > > The other point is that one of the main arguments in that RFC is "if a > > customer changes ISPs, they will always get the same size prefix (a /48)", > > which is just not working if customers can very liberally get more than > > a /48 to account for "another-level-down end sites". So we're back to > > the address space haggling days, just argueing about the number of /48s > > instead the number of single IPs. > [...] > > A /48 isn't the same as an v4-IP. I'm aware of that. > Using a /48, one has 65536 different /64-IPs > which is really enough for most applications. Less people will request more > than one /48 this way and it is and should be the job of the LIR to filter > these who want as many IPs as possible just for fun. The design of the policy is "give everybody a /48 without asking" so that there is no *need* for discussion, weeding out "unwarranted applications" and "if you don't give it to me, I go to $otherisp who will!". This contradicts the so-far result of the ongoing discussion, which is "if someone has some sort of semi-independent networks connected, they can get a /48 on their own, so the upstream has to get more space"... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55593 (55180) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From gert at space.net Wed Jan 15 15:37:27 2003 From: gert at space.net (Gert Doering) Date: Wed, 15 Jan 2003 15:37:27 +0100 Subject: [lir-wg] IPv6 assignments to RIPE itself In-Reply-To: <20030115141023.GF5806@rvdp.org>; from Ronald.vanderPol@rvdp.org on Wed, Jan 15, 2003 at 03:10:23PM +0100 References: <7497DCA1C240C042B28F6657ADFD8E0963FE72@i2km11-ukbr.domain1.systemhost.net> <20030115135618.X15927@Space.Net> <20030115131541.GD5806@rvdp.org> <20030115144937.C15927@Space.Net> <20030115141023.GF5806@rvdp.org> Message-ID: <20030115153727.F15927@Space.Net> Hi, On Wed, Jan 15, 2003 at 03:10:23PM +0100, Ronald van der Pol wrote: > On Wed, Jan 15, 2003 at 14:49:37 +0100, Gert Doering wrote: > > > The other point is that one of the main arguments in that RFC is "if a > > customer changes ISPs, they will always get the same size prefix (a /48)", > > which is just not working if customers can very liberally get more than > > a /48 to account for "another-level-down end sites". So we're back to > > the address space haggling days, just argueing about the number of /48s > > instead the number of single IPs. > > I don't agree. It's not just a customer. It's an ISP. If an ISP wants > to switch from upstream provider, that's a big job. And some negotiation > about prefix delegation is part of that. > > _End_ customers will get a /48. If they change ISP, they get a /48 again. > > Really big enterprise (end) customers with two or three /48s are not > guaranteed to get the same amount of /48s from a new ISP. But I guess > they will have a strong negotiating position. Just calling those parties ISPs will not solve the dilemma. A big company that wants to give IP connectivity to their employees (like the RIPE NCC does) is not an "ISP" in the classic sense, as it's not their main business. On the other hand, if you call everybody that happens to offer an ISDN S0 for dialup to their employees purposes an ISP, then most of our business customers could be called ISPs - which defeats the "one /48 for end sites" rule again. Of course there are some customers that make their money doing ISP business (that is: give paying customers who are different legal entities (!) access to the internet), and I have no problem with them getting a /36 or whatever. The problem is the class of customers like the RIPE NCC. > > So I still think that the concept of "one /48 for each site" without a > > proper definition of "site" is flawed. And yes, it's arguably pretty > > impossible to give a working definiton. > > Yes, that's true. But "end customer" <--> "ISP" relations are pretty > clear. Those will have /48 assignments. Well, for those "end customers" that are "end customers", assigning them a /48 is covered pretty clearly by the current policy. I still don't think that it's very easy to define a given business relation as "this is an end-end-end customer", and "that is an ISP". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55593 (55180) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From gert at space.net Wed Jan 15 15:40:08 2003 From: gert at space.net (Gert Doering) Date: Wed, 15 Jan 2003 15:40:08 +0100 Subject: [lir-wg] IPv6 assignments to RIPE itself In-Reply-To: <00A1A030.59ABCB3A.26@cc.univie.ac.at>; from woeber@cc.univie.ac.at on Wed, Jan 15, 2003 at 03:07:57PM +0100 References: <00A1A030.59ABCB3A.26@cc.univie.ac.at> Message-ID: <20030115154008.G15927@Space.Net> Hi, On Wed, Jan 15, 2003 at 03:07:57PM +0100, Wilfried Woeber, UniVie/ACOnet wrote: > >> As Leo already explained: RIPE != RIPE NCC. I see the usefulness of > >> a /48 that travels along with the RIPE meetings. As far as I know, > >> this /48 always has the same upstream (the RIPE _NCC_ office) by > >> means of a v6-in-v4 tunnel. > > > >And exactly this is the reason why I don't see the need for a second /48. > > I don't get your point here. What are you trying to salvage? > 1x /48 out of SURFnet's sTLA or 1x /48 out of the /42 or ?? I want to clarify policy. The policy says "one end customer gets ONE /48 (except if they are so big that they need more address space)". I don't want to conserve anything here, and I don't really mind if the NCC uses a /42 - I'm just being nasty on purpose to point out problems in the current set of policy definitions. Whatever the outcome of this discussion will be, I hope that it will lead to some more understanding of the way address distribution should be done. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55593 (55180) 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 Wed Jan 15 15:40:00 2003 From: he at uninett.no (Havard Eidnes) Date: Wed, 15 Jan 2003 15:40:00 +0100 (CET) Subject: [lir-wg] IPv6 assignments to RIPE itself In-Reply-To: <20030115135618.X15927@Space.Net> References: <7497DCA1C240C042B28F6657ADFD8E0963FE72@i2km11-ukbr.domain1.systemhost.net> <20030115135618.X15927@Space.Net> Message-ID: <20030115.154000.06640922.he@uninett.no> > The current way that the RIRs and IANA allocates space *is* a problem, > because it leads to "multiple prefixes per LIR", which is bad bad bad bad. I agree if the resulting address blocks can not be announced as a single aggregate. I was, however, under the impression that when a RIR makes an IPv6 allocation to a LIR, it leaves "room to grow" in the address space, so that some of the subsequent allocations can still be announced with a single routing announcement. This is different to the practices used in the IPv4 space, partly, I guess, because there is room to use that practice. Did this change and/or am I mis-remembering? Regards, - H?vard From matthew.ford at bt.com Wed Jan 15 15:42:48 2003 From: matthew.ford at bt.com (matthew.ford at bt.com) Date: Wed, 15 Jan 2003 14:42:48 -0000 Subject: [lir-wg] IPv6 assignments to RIPE itself Message-ID: <7497DCA1C240C042B28F6657ADFD8E0963FE76@i2km11-ukbr.domain1.systemhost.net> Hi, See below... -----Original Message----- From: Gert Doering [mailto:gert at space.net] Sent: Wed 15/01/2003 12:56 To: Ford,M,Mat,DEN5 FORDM5 R Cc: gall at switch.ch; gert at space.net; bortzmeyer at gitoyen.net; jeroen at unfix.org; woeber at cc.univie.ac.at; lir-wg at ripe.net Subject: Re: [lir-wg] IPv6 assignments to RIPE itself Hi, On Wed, Jan 15, 2003 at 11:25:12AM -0000, matthew.ford at bt.com wrote: > Allocate /48s, exhaust existing RIR allocation, get more addresses from RIR. > > I don't see the problem. The current way that the RIRs and IANA allocates space *is* a problem, because it leads to "multiple prefixes per LIR", which is bad bad bad bad. => which is why ripe-261 is being developed. Mat. From gert at space.net Wed Jan 15 15:48:04 2003 From: gert at space.net (Gert Doering) Date: Wed, 15 Jan 2003 15:48:04 +0100 Subject: [lir-wg] IPv6 assignments to RIPE itself In-Reply-To: <20030115.154000.06640922.he@uninett.no>; from he@uninett.no on Wed, Jan 15, 2003 at 03:40:00PM +0100 References: <7497DCA1C240C042B28F6657ADFD8E0963FE72@i2km11-ukbr.domain1.systemhost.net> <20030115135618.X15927@Space.Net> <20030115.154000.06640922.he@uninett.no> Message-ID: <20030115154804.H15927@Space.Net> Hi, On Wed, Jan 15, 2003 at 03:40:00PM +0100, Havard Eidnes wrote: > > The current way that the RIRs and IANA allocates space *is* a problem, > > because it leads to "multiple prefixes per LIR", which is bad bad bad bad. > > I agree if the resulting address blocks can not be announced as a > single aggregate. > > I was, however, under the impression that when a RIR makes an IPv6 > allocation to a LIR, it leaves "room to grow" in the address space, so > that some of the subsequent allocations can still be announced with a > single routing announcement. This is different to the practices used > in the IPv4 space, partly, I guess, because there is room to use that > practice. Did this change and/or am I mis-remembering? RIPE allocates the /32 out of a reserved /29. Which leaves quite some amount to grow, but I still think the whole distribution down from the top is still too much based on conservation-and-slow-start-thinking. Why are we messing around with /23s being given from IANA to the RIRs in the first place? That way, filtering by region will quicky get REALLY messy, and I really can't see any useful reason to do so. A useful way would be to do /12s or so (IPv4 does /8s, since we're only operating in 001 the equivalent would be a /11, and nibble-aligning gives a /12). Or maybe a /16, which looks much nicer. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55593 (55180) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From Ronald.vanderPol at rvdp.org Wed Jan 15 15:48:06 2003 From: Ronald.vanderPol at rvdp.org (Ronald van der Pol) Date: Wed, 15 Jan 2003 15:48:06 +0100 Subject: [lir-wg] IPv6 assignments to RIPE itself In-Reply-To: <00A1A02C.9DA312CA.27@cc.univie.ac.at> References: <00A1A02C.9DA312CA.27@cc.univie.ac.at> Message-ID: <20030115144806.GG5806@rvdp.org> On Wed, Jan 15, 2003 at 14:41:13 +0100, Wilfried Woeber, UniVie/ACOnet wrote: > That's something we are trying to get a feeling for at the moment. > My approach for _now_ is to treat a University's (extended) LAN as one > site (i.e. lives within 1 /48), and the hostels and remote customers' > (students and faculty) networks as a site (/48 typically or /64 in > special circumstances) each. You mean each "remote customers' network" will get its own /48, right? Does it matter how long the fibers are (or, does "remote" matter)? If a university is spread around a region, but is one administrative entity ("""site""" :-), it will use one /48 for its network. That network may stretch to remote faculties and buildings and to student dormitories. Students and employees get one /64. That's sounds like a reasonable approach too. > As regards the address distribution procedures I still maintain that > there is no technical or logical difference between a university's > "customer" which happens to be staff or student as compared to a > "regular" customer serviced by a "commercial" ISP. So they should all get a /48? Then the university is assigning /48s and is an ISP. That's another reasonable approach. rvdp From Ronald.vanderPol at rvdp.org Wed Jan 15 15:10:23 2003 From: Ronald.vanderPol at rvdp.org (Ronald van der Pol) Date: Wed, 15 Jan 2003 15:10:23 +0100 Subject: [lir-wg] IPv6 assignments to RIPE itself In-Reply-To: <20030115144937.C15927@Space.Net> References: <7497DCA1C240C042B28F6657ADFD8E0963FE72@i2km11-ukbr.domain1.systemhost.net> <20030115135618.X15927@Space.Net> <20030115131541.GD5806@rvdp.org> <20030115144937.C15927@Space.Net> Message-ID: <20030115141023.GF5806@rvdp.org> On Wed, Jan 15, 2003 at 14:49:37 +0100, Gert Doering wrote: > The other point is that one of the main arguments in that RFC is "if a > customer changes ISPs, they will always get the same size prefix (a /48)", > which is just not working if customers can very liberally get more than > a /48 to account for "another-level-down end sites". So we're back to > the address space haggling days, just argueing about the number of /48s > instead the number of single IPs. I don't agree. It's not just a customer. It's an ISP. If an ISP wants to switch from upstream provider, that's a big job. And some negotiation about prefix delegation is part of that. _End_ customers will get a /48. If they change ISP, they get a /48 again. Really big enterprise (end) customers with two or three /48s are not guaranteed to get the same amount of /48s from a new ISP. But I guess they will have a strong negotiating position. > So I still think that the concept of "one /48 for each site" without a > proper definition of "site" is flawed. And yes, it's arguably pretty > impossible to give a working definiton. Yes, that's true. But "end customer" <--> "ISP" relations are pretty clear. Those will have /48 assignments. rvdp From Ronald.vanderPol at rvdp.org Wed Jan 15 16:27:59 2003 From: Ronald.vanderPol at rvdp.org (Ronald van der Pol) Date: Wed, 15 Jan 2003 16:27:59 +0100 Subject: [lir-wg] IPv6 assignments to RIPE itself In-Reply-To: <20030115153727.F15927@Space.Net> References: <7497DCA1C240C042B28F6657ADFD8E0963FE72@i2km11-ukbr.domain1.systemhost.net> <20030115135618.X15927@Space.Net> <20030115131541.GD5806@rvdp.org> <20030115144937.C15927@Space.Net> <20030115141023.GF5806@rvdp.org> <20030115153727.F15927@Space.Net> Message-ID: <20030115152759.GH5806@rvdp.org> On Wed, Jan 15, 2003 at 15:37:27 +0100, Gert Doering wrote: > Just calling those parties ISPs will not solve the dilemma. A big company > that wants to give IP connectivity to their employees (like the RIPE NCC > does) is not an "ISP" in the classic sense, as it's not their main > business. > > On the other hand, if you call everybody that happens to offer an ISDN S0 > for dialup to their employees purposes an ISP, then most of our business > customers could be called ISPs - which defeats the "one /48 for end sites" > rule again. I agree. Maybe the difference is how the home network is connected? For most people, the normal conenctivity is via traditional ISPs. They get a /48 from that ISP. They may also have some kind of connectivity (VPN or dialup) to their company network. But I think that's mostly used for "secure" access to company services. Usually one /64 out of the company prefix will be enough. The company does not need to assign /48s to its employees. University xDSL, cable and fiber networks are different. Usually, it's the only connectivity for the students or employee. And they prefer to get /48. In this case the university can be seen as an ISP. I think some uncertainty comes from the fact that most ISPs are still not offering IPv6 services and people are trying to get an IPv6 prefix somewhere else. > I still don't think that it's very easy to define a given business > relation as "this is an end-end-end customer", and "that is an ISP". Thinking more about it, I agree. rvdp From leo at ripe.net Wed Jan 15 16:45:04 2003 From: leo at ripe.net (leo vegoda) Date: Wed, 15 Jan 2003 16:45:04 +0100 Subject: [lir-wg] IPv6 assignments to RIPE itself In-Reply-To: <20030115125935.GC5806@rvdp.org> References: <20030114101227.S15927@Space.Net> <20030115103840.GA5806@rvdp.org> <20030115125935.GC5806@rvdp.org> Message-ID: Hi Ronald, Ronald van der Pol writes [...] >This all happened when I already left surfnet. So I don't know the >details. But this sounds strange. Are you saying surfnet assigned >/48s directly to RIPE NCC employees? I suppose surfnet dealt with >one customer, RIPE NCC, and assigned several /48s to it. No, the RIPE NCC received an allocation from Surfnet, as per section 5.3 of the IPv6 policy. The RIPE NCC made /48 assignments from the allocation as per section 5.4.1 of the policy. I hope this clarifies things. Kind regards, -- leo vegoda RIPE NCC Registration Services From Ronald.vanderPol at rvdp.org Wed Jan 15 16:55:20 2003 From: Ronald.vanderPol at rvdp.org (Ronald van der Pol) Date: Wed, 15 Jan 2003 16:55:20 +0100 Subject: [lir-wg] IPv6 assignments to RIPE itself In-Reply-To: References: <20030114101227.S15927@Space.Net> <20030115103840.GA5806@rvdp.org> <20030115125935.GC5806@rvdp.org> Message-ID: <20030115155520.GI5806@rvdp.org> On Wed, Jan 15, 2003 at 16:45:04 +0100, leo vegoda wrote: > No, the RIPE NCC received an allocation from Surfnet, as per section 5.3 > of the IPv6 policy. The RIPE NCC made /48 assignments from the > allocation as per section 5.4.1 of the policy. Ah, you see RIPE NCC as an ISP. I didn't think of that. I feel a "what's an ISP" discussion coming up :-) rvdp From webmaster at keyworld.net Wed Jan 15 18:16:14 2003 From: webmaster at keyworld.net (Chris Ransley) Date: Wed, 15 Jan 2003 18:16:14 +0100 Subject: [lir-wg] 80.x.x.x cannot resolve .zw addresses Message-ID: <539500AAE31E4B4CBDDB67AED88D5833085E55@exchange.keyworld.net> Hi guys, We are having an issue when trying to resolve Zimbabwe address eg: cfs.co.zw, zol.co.zw. I tried on two 80.x.x.x networks. 80.71.96.0 255.255.240.0 & 80.77.192.0 255.255.240.0 Can anyone help? Best Regards, Christian Ransley B.Sc. Web & Technical Services Manager Keyworld Ltd. UB42, Industrial Zone San Gwann SGN 09 Tel: (+356) 2540 2540 Fax: (+356) 2540 9999 Email: webmaster at keyworld.net Website: http://www.keyworld.net From jeroen at unfix.org Wed Jan 15 18:43:59 2003 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 15 Jan 2003 18:43:59 +0100 Subject: [lir-wg] 80.x.x.x cannot resolve .zw addresses In-Reply-To: <539500AAE31E4B4CBDDB67AED88D5833085E55@exchange.keyworld.net> Message-ID: <001f01c2bcbd$afe50d60$210d640a@unfix.org> Chris Ransley wrote: > Hi guys, > > We are having an issue when trying to resolve Zimbabwe address eg: > cfs.co.zw, zol.co.zw. I tried on two 80.x.x.x networks. > > 80.71.96.0 255.255.240.0 & 80.77.192.0 255.255.240.0 You should contact the owners of that netblock not this list ;) But for this you should check http://www.foobar.tm/dns/ fill in the hosts and see where they come out. 8<------------------- Wed Jan 15 17:38:08 UTC 2003 96.71.80.in-addr.arpa NS ns2.keyworld.net ns1.keyworld.net admin.keyworld.net (2002101215 10800 86400 1209600 1800) !!! 96.71.80.in-addr.arpa SOA retry exceeds refresh 96.71.80.in-addr.arpa NS ns1.keyworld.net ns1.keyworld.net admin.keyworld.net (2002101215 10800 86400 1209600 1800 -------------------->8 There could be one problem, use dig and other tools to find out what it is and fix them. As for cfs.co.zw it doesn't exist. Contact your domain registar about that problem. zol.co.zw also has problems: 8<------------------ Wed Jan 15 17:41:51 UTC 2003 zol.co.zw NS ns2.zol.co.zw ns1.zol.co.zw dns-admin.zol.co.zw (2002121701 3600 10 1209600 3600) zol.co.zw NS ns1.zol.co.zw ns1.zol.co.zw dns-admin.zol.co.zw (2002011001 3600 10 1209600 3600) !!! ns1.zol.co.zw and ns2.zol.co.zw have different serial for zol.co.zw ------------------>8 But as said lir-wg is not the place to discuss your/these problems. Check the DNS FAQ's and happy hunting and debugging. Greets, Jeroen From gert at space.net Wed Jan 15 22:19:23 2003 From: gert at space.net (Gert Doering) Date: Wed, 15 Jan 2003 22:19:23 +0100 Subject: [lir-wg] IPv6 assignments to RIPE itself In-Reply-To: <7497DCA1C240C042B28F6657ADFD8E0963FE76@i2km11-ukbr.domain1.systemhost.net>; from matthew.ford@bt.com on Wed, Jan 15, 2003 at 02:42:48PM -0000 References: <7497DCA1C240C042B28F6657ADFD8E0963FE76@i2km11-ukbr.domain1.systemhost.net> Message-ID: <20030115221923.N15927@Space.Net> Hi, On Wed, Jan 15, 2003 at 02:42:48PM -0000, matthew.ford at bt.com wrote: > On Wed, Jan 15, 2003 at 11:25:12AM -0000, matthew.ford at bt.com wrote: > > Allocate /48s, exhaust existing RIR allocation, get more addresses from > RIR. > > > > I don't see the problem. > > The current way that the RIRs and IANA allocates space *is* a problem, > because it leads to "multiple prefixes per LIR", which is bad bad bad bad. > > => which is why ripe-261 is being developed. I'm not fully sure whether I understand this. If I read RIPE-261 correctly, it is only meant to solve the distribution issue IANA -> RIR, which is currently done in chunks of a /23 at a time, leading to fragmentation at the RIR level (and as such is a very good approach). If that interpretation is correct, it won't change the distribution issues concerning the RIR -> LIR hierarchy at all. Of course RIPE could apply a similar algorithm inside their IANA -> RIPE block, but that will only work if the block is large enough, in which case the algorithm really isn't *that* necessary on the IANA -> RIR level in the first place. If, on the other hand, this document is meant to affect the way address space is distributed down to the LIRs, that is "one global pool is used to satisfy all LIR requests all over the world, with no RIR blocks in between", then this will be very bad for by-region aggregation. People *do* want to be able to filter on other-region more-specifics, which is only possible if there *are* per-region blocks. The wording is a bit unclear on which case is correct, but I'm afraid it is meant to be "number 2". Could you (or someone else) shed some light on that? (Hmmm, reading the closing paragraph again, it seems to be a proposal only, not something finally decided yet. Is this on any of the WG's agendas?) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55593 (55180) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From engin at ripe.net Thu Jan 16 16:44:40 2003 From: engin at ripe.net (Engin Gunduz) Date: Thu, 16 Jan 2003 16:44:40 +0100 Subject: [lir-wg] Re: [db-wg] Updated proposal for clean-up of references by name In-Reply-To: <20030114115413.GD18835@x47.ripe.net> References: <20021220104444.GF5138@x47.ripe.net> <20030114115413.GD18835@x47.ripe.net> Message-ID: <20030116154440.GO8449@x47.ripe.net> Dear Colleagues, This message is to report that the operation on TEST and RIPE Whois Databases is now concluded successfully. During the operation on RIPE Database: 1928 inconsistent objects were encountered, 611 dummy person objects were created, 1287 dummy role objects were created, 289 non-existent NIC handles were fixed (corresponding dummy person objects created). The operation on RIPE Database took around two hours, without interruption on database updates or queries. Best regards, Engin Gunduz ____________________________ RIPE NCC Database Group On 2003-01-14 12:54:13 +0100, Engin Gunduz wrote: > [Apologies for duplicate messages] > > Dear Colleagues, > > On 2002-12-20 11:44:44 +0100, Engin Gunduz wrote: > > > > [Apologies for duplicate messages] > > > > Dear Colleagues, > > > > I'm attaching the updated proposal for automatically > > cleaning up the references by name in RIPE Whois Database. > > We have incorporated Janos's suggestions to the proposal. > > > > If no more comments come, we plan to apply the procedure > > described in the proposal in the first half of January, 2003. > > The operation should not take more than a day. We will notify > > the community about the actual date of the operation. > > We plan to perform the clean-up > - on January 15, Wednesday (tomorrow), afternoon (CET) on TEST database, > - on January 16, Thursday, afternoon (CET) on RIPE database. > > The operation will take several hours, however during the operation > the queries and updates will continue as normal. > > Best regards, > > Engin Gunduz > ____________________________ > RIPE NCC Database Group > From axel.pawlik at ripe.net Mon Jan 20 11:46:40 2003 From: axel.pawlik at ripe.net (Axel Pawlik) Date: Mon, 20 Jan 2003 11:46:40 +0100 Subject: [lir-wg] New service: The RIPE NCC LIR Portal Message-ID: <5.2.0.9.2.20030120114441.02219b38@localhost> Dear Colleagues, The RIPE NCC announces the release of the RIPE NCC LIR Portal. This new service will help reduce delays by providing LIRs increased access to the RIPE NCC via a web interface. The beta testing of this service started at RIPE 43 in September 2002. In addition to managing registry data, LIRs will be able to make other queries and updates without going through the RIPE NCC staff. Once the user is authenticated to the system, they will be able to access LIR specific resources and all information exchanged will be encrypted to ensure security. Features of the RIPE NCC LIR Portal include: - viewing and editing of LIR contact and address information - viewing of billing information - viewing of IP and AS resources - viewing status of open tickets - news and events To activate your account, please follow the procedure found at: https://lirportal.ripe.net/lirportal/activation/activation_request.html Or you can activate your account at the Hostmaster Centre at RIPE 44 with a photo ID. Any problems or suggestions can also be shared at the Hostmaster Centre. New features of the portal will be added based on response from the community. We welcome feedback on this new service. Comments can be sent to . Regards, Axel Pawlik RIPE NCC From axel.pawlik at ripe.net Mon Jan 20 16:16:58 2003 From: axel.pawlik at ripe.net (Axel Pawlik) Date: Mon, 20 Jan 2003 16:16:58 +0100 Subject: [lir-wg] Results of RIPE NCC 2002 Membership Survey Message-ID: <5.2.0.9.2.20030120161613.0216afa0@localhost> Dear Colleagues, As you are aware, the RIPE NCC commissioned KPMG to carry out a members and stakeholders survey on its behalf from 29 August to 31 October 2002. The focus of the survey was to give the membership and stakeholders a formal opportunity to voice opinions on the services provided by the RIPE NCC, and to give constructive input needed to plan services for the future. The survey included e-mailed responses and face-to-face meetings. There were a total of 285 respondents. The results of the survey, in full and abridged versions, are now available and can be found at: http://ripe.net/survey2002/results/ I wish to thank the members of the community who provided valuable feedback. I look forward to discussing the survey and results at the upcoming RIPE Meeting here in Amsterdam next week during Thursday's plenary session. I also wish to thank KPMG for conducting a professional and insightful analysis of our membership. Regards, Axel Pawlik RIPE NCC From leo at ripe.net Mon Jan 20 16:20:02 2003 From: leo at ripe.net (leo vegoda) Date: Mon, 20 Jan 2003 16:20:02 +0100 Subject: [lir-wg] Registration Services: Summary 2002 Message-ID: Dear Colleagues, Over 2002 the RIPE NCC has worked to improve the quality of Registration Services. Notable improvements, additions and changes include: - Response times to new tickets have improved dramatically, being answered within one working day. Since September the time taken to a first response has never risen above two working days. This is despite a record high number of tickets being received in October 2002. - The LIR WG approved new policy documents. The new structure makes documents easier to read and maintain. We will continue efforts to make policy documents clearer. - The common IPv6 policy has been implemented and we have made 76 new allocations under it. - The LIR WG reviewed the ASN assignment policy immediately before and during RIPE 43 in Rhodes. No major changes were made. - The RIPE NCC worked with Gert D?ring to analyse issues that need to be addressed in a proposal for a sub-allocation policy. Gert's proposal was accepted and a draft document is now under review by the LIR WG. - New LIRs can now take up membership much faster than in the past. The procedure has been streamlined and better documented. - Attendees at RIPE 43 in Rhodes have tested a new way to access RIPE NCC services. The "LIR Portal" was launched today as an official service and is accessible to all members. - A policy allowing temporary assignments of Internet resources for Internet experiments has been implemented. The policy wording will be incorporated into the IPv4, IPv6 and ASN policy documents. This is in addition to the existing procedure for temporary assignments to conferences and trade fairs. - We have completed the transfer of ASN registrations from the ARIN Database to the RIPE Database and have run a trial for the transfer of IPv4 registrations. In addition to this work we have plans to improve the quality of the RIPE NCC's Registration Services over 2003: - The "Hostmaster Robot" will be replaced with a new system that will handle a revised set of simpler forms. - We are reviewing the status attribute values for inetnum objects in the RIPE Database. - An improved tool to replace "asused_public" will be released soon. - A formal explanation of the system used to determine Assignment Windows will be published. - Customer service will be improved by having Hostmasters call customers to resolve difficult or complex requests more quickly. Kind regards, -- leo vegoda RIPE NCC Registration Services From gert at space.net Mon Jan 20 16:34:40 2003 From: gert at space.net (Gert Doering) Date: Mon, 20 Jan 2003 16:34:40 +0100 Subject: [lir-wg] Registration Services: Summary 2002 In-Reply-To: ; from leo@ripe.net on Mon, Jan 20, 2003 at 04:20:02PM +0100 References: Message-ID: <20030120163440.T15927@Space.Net> Hi Leo, and the rest of the NCC team, On Mon, Jan 20, 2003 at 04:20:02PM +0100, leo vegoda wrote: > - Response times to new tickets have improved dramatically, being > answered within one working day. Since September the time taken > to a first response has never risen above two working days. This > is despite a record high number of tickets being received in > October 2002. Congratulations! This is a very good result, and I am very glad to read that. (I'm a bit curious how you achieved this, but you can tell me that over a beer :-) ) Of course, all the other achievements are impressive as well, but this is simply the most outstanding one. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55857 (55593) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From mohr at belwue.de Mon Jan 20 17:22:01 2003 From: mohr at belwue.de (Christoph Mohr) Date: Mon, 20 Jan 2003 17:22:01 +0100 Subject: [lir-wg] draft-documents: sub-allocations.html Message-ID: <20030120162201.GC18384@belwue.de> Dear Colleagues! Referring to http://www.ripe.net/ripe/draft-documents/sub-allocations.html, I found a problem which maybe will arise after publishing the document. In 3.2 Restriction on creation of inetnums with an "ASSIGNED" status I read: The creation of an inetnum object with a status of "ASSIGNED PA" or "ASSIGNED PI" will not be allowed if there is either a less specific or more specific inetnum object with an "ASSIGNED" status. The assigned status inetnum is the most specific registration allowed. Now the question I have is if this will apply to all inetnum objects which are already in the database. We, the Academic Network of the Federal State of Baden-Wuerttemberg (BELWUE), manage the internet not only for the universities in Baden-Wuerttemberg, but as well for many public schools. To provide public schools with internet addresses, we are allowed by the universities to use some of the addresses in their own class B network they don't need. (I think there won't be one university which currently uses all their IPv4 addresses in its B block.) So we are able to economise IPv4 resources by using IP addresses which wouldn't be used otherwise. That's why there are overlapping inetnum objects which are both "ASSIGNED PI", which will be forbidden in the future if I understand well the new document. Example: Within 132.230/16 which is FDN (Freiburg University) one can find 132.230.194.0 - 132.230.196.255 (BELWUE-SCHULEN) which are IP addresses of public schools in the Freiburg region. We prefer to have this inetnum object because we don't want the university to deal with abuse mails which may occur because there isn't always specialised staff in the schools to manage firewalls, mailservers etc. correctly. When there is an abuse incident we are able to react quickly by contacting the respective school. We made yet the experience that these entries in the database were very useful. Well, perhaps I misunderstood the draft document and there won't be any problems like the one I mentioned. Anyway, there should be some clarification about the objects the database won't allow to create in the future. Best regards, Christoph Mohr -- -- Christoph Mohr, BelWue Coordination ---------- mailto:mohr at belwue.de ----- Computing Center University of Stuttgart (RUS) Phone: +49 711 685-2079 Allmandring 30, D-70550 Stuttgart Fax: +49 711 678-8363 ------------------------------------------------- http://www.belwue.de/ ----- From gert at space.net Tue Jan 21 14:58:44 2003 From: gert at space.net (Gert Doering) Date: Tue, 21 Jan 2003 14:58:44 +0100 Subject: [lir-wg] draft-documents: sub-allocations.html In-Reply-To: <20030120162201.GC18384@belwue.de>; from mohr@belwue.de on Mon, Jan 20, 2003 at 05:22:01PM +0100 References: <20030120162201.GC18384@belwue.de> Message-ID: <20030121145844.Y15927@Space.Net> Hi, On Mon, Jan 20, 2003 at 05:22:01PM +0100, Christoph Mohr wrote: > Referring to http://www.ripe.net/ripe/draft-documents/sub-allocations.html, > I found a problem which maybe will arise after publishing the document. > > In 3.2 Restriction on creation of inetnums with an "ASSIGNED" status I read: > > The creation of an inetnum object with a status of "ASSIGNED PA" or > "ASSIGNED PI" will not be allowed if there is either a less specific or more > specific inetnum object with an "ASSIGNED" status. The assigned status inetnum > is the most specific registration allowed. Indeed there is a problem here - 3.1 doesn't specify the type of "status:" to be used in the a sub-allocation inetnum object. I propose to use "SUB-ALLOCATED PA", but I'm not sure whether the NCC or community has some other ideas here. > Now the question I have is if this will apply to all inetnum objects which are > already in the database. This section might sound new, but it isn't - it was always a mistake to create "ASSIGNED" inetnum objects inside existing "ASSIGNED" inetnums. The database doesn't enforce this restriction today (for IPv4), but if you run the "asused" check tool, it will complain about overlapping objects (and so will the RIPE hostmasters). > We, the Academic Network of the Federal State of Baden-Wuerttemberg (BELWUE), > manage the internet not only for the universities in Baden-Wuerttemberg, but as > well for many public schools. To provide public schools with internet > addresses, we are allowed by the universities to use some of the addresses > in their own class B network they don't need. (I think there won't be one > university which currently uses all their IPv4 addresses in its B block.) > So we are able to economise IPv4 resources by using IP addresses which > wouldn't be used otherwise. > That's why there are overlapping inetnum objects which are both "ASSIGNED PI", > which will be forbidden in the future if I understand well the new document. What you do is, by definition of "ASSIGNED PI", already a violation of the policy (PI space is not supposed to be given to other institutions, by definition). It makes lots of sense to do it :-) but the policy doesn't take that into account. On the other hand, this is "old" PI stuff, which is likely to be assigned before there even was a set of RIPE rules, and thus the standard rules do not apply... [..] > Well, perhaps I misunderstood the draft document and there won't be any > problems like the one I mentioned. Anyway, there should be some clarification > about the objects the database won't allow to create in the future. It's not the central purpose of this draft document to disallow things (to the contrary :-) ), this section is mainly intended to clarify the underlying rules - ASSIGNMENTs come from ALLOCATIONs or SUB-ALLOCATIONs, and nowhere else, and MUST NOT be nested. Reading your comment, I feel that it might be useful to change 3.2 to apply only to PA (the whole draft is only targeted at PA space) and reconsider what to do with "old" PI assignments. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55857 (55593) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From mohr at belwue.de Wed Jan 22 13:35:56 2003 From: mohr at belwue.de (Christoph Mohr) Date: Wed, 22 Jan 2003 13:35:56 +0100 Subject: [lir-wg] draft-documents: sub-allocations.html In-Reply-To: <20030121145844.Y15927@Space.Net> References: <20030120162201.GC18384@belwue.de> <20030121145844.Y15927@Space.Net> Message-ID: <20030122123556.GP1778@belwue.de> Hello Gert Doering! On Tue 2003-01-21 (14:58), Gert Doering wrote: > Hi, > > On Mon, Jan 20, 2003 at 05:22:01PM +0100, Christoph Mohr wrote: > > Referring to http://www.ripe.net/ripe/draft-documents/sub-allocations.html, > > I found a problem which maybe will arise after publishing the document. > > > > In 3.2 Restriction on creation of inetnums with an "ASSIGNED" status I read: > > > > The creation of an inetnum object with a status of "ASSIGNED PA" or > > "ASSIGNED PI" will not be allowed if there is either a less specific or more > > specific inetnum object with an "ASSIGNED" status. The assigned status inetnum > > is the most specific registration allowed. > > Indeed there is a problem here - 3.1 doesn't specify the type of "status:" > to be used in the a sub-allocation inetnum object. > > I propose to use "SUB-ALLOCATED PA", but I'm not sure whether the NCC or > community has some other ideas here. > > > Now the question I have is if this will apply to all inetnum objects which are > > already in the database. > > This section might sound new, but it isn't - it was always a mistake to > create "ASSIGNED" inetnum objects inside existing "ASSIGNED" inetnums. > > The database doesn't enforce this restriction today (for IPv4), but if > you run the "asused" check tool, it will complain about overlapping > objects (and so will the RIPE hostmasters). > > > We, the Academic Network of the Federal State of Baden-Wuerttemberg (BELWUE), > > manage the internet not only for the universities in Baden-Wuerttemberg, but as > > well for many public schools. To provide public schools with internet > > addresses, we are allowed by the universities to use some of the addresses > > in their own class B network they don't need. (I think there won't be one > > university which currently uses all their IPv4 addresses in its B block.) > > So we are able to economise IPv4 resources by using IP addresses which > > wouldn't be used otherwise. > > That's why there are overlapping inetnum objects which are both "ASSIGNED PI", > > which will be forbidden in the future if I understand well the new document. > > What you do is, by definition of "ASSIGNED PI", already a violation of > the policy (PI space is not supposed to be given to other institutions, > by definition). It makes lots of sense to do it :-) but the policy doesn't > take that into account. Please have a look at 141.6.0.0/16 (BASFAG-NET) which is the Class B network of BASF (ASSIGNED PI). Now there are to other ASSIGNED PI networks nested in, namely 141.6.207.0/24 (BASFAG-CH-NET) and 141.6.198.0/23 (BASFAG-DYN-NET-141-6-198), which obviously don't belong to other institutions. It seems to me very reasonable because there are other contacts in the smaller networks. On the other hand, it doesn't seem reasonable, to apply "ALLOCATED PI or PA" to the large B net 141.6/16. This is just an example of nested inetnum objects with the status ASSIGNED PI, there could be found many others. I think the RIPE database should reflect this difficult situation, otherwise the network managers/administrators won't put in inetnum objects for smaller networks with different contacts so that finally the database doesn't provide useful information. > On the other hand, this is "old" PI stuff, which is likely to be assigned > before there even was a set of RIPE rules, and thus the standard rules do > not apply... > > [..] > > Well, perhaps I misunderstood the draft document and there won't be any > > problems like the one I mentioned. Anyway, there should be some clarification > > about the objects the database won't allow to create in the future. > > It's not the central purpose of this draft document to disallow things > (to the contrary :-) ), this section is mainly intended to clarify the > underlying rules - ASSIGNMENTs come from ALLOCATIONs or SUB-ALLOCATIONs, > and nowhere else, and MUST NOT be nested. > > Reading your comment, I feel that it might be useful to change 3.2 to > apply only to PA (the whole draft is only targeted at PA space) and > reconsider what to do with "old" PI assignments. Maybe this could be a solution at the moment. Will there be an appropiate new draft document in the web? Best regards, Christoph Mohr -- -- Christoph Mohr, BelWue Coordination ---------- mailto:mohr at belwue.de ----- Computing Center University of Stuttgart (RUS) Phone: +49 711 685-2079 Allmandring 30, D-70550 Stuttgart Fax: +49 711 678-8363 ------------------------------------------------- http://www.belwue.de/ ----- From webmaster at ripe.net Wed Jan 22 16:34:16 2003 From: webmaster at ripe.net (RIPE NCC Document Announcement Service) Date: Wed, 22 Jan 2003 16:34:16 +0100 Subject: [lir-wg] New Documents available: RIPE-263, RIPE-267 Message-ID: <200301221534.h0MFYGAq025110@birch.ripe.net> New RIPE Documents Announcement -------------------------------------- Two new documents are available from the RIPE document store. Ref: ripe-263 Title: Autonomous System (AS) Number Assignment Policies and Procedures Author: Mirjam Kuehne, Nurani Nimpuno, Sabrina Wilmot Date: 22 January 2003 Format: PS=16292 TXT=6248 Obsoletes: ripe-185, ripe-245 Obsoleted by: Updates: Updated by: Ref: ripe-267 Title: IPv6 Address Allocation and Assignment Policy Author: ARIN, APNIC, RIPE NCC Date: 22 January 2003 Format: PS=816883 TXT=34295 Obsoletes: ripe-196, ripe-246 Obsoleted by: Updates: Updated by: Short content description ------------------------- The "Autonomous System (AS) Number Assignment Policies and Procedures" provides a description of Autonomous System Numbers, their assignment procedures and guidelines on how to obtain them in RIPE NCC service region. "Assignments for Internet Experiments" has been included in this latest version. The "IPv6 Address Allocation and Assignment Policy" defines registry policies for the assignment and allocation of globally unique IPv6 addresses to Internet Service Providers (ISPs) and other organisations. "Assignments for Internet Experiments" has been included in this latest version. Accessing the RIPE document store --------------------------------- You can access the RIPE documents in HTML format via our website at the following URLs:. http://www.ripe.net/ripe/docs/asn-assignment.html http://www.ripe.net/ripe/docs/ipv6policy.html The RIPE Document Store is also available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-263.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-263.txt plain text version ftp://ftp.ripe.net/ripe/docs/ripe-267.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-267.txt plain text version From joao at psg.com Wed Jan 22 16:55:37 2003 From: joao at psg.com (Joao Damas) Date: Wed, 22 Jan 2003 16:55:37 +0100 (CET) Subject: [lir-wg] draft-documents: sub-allocations.html In-Reply-To: <20030122123556.GP1778@belwue.de> Message-ID: I thought pre-RIPE NCC address space, such as the class Bs which have been mentioned, were meant to have ALLOCATED UNSPECIFIED or ASSIGNED UNSPECIFIED status and the registration rules for that space were different, recognising its pre-RIR status. Am I completely confused? Joao From gert at space.net Wed Jan 22 17:23:30 2003 From: gert at space.net (Gert Doering) Date: Wed, 22 Jan 2003 17:23:30 +0100 Subject: [lir-wg] draft-documents: sub-allocations.html In-Reply-To: ; from joao@psg.com on Wed, Jan 22, 2003 at 04:55:37PM +0100 References: <20030122123556.GP1778@belwue.de> Message-ID: <20030122172330.P15927@Space.Net> Hi, On Wed, Jan 22, 2003 at 04:55:37PM +0100, Joao Damas wrote: > I thought pre-RIPE NCC address space, such as the class Bs which have been > mentioned, were meant to have ALLOCATED UNSPECIFIED or ASSIGNED > UNSPECIFIED status and the registration rules for that space were > different, recognising its pre-RIR status. As far as I understand, this is what the database put in when the status: field was made mandatory. When you update an entry, this status values are not permitted, though, and you have to decide upon PI/PA. Maybe it's time to introduce "ALLOCATED PRE-RIR"? Or reconsider the way the database (and asused tool) enforces "non-documentation" due to the current rules... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55857 (55593) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From mohr at belwue.de Wed Jan 22 17:25:43 2003 From: mohr at belwue.de (Christoph Mohr) Date: Wed, 22 Jan 2003 17:25:43 +0100 Subject: [lir-wg] draft-documents: sub-allocations.html In-Reply-To: References: <20030122123556.GP1778@belwue.de> Message-ID: <20030122162543.GI9690@belwue.de> Hello Joao! On Wed 2003-01-22 (16:55), Joao Damas wrote: > > I thought pre-RIPE NCC address space, such as the class Bs which have been > mentioned, were meant to have ALLOCATED UNSPECIFIED or ASSIGNED > UNSPECIFIED status ... That's not always so. As far as I know, pre-RIPE NCC address space is mostly ASSIGNED PI. Address space of providers and some universities has the status ALLOCATED UNSPECIFIED. The status "ASSIGNED UNSPECIFIED: doesn't exist. > ... and the registration rules for that space were > different, recognising its pre-RIR status. That's what I thought as well, but I understood some phrases in the draft document that there will be implemented some new restrictions in the database robot which could eventually apply to pre-RIPE NCC address space as well. Best regards, Christoph Mohr -- -- Christoph Mohr, BelWue Coordination ---------- mailto:mohr at belwue.de ----- Computing Center University of Stuttgart (RUS) Phone: +49 711 685-2079 Allmandring 30, D-70550 Stuttgart Fax: +49 711 678-8363 ------------------------------------------------- http://www.belwue.de/ ----- From kristofer at nh.is Thu Jan 23 11:56:15 2003 From: kristofer at nh.is (Kristofer Sigurdsson) Date: Thu, 23 Jan 2003 10:56:15 +0000 Subject: [lir-wg] draft-documents: sub-allocations.html In-Reply-To: <20030122162543.GI9690@belwue.de> References: <20030122123556.GP1778@belwue.de> <20030122162543.GI9690@belwue.de> Message-ID: <20030123105615.GB6067@pfy.rhi.hi.is> Hi, I was just wondering, will this new policy mean that downstream network operators can control their own assignments, at least to some extent, without being a LIR themselves? -- Krist?fer Sigur?sson Net- og kerfisdeild Neth?nnun ehf. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From gert at space.net Thu Jan 23 12:03:34 2003 From: gert at space.net (Gert Doering) Date: Thu, 23 Jan 2003 12:03:34 +0100 Subject: [lir-wg] draft-documents: sub-allocations.html In-Reply-To: <20030123105615.GB6067@pfy.rhi.hi.is>; from kristofer@nh.is on Thu, Jan 23, 2003 at 10:56:15AM +0000 References: <20030122123556.GP1778@belwue.de> <20030122162543.GI9690@belwue.de> <20030123105615.GB6067@pfy.rhi.hi.is> Message-ID: <20030123120334.U15927@Space.Net> Hi, On Thu, Jan 23, 2003 at 10:56:15AM +0000, Kristofer Sigurdsson wrote: > I was just wondering, will this new policy mean that downstream network > operators can control their own assignments, at least to some extent, > without being a LIR themselves? Yes. That's the intention. I had hoped that this was pretty obvious from the draft... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55857 (55593) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From slz at baycix.de Fri Jan 24 16:44:24 2003 From: slz at baycix.de (Sascha Lenz) Date: Fri, 24 Jan 2003 16:44:24 +0100 Subject: [lir-wg] Draft: IPv4 Sub-allocations - revisited Message-ID: <20030124164424.A32673@mama.baycix.de> Hay, even though i hope that everyone already noticed it, i didn't see any comments about it on any list yet: in "3.0 Database registration" the draft states: [...] 3.1 Status attribute for inetnums representing sub-allocations Registration of a sub-allocation in the RIPE Database requires the creation of an inetnum object with an appropriate status value. 3.2 Restriction on creation of inetnums with an .ASSIGNED. status The creation of an inetnum object with a status of .ASSIGNED PA. or .ASSIGNED PI. will not be allowed if there is either a less specific or more specific inetnum object with an .ASSIGNED. status. The assigned status inetnum is the most specific registration allowed. [...] ...just that it seems to lack the information _what_ status value is appropriate for a sub-allocation then. One might guess that "LIR-PARTITIONED [PA|PI]" could be meant, but it also might be something completely different or even some new value since the current ripe-239 doesn't really cover the usage the sub-allocation draft suggest (5.0 in ripe-239 "IP Address Policy Implications"). ...just my 0.02EUR -- ========================================================================== = Sascha 'master' Lenz SLZ-RIPE slz at baycix.de = = NOC BayCIX GmbH = = http://www.noc.baycix.de/ * PGP public Key on demand * = ========================================================================== From gert at space.net Fri Jan 24 16:57:55 2003 From: gert at space.net (Gert Doering) Date: Fri, 24 Jan 2003 16:57:55 +0100 Subject: [lir-wg] Draft: IPv4 Sub-allocations - revisited In-Reply-To: <20030124164424.A32673@mama.baycix.de>; from slz@baycix.de on Fri, Jan 24, 2003 at 04:44:24PM +0100 References: <20030124164424.A32673@mama.baycix.de> Message-ID: <20030124165755.Z15927@Space.Net> Hi, On Fri, Jan 24, 2003 at 04:44:24PM +0100, Sascha Lenz wrote: > One might guess that "LIR-PARTITIONED [PA|PI]" could be meant, but it > also might be something completely different or even some new value since > the current ripe-239 doesn't really cover the usage the sub-allocation draft > suggest (5.0 in ripe-239 "IP Address Policy Implications"). No, it's not meant to be LIR-PARTITIONED. That's something different with different implications. I vote for "SUB-ALLOCATED PA". Leo, are you listening? Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55600 (55857) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From slz at baycix.de Fri Jan 24 17:07:08 2003 From: slz at baycix.de (Sascha Lenz) Date: Fri, 24 Jan 2003 17:07:08 +0100 Subject: [lir-wg] Draft: IPv4 Sub-allocations - revisited In-Reply-To: <20030124165755.Z15927@Space.Net>; from gert@Space.Net on Fri, Jan 24, 2003 at 04:57:55PM +0100 References: <20030124164424.A32673@mama.baycix.de> <20030124165755.Z15927@Space.Net> Message-ID: <20030124170708.B32673@mama.baycix.de> Hay, On Fri, Jan 24, 2003 at 04:57:55PM +0100, Gert Doering wrote: > Hi, > > On Fri, Jan 24, 2003 at 04:44:24PM +0100, Sascha Lenz wrote: > > One might guess that "LIR-PARTITIONED [PA|PI]" could be meant, but it > > also might be something completely different or even some new value since > > the current ripe-239 doesn't really cover the usage the sub-allocation draft > > suggest (5.0 in ripe-239 "IP Address Policy Implications"). > > No, it's not meant to be LIR-PARTITIONED. That's something different > with different implications. right, but _could_ be altered to be used here, too - too many new status: values are not so good either. Though, I agree, it's not appropriate here since it was introduced with a slightly different intention. > I vote for "SUB-ALLOCATED PA". Leo, are you listening? what about allowing "ALLOCATED-BY-LIR" in inetnum:s ? Would be consistent with inet6num:s then a bit, and not again a completely new value. On the other hand, someone might mix up IPv4 and IPv6 then somehow. But i don't really care personally what will be used, it just has to be included in the document :) -- ========================================================================== = Sascha 'master' Lenz SLZ-RIPE slz at baycix.de = = NOC BayCIX GmbH = = http://www.noc.baycix.de/ * PGP public Key on demand * = ========================================================================== From leo at ripe.net Fri Jan 24 17:13:29 2003 From: leo at ripe.net (leo vegoda) Date: Fri, 24 Jan 2003 17:13:29 +0100 Subject: [lir-wg] Draft: IPv4 Sub-allocations - revisited In-Reply-To: <20030124165755.Z15927@Space.Net> References: <20030124164424.A32673@mama.baycix.de> <20030124165755.Z15927@Space.Net> Message-ID: <20030124161329.GC14697@ripe.net> Hi Gert, On Fri, Jan 24, 2003 at 04:57:55PM +0100, Gert Doering wrote: > Hi, > > On Fri, Jan 24, 2003 at 04:44:24PM +0100, Sascha Lenz wrote: > > One might guess that "LIR-PARTITIONED [PA|PI]" could be meant, but it > > also might be something completely different or even some new value since > > the current ripe-239 doesn't really cover the usage the sub-allocation draft > > suggest (5.0 in ripe-239 "IP Address Policy Implications"). > > No, it's not meant to be LIR-PARTITIONED. That's something different > with different implications. > > I vote for "SUB-ALLOCATED PA". Leo, are you listening? I am listening. We did not specify the status value to be used as we expected input from the community. Incidentally, we are reviewing all the status attribute values at the moment. Best regards, -- leo vegoda RIPE NCC Registration Services From gert at space.net Fri Jan 24 17:21:24 2003 From: gert at space.net (Gert Doering) Date: Fri, 24 Jan 2003 17:21:24 +0100 Subject: [lir-wg] Draft: IPv4 Sub-allocations - revisited In-Reply-To: <20030124170708.B32673@mama.baycix.de>; from slz@baycix.de on Fri, Jan 24, 2003 at 05:07:08PM +0100 References: <20030124164424.A32673@mama.baycix.de> <20030124165755.Z15927@Space.Net> <20030124170708.B32673@mama.baycix.de> Message-ID: <20030124172124.B15927@Space.Net> Hi, On Fri, Jan 24, 2003 at 05:07:08PM +0100, Sascha Lenz wrote: > > I vote for "SUB-ALLOCATED PA". Leo, are you listening? > > what about allowing "ALLOCATED-BY-LIR" in inetnum:s ? > Would be consistent with inet6num:s then a bit, and not again a completely > new value. I agree. This might be a good idea, to be consistant. > On the other hand, someone might mix up IPv4 and IPv6 then somehow. Well, the rules are a bit different, but the interpretation is the same - this address block was given to someone else, who is now responsible to maintain it. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55600 (55857) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From gert at space.net Fri Jan 24 17:24:01 2003 From: gert at space.net (Gert Doering) Date: Fri, 24 Jan 2003 17:24:01 +0100 Subject: [lir-wg] Draft: IPv4 Sub-allocations - revisited In-Reply-To: <20030124161329.GC14697@ripe.net>; from leo@ripe.net on Fri, Jan 24, 2003 at 05:13:29PM +0100 References: <20030124164424.A32673@mama.baycix.de> <20030124165755.Z15927@Space.Net> <20030124161329.GC14697@ripe.net> Message-ID: <20030124172401.C15927@Space.Net> Hi, On Fri, Jan 24, 2003 at 05:13:29PM +0100, leo vegoda wrote: > We did not specify the status value to be used as we expected input > from the community. Ah, ok. We got some good input, I'd say :-) > Incidentally, we are reviewing all the status attribute values at the > moment. Looking forward to see the outcome... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55600 (55857) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From webmaster at ripe.net Thu Jan 30 09:43:07 2003 From: webmaster at ripe.net (RIPE NCC WebMaster) Date: Thu, 30 Jan 2003 09:43:07 +0100 Subject: [lir-wg] Spam on mailing list Message-ID: <200301300843.h0U8h7Aq027329@birch.ripe.net> Dear all, Apologies for forwarding some spam to the lir-wg mailing list. This was purely a human error on my account. Sorry for the inconvenience, Regards Jeroen Bet RIPE NCC Mailing list moderator ==================