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

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

Proponents take IPv6 off its pedestal
by Hank Nussbacher 23 May '01

23 May '01

http://www.nwfusion.com/archive/2001/120951_05-21-2001.html -Hank

1 0

Re: Criteria for initial PA Allocation
by Wilfried Woeber, UniVie/ACOnet 23 May '01

23 May '01

Just some observations... => So, what is my conclusion? I estimate that while IPv4 address exhaustion => is going to be a problem (which IPv6 will solve), the routing topology => will cause major problems *sooner* than IPv4 runs out, and we should => do something against this. By this, I mean: => => - strongly encourage people to renumber from historic PI space to => PA space from their ISPs network block (and return the PI space => to the RIRs, to be aggregated) = :-) the finest way would be turning it "mandatory"... =i know this problem very well, as i've already done too much work =recovering some 192.x.x.x still given by ARIN... :-) This ship has left the harbour many moons ago... You can no longer honestly advocate that path to any site (without the support of _all_ ISP on the routing layer - which I expect to be nil) when the rules for obtaining address space in general, and PI in particular, have been tightened and can be expected to become even more restrictive in the future. =I still didnt finish this on my clients because some of them see it as a ="RESOURCE", and some are trying to X*Y valid addrissing by only returning =X address space... :-( they got it ;-) => - stop handing out PI space = =:-) well... could RIPE just talk to registered ISPs...? =I think this is very, very hard thing... Only a short while ago the community agreed that it is not reasonably possible to define what an ISP is. => - discourage people from becoming LIR if that's only to get "portable" => address space, with no intention of handing PA space out to customers. = =no customers = no ISP ? Be careful. You run into the same problem here, trying to define what a "customer" is. Just another aspect here, we tend to _again_ mix the concepts and responsibities of RIRs, LIRs and ISPs for the Internet (mind the capital "I" here). The ISPs collaboratively operating the Internet are responsible for the routing aspects. However, this should not prevent anyone for becoming an LIR and/or from obtaining globally unique IPv4 addresses - as long as they can document a need for them. This need does not necessarily involve connectivity to the Internet. Building an internet should be enough. => Yes, this might sound a bit harsh, but I'm *really* worried about => routeability and reachability of anything in the next couple of years. = =Yep... i see more than 104.000... Well, for the moment I consider that point moot. For quite a while the information has been made available (T.B., pfs reports) where the Internet could be improved (routing-wise) by e.g. aggregating and/or removing excessive announcements. In reality nobody really seesm to care (more than uttering their disgust :-), otherwise we would see real activity to get the broken ASes fixed (or filtered or disconnected), and an improvement. => Now go and flame me... :-) = =That's not the intention of it. = => Gert Doering => -- NetMaster => -- => SpaceNet AG Mail: netmaster(a)Space.Net => Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 => 80807 Muenchen Fax : +49-89-32356-299 => = =./Carlos = "Networking is fun!" =------------------- =<cfriacas(a)fccn.pt>, CMF8-RIPE, Wide Area Network WorkGroup http://www.fccn.pt =F.C.C.N. - Fundacao para a Computacao Cientifica Nacional fax: +351 218472167 Wilfried. _________________________________:_____________________________________ 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

2 1

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

22 May '01

