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

RIPE-181 to RPSL Migration; Completed switch-over to phase 2
by DB-News 14 May '01

14 May '01

Dear Colleagues, (Apologies for multiple messages). This is to announce that we have completed the phase 1 of migration. Starting from today, 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 has also been 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 RPSL 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 RPSL format 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, Engin Gunduz ____________________________ RIPE Database Administration.

1 0

Re: IPv6 addresses for EP or why are exhanges so special ?
by Cathy Wittbrodt 11 May '01

11 May '01

HPH, The other reason why there is an allocation policy for exchange points (at least in the ARIN region) is because the folks who are building exchange points may not have enough of them to justify the minimum allocation. It seemed reasonable that they would need provider independent space, however, so they can get it with the provisions written in the policy. If you think about a neutral exchange point provider who's business is to connect up providers to peer, etc, that exchange point provider may want or need to supply the IP addresses for that exchange point. They're providing a service and may want to provide the address space as well. I can't speak for the exchange providers, but setting up p2p vlans or whatever for folks connected to the same ethernet switch may be time consuming and also can waste quite a bit of address space (if you're using /30s for p2p links and not /31s, per the new yet unimplemented draft). I hope this helps! ---CJ From: "Hans Petter Holen" <hph(a)online.no> Subject: IPv6 addresses for EP or why are exhanges so special ? 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 ? It seems to me that shared medium exchange points historicaly have used a single subnet to interconnect. Generaly it simplifies configuration and eases operations to have a single logical interface on the physical interface connected to the shared medium. But in order to excange traffic with other partners at the exchange one needs to establish "pont to point" BGP peerings. So there is no longer any significant configuirational advantage in having all the boxes I want to talk to on a single subnet (I still need to figure out how to talk to the others by establishing BGP peerings.) On the operational side, at least back when I was directly involved in such, it would actualy be very convenient to have logical point to point links with all my peering partners in order to better diagnose and measure traffic flows and flaws. If this is the case, the IP addresses for the logical point to point links across the exchange would best be implementedwith IP addresses from any of the providers, or perhaps even the IPv6 equivalent of link local addresses. I would be interested to hear comments on this approach, because if this model makes senseto implement, it would probably make sense to document this as some kind of "best current practice" for IP v6 exchanges in order to make sure that the router vendors implements the proper tools to make this easy to configure. Looking forward to hear others opinions on this. -hph

1 0

RE: IPv6 addresses for Exchange Points
by Hallgren, Michael 11 May '01

11 May '01

> -----Message d'origine----- > De : Randy Bush [mailto:randy@psg.com] > Envoyé : jeudi 10 mai 2001 22:54 > À : David R Huberman > Cc : Gert Doering, Netmaster; Wilfried Woeber, UniVie/ACOnet; > lir-wg(a)ripe.net > Objet : Re: IPv6 addresses for Exchange Points > > > > For the purposes of this policy discussion, we must > differentiate between > > address space utilized explicitly for the interconnection > of exchange > > participants and space utilized for other purposes. > > we will gladly give them address space when they buy transit. > idem :) mh > randy > -- Michael Hallgren, Inet Eng., Teleglobe, MH2198-RIPE

1 0

Re: IPv6 addresses for Exchange Points
by Hank Nussbacher 11 May '01

11 May '01

At 10:25 10/05/01 -0700, David R Huberman wrote: > > But they need connectivity for things like member > > mailing lists, www servers etc. anyway - which does not mean that those > > services have to (or even "should") be located at the IX itself, in the > > same IP prefix. > >I should have read this before I responded to Dave Pratt's email - Gert >said it far better than I did! > >For the purposes of this policy discussion, we must differentiate between >address space utilized explicitly for the interconnection of exchange >participants and space utilized for other purposes. What about a route reflector run at an exchange point with a LG to check things out? Wouldn't a globally routable IP address be called for in regards to the LG? -Hank >/david

2 1

Re: IPv6 addresses for Exchange Points
by David R Huberman 11 May '01

11 May '01

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

2 1

Re: IPv6 addresses for Exchange Points
by Wilfried Woeber, UniVie/ACOnet 10 May '01

10 May '01

