- lir-wg - mailman.ripe.net

IP Management Tool - Minimum Requirements
by Maldwyn Morris 06 Jun '01

06 Jun '01

Hello everyone, Guy wrote: > > I am officially asking Mal to please repost the > current requirements back up on this list. [...] Happy to oblige. Cheers, Maldwyn Morris Software Manager RIPE NCC -- Hi, Following a presentation of an IP Management Tool by Guy Vegoda at the last RIPE Meeting Tools BOF, interest was expressed in the development of an Open Source version of such a tool and I agreed to use the lirwg list to try and draw up Requirements for this. Hopefully this can be refined into something that we can then begin writing Specifications for. Please remember that these are *Requirements* - i.e. what the users want the tool to do. Please confine remarks to this area and avoid mixing in the *Specifications* - i.e. how those requirements will be met - which we will come to, in good time. It should also be emphasised that we would at this stage like to concentrate on _minimum_ requirements for a simple tool, such that it would be useful to a large number of LIRs. I think we can use these Minimum Requirements to produce something that may or may not include more advanced features as well, knowing that we would at least have covered the basic needs. Comments on this process and the document are most welcome, and we would also like a good name. Thanks to Guy Vegoda, Leo Vegoda and Nigel Titley for their help in drawing up this document, and especially to Guy for presenting his tool. Cheers, Maldwyn Morris Software Manager RIPE NCC -- Minimum Requirements for an IP Management Tool ---------------------------------------------- 0. Introduction Guy Vegoda presented an IP Management Tool at the Tools BOF at RIPE 38 [1]. This document is an attempt to specify the minimum requirements for a similar tool, with the aim of producing an Open Source version for anyone who wants to use it. Below, I address 1. General Points about the project, 2. The Requirements themselves, 3. External Constraint that must be considered, and 4. A list of References. 1. General Points Name: Let's use IPMT ( IP Management Tool ) as a placeholder for now. Users: We will target as users 'The Hostmaster staff of Local Internet Registries which are Customers of the RIPE NCC and who need to manage their IP Allocations and Assignments and the requests for same that they send to the RIPE NCC' [phew]. We will call one of these people a 'LIRHostmaster' and their organisation an 'LIR'. It may also be useful to other people in other organisations to do other things, but that will not influence the requirements. Open Source: We will release this software under the LGPL licence [2]. We use this instead of GPL [3] because this means we will remain able to using non-GPL'ed libraries, should that prove necessary. The RIPE NCC is happy to support this project, but of course its Open Source nature means anyone else can use the code to begin their own Open Source project. We are also happy about that. IPV6: We would be foolish not to consider the possibility of using this tool for managing IPV6 addresses and writing it such that this is possible, but we think it will be useful even if it does not and do not consider IPV6 support a requirement. 2. Requirements General functionality: IPMT should provide the LIRHostmasters with list, create, update, and delete access to information regarding their LIR's IPV4 allocations. These actions must be undoable where necessary. Basic validity checks will be performed on all input. IPMT should provide the LIRHostmasters with list, create, update, and delete access to information regarding their LIR's IPV4 assignments. These actions must be undoable where necessary. Basic validity checks will be performed on all input. IPMT should allow the LIRHostmasters to receive requests for IPV4 assignments from the customers of their LIR and allow them to process them. IPMT should allow LIRHostmasters to send well-formatted email requests for new IPv4 assignments to the RIPE NCC and allow the LIRHostmasters to receive and process responses from the RIPE NCC. IPMT should allow LIRHostmasters to send well-formatted email requests for new IPv4 allocations to the RIPE NCC and allow the LIRHostmasters to receive and process responses from the RIPE NCC. User Interface: LIRHostmasters should be able to conveniently access IPMT functions from a wide range of Desktop Operating Systems, possibly including non-modern, non-Unix-like ones. A GUI interface is the minimal acceptable convenience level. A less-convenient interface to IPMT for more complex functions and administration is acceptable. 3. External constraints The RIPE NCC only accepts requests for new IPv4 Assignments and Allocations via email to hostmaster(a)ripe.net and replies only via email [4]. IPV4 Assignment requests must be in RIPE 141 format [5]. Requests for new IPV4 Allocations have no special format. LIRHostmasters handle customer requests for Assignments via telephone, email and web pages. IPMT must have access to the RIPE DB [6] or a local mirror thereof. 4. References [1] http://www/ripe/meetings/archive/ripe-38/index.html [2] http://www.gnu.org/copyleft/lesser.html [3] http://www.gnu.org/copyleft/gpl.html [4] http://www.ripe.net/ripencc/mem-services/registration/status.html [5] http://www.ripe.net/ripe/docs/ripe-141.html [6] http://www.ripe.net/ripencc/pub-services/db/