Hi, On Tuesday, May 22, 2001 15:58, Gert Doering, Netmaster [SMTP:netmaster@space.net] wrote: > Hi, > > (originally I did not really want to participate in this discussion, > as much of it has already been said in the last LIR-WG meeting). > > One thing got me thinking,though: > > On Tue, May 22, 2001 at 02:16:32PM +0100, Carlos Friacas wrote: > > /22 is a much more reasonable value by my view... > > Be careful what you are asking for. > > If we assume that minimum allocation size will go down to a /22, and > further assume that one fourth of the full IPv4 address range will > subsequently be handed out *and announced* as /22's, this means we > will see ( 1/4 * 2^22 ) = 1048576 /22's announced in the global BGP > table. That's over a million BGP routing table entries. I agree this is a concern, but it's always better then having the same amount of /20's in the table. I agree that we have to guard that potential 'real' LIR's do not start off with a /22, but that is also already achieved by reserving contiguous address space for a certain amount of time. The point is, would the NCC also decrease this reservation mechanism? > > This will have a significant effect on BGP routing stability and > also on the costs of global routing - you need a Gig of RAM in all > the BGP routers (on distributed architectures, more than that). The > CPU power required to handle a flap of a major line in a timely fashion > (to keep BGP convergence times low) will be horrendous. > > Also, it can be assumed that in this case, the global topology will > become complex enough so that most of the time many of the smaller > ASes won't be reachable anyway due to problems "on the way". > > I think this is something I do NOT want to see. > > > So, what is my conclusion? I estimate that while IPv4 address exhaustion > is going to be a problem (which IPv6 will solve), the routing topology > will cause major problems *sooner* than IPv4 runs out, and we should > do something against this. By this, I mean: IPv6 solves the exhaustion problem, but does it solve the multihoming problem? You would still have a lot of small companies wanting 'routable' address space. Getting PA address space makes you dependable on the routing table of at least one provider and thus doesn't guarantee you redundancy. > > - strongly encourage people to renumber from historic PI space to > PA space from their ISPs network block (and return the PI space > to the RIRs, to be aggregated) > > - stop handing out PI space > > - discourage "end users" from using multihoming with globally visible > address space (there are other ways, like "get multiple uplinks > to different POPs of the same ISP, and have them sign a SLA that > will get you 99.9% reachability or money back"). That is not really the same. For many companies, an outage of a few days can mean that they are out of business. Having your money back is then your least concern. The fact is that disasters do happen to every ISP once in a while and a lot of company's want to protect themselves from that. I don't think you really can discourage that. > > - discourage people from becoming LIR if that's only to get "portable" > address space, with no intention of handing PA space out to customers. That's nice, but you'll have to be able to offer them a good alternative. There are a few good alternatives (like NAT), but not all of these are workable for everybody. > > Yes, this might sound a bit harsh, but I'm *really* worried about > routeability and reachability of anything in the next couple of years. I agree it can create huge problems and we have to be careful, but the fact is multihoming is a huge dilemma for a lot of small company's (small of course in the sense of size of IP address space). Regards, Bert van Hogeloon > > Now go and flame me... :-) > > Gert Doering > -- NetMaster > -- > SpaceNet AG Mail: netmaster(a)Space.Net > Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 > 80807 Muenchen Fax : +49-89-32356-299 >

3 2

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

22 May '01

