April 2002 - lir-wg - mailman.ripe.net

Draft minutes from lir-wg at RIPE 41
by Hans Petter Holen 10 Sep '02

10 Sep '02

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(a)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(a)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(a)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(a)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(a)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(a)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.

2 1

IPv6 assignments to DNS root servers in the RIPE region
by Joao Luis Silva Damas 29 Apr '02

29 Apr '02

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. *******************

11 29

Re: Transferring InterNIC space from ARIN Database to other RIR databases
by Wilfried Woeber, UniVie/ACOnet 26 Apr '02

26 Apr '02

>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.

2 1

Transferring InterNIC space from ARIN Database to other RIR databases
by Joao Luis Silva Damas 26 Apr '02

26 Apr '02

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: <coord hic hdl>-MNT mnt-by: <coord hic hdl>-MNT auth: MAIL-FROM <coord e-mail address> ... 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(a)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(a)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(a)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(a)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(a)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(a)mpn.cp.philips.com changed: geertj(a)ripe.net 19940106 changed: H.Sanders(a)mpn.cp.philips.com 19960131 changed: ripe-dbm(a)ripe.net 19990706 changed: ripe-dbm(a)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(a)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(a)rodinet.com nic-hdl: ABB2 changed: blasco(a)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(a)NIS.GARR.IT nic-hdl: ABB2-ARIN changed: hostmaster(a)arin.net 19931201 source: ARIN

6 6

An increase in Merger tickets
by Dominic Spratley 26 Apr '02

26 Apr '02

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-docume… We hope that this will provide better guidance for the LIRs who are involved in this process. Regards, Dominic Spratley, RIPE NCC

1 0

FWD: [GLOBAL-V6] New draft available: IPv6 Address Allocation and Assignment Global Policy
by David Kessens 26 Apr '02

26 Apr '02

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 <narten(a)us.ibm.com> ----- X-Delivered-For: <david(a)iprg.nokia.com> X-mProtect: <200204251156> Nokia Silicon Valley Messaging Protection X-Authentication-Warning: data.staff.apnic.net: majordom set sender to owner-global-v6(a)lists.apnic.net using -f To: global-v6(a)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 <narten(a)us.ibm.com> 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(a)lists.apnic.net ----- End forwarded message -----

3 2

Creation of Reverse Delegation Objects
by Tanja Heimes 25 Apr '02

25 Apr '02

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(a)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

5 6

Re: Creation of Reverse Delegation Objects
by Wilfried Woeber, UniVie/ACOnet 25 Apr '02

25 Apr '02

Hi Joao! >Date: Wed, 24 Apr 2002 19:44:23 +0200 (CEST) >From: Joao Luis Silva Damas <joao(a)ripe.net> >To: "Wilfried Woeber, UniVie/ACOnet" <woeber(a)cc.univie.ac.at> >CC: lir-wg(a)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.

1 0

Re: Creation of Reverse Delegation Objects
by James Aldridge 24 Apr '02

24 Apr '02

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

1 0

Re: Creation of Reverse Delegation Objects
by Wilfried Woeber, UniVie/ACOnet 24 Apr '02

24 Apr '02

Hi Dominic, >Date: Wed, 24 Apr 2002 17:00:28 +0200 >To: Tanja Heimes <theimes(a)de.cw.net> >From: Dominic Spratley <dominic(a)ripe.net> >Subject: Re: Creation of Reverse Delegation Objects >CC: lir-wg(a)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(a)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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

6 6

RE: IPv6 assignments to DNS root servers in the RIPE region
by Guy Davies 24 Apr '02

24 Apr '02

-----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@space.net] > Sent: Wednesday, April 24, 2002 1:56 PM > To: Randy Bush > Cc: Joao Luis Silva Damas; lir-wg(a)ripe.net; ipv6-wg(a)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(a)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.

5 4

RE: IPv6 assignments to DNS root servers in the RIPE region
by Guy Davies 24 Apr '02

24 Apr '02

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > In message > <C653AC166708D51195D600034723D865075BBB(a)cain.telindus.co.uk>, 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.

1 0

RE: IPv6 assignments to DNS root servers in the RIPE region
by matthew.ford＠bt.com 24 Apr '02

24 Apr '02

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@space.net] > Sent: 24 April 2002 13:55 > To: Randy Bush > Cc: Joao Luis Silva Damas; lir-wg(a)ripe.net; ipv6-wg(a)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(a)Space.Net > Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 > 80807 Muenchen Fax : +49-89-32356-299 >

1 0

network transfer
by Marcus.Ruchti＠colt.de 19 Apr '02

19 Apr '02

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@colt.de COLT TELECOM GmbH Fon: +49 (0) 69 / 5 66 06 - 6351 Fax: +49 (0) 69 / 5 66 06 - 6350

2 2

New Draft IPv4 Policy Documents
by Mirjam Kuehne 18 Apr '02

18 Apr '02

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(a)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-docume… 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 <lir-wg(a)ripe.net>. 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-sys… 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.

1 0

CAll for action - PLEASE READ
by Stephen Burley 15 Apr '02

15 Apr '02

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

12 13

Re: Current wait times
by Mirjam Kuehne 15 Apr '02

15 Apr '02

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… 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

3 2

RIPE 42 - IP Request Tutorial announcement
by Rumy Kanis 11 Apr '02

11 Apr '02

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(a)ripe.net | | Training Team Leader | | | | RIPE NCC tel. +31 20 535 4444 | | www.ripe.net | o-----------------------------------o

1 0

Current wait times
by RIPE NCC Hostmaster 11 Apr '02

11 Apr '02

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 <hostmaster(a)ripe.net> <lir-help(a)ripe.net> and <new-lir(a)ripe.net> 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

2 1

Draft Agenda for LIR WG at RIPE42
by James Aldridge 11 Apr '02

11 Apr '02

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.ht… 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

3 2

Re: Draft Agenda for LIR WG at RIPE42
by jhma+ripe＠mcvax.org 11 Apr '02

11 Apr '02

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

2 1

Hostmaster Centre at RIPE 42
by RIPE NCC Staff 10 Apr '02

10 Apr '02

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/

1 0

Reopen discussion: Sub-Allcations vs. LIR-PARTITIONED
by Gert Doering 10 Apr '02

10 Apr '02

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(a)Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299

1 0

Test
by RIPE NCC Mailing Lists Moderator 10 Apr '02

10 Apr '02

1 0

update lir object
by Fabio Bracali - Local Internet Registry - Casaweb 04 Apr '02

04 Apr '02

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

2 1