Hi Gert! =Hi Wilfried, = =a few comments: = =On Wed, May 09, 2001 at 02:23:30PM +0200, Wilfried Woeber, UniVie/ACOnet wrote: =[..] => =On Mon, May 07, 2001 at 05:35:11PM +0200, Mirjam Kuehne wrote: => => 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. => = => =I suggest to change the wording to "a common layer 2 infrastructure" => =- an exchange point might be some distributed thing peering over an => =ATM/FR cloud or a SRP/DTP ring, which isn't really a "LAN". Policy => =should not be tied to special implementation techniques. => => From a technical point of view, I fully support your suggestion. => => From an administrative point of view, I'd re-iterate that nobody is => going to be able to define an IX, much like we agreed eventually that we => would never succeed in defining an ISP. = =Yes, we'll never be able to define with 100% perfection "this is an IX =and that is not". = =With Randys definition, we have something that should suffice to include =all forms of IXes, and maybe some other things that are not IXes in the =strict sense. This is why I added the remark about "ok, we will waste =addresses on 'them' - but there's so much address space, so what". = =*I* don't think we have a problem here, but yes, we need community =consensus here. = =[..] => Talking to folks at one IX (close by :-) and listening to suggestions as => to why this approach is useful, I am having problems with the assumption => that any such IX would remain confined to a *single* subnet. = =This was not part of the proposal :-) Correct :-) =- it was "if they have only one =subnet, give 'em a /64, of not, give 'em a /48". = =There is a point about interconnection between those subnets - yes, that =should not be necessary (if they are at L2 interconnected, one /64 will =suffice, if at L3 or not at all, handing out multiple /64s is just not =worth the effort - IMHO). What I was referring to was the paragraph in Mirjam's summary to the EIX list: "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." =[..] => What is going to happen here is the creation of a TWD/PI environment. => And I do not claim that this is bad i itself, btw. => Just face the fact up front. = =Yes. This is why... = => >So I'd suggest another thing: add to this a big warning that this => >space is not "PI" (whatever that means) and that it is very likely that => >it will never be routeable world-wide. This should stop people wanting => >to use such space for something different than an exchange point from => >applying for it. => => Why do we expect the v6-world to be different from the v4-world, in the => sense that it is the ISPs and the folks dealing with the routing layer => who decide about acceptiong routes, and *not* the address registries? = =There is no difference, but we can avoid making one mistake, that has =been mentioned in the "PI" discussion: if a RIR hands out a chunk of =addresses, it is kind of "sanctioned" (because what good would that =subnet be if not routeable?). Nobody has ever said "because this is =official PI, it will work", but people expect it to work nonetheless. = =So this is why I think the warning label would do good: it might make =sure that this is *really* only meant as "multi-site-local" address =space and not to be routed on the whole net (which might work, or might =not, but it's not meant for that). = => PS: btw, who is going to do revDNS for those prefixes? = =The IX themself 'course - but then their (IPv6) prefix must be routed, or they have to obtain/use addresses from (one of) their members (which sounds like the thing they want to avoid in the first place?) or buy connectivity or service form somewhere. Can be done, of course! - RIPE could delegate RR-DNS at /48 or /64 boundaries. Yes, they probably could. But do they want to? And potentially doing it for free? =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 Wilfried.

5 5

Re: IPv6 addresses for Exchange Points
by Arjan 10 May '01

10 May '01

To: lists-lir-wg-out(a)lists.ripe.net To: David R Huberman <huberman(a)gblx.net> To: <200105101738.VAA93346(a)phil.wplus.net> Euhm, can we fix this ? Whatever is happening ? I think 7 copies is enough... Thanks :) On Thu, 10 May 2001 at 10:25 -0700, David R Huberman wrote: > To: lists-lir-wg-out(a)lists.ripe.net > To: postmaster1(a)wplus.net > > > To: lists-lir-wg-out(a)lists.ripe.net > To: postmaster1(a)wplus.net > > > To: lists-lir-wg-out(a)lists.ripe.net > To: postmaster1(a)wplus.net > > > To: lists-lir-wg-out(a)lists.ripe.net > To: postmaster1(a)wplus.net > > > To: lists-lir-wg-out(a)lists.ripe.net > To: <20010510154913.C3919(a)Space.Net> > > > > But they need connectivity for things like member > > mailing lists, www servers etc. anyway - which does not mean that those > > services have to (or even "should") be located at the IX itself, in the > > same IP prefix. > > I should have read this before I responded to Dave Pratt's email - Gert > said it far better than I did! > > For the purposes of this policy discussion, we must differentiate between > address space utilized explicitly for the interconnection of exchange > participants and space utilized for other purposes. > > /david > > -- GE d- s++:++ a- C+++$ U+ P+ L- E---- W- N++ o++++ w O- M-- PS+++ PE++ Y+ PGP++ t+@ 5 X+ R* tv+ b- G e h r- y++

1 0

Re: IPv6 addresses for Exchange Points
by David R Huberman 10 May '01

10 May '01