Hello, Existing procedures promote allocation of /20 block to those who need multi homed networks. An example new LIR registration form included in Ripe212 reads: 4. What are the main reasons for becoming an LIR, rather than requesting address space from the upstream provider? We want to use BGP and connect to 2 upstream providers. Everyone knows existing internet has two problems: *limited IPv4 address space which has to be assigned in a fair manner *growing number of BGP routing entries Unfortunately those two are interconnected, if we decide to reduce initial allocation size and promote becoming a LIR, number of ASes will grow. One should keep in mind this number is also limited, on cisco routers AS number is two byte unsigned integer thus we can have max 65536 ASes. Conclusion: BGP "address space" (ASes) is even easier to exhaust than IPv4 address space. Of course one can always request IOS modification, but it will also require change in BGP specification. Taking into account scale of change and resulting growth of routing tables it won't be easy. As I understand existing RIPE rules are oriented towards traffic organization. LIRs provide internet connectivity and assign IP addresses to end customers. In an ideal world, where providers guarantee QoS there will be no need for end user multi homing. However world is not perfect, therefore a need for multi homing arises. In my opinion, based on situation in Poland, the only way to ensure proper routing is own CIDR block -> go LIR. Other solutions such as "more specific routes" don't work in practice, especially when you want to provide service (e.g. run portal) over internet. From technical point of view BGP deployment is a valid reason to assign a CIDR block. If we want to tame rapid growth of LIRs we should ask for justification of BGP implementation and refuse LIR registration if the only reason is convenience (we want own address space and are aware of PI problems). Of course it won't be easy and will result in numerous problems. Therefore we should only impose administrative limitations on becoming a LIR if we have to, e.g. we are afraid to run out of CIDRs before IPv6 is widely implemented. I understand such a policy hinders "new kids on the block", but CIDR blocks are no different from any other scarce resource, difficulty to get one increases as number of free ones decreases. Regards, Jacek Blocki -----Original Message----- From: Alfredo Sola [mailto:alfredo@intelideas.com] Sent: Monday, May 21, 2001 7:36 PM To: RIPE NCC Staff Cc: lir-wg(a)ripe.net Subject: Re: Criteria for initial PA Allocation > 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. We are painfully aware of this. Furthermore, many mid to large organisations could do it with less than a /24 as they are doing address translation and need only a handful of IPs for the translated users and a handful of public servers. However, I don't think it is feasible to allocate such small ranges. The only alternative to me seems to lower the initial allocation of Enterprise LIRs to a /22 or even a /24 (if a range is available that won't be filtered out by the usual prefix length policies), except if the LIR asks for something larger on the first request. By doing that, you would also be able to say to PI requesters to get a LIR, which they don't actually need to get their IPs as of now. Responsibilities - I honestly don't have a suggestion for that, other than pointing out that when one needs only one range and maybe a second one after many months or even years, this can probably be done without much hassle. It would be more of a problem if we were talking about ISPs, which need new allocations every day. -- Alfredo Sola Director técnico () ascii ribbon campaign /\ Support plain text e-mail

2 1

Re-shifting priorities in the Registration Services
by RIPE NCC Staff 21 May '01

21 May '01

Dear all, This is to inform you that we are re-shifting our priorities in the Registration Services at the RIPE NCC. As this may affect the members' planning, the details are outlined below. The Registration Services will for the coming future be focusing its efforts on IP and ASN requests. As reported over the last years, a large part of the RS's workload is represented by the high amounts of questions we receive. However, it has been expressed in the membership that although the education is a vital part of the RIPE NCC's role, it shouldn't impede or delay the evaluation of IP and ASN requests. In order to give required priority to IP and ASN requests, we will therefore be giving lower priority to general questions and queries, which will be removed from the general wait queue. While we are waiting for software to automate this process, we are already starting this approach on a manual basis. We therefore ask for your patience with your questions and queries, keeping in mind that IP and ASN requests will be answered in a quicker fashion. We would also like to ask you to make sure that your requests are properly filled out, paying close attention to all templates as this ensures that correct priority is given and faster processing of the request. Please see the URLs below for further information and explanations. Another change underway is related to the way priorities are given to new and on-going requests. In order to reduce the initial waiting time, we will be giving priority to new requests as opposed to on-goings. This will allow hostmasters to quickly reply to and approve correct requests, while requests that require many corrections and reiterations are given a lower priority. This change is in concordance with recent feedback from the community and is part of an attempt to respond to the membership needs in a more precise and timely fashion. Kind regards, Nurani Nimpuno +------------------------------------+ | Nurani Nimpuno | | Registration Services Manager | | RIPE Network Co-ordination Centre | | http://www.ripe.net | +------------------------------------+ Quick tips for IP and AS Requests: http://www.ripe.net/ripencc/tips/tips.html Registration Services FAQ: http://www.ripe.net/ripencc/faq/registration/index.html European IP Address Space Request Form http://www.ripe.net/ripe/docs/iprequestform.html Supporting Notes for the European IP Address Space Request Form http://www.ripe.net/ripe/docs/iprequestsupport.html

2 1

Re: IPv6 addresses for EP
by Dave Pratt 18 May '01

18 May '01

Hiya, I've removed lir-wg(a)gblx.net from the distribution !!! Please see below. On Thu, 10 May 2001, David R Huberman wrote: ->> ->Exchange points need the ability to petition RIRs directly for address ->> ->space not for routability, but to ensure uniqueness. ->> ->> I think exchange point infrastructure - web servers,monitoring,test traffic ->> boxes, etc. need to be multihomed as well as globally unique. -> ->I don't understand. An exchange point, as I think about well-known ->implementations, is simply a means by which to organize participants in a ->common place. It's an island to which multiple participants connect with ->the explicit goal of interconnecting to one another. -> ->Exchange point address space should only be used to establish those ->interconnections with the routers - not for any ancillary services the ->exchange point might provide that require internet connectivity. Such ->services should *not* be part of any exchange point address policy ->considered by LIR-WG, imo. -> ->/david Looking at a couple of professionally run exchanges in Europe, I disagree. Exchange support infrastructure needs to be multihomed, and as Randy so succinctly pointed out, this cannot be achieved through a transit provider (or with their addresses). I would see an exchange being in control of a block (at least /48, although a normal LIR assignment would make more sense to me to ensure routability). This block would be globally routable and provide connectivity to support infrastructure. A more specific prefix of this could then be used for the exchange LAN itself. If the exchange requires two completely independent prefixes then I would also support that option. IPv6 addresses are not in short supply - a /60 compromise only complicates things and is against the "/48 policy". We could expand this discussion to cover multihoming in general - why would anyone switch to IPv6 from IPv4 if it means they can no longer multihome like they did in IPv4. Cheers Dave

9 13

80/8, 81/8 Allocated to the RIPE NCC
by RIPE NCC Staff 18 May '01

18 May '01

Dear all, This is to inform you that the RIPE NCC has recently been allocated the CIDR blocks 80/8 and 81/8 by IANA. The RIPE NCC is currently starting to make allocations primarily from 80/8. The minimum allocation size made by the RIPE NCC in these address blocks is a /20. ** If you use prefix based filtering in your routers, please note this change ** This has been announced previously but may not have reached all affected parties. We sincerely apologise for this. For a complete list of all /8 address blocks, please refer to: http://www.iana.org/assignments/ipv4-address-space Kind regards, Nurani Nimpuno +------------------------------------+ | Nurani Nimpuno | | Registration Services Manager | | RIPE Network Co-ordination Centre | | http://www.ripe.net | +------------------------------------+

1 0

80/8, 81/8 Allocated to the RIPE NCC
by RIPE NCC Staff 18 May '01

18 May '01

Dear all, This is to inform you that the RIPE NCC has recently been allocated the CIDR blocks 80/8 and 81/8 by IANA. The RIPE NCC is currently starting to make allocations primarily from 80/8. The minimum allocation size made by the RIPE NCC in these address blocks is a /20. ** If you use prefix based filtering in your routers, please note this change ** This has been announced previously but may not have reached all affected parties. We sincerely apologise for this. For a complete list of all /8 address blocks, please refer to: http://www.iana.org/assignments/ipv4-address-space Kind regards, Nurani Nimpuno

1 0

RE: New Document available: RIPE-219
by Low, Adam 18 May '01

18 May '01

Is it me or are the ASCII versions of this document unavailable, the FTP site doesnt seem to have them ? Thanks, Adam > -----Original Message----- > From: RIPE NCC Document Announcement Service [mailto:ncc@ripe.net] > Sent: 04 May 2001 16:58 > To: ripe-list(a)ripe.net > Cc: local-ir(a)ripe.net; lir-wg(a)ripe.net > Subject: New Document available: RIPE-219 > > > New RIPE Document Announcement > -------------------------------------- > A new document is available from the RIPE Document Store. > > > Short content description > ------------------------- > RIPE Document number 219 is the European IP Address Space > Request Form. This new document obseletes RIPE-141. > > > 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-219.ps PostScript version > ftp://ftp.ripe.net/ripe/docs/ripe-219.txt plain text version > > You can also access the RIPE documents in HTML format via WWW. > RIPE-219 is not available from the WWW at this moment, but will > be soon, at the following URL: > > http://www.ripe.net/ripe/docs/ripe-219.html >

1 0

Fw: [aso-announce] ASO input forum at Saturday June 2nd 0900
by Hans Petter Holen 16 May '01

16 May '01

----- Original Message ----- From: "Hans Petter Holen" <hph(a)online.no> To: <aso-announce(a)aso.icann.org> Sent: Wednesday, May 16, 2001 10:47 PM Subject: [aso-announce] ASO input forum at Saturday June 2nd 0900 | Dear Adrressing Community, | | The ASO plans to hold an ASO input forum | at the upcoming ICANN meeting in Stockholm. | | http://www.icann.org/stockholm/ | | The meeting is Scheduled to take place at | Saturday June 2nd 0900 | | Please submit proposals for presentations to be | given to hph(a)online.no before May 26th | | Best Regards, | | Hans Petter Holen | Address Council Chair | www.aso.icann.org | | * on-line archive: http://aso.icann.org/wilma-bin/wilma/aso-announce * | * To unsubscribe: send "unsubscribe" to aso-announce-request(a)aso.icann.org * | |

1 0

[pekkas@netcore.fi: RIR ISP to end-user address allocation policy?]
by John Wells 16 May '01

16 May '01

Here's a message from the IPv6 WG listserv. This should start some discussion.. John -- John WELLS INRIA Rhône-Alpes équipe Planète - ENSIMAG 3A/Télécomm et Réseaux Virginia Tech MS/Computer Engineering - Networking and Visualization Lab Clé public: finger wells(a)mansoun.inrialpes.fr <interne>

6 8

RE: IPv6 addresses for EP or why are exhanges so special ?
by Hallgren, Michael 16 May '01

16 May '01

> > > > I have tried to follow this discussion, and stumbeled over a > > fundamental question when trying to reason about this: > > > > * why are exchange points so special? > > My take on this is that "they are not". > > But before plunging on, I would find it useful to distinguish > between the two portions that have been discussed so far: > > o Addresses for the exchange point medium itself (usually a > layer-two network of some sort) > > o Addresses for a "service network", probably used by the > organization which runs the exchange point and which can > provide additional common services of interest to the > connected networks. > > I'll also mention that my experience on the matter is based on > IPv4, so if there are additional quirks that are specific to IPv6 > that I don't know about, you'll have to excuse me. > > For the exchange point medium itself, if the medium is a "multiple- > access broadcast network" it *is* actually a benefit to use the > "natural" way to number such networks, i.e. use a single IP subnet, > as in that case you can use BGP in the "standard configuration". > Starting to muddle with secondary IP addresses and run "multiple > subnet on the same layer-two medium" when you in reality don't have > to, just causes extra complications, and should therefore be > avoided. If your exchange point is implemented using a "multiple- > access non-broadcast network" of some sort, the multiple point-to- > point links, each with their own subnet out of a connected peer's > address block makes sense. > I'm of the same opinion. > Some have said that the IP network used to number the exchange > itself does not have to be announced on the global level. However, > it would appear that practices vary quite widely on this point for > IPv4, and many are announced globally. You mention the possible use > of link-local addresses; I wonder if that won't make it difficult to > handle such things as ICMP; it'll probably be met with similar > issues as folks who use RFC 1918 addresses in today's network (e.g. > breaking Path MTU discovery because RFC 1918-originated datagrams > are often summarily dropped on the floor). > I fear that as well. Of course, however, it's a question of being smallest MTU on path - but for avoiding such potential problems... > I may have misunderstood something fundamental, but I also don't > quite know what's so bad with using IP(v4) addresses out of a > provider's block to number the exchange point medium. > > > As for the "service network", it will of course need global > connectivity, and thus has to get transit service from one or more > ISPs. What I don't understand is why this service network needs to > be so special up and above other normal customers when it comes to > IP address assignment? > Depending on how transit / co-location is provided, yes. Hrm,... maybe I'm wrong, maybe I'm right... but couldn't suitable PI disjunct to IX infra space (and/or close segment) be a choice as well? Thoughts? Kind regards Michael > > Creating these "special cases" as exceptions to the rules just opens > up the floor for other folks who will stand up and say "My Cause is > Extremely Worthy too, so I want some too under those conditions!!". > > > Best regards, > > - Håvard >

1 0

IPv6 addresses for Exchange Points
by Mirjam Kuehne 15 May '01

15 May '01

[Apologies 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, At RIPE 39 last week in Bologna the issue of IPv6 address assignments to Internet Exchange Points was discussed (see also my mail from 24 April 2001 to these lists). There was consensus to assign a /64 to an isolated Exchange Point. It was further suggested to assign the agreed standard assignment size to a site (currently a /48) to a group of inter-connected Exchange Points. An Internet Exchange Point was defined as follows: 3 or more ASes and 3 or more separate entities attached to a LAN (the same infrastructure) for the purpose of peering and more are welcome to join. The RIPE NCC proposes to proceed with assignments for Exchange Points under the above policy. Kind Regards, Mirjam Kuehne RIPE NCC

3 2