3 2

Summary: PA Allocation criteria discussion
by RIPE NCC Staff 01 Jun '01

01 Jun '01

Dear all, Thank you for you input thus far in the discussion on portable address space. Many useful points have been raised on the matter of PI address space and PA Allocations. (The complete discussion can be read at: http://www.ripe.net/ripe/mail-archives/lir-wg/current/msg00130.html) Below is an attempt to summarise the discussion so far: The concept of smaller allocations (than current /20) was initially brought but the majority felt that this was not a realistic option. The comments showed concern about the exponential growth in the routing table and it was believed that smaller allocations would further contribute to this growth. There was consequently further discussion on how the RIR policies can prevent/reduce this through sensible address allocation/assignment criteria. On the subject of PI assignments, related to the current growth in the routing table, it was agreed that PI assignments should (as current policy states) be based on need and not routability. It was further stated that end users should be discouraged from multi-homing with globally visible address space. Some participants of the discussion argued for a complete discontinuation of PI. Most contributors agreed that /20 PA Allocations should be given to organisations who wish to further assign addresses to customers / end-users from their PA block. PA Allocations should not be made to organisations to satisfy pure multi-homing / independence needs. A set of criteria should therefore be determined to clarify this. Lastly, the majority agreed that the PA Allocation criteria should be based on previous efficient utilisation. There was further discussion with regards to the size of the efficiently utilised address space the requestor needs to demonstrate. The prefix sizes /22 and /21 were briefly discussed. If the community believes that this is a just summary of the discussion, I wish to move forward and determine the details of such criteria, through presenting a few very concrete discussion points. I would like your opinion on the following: 1. Do you agree on the following criteria to be set: The requesting organisation need to show - Demonstrated efficient utilisation of a /xx or - Immediate need for a /xx ? 2. If qualifying through the criterion of demonstrated efficient utilisation of address space, should the requestor need to demonstrate efficient utilisation of A. /22 or B. /21 ? 3. If qualifying through the criterion of demonstrated immediate need, should the requestor need to demonstrate an immediate need of a A. /22 or B. /21? 4. Should the requesting organisation be required to renumber depending on the sizes of its current aggregates? 4A. If so, what is a reasonable size of the smallest aggregate that an organisation would be required to renumber? I am looking forward to your input on these concrete points. Kind regards, Nurani Nimpuno RIPE NCC

2 1

RIPE-181 to RPSL Migration; Phase 2.
by db-news＠ripe.net 31 May '01

31 May '01

Dear Colleagues, (Apologies for multiple messages). On and from Monday, 14th May, 2001, <auto-dbm(a)ripe.net> shall only accept updates in RPSL format; updates in RIPE-181 format will no longer be accepted. Updates in RIPE-181 format can be sent to <auto-181(a)ripe.net>, where they will be automatically converted to RPSL format. <auto-rpsl(a)ripe.net> will continue to accept updates in RPSL format. The update path for the TEST database will also be changed. In summary, from 14th May, 2001: =============================== RIPE Database: ------------- <auto-dbm(a)ripe.net> - updates in RPSL format only <auto-rpsl(a)ripe.net> - updates in RPSL format only <auto-181(a)ripe.net> - updates in RIPE-181 format, automatically converted to RPS L format TEST Database: ------------- <test-dbm(a)ripe.net> - updates in RPSL format only <test-rpsl(a)ripe.net> - updates in RPSL format only <test-181(a)ripe.net> - updates in RIPE-181 format, automatically converted to RPS L format On Monday, 14th May, 2001, we cannot guarantee that an update message sent to <auto-dbm(a)ripe.net> will use a specific update path (RPSL or RIPE-181). Thus, we advise that updates in RIPE-181 format should be sent to <auto-181(a)ripe.net> and that updates in RPSL format should be sent to <auto-rpsl(a)ripe.net>. Please note that from Monday, 15th October, 2001, updates in RIPE-181 format will no longer be accepted by the RIPE Database. Further information is available from http://www.ripe.net/rpsl/. If you have any questions, please contact <ripe-dbm(a)ripe.net>. Regards, A. M. R. Magee -------------- Database Group RIPE NCC

4 5

fwd: New in-addr.arpa release
by RIPE NCC Staff 31 May '01

31 May '01

[Apologies for duplicate messages] Dear all, Please note the message below, posted by Ginny Listman, Director of Engineering at ARIN. A message has previously been forwarded to these mailing lists with further information. (Please refer to: http://www.ripe.net/ripe/mail-archives/routing-wg/current/msg00040.html) For direct questions regarding these changes, please contact <inaddr(a)arin.net>. Kind regards, Nurani Nimpuno +------------------------------------+ | Nurani Nimpuno | | Registration Services Manager | | RIPE Network Co-ordination Centre | | http://www.ripe.net | +------------------------------------+ ------- Forwarded Message Date: Fri, 25 May 2001 12:25:12 -0400 (EDT) From: ARIN IN-ADDR Role <inaddr(a)arin.net> Sender: owner-arin-announce(a)arin.net To: arin-announce(a)arin.net Subject: New in-addr.arpa release On May 17, ARIN announced that it would be making changes to the way it produces the in-addr.arpa zone file. Comments on these changes have been minimual. Most were questions addressing specific networks, or were statements of approval. Therefore, ARIN will proceed with implementation on June 1. If you are concerned about possible impact on your networks, please review examples of the changes to occur at: http://www.arin.net/inaddr/ If you still have concerns after reviewing these examples, please direct specific questions about your networks to inaddr(a)arin.net. Regards, Ginny Listman Director of Engineering ARIN ------- End of Forwarded Message

1 0

Fw: NAIS Interim Report
by Hans Petter Holen 30 May '01

30 May '01

----- Original Message ----- From: "Rob Courtney" <rob(a)cdt.org> To: <secretariat(a)dnso.org>; <pso-secretary(a)etsi.fr>; <secretariat(a)aso.icann.org> Cc: <hph(a)online.no> Sent: Wednesday, May 30, 2001 4:31 AM Subject: NAIS Interim Report | Dear S.O. Secretariats: | | The NGO and Academic ICANN Study has recently released the Executive | Summary of its Interim Report. Could you please help distribute this | notice to your Supporting Organizations? | | Thank you, | | Rob Courtney | NGO and Academic ICANN Study | | * * * | | Greetings, | | 1. In preparation for the upcoming ICANN meeting in Stockholm, the | NGO and Academic ICANN Study is releasing its Interim Report on last | year's At Large election and on the future of the public role in | ICANN. | | The Executive Summary of that report is available online at | http://www.naisproject.org/ or, for those without Web access, by | e-mail to info(a)naisproject.org. The full Interim Report will be | available online shortly. Translations of the Executive Summary in | Spanish, French and Chinese will be available later this week. | | The Interim Report is preliminary in nature. NAIS will publish its | Final Report, with recommendations, in September. We welcome | comments, and look forward to continued discussion on this topic. | | 2. NAIS also invites members of the ICANN community to a lunchtime | briefing on the report this Saturday, June 2, at the Stockholm | meeting. NAIS members will provide an overview of the Interim Report | and host an open discussion of its contents. Please feel free to | bring a bag lunch and join the conversation. | | DATE: Saturday, June 2nd, 12:00-13:15 | TIME: 12:00 - 13:15 | PLACE: First Hotel Royal Star, Skytten room (near the Stockholm | International Fairs building, site of the meetings) | | We look forward to your comments and suggestions! | | The NAIS Project | | * * * | | The NGO and Academic ICANN Study (NAIS) is a collaboration of experts | from around the world, formed to explore public participation in | ICANN and the selection of At-Large Directors on ICANN's governing | board. NAIS mirrors ICANN's own study effort, and was created to | provide an independent examination, global in scope and grounded in a | belief in the importance of public representation. | | For more information, please visit http://www.naisproject.org/ or | contact info(a)naisproject.org. | | -- | | Rob Courtney | Policy Analyst | Center for Democracy & Technology | 1634 Eye Street NW, Suite 1100 | Washington, DC 20006 | 202 637 9800 | fax 202 637 0968 | rob(a)cdt.org | pgp id: 0xAD7123FB | http://www.cdt.org/ | |

1 0

Changes to ARIN inaddr.arpa zone generation process
by RIPE NCC Staff 28 May '01

28 May '01

[Apologies for duplicate messages] CHANGES TO ARIN IN-ADDR.ARPA ZONE GENERATION PROCESS Please not the information in the message below from Ginny Listman, Director of Engineering at ARIN, the American Registry for Internet Numbers. The message relates to changes in the generation of the in-addr.arpa zone files by ARIN. This information is specifically pertinent to organisations with networks currently reverse-delegated by ARIN. Please note that this does not directly affect organisations with networks reverse-delegated by the RIPE NCC. Kind regards, RIPE NCC +------------------------------------------------+ | RIPE NCC (Network Co-ordination Centre) | | <ncc(a)ripe.net> | | | | http://www.ripe.net | | Singel 258, 1016 AB Amsterdam, The Netherlands | | Tel: +31-20-5354444 | | Fax: +31-20-5354445 | +------------------------------------------------+ -----Begin Forwarded Message ----- From: On Behalf Of ARIN IN-ADDR Role <inaddr(a)arin.net> Sent: Thursday, May 17, 2001 4:18 PM To: arin-announce(a)arin.net Cc: nanog(a)nanog.org Subject: in-addr.arpa zone generation process to change When ARIN began operations, one of the tasks that it took over from the InterNIC was the generation of the zone file for the in-addr.arpa domain. In order to correct long-standing issues with the data in the zone file, new software is being deployed. ARIN policy states that allocation subscribers with networks of /16 or shorter prefix are responsible for maintaining all in-addr.arpa domain records for reassignments within the block. They must also provide to ARIN the host names of the nameservers hosting any delegations. ARIN will continue to host domain records for delegations of networks with prefixes longer than /16. The in-addr.arpa zone will contain delegations for any /8 containing nameservers within ARIN's database. For address space not covered via these delegations, the in-addr.arpa domain will contain delegations for /16's with nameservers. For address space still not delegated and as mentioned above, the in-addr.arpa domain will contain delegations of /24's for networks longer than a /16 containing in-addr nameservers. In all cases, the most specific reassignment with nameservers at each octet boundary will prevail. ARIN is making every effort to ensure that any impact from these changes will not disrupt in-addr.arpa name services. If you have concerns whether in-addr.arpa name services will be impacted for your networks, please review examples of the changes to occur at: http://www.arin.net/inaddr/inaddr-examples.txt If you still have concerns after reviewing these examples, please direct specific questions about your networks to inaddr(a)arin.net. We have tentatively scheduled implementation of the new process for late May or early June. A specific date will be announced several days prior to the cut-over on both the arin-announce and nanog mailing lists. Regards, Ginny Listman Director of Engineering ARIN -----End Forwarded Message -----

1 0

Criteria for initial PA Allocation
by RIPE NCC Staff 25 May '01

25 May '01

Dear all, At the last RIPE meeting (RIPE 39) in Bologna, the issue of criteria for PA Allocations was discussed in the LIR-WG. The presentation delivered is available from: http://www.ripe.net/meetings/archive/ripe-39/presentations/ (Please also refer to the mail sent out to the lir-working group the 25 April at: http://www.ripe.net/ripe/mail-archives/lir-wg/current/msg00056.html We would like the communities input on this matter. The problem brought up was the lack of clear and consistent policy on portable address space. Currently two types of portable address space are available: - Provider Aggregatable (PA) Allocations - Provider Independent (PI) Assignments The discussion was focused on criteria for PA Allocations as this is where the most significant policy inconsistency can be found. Current criteria for initial PA Allocations are: - Membership (You are required to be a member in order to get your first allocation. The RIPE NCC membership is open, anyone can become a member.) - Justification of first assignment (You are required to justify the first assignment you make out of your allocation. There is no minimum assignment size.) The minimal PA Allocation size is currently a /20 (= 4096 IP addresses) This means in reality that anyone who can justify one IP address is eligible for 4096 addresses. With an increased demand for independence and multi-homing, the RIPE NCC can see the consequences of this in the impressive membership growth in the last years: New LIRs set up per year: 1997: 262 1998: 446 1999: 525 2000: 865 2001: 997 (projected, end of year) The RIPE NCC has experienced several cases where organisations have insisted on becoming members in order to receive a portable /20 address block despite the fact they clearly state that their need is for less, in some cases only for c:a 300 addresses. We also observe organisations who become LIRs with the pure objective of obtaining portable address space but who are unaware of the responsibilities and workload membership comprises. As all assignments made are based on need, there is clearly a policy inconsistency in the fact that allocations currently do not require any such justification. Consensus was reached in the LIR-WG at RIPE 39 that a set of criteria should be defined for obtaining an initial PA Allocation. The working group also agreed that the exact details of those criteria should be further discussed on the mailing list. Extending the logic of basing address assignments on need and previous utilisation to allocations, I therefore put forward the following proposal: Proposed Initial PA Allocation Criteria: - Demonstrated efficient utilisation of a /xx (/22?) Or - Immediate need for a /xx (/22?) - Agree to renumber (Required? Recommended?) As the need for portable address space is a complex matter, I would like to propose to first focus this discussion on defining these criteria. The matter clearly also touches on the matter of PI Assignments, which is something I would like to encourage further discussion on. However, I would like start by requesting the communities input on the matter of initial PA Allocation criteria. Kind regards, Nurani Nimpuno +------------------------------------+ | Nurani Nimpuno | | Registration Services Manager | | RIPE Network Co-ordination Centre | | http://www.ripe.net | +------------------------------------+ Relevant studies: ----------------- Philip Smith "Studies of the routing table": http://www.apnic.net/stats/bgp/ Geoff Huston "Measuring BGP": http://www.apnic.net/meetings/presentations/apricot01.ppt http://www.ietf.org/internet-drafts/draft-iab-bgparch-00.txt Scott Marcus "ASN Growth": http://www.ripe.net/ripe/meetings/archive/ripe-38/index.html RIS report / BGP prefix distribution: http://www.ripe.net/ripencc/pub-services/np/ris-index.html

15 26

RE: Criteria for initial PA Allocation
by BLOCKI,JACEK (HP-Poland,ex1) 24 May '01

24 May '01

(1) Do you agree or disagree that allocating /20s to every requestor who can justify an initial assignment is irresponsible? Allocating /20 is reasonable due to routing limitations There are two end of knot called Internet: End Users and Service Providers (e.g. Portals). I do insist on recognizing needs of LIRs servicing Service Providers only. Such an organization has to do multi homing and by nature will use only a fraction of assigned allocation since system servicing end users needs limited number od IPs if properly configured. As it was discussed before we should keep in mind routing tables growth while handling out IP blocks. We can argue if initial allocation of /21 is better than /20, but thinking about much smaller allocations is not practical. (2) Do you agree or disagree that RIPE should consider establishing a policy by which an organization can only request a PA allocation if it can demonstrate the efficient utilization of an existing block of IP address space (as yet undefined - /22, /21, /20, etc.)? See comment above. As long as I can have routable block I am fine. (3) Do you agree or disagree that RIPE should implement a PI assignment policy establishing an assignment model consistent with the principles established for such assignments in RFC 2050 (25% utilization immediately, 50% utilization within one year)? PI should be avoided, there should be two options: 1) Connect to existing provider and use his service 2) Establish your own connectivity / routing policy So you either need a chunk of PA space or own PA block. Yes I do think a need for own connectivity has to be well justified (4) Should organizations which are using a relatively small amount of address space be required to renumber in order to recieve a PA allocation from RIPE? Once we decide to abandon PI renumbering seems practical

