April 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

agenda for IPv6 working group RIPE39
by David Kessens 29 Apr '01

29 Apr '01

Hi, Below follows the final version of the agenda for the ipv6 wg. The second part of our session will be used for ipv6 policy discusions. This part will be a joint session with the local-ir working group. Thanks, David K. --- Agenda for the IPv6 Working Group Meeting RIPE39, Bologna Tuesday, May 1, 2001, 14:00-17:30 1st part 14:00-15:30 A. Administrative stuff - appointment of scribe - agenda bashing (David Kessens) B. Status of the 6bone (David Kessens) C. Securing the Mobile-IPv6 Binding Update (Tony Hain) D. 3G and IPv6 (Niall Murphy) E. IPv6 deployments at Jippii (Jan-Ahrent Czmok) F. Developments/initiatives regarding IPv6 in the RIPE region and beyond (input from the audience) 2nd part 16:00-17:30 joint session with lir-wg G. Draft on allocation sizes http://www.enigma.ie/articles/global-ipv6-alteration.html (Niall Murphy) other info: http://www.djp.net/ipv6/proposal.html http://www.ripe.net/ripe/mail-archives/ipv6-wg/20010101-20010401/msg00017.h… (Dave Pratt) H. Status of IETF/RIR allocation boundary discussions (Randy Bush/Mirjam Kuehne) Z. AOB ---

1 0

The status of the migration iissues
by Andrei Robachevsky 26 Apr '01

26 Apr '01

