From lir at acantho.com Thu Apr 4 12:36:34 2002 From: lir at acantho.com (Fabio Bracali - Local Internet Registry - Casaweb) Date: Thu, 04 Apr 2002 12:36:34 +0200 Subject: update lir object Message-ID: <5.1.0.14.2.20020404123200.03d1f268@10.0.0.5> I would like to update my lir object with new contact persons and new email addresses. How can i do it? what is ripe email address that I must use to send the form? thanks in advance From sabrina at ripe.net Thu Apr 4 15:39:08 2002 From: sabrina at ripe.net (Sabrina Wilmot) Date: Thu, 4 Apr 2002 15:39:08 +0200 Subject: update lir object In-Reply-To: <5.1.0.14.2.20020404123200.03d1f268@10.0.0.5> References: <5.1.0.14.2.20020404123200.03d1f268@10.0.0.5> Message-ID: <20020404153908.5018b1b1.sabrina@ripe.net> On Thu, 04 Apr 2002 12:36:34 +0200 Fabio Bracali - Local Internet Registry - Casaweb wrote: > I would like to update my lir object with new contact persons and new > email addresses. > How can i do it? > what is ripe email address that I must use to send the form? > thanks in advance > For updates of your LIR's contact information please write to . Do not forget to include your registry ID. Regards, -- o------------------------------------------o | Sabrina Wilmot sabrina at ripe.net | | Registration Services Operations Manager | | | | RIPE NCC tel +31 20 535 4444 | | www.ripe.net fax +31 20 535 4445 | o------------------------------------------o From lir-mod at ripe.net Wed Apr 10 17:15:20 2002 From: lir-mod at ripe.net (RIPE NCC Mailing Lists Moderator) Date: Wed, 10 Apr 2002 17:15:20 +0200 Subject: Test Message-ID: <200204101515.g3AFFKu14972@birch.ripe.net> From gert at space.net Wed Apr 10 17:39:49 2002 From: gert at space.net (Gert Doering) Date: Wed, 10 Apr 2002 17:39:49 +0200 Subject: Reopen discussion: Sub-Allcations vs. LIR-PARTITIONED Message-ID: <20020410173949.A61447@Space.Net> Hi, as you might remember, there was a lengthy discussion on this list about sub-allocations, reservations (yes, the ugly word) of IP address blocks for LIR customers that are themselves resellers, and so on. James Aldridge originally proposed something that ended up in being "status: LIR-PARTITIONED PA/PI". I just checked the RIPE DB, and there are just 7 objects in the RIPE database that use this at all, and 6 of them are by one maintainer. This matches my feelings of LIR-PARTITIONED - "nice try, but this isn't what I imagined". I think "official sub-allocations" are more useful, and have written up a proposal for this (based on the discussion here and at the LIR-WG meeting in Prague). Give it a good discussion and let's decide something in Amsterdam... gert --------- snip ---------- Motivation: - Some LIRs have internal hierarchies, like "resellers that have their own end customers". - For aggregation reasons internal to the LIR network, LIRs "allocate" address space to their resellers ("hierarchical sub-LIRs"), who then "assign" addresse from that to their customers. Usually the LIR has to approve all end-user requests, but the sub-LIR is doing the actual assignment from the "allocated" space. - The current policy doesn't explicitely permit this, but acknowledges to some extent that it is done. - When the LIR goes to the RIR to get another allocation, the 80% rule does not take into account the fact that some of the "not assigned" space may be in fact "sub-allocated" to a "sub-LIR", thus it may be very hard to reach 80% (and will lead to internal fragmentation). (This is what Wilfried calls "reservation") - The sub-allocations are not documented, so an outsider cannot see who might be the best contact (the reseller!) if one of the end customers misbehaves (this part could be solved with "LIR-PARTITIONED"). Proposal: - permit LIRs to sub-allocate the address allocation they receive from a RIR to "downstream parties", from now on called sub-LIRs - the Sub-Allocations are documented as an inetnum: object with "status: SUB-ALLOCATED PA" in the RIPE database. I do not like "LIR-PARTITIONED", because it isn't partitioned ("equal parts"), and also because it doesn't go far enough. - All assignments from the Sub-Allocation are done by the Sub-LIR. The Sub-LIR is responsible to the LIR for following policies and procedures. The LIR is responsible to the RIR for making sure that the Sub-LIR follows the procedures. This is no big difference from what is being *done* now, it's just "officially documented". - When the LIR has to apply for an additional allocation, the Sub-Allocation are counted for the "80% utilization rule". So, to show an extreme example, a LIR that has sub-allocated 90% to its resellers, and they have only assigned a total of 30% of the total allocation yet, the LIR *would be* entitled to get a new allocation (under the current policy, it is not). In extreme cases, it might be necessary to show lots of good documentation to the RIR as for "why did you allocate so much". Points of Concern: - "They will just waste address space". Yes, it will waste some space, due to better aggregation. It is not expected that this will waste space due to "sloppyness" in following the policies and procedures - each hierarchy level will be fully responsible for making sure that the next-lower level will understand the rules and follow them. It is similar to what IANA and the RIRs do. The RIRs try to hand out address space in a responsible way (which does not always succeeed, which is why changes to the procedures are made, like /19 -> /20 for the initial allocation), and in this proposal, the LIRs have to hand out space to the sub-LIRs in a responsible way. If the RIRs mess up, they have a problem with IANA, if the LIRs mess up, they have a problem with their RIR. - "How big shall the sub-allocation be"? The exact numbers for the default case would have to be defined. Again, this is similar to the RIR->LIR case. A LIR by default gets a /20, but might get a bigger space in case it produces a good forecast that shows a reasonable need for a bigger space. I propose to give a Sub-LIR a /24 to start with, except in cases that they show evidence for needing more. Rationale: it's not too much, and you can delegate DNS on /24 boundaries without ugly tricks. When the Sub-Allocation is used up (= 80% of the space in there is ASSIGNED), the Sub-LIR can ask for more. If a customer asks for more space than the Sub-LIR has left, the Sub-Allocation can also be increased / a new Sub-Allocation be made. - "What's the size of networks a Sub-LIR can assign to their customers"? It can not go over the AW of the LIR. This part is fixed due to the RIR/LIR relation. As for the rest, I propose that this should be a matter between the LIR and the Sub-LIR. They have a contract, and it's the LIRs job to make sure that the Sub-LIR follows the official policies and procedures, maybe introducing their own Sub-AW per Sub-LIR etc. --------- snip ---------- -- Total number of prefixes smaller than registry allocations: 74810 (74196) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From ncc at ripe.net Wed Apr 10 18:15:52 2002 From: ncc at ripe.net (RIPE NCC Staff) Date: Wed, 10 Apr 2002 18:15:52 +0200 Subject: Hostmaster Centre at RIPE 42 Message-ID: <200204101615.g3AGFqu02712@birch.ripe.net> Dear all, RIPE NCC Registrations Services are pleased to announce that during the RIPE 42 Meeting in Amsterdam we will open a RIPE NCC Hostmaster Centre. RIPE NCC Hostmasters will be available for questions related to IP and ASN requests, as well as any general policy questions and LIR set up issues. A timesheet at the centre will be made available for appointments, though 'walk-in's will also be welcome. Please note the following time-table: Monday April 29th. 12:30 - 17:30 Wednesday May 1st. 12:30 - 17:30 Thursday May 2nd. 9:00 - 17:30 Friday May 3rd. 9:00 - 14:00 We look forward to meeting you. Regards, RIPE NCC Hostmasters Information about the RIPE 42 Meeting can be found at: http://www.ripe.net/ripe/meetings/current/ripe-42/ From jhma+ripe at mcvax.org Wed Apr 10 21:23:10 2002 From: jhma+ripe at mcvax.org (James Aldridge) Date: Wed, 10 Apr 2002 21:23:10 +0200 Subject: Draft Agenda for LIR WG at RIPE42 Message-ID: Herewith the first draft of the agenda for the forthcoming LIR-WG meeting at RIPE42. It would be good if we could have some on-list discussion on these topics before the meeting itself. Regards, James LIR-WG Co-Chair ---------- LIR WORKING GROUP Draft Agenda for RIPE 42 (version 1.4) 09:00-12:30 Wednesday, 1st May 2002 Chair: Hans Petter Holen Co-chairs: James Aldridge, Denesh Bhabuta Note that some items currently have zero time allocated to them; this may change as we get an idea of how long some of the regular presentations will take. We have a lot to get through so I would urge people not to celebrate Queensday too excessively on Tuesday so we can make a prompt start on Wednesday morning. 09:00 - 09:05 A. Admin: scribe, participant list, charter, mailing lists 09:05 - 09:10 B. Agenda bashing 09:10 - 09:20 C. RIPE 41 minutes and actions [Has anyone seen the minutes from the last meeting? I've only seen those for the IPv6 Policy sessions] 09:20 - 09:40 D. Report from the RIPE NCC Hostmasters - Presentation [Sabrina Wilmot ?] 09:40 - 09:55 E. Report from the Address Council - Presentation [Hans Petter Holen ?] 09:55 - 10:30 F. IPv4 Assignment and Allocation Policy F.1 Do we need to bring the IPv4 assignment policy into line with the new (Nov 2001) "Minimum Allocation Criteria" policy? - Summary of problem [Sabrina Wilmot ?] - Proposed solution (?) - Discussion F.2 "Official Sub-Allocations" Proposal [Gert Doering] F.3 "MIR/SUB-LIR" Proposal (WG action from RIPE40) http://www.ripe.net/ripe/mail-archives/lir-wg/20010701-20020101/msg00138.html Is this still needed following the implementation of "status: LIR-PARTITIONED" (documentation) or do we still need a more hierarchical allocation scheme (policy)? 10:30 - 11:00 Coffee break 11:00 - 12:30 G. IPv6 Allocation Policy Can this community agree with the consensus reached at the recent APNIC and ARIN meetings? - Summary presentation [Mirjam Kuehne ?] - IPv6 WG Input [David Kessens ?] - Discussion - Consensus! 00:00 - 00:00 X. Any other business 00:00 - 00:00 Y. Summary of actions arising from this meeting 00:00 - 00:00 Z. Open microphone From gert at space.net Wed Apr 10 22:22:31 2002 From: gert at space.net (Gert Doering) Date: Wed, 10 Apr 2002 22:22:31 +0200 Subject: Draft Agenda for LIR WG at RIPE42 In-Reply-To: ; from jhma+ripe@mcvax.org on Wed, Apr 10, 2002 at 09:23:10PM +0200 References: Message-ID: <20020410222231.H37214@Space.Net> Hi, On Wed, Apr 10, 2002 at 09:23:10PM +0200, James Aldridge wrote: > F.2 "Official Sub-Allocations" Proposal [Gert Doering] > > F.3 "MIR/SUB-LIR" Proposal (WG action from RIPE40) > > http://www.ripe.net/ripe/mail-archives/lir-wg/20010701-20020101/msg00138.html > > Is this still needed following the implementation of "status: > LIR-PARTITIONED" (documentation) or do we still need a more > hierarchical allocation scheme (policy)? I think this is more or less the same agenda item - the "sub-allocation proposal" came from the MIR/SUB-LIR discussion, I just wrote it down :-) And yes, I think that discussion is needed whether LIR-PARTITIONED is enough or whether we need more "official hierarchy"... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 74810 (74196) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From jhma+ripe at mcvax.org Thu Apr 11 00:06:05 2002 From: jhma+ripe at mcvax.org (jhma+ripe at mcvax.org) Date: Thu, 11 Apr 2002 00:06:05 +0200 Subject: Draft Agenda for LIR WG at RIPE42 In-Reply-To: <20020410.235527.42651220.he@uninett.no> References: <20020410.235527.42651220.he@uninett.no> Message-ID: Havard Eidnes asked: > Can you please send a pointer to the LIR mailing list which points > towards the policy which there appers to be consensus on? Attached is a message posted to the global-v6 list by Takashi Arano following the last APNIC meeting. The ARIN meeting has just finished and I haven't yet seen any formal report from that meeting but I am lead to believe that the same consensus was reached. James -------------- next part -------------- An embedded message was scrubbed... From: Takashi Arano Subject: [GLOBAL-V6] Consensus in AP region Date: Mon, 11 Mar 2002 22:11:46 +0900 Size: 5443 URL: From arano at gblx.ad.jp Thu Apr 11 09:34:35 2002 From: arano at gblx.ad.jp (Takashi Arano) Date: Thu, 11 Apr 2002 16:34:35 +0900 Subject: Draft Agenda for LIR WG at RIPE42 In-Reply-To: References: <20020410.235527.42651220.he@uninett.no> <20020410.235527.42651220.he@uninett.no> Message-ID: <4.3.2-J.20020411162930.03e42a98@mail.gblx.ad.jp> James, Yes, every point has got consensus in ARIN meeting this week as well as APNIC. Maybe, Thomas Narten of IPv6 WG chair of ARIN will formally report to you soon. Now it is your turn to decide! Regards, Takashi Arano At 07:06 02/04/11, jhma+ripe at mcvax.org wrote: >Havard Eidnes asked: > > Can you please send a pointer to the LIR mailing list which points > > towards the policy which there appers to be consensus on? > >Attached is a message posted to the global-v6 list by Takashi Arano following >the last APNIC meeting. The ARIN meeting has just finished and I haven't yet >seen any formal report from that meeting but I am lead to believe that the >same consensus was reached. > >James > >Return-Path: owner-global-v6 at lists.apnic.net >Delivery-Date: Mon Mar 11 13:13:05 2002 >Received: from cumin.apnic.net ([202.12.29.59])by mcvax.org with esmtp (Exim 3.34 #1)id 16kPbs-000NZp-00for jhma at mcvax.org; Mon, 11 Mar 2002 13:13:04 +0000 >Received: from hadrian.staff.apnic.net (hadrian.apnic.net [202.12.29.249])by cumin.apnic.net (8.12.1/8.12.1) with ESMTP id g2BD79c2016416;Mon, 11 Mar 2002 23:07:17 +1000 >Received: from data.staff.apnic.net (data.apnic.net [202.12.29.247])by hadrian.staff.apnic.net (8.9.3/8.9.3) with ESMTP id XAA13165;Mon, 11 Mar 2002 23:11:23 +1000 (EST) >Received: (from majordom at localhost)by data.staff.apnic.net (8.10.1/8.10.1) id g2BD5h309508;Mon, 11 Mar 2002 23:05:43 +1000 (EST) >X-Authentication-Warning: data.staff.apnic.net: majordom set sender to owner-global-v6 at lists.apnic.net using -f >Received: from cumin.apnic.net (cumin.apnic.net [202.12.29.59])by data.staff.apnic.net (8.10.1/8.10.1) with ESMTP id g2BD5ff09504for ; Mon, 11 Mar 2002 23:05:41 +1000 (EST) >Received: from mail.gblx.ad.jp (mail.gblx.ad.jp [203.192.133.6])by cumin.apnic.net (8.12.1/8.12.1) with ESMTP id g2BD72c2016410for ; Mon, 11 Mar 2002 23:07:03 +1000 >Received: from TAARANO02.gblx.ad.jp (kujira [203.192.128.6])by mail.gblx.ad.jp (8.10.2+Sun/3.7W00120817) with ESMTP id g2BDBAe00489for ; Mon, 11 Mar 2002 22:11:10 +0900 (JST) >Message-Id: <4.3.2-J.20020311220313.053e5088 at mail.gblx.ad.jp> >X-Sender: tarano at mail.gblx.ad.jp >X-Mailer: QUALCOMM Windows Eudora Version 4.3.2-J >Date: Mon, 11 Mar 2002 22:11:46 +0900 >To: global-v6 at lists.apnic.net >From: Takashi Arano >Subject: [GLOBAL-V6] Consensus in AP region >Mime-Version: 1.0 >Content-Type: text/plain; charset="us-ascii" >X-Scanned-By: MIMEDefang 2.1 (www dot roaringpenguin dot com slash mimedefang) >X-Scanned-By: MIMEDefang 2.1 (www dot roaringpenguin dot com slash mimedefang) >Sender: owner-global-v6 at lists.apnic.net >Precedence: bulk > >Hi, > >Policy amendment was proposed in the APNIC Address Policy SIG >from the global IPv6 policy editorial team and the current >draft (dated 12/22) with this amendment was supported >as AP region consensus. > >In the meeting, three issues were identified through efforts >to summarize continuing discussion in RIPE41 and the global >mailing list. Those were; > >1) Initial allocation criteria >2) Do we continue to use HD-Ratio? >3) Are requirements of LIR's sub-allocation appropriate? > >Regarding 1), the editorial team proposed an amendment >which would replace Section 5.2.1 of the original draft. >See the below in this mail. > >We spent one and a half hour for discussion. >During discussion, more issues other than these were raised >but finally they were withdrawn, considering the priority >for moving forward. > >To the end, each of the issues was supported by the show of hands. >More clearly, > >Consensus 1) the amendment below was accepted >Consensus 2) Yes, HD-ratio should be used as the draft shows >Consensus 3) Yes, requirements in the draft are okay. > >Finally, I, as the chair, asked participants for voting >the whole draft with the amendment and found this reached >the consensus of AP region consensus. > >I hope quick resolution with good discussion >in both ARIN and RIPE meeting (of course as well as in >the mailing list) would be appreciated. > >Please review the following and give any feedback. Thanks. > >Regards, >Takashi Arano >--------------------------------- > > >Start of proposed text >================ > >5.2.1. Initial allocation criteria > >In order to reduce address space fragmentation and increase the >likelyhood that routes can be aggregated, end sites should obtain >address space from their connectivity providers as opposed to directly >from RIR/NIRs. Having RIR/NIRs assign address space directly to end >sites in general is known to lead to unscalable routing, since the >routes to those end sites will not aggregate. Thus, allocations of >large address blocks (i.e., much larger than /48s) are made to >organizations that assign /48s to organizations other than itself, and >also provide connectivity for those organizations. Specifically: > >- Organizations requesting address space must be an LIR. (see Section > 2.6). > >- Organizations requesting address space must not be end sites. > >- Organizations requesting address space will provide connectivity for > the organizations it has assigned /48s to by advertising such > connectivity through the single aggregate allocated to that > organization. > >- Organizations requesting address space have a plan for assigning > address space (e.g., /48s) to other organizations, with the number > of such assignments likely to result in at least 200 such > assignments over the next two years. > >- Organizations who are granted initial allocations, but after two > years no longer satisfy the requirements above, are subject to > having their allocations revoked. > >================ >End proposed text > >Note: Section 2.6 defines LIR as follows: > >2.6. Local Internet Registry (LIR) > > A Local Internet Registry (LIR) is an IR that primarily assigns > address space to the users of the network services that it provides. > LIRs are generally ISPs, whose customers are primarily end users and > possibly other ISPs. > >------------------------------------------- > >- >- This list (global-v6) is handled by majordomo at lists.apnic.net From stephenb at uk.uu.net Thu Apr 11 10:47:50 2002 From: stephenb at uk.uu.net (Stephen Burley) Date: Thu, 11 Apr 2002 09:47:50 +0100 Subject: Draft Agenda for LIR WG at RIPE42 References: Message-ID: <013b01c1e135$8fc938d0$2e04bf3e@eu.frd.uu.net> > F.3 "MIR/SUB-LIR" Proposal (WG action from RIPE40) > > http://www.ripe.net/ripe/mail-archives/lir-wg/20010701-20020101/msg00138.htm l > > Is this still needed following the implementation of "status: > LIR-PARTITIONED" (documentation) or do we still need a more > hierarchical allocation scheme (policy)? > As far as it goes the LIR-PARTITIONED status does not address our needs for a more structured allocation/assignment policy. From hostmaster at ripe.net Thu Apr 11 13:05:06 2002 From: hostmaster at ripe.net (RIPE NCC Hostmaster) Date: Thu, 11 Apr 2002 13:05:06 +0200 Subject: Current wait times Message-ID: <200204111105.g3BB56u03568@birch.ripe.net> Dear Colleagues, As you are probably aware, the period of time you are waiting for a first reply to your requests and queries has risen recently. Current wait times for the and mail boxes are running at over two weeks. We understand that this is very inconvenient for you and want to keep you informed as to the reasons and our actions to improve the situation. There are three key factors in the rise of the wait queues: Firstly, the number of tickets opened by LIRs during the first three months of 2002 was approximately 6% higher than that period in 2001. Secondly, the number of mergers and closures of LIRs have more than doubled and their complexity has risen. We are seeing far more mergers involving six or more LIRs. Fuller details will be presented at the next RIPE meeting (RIPE42, 29 April - 3 May 2002 in Amsterdam). Finally, the "criteria for an initial /20 PA allocation" policy implemented in November 2001 has placed an additional load on our New-LIR Co-ordinators. The combination of these three factors has had a negative impact on the service we aim to provide our membership. We are currently streamlining our processes and reviewing our internal procedures. Additional and revised documentation of policies and procedures will be published shortly. We look forward to seeing you at the next RIPE meeting in Amsterdam. A full report from the RIPE NCC Registration Services will be given in the LIR Working Group session on Wednesday morning, 1 May 2002. Kind regards, Dominic Spratley Registration Services Assistant Manager From stephenb at uk.uu.net Thu Apr 11 15:58:45 2002 From: stephenb at uk.uu.net (Stephen Burley) Date: Thu, 11 Apr 2002 14:58:45 +0100 Subject: Current wait times References: <200204111105.g3BB56u03568@birch.ripe.net> Message-ID: <03d601c1e160$ff0ff370$2e04bf3e@eu.frd.uu.net> Hmmm....i seem to remember a solution which was worked on by the task force which would have meant this sort of announcement never happening again. I think its time this proposal which achieved concensus in the meeting is implemented without further delay, regardless of what the managment may or may not think is best for the community. The community tasked the NCC with the implementation with the building of a automated approval robot which was detailed in the taskforces proposal, then for some reason managment made a unilateral decision to not do as the community asked. Please it is clear the current measures to reduce the wait queue are no working so lets go back to what was asked of the NCC before it gets out of control again. I can find the related documentation if the community would like? Regards, Stephen Burley WorldCom EMEA Hostmaster SB855-RIPE ----- Original Message ----- From: "RIPE NCC Hostmaster" To: Sent: Thursday, April 11, 2002 12:05 PM Subject: Current wait times > > Dear Colleagues, > > As you are probably aware, the period of time you are waiting for a first > reply to your requests and queries has risen recently. Current wait times > for the > > > and > > mail boxes are running at over two weeks. We understand that this is very > inconvenient for you and want to keep you informed as to the reasons and > our actions to improve the situation. > > There are three key factors in the rise of the wait queues: > > Firstly, the number of tickets opened by LIRs during the first three > months of 2002 was approximately 6% higher than that period in 2001. > > Secondly, the number of mergers and closures of LIRs have more than > doubled and their complexity has risen. We are seeing far more mergers > involving six or more LIRs. Fuller details will be presented at the next > RIPE meeting (RIPE42, 29 April - 3 May 2002 in Amsterdam). > > Finally, the "criteria for an initial /20 PA allocation" policy > implemented in November 2001 has placed an additional load on our > New-LIR Co-ordinators. > > The combination of these three factors has had a negative impact on the > service we aim to provide our membership. We are currently streamlining > our processes and reviewing our internal procedures. Additional and > revised documentation of policies and procedures will be published > shortly. > > We look forward to seeing you at the next RIPE meeting in Amsterdam. A > full report from the RIPE NCC Registration Services will be given in the > LIR Working Group session on Wednesday morning, 1 May 2002. > > Kind regards, > > Dominic Spratley > Registration Services Assistant Manager > From rumy at ripe.net Thu Apr 11 16:56:53 2002 From: rumy at ripe.net (Rumy Kanis) Date: Thu, 11 Apr 2002 16:56:53 +0200 Subject: RIPE 42 - IP Request Tutorial announcement Message-ID: <200204111456.g3BEusu10566@birch.ripe.net> Dear Colleagues, During the RIPE 42 Meeting, an "IP Request Tutorial" will be held on Monday, 29 April 2002, from 14:00 - 17:30. The goal of the "IP Request Tutorial" is to explain address space assignment and allocation procedures. It contains selected parts from the LIR course that the RIPE NCC provides to its members: How to Interact with the RIPE Whois Database How to Request Address Space - Completing the Request Form - Evaluation Assignment Window PI Assignments It is not necessary to register. All RIPE meeting participants are more than welcome to attend this tutorial. More information about the course that the RIPE NCC offers to its members is available at: http://www.ripe.net/training/ Material will soon be available at the RIPE Meeting web pages: http://www.ripe.net/ripe/meetings/current/ripe-42/tutorials/ip_request.html Kind regards, Rumy o-----------------------------------o | Rumy Kanis rumy at ripe.net | | Training Team Leader | | | | RIPE NCC tel. +31 20 535 4444 | | www.ripe.net | o-----------------------------------o From stephenb at uk.uu.net Fri Apr 12 13:20:45 2002 From: stephenb at uk.uu.net (Stephen Burley) Date: Fri, 12 Apr 2002 12:20:45 +0100 Subject: CAll for action - PLEASE READ Message-ID: <04e101c1e214$175b3080$2e04bf3e@eu.frd.uu.net> Hi Me again I know half of you are say shut up and go away and the rest just do not care, well I have no where else to go and I think everyone should care about our community. Yesterday I replied to the hostmaster email which contained nothing but excuses for what has been an abysmal service on the hostmaster queue I will get to that later. First I would like to say to the hostmaster in general those who know me and those who do not, you are the backbone of our community and you do a fine job...most of the time ;), and this email is in no way aimed at the hostmasters, it is aimed at the management of the NCC. RIPE fundamental truth number 1 - The NCC is there to work for the BENEFIT of the RIPE community at large. RIPE fundamental truth number 2 - We the RIPE community do not expect the NCC staff to do this out of love but are charged a SERVICE fee which enables the NCC to staff competent, intelligent hostmasters equal to the task at hand. So lets look at the facts. How many people work for the NCC 100 approx? How many are working as hostmasters 27? I do not see the lack of staffing, what I do see is a shift in priorities. All NCC staff members should be trained on the hostmaster desk for at least 6 months or until they are a competent hostmaster and can make correct decisions on requests. All NCC staff should spend a week every 6 months answering queries so they never lose their hostmaster skill. Throwing more staff at the wait queue problem is not the answer we have the staff at the NCC they are just not used when needed to help with increased work loads. Question - How many times has the wait queue ever been at an acceptable level 3 days max? Notice I said max not minimum, requests should not be in the queue longer than 3 days even this would be excessive in my view. In the current climate order to revenue needs to be as short as possible and if we have to build into the order process a possible 10 day delay that is unacceptable, we should be able to build in to our order processes a standard response time for all requests. And remember the wait queue list only measures how long before the initial response it does not account for the email conversation between hostmasters which could mean anything upto a week or more. So lets go back to the email we received giving us excuses for the pitiful turnaround times: 1. Firstly, the number of tickets opened by LIRs during the first three months of 2002 was approximately 6% higher than that period in 2001. I am sorry this is bad management it is obvious this increase would happen why was it not planned for? We work on the internet which has not stopped growing or had that escaped managements notice ;) 2. Secondly, the number of mergers and closures of LIRs have more than doubled and their complexity has risen. We are seeing far more mergers involving six or more LIRs. Fuller details will be presented at the next RIPE meeting (RIPE42, 29 April - 3 May 2002 in Amsterdam). And? This in no way should have any impact on the rest of the community - bad management! 3. Finally, the "criteria for an initial /20 PA allocation" policy implemented in November 2001 has placed an additional load on our New-LIR Co-ordinators. Now this is possibly the worst, since the NCC came up with this policy it would have seemed obvious to the world that this would increase the load on the hostmasters apart from the NCC management as they did not planned for it. They are not reasons they are excuses for bad management and far from excusing the hostmasters for not doing their job (because they are) if firmly points the finger at bad management and a lack of prioritising. The NCC has the resources to get the wait queue under control they are not being used. When was the last time Axel approved a request? If management do not see the wait queue as a major problem we are in trouble. If management do see the problem why are all hands not on the pumps (ALL)? I am not going to even start on the task force findings and ask what has been done and what has not been done it just frustrates our efforts. To summarise: A. ALL NCC staff should be trained on the hostmaster queue. B. ALL NCC staff should help with excessive wait queues 3 days +. C. If the above is not acceptable I would remind the community of the 2 fundamental truths stated at the start of this email. D. If A and B do not solve the problem then we look to changing the workflow process i.e.. adding an automated approval system with proper audit tracking and processes as detail by the task force or arrange another task force paid by the NCC this time. http://www.ripe.net/ripe/meetings/archive/ripe-39/presentations/lir-wg39-ple naryreport/sld012.html This problem has reared its head too many times, its now time to listen to the community and do what they ask, you the NCC have given us your assurance this would be brought under control and have failed every time. Have a look at APnic, they would never have a wait queue longer than 3 days, and if ARIN had the wait queue we have the Americans would be calling for legal action. Why should we put up with a second rate service? It used to be RIPE was the registry which showed the way it should be done, i think it may have been side tracked. Lets get this one solved once and for all time!! Regards Stephen Burley WorldCom EMEA Hostmaster SB855-RIPE From peter.galbavy at knowtion.net Fri Apr 12 14:10:24 2002 From: peter.galbavy at knowtion.net (Peter Galbavy) Date: Fri, 12 Apr 2002 13:10:24 +0100 Subject: CAll for action - PLEASE READ References: <04e101c1e214$175b3080$2e04bf3e@eu.frd.uu.net> Message-ID: <009601c1e21b$06e72310$2728a8c0@carpenter> For what it is worth, I as a >paying< RIPE member completely agree. RIPE appears to have strayed off track, and the NCC should be the primary role of RIPE - that we after all fund. Other activities seem to have taken over to the detriment of the NCC functions. I am unable to attend the next couple of meetings, but if there is a motion to 'order' the RIPE management to re-evaluate and act on member sentiments like this, then at least three registries I represent (all small) are in favour. Peter ----- Original Message ----- From: "Stephen Burley" To: Sent: Friday, April 12, 2002 12:20 PM Subject: CAll for action - PLEASE READ > Hi > Me again I know half of you are say shut up and go away and the rest > just do not care, well I have no where else to go and I think everyone > should care about our community. > Yesterday I replied to the hostmaster email which contained nothing but > excuses for what has been an abysmal service on the hostmaster queue I will > get to that later. First I would like to say to the hostmaster in general > those who know me and those who do not, you are the backbone of our > community and you do a fine job...most of the time ;), and this email is in > no way aimed at the hostmasters, it is aimed at the management of the NCC. > > RIPE fundamental truth number 1 - The NCC is there to work for the > BENEFIT of the RIPE community at large. > RIPE fundamental truth number 2 - We the RIPE community do not expect > the NCC staff to do this out of love but are charged a SERVICE fee which > enables the NCC to staff competent, intelligent hostmasters equal to the > task at hand. > > So lets look at the facts. How many people work for the NCC 100 approx? > How many are working as hostmasters 27? I do not see the lack of staffing, > what I do see is a shift in priorities. All NCC staff members should be > trained on the hostmaster desk for at least 6 months or until they are a > competent hostmaster and can make correct decisions on requests. All NCC > staff should spend a week every 6 months answering queries so they never > lose their hostmaster skill. Throwing more staff at the wait queue problem > is not the answer we have the staff at the NCC they are just not used when > needed to help with increased work loads. > Question - How many times has the wait queue ever been at an acceptable > level 3 days max? Notice I said max not minimum, requests should not be in > the queue longer than 3 days even this would be excessive in my view. In the > current climate order to revenue needs to be as short as possible and if we > have to build into the order process a possible 10 day delay that is > unacceptable, we should be able to build in to our order processes a > standard response time for all requests. And remember the wait queue list > only measures how long before the initial response it does not account for > the email conversation between hostmasters which could mean anything upto a > week or more. > So lets go back to the email we received giving us excuses for the > pitiful turnaround times: > > 1. Firstly, the number of tickets opened by LIRs during the first three > months of 2002 was approximately 6% higher than that period in 2001. > > I am sorry this is bad management it is obvious this increase would happen > why was it not planned for? We work on the internet which has not stopped > growing or had that escaped managements notice ;) > > 2. Secondly, the number of mergers and closures of LIRs have more than > doubled and their complexity has risen. We are seeing far more mergers > involving six or more LIRs. Fuller details will be presented at the next > RIPE meeting (RIPE42, 29 April - 3 May 2002 in Amsterdam). > > And? This in no way should have any impact on the rest of the community - > bad management! > > 3. Finally, the "criteria for an initial /20 PA allocation" policy > implemented in November 2001 has placed an additional load on our > New-LIR Co-ordinators. > > Now this is possibly the worst, since the NCC came up with this policy it > would have seemed obvious to the world that this would increase the load on > the hostmasters apart from the NCC management as they did not planned for > it. > > They are not reasons they are excuses for bad management and far from > excusing the hostmasters for not doing their job (because they are) if > firmly points the finger at bad management and a lack of prioritising. > The NCC has the resources to get the wait queue under control they are > not being used. When was the last time Axel approved a request? If > management do not see the wait queue as a major problem we are in trouble. > If management do see the problem why are all hands not on the pumps (ALL)? I > am not going to even start on the task force findings and ask what has been > done and what has not been done it just frustrates our efforts. > > To summarise: > A. ALL NCC staff should be trained on the hostmaster queue. > B. ALL NCC staff should help with excessive wait queues 3 days +. > C. If the above is not acceptable I would remind the community of the 2 > fundamental truths stated at the start of this email. > D. If A and B do not solve the problem then we look to changing the workflow > process i.e.. adding an automated approval system with proper audit tracking > and processes as detail by the task force or arrange another task force paid > by the NCC this time. > http://www.ripe.net/ripe/meetings/archive/ripe-39/presentations/lir-wg39-ple > naryreport/sld012.html > > This problem has reared its head too many times, its now time to listen to > the community and do what they ask, you the NCC have given us your assurance > this would be brought under control and have failed every time. Have a look > at APnic, they would never have a wait queue longer than 3 days, and if ARIN > had the wait queue we have the Americans would be calling for legal action. > Why should we put up with a second rate service? It used to be RIPE was the > registry which showed the way it should be done, i think it may have been > side tracked. > > Lets get this one solved once and for all time!! > > Regards > > > > > Stephen Burley > WorldCom EMEA Hostmaster > SB855-RIPE > > From per at swip.net Fri Apr 12 14:18:37 2002 From: per at swip.net (Per Lundberg) Date: Fri, 12 Apr 2002 14:18:37 +0200 (MET DST) Subject: CAll for action - PLEASE READ In-Reply-To: <04e101c1e214$175b3080$2e04bf3e@eu.frd.uu.net> Message-ID: Hi Stephen et al, I fully support your view and the items you pointed out, and are quite curious on the NCC's reply. /Per On Fri, 12 Apr 2002, Stephen Burley wrote: > Hi > Me again I know half of you are say shut up and go away and the rest > just do not care, well I have no where else to go and I think everyone > should care about our community. > Yesterday I replied to the hostmaster email which contained nothing but > excuses for what has been an abysmal service on the hostmaster queue I will > get to that later. First I would like to say to the hostmaster in general > those who know me and those who do not, you are the backbone of our > community and you do a fine job...most of the time ;), and this email is in > no way aimed at the hostmasters, it is aimed at the management of the NCC. > > RIPE fundamental truth number 1 - The NCC is there to work for the > BENEFIT of the RIPE community at large. > RIPE fundamental truth number 2 - We the RIPE community do not expect > the NCC staff to do this out of love but are charged a SERVICE fee which > enables the NCC to staff competent, intelligent hostmasters equal to the > task at hand. > > So lets look at the facts. How many people work for the NCC 100 approx? > How many are working as hostmasters 27? I do not see the lack of staffing, > what I do see is a shift in priorities. All NCC staff members should be > trained on the hostmaster desk for at least 6 months or until they are a > competent hostmaster and can make correct decisions on requests. All NCC > staff should spend a week every 6 months answering queries so they never > lose their hostmaster skill. Throwing more staff at the wait queue problem > is not the answer we have the staff at the NCC they are just not used when > needed to help with increased work loads. > Question - How many times has the wait queue ever been at an acceptable > level 3 days max? Notice I said max not minimum, requests should not be in > the queue longer than 3 days even this would be excessive in my view. In the > current climate order to revenue needs to be as short as possible and if we > have to build into the order process a possible 10 day delay that is > unacceptable, we should be able to build in to our order processes a > standard response time for all requests. And remember the wait queue list > only measures how long before the initial response it does not account for > the email conversation between hostmasters which could mean anything upto a > week or more. > So lets go back to the email we received giving us excuses for the > pitiful turnaround times: > > 1. Firstly, the number of tickets opened by LIRs during the first three > months of 2002 was approximately 6% higher than that period in 2001. > > I am sorry this is bad management it is obvious this increase would happen > why was it not planned for? We work on the internet which has not stopped > growing or had that escaped managements notice ;) > > 2. Secondly, the number of mergers and closures of LIRs have more than > doubled and their complexity has risen. We are seeing far more mergers > involving six or more LIRs. Fuller details will be presented at the next > RIPE meeting (RIPE42, 29 April - 3 May 2002 in Amsterdam). > > And? This in no way should have any impact on the rest of the community - > bad management! > > 3. Finally, the "criteria for an initial /20 PA allocation" policy > implemented in November 2001 has placed an additional load on our > New-LIR Co-ordinators. > > Now this is possibly the worst, since the NCC came up with this policy it > would have seemed obvious to the world that this would increase the load on > the hostmasters apart from the NCC management as they did not planned for > it. > > They are not reasons they are excuses for bad management and far from > excusing the hostmasters for not doing their job (because they are) if > firmly points the finger at bad management and a lack of prioritising. > The NCC has the resources to get the wait queue under control they are > not being used. When was the last time Axel approved a request? If > management do not see the wait queue as a major problem we are in trouble. > If management do see the problem why are all hands not on the pumps (ALL)? I > am not going to even start on the task force findings and ask what has been > done and what has not been done it just frustrates our efforts. > > To summarise: > A. ALL NCC staff should be trained on the hostmaster queue. > B. ALL NCC staff should help with excessive wait queues 3 days +. > C. If the above is not acceptable I would remind the community of the 2 > fundamental truths stated at the start of this email. > D. If A and B do not solve the problem then we look to changing the workflow > process i.e.. adding an automated approval system with proper audit tracking > and processes as detail by the task force or arrange another task force paid > by the NCC this time. > http://www.ripe.net/ripe/meetings/archive/ripe-39/presentations/lir-wg39-ple > naryreport/sld012.html > > This problem has reared its head too many times, its now time to listen to > the community and do what they ask, you the NCC have given us your assurance > this would be brought under control and have failed every time. Have a look > at APnic, they would never have a wait queue longer than 3 days, and if ARIN > had the wait queue we have the Americans would be calling for legal action. > Why should we put up with a second rate service? It used to be RIPE was the > registry which showed the way it should be done, i think it may have been > side tracked. > > Lets get this one solved once and for all time!! > > Regards > > > > > Stephen Burley > WorldCom EMEA Hostmaster > SB855-RIPE > > -- V?nligen Per DNS/IP Registry - - - - - - - - - Swedish IP Network - - - - - - - - - Tele2AB/Swipnet e-mail: per at swip.net Box 62 direct: +46 8 5626 4579 164 94 KISTA gsm: +46 704 26 4579 Sweden fax: +46 8 5626 4210 From neil at COLT.NET Fri Apr 12 14:35:19 2002 From: neil at COLT.NET (Neil J. McRae) Date: Fri, 12 Apr 2002 13:35:19 +0100 Subject: CAll for action - PLEASE READ In-Reply-To: Message-ID: I agree with Stephen, perhaps less time spent on the rediculous week long RIPE meetings and more focus on the registry. I find it hard to believe that the RIPE has not taken stock in the current climate to re-organise its activities. Regards, Neil -- Neil J. McRae - COLT neil at COLT.NET From theimes at de.cw.net Fri Apr 12 15:18:33 2002 From: theimes at de.cw.net (Tanja Heimes) Date: Fri, 12 Apr 2002 15:18:33 +0200 Subject: CAll for action - PLEASE READ References: Message-ID: <3CB6DEA9.53AD6807@de.cw.net> Hi All, I completely agree with Stephens mail. The long queue time is seriously affecting my workflow. Tanja Heimes Per Lundberg wrote: > > Hi Stephen et al, > > I fully support your view and the items you pointed out, and are quite > curious on the NCC's reply. > > /Per > > On Fri, 12 Apr 2002, Stephen Burley wrote: > > > Hi > > Me again I know half of you are say shut up and go away and the rest > > just do not care, well I have no where else to go and I think everyone > > should care about our community. > > Yesterday I replied to the hostmaster email which contained nothing but > > excuses for what has been an abysmal service on the hostmaster queue I will > > get to that later. First I would like to say to the hostmaster in general > > those who know me and those who do not, you are the backbone of our > > community and you do a fine job...most of the time ;), and this email is in > > no way aimed at the hostmasters, it is aimed at the management of the NCC. > > > > RIPE fundamental truth number 1 - The NCC is there to work for the > > BENEFIT of the RIPE community at large. > > RIPE fundamental truth number 2 - We the RIPE community do not expect > > the NCC staff to do this out of love but are charged a SERVICE fee which > > enables the NCC to staff competent, intelligent hostmasters equal to the > > task at hand. > > > > So lets look at the facts. How many people work for the NCC 100 approx? > > How many are working as hostmasters 27? I do not see the lack of staffing, > > what I do see is a shift in priorities. All NCC staff members should be > > trained on the hostmaster desk for at least 6 months or until they are a > > competent hostmaster and can make correct decisions on requests. All NCC > > staff should spend a week every 6 months answering queries so they never > > lose their hostmaster skill. Throwing more staff at the wait queue problem > > is not the answer we have the staff at the NCC they are just not used when > > needed to help with increased work loads. > > Question - How many times has the wait queue ever been at an acceptable > > level 3 days max? Notice I said max not minimum, requests should not be in > > the queue longer than 3 days even this would be excessive in my view. In the > > current climate order to revenue needs to be as short as possible and if we > > have to build into the order process a possible 10 day delay that is > > unacceptable, we should be able to build in to our order processes a > > standard response time for all requests. And remember the wait queue list > > only measures how long before the initial response it does not account for > > the email conversation between hostmasters which could mean anything upto a > > week or more. > > So lets go back to the email we received giving us excuses for the > > pitiful turnaround times: > > > > 1. Firstly, the number of tickets opened by LIRs during the first three > > months of 2002 was approximately 6% higher than that period in 2001. > > > > I am sorry this is bad management it is obvious this increase would happen > > why was it not planned for? We work on the internet which has not stopped > > growing or had that escaped managements notice ;) > > > > 2. Secondly, the number of mergers and closures of LIRs have more than > > doubled and their complexity has risen. We are seeing far more mergers > > involving six or more LIRs. Fuller details will be presented at the next > > RIPE meeting (RIPE42, 29 April - 3 May 2002 in Amsterdam). > > > > And? This in no way should have any impact on the rest of the community - > > bad management! > > > > 3. Finally, the "criteria for an initial /20 PA allocation" policy > > implemented in November 2001 has placed an additional load on our > > New-LIR Co-ordinators. > > > > Now this is possibly the worst, since the NCC came up with this policy it > > would have seemed obvious to the world that this would increase the load on > > the hostmasters apart from the NCC management as they did not planned for > > it. > > > > They are not reasons they are excuses for bad management and far from > > excusing the hostmasters for not doing their job (because they are) if > > firmly points the finger at bad management and a lack of prioritising. > > The NCC has the resources to get the wait queue under control they are > > not being used. When was the last time Axel approved a request? If > > management do not see the wait queue as a major problem we are in trouble. > > If management do see the problem why are all hands not on the pumps (ALL)? I > > am not going to even start on the task force findings and ask what has been > > done and what has not been done it just frustrates our efforts. > > > > To summarise: > > A. ALL NCC staff should be trained on the hostmaster queue. > > B. ALL NCC staff should help with excessive wait queues 3 days +. > > C. If the above is not acceptable I would remind the community of the 2 > > fundamental truths stated at the start of this email. > > D. If A and B do not solve the problem then we look to changing the workflow > > process i.e.. adding an automated approval system with proper audit tracking > > and processes as detail by the task force or arrange another task force paid > > by the NCC this time. > > http://www.ripe.net/ripe/meetings/archive/ripe-39/presentations/lir-wg39-ple > > naryreport/sld012.html > > > > This problem has reared its head too many times, its now time to listen to > > the community and do what they ask, you the NCC have given us your assurance > > this would be brought under control and have failed every time. Have a look > > at APnic, they would never have a wait queue longer than 3 days, and if ARIN > > had the wait queue we have the Americans would be calling for legal action. > > Why should we put up with a second rate service? It used to be RIPE was the > > registry which showed the way it should be done, i think it may have been > > side tracked. > > > > Lets get this one solved once and for all time!! > > > > Regards > > > > > > > > > > Stephen Burley > > WorldCom EMEA Hostmaster > > SB855-RIPE > > > > > > -- > V?nligen > Per > DNS/IP Registry > - - - - - - - - - Swedish IP Network - - - - - - - - - > Tele2AB/Swipnet e-mail: per at swip.net > Box 62 direct: +46 8 5626 4579 > 164 94 KISTA gsm: +46 704 26 4579 > Sweden fax: +46 8 5626 4210 -- Tanja Heimes / IP Engineer E-Mail Tanja.Heimes at de.cw.com Cable & Wireless Deutschland GmbH TEL. + 49 89 92699-0 Landsberger Strasse 155 Fax. + 49 89 92699-810 D-80687 Munich, Germany web: http://www.cw.com/de From alfredo at intelideas.com Fri Apr 12 16:46:13 2002 From: alfredo at intelideas.com (Alfredo Sola) Date: Fri, 12 Apr 2002 16:46:13 +0200 Subject: CAll for action - PLEASE READ References: <04e101c1e214$175b3080$2e04bf3e@eu.frd.uu.net> Message-ID: <3CB6F335.70F71D04@intelideas.com> Hi, Besides agreeing for the most part, I specially appreciate and support your point in going further and suggesting a solution. The drawback I can see with your proposal for the audit is, can you imagine an allocation being auto-approved then taken back as a result of a probably very correct audit? I fail to see all the factors contributing to the long queue. It's probably the hostmasters and management themselves who know better, so we could as well try to work with them to a solution. That should include the objective we want to get to, in order to avoid falling again in the same problem. The three days target seems reasonable enough to me at this time (from a LIR p-o-v). > D. If A and B do not solve the problem then we look to changing the workflow > process i.e.. adding an automated approval system with proper audit tracking > and processes as detail by the task force or arrange another task force paid > by the NCC this time. > http://www.ripe.net/ripe/meetings/archive/ripe-39/presentations/lir-wg39-ple > naryreport/sld012.html -- Alfredo Sola Director tecnico From hank at att.net.il Fri Apr 12 17:59:06 2002 From: hank at att.net.il (Hank Nussbacher) Date: Fri, 12 Apr 2002 18:59:06 +0300 (IDT) Subject: CAll for action - PLEASE READ In-Reply-To: <04e101c1e214$175b3080$2e04bf3e@eu.frd.uu.net> Message-ID: On Fri, 12 Apr 2002, Stephen Burley wrote: One small correction to what I agree with: it should be 3 business day turnaround and not 3 day turnaround. NCC should publish someplace on its page the official days they are closed in Amsterdam so we know what to expect. -Hank > Hi > Me again I know half of you are say shut up and go away and the rest > just do not care, well I have no where else to go and I think everyone > should care about our community. > Yesterday I replied to the hostmaster email which contained nothing but > excuses for what has been an abysmal service on the hostmaster queue I will > get to that later. First I would like to say to the hostmaster in general > those who know me and those who do not, you are the backbone of our > community and you do a finejob...most of the time ;), and this email is in > no way aimed at the hostmasters, it is aimed at the management of the NCC. > > RIPE fundamental truth number 1 - The NCC is there to work for the > BENEFIT of the RIPE community at large. > RIPE fundamental truth number 2 - We the RIPE community do not expect > the NCC staff to do this out of love but are charged a SERVICE fee which > enables the NCC to staff competent, intelligent hostmasters equal to the > task at hand. > > So lets look at the facts. How many people work for the NCC 100 approx? > How many are working as hostmasters 27? I do not see the lack of staffing, > what I do see is a shift in priorities. All NCC staff members should be > trained on the hostmaster desk for at least 6 months or until they are a > competent hostmaster and can make correct decisions on requests. All NCC > staff should spend a week every 6 months answering queries so they never > lose their hostmaster skill. Throwing more staff at the wait queue problem > is not the answer we have the staff at the NCC they are just not used when > needed to help with increased work loads. > Question - How many times has the wait queue ever been at an acceptable > level 3 days max? Notice I said max not minimum, requests should not be in > the queue longer than 3 days even this would be excessive in my view. In the > current climate order to revenue needs to be as short as possible and if we > have to build into the order process a possible 10 day delay that is > unacceptable, we should be able to build in to our order processes a > standard response time for all requests. And remember the wait queue list > only measures how long before the initial response it does not account for > the email conversation between hostmasters which could mean anything upto a > week or more. > So lets go back to the email we received giving us excuses for the > pitiful turnaround times: > > 1.Firstly, the number of tickets opened by LIRs during the first three > months of 2002 was approximately 6% higher than that period in 2001. > > I am sorry this is bad management it is obvious this increase would happen > why was it not planned for? We work on the internet which has not stopped > growing or had that escaped managements notice ;) > > 2. Secondly, the number of mergers and closures of LIRs have more than > doubled and their complexity has risen. We are seeing far more mergers > involving six or more LIRs. Fuller details will be presented at the next > RIPE meeting (RIPE42, 29 April - 3 May 2002 in Amsterdam). > > And? This in no way should have any impact on the rest of the community - > bad management! > > 3.Finally, the "criteria for an initial /20 PA allocation" policy > implemented in November 2001 has placed an additional load on our > New-LIR Co-ordinators. > > Now this is possibly the worst, since the NCC came up with this policy it > would have seemed obvious to the world that this would increase the load on > the hostmasters apart from the NCC management as they did not planned for > it. > > They are not reasons they are excuses for bad management and far from > excusing the hostmasters for not doing their job (because they are) if > firmly points the finger at bad management and a lack of prioritising. > The NCC has the resources to get the wait queue under control they are > not being used. When was the last time Axel approved a request? If > management do not see the wait queue as a major problem we are in trouble. > If management do see the problem why are all hands not on the pumps (ALL)? I > am not going to even start on the task force findings and ask what has been > done and what has not been done it just frustrates our efforts. > > To summarise: > A. ALL NCC staff should be trained on the hostmaster queue. > B. ALL NCC staff should help with excessive wait queues 3 days +. > C. If the above is not acceptable I would remind the community of the 2 > fundamental truths stated at the start of this email. > D. If A and B do not solve the problem then we look to changing the workflow > process i.e.. adding an automated approval system with proper audit tracking > and processes as detail by the task force or arrange another task force paid > by the NCC this time. > http://www.ripe.net/ripe/meetings/archive/ripe-39/presentations/lir-wg39-ple > naryreport/sld012.html > > This problem has reared its head too many times, its now time to listen to > the community and do what they ask, you the NCC have given us your assurance > this would be brought under control and have failed every time. Have a look > at APnic, they would never have a wait queue longer than 3 days, and if ARIN > had the wait queue we have the Americans would be calling for legal action. > Why should we put up with a second rate service? It used to be RIPE was the > registry which showed the way it should be done, i think it may have been > side tracked. > > Lets get this one solved once and for all time!! > > Regards > > > > > Stephen Burley > WorldCom EMEA Hostmaster > SB855-RIPE > Hank Nussbacher From mir at ripe.net Fri Apr 12 19:01:38 2002 From: mir at ripe.net (Mirjam Kuehne) Date: Fri, 12 Apr 2002 17:01:38 +0000 Subject: Current wait times Message-ID: <200204121701.g3CH1cu08674@birch.ripe.net> Dear LIRs, Be assured that we take this matter very seriously and we are doing all we can to improve the situation. All suggestions made by the "17th May Task Force" and agreed by the LIR WG were implemented (since May 2001) and resulted in a significantly lower response time as you can see on the yearly Hostmaster Waitqueue graph (last graph on the following page): http://www.ripe.net/ripencc/mem-services/registration/rttqueue/rttwaitqueue.html Due to market developments (i.e. increase of mergers, take overs, closures) and unforeseen issues with the implementation of the new "Minimum Allocation Criteria" policy in November 2001 we experienced an unexpected high work load since mid January 2002 (as described in our previous mail). These factors appeared unfortunately at the same time. We are currently preparing a detailed report for you to be presented at the RIPE 42 Meeting. However, we are going to send a preliminary summary early next week to this list. Kind Regards, Mirjam Kuehne External Relations RIPE NCC From hph at online.no Sat Apr 13 10:25:06 2002 From: hph at online.no (Hans Petter Holen) Date: Sat, 13 Apr 2002 10:25:06 +0200 Subject: Current wait times References: <200204121701.g3CH1cu08674@birch.ripe.net> Message-ID: <007501c1e2c4$b7f86020$7900a8c0@no.tiscali.com> Mirjam, Thanks for allready acting on this matter. | We are currently preparing a detailed report for you to be presented | at the RIPE 42 Meeting. However, we are going to send a preliminary | summary early next week to this list. It would indeed be very good to have material circulated to the list, lets say two weeks before the meeting so that everybody could be perpared for this discussion. Hans Petter From algardo at sura.ru Sat Apr 13 15:55:37 2002 From: algardo at sura.ru (Aleksey Perov) Date: Sat, 13 Apr 2002 17:55:37 +0400 Subject: CAll for action - PLEASE READ In-Reply-To: <3CB6F335.70F71D04@intelideas.com> References: <04e101c1e214$175b3080$2e04bf3e@eu.frd.uu.net> <3CB6F335.70F71D04@intelideas.com> Message-ID: <20020413175537.1878875c.algardo@sura.ru> Hi, On Fri, 12 Apr 2002 16:46:13 +0200, Alfredo Sola wrote: > I fail to see all the factors contributing to the long queue. It's Well, let me guess. I looked at http://www.ripe.net/ripencc/about/staff/hm-staff.html and saw 18 hostmasters there. Then I looked at http://www.ripe.net/ripencc/mem-services/registration/rttqueue/rttwaitqueue.html and saw that last 12 months there was average 189 tickets in the hostmaster queue. So, 189/18 = 10.5. That is, every hostmaster always works with 10.5 requests. Next, on the second page we see that during last 12 months the average request processing time is 9.3 days. Assume that every hostmaster processes his/her requests somehow parallelly or sequentially, and this takes 9.3 days. For one request this is 9.3/10.5 = 0.89 days. I suppose this value is the real average _total_ amount of time that every request requires to be completed. So, if we want our requests to take 3 days, a hostmaster sould have 3/0.89 = 3.37 requests. Under last year's average NCC work load, there should be 189/3.37 = 56 hostmasters. Significant? No more significant than 3 days against 10. Another digits. I've just opened Slides Booklet taken from last LIR training courses and saw that currently NCC has 3100+ LIRs and 99 staff members (slide 10, "Vital Statistics"). This is 31+ LIRs (read: address spaces, ASNs, DB objects, problems, questions etc) to one staff member. How do you find it? Stephen wrote that he doesn't see the lack of staffing but I do. If someone's resources are not enough for his load, he should increase the resources. But looking at that 12-months statistics we see that the load of hostmaster staff varies from season to season. Obviously we should understand that the request processing time is below average in autumn and winter and is above average in spring and summer. Colleagues, let's be patient, good things don't come fast. -- Aleksey A. Perov Postmaster ALP215-RIPE JSC Svyazinform, Penza, Russia e-mail: algardo at sura.ru phone: +7 8412 520215 From hph at online.no Sat Apr 13 23:54:22 2002 From: hph at online.no (Hans Petter Holen) Date: Sat, 13 Apr 2002 23:54:22 +0200 Subject: CAll for action - PLEASE READ References: <04e101c1e214$175b3080$2e04bf3e@eu.frd.uu.net><3CB6F335.70F71D04@intelideas.com> <20020413175537.1878875c.algardo@sura.ru> Message-ID: <004001c1e335$c82f00e0$7900a8c0@no.tiscali.com> Hmm, I am not shure I understand your reasoning, I always tought * If the cueue increases there are to few hostmasters, or the hostmasters spend to long time on each request. * If the queue is long but not increasing, increasing the number of hostmasters will bring down the cueue to zero, but Possible fixes: - increase the number of hostmasters - lower the ammount of time spent on each request the first is simple, the second is more complex: - make the hostmasters work faster (better training, faster computers, other incentives) - simplify the procedures to make the work faster - simplify the policy so that the procedures could be simpler - clearify the policy/procedures so that the requests are resolved at first iteration rather than requiring a number of interactions to solve a problem - make the LIR staff sumitt better requests (better training, faster computers, cleverer people) >From looking at this from time to time, I don't think one single factor can solve the problem or bring us out of the situation we are in. -hph From hph at online.no Sun Apr 14 00:09:48 2002 From: hph at online.no (Hans Petter Holen) Date: Sun, 14 Apr 2002 00:09:48 +0200 Subject: CAll for action - PLEASE READ References: <04e101c1e214$175b3080$2e04bf3e@eu.frd.uu.net><3CB6F335.70F71D04@intelideas.com> <20020413175537.1878875c.algardo@sura.ru> <004001c1e335$c82f00e0$7900a8c0@no.tiscali.com> Message-ID: <005b01c1e337$edd7e4e0$7900a8c0@no.tiscali.com> Reading your mail again I seem to understand your maths, | Next, on the second page we see that during last 12 months the average | request processing time is 9.3 days. Assume that every hostmaster | processes his/her requests somehow parallelly or sequentially, and this | takes 9.3 days. For one request this is 9.3/10.5 = 0.89 days. Now this figure is interesting. I means that the average time spent on a request assuming 80 % efficiency and a 40 hour worrking week leaving 6,4 hours a day for productive work means 5 hours and 41 minutes pr request. Five hours and forty one minutes pr request on average is a fairly substantial figure. I would have assumed no more than 20 minutes as a goal and if we needed a couple iterations to sort things out I would say times 3-4 for the difficult ones were we need to cumunicate by email (or perhaps even by phone...) would leave the average below one hour. I would be very interested in figures from the RIPE NCC telling the true story on this. -hph From hph at online.no Sun Apr 14 00:09:57 2002 From: hph at online.no (Hans Petter Holen) Date: Sun, 14 Apr 2002 00:09:57 +0200 Subject: CAll for action - PLEASE READ References: <04e101c1e214$175b3080$2e04bf3e@eu.frd.uu.net><3CB6F335.70F71D04@intelideas.com> <20020413175537.1878875c.algardo@sura.ru> Message-ID: <005c01c1e337$f2a60ec0$7900a8c0@no.tiscali.com> ----- Original Message ----- From: "Aleksey Perov" To: Sent: Saturday, April 13, 2002 3:55 PM Subject: Re: CAll for action - PLEASE READ | Hi, | | On Fri, 12 Apr 2002 16:46:13 +0200, Alfredo Sola wrote: | | > I fail to see all the factors contributing to the long queue. It's | | Well, let me guess. I looked at | | http://www.ripe.net/ripencc/about/staff/hm-staff.html | | and saw 18 hostmasters there. Then I looked at | | http://www.ripe.net/ripencc/mem-services/registration/rttqueue/rttwaitqueue. html | | and saw that last 12 months there was average 189 tickets in the | hostmaster queue. So, 189/18 = 10.5. That is, every hostmaster always | works with 10.5 requests. | | Next, on the second page we see that during last 12 months the average | request processing time is 9.3 days. Assume that every hostmaster | processes his/her requests somehow parallelly or sequentially, and this | takes 9.3 days. For one request this is 9.3/10.5 = 0.89 days. I suppose | this value is the real average _total_ amount of time that every request | requires to be completed. So, if we want our requests to take 3 days, | a hostmaster sould have 3/0.89 = 3.37 requests. Under last year's average | NCC work load, there should be 189/3.37 = 56 hostmasters. Significant? | No more significant than 3 days against 10. | | Another digits. I've just opened Slides Booklet taken from last LIR | training courses and saw that currently NCC has 3100+ LIRs and 99 staff | members (slide 10, "Vital Statistics"). This is 31+ LIRs (read: address | spaces, ASNs, DB objects, problems, questions etc) to one staff member. | How do you find it? | | Stephen wrote that he doesn't see the lack of staffing but I do. If | someone's resources are not enough for his load, he should increase the | resources. | | But looking at that 12-months statistics we see that the load of | hostmaster staff varies from season to season. Obviously we should | understand that the request processing time is below average in autumn | and winter and is above average in spring and summer. Colleagues, let's | be patient, good things don't come fast. | | | | | -- | Aleksey A. Perov | Postmaster | ALP215-RIPE | JSC Svyazinform, Penza, Russia | e-mail: algardo at sura.ru | phone: +7 8412 520215 | From sam.bradford at demon.net Fri Apr 12 17:06:55 2002 From: sam.bradford at demon.net (Sam Bradford) Date: Fri, 12 Apr 2002 16:06:55 +0100 Subject: CAll for action - PLEASE READ In-Reply-To: References: <04e101c1e214$175b3080$2e04bf3e@eu.frd.uu.net> Message-ID: <20020412150655.GB53002@demon.net> On Fri, Apr 12, 2002, Hank Nussbacher (hank at att.net.il) typed: > One small correction to what I agree with: it should be 3 business day > turnaround and not 3 day turnaround. NCC should publish someplace > on its page the official days they are closed in Amsterdam so we know what > to expect. They already send out notification mails in advance of office closure... SamSam ----------------------------------------------------------------- sam bradford, hostmaster team leader sam.bradford at demon.net Demon Internet / Thus plc . hostmaster at demon.net Tel: +44-845-272-0666 . . http://www.demon.net/ Fax: +44-20-8371-1285 t h u s http://www.thus.net/ From fredrik at sunet.se Fri Apr 12 18:50:51 2002 From: fredrik at sunet.se (Fredrik Widell) Date: Fri, 12 Apr 2002 18:50:51 +0200 (CEST) Subject: CAll for action - PLEASE READ In-Reply-To: Message-ID: On Fri, 12 Apr 2002, Per Lundberg wrote: > Hi Stephen et al, > > I fully support your view and the items you pointed out, and are quite > curious on the NCC's reply. Agree!! > > /Per > > On Fri, 12 Apr 2002, Stephen Burley wrote: > > > Hi > > Me again I know half of you are say shut up and go away and the rest > > just do not care, well I have no where else to go and I think everyone > > should care about our community. > > Yesterday I replied to the hostmaster email which contained nothing but > > excuses for what has been an abysmal service on the hostmaster queue I will > > get to that later. First I would like to say to the hostmaster in general > > those who know me and those who do not, you are the backbone of our > > community and you do a fine job...most of the time ;), and this email is in > > no way aimed at the hostmasters, it is aimed at the management of the NCC. > > > > RIPE fundamental truth number 1 - The NCC is there to work for the > > BENEFIT of the RIPE community at large. > > RIPE fundamental truth number 2 - We the RIPE community do not expect > > the NCC staff to do this out of love but are charged a SERVICE fee which > > enables the NCC to staff competent, intelligent hostmasters equal to the > > task at hand. > > > > So lets look at the facts. How many people work for the NCC 100 approx? > > How many are working as hostmasters 27? I do not see the lack of staffing, > > what I do see is a shift in priorities. All NCC staff members should be > > trained on the hostmaster desk for at least 6 months or until they are a > > competent hostmaster and can make correct decisions on requests. All NCC > > staff should spend a week every 6 months answering queries so they never > > lose their hostmaster skill. Throwing more staff at the wait queue problem > > is not the answer we have the staff at the NCC they are just not used when > > needed to help with increased work loads. > > Question - How many times has the wait queue ever been at an acceptable > > level 3 days max? Notice I said max not minimum, requests should not be in > > the queue longer than 3 days even this would be excessive in my view. In the > > current climate order to revenue needs to be as short as possible and if we > > have to build into the order process a possible 10 day delay that is > > unacceptable, we should be able to build in to our order processes a > > standard response time for all requests. And remember the wait queue list > > only measures how long before the initial response it does not account for > > the email conversation between hostmasters which could mean anything upto a > > week or more. > > So lets go back to the email we received giving us excuses for the > > pitiful turnaround times: > > > > 1. Firstly, the number of tickets opened by LIRs during the first three > > months of 2002 was approximately 6% higher than that period in 2001. > > > > I am sorry this is bad management it is obvious this increase would happen > > why was it not planned for? We work on the internet which has not stopped > > growing or had that escaped managements notice ;) > > > > 2. Secondly, the number of mergers and closures of LIRs have more than > > doubled and their complexity has risen. We are seeing far more mergers > > involving six or more LIRs. Fuller details will be presented at the next > > RIPE meeting (RIPE42, 29 April - 3 May 2002 in Amsterdam). > > > > And? This in no way should have any impact on the rest of the community - > > bad management! > > > > 3. Finally, the "criteria for an initial /20 PA allocation" policy > > implemented in November 2001 has placed an additional load on our > > New-LIR Co-ordinators. > > > > Now this is possibly the worst, since the NCC came up with this policy it > > would have seemed obvious to the world that this would increase the load on > > the hostmasters apart from the NCC management as they did not planned for > > it. > > > > They are not reasons they are excuses for bad management and far from > > excusing the hostmasters for not doing their job (because they are) if > > firmly points the finger at bad management and a lack of prioritising. > > The NCC has the resources to get the wait queue under control they are > > not being used. When was the last time Axel approved a request? If > > management do not see the wait queue as a major problem we are in trouble. > > If management do see the problem why are all hands not on the pumps (ALL)? I > > am not going to even start on the task force findings and ask what has been > > done and what has not been done it just frustrates our efforts. > > > > To summarise: > > A. ALL NCC staff should be trained on the hostmaster queue. > > B. ALL NCC staff should help with excessive wait queues 3 days +. > > C. If the above is not acceptable I would remind the community of the 2 > > fundamental truths stated at the start of this email. > > D. If A and B do not solve the problem then we look to changing the workflow > > process i.e.. adding an automated approval system with proper audit tracking > > and processes as detail by the task force or arrange another task force paid > > by the NCC this time. > > http://www.ripe.net/ripe/meetings/archive/ripe-39/presentations/lir-wg39-ple > > naryreport/sld012.html > > > > This problem has reared its head too many times, its now time to listen to > > the community and do what they ask, you the NCC have given us your assurance > > this would be brought under control and have failed every time. Have a look > > at APnic, they would never have a wait queue longer than 3 days, and if ARIN > > had the wait queue we have the Americans would be calling for legal action. > > Why should we put up with a second rate service? It used to be RIPE was the > > registry which showed the way it should be done, i think it may have been > > side tracked. > > > > Lets get this one solved once and for all time!! > > > > Regards > > > > > > > > > > Stephen Burley > > WorldCom EMEA Hostmaster > > SB855-RIPE > > > > > > -- Mvh /Fredrik ------------------------------------------------------- KTHNOC, KTH, S-100 44 Stockholm, Sweden +46 8 790 65 17 ------------------------------------------------------- From stephenb at uk.uu.net Mon Apr 15 11:48:40 2002 From: stephenb at uk.uu.net (Stephen Burley) Date: Mon, 15 Apr 2002 10:48:40 +0100 Subject: Current wait times References: <200204121701.g3CH1cu08674@birch.ripe.net> Message-ID: <06e401c1e462$b97512f0$2e04bf3e@eu.frd.uu.net> Stephen Burley WorldCom EMEA Hostmaster SB855-RIPE > > Dear LIRs, > > Be assured that we take this matter very seriously and we are > doing all we can to improve the situation. > > All suggestions made by the "17th May Task Force" and agreed by > the LIR WG were implemented No they where not, the most major change suggested was the automated approval robot, which is not as bad as it sounds and was agreed at the lir-working group with a few caveats. It was modified with the task force before the plenary and represented threre, after a few comments we recieved consensus to implement ALL the task force findings, what happened after this point is something which still astounds me. Firstly nothing was said about the robot at the next ripe meeting in fact it was as if the proposal never even existed. On a closed mailing list (the task force list) i asked for an update on the robots implementation to which we had a reply telling us a detailed report would be sent to the list soon by Axel. When it arrived i was astonished to read that due to concernes raised by people to Axel in the COFFEE break and the LUNCH break, HE, Axel, made the desicion based on these concerns to not implement the robot. So Axel single handedly overrode the whole community by listening the peoples comments in the breaks. Which means that we do not need meetings to gain concensus just have one long coffee break with the odd lunch break to decide RIPE NCC policy. Needless to say the concerns that where listed where not founded and they where not even discussed with the task force. (since May 2001) and resulted in a > significantly lower response time as you can see on the yearly > Hostmaster Waitqueue graph (last graph on the following page): > > http://www.ripe.net/ripencc/mem-services/registration/rttqueue/rttwaitqueue. html > > Due to market developments (i.e. increase of mergers, take overs, > closures) and unforeseen issues with the implementation of the new I am sorry but this is still not a fair excuse, why should the NCC be involved in this to a great extent. We suffer because of none request related issues. > "Minimum Allocation Criteria" policy in November 2001 we experienced > an unexpected high work load since mid January 2002 (as described in > our previous mail). You did not describe why you failed to see what was obvious to the rest of the world. These factors appeared unfortunately at the same > time. > > We are currently preparing a detailed report for you to be presented > at the RIPE 42 Meeting. However, we are going to send a preliminary > summary early next week to this list. I would like to see the detailed report on the list first PP presentations tend to cloud issues. > > Kind Regards, > > Mirjam Kuehne > External Relations > RIPE NCC From mir at ripe.net Mon Apr 15 11:54:46 2002 From: mir at ripe.net (Mirjam Kuehne) Date: Mon, 15 Apr 2002 09:54:46 +0000 Subject: CAll for action - PLEASE READ In-Reply-To: Your message of Sat, 13 Apr 2002 23:54:22 +0200. <004001c1e335$c82f00e0$7900a8c0@no.tiscali.com> Message-ID: <200204150954.g3F9slu08634@birch.ripe.net> Hans Petter, Thank you for your constructive ideas. As announced earlier, we are busy re-writing the IP address policy document. The outcome of this should be a more clear and concise documentation of address policies. In parallel we hope that the simplification of the policies will lead to more simple procedures regarding the evaluation of address requests. Review work on the new IPv4 policy document has been done together with the RIPE community on . Tomorrow the final draft will be submitted to the LIR WG mailing list for comment. Regards, Mirjam Kuehne External Relation RIPE NCC "Hans Petter Holen" writes: * Hmm, I am not shure I understand your reasoning, I always tought * * If the cueue increases there are to few hostmasters, or the hostmasters * spend to long time on each request. * * If the queue is long but not increasing, increasing the number of * hostmasters will bring down the cueue to zero, but * * Possible fixes: * - increase the number of hostmasters * - lower the ammount of time spent on each request * * the first is simple, * the second is more complex: * * - make the hostmasters work faster (better training, faster computers, othe * r * incentives) * - simplify the procedures to make the work faster * - simplify the policy so that the procedures could be simpler * - clearify the policy/procedures so that the requests are resolved at first * iteration rather than requiring a number of interactions to solve a problem * - make the LIR staff sumitt better requests (better training, faster * computers, cleverer people) * * >From looking at this from time to time, I don't think one single factor ca * n * solve the problem or bring us out of the situation we are in. * * -hph * From hph at online.no Tue Apr 16 10:43:36 2002 From: hph at online.no (Hans Petter Holen) Date: Tue, 16 Apr 2002 10:43:36 +0200 Subject: Draft minutes from lir-wg at RIPE 41 Message-ID: <000301c1e5e1$bdb56ab0$070b2f0a@no.tiscali.com> Dear WG, The RIPE NCC have just finished the draft minutes and published them on the RIPE web site under: http://www.ripe.net/ripe/wg/lir/r41-minutes.html RIPE Meeting: 41 Working Group: LIR Status: 1st Draft Revision Number: 1 Please mail comments/suggestions on: content to the Chair of the working group. format to webmaster at ripe.net. ---------------------------------------------------------------------------- --- Draft Minutes of the LIR Working Group session of the RIPE 41 Meeting 14-18 January 2002, at the Krasnapolsky Hotel, Amsterdam, Netherlands. ----------------------------------- Chair: James Aldridge Vice-Chair: Denesh Bhabuta Scribe: Jeannette Decades ----------------------------------- Agenda: A. Admin - scribe, participant list, charter, mailing-lists B. Agenda bashing C. RIPE 39+40 (minutes & actions) D. Report from the RIPE NCC Hostmasters E. RIPE 185 ("European Internet Registry Policies and Procedures") F. Change of policy for Portable address space G. RFC 2050 ("European Internet Registry Policies and Procedures") revision H. Report from The Address Council Y. Any Other Business Z. Open Microphone. Denesh Bhabuta (DB): Hans Petter Holen couldn't make it. So the meeting will have to do with James Aldridge and myself, Denesh Bhabuta. We want to set a ground rule: One of the complaints from the past was that the LIR WG has been fed with too many discussions. Discussions are supposed to happen on the mailing lists and policy decisions are to be made at the meeting. James Aldridge (JA): The agenda was sent out yesterday to the mailing list. ======================== A: Scribe. ======================== DB: Could we have a non-RIPE staff scribe please? No reactions. A RIPE staff member is scribe. ======================== B: Agenda bashing ======================== JA: Are there any additional items for the agenda? No reactions. ======================== C: RIPE 39 and RIPE 40 minutes and actions. ======================== JA: The minutes are on the website since November we think. Actions as it appears on the website, few of them are very old actions from RIPE 35, 36 and 38. Most of these had something happened since the last RIPE meeting. A lot of it is ongoing work. The 38.5 LIR-Allocated, my original suggestion, is now LIR-Partitioned and some email is sent out this week. It is now in the test database and will go live real soon now. Working group chair roles is working fine since Hans Petter Holen is not here and I am. Policy action undivided address space action on the working group to participate on the RFC 2050 is in progress. ======================= D: Report from the RIPE NCC Hostmasters ======================== Presentation of Sabrina Waschke can be found at: http://www.ripe.net/ripe/meetings/archive/ripe-41/presentations/lir-rsreport /index.html Some additional comments from Sabrina on the slides: RS staffing. We have now 5 teams. Three new hostmasters are starting in January. At this point we hope to be fully staffed and can cope with the workload. And as you can see, you have probably seen it before, we also work on future growth. (Sabrina shows her big belly). Number of requests in hostmaster at ripe.net. In 2000, we see a peak but now the graph shows a steady growth. We introduced last year the two-day-turnaround time for ongoing tickets. That meant that when your request was picked up out of the wait queue, a hostmaster dealt with it, you replied, you had to wait for 48 hours before you got a response from us again. That means that correctly filled out requests get a faster approval. The special lir-help at ripe.net mailbox is not holding up normal requests anymore. We still apply the 'approve but educate' approach. Even not perfect requests got approved and we gave tips and information for improvements to get a faster approval next time. Wait queue. The last 6 months the wait queue is low. The last 2 months it is a bit higher, due to Dutch weather (sickness) and Christmas holidays. Total LIRs per region. The growth is slowing down. We don't expect too many new LIRs. IPv4 Allocation distribution. LIRs that are working all over Europe have the country code EU. Policy development. A message was sent out to the LIR WG concerning the /20 criteria. At RIPE 40 the decision about the Assignment Window (AW) for infrastructure for LIRs was decided upon and it was introduced in December 2001. Already 250 objects have been created in the database with the INFRA-AW extension. Not all of them are valid. Some LIRs have tried to use this to clean up the database. RS services are working on a document that tries to cover everything concerning mergers, take-overs and closures of LIRs. IPv6. The assignments for Exchange Points have been introduced in August 2001. E: RIPE 185 ("European Internet Registry Policies and Procedures") ======================== Nurani Nimpuno (NN): We encourage everyone to look at the document and to give comments. We're speaking about the new policy draft document for IPv4 policies. The document has been out on the web for 5 months and there was very little activity. The couple of comments that have been made have been published on the LIR WG mailing list. JA: I'm not sure how much more we can do. There hasn't been very much discussion on the mailing list about this. My opinion is this, more profitable work is done on the mailing list. Then we can come to the RIPE meetings for final decisions, rather than having long drawn-out arguments and conversations here. But are there any brief comments from anyone here? Because we're actually ahead of schedule and I'm trying to think of anything to fit in a bit of time. I encourage everyone to join the mailing list and to participate in the revision process. The email address is ripe-185bis at ripe.net. ======================== F: Change of policy for Portable address space ======================== JA: The question is if people are happy with the new policy? No reaction. DB: Are people aware of the policy change? It's about the requirements of a /22 immediate or the previously use of a /22 to become a new LIR. This was voted on at the last RIPE meeting. Any thoughts? Are people finding it difficult with their customers who want to be mainly multi-homed? Comments? No? We will continue this discussion on the mailing list. ======================== G: RFC 2050 ("European Internet Registry Policies and Procedures") revision ======================== JA: The agenda on the web was wrong about this one. This should be the RFC 2050, the global Internet Registries guidelines, which is being revised and prolong sides the European policy. Again joining the mailing list for participation and discussion is appreciated. Are there any comments for now? Mark Mcfadden (mcf at uwm.edu): I'll give a brief update. There is a mailing list available through ARIN for the global RFC 2050 discussion. Part of that working group, there are also some milestones. We're a little bit behind on those because of some things that happened at the end of last year. But we can start see there again is some movement forward. So I encourage anyone who is interested in the discussion of the revision of RFC 2050 to make sure that you're part of that mailing list. Mailing list address: rfc2050-WG at arin.net JA: Any questions, comments, anything? Comment from ?: I think that there are more hostmasters here are than LIRs. ======================== H: Report from The Address Council ======================== Barbara Roseman gave a report from the Address Council. Slides can be found at: ======================== Y: Any Other Business ======================== UUNET: There has been a discussion on the mailing list about PI - multihomed issues. The question raised if multi-homed is always needed or not. We have customers that need multi-homing. But not all providers will route small address blocks. JA: I don't know if there's anything that the LIR WG can do to force providers to route any particular address space. I would be inclined, rather than a policy change our of LIRs, have the Routing WG work on this issue and come up with a 'best practice or something'. DB: We can talkabout 'best practice' but there are commercial realities behind this as well. A lot of ISPs have customer requirements to fulfill. You're not the only person who has spoken about this issue with us and it has mainly come up since the last policy change. This was about the minimum requirement of a /22 before we can get address space. Are there any suggestions? UUNET: As far as I can see, the company that I work for, which is UUNET, is thinking about(at least the hostmaster is, which I am not) having a policy where you accept other provider's PA space instead of trying to go the PI route. This is current thinking, this is no decision, but the problem is we don't have a consistent policy across our AS and we'd like to implement one. Before we implement it we'd like to have consistent policy within RIPE. The problem is that whenever we get the discussion, everybody starts jumping and shouting saying: "Multi-homing". Then the discussion dies because multi-homing is the issue. But before we solve that problem we would like to have something implemented that is workable right now instead of waiting until we solve the mult-homing discussion, which seems to be without a logical solution. DB: My suggestion is that we take this up with the Routing WG as well and maybe we can make this into an action item from this meeting. UUNET: I didn't raise it in the Routing WG yesterday, thinking that was more appropriate to the LIR WG. I guess there were some initiatives in the community, but they all died. So I wonder if there's anybody else that feels like this, something we need to resolve rather sooner than later. DB: Any other comments? No reaction. UUNET: I guess there's too much RIPE NCC people here as previously discussed. DB: We'll set it as an action point. JA: This is the first new action point from this RIPE meeting. Any other questions, comments? I think this is about it for this morning. Please participate on the mailing lists. It does make it so much easier if there's been discussion before RIPE meetings. We can then reach final decisions at these WG-meetings. From mir at ripe.net Thu Apr 18 18:13:35 2002 From: mir at ripe.net (Mirjam Kuehne) Date: Thu, 18 Apr 2002 18:13:35 +0200 Subject: New Draft IPv4 Policy Documents Message-ID: <5.1.0.14.2.20020418181202.02a2fa90@mailhost.ripe.net> Dear LIRs, We are pleased to announce the availability of the new draft "IPv4 Address Allocation and Assignment Policies in the RIPE NCC Service Region" document. Previous drafts of this document have been sent to the public mailing list ripe-185bis at ripe.net and reviewed by an editorial team. During this time we received many useful and constructive comments and would like to thank those that were active in providing feedback. The current RIPE document "European Internet Registry Policies and Procedures" (ripe-185) contains all topics and aspects related to addressing policy including procedures and background information. During the review process it was decided that this document would be split into several concise documents. These documents would also make it easier for LIRs to refer to various parts of IPv4 policy. Additional goals of the review process were to clarify and separate policies from procedures, motivate policies and procedures, include policy amendments since the publication of ripe-185, and generally update the policy document. No policies described in the ripe-185 document were changed other than the amendments discussed and agreed by the LIR Working Group. The new set of policy documents consist of the following: - IPv4 Address Allocation and Assignment Policies in the RIPE NCC Service Region - Autonomous System (AS) Number Assignment Policies and Procedures - Mergers, Acquisitions, Take-overs and Closures of LIRs - New Values of the "status:" Attribute for Inetum Objects (LIR-PARTITIONED) The text version of the draft "IPv4 Address Allocation and Assignment Policies in the RIPE NCC Service Region" document can be found in the text to follow. The complete set of new draft documentation can be found at: http://www.ripe.net/ripencc/mem-services/registration/policies/draft-documents/ The deadline for comments and suggestions is Friday, 3 May 2002. After incorporating any suggested changes to the documents the final documents will be published soon after the RIPE Meeting. All comments and suggestions should be sent to . Regards, Mirjam Kuehne Director External Relations ======= DRAFT: IPv4 Address Allocation and Assignment Policies in the RIPE NCC Service Region Author(s): Document ID: TBA Date Published: April 2002 Obsoletes: ripe-104, ripe-105, ripe-136, ripe-140, ripe-159, ripe-185 ABSTRACT This document describes the current IPv4 address allocation policies developed by the Local Internet Working Group (LIR WG) of the RIPE community and implemented by the RIPE NCC. These policies apply to the RIPE NCC and the Local Internet Registries (LIRs) in the RIPE NCC service region. Table of Contents 1.0 Introduction 1.1 Scope 2.0 Internet Address Space 3.0 Goals of the Internet 4.0 Establishing a New LIR 5.0 IPv4 Address Assignment and Allocation Policies 5.1 General 5.1.1 Validity of an Assignment 5.1.2 Documentation 5.1.3 Registration Requirements 5.1.4 Reservations Not Supported 5.1.5 Administrative Ease 5.1.6 Utilisation 5.1.7 Provider Independent vs. Provider Aggregatable Addresses 5.1.8 Private Address Space 5.2 Assignment Guidelines 5.2.1 Dynamic Assignments 5.2.2 Web Hosting 5.2.3 Renumbering 5.2.4 Assignment Window 5.2.4.1 Assignment Window for End User Assignments 5.2.4.2 Assignment Window for LIR Infrastructure 5.3 Policies and Guidelines for Allocations 5.3.1 First allocation 5.3.2 Slow-start Mechanism 5.3.3 Further Allocations 5.4 Operating an LIR 5.4.1 Record Keeping 5.4.2 Contact persons 5.4.3 Mergers, Take-overs, and Closures of LIRs 5.4.4 LIR Audit 5.4.5 Closure of an LIR by the RIPE NCC 5.4.6 Reverse Delegation 6.0 Appendices I. RIPE Database Procedures II. Assignment Window III. Useful URLs IV. Bit Boundary Chart 1.0 Introduction The RIPE Network Coordination Centre, established as an independent association, serves as one of three existing Regional Internet Registries (RIRs). Its service region incorporates Europe, the Middle East, Central Asia and African countries located north of the equator. As an RIR, the RIPE NCC is responsible for the assignment and allocation of IP address space, Autonomous System (AS) Numbers and the management of reverse domain names. The distribution of IP address space follows the hierarchical scheme described in the draft document "Internet Registry System" found at: http://www.ripe.net/ripencc/mem-services/registration/policies/registry-system.html The RIPE NCC allocates address space to Local Internet Registries that assign address space on to End Users. In this document, the policies associated with the distribution and management of IPv4 address space are described. These policies need to be implemented by all LIRs. The RIPE community, through the open-consensus process used for policy development, has developed the policies described in this document. In RIPE, it is the RIPE LIR Working Group (LIR-WG) where Internet address policy is developed, discussed and set. This process is facilitated and supported by the RIPE NCC. 1.1 Scope This document describes the policies for the responsible management of the globally unique IPv4 Internet address space in the RIPE NCC service region. The policies set forth in this document apply to all IPv4 address space allocated and assigned by the RIPE NCC. This document does not describe address policies related to IPv6, multicast, or private address space. This document does not describe address distribution policies used by other RIRs. Policies regarding AS Numbers are also out of scope for this document. The draft document "Autonomous System (AS) Number Assignment Policies and Procedures" can be found at: http://www.ripe.net/rs/policies/draft-documents/asn-assignments.html 2.0 Internet Address Space IP addresses, for the purposes of this document, are 32-bit binary numbers used as addresses in the IPv4 protocol. There are three main types of IPv4 addresses: Public Addresses Public IP addresses are assigned to be globally unique according to the goals described in Section 3.1. of this document. Private Addresses Some address ranges have been set aside for the operation of private networks using IP. Anyone can use these addresses in their private networks without any registration or co-ordination. Hosts using these addresses cannot be reached directly from the Internet. For a detailed description of private address space and the ranges set aside for this purpose, please refer to RFC 1918 (Address Allocation for Private Internets) at: ftp://ftp.ripe.net/rfc/rfc1918.txt Special and Reserved Addresses There are a number of address ranges reserved for applications such as multicast. These are described in RFC 1112 (Host Extensions for IP Multicasting) and are beyond the scope of this document. RFC 1112 can be found at: http://www.ietf.org/rfc/rfc1112.txt?number=1112 3.0 Goals of the Internet In this document, we are primarily concerned with the management of public Internet address space as applied to IPv4. It should be understood that the focus or importance of these goals might differ for other IP versions, such as IPv6. Public Internet address space assignments should be made with the following goals in mind: Uniqueness Each public Internet address worldwide must be unique. This is an absolute requirement that guarantees that every host on the Internet can be uniquely identified. Aggregation Public Internet addresses must be distributed in an hierarchical manner, permitting the aggregation of routing information. This is necessary to ensure proper operation of Internet routing. This goal could also be called Routability. Conservation Public Internet address space must be fairly distributed, according to the operational needs of the End Users' operating networks using this address space. To maximize the lifetime of the public Internet address space resource, addresses must be distributed according to need, and stockpiling must be prevented. Registration The provision of a public registry documenting address space allocations and assignments must exist. This is necessary to ensure uniqueness and to provide information for Internet troubleshooting at all levels. It is in the interest of the Internet community as a whole that these goals are pursued. It is worth noting that "conservation" and "aggregation" are often conflicting goals and, therefore, that each assignment must be evaluated carefully. Moreover, the above goals may occasionally be in conflict with the interests of individual End Users or service providers. Careful analysis and judgement are necessary in each individual case to find an appropriate compromise. The rules and guidelines in this document are intended to help LIRs and End Users in their search for equitable compromises. 4.0 Establishing a New LIR The process of setting up a new LIR is explained in detail in the RIPE document, "Guidelines for Setting up a Local Internet Registry at the RIPE NCC" at: http://www.ripe.net/ripe/docs/new-lir.html 5.0 IPv4 Address Assignment and Allocation Policies 5.1 General The policies in the RIPE NCC service region document are applicable to all globally unique, unicast IPv4 addresses. Specific policies and guidelines for Provider Aggregatable (PA) and Provider Independent (PI) address space are covered later in this section. 5.1.1 Validity of an Assignment Address space assignments of any kind are valid as long as the original criteria on which the assignment was based are still valid. If an assignment is made for a specific purpose and that purpose no longer exists, the assignment is no longer valid. If an assignment is based on information that turns out to be invalid, the assignment is no longer valid. 5.1.2 Documentation Relevant information must be gathered about the network in question in order to determine the amount of addresses required for that network. This information may include organisation details, addressing requirements, network infrastructure, current address space usage, and future plans of the End User requesting address space. This information is essential in making the appropriate assignment decisions, balancing the overall goals of the Internet Registry system (Section 3.0) with the requirements of the network in question, and is needed for every network (the level of detail is dependent on the complexity of the network). The LIR must ensure that the necessary information is complete before proceeding with a request. The RIPE NCC provides a set of forms to be completed for gathering the required information as well as supporting notes for the forms. The set of information requested in the forms provided by the RIPE NCC should be collected by the LIR. LIRs may use these forms for their customers' requests or develop their own local set of forms. Please note that local forms produced by the LIR can be used provided they record all the required data. However, if a request needs to be approved by the RIPE NCC or if information is required in the event of an audit, the information must be submitted on a current version of the "European IP Address Space Request Form" available at: http://www.ripe.net/ripe/docs/iprequestform.html For complete instructions on how to fill out the "European IP Address Request Form", please refer to: http://www.ripe.net/ripe/docs/iprequestsupport.html Please note that all information sent to the RIPE NCC must be submitted in English. 5.1.3 Registration Requirements Each assignment and allocation for public Internet address space must be registered in a publicly accessible Whois Database. Allocations and assignments in the RIPE NCC service region are registered in the RIPE Whois Database. This is necessary to ensure uniqueness and to support network operations. Only allocations and assignments registered in the RIPE Database are considered valid. The required registration of objects in the RIPE Database is the final step in making an assignment. This step validates the assignment and makes information regarding the assignment publicly available and archived. Therefore, care should be taken to ensure that the data registered is correct (e.g. correct IP address range, contact information, etc.). IP addresses used solely for the connection of an End User to an LIR can be considered as part of the service provider's infrastructure. This means that these addresses do not have to be registered with the End User's contact details but can be registered as part of the service provider's internal infrastructure, i.e. point-to-point links. However, four or more addresses (e.g. /30 or more) used on the End User's network need to be registered separately with the contact details of the End User. For further instructions on how to register objects in the Database, please refer to section I (RIPE Database Procedures) of the Appendix. 5.1.4 Reservations Not Supported In accordance with the goal of address conservation, End Users are not permitted to reserve address space. Evaluation of IP address space requests must be based on a demonstrated need. If possible, unused or inefficiently used address space assigned in the past should be used to meet the current request. Once an organisation has used its assigned address space, it can request additional address space based on an updated estimate of growth in its network. 5.1.5 Administrative Ease The current rate of consumption of the remaining unassigned IPv4 address space does not permit the assignment of addresses for administrative ease. Examples of this include, but are not limited to, ease of billing administration and network management. 5.1.6 Utilisation Immediate utilisation should be at least 25% of the assigned address space and the utilisation rate after one year should be at least 50% of the address assignment unless special circumstances are defined. Assignments must be based solely on realistic expectations as specified in the addressing plan and the current address space usage. End Users are not permitted to reserve addresses based on long-term plans as this fragments the address space. LIRs cannot make long-term reservations for End Users or their own infrastructure as this violates the goal of conservation and also fragments the address space in case the initial forecasts are not met. 5.1.7 Provider Independent vs. Provider Aggregatable Address Space Provider Aggregatable Address Space (PA) LIRs are allocated Provider Aggregatable address space that they assign to their End Users and announced as one prefix. If an End User changes its service provider, the PA address space assigned by the previous service provider will have to be returned and the network renumbered. Provider Independent Address Space (PI) In contrast to PA address space, PI address space is not aggregatable but can remain assigned to the network as long as the criteria for the original assignment are met. However, PI addresses are expensive to route as no use can be made of aggregation and therefore they might not be globally routable. Please note that the use of PA address space should always be recommended. LIRs must make it clear to the End User which type of address space is assigned. Clear contractual arrangements that specify the validity and duration of the address assignment are strongly recommended for every address assignment. For further information and more detailed recommendations concerning PI and PA addresses, please refer to the RIPE document: "Provider Independent versus Provider Aggregatable Address Space" at: http://www.ripe.net/ripe/docs/pi-pa.html 5.1.8 Private Address Space Using private addresses helps to meet the conservation goal and provides more flexibility for the End User when addressing the network. For this reason End Users should always be informed that private addresses might be a viable option. For a detailed description of private address space and the actual ranges of addresses set aside for that purpose, please refer to RFC 1918 ("Address Allocation for Private Internets") at: http://www.ietf.org/rfc/rfc1918.txt?number=1918 5.2 Assignment Guidelines LIRs assign IP address space from the range of addresses allocated to them by the RIPE NCC. As conservation and aggregation are often conflicting goals, each address request needs to be evaluated carefully in order to assign the amount of address space fulfilling these goals in the best way possible. Implications for both conservation and aggregation have to be evaluated before an assignment is made. For example, if the assignment of the exact number of addresses required creates a large number of prefixes, it might be better to assign one single prefix. In other cases, multiple prefixes might have to be "announced" if the assignment of one single prefix would leave too many addresses unused. Please note that the RIPE NCC must approve requests that are larger than the LIR's Assignment Window. LIRs are always welcome to request advice from the RIPE NCC in making assignment decisions. 5.2.1 Dynamic Assignments The use of static IP address assignments (e.g. one address per customer) for dial-up users is strongly discouraged due to a shortage of IPv4 address space. Organisations considering the use of static IP address assignments are expected to investigate and implement dynamic assignment technologies whenever possible. If static IP address assignments are requested, special verification procedures apply. However, for services that are permanently connected to the Internet, static one-to-one connections are considered acceptable. All assignments to End Users need to be registered in the RIPE Whois Database. However, static assignments of single IP addresses to individual End Users (e.g. dial-up, ADSL, etc.) do not have to be registered separately to the Database. However, special verification methods apply. 5.2.2 Web Hosting With the development of HTTP 1.1, the need for one-to-one mapping of IP addresses to web sites has been eliminated. The RIPE community strongly encourages the deployment of name-based web hosting versus IP-based web hosting in accordance with the goal of conservation. For certain applications the need for IP-based web hosting is recognised and should be described. Special verification methods apply for IP-based web hosting. 5.2.3 Renumbering In general, address space can be replaced on a one-to-one basis. A valid assignment can be replaced with the same amount of addresses if the original assignment criteria are still met and if the address space to be replaced is currently in use. An End User will be required to submit the usual documentation to the LIR only if a large percentage of the original assignment is not in use (50%). This part of the request is then treated as any other request for the assignment of additional addresses. If this exceeds the Assignment Window, see Section 4.2.4 (Assignment Window for End User Assignments), the renumbering request needs to be sent to the RIPE NCC for approval. A period of 3 months is generally accepted, within the RIPE community, to be enough to migrate a network from the old to the new address space. For exceptional cases where the End User requests to keep both assignments for more than three months, an agreement should be obtained from the RIPE NCC for the proposed time frame. 5.2.4 Assignment Window An Assignment Window (AW) refers to the maximum number of addresses that can be assigned by the LIR to either their own network or to an End User's network without prior approval from the RIPE NCC. This is expressed in /nn notation. The Assignment Window procedure was put in place to achieve various levels of support based on the level of experience of the LIR. The RIPE NCC may review LIR assignments made with the LIR's AW in order to assure the LIR is assigning according to policies. This is important to assure the fair distribution of address space and to meet the goals of aggregation, conservation and registration. Documentation regarding assignments made with an AW need to contain equivalent information as in a completed "European IP Address Space Request form". All new LIRs start with an Assignment Window of zero (0). This means that every assignment requires prior approval from the RIPE NCC. The same applies to assignments larger than the LIR's Assignment Window. The AW is applied differently depending whether the assignment is for an End User or for the LIR's infrastructure. 5.2.4.1 Assignment Window for LIR Infrastructure The Assignment Window policy was adjusted in December 2001 to include LIR infrastructure assignments. There is no constraint as to how often the LIR uses its AW for own infrastructure assignments. These assignments may not exceed the LIR's AW. This means that an LIR with a /25 AW can make numerous individual /25 assignments to its own network infrastructure without having to send each request to the RIPE NCC. However, where a single assignment would exceed a /25 the LIR would need to complete the RIPE document "European IP Address Space Request Form" and send it to the RIPE NCC for approval. An LIR must specify which assignments have been made with the AW to the LIR's own infrastructure. Such assignments must have a remarks attribute with the value INFRA-AW in the inetnum object registered in the RIPE database. It is important that a separate remarks attribute is used solely for this purpose. For further explanation of the Assignment Window procedures, please refer to Section II (Assignment Window) of the Appendix. 5.2.4.2 Assignment Window for End User Assignments An LIR can apply their Assignment Window to an End User network only once in any 12 month period. This means that if an LIR makes more than one assignment to an organisation, the total amount of address space assigned with their AW in any 12-month period may not exceed the LIR's AW size. The LIR may only assign additional addresses to the same organisation after approval from the RIPE NCC. 5.3 Policies and Guidelines for Allocations All LIRs that receive address space from the RIPE NCC shall adopt allocation and assignment policies that are consistent with the policies formulated by the RIPE community as described in this document. An LIR cannot have more than one "open" (less than 80% assigned) allocation. The RIPE NCC is the only organisation that allocates address space in its service region. An LIR is not allowed to re-allocate part of its allocation to any other organisation. An LIR can only make assignments. If an LIR is planning to exchange or transfer address space it needs to contact the RIPE NCC so that the changes can be properly registered. The RIPE NCC recognises that LIRs may want to issue parts of their allocation to re-sellers or downstream service providers, as this may be beneficial for aggregation. Please note that the LIR always remains responsible for the entire allocation it receives from the RIPE NCC and that all policies are applied. 5.3.1 First Allocation The minimum allocation size to LIRs is a /20 (4096 addresses), according to the slow-start mechanism described in section 4.3.2 (Slow-start Mechanism). It is expected that this prefix be announced as one aggregate. In order to receive an initial allocation an LIR needs to demonstrate: - either the previous utilisation of a minimum /22 (1024 addresses) - or an immediate need for at least a /22 of address space. This can include address assignments to the LIR's infrastructure as well as assignments to customers' networks that will be renumbered into the LIR's new allocation. Verification of previous utilisation by an organisation is based on the assignments registered in the RIPE Database, as only assignments registered in the RIPE Database are considered valid. Further details can be found in the RIPE document "Guidelines for Setting up a Local Internet Registry at the RIPE NCC" at: http://www.ripe.net/ripe/docs/new-lir.html 5.3.2 Slow-start Mechanism The intent of the slow-start mechanism is to treat all new LIRs equally by allocating address space to LIRs at the rate that the addresses are assigned by the LIRs. The minimum size of the first allocation is /20 (4096 addresses). An allocation larger than a /20 can be made if the need is demonstrated. Additionally, the size of future allocations will be based on the usage rate of the previous allocation. The slow-start mechanism was put into place by the Regional Internet Registries to ensure a consistent and fair policy for all LIRs with respect to allocations. 5.3.3 Further Allocations An LIR is eligible for additional address space allocation when: - at least eighty percent (80%) of the allocated address space is used in valid assignments; - or if a single assignment will require a larger set of addresses that cannot be satisfied with the address space currently held by the LIR; - the appropriate documentation is available for each assignment; - each assignment is registered in the RIPE Whois Database; - 80% of the allocation is utilised before additional address space is requested; - all allocations must be at 80% usage; - overall usage must also be at 80%. Reservations are not counted as assignments. It may be useful for internal aggregation to keep some address space free for a customer for future growth in addition to the actual assignment. However, the LIR must be aware that these internal reservations do not count as assignments and must be assigned before the LIR can request another allocation. The size of further allocations mainly depends on the assignment rate of previous allocations. To obtain a new allocation, an LIR should submit a request to the RIPE NCC using the RIPE document "European IP Allocation Request Form" and include a complete list of the assignments (i.e. IP address range and netname) made from their last allocation. However, all previous allocations made to the LIR also need to show a utilisation rate of at least 80%. Additional address space will be allocated only after the information supplied with the request has been verified and a new allocation has been deemed necessary. The RIPE NCC will do its best to allocate contiguous address space in order to support aggregation. This cannot be guaranteed as it depends on factors outside the RIPE NCC's influence (e.g. the number of new LIRs and the time needed to utilise the allocation). 5.4 Operating an LIR This section outlines procedures associated with IP registration services that LIRs are expected to follow in order to ensure that the policies are applied in a fair and impartial manner throughout the entire RIPE NCC service region. 5.4.1 Record Keeping LIRs must maintain proper records of all address assignments they have made. All documentation related to an IP address request and assignment needs to be maintained by the LIR for future reference. This data is needed for the evaluation of subsequent requests for the same organisation/End User, for audits by the RIR, and for the resolution of any questions that may arise regarding assignments. The records must include: - The original request - All supporting documentation - All related correspondence between the LIR and the customer - The assignment decision, including: - Reasons behind any unusual decision - The person responsible for making the decision The chronology of events and the persons responsible should be stated clearly in the records. In order to facilitate the exchange of information, it is highly recommended that documents are kept electronically and readily accessible. If requested, any of this information should be made available to the RIPE NCC in English. 5.4.2 LIR Contact Persons Each LIR must provide the RIPE NCC with a list of contact persons. The contact persons should be those who submit address space requests for the LIR. This contact information should be kept up-to-date. Address space requests will only be accepted from LIR staff members that are registered as contact persons for an LIR. This is necessary to ensure confidentiality. Every registered contact person can make updates and/or changes to the contact information the RIPE NCC keeps for that LIR. A list of registered contact person's responsibilities and important referencing documents can be found at: http://www/ripe/docs/new-lir.html [This document is currently being revised.] 5.4.3 Mergers, Take-overs, and Closures of LIRs In the event that an LIR changes ownership (e.g. merger, sale, or take-over), the new entity must register any changes to its network operations or contact persons with the RIPE NCC. If the effect of a take-over, sale, or merger results in a change of the LIR as a legal entity, the LIR must provide relevant legal documentation confirming the new organisation to the RIPE NCC. For further information on change of LIR ownership and closures, see the draft document "Mergers, Acquisitions, Takeovers and Closures of LIRs" found at: http://www.ripe.net/rs/policies/draft-documents/mergers.html 5.4.4 LIR Audit The RIPE NCC was asked by the RIPE community to audit LIR operations in order to ensure consistent and fair implementation of address policies set by the community. This includes regular checks of assignment data in the RIPE Whois Database for completeness and consistency. The RIPE NCC may also contact an LIR to ask for documentation or for more information about certain requests or database entries. The RIPE NCC will work with an LIR to correct any problems that are found. If necessary, the RIPE NCC may take corrective action such as lowering the LIR's Assignment Window. This activity is described in detail in the RIPE document "RIPE NCC Consistency and Auditing Activity" at: http://www.ripe.net/ripe/docs/audit.html For further information regarding the RIPE NCC auditing activity, please refer to: http://www.ripe.net/audit 5.4.5 Closure of an LIR by the RIPE NCC The RIPE NCC may decide to close an LIR for the following reasons: - the LIR stops paying its bills to the RIPE NCC - and/or the LIR cannot be contacted by the RIPE NCC for a significant period of time Moreover, if an LIR consistently violates the policies applicable in the RIPE NCC service region, it may result in closure of the LIR. In the event of an LIR closure, the RIPE NCC will take responsibility for all address space held by the LIR. 5.4.6 Reverse Delegation LIRs should maintain in.addr.arpa resource records for their customers' networks. The RIPE NCC only accepts requests for reverse delegation from LIRs. More information about reverse delegation can be found in the draft document "Reverse Delegation Under "in-addr.arpa" in the RIPE NCC Service Region" found at: [To be published] 6.0 Appendices I. RIPE Whois Database Procedures Registration of objects pertaining to an assignment in the RIPE Whois Database enables uniqueness and provides contact information. This is essential for the effective administration and operation of IP networks. Submission of objects to the RIPE Whois Database is the final step in making an assignment. This step validates the assignment and makes the information regarding the assignment publicly available. Therefore, care should be taken to assure the assignment and of all relevant data is correct prior to completing this step. The information collected about the End User's organisation in the Network Template (see http://www.ripe.net/ripe/docs/iprequestsupport.html) is used to construct an inetnum object. The range of addresses assigned to the End User is also entered in the inetnum object and is specified in dotted quad notation. For example, if an organisation is assigned a /22 address set for 1024 network addresses, the range will resemble the following: 193.0.0.0 193.0.1.255 A person object must be submitted for each person specified in the tech-c and admin-c fields of the inetnum object unless up-to-date objects are already available in the RIPE Database in addition to the inetnum object. The person object is referenced from the inetnum by its nic-handle. The information should remain in the RIPE Database for as long as the original assignment is valid. If the address space is returned, the LIR that made the assignment must remove the old entry from the RIPE Database. An assignment is considered valid when based on the following factors: - all assignments must be registered in the RIPE Database - assignments should either be covered by an LIR's AW or should have received prior approval from the RIPE NCC - Database objects describing an assignment approved by the RIPE NCC should: - use the same netname as approved by the RIPE NCC - use the date of approval or a later date in the first changed line of the inetnum object - not exceed the number of IP addresses approved by the RIPE NCC The type of the assigned address space must be registered in the status attribute of the inetnum object. The possible values of this attribute are: ASSIGNED PA This is used for PA address space that has been assigned to an End User. ASSIGNED PI This is used for PI address space that has been assigned to an End User. Every new address space assignment must be marked as PA or PI in the RIPE Database. To improve registration of old assignments, LIRs are encouraged to mark legacy assignments in the RIPE Database with PA or PI as appropriate. This should be done in collaboration with the End User to make sure of the status of the address space. Both LIR and End User should understand the implications. Allocation Registration The RIPE NCC registers all address space allocated to an LIR in the RIPE Whois Database using inetnum objects. Inetnum objects describing allocations to LIRs are maintained by the RIPE NCC. Hierarchical authorisation can be used to allow the LIR the creation of inetnum objects more specific than the allocation objects. Organisational information about the LIR is stored together with the address space range and the type of addresses. The range of the addresses is stored in the inetnum field in dotted quad notation. The address type is stored in the status field and can have one of the following values: ALLOCATED PA This address space has been allocated to an LIR or an RIR and all assignments made from it are provider aggregatable. This is the most common allocation type for LIRs. ALLOCATED PI This address space has been allocated to an LIR and all assignments made from it are provider independent. This case is extremely rare and is only done after careful consideration. ALLOCATED UNSPECIFIED This address space has been allocated to an LIR and assignments made from it may be either provider aggregatable or provider independent. This type of allocation is obsolete and will not be applied to future allocations. Some older allocations have been used for both PA and PI assignments and as such received this allocation type. For information and instructions on the use of the RIPE Database, please refer to the RIPE document: "RIPE Database Reference Manual" at: http://www.ripe.net/ripe/docs/databaseref-manual.html II. Assignment Window The LIR's Assignment Window can either be applied to assignments for their own network infrastructure or for End User assignments. As mentioned in 4.2.6 (Assignment Window for LIR Infrastructure), LIRs must specify in the RIPE database which assignments have been made to the LIR's own infrastructure network using their AW. Only assignments to the LIR's infrastructure may have the INFRA-AW identifier. Assignments to End Users do not need any identifier. The AW is regularly reviewed by the RIPE NCC Hostmasters. LIRs may approach the RIPE NCC for an evaluation of its Assignment Window at any time. Please note that LIRs are always welcome to approach the RIPE NCC for a second opinion on requests even if theyfall within the LIR's Assignment Window. Raising of the Assignment Window As the proficiency of the LIR contacts increases the size of their Assignment Window may be raised. This is determined based on: - correctly completed documentation presented to the RIPE NCC - good judgement shown in the evaluation of address space requests - past assignments have been properly registered. Lowering of the Assignment Window An established LIR is responsible for training new LIR contacts to handle address space assignments according to the policies described in this document and their procedures. Less experienced LIR contacts may make errors both in judgement and procedure. If errors happen repeatedly the Assignment Window of the LIR may be decreased to prevent the LIR from making erroneous assignments. The Assignment Window may again be increased based on the criteria stated above. The Assignment Window may be lowered as a result of an audit where erroneous assignments are noted or to enforce overdue payment. III. Useful URLs RIPE NCC Registration Services information http://www.ripe.net/rs/ RIPE NCC E-mail contacts http://www.ripe.net/ripencc/about/contact.html RIPE NCC Frequently Asked Questions http://www.ripe.net/ripencc/faq/index.html Quick Tips for IP and AS Requests http://www.ripe.net/ripencc/tips/tips.html IPv6 Allocation and Assignment Information http://www.ripe.net/ipv6 Draft: New Values of the "status:" Attribute for Inetum Objects(LIR-Partitioned) http://www.ripe.net/rs/policies/draft-documents/lir-partitioned.html RIPE Documentation store http://www.ripe.net/ripe/docs/index.html IV. Bit Boundary Chart Historically, IP addresses have been assigned in the form of network numbers of class A, B, or C. With the introduction of classless inter-domain routing (CIDR) classful restrictions are no longer valid. Address space is now allocated and assigned on bit boundaries. The following table illustrates this: +-----------------------------------------------+ |addrs bits pref mask | +-----------------------------------------------+ | 1 0 /32 255.255.255.255 | | 2 1 /31 255.255.255.254 | | 4 2 /30 255.255.255.252 | | 8 3 /29 255.255.255.248 | | 16 4 /28 255.255.255.240 | | 32 5 /27 255.255.255.224 | | 64 6 /26 255.255.255.192 | | 128 7 /25 255.255.255.128 | | 256 8 /24 255.255.255 | | 512 9 /23 255.255.254 | | 1K 10 /22 255.255.252 | | 2K 11 /21 255.255.248 | | 4K 12 /20 255.255.240 | | 8K 13 /19 255.255.224 | | 16K 14 /18 255.255.192 | | 32K 15 /17 255.255.128 | | 64K 16 /16 255.255 | | 128K 17 /15 255.254 | | 256K 18 /14 255.252 | | 512K 19 /13 255.248 | | 1M 20 /12 255.240 | | 2M 21 /11 255.224 | | 4M 22 /10 255.192 | | 8M 23 /9 255.128 | | 16M 24 /8 255 | | 32M 25 /7 254 | | 64M 26 /6 252 | | 128M 27 /5 248 | | 256M 28 /4 240 | | 512M 29 /3 224 | |1024M 30 /2 192 | +-----------------------------------------------+ 'bits' The size of the allocation/assignment in bits of address space. 'addrs' The number of addresses available; note that the number of addressable hosts is normally 2 less than this number because the host parts with all equal bits (all 0s, all 1s) are reserved. 'pref' The length of the route prefix covering this address space. This is sometimes used to indicate the size of an allocation/assignment. 'mask' The network mask defining the routing prefix in dotted quad notation. Throughout this document, the RIPE NCC refers to the size of allocation and assignments in terms of 'bits of address space' and adds the length of the route prefix in parentheses wherever appropriate. From Marcus.Ruchti at colt.de Fri Apr 19 09:36:30 2002 From: Marcus.Ruchti at colt.de (Marcus.Ruchti at colt.de) Date: Fri, 19 Apr 2002 09:36:30 +0200 Subject: network transfer Message-ID: Hello, the german Internet and DSL provider RIODATA has requested insolvency 3 weeks ago. We (COLT Telecom) plan to take over a huge part of their customers. Some customers have already switched their connection to us. My question is now, whether it is possible (administratively and policy-based) to take over a part of RIODATA's IP addresses. RIODATA is owner of the 62.16.128.0/17 network. If it is possible, what have we and RIODATA to do now ? Thanks for your answer and kind regards, Marcus Ruchti Internet Systems Engineer mailto:marcus.ruchti at colt.de COLT TELECOM GmbH Fon: +49 (0) 69 / 5 66 06 - 6351 Fax: +49 (0) 69 / 5 66 06 - 6350 From hph at online.no Fri Apr 19 10:46:36 2002 From: hph at online.no (Hans Petter Holen) Date: Fri, 19 Apr 2002 10:46:36 +0200 Subject: network transfer References: Message-ID: <004401c1e77e$b73676e0$070b2f0a@no.tiscali.com> One place to start is to look at one of the drafts just created: http://www.ripe.net/ripencc/mem-services/registration/policies/draft-documen ts/mergers.html While this is strictly speaking just a draft, it reflects fairly well what you have to do. -hph ----- Original Message ----- From: To: Sent: Friday, April 19, 2002 9:36 AM Subject: network transfer | Hello, | | the german Internet and DSL provider RIODATA | has requested insolvency 3 weeks ago. | | We (COLT Telecom) plan to take over a huge part of their | customers. Some customers have already switched their | connection to us. | | My question is now, whether it is possible (administratively | and policy-based) to take over a part of RIODATA's IP addresses. | RIODATA is owner of the 62.16.128.0/17 network. | | If it is possible, what have we and RIODATA to do now ? | | Thanks for your answer and kind regards, | | Marcus Ruchti | Internet Systems Engineer | | mailto:marcus.ruchti at colt.de | COLT TELECOM GmbH | Fon: +49 (0) 69 / 5 66 06 - 6351 | Fax: +49 (0) 69 / 5 66 06 - 6350 | | | | From hph at online.no Fri Apr 19 10:49:15 2002 From: hph at online.no (Hans Petter Holen) Date: Fri, 19 Apr 2002 10:49:15 +0200 Subject: network transfer References: Message-ID: <004d01c1e77f$15cace40$070b2f0a@no.tiscali.com> One place to start is to look at one of the drafts just created: http://www.ripe.net/ripencc/mem-services/registration/policies/draft-documen ts/mergers.html While this is strictly speaking just a draft, it reflects fairly well what you have to do. -hph ----- Original Message ----- From: To: Sent: Friday, April 19, 2002 9:36 AM Subject: network transfer | Hello, | | the german Internet and DSL provider RIODATA | has requested insolvency 3 weeks ago. | | We (COLT Telecom) plan to take over a huge part of their | customers. Some customers have already switched their | connection to us. | | My question is now, whether it is possible (administratively | and policy-based) to take over a part of RIODATA's IP addresses. | RIODATA is owner of the 62.16.128.0/17 network. | | If it is possible, what have we and RIODATA to do now ? | | Thanks for your answer and kind regards, | | Marcus Ruchti | Internet Systems Engineer | | mailto:marcus.ruchti at colt.de | COLT TELECOM GmbH | Fon: +49 (0) 69 / 5 66 06 - 6351 | Fax: +49 (0) 69 / 5 66 06 - 6350 | | | | From joao at ripe.net Mon Apr 22 14:41:54 2002 From: joao at ripe.net (Joao Luis Silva Damas) Date: Mon, 22 Apr 2002 14:41:54 +0200 Subject: IPv6 assignments to DNS root servers in the RIPE region Message-ID: Dear all, below find a proposal for a policy enabling the assignment of blocks of IPv6 addresses to Internet DNS root servers in the RIPE region. I would like to use the opportunity to request from the chairman of the LIR WG to include this point for discussion in the WG meeting next week. Of course, discussion in the mailing list is welcome. Best regards, Joao Damas RIPE NCC **************** This proposal requests the adoption of a special IPv6 assignment policy for Internet DNS root servers. It does not apply to any other infrastructure. Specifically, this is not a request for a generic "special infrastructure" IPv6 assignment policy. --- IPv6 address assignments to Internet DNS root servers in the RIPE region Internet DNS root servers are particularly critical elements of the Internet's infrastructure. They need to be operated in a neutral and professional manner which will not impose any artificial or unnecessary barriers for access to their designated services. DNS resolvers and resolving name servers need to be pre-configured with the network addresses of the root name servers. This makes these addresses special and not easy to change. Hence this special policy. Under this policy, each (current or future) Internet DNS root server (as listed in the root-servers.net zone) in the RIPE region will be assigned a block of IPv6 address space for purposes of root server operations. The size of the block shall be the same as the size of the minimum allocation to LIRs valid at the time of the root server assignment. The assigned prefix is only for root server operations and support functions related directly to the operations, such as monitoring, statistics, etc., and is bound to the root server service itself. It is not associated with the organization/s that operate the root server at a particular point in time and these organizations should not use the address space to provide any services not related to the root server. Should the operational responsibility for a DNS root server move to a new organization, the IPv6 address space associated with the server will also move to the new organization. The old and the new organizations must update the registration information with the RIPE NCC. If the new location of the root name server is outside the RIPE region, the address space must be returned to the RIPE NCC and a new assignment must be requested from the appropriate RIR. If a root server stops operating within the RIPE region, the address space will be returned to the RIPE NCC and marked as "reserved" for a suitably long period of time. ******************* From randy at psg.com Mon Apr 22 18:47:24 2002 From: randy at psg.com (Randy Bush) Date: Mon, 22 Apr 2002 09:47:24 -0700 Subject: IPv6 assignments to DNS root servers in the RIPE region References: Message-ID: > DNS resolvers and resolving name servers need to be pre-configured with > the network addresses of the root name servers. This makes these > addresses special and not easy to change. Hence this special policy. while the addresses are well-known and embedded in all sorts of places, what difference does the actual integer value of those addresses make? > Should the operational responsibility for a DNS root server move to a > new organization, the IPv6 address space associated with the server > will also move to the new organization. so, you want give provider independence to the root servers. i.e, this is based on the idea that root servers, one of which which moves about every five or more years, and the protocols takes care of following the hints file anyway, are more deserving of provider independence than other members' servers and services. but i am sure that cnn.com they are just as deserving and needy. i sure think that my site is. i don't buy it. randy From Daniel.Karrenberg at ripe.net Tue Apr 23 09:25:22 2002 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 23 Apr 2002 09:25:22 +0200 Subject: IPv6 assignments to DNS root servers in the RIPE region In-Reply-To: References: Message-ID: <4.3.2.7.2.20020423092142.023f8a98@localhost.ripe.net> At 18:47 22/04/2002, Randy Bush wrote: >so, you want give provider independence to the root servers. i.e, >this is based on the idea that root servers, one of which which >moves about every five or more years, and the protocols takes care >of following the hints file anyway, are more deserving of provider >independence than other members' servers and services. Look at it the other way around: You do not want a provider to keep that space if they should not. Daniel From randy at psg.com Tue Apr 23 13:40:00 2002 From: randy at psg.com (Randy Bush) Date: Tue, 23 Apr 2002 07:40:00 -0400 Subject: IPv6 assignments to DNS root servers in the RIPE region References: <4.3.2.7.2.20020423092142.023f8a98@localhost.ripe.net> Message-ID: >> so, you want give provider independence to the root servers. i.e, >> this is based on the idea that root servers, one of which which >> moves about every five or more years, and the protocols takes care >> of following the hints file anyway, are more deserving of provider >> independence than other members' servers and services. > Look at it the other way around: You do not want a provider to > keep that space if they should not. as currently, in v4, 'that space' was the providers in the first place, of course i do. randy From joao at ripe.net Tue Apr 23 13:59:44 2002 From: joao at ripe.net (Joao Luis Silva Damas) Date: Tue, 23 Apr 2002 13:59:44 +0200 Subject: IPv6 assignments to DNS root servers in the RIPE region In-Reply-To: References: <4.3.2.7.2.20020423092142.023f8a98@localhost.ripe.net> Message-ID: At 7:40 -0400 23/4/02, Randy Bush wrote: > >> so, you want give provider independence to the root servers. i.e, >>> this is based on the idea that root servers, one of which which >>> moves about every five or more years, and the protocols takes care >>> of following the hints file anyway, are more deserving of provider >>> independence than other members' servers and services. >> Look at it the other way around: You do not want a provider to >> keep that space if they should not. > >as currently, in v4, 'that space' was the providers in the first >place, of course i do. you mean keep it if they should not? Anyway, if anything, time should make us smarter. I understand your argument about "I am special, you are special, we are all special". The difference between these machines and others is that these ones are needed by everyone. When you say the protocol "WILL" take care of the hints file, maybe you wanted to say: the protocol "SHOULD" take care... The request to get the addresses back is, as Daniel pointed out, a reasonable one from an operations point of view. If a root server were to move and a change of address was required, it might be a good idea not to have another name server at the same address, or if you have one, let it be something that would be helping towards a smooth transition. Joao From randy at psg.com Tue Apr 23 14:08:37 2002 From: randy at psg.com (Randy Bush) Date: Tue, 23 Apr 2002 08:08:37 -0400 Subject: IPv6 assignments to DNS root servers in the RIPE region References: <4.3.2.7.2.20020423092142.023f8a98@localhost.ripe.net> Message-ID: > Anyway, if anything, time should make us smarter. some days i wonder. this is one example that makes me wonder. > The difference between these machines and others is that these ones > are needed by everyone. When you say the protocol "WILL" take care of > the hints file, maybe you wanted to say: the protocol "SHOULD" take > care... "DOES" would probably be most appropriate, as it works in theory and has been shown to work in practice > The request to get the addresses back is, as Daniel pointed out, a > reasonable one from an operations point of view. of course > If a root server were to move and a change of address was required, it > might be a good idea not to have another name server at the same address, > or if you have one, let it be something that would be helping towards a > smooth transition. yup. it's called prudent operation. it's not like we have not been here before and don't have the coffee mug. people should also not announce bogus routes to the root servers. so, should we hard-wire the routes into the routers? randy From theimes at de.cw.net Wed Apr 24 09:45:08 2002 From: theimes at de.cw.net (Tanja Heimes) Date: Wed, 24 Apr 2002 09:45:08 +0200 Subject: Creation of Reverse Delegation Objects Message-ID: <3CC66284.F0346AA5@de.cw.net> Hi All, this ist the response of the RIPE Robot to one of our customers after he tried to create a reverse delegation object in the RIPE DB: "The RIPE NCC no longer accepts requests for creation and ammendments of reverse delegations which do not include the registry ID of an existing Local Internet Registry. If you are not a representative of an LIR, you should contact the LIR who assigned you the address space, or your upstream provider..." The customers owns his Provider Independent IP address space and is not able to create this object as he needs to state a reg-id in the request. Now this customers (and others in the past) claim that they have to apply to there upstream provider in order that this ISP creates the object. The customer certainly has is own maintainer. My question now: Should Provider Indepent IP space not be 100% Provider Indepent in concern to its administration in the RIPE DB? In my opinion the RIPE Robot should distinguish between PA and PI space and not request an reg-id for customers that own PI space and like to create a reverse delegation record. Best regards, Tanja Heimes -- Tanja Heimes / IP Engineer E-Mail Tanja.Heimes at de.cw.com Cable & Wireless Deutschland GmbH TEL. + 49 89 92699-0 Landsberger Strasse 155 Fax. + 49 89 92699-810 D-80687 Munich, Germany web: http://www.cw.com/de From joao at ripe.net Wed Apr 24 14:38:09 2002 From: joao at ripe.net (Joao Luis Silva Damas) Date: Wed, 24 Apr 2002 14:38:09 +0200 Subject: IPv6 assignments to DNS root servers in the RIPE region In-Reply-To: References: <4.3.2.7.2.20020423092142.023f8a98@localhost.ripe.net> Message-ID: At 8:08 -0400 23/4/02, Randy Bush wrote: > >"DOES" would probably be most appropriate, as it works in theory and has >been shown to work in practice For BIND versions that support IPv6 that is true. I am not sure about other DNS server software and every day there are more, which is a good thing(tm). > >> If a root server were to move and a change of address was required, it >> might be a good idea not to have another name server at the same address, >> or if you have one, let it be something that would be helping towards a >> smooth transition. > >yup. it's called prudent operation. it's not like we have not been here >before and don't have the coffee mug. people should also not announce bogus >routes to the root servers. so, should we hard-wire the routes into the >routers? Sure, if it is your router you can do whatever you want with it. I am told that just behind the upcoming RIPE meeting's venue there are some fine artists specialised in etching with different colours of ink and some electrical needles. Seriously now. I strongly believe that if a root server were to stop operations, it would be in everyone's benefit that either the address space where it is hosted moves with it OR **the address space which it was using is returned** I do not want to find out that my name server is using an old address, which replies with a hints file that might not be the one I expect. For the return/blockage/tagging to be operationally feasible, no unrelated services can ride on that address space. Joao From randy at psg.com Wed Apr 24 14:44:44 2002 From: randy at psg.com (Randy Bush) Date: Wed, 24 Apr 2002 08:44:44 -0400 Subject: IPv6 assignments to DNS root servers in the RIPE region References: <4.3.2.7.2.20020423092142.023f8a98@localhost.ripe.net> Message-ID: > Seriously now. I strongly believe that if a root server were to stop > operations, it would be in everyone's benefit that either the address > space where it is hosted moves with it OR **the address space which > it was using is returned** nope. should nasa return 128.8 just because the server is moved from 128.8.10.90? i don't think so. but, if it is moved, they should not put anything else at 128.8.10.90 for a decade or two. randy From joao at ripe.net Wed Apr 24 14:48:17 2002 From: joao at ripe.net (Joao Luis Silva Damas) Date: Wed, 24 Apr 2002 14:48:17 +0200 Subject: IPv6 assignments to DNS root servers in the RIPE region In-Reply-To: References: <4.3.2.7.2.20020423092142.023f8a98@localhost.ripe.net> Message-ID: At 8:44 -0400 24/4/02, Randy Bush wrote: > > Seriously now. I strongly believe that if a root server were to stop >> operations, it would be in everyone's benefit that either the address >> space where it is hosted moves with it OR **the address space which >> it was using is returned** > >nope. should nasa return 128.8 just because the server is moved from >128.8.10.90? i don't think so. but, if it is moved, they should not >put anything else at 128.8.10.90 for a decade or two. No, NASA should probably not return their IPv4 space. With IPv6 you can do it right, so why not do it right? Has conservation suddenly become an issue, maybe I missed that part. Joao From randy at psg.com Wed Apr 24 14:50:05 2002 From: randy at psg.com (Randy Bush) Date: Wed, 24 Apr 2002 08:50:05 -0400 Subject: IPv6 assignments to DNS root servers in the RIPE region References: <4.3.2.7.2.20020423092142.023f8a98@localhost.ripe.net> Message-ID: > No, NASA should probably not return their IPv4 space. With IPv6 you > can do it right, so why not do it right? oh, i forgot ipv6's rapid renumbering. i also forgot santa claus and the tooth fairy. randy From gert at space.net Wed Apr 24 14:54:31 2002 From: gert at space.net (Gert Doering) Date: Wed, 24 Apr 2002 14:54:31 +0200 Subject: IPv6 assignments to DNS root servers in the RIPE region In-Reply-To: ; from randy@psg.com on Wed, Apr 24, 2002 at 08:44:44AM -0400 References: <4.3.2.7.2.20020423092142.023f8a98@localhost.ripe.net> Message-ID: <20020424145431.G69684@Space.Net> Hi, On Wed, Apr 24, 2002 at 08:44:44AM -0400, Randy Bush wrote: > > Seriously now. I strongly believe that if a root server were to stop > > operations, it would be in everyone's benefit that either the address > > space where it is hosted moves with it OR **the address space which > > it was using is returned** > > nope. should nasa return 128.8 just because the server is moved from > 128.8.10.90? i don't think so. but, if it is moved, they should not > put anything else at 128.8.10.90 for a decade or two. Which makes you agree with Joao, doesn't it? The way it was done with 128.8 obviously created problems, which would mean that "special networks for root name servers" might be a good thing after all... Lacking experience with root name server operations, I didn't comment the whole proposal yet, and I'm still not sure what is "the right thing to do". Let's turn it around - which of both approaches would be "the wrong thing to do", and why? Having special-case networks for every other purpose is clearly a bad thing, but I think most would agree that root name server *are* special because that's the only thing you cannot (completely) put into DNS... With the number of root name servers, I don't see any major issues due to address wastage or enormous numbers of additional routes. Just my $0.2... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 44543 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 Apr 24 14:55:39 2002 From: gert at space.net (Gert Doering) Date: Wed, 24 Apr 2002 14:55:39 +0200 Subject: IPv6 assignments to DNS root servers in the RIPE region In-Reply-To: ; from randy@psg.com on Wed, Apr 24, 2002 at 08:50:05AM -0400 References: <4.3.2.7.2.20020423092142.023f8a98@localhost.ripe.net> Message-ID: <20020424145539.H69684@Space.Net> hi, On Wed, Apr 24, 2002 at 08:50:05AM -0400, Randy Bush wrote: > > No, NASA should probably not return their IPv4 space. With IPv6 you > > can do it right, so why not do it right? > > oh, i forgot ipv6's rapid renumbering. i also forgot santa claus and > the tooth fairy. Huh? What does this have to do with anything? This proposal is about NOT changing IPv6 root name server addresses, and NOT about "easy renumbering". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 44543 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From Guy.Davies at telindus.co.uk Wed Apr 24 15:09:49 2002 From: Guy.Davies at telindus.co.uk (Guy Davies) Date: Wed, 24 Apr 2002 14:09:49 +0100 Subject: IPv6 assignments to DNS root servers in the RIPE region Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Gert, I think what Joao was suggesting was that if the nameserver had been in NASA's v6 block, then rapid renumbering would have made it viable to demand the whole block back from NASA when the nameserver was shutdown. While this is nice in theory, I tend to agree with Randy that it is not very likely in reality for a huge organisation like NASA. Regards, Guy > -----Original Message----- > From: Gert Doering [mailto:gert at space.net] > Sent: Wednesday, April 24, 2002 1:56 PM > To: Randy Bush > Cc: Joao Luis Silva Damas; lir-wg at ripe.net; ipv6-wg at ripe.net > Subject: Re: IPv6 assignments to DNS root servers in the RIPE > region > > > hi, > > On Wed, Apr 24, 2002 at 08:50:05AM -0400, Randy Bush wrote: > > > No, NASA should probably not return their IPv4 space. > With IPv6 you > > > can do it right, so why not do it right? > > > > oh, i forgot ipv6's rapid renumbering. i also forgot santa > claus and > > the tooth fairy. > > Huh? What does this have to do with anything? > > This proposal is about NOT changing IPv6 root name server > addresses, and > NOT about "easy renumbering". > > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations: 44543 > > SpaceNet AG Mail: netmaster at Space.Net > Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 > 80807 Muenchen Fax : +49-89-32356-299 > -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.1 iQA/AwUBPMauCY3dwu/Ss2PCEQLfkwCg7upE2tAaEQ2GoHjIlRwwIEkLez8AoMjD X24zM7WSw2QARZm0DFdvnnCx =WbDK -----END PGP SIGNATURE----- This e-mail is private and may be confidential and is for the intended recipient only. If misdirected, please notify us by telephone and confirm that it has been deleted from your system and any copies destroyed. If you are not the intended recipient you are strictly prohibited from using, printing, copying, distributing or disseminating this e-mail or any information contained in it. We use reasonable endeavors to virus scan all e-mails leaving the Company but no warranty is given that this e-mail and any attachments are virus free. You should undertake your own virus checking. The right to monitor e-mail communications through our network is reserved by us. From joao at ripe.net Wed Apr 24 15:10:51 2002 From: joao at ripe.net (Joao Luis Silva Damas) Date: Wed, 24 Apr 2002 15:10:51 +0200 Subject: IPv6 assignments to DNS root servers in the RIPE region In-Reply-To: <20020424130250.GA10743@bfib.colo.bit.nl> References: <20020424130250.GA10743@bfib.colo.bit.nl> Message-ID: At 15:02 +0200 24/4/02, Pim van Pelt wrote: >Hi Joao, and other engineers, > >When deploying a set of root DNS servers, I think it is a good idea to >allocate some chunk of space (say a /32 or /31) and assign each nameserver >that we use in the RIPE region one aggregatable /35. The other RIRs can >do the same thing resulting in 24 to 48 TLAs which we can then stick >onto root nameservers. I am not sure I understand this paragraph. Are you suggesting that the address blocks where the different root servers reside should be aggregatable into one superblock? I hope not. Joao From joao at ripe.net Wed Apr 24 15:15:00 2002 From: joao at ripe.net (Joao Luis Silva Damas) Date: Wed, 24 Apr 2002 15:15:00 +0200 Subject: IPv6 assignments to DNS root servers in the RIPE region In-Reply-To: References: Message-ID: At 14:09 +0100 24/4/02, Guy Davies wrote: > >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Hi Gert, > >I think what Joao was suggesting was that if the nameserver had been >in NASA's v6 block, then rapid renumbering would have made it viable >to demand the whole block back from NASA when the nameserver was >shutdown. While this is nice in theory, I tend to agree with Randy >that it is not very likely in reality for a huge organisation like >NASA. Actually, not quite. I don't believe in IPv6 rapid renumbering. If you allow people to put other services in an address block that block will always be out there, no one will be able to reclaim it (then again I once won the lottery, so strange things do happen). Joao >Regards, > >Guy From Guy.Davies at telindus.co.uk Wed Apr 24 15:16:47 2002 From: Guy.Davies at telindus.co.uk (Guy Davies) Date: Wed, 24 Apr 2002 14:16:47 +0100 Subject: IPv6 assignments to DNS root servers in the RIPE region Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > In message > , Guy > Da vies writes: > > >Hi Gert, > > > >I think what Joao was suggesting was that if the nameserver had > >been in NASA's v6 block, then rapid renumbering would have made it > >viable to demand the whole block back from NASA when the > >nameserver was shutdown. While this is nice in theory, I tend to > >agree with Randy that it is not very likely in reality for a huge > >organisation like NASA. > > As I read it, it means that the root-server will get its own > allocation, and that allocation follows the rootserver around. That's the original discussion point. However, there's a little throwaway comment in one of Joao's subsequent emails in which he says... "No, NASA should probably not return their IPv4 space. With IPv6 you can do it right, so why not do it right?". To me, that implies that you can force an organisation like NASA to return *all* their v6 space and renumber in this kind of situation. > Sounds surprisingly reasonable to me. For the initial discussion point, yes. For the subsequent point, above, absolutely not. Guy -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.1 iQA/AwUBPMavqo3dwu/Ss2PCEQJL/wCfRGx6hetMOJqPCh/+d/thPLA9dssAn0y3 1KYq6bIEy0YhVED7SbjmdxTV =0hrB -----END PGP SIGNATURE----- This e-mail is private and may be confidential and is for the intended recipient only. If misdirected, please notify us by telephone and confirm that it has been deleted from your system and any copies destroyed. If you are not the intended recipient you are strictly prohibited from using, printing, copying, distributing or disseminating this e-mail or any information contained in it. We use reasonable endeavors to virus scan all e-mails leaving the Company but no warranty is given that this e-mail and any attachments are virus free. You should undertake your own virus checking. The right to monitor e-mail communications through our network is reserved by us. From pim at ipng.nl Wed Apr 24 15:02:50 2002 From: pim at ipng.nl (Pim van Pelt) Date: Wed, 24 Apr 2002 15:02:50 +0200 Subject: IPv6 assignments to DNS root servers in the RIPE region In-Reply-To: References: Message-ID: <20020424130250.GA10743@bfib.colo.bit.nl> Hi Joao, and other engineers, When deploying a set of root DNS servers, I think it is a good idea to allocate some chunk of space (say a /32 or /31) and assign each nameserver that we use in the RIPE region one aggregatable /35. The other RIRs can do the same thing resulting in 24 to 48 TLAs which we can then stick onto root nameservers. If one company/AS hosts the nameserver, it starts announcing that space to the world. If it then stops running the nameserver, the whole TLA can be handed over to the next company/AS who is up to the task. Doing this will not at all mean 'renumbering' as somebody mentioned, if we can decide on a standard numberplan for these special TLAs. We are not wasting space all of a suddon, if we do this. Huitema and Durand have estimated that we have lots and lots of space if we deploy sites with /48 and TLAs with /35. However, recently at the AMS-IX noc, I talked to some engineers who explained to me that they themselves have a /48 to announce with AS1200. This of course will not be reachable anywhere else than AS1200's direct peers. This is why I would like to start a discussion on some 'special TLA' in which we allow up to /48 to pass unfiltered. This way, we can organise our nameservers within one /32, and our IX:en (2001:7f8::/32) in another and let those be in the DFZ with prefixlen <= 48. I don't really understand (yet) the fuss on Joao's proposal. groet, Pim On Mon, Apr 22, 2002 at 02:41:54PM +0200, Joao Luis Silva Damas wrote: | Dear all, | | below find a proposal for a policy enabling the assignment of blocks of IPv6 addresses to Internet DNS root servers in the RIPE region. | | I would like to use the opportunity to request from the chairman of the LIR WG to include this point for discussion in the WG meeting next week. Of course, discussion in the mailing list is welcome. | | Best regards, | Joao Damas | RIPE NCC | | | **************** | | This proposal requests the adoption of a special IPv6 assignment policy | for Internet DNS root servers. It does not apply to any other | infrastructure. | | Specifically, this is not a request for a generic "special | infrastructure" IPv6 assignment policy. | | --- | | IPv6 address assignments to Internet DNS root servers in the RIPE | region | | | Internet DNS root servers are particularly critical elements of the | Internet's infrastructure. They need to be operated in a neutral and | professional manner which will not impose any artificial or unnecessary | barriers for access to their designated services. | | DNS resolvers and resolving name servers need to be pre-configured with | the network addresses of the root name servers. This makes these | addresses special and not easy to change. Hence this special policy. | | Under this policy, each (current or future) Internet DNS root server | (as listed in the root-servers.net zone) in the RIPE region will be | assigned a block of IPv6 address space for purposes of root server | operations. The size of the block shall be the same as the size of the | minimum allocation to LIRs valid at the time of the root server | assignment. | | The assigned prefix is only for root server operations and support | functions related directly to the operations, such as monitoring, | statistics, etc., and is bound to the root server service itself. | | It is not associated with the organization/s that operate the root | server at a particular point in time and these organizations should not | use the address space to provide any services not related to the root | server. | | Should the operational responsibility for a DNS root server move to a | new organization, the IPv6 address space associated with the server | will also move to the new organization. The old and the new | organizations must update the registration information with the RIPE | NCC. If the new location of the root name server is outside the RIPE | region, the address space must be returned to the RIPE NCC and a new | assignment must be requested from the appropriate RIR. | | If a root server stops operating within the RIPE region, the address | space will be returned to the RIPE NCC and marked as "reserved" for a | suitably long period of time. | | ******************* -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim at ipng.nl http://www.ipng.nl/ IPv6 Deployment ----------------------------------------------- From phk at critter.freebsd.dk Wed Apr 24 15:09:40 2002 From: phk at critter.freebsd.dk (Poul-Henning Kamp) Date: Wed, 24 Apr 2002 15:09:40 +0200 Subject: IPv6 assignments to DNS root servers in the RIPE region In-Reply-To: Your message of "Wed, 24 Apr 2002 14:09:49 BST." Message-ID: <5044.1019653780@critter.freebsd.dk> In message , Guy Da vies writes: >Hi Gert, > >I think what Joao was suggesting was that if the nameserver had been >in NASA's v6 block, then rapid renumbering would have made it viable >to demand the whole block back from NASA when the nameserver was >shutdown. While this is nice in theory, I tend to agree with Randy >that it is not very likely in reality for a huge organisation like >NASA. As I read it, it means that the root-server will get its own allocation, and that allocation follows the rootserver around. Sounds surprisingly reasonable to me. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From matthew.ford at bt.com Wed Apr 24 15:11:46 2002 From: matthew.ford at bt.com (matthew.ford at bt.com) Date: Wed, 24 Apr 2002 14:11:46 +0100 Subject: IPv6 assignments to DNS root servers in the RIPE region Message-ID: I couldn't agree more. The only conceivable objection to the proposal is that it potentially sets a precedent that will be used to trash the IPv6 routing heirarchy. Given carefully worded policy, that precedent need not be set. Mat. > -----Original Message----- > From: Gert Doering [mailto:gert at space.net] > Sent: 24 April 2002 13:55 > To: Randy Bush > Cc: Joao Luis Silva Damas; lir-wg at ripe.net; ipv6-wg at ripe.net > Subject: Re: IPv6 assignments to DNS root servers in the RIPE region > > > Hi, > > On Wed, Apr 24, 2002 at 08:44:44AM -0400, Randy Bush wrote: > > > Seriously now. I strongly believe that if a root server > were to stop > > > operations, it would be in everyone's benefit that either > the address > > > space where it is hosted moves with it OR **the address > space which > > > it was using is returned** > > > > nope. should nasa return 128.8 just because the server is > moved from > > 128.8.10.90? i don't think so. but, if it is moved, they > should not > > put anything else at 128.8.10.90 for a decade or two. > > Which makes you agree with Joao, doesn't it? The way it was done with > 128.8 obviously created problems, which would mean that > "special networks > for root name servers" might be a good thing after all... > > Lacking experience with root name server operations, I didn't comment > the whole proposal yet, and I'm still not sure what is "the > right thing > to do". > > Let's turn it around - which of both approaches would be "the > wrong thing > to do", and why? > > Having special-case networks for every other purpose is clearly a bad > thing, but I think most would agree that root name server > *are* special > because that's the only thing you cannot (completely) put into DNS... > > With the number of root name servers, I don't see any major issues due > to address wastage or enormous numbers of additional routes. > > Just my $0.2... > > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations: 44543 > > SpaceNet AG Mail: netmaster at Space.Net > Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 > 80807 Muenchen Fax : +49-89-32356-299 > From plzak at arin.net Wed Apr 24 15:22:43 2002 From: plzak at arin.net (Ray Plzak) Date: Wed, 24 Apr 2002 09:22:43 -0400 Subject: IPv6 assignments to DNS root servers in the RIPE region In-Reply-To: Message-ID: <002a01c1eb93$1df1cbb0$94fc95c0@ano> I agree with Joao in regards to there not being one superblock. Ray > -----Original Message----- > From: owner-ipv6-wg at ripe.net [mailto:owner-ipv6-wg at ripe.net] > On Behalf Of Joao Luis Silva Damas > Sent: Wednesday, April 24, 2002 9:11 AM > To: Pim van Pelt > Cc: lir-wg at ripe.net; ipv6-wg at ripe.net > Subject: Re: IPv6 assignments to DNS root servers in the RIPE region > > > At 15:02 +0200 24/4/02, Pim van Pelt wrote: > >Hi Joao, and other engineers, > > > >When deploying a set of root DNS servers, I think it is a > good idea to > >allocate some chunk of space (say a /32 or /31) and assign each > >nameserver that we use in the RIPE region one aggregatable /35. The > >other RIRs can do the same thing resulting in 24 to 48 TLAs which we > >can then stick onto root nameservers. > > > I am not sure I understand this paragraph. Are you suggesting that > the address blocks where the different root servers reside should be > aggregatable into one superblock? I hope not. > > Joao > From joao at ripe.net Wed Apr 24 15:52:10 2002 From: joao at ripe.net (Joao Luis Silva Damas) Date: Wed, 24 Apr 2002 15:52:10 +0200 Subject: Transferring InterNIC space from ARIN Database to other RIR databases Message-ID: Dear all, Sometime ago we started a thread about distributing address space issued prior to the existence of the RIRs, which is currently registered at the ARIN database (imported from the InterNIC's database), to the RIR that now operates in the region where the address space is registered as used. Doing this would simplify processes such as modifying the name servers for in-addr.arpa for those addresses, changing contact information, etc as the user will issue requests for change to the RIR in their region, the one with which they will normally be more familiar. Both ARIN and the RIPE NCC are now ready to proceed with this. There are some aspects, however, where community input is required and I would like to ask you to comment on the proposal below. Note: the examples at the bottom are just examples. We do not want to imply there is anything wrong with the objects mentioned. Best regards, Joao Damas RIPE NCC -------------------------------------------- Proposed procedure for migration of legacy objects from ARIN Database When moving data from the ARIN database into the RIPE Database the situation is not, unfortunately, always without conflicts. Some data that is in the ARIN database also has an entry in the RIPE database. While the ARIN database is the one which contains the authoritative information for the set of name servers used in in-addr.arpa resolution for the addresses in question (the in-addr.arpa zone file is generated from that data), sometimes the administrative contacts seem to be more up to date in the RIPE database. Below are a set of proposals for actions when transferring the data: I. inetnum objects 1. There are several types of conflicts with the data in the RIPE Database: 1.1 Exact matches with RIPE networks (4325) *Proposal: to override data in the RIPE Database with ARIN's. If the object in the RIPE database has a "changed" date more recent than the object in the ARIN database, contact information from the RIPE database is kept and the nameservers are the ones in the ARIN database. 1.2 ARIN network contains a RIPE network(s) (169) 1.2.1. ARIN's allocation, while multiple assignments are registered in the RIPE Database *Proposal: to keep RIPE's and ARIN's data 1.2.2. Minor Mismatch *Proposal: to override data in the RIPE Database with ARIN's 1.3 ARIN network is contained in a RIPE network (3060) *Proposal: to keep ARIN's data and delete RIPE network 1.4. Objects in the ARIN database only *Proposal: to put ARIN's data in the RIPE Database 2. Protection of the transferred inetnums *Proposal: To create a mntner object for each ARIN's 'coordinator'. Syntax could be: mntner: -MNT mnt-by: -MNT auth: MAIL-FROM ... Then we protect inetnums 'owned' by the coordinator with this maintainer. Should be the same level of security as currently at ARIN. Note: it could be different if the POC is merged/replaced by existing RIPE person object (see further discussion). II. POC objects 1. Try to match POCs from ARIN DB to the existing person objects in the RIPE DB (762) The implication is that we use the person's e-mail address as authorization (see proposal above) * Proposal: to contact all affected persons in advance and have a more clear picture before the transfer. Questions to ask: - Do both records represent the same person? - Would (s)he like to merge the contact data, in what manner? After an answer to these questions is received: - Discuss protection issue (existing maintainer, coordinator's maintainer, auth). Needs human work. 2. Protection of the transferred POCs * Proposal: to add mnt-by referencing a respective coordinator's maintainer. ---------------- Examples I.1.2.1 inetnum: 130.242.0.0 - 130.243.255.255 netname: SUNETREGAB-RIPE descr: European Regional Internet Registry/RIPE NCC descr: These addresses have been further assigned descr: to European users. Contact information can descr: be found in the RIPE database at whois.ripe.net country: NL admin-c: RIPE-NCC-ARIN rev-srv: sunic.sunet.se rev-srv: falun.dns.swip.net rev-srv: ns.ripe.net status: ALLOCATION changed: hostmaster at arin.net 20000329 source: ARIN ... inetnum: 130.242.43.0 - 130.242.43.255 netname: SE-TEKNISKAMUSEET descr: Tekniska Museet country: SE admin-c: HALI1-RIPE tech-c: HALI1-RIPE status: ASSIGNED PA mnt-by: SUNET-MNT changed: fredrik at sunet.se 19981022 source: RIPE inetnum: 130.242.48.0 - 130.242.48.255 netname: SE-ARMEMUSEUM descr: Statens Forsvarshistoriska Museer country: SE admin-c: BOMI1-RIPE tech-c: LEPE1-RIPE status: ASSIGNED PA mnt-by: SUNET-MNT changed: fredrik at sunet.se 19981022 source: RIPE ... I.1.2.2 inetnum: 131.117.0.0 - 131.117.128.255 netname: ZUERI descr: Municipality of Zuerich descr: Wilhelmstr. 10 descr: Zurich, 8021 descr: CH country: CH admin-c: BM153-ARIN status: ASSIGNMENT changed: hostmaster at arin.net 19980824 source: ARIN inetnum: 131.117.0.0 - 131.117.127.255 netname: ZUERI-NET descr: Municipality of Zuerich descr: Zuerich, Switzerland country: CH admin-c: BM16-RIPE tech-c: BM16-RIPE changed: huber at switch.ch 19950412 source: RIPE I.1.3 inetnum: 130.138.0.0 - 130.140.255.255 netname: PHILIPS descr: Philips C&P/NBS descr: Eindhoven country: NL admin-c: HS6189-RIPE tech-c: HS6189-RIPE notify: H.Sanders at mpn.cp.philips.com changed: geertj at ripe.net 19940106 changed: H.Sanders at mpn.cp.philips.com 19960131 changed: ripe-dbm at ripe.net 19990706 changed: ripe-dbm at ripe.net 20000225 source: RIPE inetnum: 130.138.0.0 - 130.138.255.255 netname: PHILIPS-SERI-1 descr: Philips Components BV descr: Building BC136 descr: Hurkesestraat 9 descr: 5600 MD Eindhoven descr: THE NETHERLANDS country: NL admin-c: OK6-ARIN status: REASSIGNMENT changed: hostmaster at arin.net 19930413 source: ARIN II.1 person: Antonio_Blasco Bonito address: Rodinet S.a.s. address: Via Cavour 6 address: I-54033 Carrara address: Italy phone: +39 0585 779435 fax-no: +39 0585 757385 e-mail: Antonio-Blasco.Bonito at rodinet.com nic-hdl: ABB2 changed: blasco at rodinet.com 19990310 source: RIPE person: A. Blasco Bonito address: GARR-NIS address: c/o CNR-Istituto CNUCE address: via Santa Maria 36 phone: +39 50 593246 fax-no: +39 50 904052 e-mail: bonito at NIS.GARR.IT nic-hdl: ABB2-ARIN changed: hostmaster at arin.net 19931201 source: ARIN From pim at ipng.nl Wed Apr 24 15:38:31 2002 From: pim at ipng.nl (Pim van Pelt) Date: Wed, 24 Apr 2002 15:38:31 +0200 Subject: IPv6 assignments to DNS root servers in the RIPE region In-Reply-To: References: <20020424130250.GA10743@bfib.colo.bit.nl> Message-ID: <20020424133831.GA11259@bfib.colo.bit.nl> On Wed, Apr 24, 2002 at 03:10:51PM +0200, Joao Luis Silva Damas wrote: | At 15:02 +0200 24/4/02, Pim van Pelt wrote: | >Hi Joao, and other engineers, | > | >When deploying a set of root DNS servers, I think it is a good idea to | >allocate some chunk of space (say a /32 or /31) and assign each nameserver | >that we use in the RIPE region one aggregatable /35. The other RIRs can | >do the same thing resulting in 24 to 48 TLAs which we can then stick | >onto root nameservers. | | I am not sure I understand this paragraph. Are you suggesting that | the address blocks where the different root servers reside should be | aggregatable into one superblock? I hope not. I did not say that these should be combined into one aggregatable block at all. I said that if we were to allocate a /32 for use of DNS root nameservers, that we would have 8 /35s herein, and 16 /35s if we were to allocate a /31 for the use of DNS. All three RIRs would then have 24 or 48 of these /35 TLAs respectively. By the way, some paragraphs down the line I actually DID propose to create an administrative hierarchy based on /48 aggregates but I fully realise that his is going out on a limb. I think however, that if we were to use 'n' TLAs for nameservers, that I would prefer to see 'n' /48s in my routing table than 'n' /35s, this of course from the conservation point of view. The same holds for Internet Exchanges. Perhaps for other sites as well. How do we plan to have AMS-IX reachable from networks that do not peer with AS1200, if the AMS-IX is assigned only a /48 ? I see two possibilities (obvious ones, that is). 1. Allocate /35 to AMS-IX and let it announce that from AS1200 2. Make global policy to have 2001:7f8::/32 prefixlen 48 and lower allowable. This latter solution could be extended to any number of services and sites. Sorry if I am rocking the boat here ;-) groet, Pim -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim at ipng.nl http://www.ipng.nl/ IPv6 Deployment ----------------------------------------------- From henner at nerim.net Wed Apr 24 15:50:17 2002 From: henner at nerim.net (Xavier Henner) Date: Wed, 24 Apr 2002 15:50:17 +0200 Subject: IPv6 assignments to DNS root servers in the RIPE region In-Reply-To: <5044.1019653780@critter.freebsd.dk>; from phk@critter.freebsd.dk on Wed, Apr 24, 2002 at 03:09:40PM +0200 References: <5044.1019653780@critter.freebsd.dk> Message-ID: <20020424155017.A19285@euclide.org> > As I read it, it means that the root-server will get its own > allocation, and that allocation follows the rootserver around. > > Sounds surprisingly reasonable to me. Have a TLA by root server is acceptable. We can then have a fixed root.hint and, why not, include it inside the DNS servers (if root servers never change, why specify them in a dynamic configuration file ?). It can be a default config to have out of the box working DNS servers. But it could be a good thing to explicitly forbid the use of these TLA to any other purpose than hosting a root server and its basic network infrastructure. If organization foo has the X root server and use par of X root server's TLA for anything else, it can be a problem the day organization foo stops hosting the service and has to give back the TLA. We can also change the rfc to add, for example that root servers are located in specific, static adresses. -- Xavier Henner Responsable de l'exp?rimentation IPv6 Nerim -- Fournisseur d'acc?s ? Internet URL: From gert at space.net Wed Apr 24 16:00:18 2002 From: gert at space.net (Gert Doering) Date: Wed, 24 Apr 2002 16:00:18 +0200 Subject: IPv6 assignments to DNS root servers in the RIPE region In-Reply-To: ; from Guy.Davies@telindus.co.uk on Wed, Apr 24, 2002 at 02:09:49PM +0100 References: Message-ID: <20020424160018.I69684@Space.Net> Hi, On Wed, Apr 24, 2002 at 02:09:49PM +0100, Guy Davies wrote: > I think what Joao was suggesting was that if the nameserver had been > in NASA's v6 block, then rapid renumbering would have made it viable > to demand the whole block back from NASA when the nameserver was > shutdown. While this is nice in theory, I tend to agree with Randy > that it is not very likely in reality for a huge organisation like > NASA. I understood Joao's proposal differently. If I remember correctly, it explicitely says that this "special IPv6 space" MUST NOT be used for anything not related to IPv6 root operation. So if an organization runs a root server, they would have to have two distinct IPv6 prefixes for "root DNS related" and "all our other stuff". If they use the same IPv6 space for both, they will experience pain, but the proposal explicitely says "do not do that". So if the root server goes away, this special prefix goes away, and the "normal" address space is *untouched* - which makes Randy agree with Joao, in a way: if we do it the "old" way, we can't take the IPv6 address away - but that is not what Joao is proposing. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 44543 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From henner at nerim.net Wed Apr 24 16:00:42 2002 From: henner at nerim.net (Xavier Henner) Date: Wed, 24 Apr 2002 16:00:42 +0200 Subject: IPv6 assignments to DNS root servers in the RIPE region In-Reply-To: <20020424133831.GA11259@bfib.colo.bit.nl>; from pim@ipng.nl on Wed, Apr 24, 2002 at 03:38:31PM +0200 References: <20020424130250.GA10743@bfib.colo.bit.nl> <20020424133831.GA11259@bfib.colo.bit.nl> Message-ID: <20020424160042.B19285@euclide.org> > create an administrative hierarchy based on /48 aggregates but I fully > realise that his is going out on a limb. I think however, that if we > were to use 'n' TLAs for nameservers, that I would prefer to see 'n' > /48s in my routing table than 'n' /35s, this of course from the > conservation point of view. > > The same holds for Internet Exchanges. Perhaps for other sites as well. > How do we plan to have AMS-IX reachable from networks that do not peer > with AS1200, if the AMS-IX is assigned only a /48 ? I see two > possibilities (obvious ones, that is). > 1. Allocate /35 to AMS-IX and let it announce that from AS1200 > 2. Make global policy to have 2001:7f8::/32 prefixlen 48 and lower > allowable. 3. http://www.ripe.net/ripencc/mem-services/registration/ipv6/eix-interim.html Or is this document deprecated ? IX can have non globally routable adress space. The NOC of an IX can have a /48 from any ISP, like any other organization. I don't see the problem here. -- Xavier Henner Responsable de l'exp?rimentation IPv6 Nerim -- Fournisseur d'acc?s ? Internet URL: From henk.steenman at ams-ix.net Wed Apr 24 16:25:49 2002 From: henk.steenman at ams-ix.net (Henk Steenman) Date: 24 Apr 2002 16:25:49 +0200 Subject: IPv6 assignments to DNS root servers in the RIPE region In-Reply-To: <20020424160042.B19285@euclide.org> References: <20020424130250.GA10743@bfib.colo.bit.nl> <20020424133831.GA11259@bfib.colo.bit.nl> <20020424160042.B19285@euclide.org> Message-ID: <1019658350.12973.40.camel@localhost.localdomain> On Wed, 2002-04-24 at 16:00, Xavier Henner wrote: > > create an administrative hierarchy based on /48 aggregates but I fully > > realise that his is going out on a limb. I think however, that if we > > were to use 'n' TLAs for nameservers, that I would prefer to see 'n' > > /48s in my routing table than 'n' /35s, this of course from the > > conservation point of view. > > > > The same holds for Internet Exchanges. Perhaps for other sites as well. > > How do we plan to have AMS-IX reachable from networks that do not peer > > with AS1200, if the AMS-IX is assigned only a /48 ? I see two > > possibilities (obvious ones, that is). > > 1. Allocate /35 to AMS-IX and let it announce that from AS1200 > > 2. Make global policy to have 2001:7f8::/32 prefixlen 48 and lower > > allowable. > 3. http://www.ripe.net/ripencc/mem-services/registration/ipv6/eix-interim.html > > Or is this document deprecated ? > > IX can have non globally routable adress space. > The NOC of an IX can have a /48 from any ISP, like any other organization. > I don't see the problem here. Like for any other organization the problem here is multihoming but an additional problem is that as a neutral meeting point for a lot of ISPs/Carriers, as an Exchange we don't want a special relation with one of our members/customers and choosing one of them as a provider for address space and upstream provide does just that -- - Henk Henk Steenman tel: +31 20 514 1711 Amsterdam Internet Exchange mobile: +31 65 131 2774 http://www.ams-ix.net e-mail: Henk.Steenman at ams-ix.net From gert at space.net Wed Apr 24 16:49:44 2002 From: gert at space.net (Gert Doering) Date: Wed, 24 Apr 2002 16:49:44 +0200 Subject: IPv6/IXes [was: Re: IPv6 assignments to DNS root servers] In-Reply-To: ; from arien.vijn@ams-ix.net on Wed, Apr 24, 2002 at 04:45:30PM +0200 References: <20020424160042.B19285@euclide.org> Message-ID: <20020424164944.K69684@Space.Net> Hi, On Wed, Apr 24, 2002 at 04:45:30PM +0200, Arien Vijn wrote: > > IX can have non globally routable adress space. > > The NOC of an IX can have a /48 from any ISP, like any other organization. > > As neutral IX we can not do this. This might not be as obvious since there > are non-neutral IXes which are owned by one particular company. Could we please keep these discussions separate? This is a different issue (and has been discussed to death in various IPv6-WG meetings). An IX is no different concerning *upstream* connectivity than any other "I want to be multihomed" customer. The special part about IXes is if they have a non-globally visible exchange LAN - those special networks are for *that* (only). No IX is forced to use that. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 44543 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From dominic at ripe.net Wed Apr 24 17:00:28 2002 From: dominic at ripe.net (Dominic Spratley) Date: Wed, 24 Apr 2002 17:00:28 +0200 Subject: Creation of Reverse Delegation Objects In-Reply-To: <3CC66284.F0346AA5@de.cw.net> Message-ID: <5.1.0.14.2.20020424165353.0218e9b8@mailhost.ripe.net> Hi Tanja, There are several reasons why we do not accept requests directly from end-users. Most are based on the fact that the Internet Registry system is hierarchical. This means that we are funded by LIRs to provide services to them, not to end-users. LIRs have more expertise in dealing with the RIPE Database than End Users. This is the main reason for requiring requests to come from them. Yours sincerely, Dominic Spratley, R.S. Assistant Manager, RIPE NCC At 09:45 AM 4/24/2002 +0200, Tanja Heimes wrote: >Hi All, > >this ist the response of the RIPE Robot to one of our customers after he >tried to create a reverse delegation object in the RIPE DB: > >"The RIPE NCC no longer accepts requests for creation and ammendments >of reverse delegations which do not include the registry ID of an >existing Local Internet Registry. > >If you are not a representative of an LIR, you should contact the >LIR who assigned you the address space, or your upstream provider..." > >The customers owns his Provider Independent IP address space and is not >able to create this object as he needs to state a >reg-id in the request. Now this customers (and others in the past) claim >that they have to apply to there upstream provider in >order that this ISP creates the object. The customer certainly has is >own maintainer. > >My question now: > >Should Provider Indepent IP space not be 100% Provider Indepent in >concern to its administration in the RIPE DB? >In my opinion the RIPE Robot should distinguish between PA and PI space >and not request an reg-id for customers that own PI >space and like to create a reverse delegation record. > >Best regards, > >Tanja Heimes > > >-- >Tanja Heimes / IP Engineer E-Mail Tanja.Heimes at de.cw.com > >Cable & Wireless Deutschland GmbH TEL. + 49 89 92699-0 >Landsberger Strasse 155 Fax. + 49 89 92699-810 >D-80687 Munich, Germany web: http://www.cw.com/de From gert at space.net Wed Apr 24 17:47:17 2002 From: gert at space.net (Gert Doering) Date: Wed, 24 Apr 2002 17:47:17 +0200 Subject: IPv6/IXes [was: Re: IPv6 assignments to DNS root servers] In-Reply-To: ; from arien.vijn@ams-ix.net on Wed, Apr 24, 2002 at 05:38:23PM +0200 References: <20020424164944.K69684@Space.Net> Message-ID: <20020424174717.L69684@Space.Net> Hi, On Wed, Apr 24, 2002 at 05:38:23PM +0200, Arien Vijn wrote: > On 24-04-2002 16:49PM, "Gert Doering" wrote: > >>> IX can have non globally routable adress space. > >>> The NOC of an IX can have a /48 from any ISP, like any other organization. > >> > >> As neutral IX we can not do this. This might not be as obvious since there > >> are non-neutral IXes which are owned by one particular company. > > > > Could we please keep these discussions separate? > > This is a different issue. > > In a sense it is not. It's about situations on which the aggregation model > is not applicable because of neutrality and independence. Please do not come > with statements that this does not mean anything. This is very much different. One is about "addresses that are special because they need to be hard-wired into applications and must not be tied to specific organizations", while the other is "organizations that want or do not want to be multihomed" > >(and has been discussed to death in various IPv6-WG meetings). > > Afraid it will be a point of discussion until this issue is resolved > properly. Sorry. The fact that you don't like the outcome of the previous discussions doesn't mean that it has to be intermixed into every other IPv6 policy discussion that is going on. > > An IX is no different concerning *upstream* connectivity than any other > > "I want to be multihomed" customer. > > Who's customer? Please do understand that some IXes just can not be a > customer of one individual member. Adressing and business relations are different issues. > >The special part about IXes is > > if they have a non-globally visible exchange LAN - those special networks > > are for *that* (only). No IX is forced to use that. > > OK. We want to have the ISP exchange LAN globally visible. What are the > options? > > Should apply for a /35 to use one /64 out of it? What good does this do to > routing table sizes? Where is the difference in the impact on the global routing table whether you announce one (1) /64 or one (1) /35? None. Bad argument. > Should we leave the address space assigned to *one* of the members? *Then* > neutrality will mean have no meaning. Neutrality and member-independence is important for the peering mesh (as the fabric that BGP is run over, which would make a real mess if the member providing the address space goes away). For global routing, you will be dependent on a subset of your members anyway - as not everybody might be willing to provide transit, and not everybody has comparable international connections. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 44543 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From woeber at cc.univie.ac.at Wed Apr 24 19:10:35 2002 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 24 Apr 2002 19:10:35 +0200 Subject: Creation of Reverse Delegation Objects Message-ID: <00A0CF4C.2D135B3E.6@cc.univie.ac.at> Hi Dominic, >Date: Wed, 24 Apr 2002 17:00:28 +0200 >To: Tanja Heimes >From: Dominic Spratley >Subject: Re: Creation of Reverse Delegation Objects >CC: lir-wg at ripe.net > >Hi Tanja, > >There are several reasons why we do not accept requests directly >from end-users. Most are based on the fact that the Internet >Registry system is hierarchical. This means that we are funded by >LIRs to provide services to them, not to end-users. From _quite_ a distance, I tend to agree, in principle, but. Looking at the details, you are (from my point of view) over-simplifying the situation. E.g. there are probably quite a few holders of "traditional" address space which have a considerably higher clue-level that some LIRs. And, there _IS_ (or is this was?) a mandate for the NCC to provide services or functions for the community at large (just have a look at the annual activity descriptions which get agreed in the RIPE Community and ultimately get approved by the members once a year). Not all of these activities have to be channeled through (the wait queue for) a particular LIR. But my biggest point of concern here is that this is another instance where pretty *fundamental* operational (and policy) changes get implemented unilaterally by the NCC (should I say hostmaster group here?), without discussion, approval, and a look at the consequences and *NOT EVEN* an information being distributed those *AFFECTED*: the LIR community. We are left to find out by chance. > >LIRs have more expertise in dealing with the RIPE Database than >End Users. This is the main reason for requiring requests to come >from them. > >Yours sincerely, > > >Dominic Spratley, > >R.S. Assistant Manager, >RIPE NCC In my books this is very bad management style! Respectfully, Wilfried Woeber, (at.aconet) _________________________________:_____________________________________ 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 joao at ripe.net Wed Apr 24 19:44:23 2002 From: joao at ripe.net (Joao Luis Silva Damas) Date: Wed, 24 Apr 2002 19:44:23 +0200 (CEST) Subject: Creation of Reverse Delegation Objects In-Reply-To: <00A0CF4C.2D135B3E.6@cc.univie.ac.at> Message-ID: Dear Wilfried, I wholeheartedly agree with your arguments: There *IS* indeed a mandate on the RIPE NCC to provide services to the community at large. The RIPE Database is a fine example. However, the handling of the in-addr tree is a membership service and as such only available to members of the RIPE NCC Association. I agree with the fact that old hats usually have greater knowledge than new hats (though not always). Those are usually either LIRs or have their address space registered at the ARIN Database (and yes this becomes an issue to discuss in view of the pending transfer of "legacy" space from ARIN to the RIPE NCC). I agree with the fact that the RIPE NCC should not change things unilaterally and without discussion (though we should not become inoperative). However Tanja is the one requesting the change. The RIPE NCC hasn't changed the behaviour of the in-addr robot for longer than I have been here (and that's about 50% of the RIPE NCC's life already) I agree that you don't want things like this to be put into a wait queue. The in-addr robot has nothing to do with any wait queue. If the command is sent correctly no hostmaster ever looks at the request. The robot analyzes it, does the DNS checks and registers the new set of name servers in the RIPE Database (assuming all is OK). Most of the requests get done that way, without human intervention. Having the reg.id enables the robot to check whether the requester is a member or not. I also agree that Dominic's mail might have been a bit oversimplified, probably from the fact that a lot of context was taken for granted. I hope to have filled you in with this message Regards, joao From arien.vijn at ams-ix.net Wed Apr 24 17:38:23 2002 From: arien.vijn at ams-ix.net (Arien Vijn) Date: Wed, 24 Apr 2002 17:38:23 +0200 Subject: IPv6/IXes [was: Re: IPv6 assignments to DNS root servers] In-Reply-To: <20020424164944.K69684@Space.Net> Message-ID: On 24-04-2002 16:49PM, "Gert Doering" wrote: > Hi, > > On Wed, Apr 24, 2002 at 04:45:30PM +0200, Arien Vijn wrote: >>> IX can have non globally routable adress space. >>> The NOC of an IX can have a /48 from any ISP, like any other organization. >> >> As neutral IX we can not do this. This might not be as obvious since there >> are non-neutral IXes which are owned by one particular company. > > Could we please keep these discussions separate? > This is a different issue. In a sense it is not. It's about situations on which the aggregation model is not applicable because of neutrality and independence. Please do not come with statements that this does not mean anything. >(and has been discussed to death in various IPv6-WG meetings). > Afraid it will be a point of discussion until this issue is resolved properly. Sorry. > An IX is no different concerning *upstream* connectivity than any other > "I want to be multihomed" customer. Who's customer? Please do understand that some IXes just can not be a customer of one individual member. >The special part about IXes is > if they have a non-globally visible exchange LAN - those special networks > are for *that* (only). No IX is forced to use that. > OK. We want to have the ISP exchange LAN globally visible. What are the options? Should apply for a /35 to use one /64 out of it? What good does this do to routing table sizes? Should we leave the address space assigned to *one* of the members? *Then* neutrality will mean have no meaning. > Gert Doering > -- NetMaster -- Arien Vijn tel: +31 205 141 718 Amsterdam Internet Exchange mobile: +31 651 836 444 http://www.ams-ix.net e-mail: arien.vijn at ams-ix.net From lyric at verio.net Wed Apr 24 18:05:20 2002 From: lyric at verio.net (lyric apted) Date: Wed, 24 Apr 2002 16:05:20 +0000 (GMT) Subject: Creation of Reverse Delegation Objects In-Reply-To: <5.1.0.14.2.20020424165353.0218e9b8@mailhost.ripe.net> Message-ID: but RIPE gave the customer the space - it is PI space not PA space, the 'end customer' should be able to take care of their own space... -lyric On Wed, 24 Apr 2002, Dominic Spratley wrote: > Hi Tanja, > > There are several reasons why we do not accept requests directly > from end-users. Most are based on the fact that the Internet > Registry system is hierarchical. This means that we are funded by > LIRs to provide services to them, not to end-users. > > LIRs have more expertise in dealing with the RIPE Database than > End Users. This is the main reason for requiring requests to come > from them. > > Yours sincerely, > > > Dominic Spratley, > > R.S. Assistant Manager, > RIPE NCC > > > > At 09:45 AM 4/24/2002 +0200, Tanja Heimes wrote: > >Hi All, > > > >this ist the response of the RIPE Robot to one of our customers after he > >tried to create a reverse delegation object in the RIPE DB: > > > >"The RIPE NCC no longer accepts requests for creation and ammendments > >of reverse delegations which do not include the registry ID of an > >existing Local Internet Registry. > > > >If you are not a representative of an LIR, you should contact the > >LIR who assigned you the address space, or your upstream provider..." > > > >The customers owns his Provider Independent IP address space and is not > >able to create this object as he needs to state a > >reg-id in the request. Now this customers (and others in the past) claim > >that they have to apply to there upstream provider in > >order that this ISP creates the object. The customer certainly has is > >own maintainer. > > > >My question now: > > > >Should Provider Indepent IP space not be 100% Provider Indepent in > >concern to its administration in the RIPE DB? > >In my opinion the RIPE Robot should distinguish between PA and PI space > >and not request an reg-id for customers that own PI > >space and like to create a reverse delegation record. > > > >Best regards, > > > >Tanja Heimes > > > > > >-- > >Tanja Heimes / IP Engineer E-Mail Tanja.Heimes at de.cw.com > > > >Cable & Wireless Deutschland GmbH TEL. + 49 89 92699-0 > >Landsberger Strasse 155 Fax. + 49 89 92699-810 > >D-80687 Munich, Germany web: http://www.cw.com/de > > ------------------------------ lyric apted ip engineering manager, vipar lyric at verio.net 425.649.7491 ntt/verio ------------------------------ From Gabriella.Paolini at garr.it Wed Apr 24 16:37:06 2002 From: Gabriella.Paolini at garr.it (Gabriella Paolini) Date: Wed, 24 Apr 2002 16:37:06 +0200 Subject: Transferring InterNIC space from ARIN Database to other RIR databases References: Message-ID: <3CC6C312.9050709@garr.it> Dear Joao, first of all, let me say, I'm very happy to read your mail! About your proposal, the great problem of the Arin DB is that the data are connected to a person and not to a Maintainer / LIR. So, in some cases, people changed, email adresses changed, but ARIN data were the same. I think it's easy (for a lot of these objects) to understand what is the RIPE maintainer/LIR of reference. After understanding that, you can 1) ask each one how they want to do the transition; (too difficult?) 2) ask them to modify or add data in RIPE DB and after, delete data in ARIN DB. About person objects, I think a lot of ARIN data are old and incorrect (Antonio_Blasco Bonito is a good example) and it's better to prefer RIPE data and delete the ARIN data. kind regards, Gabriella -- Gabriella Paolini ------------------------------------------------- GARR - The Italian Academic and Research Network http://www.garr.it INFN-GARR Via Tiburtina, 770 I-00159 Rome - Italy tel: +39 06 433614 33 fax: +39 06 433614 44 m at il: gabriella.paolini at garr.it ------------------------------------------------- Joao Luis Silva Damas wrote: > Dear all, > > Sometime ago we started a thread about distributing address space issued > prior to the existence of the RIRs, which is currently registered at the > ARIN database (imported from the InterNIC's database), to the RIR that > now operates in the region where the address space is registered as used. > > Doing this would simplify processes such as modifying the name servers > for in-addr.arpa for those addresses, changing contact information, etc > as the user will issue requests for change to the RIR in their region, > the one with which they will normally be more familiar. > > Both ARIN and the RIPE NCC are now ready to proceed with this. > > There are some aspects, however, where community input is required and I > would like to ask you to comment on the proposal below. > > Note: the examples at the bottom are just examples. We do not want to > imply there is anything wrong with the objects mentioned. > > Best regards, > Joao Damas > RIPE NCC > > -------------------------------------------- > Proposed procedure for migration of legacy objects from ARIN Database > > When moving data from the ARIN database into the RIPE Database the > situation is not, unfortunately, always without conflicts. > Some data that is in the ARIN database also has an entry in the RIPE > database. > > While the ARIN database is the one which contains the authoritative > information for the set of name servers used in in-addr.arpa resolution > for the addresses in question (the in-addr.arpa zone file is generated > from that data), sometimes the administrative contacts seem to be more > up to date in the RIPE database. > > Below are a set of proposals for actions when transferring the data: > > > I. inetnum objects > > 1. There are several types of conflicts with the data in the RIPE > Database: > 1.1 Exact matches with RIPE networks (4325) > *Proposal: to override data in the RIPE Database with ARIN's. > If the object in the RIPE database has a "changed" date more > recent than the object in the ARIN database, contact information > from the RIPE database is kept and the nameservers are the > ones in the ARIN database. > 1.2 ARIN network contains a RIPE network(s) (169) > 1.2.1. ARIN's allocation, while multiple assignments are registered > in the RIPE Database > *Proposal: to keep RIPE's and ARIN's data > 1.2.2. Minor Mismatch > *Proposal: to override data in the RIPE Database with ARIN's > 1.3 ARIN network is contained in a RIPE network (3060) > *Proposal: to keep ARIN's data and delete RIPE network > 1.4. Objects in the ARIN database only > *Proposal: to put ARIN's data in the RIPE Database > > 2. Protection of the transferred inetnums > *Proposal: > To create a mntner object for each ARIN's 'coordinator'. Syntax could > be: > > mntner: -MNT > mnt-by: -MNT > auth: MAIL-FROM > ... > > Then we protect inetnums 'owned' by the coordinator with this > maintainer. Should be the same level of security as currently at ARIN. > Note: it could be different if the POC is merged/replaced by existing > RIPE person object (see further discussion). > > II. POC objects > 1. Try to match POCs from ARIN DB to the existing person objects in the > RIPE DB (762) > The implication is that we use the person's e-mail address as authorization > (see proposal above) > * Proposal: to contact all affected persons in advance and have a > more clear > picture before the transfer. Questions to ask: > - Do both records represent the same person? > - Would (s)he like to merge the contact data, in what manner? > After an answer to these questions is received: > - Discuss protection issue (existing maintainer, coordinator's > maintainer, auth). > > Needs human work. > > 2. Protection of the transferred POCs > * Proposal: to add mnt-by referencing a respective coordinator's > maintainer. > > > ---------------- > Examples > > > I.1.2.1 > inetnum: 130.242.0.0 - 130.243.255.255 > netname: SUNETREGAB-RIPE > descr: European Regional Internet Registry/RIPE NCC > descr: These addresses have been further assigned > descr: to European users. Contact information can > descr: be found in the RIPE database at whois.ripe.net > country: NL > admin-c: RIPE-NCC-ARIN > rev-srv: sunic.sunet.se > rev-srv: falun.dns.swip.net > rev-srv: ns.ripe.net > status: ALLOCATION > changed: hostmaster at arin.net 20000329 > source: ARIN > > ... > inetnum: 130.242.43.0 - 130.242.43.255 > netname: SE-TEKNISKAMUSEET > descr: Tekniska Museet > country: SE > admin-c: HALI1-RIPE > tech-c: HALI1-RIPE > status: ASSIGNED PA > mnt-by: SUNET-MNT > changed: fredrik at sunet.se 19981022 > source: RIPE > > inetnum: 130.242.48.0 - 130.242.48.255 > netname: SE-ARMEMUSEUM > descr: Statens Forsvarshistoriska Museer > country: SE > admin-c: BOMI1-RIPE > tech-c: LEPE1-RIPE > status: ASSIGNED PA > mnt-by: SUNET-MNT > changed: fredrik at sunet.se 19981022 > source: RIPE > ... > > I.1.2.2 > inetnum: 131.117.0.0 - 131.117.128.255 > netname: ZUERI > descr: Municipality of Zuerich > descr: Wilhelmstr. 10 > descr: Zurich, 8021 > descr: CH > country: CH > admin-c: BM153-ARIN > status: ASSIGNMENT > changed: hostmaster at arin.net 19980824 > source: ARIN > > inetnum: 131.117.0.0 - 131.117.127.255 > netname: ZUERI-NET > descr: Municipality of Zuerich > descr: Zuerich, Switzerland > country: CH > admin-c: BM16-RIPE > tech-c: BM16-RIPE > changed: huber at switch.ch 19950412 > source: RIPE > > > I.1.3 > > inetnum: 130.138.0.0 - 130.140.255.255 > netname: PHILIPS > descr: Philips C&P/NBS > descr: Eindhoven > country: NL > admin-c: HS6189-RIPE > tech-c: HS6189-RIPE > notify: H.Sanders at mpn.cp.philips.com > changed: geertj at ripe.net 19940106 > changed: H.Sanders at mpn.cp.philips.com 19960131 > changed: ripe-dbm at ripe.net 19990706 > changed: ripe-dbm at ripe.net 20000225 > source: RIPE > > inetnum: 130.138.0.0 - 130.138.255.255 > netname: PHILIPS-SERI-1 > descr: Philips Components BV > descr: Building BC136 > descr: Hurkesestraat 9 > descr: 5600 MD Eindhoven > descr: THE NETHERLANDS > country: NL > admin-c: OK6-ARIN > status: REASSIGNMENT > changed: hostmaster at arin.net 19930413 > source: ARIN > > II.1 > > person: Antonio_Blasco Bonito > address: Rodinet S.a.s. > address: Via Cavour 6 > address: I-54033 Carrara > address: Italy > phone: +39 0585 779435 > fax-no: +39 0585 757385 > e-mail: Antonio-Blasco.Bonito at rodinet.com > nic-hdl: ABB2 > changed: blasco at rodinet.com 19990310 > source: RIPE > > > person: A. Blasco Bonito > address: GARR-NIS > address: c/o CNR-Istituto CNUCE > address: via Santa Maria 36 > phone: +39 50 593246 > fax-no: +39 50 904052 > e-mail: bonito at NIS.GARR.IT > nic-hdl: ABB2-ARIN > changed: hostmaster at arin.net 19931201 > source: ARIN > From arien.vijn at ams-ix.net Wed Apr 24 16:45:30 2002 From: arien.vijn at ams-ix.net (Arien Vijn) Date: Wed, 24 Apr 2002 16:45:30 +0200 Subject: IPv6 assignments to DNS root servers in the RIPE region In-Reply-To: <20020424160042.B19285@euclide.org> Message-ID: On 24-04-2002 16:00PM, "Xavier Henner" wrote: >> create an administrative hierarchy based on /48 aggregates but I fully >> realise that his is going out on a limb. I think however, that if we >> were to use 'n' TLAs for nameservers, that I would prefer to see 'n' >> /48s in my routing table than 'n' /35s, this of course from the >> conservation point of view. >> >> The same holds for Internet Exchanges. Perhaps for other sites as well. >> How do we plan to have AMS-IX reachable from networks that do not peer >> with AS1200, if the AMS-IX is assigned only a /48 ? I see two >> possibilities (obvious ones, that is). >> 1. Allocate /35 to AMS-IX and let it announce that from AS1200 >> 2. Make global policy to have 2001:7f8::/32 prefixlen 48 and lower >> allowable. > 3. http://www.ripe.net/ripencc/mem-services/registration/ipv6/eix-interim.html > > Or is this document deprecated ? > The problem is point 5. > IX can have non globally routable adress space. > The NOC of an IX can have a /48 from any ISP, like any other organization. As neutral IX we can not do this. This might not be as obvious since there are non-neutral IXes which are owned by one particular company. AMS-IX is not owned by one party. We are an association of all parties connecting to it. It is not desirable to have a customer relationship with one particular member. Because every member is equal. This is the basis of our existents. Although it might be not as obvious as root DNS servers it is at a smaller scale exactly the same issue. Some things can not be "owned". > I don't see the problem here. Hope this explained the problem. If not please say so and I'll try to find better words. Kind regards, Arien -- Arien Vijn tel: +31 205 141 718 Amsterdam Internet Exchange mobile: +31 651 836 444 http://www.ams-ix.net e-mail: arien.vijn at ams-ix.net From theimes at de.cw.com Wed Apr 24 18:36:48 2002 From: theimes at de.cw.com (Tanja Heimes) Date: Wed, 24 Apr 2002 18:36:48 +0200 Subject: Creation of Reverse Delegation Objects References: Message-ID: <3CC6DF20.865319F1@de.cw.com> Hi Dominic, if my customer got PI space so he owns his own maintainer with its own authorization method. Why should he give me his password and why should I have to deal with failure messsages of the Marvin Robot and the Hostmasters and forward this messages out to the customer in order that he will correct his DNS settings. I face this problem many times that customers did not set up correctly their zones on their DNS servers. This is the problem of the customer that owns the PI space so why should a upstream provider that very often even did not arrange the PI space for this customer administer this records. The administartion of this things are wasting my time. I completely agree that for PA space RIPE does not deal with end-users - but I am still in the opionion that the policiy regarding PI space should be changed. If the customer owns PI space he should administer this space by himself even the reverse delegations. Best regards, Tanja Heimes lyric apted wrote: > > but RIPE gave the customer the space - it is PI space not PA space, the > 'end customer' should be able to take care of their own space... > > -lyric > > On Wed, 24 Apr 2002, Dominic Spratley wrote: > > > Hi Tanja, > > > > There are several reasons why we do not accept requests directly > > from end-users. Most are based on the fact that the Internet > > Registry system is hierarchical. This means that we are funded by > > LIRs to provide services to them, not to end-users. > > > > LIRs have more expertise in dealing with the RIPE Database than > > End Users. This is the main reason for requiring requests to come > > from them. > > > > Yours sincerely, > > > > > > Dominic Spratley, > > > > R.S. Assistant Manager, > > RIPE NCC > > > > > > > > At 09:45 AM 4/24/2002 +0200, Tanja Heimes wrote: > > >Hi All, > > > > > >this ist the response of the RIPE Robot to one of our customers after he > > >tried to create a reverse delegation object in the RIPE DB: > > > > > >"The RIPE NCC no longer accepts requests for creation and ammendments > > >of reverse delegations which do not include the registry ID of an > > >existing Local Internet Registry. > > > > > >If you are not a representative of an LIR, you should contact the > > >LIR who assigned you the address space, or your upstream provider..." > > > > > >The customers owns his Provider Independent IP address space and is not > > >able to create this object as he needs to state a > > >reg-id in the request. Now this customers (and others in the past) claim > > >that they have to apply to there upstream provider in > > >order that this ISP creates the object. The customer certainly has is > > >own maintainer. > > > > > >My question now: > > > > > >Should Provider Indepent IP space not be 100% Provider Indepent in > > >concern to its administration in the RIPE DB? > > >In my opinion the RIPE Robot should distinguish between PA and PI space > > >and not request an reg-id for customers that own PI > > >space and like to create a reverse delegation record. > > > > > >Best regards, > > > > > >Tanja Heimes > > > > > > > > >-- > > >Tanja Heimes / IP Engineer E-Mail Tanja.Heimes at de.cw.com > > > > > >Cable & Wireless Deutschland GmbH TEL. + 49 89 92699-0 > > >Landsberger Strasse 155 Fax. + 49 89 92699-810 > > >D-80687 Munich, Germany web: http://www.cw.com/de > > > > > > ------------------------------ > lyric apted > ip engineering manager, vipar > lyric at verio.net > 425.649.7491 > > ntt/verio > ------------------------------ From theimes at de.cw.com Wed Apr 24 19:51:44 2002 From: theimes at de.cw.com (Tanja Heimes) Date: Wed, 24 Apr 2002 19:51:44 +0200 Subject: Creation of Reverse Delegation Objects References: <00A0CF4C.2D135B3E.6@cc.univie.ac.at> Message-ID: <3CC6F0B0.68C20650@de.cw.com> Dominic, I am sorry but if LIRs are more expertised in using the RIPE DB than end-users should not receive PI space, aut-num, and maintainer. Owners of PI space can update ther AS and PI inetnums and maintainer in the DB with their authorization method - so why should they not be able to update their reverse delegations of their PI space? If RIPE is serving only the RIPE community - than Provider Independent space should not exist. Regard, Tanja Heimes "Wilfried Woeber, UniVie/ACOnet" wrote: > > Hi Dominic, > > >Date: Wed, 24 Apr 2002 17:00:28 +0200 > >To: Tanja Heimes > >From: Dominic Spratley > >Subject: Re: Creation of Reverse Delegation Objects > >CC: lir-wg at ripe.net > > > >Hi Tanja, > > > >There are several reasons why we do not accept requests directly > >from end-users. Most are based on the fact that the Internet > >Registry system is hierarchical. This means that we are funded by > >LIRs to provide services to them, not to end-users. > > From _quite_ a distance, I tend to agree, in principle, but. > > Looking at the details, you are (from my point of view) over-simplifying > the situation. E.g. there are probably quite a few holders of > "traditional" address space which have a considerably higher clue-level > that some LIRs. > > And, there _IS_ (or is this was?) a mandate for the NCC to provide > services or functions for the community at large (just have a look at > the annual activity descriptions which get agreed in the RIPE Community > and ultimately get approved by the members once a year). > > Not all of these activities have to be channeled through (the wait queue > for) a particular LIR. > > But my biggest point of concern here is that this is another instance > where pretty *fundamental* operational (and policy) changes get > implemented unilaterally by the NCC (should I say hostmaster group > here?), without discussion, approval, and a look at the consequences and > *NOT EVEN* an information being distributed those *AFFECTED*: the LIR > community. We are left to find out by chance. > > > > >LIRs have more expertise in dealing with the RIPE Database than > >End Users. This is the main reason for requiring requests to come > >from them. > > > >Yours sincerely, > > > > > >Dominic Spratley, > > > >R.S. Assistant Manager, > >RIPE NCC > > In my books this is very bad management style! > > Respectfully, > Wilfried Woeber, (at.aconet) > _________________________________:_____________________________________ > 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 thinman at clp.cw.net Wed Apr 24 20:51:02 2002 From: thinman at clp.cw.net (Tanya Hinman) Date: Wed, 24 Apr 2002 14:51:02 -0400 Subject: Creation of Reverse Delegation Objects In-Reply-To: <3CC6F0B0.68C20650@de.cw.com> Message-ID: Dominic, I agree completely with Tanja. PI space should not be assigned to End-Users if they cannot be responsible for it, including the reverse delegation. Regards, Tanya Hinman -----Original Message----- From: owner-lir-wg at ripe.net [mailto:owner-lir-wg at ripe.net]On Behalf Of Tanja Heimes Sent: Wednesday, April 24, 2002 1:52 PM To: Wilfried Woeber, UniVie/ACOnet Cc: lir-wg at ripe.net Subject: Re: Creation of Reverse Delegation Objects Dominic, I am sorry but if LIRs are more expertised in using the RIPE DB than end-users should not receive PI space, aut-num, and maintainer. Owners of PI space can update ther AS and PI inetnums and maintainer in the DB with their authorization method - so why should they not be able to update their reverse delegations of their PI space? If RIPE is serving only the RIPE community - than Provider Independent space should not exist. Regard, Tanja Heimes "Wilfried Woeber, UniVie/ACOnet" wrote: > > Hi Dominic, > > >Date: Wed, 24 Apr 2002 17:00:28 +0200 > >To: Tanja Heimes > >From: Dominic Spratley > >Subject: Re: Creation of Reverse Delegation Objects > >CC: lir-wg at ripe.net > > > >Hi Tanja, > > > >There are several reasons why we do not accept requests directly > >from end-users. Most are based on the fact that the Internet > >Registry system is hierarchical. This means that we are funded by > >LIRs to provide services to them, not to end-users. > > From _quite_ a distance, I tend to agree, in principle, but. > > Looking at the details, you are (from my point of view) over-simplifying > the situation. E.g. there are probably quite a few holders of > "traditional" address space which have a considerably higher clue-level > that some LIRs. > > And, there _IS_ (or is this was?) a mandate for the NCC to provide > services or functions for the community at large (just have a look at > the annual activity descriptions which get agreed in the RIPE Community > and ultimately get approved by the members once a year). > > Not all of these activities have to be channeled through (the wait queue > for) a particular LIR. > > But my biggest point of concern here is that this is another instance > where pretty *fundamental* operational (and policy) changes get > implemented unilaterally by the NCC (should I say hostmaster group > here?), without discussion, approval, and a look at the consequences and > *NOT EVEN* an information being distributed those *AFFECTED*: the LIR > community. We are left to find out by chance. > > > > >LIRs have more expertise in dealing with the RIPE Database than > >End Users. This is the main reason for requiring requests to come > >from them. > > > >Yours sincerely, > > > > > >Dominic Spratley, > > > >R.S. Assistant Manager, > >RIPE NCC > > In my books this is very bad management style! > > Respectfully, > Wilfried Woeber, (at.aconet) > _________________________________:_____________________________________ > 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 Apr 24 21:02:22 2002 From: gert at space.net (Gert Doering) Date: Wed, 24 Apr 2002 21:02:22 +0200 Subject: Creation of Reverse Delegation Objects In-Reply-To: ; from thinman@clp.cw.net on Wed, Apr 24, 2002 at 02:51:02PM -0400 References: <3CC6F0B0.68C20650@de.cw.com> Message-ID: <20020424210222.O69684@Space.Net> Hi, On Wed, Apr 24, 2002 at 02:51:02PM -0400, Tanya Hinman wrote: > I agree completely with Tanja. PI space should not be assigned to End-Users > if they cannot be responsible for it, including the reverse delegation. I feel tempted to shorten that sentence further to "PI space should not be assigned to End-Users" but I am afraid this isn't too workable. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 44543 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From randy at psg.com Wed Apr 24 21:51:23 2002 From: randy at psg.com (Randy Bush) Date: Wed, 24 Apr 2002 15:51:23 -0400 Subject: IPv6 assignments to DNS root servers in the RIPE region References: <4.3.2.7.2.20020423092142.023f8a98@localhost.ripe.net> <20020424145431.G69684@Space.Net> Message-ID: >> nope. should nasa return 128.8 just because the server is moved from >> 128.8.10.90? i don't think so. but, if it is moved, they should not >> put anything else at 128.8.10.90 for a decade or two. > Which makes you agree with Joao, doesn't it? The way it was done with > 128.8 obviously created problems, which would mean that "special networks > for root name servers" might be a good thing after all... no, quite the opposite o nasa should just not put another host at that HOST address o and the kremlin should not announce 128.8/16 o and all the other obvious things that we operators are paid to do and not do. randy From hph at online.no Thu Apr 25 00:31:10 2002 From: hph at online.no (Hans Petter Holen) Date: Thu, 25 Apr 2002 00:31:10 +0200 Subject: Creation of Reverse Delegation Objects References: Message-ID: <008201c1ebdf$bc3c7e40$8000a8c0@cq> > There *IS* indeed a mandate on the RIPE NCC to provide services to the > community at large. The RIPE Database is a fine example. However, the handling of > the in-addr tree is a membership service and as such only available to > members of the RIPE NCC Association. I think Wilfrieds said: >But my biggest point of concern here is that this is another instance > where pretty *fundamental* operational (and policy) changes get > implemented unilaterally by the NCC (should I say hostmaster group > here?), without discussion, approval, and a look at the consequences and > *NOT EVEN* an information being distributed those *AFFECTED*: the LIR > community. We are left to find out by chance. I would rephrase: When was this deceided and by whom ? -hph From he at uninett.no Thu Apr 25 00:52:07 2002 From: he at uninett.no (Havard Eidnes) Date: Thu, 25 Apr 2002 00:52:07 +0200 (CEST) Subject: Transferring InterNIC space from ARIN Database to other RIR databases In-Reply-To: References: Message-ID: <20020425.005207.82052548.he@uninett.no> Hi, I may not have had my attention in focus when this was discussed the last time around, so I hope you will excuse me for asking some simple questions which may already have been given their reply. I understand that what is happening is that the "master source" for the affected registrations is being moved from (in our case) ARIN to the RIPE NCC. o I suppose this means that in-addr.arpa updates will after this change be done only against the RIPE database for those pieces of address space which is transferred? o Can the RIPE NCC shed some light on how the in-addr.arpa zone generation will happen "behind the scenes" after this change? E.g. what would the typical latency be between "update of registration data in the RIPE DB" to "visibility in the DNS"? o After the move of the authority for the data, what information will the ARIN database return when queried via whois? A pointer to the RIPE NCC (as happens now for the larger RIPE address blocks), or a "slave" copy of of the data from the RIPE database? I think this looks otherwise fine -- I suspect some of us will have to do some tidy-up work in the aftermath of the move no matter what. Regards, - H?vard From wsx at wsx6.net Wed Apr 24 20:41:24 2002 From: wsx at wsx6.net (Jan Oravec) Date: Wed, 24 Apr 2002 20:41:24 +0200 Subject: IPv6 assignments to DNS root servers in the RIPE region In-Reply-To: <20020424133831.GA11259@bfib.colo.bit.nl> References: <20020424130250.GA10743@bfib.colo.bit.nl> <20020424133831.GA11259@bfib.colo.bit.nl> Message-ID: <20020424184124.GA16977@hades.xs26.net> On Wed, Apr 24, 2002 at 03:38:31PM +0200, Pim van Pelt wrote: > On Wed, Apr 24, 2002 at 03:10:51PM +0200, Joao Luis Silva Damas wrote: > | At 15:02 +0200 24/4/02, Pim van Pelt wrote: > | >Hi Joao, and other engineers, > | > > | >When deploying a set of root DNS servers, I think it is a good idea to > | >allocate some chunk of space (say a /32 or /31) and assign each nameserver > | >that we use in the RIPE region one aggregatable /35. The other RIRs can > | >do the same thing resulting in 24 to 48 TLAs which we can then stick > | >onto root nameservers. > | > | I am not sure I understand this paragraph. Are you suggesting that > | the address blocks where the different root servers reside should be > | aggregatable into one superblock? I hope not. > > I did not say that these should be combined into one aggregatable block > at all. I said that if we were to allocate a /32 for use of DNS root > nameservers, that we would have 8 /35s herein, and 16 /35s if we were to > allocate a /31 for the use of DNS. All three RIRs would then have 24 or 48 > of these /35 TLAs respectively. I would prefer if IANA, rather than RIRs, assigns TLAs for root nameservers. That will make transfering root nameserver between regions easier. Root nameservers are something related to whole Internet, thus we shall not divide it between regions. > By the way, some paragraphs down the line I actually DID propose to > create an administrative hierarchy based on /48 aggregates but I fully > realise that his is going out on a limb. I think however, that if we > were to use 'n' TLAs for nameservers, that I would prefer to see 'n' > /48s in my routing table than 'n' /35s, this of course from the > conservation point of view. That would require additional filter rules. I think that allowed size of announced prefixes should be some range and we shall not partition IPv6 address space in many parts with different allowed prefix lengths. More filter rules == higher CPU usage. > The same holds for Internet Exchanges. Perhaps for other sites as well. > How do we plan to have AMS-IX reachable from networks that do not peer > with AS1200, if the AMS-IX is assigned only a /48 ? I see two > possibilities (obvious ones, that is). > 1. Allocate /35 to AMS-IX and let it announce that from AS1200 I agree with this one. > 2. Make global policy to have 2001:7f8::/32 prefixlen 48 and lower > allowable. See above. Regards, -- Jan Oravec project coordinator XS26 - 'Access to IPv6' http://www.xs26.net jan.oravec at xs26.net From henner at nerim.net Wed Apr 24 21:06:55 2002 From: henner at nerim.net (Xavier Henner) Date: Wed, 24 Apr 2002 21:06:55 +0200 Subject: IPv6/IXes [was: Re: IPv6 assignments to DNS root servers] In-Reply-To: ; from arien.vijn@ams-ix.net on Wed, Apr 24, 2002 at 05:38:23PM +0200 References: <20020424164944.K69684@Space.Net> Message-ID: <20020424210655.A22134@euclide.org> > Afraid it will be a point of discussion until this issue is resolved > properly. Sorry. > > > An IX is no different concerning *upstream* connectivity than any other > > "I want to be multihomed" customer. > > Who's customer? Please do understand that some IXes just can not be a > customer of one individual member. Why not be a "customer" af ALL individual members ? If ISP X want to be on AMS-IX, you give an IP from the /64. And the ISP gives you a /48 and transit. There is still the multihoming problem, with a little change : AMS-IX will have a lot of upstreams. You have independance and neutrality for your transit. The /64 is given directly by the RIR : you have independance and neutrality for your IP adresses The /64 has not to be routable globally. For the DNS root servers, the problem is that they must have a real PI adress which is routable globally and which will never change. -- Xavier Henner Responsable de l'exp?rimentation IPv6 Nerim -- Fournisseur d'acc?s ? Internet URL: From theimes at de.cw.com Wed Apr 24 21:28:46 2002 From: theimes at de.cw.com (Tanja Heimes) Date: Wed, 24 Apr 2002 21:28:46 +0200 Subject: Creation of Reverse Delegation Objects References: <3CC6F0B0.68C20650@de.cw.com> <20020424210222.O69684@Space.Net> Message-ID: <3CC7076E.FB2E97F2@de.cw.com> Gert Doering wrote: > > Hi, > > On Wed, Apr 24, 2002 at 02:51:02PM -0400, Tanya Hinman wrote: > > I agree completely with Tanja. PI space should not be assigned to End-Users > > if they cannot be responsible for it, including the reverse delegation. > > I feel tempted to shorten that sentence further to > > "PI space should not be assigned to End-Users" > .....this would propably solve the routability problems Tanja Heimes > but I am afraid this isn't too workable. > > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations: 44543 > > SpaceNet AG Mail: netmaster at Space.Net > Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 > 80807 Muenchen Fax : +49-89-32356-299 From jhma at mcvax.org Wed Apr 24 23:34:56 2002 From: jhma at mcvax.org (James Aldridge) Date: Wed, 24 Apr 2002 21:34:56 +0000 Subject: Creation of Reverse Delegation Objects In-Reply-To: Message from Gert Doering of "Wed, 24 Apr 2002 21:02:22 +0200." <20020424210222.O69684@Space.Net> Message-ID: Gert Doering wrote: > Hi, > > On Wed, Apr 24, 2002 at 02:51:02PM -0400, Tanya Hinman wrote: > > I agree completely with Tanja. PI space should not be assigned to End-Users > > if they cannot be responsible for it, including the reverse delegation. > > I feel tempted to shorten that sentence further to > > "PI space should not be assigned to End-Users" > > but I am afraid this isn't too workable. How about simply "PI space should not be assigned." (if not to an end-user, then to whom?) ;-) However, you request PI space from a LIR. Why not request in-addr.arpa delegation from this same LIR at the same time? Once the delegation is in place you are free to change provider as much as you like but there is no reason to change the DNS setup (after all, you've got yourself PI address space and your master nameserver's in that space, isn't it?) James From woeber at cc.univie.ac.at Thu Apr 25 10:28:13 2002 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 25 Apr 2002 10:28:13 +0200 Subject: Creation of Reverse Delegation Objects Message-ID: <00A0CFCC.5E849D7E.7@cc.univie.ac.at> Hi Joao! >Date: Wed, 24 Apr 2002 19:44:23 +0200 (CEST) >From: Joao Luis Silva Damas >To: "Wilfried Woeber, UniVie/ACOnet" >CC: lir-wg at ripe.net >Subject: Re: Creation of Reverse Delegation Objects > >Dear Wilfried, thanks for the very useful explanations! It turns out that we were discussing a non-issue - mostly. Sorry for getting started again, yesterday, it was the style of the 1st answer... >I wholeheartedly agree with your arguments: > >There *IS* indeed a mandate on the RIPE NCC to provide services to the >community at large. > > [ snip ] > > ... Those are usually either LIRs or have their >address space registered at the ARIN Database (and yes this becomes an >issue to discuss in view of the pending transfer of "legacy" space from >ARIN to the RIPE NCC). Where do you propose to discuss those things? LIR / DB / somewhere else? For scheduling reasons, I do have a preference for DB, but it's your decision. >I hope to have filled you in with this message Indeed, thanks again. >Regards, >joao Cheers, Wilfried. From joao at ripe.net Thu Apr 25 11:08:39 2002 From: joao at ripe.net (Joao Luis Silva Damas) Date: Thu, 25 Apr 2002 11:08:39 +0200 Subject: Transferring InterNIC space from ARIN Database to other RIR databases In-Reply-To: <20020425.005207.82052548.he@uninett.no> References: <20020425.005207.82052548.he@uninett.no> Message-ID: Hi H?vard, At 0:52 +0200 25/4/02, Havard Eidnes wrote: >Hi, > >I may not have had my attention in focus when this was discussed the >last time around, so I hope you will excuse me for asking some simple >questions which may already have been given their reply. > >I understand that what is happening is that the "master source" for >the affected registrations is being moved from (in our case) ARIN to >the RIPE NCC. > > o I suppose this means that in-addr.arpa updates will after this > change be done only against the RIPE database for those pieces of > address space which is transferred? Yes, the main goal of the exercise is to simplify the current process, which is a hassle for everyone involved. > o Can the RIPE NCC shed some light on how the in-addr.arpa zone > generation will happen "behind the scenes" after this change? E.g. > what would the typical latency be between "update of registration > data in the RIPE DB" to "visibility in the DNS"? The in-addr.arpa zone will (already has?) 256 entries, with delegations to nameservers of the RIRs for each /8. For each /8 one of the RIRs will be the primary. Which it is will be decided by counting the number of registrations on each /8 (ARIN has already done this). If there are registrations for several RIRs in a particular /8 then the RIR that are not the primary will send information to the primary for inclusion in the zone file. The proposed frequency of update is, I recall correctly, at least twice a day. > o After the move of the authority for the data, what information will > the ARIN database return when queried via whois? A pointer to the > RIPE NCC (as happens now for the larger RIPE address blocks), or a > "slave" copy of of the data from the RIPE database? A pointer seems to be the more favoured approach right now. >I think this looks otherwise fine -- I suspect some of us will have to >do some tidy-up work in the aftermath of the move no matter what. A good thing, even though it is a bit of a pain. regards Jo?o From Rimas.Janusauskas at sc.vu.lt Thu Apr 25 16:27:37 2002 From: Rimas.Janusauskas at sc.vu.lt (Rimas Janusauskas) Date: Thu, 25 Apr 2002 16:27:37 +0200 (GMT) Subject: Creation of Reverse Delegation Objects In-Reply-To: <5.1.0.14.2.20020424165353.0218e9b8@mailhost.ripe.net> Message-ID: Hi all, Maybe it makes sense to cover PI assignments as zz.unspecified registry? This should not harm checking robot and/or end-user ;-) Regards, Rimas Janusauskas, Vilnius University Hostmaster On Wed, 24 Apr 2002, Dominic Spratley wrote: > Date: Wed, 24 Apr 2002 17:00:28 +0200 > From: Dominic Spratley > To: Tanja Heimes > Cc: lir-wg at ripe.net > Subject: Re: Creation of Reverse Delegation Objects > > Hi Tanja, > > There are several reasons why we do not accept requests directly > from end-users. Most are based on the fact that the Internet > Registry system is hierarchical. This means that we are funded by > LIRs to provide services to them, not to end-users. > > Yours sincerely, > > > Dominic Spratley, > > R.S. Assistant Manager, > RIPE NCC > > > > At 09:45 AM 4/24/2002 +0200, Tanja Heimes wrote: > > > >My question now: > > > >Should Provider Indepent IP space not be 100% Provider Indepent in > >concern to its administration in the RIPE DB? > >In my opinion the RIPE Robot should distinguish between PA and PI space > >and not request an reg-id for customers that own PI > >space and like to create a reverse delegation record. > > > >Best regards, > > > >Tanja Heimes > > From Rimas.Janusauskas at sc.vu.lt Thu Apr 25 18:06:53 2002 From: Rimas.Janusauskas at sc.vu.lt (Rimas Janusauskas) Date: Thu, 25 Apr 2002 18:06:53 +0200 (GMT) Subject: Creation of Reverse Delegation Objects In-Reply-To: <3CC8220A.B608A4A9@de.cw.net> Message-ID: On Thu, 25 Apr 2002, Tanja Heimes wrote: > Date: Thu, 25 Apr 2002 17:34:34 +0200 > From: Tanja Heimes > To: Rimas Janusauskas > Cc: Dominic Spratley , lir-wg at ripe.net > Subject: Re: Creation of Reverse Delegation Objects > > Rimas, > > you mean - than end-users could use this zz.unspecified reg-id in order > to perform reverse delegation > records by themselves? > > > Tanja > Exactly! Dominic could correct me if I'm wrong: message with reverse address delegation reguest is checked for regID; if found, it's ckecked, do address space is allocated to the registry; if yes - further actions on reguest are taken. So, if introduce zz.unspecified RegID for PI address assignments, the described scheme should work. One more thing: section 5.3.4 of ripe-185 might be revised, if my proposal seems acceptable. Current statement: 5.3.4.Side Effects for PA/PI Assignments End users have a right to reverse mapping services. An end user holding non-PA address space from a zone that has been reverse delegated to one service provider is permitted to keep the address space, and obtain connectivity services from another provider. Because the address space falls in the reverse delegation zone of the initial Local IR, that IR is required to continue to provide reverse mapping services for the address space assigned to the end user. Moreover, the Local IR has to provide this service under the same conditions it applies to its other end users (e.g. extremely high fees for this service are unacceptable - unless they are applied to all end users.) IMHO, this is shortest way to eliminate contradiction. Best regards, Rimas From david at IPRG.nokia.com Fri Apr 26 02:47:59 2002 From: david at IPRG.nokia.com (David Kessens) Date: Thu, 25 Apr 2002 17:47:59 -0700 Subject: FWD: [GLOBAL-V6] New draft available: IPv6 Address Allocation and Assignment Global Policy Message-ID: <20020425174759.B17766@iprg.nokia.com> For your information: You might want to read the latest iteration of the 'IPv6 Address Allocation and Assignment Global Policy' draft before the actual discussion of the draft during the lir wg session at the RIPE meeting next week. David K. --- ----- Forwarded message from Thomas Narten ----- X-Delivered-For: X-mProtect: <200204251156> Nokia Silicon Valley Messaging Protection X-Authentication-Warning: data.staff.apnic.net: majordom set sender to owner-global-v6 at lists.apnic.net using -f To: global-v6 at lists.apnic.net Subject: [GLOBAL-V6] New draft available: IPv6 Address Allocation and Assignment Global Policy Date: Thu, 25 Apr 2002 06:54:02 -0400 From: Thomas Narten X-Scanned-By: MIMEDefang 2.1 (www dot roaringpenguin dot com slash mimedefang) X-Scanned-By: MIMEDefang 2.1 (www dot roaringpenguin dot com slash mimedefang) A revised version of the IPv6 address document is now available. It incorporates feedback from the recent RIPE, APNIC and ARIN discussions, as well as many wording cleanups. It is believed that the document is consisent with the discussions held so far and the consensus calls of APNIC and ARIN. The document can be found at: IPv6 Address Allocation and Assignment Global Policy ftp://ftp.cs.duke.edu/pub/narten/ietf/global-ipv6-assign-2002-04-25.txt Thomas - - This list (global-v6) is handled by majordomo at lists.apnic.net ----- End forwarded message ----- From arien.vijn at ams-ix.net Thu Apr 25 17:12:47 2002 From: arien.vijn at ams-ix.net (Arien Vijn) Date: Thu, 25 Apr 2002 17:12:47 +0200 Subject: IPv6/IXes [was: Re: IPv6 assignments to DNS root servers] In-Reply-To: <20020424210655.A22134@euclide.org> Message-ID: Thanks for your suggestion Xavier. This scenario of site multi-homing might take care of global routable IPv6 services. But it is no solution for a global reachable peering LAN. With regards of services I would be reluctant to work this way. Only 12 of 130 members do "something" with IPv6. My guess is that only one might be willing to assign a /48 out of their RIR TLA. Would not be a bases to deploy IPv6 services? I don't think so. I would rather stick with our 6Bone /24 then. With regards of a global routable peering LAN. I know there are pros and cons to that. But those are for an IX and its members to decide on. Thanks again for this constructive contribution. Kind regards, Arien On 24-04-2002 21:06PM, "Xavier Henner" wrote: >> Afraid it will be a point of discussion until this issue is resolved >> properly. Sorry. >> >>> An IX is no different concerning *upstream* connectivity than any other >>> "I want to be multihomed" customer. >> >> Who's customer? Please do understand that some IXes just can not be a >> customer of one individual member. > > Why not be a "customer" af ALL individual members ? > > If ISP X want to be on AMS-IX, you give an IP from the /64. > And the ISP gives you a /48 and transit. > > There is still the multihoming problem, with a little change : > AMS-IX will have a lot of upstreams. > > You have independance and neutrality for your transit. > > The /64 is given directly by the RIR : you have independance and neutrality > for > your IP adresses > > The /64 has not to be routable globally. > Not nescesaraly but for analisye an trouble shooiting purposes we think this this is desirbale to have this glopbaly routable. > > For the DNS root servers, the problem is that they must have a real PI adress > which is routable globally and which will never change. > I recognize this. > > -- > Xavier Henner > Responsable de l'exp?rimentation IPv6 > Nerim -- Fournisseur d'acc?s ? Internet > URL: > > -- Arien Vijn tel: +31 205 141 718 Amsterdam Internet Exchange mobile: +31 651 836 444 http://www.ams-ix.net e-mail: arien.vijn at ams-ix.net From theimes at de.cw.net Thu Apr 25 17:34:34 2002 From: theimes at de.cw.net (Tanja Heimes) Date: Thu, 25 Apr 2002 17:34:34 +0200 Subject: Creation of Reverse Delegation Objects References: Message-ID: <3CC8220A.B608A4A9@de.cw.net> Rimas, you mean - than end-users could use this zz.unspecified reg-id in order to perform reverse delegation records by themselves? Tanja Rimas Janusauskas wrote: > > Hi all, > > Maybe it makes sense to cover PI assignments as zz.unspecified > registry? > > This should not harm checking robot and/or end-user ;-) > > Regards, > > Rimas Janusauskas, > Vilnius University Hostmaster > > On Wed, 24 Apr 2002, Dominic Spratley wrote: > > > Date: Wed, 24 Apr 2002 17:00:28 +0200 > > From: Dominic Spratley > > To: Tanja Heimes > > Cc: lir-wg at ripe.net > > Subject: Re: Creation of Reverse Delegation Objects > > > > Hi Tanja, > > > > There are several reasons why we do not accept requests directly > > from end-users. Most are based on the fact that the Internet > > Registry system is hierarchical. This means that we are funded by > > LIRs to provide services to them, not to end-users. > > > > Yours sincerely, > > > > > > Dominic Spratley, > > > > R.S. Assistant Manager, > > RIPE NCC > > > > > > > > At 09:45 AM 4/24/2002 +0200, Tanja Heimes wrote: > > > > > > >My question now: > > > > > >Should Provider Indepent IP space not be 100% Provider Indepent in > > >concern to its administration in the RIPE DB? > > >In my opinion the RIPE Robot should distinguish between PA and PI space > > >and not request an reg-id for customers that own PI > > >space and like to create a reverse delegation record. > > > > > >Best regards, > > > > > >Tanja Heimes > > > -- Tanja Heimes / IP Engineer E-Mail Tanja.Heimes at de.cw.com Cable & Wireless Deutschland GmbH TEL. + 49 89 92699-0 Landsberger Strasse 155 Fax. + 49 89 92699-810 D-80687 Munich, Germany web: http://www.cw.com/de From kristian.rastas at sonera.com Fri Apr 26 09:38:17 2002 From: kristian.rastas at sonera.com (Kristian Rastas) Date: Fri, 26 Apr 2002 09:38:17 +0200 Subject: Transferring InterNIC space from ARIN Database to other RIR databases In-Reply-To: Message-ID: <4.2.0.58.20020425190134.00c148c0@mail.intra.sonera.fi> Hello all, First, I'm very delighted to see some official action with this issue to happen. Here are some comments and experiences to share. Our LIR has been dealing with this InterNIC-space issue some time already. We started our individual transfer process back 1999 and now it is almost completed. There were other off topic things than plain address transfers, that is why it has taken so long time. We have now moved five /16 allocations from ARIN to RIPE-db but there are some individual, not very well aggregatable /24's still remaining in ARIN-db and of course the reverse information is still there. From my personal experience I think the following points among others already mentioned should be noted, when transfers are planned or made: - Good coordination between ARIN,RIPE-NCC and LIR, maybe some dedicated hostmaster(s) to dig into this from RIRs part, because this project needs lots of interaction. Some documentation or FAQ for LIRs/users would be nice, how to start and proceed. Also ARIN's way of presenting db-data is somewhat different compared to RIPE. Not all LIR's and especially not customers are familiar of it at first glance. Db-reports provided by ARIN-staff proved to be very helpfull when we did the cross referencing between RIPE-db and ARIN-db. -Only one ticketing point should be used, it was frustrating to track things between two RIRs, especially when they were not so very well aware of each others doings. Not to blaim them, on the contrary, they were very helpfull in general. - LIRs should be prepared to do some detective work, because many of the individual networks are not more in the hands they were originally given and maybe even not in use at all or visible in the public network at the time of transfer moment, but some customers may still use it inside or wants to use it as a public address space in the near future. They may even have the original documentation for the address space, but they didn't knew how to update the data in ARIN-db or whom to contact. How to decide what to do with these "black" networks ? Leave as they are or delete ? Some public announcement to reach the real users ? (yes, I fully understand, the problem isn't new and the transfer isn't a solution for unmaintained LIR-independant data, but we shouldn't really add more carbage in the RIPE-db) - Status of the old networks (PA/PI), how to determine that, can we just make new PI-assignments to RIPE-db ??? - Reverse transfers should be done and timing planned with care and the confirmation is needed from the customers/LIRs, because wrongly pasted/copied data causes BIG troubles, (We unfortunately experienced this with one update) - Care should be taken not to loose the original dates with same customers in ARIN-db, otherwise it will distract the AW-tools RIPE-NCC has. Back to the original proposal. >* Proposal: to contact all affected persons in advance and have a more clear >picture before the transfer. Questions to ask: > - Do both records represent the same person? > - Would (s)he like to merge the contact data, in what manner? >After an answer to these questions is received: > - Discuss protection issue (existing maintainer, coordinator's >maintainer, auth). These are important and time consuming things to solve, all LIRs don't have so many staff to do this. >Needs human work. Yes, this is _very_ true and can't be avoided :) Just my five euro cents... Kristian Rastas, Sonera Local Internet Registry From hank at att.net.il Fri Apr 26 11:56:17 2002 From: hank at att.net.il (Hank Nussbacher) Date: Fri, 26 Apr 2002 11:56:17 +0200 Subject: Transferring InterNIC space from ARIN Database to other RIR databases In-Reply-To: Message-ID: <5.1.0.14.2.20020426113014.00ffbe60@max.att.net.il> At 03:52 PM 24-04-02 +0200, Joao Luis Silva Damas wrote: >Dear all, > >Sometime ago we started a thread about distributing address space issued >prior to the existence of the RIRs, which is currently registered at the >ARIN database (imported from the InterNIC's database), to the RIR that now >operates in the region where the address space is registered as used. > >Doing this would simplify processes such as modifying the name servers for >in-addr.arpa for those addresses, changing contact information, etc as the >user will issue requests for change to the RIR in their region, the one >with which they will normally be more familiar. > >Both ARIN and the RIPE NCC are now ready to proceed with this. As someone who has already undergone forced migration of my IP space from ARIN to RIPE I can make some comments. >There are some aspects, however, where community input is required and I >would like to ask you to comment on the proposal below. > >Note: the examples at the bottom are just examples. We do not want to >imply there is anything wrong with the objects mentioned. > >Best regards, >Joao Damas >RIPE NCC > >-------------------------------------------- >Proposed procedure for migration of legacy objects from ARIN Database > >When moving data from the ARIN database into the RIPE Database the >situation is not, unfortunately, always without conflicts. >Some data that is in the ARIN database also has an entry in the RIPE database. > >While the ARIN database is the one which contains the authoritative >information for the set of name servers used in in-addr.arpa resolution >for the addresses in question (the in-addr.arpa zone file is generated >from that data), sometimes the administrative contacts seem to be more up >to date in the RIPE database. > >Below are a set of proposals for actions when transferring the data: > > >I. inetnum objects > >1. There are several types of conflicts with the data in the RIPE >Database: I would suggest to contact those with conflicts. Often, the contact info is out of date, so try sending email to both the ARIN and RIPE contacts. >1.1 Exact matches with RIPE networks (4325) > *Proposal: to override data in the RIPE Database with ARIN's. > If the object in the RIPE database has a "changed" date more > recent than the object in the ARIN database, contact information > from the RIPE database is kept and the nameservers are the > ones in the ARIN database. >1.2 ARIN network contains a RIPE network(s) (169) > 1.2.1. ARIN's allocation, while multiple assignments are registered > in the RIPE Database > *Proposal: to keep RIPE's and ARIN's data > 1.2.2. Minor Mismatch > *Proposal: to override data in the RIPE Database with ARIN's >1.3 ARIN network is contained in a RIPE network (3060) > *Proposal: to keep ARIN's data and delete RIPE network I don't understand this. If ARIN has a /24 that is part of a /16 registered in RIPE, you propose to delete the /16?! What has happened often is the following: the ISP had a /16 from ARIN. The ISP was in Europe so they did all their updates to RIPE. They assigned /24s to customers. These customers, on their own, went and registered these /24s in ARIN without the ISP knowing. Later on (years), the customer leaves the ISP, the ISP updates the RIPE database but doesn't know about ARIN entries. The ARIN entry exists as a /24 poked into the /16. It should be deleted. The RIPE data should not be deleted! >1.4. Objects in the ARIN database only > *Proposal: to put ARIN's data in the RIPE Database > >2. Protection of the transferred inetnums > *Proposal: >To create a mntner object for each ARIN's 'coordinator'. Syntax could >be: > >mntner: -MNT >mnt-by: -MNT >auth: MAIL-FROM >... > >Then we protect inetnums 'owned' by the coordinator with this >maintainer. Should be the same level of security as currently at ARIN. >Note: it could be different if the POC is merged/replaced by existing >RIPE person object (see further discussion). > >II. POC objects >1. Try to match POCs from ARIN DB to the existing person objects in the >RIPE DB (762) >The implication is that we use the person's e-mail address as authorization >(see proposal above) > * Proposal: to contact all affected persons in advance and have a more > clear >picture before the transfer. Questions to ask: Excellent! > - Do both records represent the same person? > - Would (s)he like to merge the contact data, in what manner? >After an answer to these questions is received: > - Discuss protection issue (existing maintainer, coordinator's >maintainer, auth). > >Needs human work. > >2. Protection of the transferred POCs > * Proposal: to add mnt-by referencing a respective coordinator's >maintainer. > > >---------------- >Examples > > >I.1.2.1 >inetnum: 130.242.0.0 - 130.243.255.255 >netname: SUNETREGAB-RIPE >descr: European Regional Internet Registry/RIPE NCC >descr: These addresses have been further assigned >descr: to European users. Contact information can >descr: be found in the RIPE database at whois.ripe.net Perhaps they can fix (spelling, typos) all the existing entries that have already moved and read like this now: European Regional Internet Registry/RIPE NCC (NET-IL-ISOC-RIPE) These addresses have been further assigned to European users. Contact informatio be found in the RIPE database, whois.ripe.net NL Or even better, the "pointer" info should be unified and not different depending on which block you ask for: European Regional Internet Registry/RIPE NCC (NETBLK-RIPE-C3) These addresses have been further assigned to European users. Contact info can be found in the RIPE database, via the WHOIS and TELNET servers at whois.ripe.net, and at http://www.ripe.net/perl/whois/ NL On a different matter, why just inetnum? What about ASNs? Same issues exist and there are hundreds of ASNs originally allocated by ARIN and now being handled in RIPE. -Hank >country: NL >admin-c: RIPE-NCC-ARIN >rev-srv: sunic.sunet.se >rev-srv: falun.dns.swip.net >rev-srv: ns.ripe.net >status: ALLOCATION >changed: hostmaster at arin.net 20000329 >source: ARIN > >... >inetnum: 130.242.43.0 - 130.242.43.255 >netname: SE-TEKNISKAMUSEET >descr: Tekniska Museet >country: SE >admin-c: HALI1-RIPE >tech-c: HALI1-RIPE >status: ASSIGNED PA >mnt-by: SUNET-MNT >changed: fredrik at sunet.se 19981022 >source: RIPE > >inetnum: 130.242.48.0 - 130.242.48.255 >netname: SE-ARMEMUSEUM >descr: Statens Forsvarshistoriska Museer >country: SE >admin-c: BOMI1-RIPE >tech-c: LEPE1-RIPE >status: ASSIGNED PA >mnt-by: SUNET-MNT >changed: fredrik at sunet.se 19981022 >source: RIPE >... > >I.1.2.2 >inetnum: 131.117.0.0 - 131.117.128.255 >netname: ZUERI >descr: Municipality of Zuerich >descr: Wilhelmstr. 10 >descr: Zurich, 8021 >descr: CH >country: CH >admin-c: BM153-ARIN >status: ASSIGNMENT >changed: hostmaster at arin.net 19980824 >source: ARIN > >inetnum: 131.117.0.0 - 131.117.127.255 >netname: ZUERI-NET >descr: Municipality of Zuerich >descr: Zuerich, Switzerland >country: CH >admin-c: BM16-RIPE >tech-c: BM16-RIPE >changed: huber at switch.ch 19950412 >source: RIPE > > >I.1.3 > >inetnum: 130.138.0.0 - 130.140.255.255 >netname: PHILIPS >descr: Philips C&P/NBS >descr: Eindhoven >country: NL >admin-c: HS6189-RIPE >tech-c: HS6189-RIPE >notify: H.Sanders at mpn.cp.philips.com >changed: geertj at ripe.net 19940106 >changed: H.Sanders at mpn.cp.philips.com 19960131 >changed: ripe-dbm at ripe.net 19990706 >changed: ripe-dbm at ripe.net 20000225 >source: RIPE > >inetnum: 130.138.0.0 - 130.138.255.255 >netname: PHILIPS-SERI-1 >descr: Philips Components BV >descr: Building BC136 >descr: Hurkesestraat 9 >descr: 5600 MD Eindhoven >descr: THE NETHERLANDS >country: NL >admin-c: OK6-ARIN >status: REASSIGNMENT >changed: hostmaster at arin.net 19930413 >source: ARIN > >II.1 > >person: Antonio_Blasco Bonito >address: Rodinet S.a.s. >address: Via Cavour 6 >address: I-54033 Carrara >address: Italy >phone: +39 0585 779435 >fax-no: +39 0585 757385 >e-mail: Antonio-Blasco.Bonito at rodinet.com >nic-hdl: ABB2 >changed: blasco at rodinet.com 19990310 >source: RIPE > > >person: A. Blasco Bonito >address: GARR-NIS >address: c/o CNR-Istituto CNUCE >address: via Santa Maria 36 >phone: +39 50 593246 >fax-no: +39 50 904052 >e-mail: bonito at NIS.GARR.IT >nic-hdl: ABB2-ARIN >changed: hostmaster at arin.net 19931201 >source: ARIN From he at uninett.no Fri Apr 26 14:03:28 2002 From: he at uninett.no (Havard Eidnes) Date: Fri, 26 Apr 2002 14:03:28 +0200 (CEST) Subject: FWD: [GLOBAL-V6] New draft available: IPv6 Address Allocation and Assignment Global Policy In-Reply-To: <20020425174759.B17766@iprg.nokia.com> References: <20020425174759.B17766@iprg.nokia.com> Message-ID: <20020426.140328.22920786.he@uninett.no> Hi, I have a concrete question and a general comment with regards to this. The concrete question is illustrated by an example: o Assume I'm a transit service provider with my own AS o Assume that I only sell "wholesale" service to a smaller number of customers o Assume that I want to provide IPv6 service o Assume that all my customers have their own IPv6 address allocations Now, where does that leave me in terms of getting IPv6 addresses assigned to number my internal network and the few internal servers we have? The way I read the draft policy, the answer would be "out in the cold". One possible way out would be to get an e.g. /48 assignment from one of the downstreams, which address-space-wise would be sufficient to number this network. However, there is no guarantee that the route for the /48 would not be filtered away "all over the place" (I would guess that it *would* be filtered away). The result would be that if the connection to the downstream which announces the enclosing /32 goes away, so does the general connectivity to the systems in my own AS. Another option could be to get an address assignment from one of my upstreams. However, again, my general connectivity would be married with that provider's connectivity (do to assumed filtering of /48 routes), so does not prove to be useful in a setup with more than one "upstream" provider; if the connectivity with that provider was broken, so would my general connectivity be, even though I have physical connectivity via my other upstream(s). My baggage is from IPv4, so I may have missed a few details (corrections appreciated), but it seems to me that the attempt of imposing a strict hierarchical address allocation covering multiple routing domains can at best be characterized as an attempt at putting a band-aid across the gaping chest-wound called "IPv6 multihoming", by in essence telling people "don't do that!" and also "you do not have routing-wise autonomy (or visibility) even though you have an AS". The draft policy says that "routability" is not guaranteed for any assignment or allocation, and the policies as to what is commonly filtered and what isn't are not yet defined (I think), but how many think /48s will be universally accepted? (I certainly don't.) Regards, - H?vard From henner at nerim.net Fri Apr 26 15:15:50 2002 From: henner at nerim.net (Xavier Henner) Date: Fri, 26 Apr 2002 15:15:50 +0200 Subject: FWD: [GLOBAL-V6] New draft available: IPv6 Address Allocation and Assignment Global Policy In-Reply-To: <20020426.140328.22920786.he@uninett.no>; from he@uninett.no on Fri, Apr 26, 2002 at 02:03:28PM +0200 References: <20020425174759.B17766@iprg.nokia.com> <20020426.140328.22920786.he@uninett.no> Message-ID: <20020426151550.A11336@euclide.org> > o Assume I'm a transit service provider with my own AS > o Assume that I only sell "wholesale" service to a smaller number of > customers > o Assume that I want to provide IPv6 service > o Assume that all my customers have their own IPv6 address allocations If all your custommers have their own IPv6 address allocation, all are ISP. You provide only transit for ISP (no hosting, no lease lines for big custommers, no global services for vISP) I don't think there is many such organizations. But I think a RIR will give a /32 to such an organization : it needs a /32 and there is no other solution. -- Xavier Henner Responsable de l'exp?rimentation IPv6 Nerim -- Fournisseur d'acc?s ? Internet URL: From dominic at ripe.net Fri Apr 26 15:50:35 2002 From: dominic at ripe.net (Dominic Spratley) Date: Fri, 26 Apr 2002 15:50:35 +0200 Subject: An increase in Merger tickets Message-ID: <5.1.0.14.2.20020426154005.02622ae8@mailhost.ripe.net> Dear Colleagues, In our previous email we felt it was important to notify you that specific issues had arisen that had resulted in an increase in the current response time length and that we were working to address these. We would like to take this opportunity to explain in greater detail one of these issues. When we compare the first quarter of this year with the same quarter last year we see that the number of hostmaster tickets/requests relating to Mergers and Closures has risen from nearly 5 tickets per month to over 27 tickets per month (an increase of more than 500%). Mergers, closures and takeovers of LIRs are notably complex for a variety of reasons. The process of merging, closing or taking over another LIR involves the transfer of IP addresses and AS numbers. This is necessary to ensure that Internet resources are not lost and that they get registered properly in the RIPE Database. Often, the new or remaining LIR is not aware of all the addresses involved in the process. This is specifically the case with 'old' LIRs. It can also mean that part of the address space could be returned if, through a merger or takeover, an LIR receives more address space than needed. In many cases contact persons of the LIR closing or being taken over hold all of the knowledge and are no longer reachable. This could lead to wastage of Internet resources as the addresses are very difficult to trace. All of this uses a lot of resources. We realise that those LIRs merging, closing or being taken over already have address space to add to their own and their customers' networks, whereas other LIRs that send requests to the RIPE NCC are in need of address space. We would like to give priority to the latter, but for the reasons listed above it is not always possible to have a lower response time. The process must be carried out separately for every LIR involved and having to communicate with each LIR's contacts can often add to the delay. A new draft procedure document titled "Mergers, Acquisitions, Takeovers and Closures of LIRs" has been drafted and can be found at: http://www.ripe.net/ripencc/mem-services/registration/policies/draft-documents/ We hope that this will provide better guidance for the LIRs who are involved in this process. Regards, Dominic Spratley, RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: From pfs at cisco.com Fri Apr 26 17:02:37 2002 From: pfs at cisco.com (Philip Smith) Date: Sat, 27 Apr 2002 01:02:37 +1000 Subject: Transferring InterNIC space from ARIN Database to other RIR databases In-Reply-To: References: <20020425.005207.82052548.he@uninett.no> <20020425.005207.82052548.he@uninett.no> Message-ID: <5.1.0.14.2.20020427005439.05b249a0@lint.cisco.com> At 11:08 25/04/2002 +0200, Joao Luis Silva Damas wrote: >> o After the move of the authority for the data, what information will >> the ARIN database return when queried via whois? A pointer to the >> RIPE NCC (as happens now for the larger RIPE address blocks), or a >> "slave" copy of of the data from the RIPE database? > >A pointer seems to be the more favoured approach right now. A pointer would be the right thing to do, IMO. There are already several address blocks from 192/8 which are registered in the RIPE database but are listed as unassigned in ARIN's database. This creates the appearance of a conflict and will probably confuse some people. philip -- From woeber at cc.univie.ac.at Fri Apr 26 18:32:27 2002 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Fri, 26 Apr 2002 18:32:27 +0200 Subject: Transferring InterNIC space from ARIN Database to other RIR databases Message-ID: <00A0D0D9.2E38D60E.8@cc.univie.ac.at> >At 11:08 25/04/2002 +0200, Joao Luis Silva Damas wrote: >>> o After the move of the authority for the data, what information will >>> the ARIN database return when queried via whois? A pointer to the >>> RIPE NCC (as happens now for the larger RIPE address blocks), or a >>> "slave" copy of of the data from the RIPE database? >> >>A pointer seems to be the more favoured approach right now. > >A pointer would be the right thing to do, IMO. There are already several >address blocks from 192/8 which are registered in the RIPE database but are >listed as unassigned in ARIN's database. This creates the appearance of a >conflict and will probably confuse some people. > >philip >-- After (during?) the various migrations, we should aim for a system where every RIR whois server returns "the same" info about allocated and assigned addresses. The _authoritative_ whois should give the full story, all the other 3(*) should return a pointer reference. Pending an analysis of what the potential load could be, I'd even suggets to implement a referral mechanism similar to the support for domain referrals in the RIPE DB Software. I'd like to get feedback form the LIR community about the usefulness of that approach. We could then, if supported, take it to the DB-WG for review. *) this includes the LACNIC whois. Wilfried. From gert at space.net Fri Apr 26 18:38:46 2002 From: gert at space.net (Gert Doering) Date: Fri, 26 Apr 2002 18:38:46 +0200 Subject: Transferring InterNIC space from ARIN Database to other RIR databases In-Reply-To: <00A0D0D9.2E38D60E.8@cc.univie.ac.at>; from woeber@cc.univie.ac.at on Fri, Apr 26, 2002 at 06:32:27PM +0200 References: <00A0D0D9.2E38D60E.8@cc.univie.ac.at> Message-ID: <20020426183846.H69684@Space.Net> Hi, On Fri, Apr 26, 2002 at 06:32:27PM +0200, Wilfried Woeber, UniVie/ACOnet wrote: > I'd like to get feedback form the LIR community about the usefulness of > that approach. We could then, if supported, take it to the DB-WG for > review. Definitely yes for "manual referrals" ('look into whois.ripe.net'). I do also think that "automatic referral" (RIR DB A looks it up in RIR DB B itself and returns the data plus a comment) would be useful. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 47584 (44543) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From hph at online.no Sat Apr 27 11:51:12 2002 From: hph at online.no (Hans Petter Holen) Date: Sat, 27 Apr 2002 11:51:12 +0200 Subject: IPv6 assignments to DNS root servers in the RIPE region References: <20020424130250.GA10743@bfib.colo.bit.nl> Message-ID: <00a701c1edd1$1125eb10$7a00a8c0@no.tiscali.com> | I am not sure I understand this paragraph. Are you suggesting that | the address blocks where the different root servers reside should be | aggregatable into one superblock? I hope not. Aggregation may not make sense, but the ease of not filtering theese routes would. -hph From joao at ripe.net Mon Apr 29 14:14:13 2002 From: joao at ripe.net (Joao Luis Silva Damas) Date: Mon, 29 Apr 2002 14:14:13 +0200 Subject: IPv6 assignments to DNS root servers in the RIPE region In-Reply-To: <00a701c1edd1$1125eb10$7a00a8c0@no.tiscali.com> References: <20020424130250.GA10743@bfib.colo.bit.nl> <00a701c1edd1$1125eb10$7a00a8c0@no.tiscali.com> Message-ID: A quick message to clarify my initial mail as some people where getting the wrong impression. The proposal is for a policy for *IPv6* only. Also, it is not a "special infrastructure policy", it is *ONLY* for Internet DNS root servers. Regards, Joao Damas RIPE NCC From randy at psg.com Mon Apr 29 14:35:59 2002 From: randy at psg.com (Randy Bush) Date: Mon, 29 Apr 2002 14:35:59 +0200 Subject: IPv6 assignments to DNS root servers in the RIPE region References: <20020424130250.GA10743@bfib.colo.bit.nl> <00a701c1edd1$1125eb10$7a00a8c0@no.tiscali.com> Message-ID: > The proposal is for a policy for *IPv6* only. Also, it is not a > "special infrastructure policy", it is *ONLY* for Internet DNS root > servers. and we will all sign in blood that o there will be no other magic v6 assignments and o there will be no magic v4 assignments? maybe i can live with that randy From joao at ripe.net Mon Apr 29 15:47:43 2002 From: joao at ripe.net (Joao Luis Silva Damas) Date: Mon, 29 Apr 2002 15:47:43 +0200 Subject: IPv6 assignments to DNS root servers in the RIPE region In-Reply-To: References: <20020424130250.GA10743@bfib.colo.bit.nl> <00a701c1edd1$1125eb10$7a00a8c0@no.tiscali.com> Message-ID: At 14:35 +0200 29/4/02, Randy Bush wrote: > > The proposal is for a policy for *IPv6* only. Also, it is not a >> "special infrastructure policy", it is *ONLY* for Internet DNS root >> servers. > >and we will all sign in blood that > o there will be no other magic v6 assignments and > o there will be no magic v4 assignments? > >maybe i can live with that Me too Joao >randy