1 0

RE: Criteria for initial PA Allocation
by Hogeloon, Bert van 23 May '01

23 May '01

On Tuesday, May 22, 2001 23:03, Poul-Henning Kamp [SMTP:phk@critter.freebsd.dk] wrote: > In message <002101c0e301$8b591f00$0600000a@hph>, "Hans Petter Holen" writes: > >| >I think it makes sense - if you are not able to fill a /22, your network > >| >is "smallish". So using PA space and renumbering when changing ISPs is > >| >not *that* hard, if done properly (DHCP, DNS, no hard-coded IP addresses > >| >anywhere). > >| > >| I know several companies who would be willing to renumber once per year > >| as long as they can be multihomed... > > > >Why should I have to renumber once a year to be multi-homed ? > > I'm not saying you should, I'm saying people are willing to it. > > To me that indicates that we are not looking at the problem right > now, but on a symptom of the >real< problem. > > I think the solution to the real problem is to find a better method > for assignment of routable IPs to multihomed customers. Exactly. Allowing /22's to be allocated is probably not a good idea and certainly doesn't solve anything on the longer term. However imposing a certain amount of minimal usage doesn't also solve the real problem. The base rule for address assignments is that people ought to get what they technically need, no more and no less. The base rule for an allocation is that people should get one if they technically need one. They will need to explain this in their application for a LIR. The only problem of course is what are the technical criteria for this. For a start we could ask the potential LIR to specify why he is not able to use any alternative method and only grant the allocation if he is able to provide a satisfying answer or if he can justify a minimal usage of a /22 (within 2 years time?) I don't think that there is a need for justifying why the person wants to be multi-homed. Even if it's not a good reason, everybody should have the freedom choosing multiple ISP's. How are we going to apply those rules in IPv6 BTW? Justifying the usage of a quarter of the minimal allocation is going to be difficult for anyone. Regards, Bert > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk(a)FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence.

5 4

New Document available: RIPE-222
by RIPE NCC Document Announcement Service 23 May '01

23 May '01

New/Revised RIPE Document Announcement -------------------------------------- A new document is available from the RIPE document store. Ref: ripe-222 Title: Smallest RIPE NCC Allocation / Assignment Sizes Author: Joao Luis Silva Damas, Nurani Nimpuno Date: 22 May 2001 Format: PS=9509 TXT=1840 Obsoletes: ripe-211 Obsoleted by: Updates: Updated by: Short content description ------------------------- This document contains the size of the minimum and default allocations made by the RIPE NCC to users from CIDR blocks assigned to the RIPE NCC by the Internet Assigned Numbers Authority (IANA). The document is of special interest to routing engineers and network operators. Accessing the RIPE document store --------------------------------- The RIPE document store is available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-222.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-222.txt plain text version You can also access the RIPE documents in HTML format via WWW. RIPE-222 is available at the following URL: http://www.ripe.net/docs/smallest-alloc-sizes.html Excuses for duplicate mails

1 0