Dear Colleagues, As some of you might have noticed, several problems showed up after the migration. Let me present an update on their status: 1. PGP signed messages sent to <auto-rpsl(a)ripe.net> didn't pass authorization checks This was fixed on 24th of April. Please note that PGP signed updates cannot be processed by <auto-dbm(a)ripe.net>. Until 14th of May, <auto-dbm(a)ripe.net> processes updates in RIPE-181 format and automatically translates them into RPSL, which voids PGP signatures. 2. Conversion problems of updates sent to <auto-dbm(a)ripe.net> Problematic objects were: - Objects with syntax errors - Indented objects (containing leading whitespace) In both cases objects were not converted to RPSL and user received an empty acknowledgement. This was fixed today, 26th of April. Please note that <auto-dbm(a)ripe.net> cannot reproduce all the behaviour of the v2 database. In particular, empty attribute is treated as a syntax error and Routing Policy System Security authorization rules apply. We strongly recommend you to switch to updates in RPSL format as soon as possible. Also note, that <auto-dbm(a)ripe.net> will process updates in RIPE-181 format until 14th of May. After that, updates in RIPE-181 format should be sent to the new address, <auto-181(a)ripe.net>, and <auto-dbm(a)ripe.net> will accept only RPSL syntax. 3. Due to above problems some of the updates were not processed. If you haven't received an acknowledgement from the database one day after you sent your update we would kindly ask to re-send it. We apologize for any inconvenience these problems caused. We are working on some minor problems and rely on your understanding. Please visit the "Migration Issues" link on the "Database Status" page (http://www.ripe.net/ripencc/pub-services/db/issues.html) for the up-to-date information. Regards, Andrei Robachevsky DB Group Manager RIPE NCC

3 2

Hostmaster Centre at RIPE 39
by RIPE NCC Staff 25 Apr '01

25 Apr '01

Dear all, Ripe NCC Registrations Services are pleased to announce that during the RIPE 39 Meeting in Bologna, we will open a Ripe NCC Hostmaster Centre. Ripe NCC Hostmasters will be available for any IP and ASN request questions, and also any general policy questions. 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 30. 12:30 - 14:00 Tuesday May 1. 9:00 - 17:30 Wednesday May 2. 12:30 - 14:00 & 16:00 - 17:00 Thursday May 3. 9:00 - 14:00. Friday May 4. CLOSED. (IP request Tutorial, 14.00-17.30) We look forward to meeting you. Regards, Ripe NCC Hostmasters

1 0

portable address space
by RIPE NCC Staff 25 Apr '01

25 Apr '01

Dear all, At the upcoming RIPE meeting next week, the RIPE NCC will put forward a proposal attempting to clarify current policy on independent/portable address space. We are seeking the communities input on this matter. The RIPE NCC is currently experiencing an increased demand for portable address space, clearly visible through the amount of new members signing up from a need for portable address space but also through the amount of PI (Provider Independent) address requests received at the RIPE NCC. At this time there is no clear and consistent policy on any of these types of portable address space. - PI address space is discouraged and requestors are informed of disadvantages with PI space and what possible implications there may be. However, there are no criteria for obtaining PI address space. - PA allocations can be obtained by anyone who is a member of the RIPE NCC. (The RIPE NCC membership is open.) The LIR is only required to justify the first assignment out of that address block. As all members are required to request and justify each assignment made to customers or own infrastructure, we feel that current poorly defined PA Allocation criteria create an inconsistency in policy. In practice it means that anyone justifying the need of one IP address can receive a PA allocation (currently a /20 = 4096 addresses). This has resulted in an enormous growth of new members over the last three years. Whilst ARIN has a clearly defined policy on portable address space, APNIC has experienced the same dilemma as the RIPE NCC with their similar policies on portable address space. This was brought up and discussed at the APNIC meeting in Kuala Lumpur, March 2001. (see URL below.) As demonstrated in several recent studies of the changes in the Internet over the last years, it is clear that there is an increase of multi-homing taking place globally, an increase of smaller routes being announced in the Internet and an increased need for portable address space. The RIPE NCC wishes to develop a clear and consistent policy for portable address space in a realistic and pragmatic manner that also accommodates this increased need for portable address space. We will at the upcoming lir-wg meeting present statistics showing this trend and suggest possible steps forward. We wish to request the communities input in this discussion and we look forward to a fruitful discussion. Kind regards Nurani Nimpuno Registration Services Manager RIPE NCC http://www.ripe.net REFERENCES: -------------------- Policy documentation: "European Internet Registry Policies and Procedures", section 3.4.2.PA vs PI Space http://www.ripe.net/ripe/docs/ripe-185.html#toc34 "Provider Independent versus Provider Aggregatable Address Space" http://www.ripe.net/ripe/docs/ripe-127.html APNIC policy documentation: http://www.apnic.net/docs/add-manage-policy.html ARIN policy documentation: http://www.arin.net/regserv.html Presentations and papers: "Architectural Requirements for Inter-Domain Routing in the Internet" - Geoff Huston http://www.ietf.org/internet-drafts/draft-iab-bgparch-00.txt "The State of BGP routing" http://www.telstra.net/gih/papers/ietf/ietf50-plenary.pdf "Consistent and realistic policy framework for 'Portable' allocation and assignment" - Paul Wilson http://www.apnic.net/meetings/presentations/pa-pi-criteria.ppt Global policy document: "RIR comparative Policy Overview" http://www.ripe.net/ripencc/mem-services/registration/rir-comp-matrix-rev.h…

1 0

Proposed Agenda for Tools WG at RIPE 39
by Maldwyn Morris 25 Apr '01

25 Apr '01

Proposed Agenda for Tools WG at RIPE 39 --------------------------------------- 1. Administratrivia a. Scribe b. List of participants 2. Agenda bashing 3. Election of WG Chair Maldwyn Morris is leaving the RIPE NCC and will be stepping down as Chair of the WG, so we need to chose a new Chair. Manuel Valente, the new RIPE NCC Software Manager, will stand for the position. 4. IPMT - Manuel Valente a. Specifications We have already produced basic requirements for the IP Management Tool ( IPMT ) and would now like your assistance to flesh out the specifications - a real _working_ group ! Anyone who has used a similar tool or might use IPMT is encouraged to come along and help. b. Developers Group We would like to organise a group of people willing to help implement IPMT. 5. Tools and Techniques - Manuel Valente We would like to discuss proposed and existing tools or techniques of use to LIRs. If you have tools or ideas of your own, please bring them along. Cheers, Maldwyn Morris Software Manager RIPE NCC

1 0

IPv6 addresses for Exchange Points
by Mirjam Kuehne 24 Apr '01

24 Apr '01

[Appologies for multiple postings. I suggest to keep the discussion on <lir-wg(a)ripe.net> as it is related to address allocation policies]. Dear colleagues, The RIPE NCC received a number of requests from Internet Exchange Points (IXPs) for IPv6 address space. While evaluating these requests, we realised that it is still not entirely clear what the role of an IXP is in the IPv6 world. We also noticed that the allocation criteria currently described in the 'Provisional IPv6 Assignment and Allocation Policy Document' (http://www.ripe.net/ripe/docs/ripe-196.html) do not necessarily apply to IXPs. Please find some more details regarding this issue below. We would like to discuss this with you at the upcoming RIPE Meeting in Bologna. For more information abut the schedule, please refer to the agenda of the EIX-WG and the LIR-WG: http://www.ripe.net/ripe/meetings/current/ripe-39/ Kind Regards, Mirjam Kuehne RIPE NCC ------------ PROBLEM STATEMENT: - IXPs need independent address space for their infrastructure to allow their members/customers to connect via native IPv6 - IXPs do not necessarily fulfill the current criteria: - they do not have 40 customers (in most cases IXPs do not assign address space to their members) - if IXPs are on the 6bone, they might not have a whole pTLA, but only connect to the 6bone via another ISP - they do not need a whole subTLA (a /64 or /48, depending on the case, might be enough) POSSIBLE SOLUTIONS: 1. view IXPs as a site and assign them a /48 (or /64) directly (equivalent to IPv4 PI space) 2. require IXPs to fulfill the criteria and allocate a subTLA: - either by requiring them to get 6bone experience first - or by applying the general allocation criteria and require to connect to 3 other subTLA holders OPEN ISSUES: - what about IXPs with multiple PoPs - technical criteria for exchange points

1 0