To: lists-lir-wg-out(a)lists.ripe.net To: <20010510154913.C3919(a)Space.Net> > But they need connectivity for things like member > mailing lists, www servers etc. anyway - which does not mean that those > services have to (or even "should") be located at the IX itself, in the > same IP prefix. I should have read this before I responded to Dave Pratt's email - Gert said it far better than I did! For the purposes of this policy discussion, we must differentiate between address space utilized explicitly for the interconnection of exchange participants and space utilized for other purposes. /david

2 1

Re: IPv6 addresses for Exchange Points
by Wilfried Woeber, UniVie/ACOnet 10 May '01

10 May '01

>Subj: Re: IPv6 addresses for Exchange Points I think there are still quite a few aspects which require forming a consensus, finding a definition or a solution. First of all, talking directly to the set of IXs effectively bypasses the LIR to NCC channel. so, tjis should be defined in the proposal. I can imageing that the IX should either become an Enterprise Registry or work with one of the existing LIRs. =Date: Mon, 7 May 2001 17:51:56 +0200 =From: Gert Doering <gert(a)space.net> =To: Mirjam Kuehne <mir(a)ripe.net> =CC: lir-wg(a)ripe.net =Subject: Re: IPv6 addresses for Exchange Points = =Hi, = =On Mon, May 07, 2001 at 05:35:11PM +0200, Mirjam Kuehne wrote: => 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. = =I suggest to change the wording to "a common layer 2 infrastructure" =- an exchange point might be some distributed thing peering over an =ATM/FR cloud or a SRP/DTP ring, which isn't really a "LAN". Policy =should not be tied to special implementation techniques. From a technical point of view, I fully support your suggestion. From an administrative point of view, I'd re-iterate that nobody is going to be able to define an IX, much like we agreed eventually that we would never succeed in defining an ISP. =Besides this, I like the proposal. = =As discussed with a few people after the WG, it *does* pose the risk of =handing out "lots and lots" of /48s and /64s to people claiming to be =an exchange point. (It's not that hard to get three ASes together =over "some" medium). Talking to folks at one IX (close by :-) and listening to suggestions as to why this approach is useful, I am having problems with the assumption that any such IX would remain confined to a *single* subnet. Also, in keeping with the IAB/IESG recommendation I would propose to simply ask the applicant whether they really intend to run *one* layer-2 subnet (and then assign a /64). (Examples: multicast test-beds, VLANs, host not allowed on DMZs,...) Otherwise assign a /48 - without asking questions about "relations" between IXs. >On the other hand: if we reserve a /35 for that, we have 2^13 /48's >to hand out to "would-be IXes". So the danger of address wastage >is not too big. > >The danger of routing deaggregation *is*... What is going to happen here is the creation of a TWD/PI environment. And I do not claim that this is bad i itself, btw. Just face the fact up front. >So I'd suggest another thing: add to this a big warning that this >space is not "PI" (whatever that means) and that it is very likely that >it will never be routeable world-wide. This should stop people wanting >to use such space for something different than an exchange point from >applying for it. Why do we expect the v6-world to be different from the v4-world, in the sense that it is the ISPs and the folks dealing with the routing layer who decide about acceptiong routes, and *not* the address registries? >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 Wilfried. PS: btw, who is going to do revDNS for those prefixes? _________________________________:_____________________________________ 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

RIPE-181 to RPSL Migration; Phase 2.
by DB-News 10 May '01

10 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 RP S 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 RP S 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

1 0

RE: IPv6 addresses for Exchange Points
by paul.mylotte＠bt.com 09 May '01

09 May '01

At the RIPE 39 joint meeting it was clarified that we should cater for the support of both types of IPv6 exchanges, viz: * allocate addresses for IPv6 exchange infrastructure only (no onwards allocation in the manner of a backbone ISP). * allocate a sub TLA to the IPv6 exchange which will then act in the manner of an ISP and allocate downstream. In order to progress this, I would like to propose: * IPv6 exchanges that need addresses for the purpose of internal addressing can apply for the addresses already set aside for this purpose and held by IANA, as per RFC2928 and RFC2450. In this case a /48 allocation will be sufficient. (How IPv6 exchanges should apply for these addresses is out of scope - either direct to IANA, or IANA allocates down to RIRs first). * IPv6 exchanges that plan to onward allocate addresses in the manner of an ISP should apply via the existing mechanism. The existing mechanism is currently being reviewed and this review should take account of any changes necessary to include IPv6 exchanges explicitly desiring addresses for onward allocation as being acceptable candidates for address space. Regards, Paul P. S. Mylotte BTexact Technologies Adastral Park 01473 606333 / + 44 1473 606333 paul.mylotte(a)bt.com BTexact Technologies is a trademarkof British Telecommunications plc Registered office 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000 This electronic message contains information from British Telecommunications plc which may be priveleged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the number or address above) immediately. > -----Original Message----- > From: Mirjam Kuehne [SMTP:mir@ripe.net] > Sent: 07 May 2001 16:35 > To: eix-wg(a)ripe.net > Cc: ipv6-wg(a)ripe.net; lir-wg(a)ripe.net > Subject: IPv6 addresses for Exchange Points > > > [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 > >

1 0

IPv6 Bootstrap Phase
by Mirjam Kuehne 07 May '01

07 May '01

Dear colleagues, As discussed at RIPE 39 in Bologna last week, we have almost reached the end of the bootstrap phase for IPv6 allocations as originally defined in the "Provisional IPv6 Assignment and Allocation Policy Document": 4.2.2.1. Duration of Bootstrap Phase " The eligibility criteria in this section will only apply until 100 requesting organisations have received allocations of sub-TLA address space, provided that no more than 60 of these organisations are located in one Regional IR's region. After this threshold has been reached, the bootstrap phase will be considered to be over and Regional IRs will only make allocations to organisations that meet the general criteria in section 4.2.1. " The Regional Internet Registries (RIRs) have jointly made almost 80 IPv6 allocations to date. At the RIPE meeting it was suggested to continue allocating under the bootstrap criteria until 100 allocations have been made and to further extend the bootstrap phase. No specific end for the bootstrap phase has been suggested. The RIRs will inform the community as soon as 100 IPv6 allocations have been made. Kind Regards, Mirjam Kuehne RIPE NCC

1 0

Re: New Document available: RIPE-219
by Dmitry Morozovsky 04 May '01

04 May '01

To: <200105041458.QAA23820(a)office.ripe.net> Cc: RIPE NCC Document Announcement Service <ncc(a)ripe.net> On Fri, 4 May 2001, RIPE NCC Document Announcement Service wrote: RNDAS> Document number 219 is the European IP Address Space Request RNDAS> Form. This new document obseletes RIPE-141. I suppose differences between ripe-141 and ripe-219 are interesting for the LIR community. They follow (besides formatting issues and obvious references); on the other hand, most of changes between ripe-142 and ripe-220 are in formatting and changing all dates to 4-digit year notaion. --- ripe-141.txt +++ ripe-219.txt @@ -25,13 +24,13 @@ This document contains the set of templates to be used when submitting an IP assignment request. This set of templates must be used by - Internet Service Providers when submitting a request to the RIPE NCC. + Local Internet Registries when submitting a request to the RIPE NCC. It may also be used by ISPs to collect information from those managing the networks that will use the address space. Instructions for filling out the templates are found in the accompanying document "Supporting - Notes for the European IP Address Space Request Form ( ripe-142). + Notes for the European IP Address Space Request Form ( ripe-219). - Internet Service Providers: Submit the form via e-mail to + Requesters: Submit the form via e-mail to "<hostmaster(a)ripe.net>." (If the ISP is not a Local Internet Registry , the form should be submitted to the upstream provider.) @@ -138,13 +137,14 @@ inetnum: netname: descr: - descr: country: admin-c: tech-c: status: +mnt-by: +mnt-lower: (optional) +mnt-routes: (optional) notify: (optional) - mnt-by: (optional) changed: source: RIPE @@ -152,8 +152,6 @@ person: address: - address: - address: e-mail: phone: fax-no: (optional) @@ -163,6 +161,13 @@ changed: source: RIPE - #[TEMPLATES END]# IV. Optional Information Sincerely, D.Marck [DM5020, DM268-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck(a)rinet.ru *** ------------------------------------------------------------------------

1 0

New Document available: RIPE-219
by RIPE NCC Document Announcement Service 04 May '01

04 May '01

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

4 3

New Document available: RIPE-220
by RIPE NCC Document Announcement Service 04 May '01

04 May '01

New RIPE Document Announcement -------------------------------------- A new document is available from the RIPE Document Store. Short content description ------------------------- Supporting Notes for the European IP Address Space Request Form. This document obseletes RIPE-142. 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-220.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-220.txt plain text version You can also access the RIPE documents in HTML format via WWW. RIPE-220 is not available from the WWW at this moment, but will be soon, at the following URL: http://www.ripe.net/ripe/docs/ripe-220.html

2 1

Acrion list after RIPE 39
by Hans Petter Holen 04 May '01

04 May '01

35.4 NCC PGP Key exchange procedure Low prio 35.5 NCC Implement PGP for hm Low prio 36.5 Chair Assignment window applied on infrastructure Proposed change 36.6 AP Collect arbitrators Taken care of. 36.7 NCC Keep lir-wg updated on pre RIR address space changes Db-wg presentation 37.1 WG Further discuss restoring the transparency Ntr 38.2 NCC Implement changes to the form while taking into account the comments from the WG In progress 38.3 WG Reopen policy discussion - do we need a major revision of RIPE 185 RIPE 40 38.4 AC Consider how to coordinate Address prediction work Work launced 38.5 NCC Implement 34.6 LIR-ALLOCATED 38.6 NCC Propose PI policy to the WG Ongoing 39.1 NCC Better metrics & more relevant stats 39.2 NCC Suggest procedure and possible policy changes 39.3 NCC Call for AC nominations 39.4 Chairs Define & divide work 39.5 Chairs Beta test 6 weeks deadline for proposals

1 0

lir-wg draft minutes from RIPE 38
by Hans Petter Holen 01 May '01

01 May '01

Dear lir-wg, I am sorry for submitting the draft minutes to you at such a late stage, it is partly due to the fact that I myself got the minutes rather late, partly due to my own lack of time to go trough them. Hans Petter --------- Draft Minutes Tuesday 23 January 2001. Scribe: RIPE NCC Hostmaster - Geoff Charters, Roger Arcilla Hans Petter Holen (HPH) opens the meeting by describing the way policies are developed in this region. Policies are developed in open forums (LIR-WG in the RIPE region). The Address Council (AC) oversees the process and gives resommendations to the ICANN board. He asks the audience to give input to the AC. He also stresses that the AC are elected by the regional policy foras like the lir-wg and that we are not there to make policy ourselves, but merely to oversee the policy making in the regions. (http://www.ripe.net/ripe/meetings/archive/ripe-38/presentations.html#LIR)5 HPH introduces the members of the AC: There are 3 members from the APNIC region, 3 from the ARIN region, 3 from the RIPE region (see http://www.aso.icann.org/ac/) Sabine Jaumes term is ending. At the RIPE 38 plenary session elections will take place. HPH describes how the AC operates: The AC makes an effort not only to attend open policy forums and other events in the recpetive region, but also to gather input trough special input foras. The AC and the RIRs have recently sent out a call for nominations for a vacant ICANN board seat. Nominations can be submitted by anyone. There is also a possibility to express support for nominees. In order to keep the geographic diversity on the ICANN board, the new board member cannot come from Europe or the Asian Pacific region. Address allocation policies are developed in a bottom-up manner in each region. How is global policy developed? Is a proposal first discussed in each region and then coordinatd between the RIRs? This can be a long process. Do we need to create a gobal mechanism? Is there more co-ordination necessary between the RIRs or the regional open policy forums? What are global issues, what are regional? HPH reports from the workshop the AC had with the RIRs and IANA in Brisbane in November 2000. It was a very productive and effective workshop. The role of the AC was discussed. Is the AC too active or not active enough? An action was placed on the RIR's to compare regional policies. The goal is not to produce the same policies - but to find the differences. There might reasons for different policies. The general issue on how to take care of resource (IP addresses, ASNs). Is it a public resource that need to be protected or should it be market driven or auctioned? The AC is committed to be more proactive in informing the community about their acivities by creating a publically archived mailing list which is used for AC meeting agendas, minutes and policy discussions. Only about 5 people in the audience looked at the ASO web site. HPH encourgaes everyone to follow the developments. One achievement during last year was the discussion related to address space needed for GPRS. This has been taken up in all regions and is being handled in a consistent way. Up til now, address requirements for the GPRS infrastructure has been discussed. Further discussions need to take addresses for handsets into account. Many of these developments address issues listed by the Ad hoc group. The Ad hoc group will present its final report to ICANN shortly and will then be closed. The RIRs submitted a document to the AC and to ICANN listing criteria to be used by ICANN when approving emerging RIR. According the ASO MoU it is ICANN that makes the final decision about the approval of a new RIR. One important criteria is strong support from within the region of the emerging RIR. Similar to the RIPE LIR-WG there are open policy forums in the ARIN and APNIC regions. HPH wonders if this was a useful overview of AC activities and asks for feedback. What should be on the AC's list of actions for 2001? The audience feels this was useful. Mark McFadden wants the AC to do more. In particular: there is a lot of discussion about scarcity of IPv4 addresses and ASNs. A lot of work is done in an uncoordinated way. Wants the AC to co-ordinate this. Spreaded activities all over the world, wants the AC to combine this work. He is not suggesting that they do the work themselves. He also wants the AC be more active in globalising addressing policies. He also feels that RFC2050 should be revised, the AC should not do this, but another group. It is out of date and incomplete. Randy Bush agrees with Marks second point, it would be nice to have policies/procedures more aligned. To the first point, this work is ongoing in the IETF. The only useful addition one could be to compile and bundle this work for people who do not have the time to follow all developments. Mark points out that there is engineering work being done outside the IETF, the AC could play a role in this. Wilfried Woeber would like to share some of his experiences with this 'flying circus': sometimes one finds out that one was part of a feedback loop. Requirement to interact with different people and groups, this is a good thing about the Internet industry self-regulation. On the issue of global policy, thinks the AC did a good start by asking the RIRs to look at each other policies and define which ones are different and why. Then this could be given back to the communities asking if they want to keep it the way, because they are used to this and it doesn't harm or if they want to put energy in it to try to make them more aligned. Carsten Schiefner wonders if there a transition plan from the established RIRs to the emerging RIRs. HPH explains that this is done in a bottom-up manner: ISPs in the area cannot be forced to either stay or move, they have to show support. Randy wonders if there will be competition between the RIRs? Mirjam: No, RIRs operate in geographic regions, it has been working well so far, they are not proposals on the table to change this. Juergen Rauschenbach notes that the IPv6 policy document still pending, because one of the communities did not agree. He wonders if additional RIRs will impose even more delay on these kinds of issues. Mirjam explains that policies are in place so that IPv6 operations are not delayed through that. SubTLAS are handed out. ARIN community set up a working group to look into the policy. Richard Jimmerson from ARIN reports from the status of the ARIN IPv6-WG. Juergen suggests to implement regional policies if one of the regional communities cannot make a decision to go along with the others. Mirjam urges everybody to try to develop globally consistent allocation policy for IPv6. The RIRs are still committed to that. She reminds the audience that the fact that some of the IPv4 allocation policies have not been aligned has created constant criticism. Lets try to avoid this in IPv6. Paul Mylotte: Presentation on global address forecast (http://www.ripe.net/ripe/meetings/archive/ripe-38/presentations.html#LIR) Juergen believes that both methods are flawed 1. method: H-Ratio has not taken into account Even though there are 400 million addresses still available it will be hard to push density above 116 million addresses used, currently density at about 105 - 110 millions 2. method: good numbers if the growth is staying stable. There are more factors: mobile devices, address needs in China etc. Scott Markus also comments on method 2: not on the total numbers allocated, but on the growth itself; change in the change, no change in the base. Geoff Huston for instance calculates 7% of addresses allocated Mark MacFadden acknowledges that substantial work has been done in a number of areas. Personally he believes the H-ratio is questionable. He would like to see some harmony between the work that is going on. They all relate to different things, difficult to compare. We need to bring this information together. The AC should take on this work. Scott agrees with Mark. There was a discussion among the RIRs themselves to put more effort into this, will make the base data more widely available and put more work into this. Leos Vegoda: presentation (http://www.ripe.net/ripe/meetings/archive/ripe-38/presentations.html#LIR) Wilfried wonders if we really want to go into a lot of details for such small amount of address space? Should there be a standard size of address space where one is entitled to have one without any questions asked? Joao believes that this would mean a shift from assignments based on actual need to more simplification. Gerd is in favour of giving people public addresses instead of private addresses if they don't want it. He would be happy to give everyone a /29. This would make life easier for people and would also pushes the deployment of IPv6. John Klensin notes that these kind of limits (/29 in this case) seem to be made up by magic. He advocates to be careful with looking at these numbers and to draw conclusions from them or to assume all kinds of things that might not be valid in the future. PaulW points out that this proposal has also global implications. In the APNIC region there is very rapid deployment of cable and ADSL in a number of countries. Any decision that is made here, will be used and seen as a precedent in other regions. This will increase the usage rate significantly. He suggests to still have it dependend on the network and the application, not on the technology. An assignment of a /29 to all cable and ADSL customers seem to be very dangerous and not at all necessary. HPH proposes to introduce a separate assignment window for infrastructure. Maybe together with some safeguard to review this once a year or so. Discussion will be continued on the mailing list. Finally the ASO General Assembly Meeting was announced to be held in San Francisco on 4 April 2001.

1 0

IPMT specification rough draft
by Manuel Valente 01 May '01

01 May '01

Hi, Following a presentation by Guy Vegoda at the Tools BOF at RIPE37 of an IP Management Tool, interest was expressed in the development of an Open Source version of such a tool and we used the lirwg list to draw up Requirements for this. We have now produced some rough specifications for this tool that we will present at the upcoming Tools WG tomorrow. 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'. We would now like the help of such potential users to refine these specifications into something that the RIPE NCC and interested developers can go away and implement. So, if you're interested by such a tool, please come along to the RIPE39 Tools WG tomorrow at 16h00 in the Europa Auditorium. Thanks. -- Manuel Valente - Software Manager - RIPE NCC ------------------------------------------------------------------ Draft of Specifications for an IP Management Tool Manuel Valente, Leo Vegoda, Maldwyn Morris RIPE NCC swcontact(a)ripe.net 20010419 0. Introduction Following a presentation of an IP Management Tool by Guy Vegoda at the Tools BOF at RIPE 38 [1], interest was expressed in the development of an Open Source version of such a tool and we drew up Requirements (qv) 1. General Points 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. Definitions: Parties : RIPE NCC: The European Regional Internet Registry, which grants IPV4 address allocations to its customers, the LIRs. LIR: A customer of the RIPE NCC which interracts with the RIPE NCC in order to make IPV4 address assignments to their LIRCustomers from the LIR's IPV4 address allocation. LIR Customer: A person or organisation which wants to receive IPV4 address assignments. LIR Hostmaster: A person working for a LIR whose job it is to make IPV4 address assignments to the LIR Customers. Registered IPV4 Address Information: There are two forms of IPV4 address information which are registerd by the RIPE NCC and which are stored in the RIPE Whois Database: IPV4 Address allocations and IPV4 Address assignments. IPV4 Address allocations: A range of IPV4 addresses from which the RIPE NCC allows a certain LIR to make IPV4 Address assignments to their LIRCustomers. IPV4 Address assignments: A range of IPV4 addresses from a LIR's IPV4 Address allocations which the RIPE NCC and the LIR allows a certain LIRCustomer to use on the Internet. Interactions: I1: LIR Customer Assignment Request: An LIRCustomer asks their LIR for an IPV4 Address assignment and the LIR replies. Composed of: I1.1: LIRCustomer communicates request for IPV4 Address assignment to LIR I1.2: LIRHostmaster evaluates request I1.3: LIRHostmaster queries LIRCustomer about request I1.4: LIRHostmaster actions request I1.5: LIRHostmaster informs LIRCustomer of request outcome I1.6: LIRHostmaster completes request for LIR Customer I2: LIR Assignment Request: An LIR asks the RIPE NCC for approval of an IPV4 Address assignment and the RIPE NCC replies. I2.1: LIRHostmaster formulates query I2.2: LIRHostmaster sends request to NCC I2.3: LIRHostmaster handles response I2.4: LIRHostmaster completes request I3: LIR Allocation Request: An LIR asks the RIPE NCC for an IPV4 Address allocation and the RIPE NCC replies. I3.1: LIRHostmaster formulates query I3.2: LIRHostmaster sends request to NCC I3.3: LIRHostmaster handles response I3.4: LIRHostmaster completes request I4: LIRH Manages Customers I4.1: LIRHostmaster composes report(s) of info on one customer I4.2: LIRHostmaster composes report(s) on all customers I4.3: Creation of new customer I4.3: Update customer info I4.3: Delete customer I5: LIRH Manages LIR's Assignments I5.1: LIRHostmaster composes report of all assignments I5.2: LIRHostmaster composes report on a specific assignment I6: LIRH Manages LIR's Allocations I6.1: LIRHostmaster composes report of all allocations I6.2: LIRHostmaster composes report on a specific allocation 3. IPMT Functional Breakdown The functions the IPMT tool must provide, divided per Interaction. I1: LIR Customer Assignment Request: I1.1. LIRCustomer communicates request for IPV4 Address assignment to LIR IPMT: F1: receive the LIR Customer Assignment Request F2: store request info F3: LIR Hostmaster sees new request I1.2 LIRHostmaster evaluates request IPMT: F4: Check request correctly formatted and I1.5: Deny if not F5: Check request valid and I1.5: Deny if not F6: Check LIR Customer valid and I1.5: Deny if not I1.3: LIRHostmaster queries LIRCustomer about request IPMT: F7: Get more info from LIR Customer regarding request F8: update request info F9: -> I1.2: Evaluate I1.4: LIRHostmaster actions request F11: Need to ask RIPE to perform request ? -> I2 if so F12: Check request F13: Update request info F14: Check other info concerning assignments F15: Update other info based on request I1.5: LIRHostmaster informs LIRCustomer of request outcome F16: Communicate request outcome and info to LIR Customer I1.6: LIRHostmaster fills in customer request F17: Generate info about request, possible with F7 4. Implementation proposals ?? LIR Hostmaster interracts with IPMT via a GUI. ?? IPMT GUI will have HTML form range of elements ( text, buttons, single-line text, multi-line text, radio buttons, check boxes ). I1.1 LIRCustomer communicates request for IPV4 Address assignment to LIR F1: receive the LIR Customer Assignment Request ?? LIR Customer sends request : - via html form - by snailmail/phone/other & LIRH fills in a GUI form - by email to designated address - address served by mail robot ? - FORGET for now - too complex ? - LIRH uses CLI to fill in - Other LIR fills in using IPMT via API F2: store request info ?? Store in 'LIR Customer request' record in DB ?? Request record: Request id LIR Customer email address date raw request info - from LIR customer comm.s LIRH ID - 'request owner' F3: LIR Hostmaster sees new request ?? IPMT 'fetch next request' button to show next LIR Customer Request in GUI - wait queue... - IPMT perfroms F4,F5,F6 I1.2 LIRHostmaster evaluates request F4: Check request correctly formatted and I1.5: Deny or I1.6 if not IPMT parses 'LIR Customer Request' record, extracts and stores in it: LIR customer id request size in num of IP addresses request category: ?? status: ?? IPMT informs LIR Hostmaster if parse fails F5: Check request valid and I1.5: Deny or I1.6 if not ?? IPMT checks 'LIR Customer request' record ?? I1.3 if more info needed OK ?? IPMT sets 'checked' flag F6: Check LIR customer valid and I1.5: Deny or I1.6 if not IPMT looks up LIR customer info ?? LIR customer info stored in a DB ?? 'LIR customer' record LIR customer id customer email addresses and other contact info. request ids of previous requests total space size of assignments - enough info to make Whois DB person object ? IPMT informs LIR Hostmaster if customer not valid I1.3: LIRHostmaster queries LIRCustomer about request F7: Get more info from LIR customer regarding request ?? LIR Hostmaster uses IPMT to compose and send email to LIR customer ?? LIR customer reply automatically added to 'customer request' record or LIRH can use IPMT to do this ( e.g. : enter phone conversation ) ?? IPMT 'action needed' button to show customer reply received F8: update request info LIR Hostmaster updates 'customer' and 'customer request' records F9: -> I1.2: Evaluate I1.4: LIRHostmaster actions request F11: Need to ask RIPE to perform request ? -> I2 if so IPMT Check LIR Assignment window vs size of request - force insert of NCC# ticket number of approval if it's needed - need access to LIR Assignment window reports to LIR Hostmaster F12: Check request IPMT examines request record vs customer and LIR assignment and allocation records ?? assignment records - in whois ??: - or IPMT stores this locally - or LIR's records ?? via defined API ?? ipv4 range - IPMT makes _suggestion_ - allow choice of methods by config file as debatable - what methods are there ? netname - IPMT makes _suggestion_ ?? allocation records - in whois ??: - or IPMT stores this locally - or LIR's own records ?? via defined API ?? ipv4 range F13: Update request info ?? IPMT generates assignment addresses from 'customer request' record and assignment and allocation records LIR Hostmaster agrees or alters assignment addresses F14: Check other info concerning assignments - too varied so LIR to implement - IPMT provides I4,5,6 to allow LIRH access to info it has ?? LIR workflow stats ?? LIR Hostmaster stats ?? LIR infrastructure updates ?? LIR customer billing F15: Update other info based on request IPMT stores assignment addresses in 'customer request' record I1.5: LIRHostmaster informs LIRCustomer of request outcome F16: Communicate request outcome and info to customer LIR Hostmaster uses IPMT to compose and send email to customer Update 'customer request' record I2: LIR Assignment Request: An LIR asks the RIPE NCC for approval of an IPV4 Address assignment and the RIPE NCC replies. I2.1: LIRHostmaster formulates query F20: LIRH uses IPMT to produce a filled-out 141 Form. Gets data from customer, request and assignment records I2.2: LIRHostmaster sends request to NCC F21: Send request to RIPE-NCC by e-mail I2.3: LIRHostmaster handles response F22: Check response of RIPE-NCC and resent request if necessary -> repeat F20 I2.4: LIRHostmaster completes request F23: Update customer, request and assignment records. I3: LIR Allocation Request: An LIR asks the RIPE NCC for an IPV4 Address allocation and the RIPE NCC replies. I3.1: LIRHostmaster formulates query F30: Gets data from assignment and allocation records and fills out pro-forma request to RIPE-NCC. I3.2: LIRHostmaster sends request to NCC F31: Send request by e-mail. I3.3: LIRHostmaster handles response F32: Check response of RIPE-NCC and resent request if necessary -> repeat F30 I3.4: LIRHostmaster completes request F33: Update assignment and allocation records

1 0