May 2001 - lir-wg - mailman.ripe.net

Summary: Fixed Boundary (/29) Assignments
by Mirjam Kuehne 19 Sep '01

19 Sep '01

Dear LIR-WG, Here is an attempt to summarise the recent discussions on this mailing list regarding possible fixed size assignments. Following a review of the comments, it looks like the majority does not believe that a special assignment policy is needed. Most contributors agreed that there is no need to make a distinction in policy relating to different access methods. All assignments should be made on actual needs and according to the current IP address policies. The comments showed concerns about the administrative procedures required for these kinds of assignments. However, it was felt that these addresses need to be accounted for in some way. A possible way forward would be to initiate discussion surrounding the set of information necessary to justify these assignments while providing an efficient way for the LIRs to provide services to their customers. I realise that I did not touch on every aspect of the discussion but I hope that this is a fair summary in order for you to move forward Looking forward to a continuation of this debate. Best Regards, Mirjam Kuehne RIPE NCC

3 2

Call for agenda items & draft agenda
by Hans Petter Holen 11 Jul '01

11 Jul '01

Dear WG, I would like to bring to your attention the upcoming working group meeting in Bologna, likely to be on Wed May 2nd. Please suggest agenda items that needs to be discussed to the mailinglist. Draft Agenda 1.Admin - scribe, participant list, charter, mailing-lists 2.Agenda 3.RIPE 38 minutes & actions 4.Report from the RIPE NCC Hostmasters by Nurani Nimpuno 5. 17th of May Task force - goal reached or what to do next ? 6. Report from The ASO: AC happenings and GA 7.Closure of the ICANN ad Hoc Group on numbering 8.Election of WG Chair and co-chair Actions from last meeting: 35.4 NCC PGP Key exchange procedure 35.5 NCC Implement PGP for hm 36.5 Chair Assignment window applied on infrastructure 36.6 AP Collect arbitrators 36.7 NCC Keep lir-wg updated on pre RIR address space changes 37.1 WG Further discuss restoring the transparency 37.2 NCC Incorporate IESG/IAB proposal into IPv6 policy 37.3 M17 Work with the RIPE NCC to implement suggestions

1 4

Re: Modifying references to contact info in the RIPE DB
by Wilfried Woeber, UniVie/ACOnet 24 Jun '01

24 Jun '01

Hi Joao! >If the reference is by name then when I query the DB I will get the list of >persons with that name, right? Right. >Whether the object belongs to the person or not is not going to save this >person from being contacted. From the point of view of the database and the >user querying it, the object belongs to that person. Right >The link is via a name. > >Now we substitute the reference by name with a reference by nic handle >pointing to the same person. >What is the difference? > >ALMOST NONE except that: True, for the case where there is a strict one-to-one mapping, e.g the recursion using the name returns *one* object. What do you suggets to do with the case where the recursion, based on the names, returns a *set* of objects? I can see 2 approaches (at least): - do not perform the handle substitution for that referring object and put it on the list of those requiring human intervention - expand the xxxx-c: list (which? the tech-c:?) to refer to *all* objects, but by ref'ing their handles While human beings are quite clever in selecting the "proper" instance of a person: object (by looking at country, address, email,...) a script might be quite clueless with that respect :-) Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Vienna University : Fax: +43 1 4277 - 9 140 Universitaetsstrasse 7 : RIPE-DB (&NIC) Handle: WW144 A-1010 Vienna, Austria, Europe : PGP public key ID 0xF0ACB369 --------------------------------------------------------------------------

3 3

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

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