February 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

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

Management of the working group
by Hans Petter Holen 04 Apr '01

04 Apr '01

Dear lir-wg, as just expressed at the wg meeting, I think it is appropriate to suggest some formalities for the wg to elect its chairs. My proposal is as following: 1) Open nominations on the lir-wg mailinglist 2) Optional discussion and support statements 3) Election of chair and 1-2 co chairs at the next lir-wg meeting in Bologna. 3b) The election to be performed either open ballot or by secret ballot if demanded by one or more participants at the meeting 3c) The election to be confirmed by consensus by the wg after the election result have been duly counted by a counting team from the audience. 4) That we perform such an election annualy to ensure the community support to the wg chairs. As the meeting expressed support towards such an idea, I would like to hear the opinions of the wg on theese matters before proceeding. Sincerely, Hans Petter Holen lir-wg Chair

6 10

Re: IP Management Tool - Minimum Requirements
by Guy Vegoda 06 Mar '01

06 Mar '01

> Would there not be intellectual property difficulties if you > wrote a similar system for another company? > > Niall > > (Interested but also enmeshed in IP problems) I guess that depends on how similar you mean by similar (-: I don't think IPMT will be anything like Robo-Bijal, code-wise. (Not least because: (1) I will not be the only coder, (2) Manuel's IP libraries are open source, (3) It will probably support IPv6, which Robo-Bijal doesn't, and (4) I would like to do it in OO perl. ) So should hopefully all work out. Guy -- Guy Vegoda \ guy(a)vegoda.org *Please do not send html* NIC: GUY-RIPE \ guy(a)cryptography.org.uk *attachments* Unix, Linux Hobbyist \ +44(0)20 7961 8318 (work) www.thenakedfrenchman.com \ +44(0)958 469 532 (cell)

2 1

Re: Refuse een assignment because it 'cannot' be routed?
by Wilfried Woeber, UniVie/ACOnet 05 Mar '01

05 Mar '01

To continue that (cute | silly | pick-your-choice) analogy... => I only want a fixed frontdoor (1 fixed IP address), but I am trying to force => my landlord into letting me have it without paying tripple rent, by asking => the government (RIPE) to give me a building permission to install more => doors. Not because I want more doors, but to keep the landlord from moving => my single door every day :) => = =Hi, = = Hmm... this analogy isn't correct. RIPE is not the government in this. =RIPE, or your local LIR can give you a door (address assignment), but =you still need to get a permit from the local counsil to place it =(Getting your service provider to actually route it). = =One of the things your local LIR may require before selling you a door =is having a permit. Buying the door somewhere else (RIPE) does not =automagically entitle you to a permit. ...what we are seeing in reality, though, is something like the "government" (the RIPE NCC) coming back with a question about the colour and style of the door. And - depending on your answer - either going ahead issuing a _permanent_ permit for e.g. an Ethernet- or leased-line-style door ("static"), but limiting the validity of the permit for an xDSL- style or dial-up door to as long as you, or someone from your family, happens stay at home ("dynamic"). As soon as you go to work, or even worse - take a couple of days off, duhh!!! - you have to submit another application for installing a door. And, the "government", suggests to the manufaturers of the doors (and/or to the landlord), to give you a call on the phone every, say, 8 hours, to confirm that you haven't left for shopping (physicly) or turned to RTFM (virtually/mentally logging off). That's exactly what happens to me, back home, with my ADSL link being dropped every 8 hours by the ISP *on purpose*, because the NCC sort of "suggests" to the ISPs to use dial-up ratio mechanisms for 24x7 xDSL, flat rate billing. Very clever, indeed, in particular when someone tries to do stuff that is security-aware. But I have beaten that one to death before (technology independence of assignment rules). Sigh... 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Träume darf man nicht verbieten, sonst werden sie Wirklichkeit...

3 3

Refuse een assignment because it 'cannot' be routed?
by Herbert Baerten 02 Mar '01

02 Mar '01

Dear colleagues, in the discussion about assigning fixed address space to residential always-on customers, I concluded that most ISPs are eager to provide their customers with this service, even using it as a weapon in the competition battle. However in some countries apparently the contrary is going on. All ISPs there offer 2 classes of DSL service: cheap subscriptions (low traffic, dynamic ip, no options) on one hand and an expensive 'pro' contract (high traffic volume, static ip, router etc.) on the other. Now a customer would like to get a static ip but does not want the router, large volume etc so he does not want to pay 4 times as much per month (real-life example) just to get a static ip. If the customers sends a RIPE-141 request to the ISP, can the ISP assign a range but not route it to the customer? Can it refuse the request on the grounds that it cannot route the assigned range to a dynamic ip? Or is the ISP obliged to assign a range and route it (no matter how, presumably by assigning the customer a static ip anyway) ? With or without additional (reasonable?) cost to the customer? tia best regards, Herbert -- HB5351 Herbert Baerten Network Manager HostIT Benelux

4 7

LIR Charging Publications
by Roberto Pezzile 28 Feb '01

28 Feb '01

Hello to all colleagues, I am Roberto Pezzile, network and telecommunications manager of Seven, in Castelfranco Veneto, Italy. We have recently become a new LIR. In the documentation given, I have a few questions regarding the publication of "Charging by Local Internet Registries" - precisely, ripe-152.txt; where "5. Recommendations" urges all registries to publish operating procedures, service details,and relative charges. In my working experience, mostly in Italy, but occasionally in the US, Brasil, Germany, France and China, I have never seen such Charging Information published at all, by anyone. Perhaps I've missed something somewhere. Even reference documents ripe-104 and ripe-112 did not offer additional information . I would like to know: 1. Is there a form to fill out and send to RIPE for eventual publication ? 2. Is there another LIR in our area which can show us an example of their charging policies and procedures ? 3. What is intended by ".....achieving consensus within the community served regarding the disposal of any surplus revenues"? I look forward to receiving information on the above, based on the practical working experiences of those kind enough to give me a hand. Thankyou very much Roberto

1 0

Re: Refuse een assignment because it 'cannot' be routed?
by Wilfried Woeber, UniVie/ACOnet 27 Feb '01

27 Feb '01

> > >> Now a customer would like to get a static ip but does not want > > ONE static IP address? PA, I assume? > > Yes, PA. > > > > >> If the customers sends a RIPE-141 request to the ISP, can the > > ISP assign a > > >> range but not route it to the customer? I guess, formally, the answer is YES. Because when the customer can document his/her need, then the LIR *may* assign addresses But, holding a block of addresses does not in any way "guarantee" connectivity... > > > > ... which would be extremely useful for ??? routing can be very different things: - distribute the announcement for that address space only within the ISPs IGP - distribute the announcement to direct EGP peers, but with "no-propagate", i.e. for providing access to a particaular server, or to suppoort dual-homing/mutual backup - make the address block (potentially) visible from "everywhere", by announcing the encopmpassing aggregate and/or the particular (more specific) prefix. The usefulness is subject to effects of aggregation and filtering - ... > In order to force the customer to buy a more expensive service which > includes fixed ip! Formally, definition of prodcut packages and charging for services is outside the scope of the rules for address assignment - with the exception that the address space itself must not be sold. > Please understand that nor I nor my employer is doing this or even > advocating this practice. To the contrary: I'm just observing that it > happens and am so displeased about this that I am looking for ways to > counter it. As I said in a different thread, this should be discussed in the frame-work of a BCP, either within RIPE or somewhere else. We might also want to leave it to competition to eventually deal with that (don't hold your breath ;-) > > >> Can it refuse the request on the grounds that it cannot route > > the assigned > > >> range to a dynamic ip? > > > > ... so, you want to rent a house and put a security guard on the entrance > > door not allowing people who bought it to move in. Interesting ... > > I think it is more appropriate to state that someone is looking for a house > but all landlords he meets will move his front door every day unless he pays > tripple rent. > > I suppose the question can be phrased more theoretically as: > > "If a LIR is obliged to assign address space (is it?), No, it is not. An IPS's LIR may have very good reasons (financial, security, AUP...) *not* to assign addresses to an entity wanting to become connected and obtain services, and even become a customer :-) > wouldn't it make > sense to oblige a provider to route it" No. That's what contracts are invented for, either implicitely by subscribing to a service or explicitely by negotiating ToS/QoS. > or the other way'round: > > "If an address space request is made, is the non-willingness of an ISP to > route it sufficient grounds to deny the request?" I think so. Unless there are other valid reasons for an LIR to perform an address assignment for a customer or peer (i.e. PI space, that is *not* accepted by the IPSs routing layer, but may be used on other links of the customer). > > Well, there is no formal policy obligation for you to route the addresses > > you assigned, but what would those addresses then be good for? > > That's the point. Can the customer somehow (e.g. by submitting a ripe-141) > force the ISP to assign him a static ip address? Or will it get him nowhere? It depends what the definition of "customer" looks like in that case. When the ISP does offer a package that includes the privilege to obtain service from the ISP's LIR, then the customer can probably (try to) use force (legal measures or refusing to pay fees). Trying to throw a 141 form at some free dial-in service provider would probably "get you nowhere" :-) But in general I would try to find a different ISP... ______________________________________________________________________ =Hi, = = This is a very interesting problem. = = As far as I am aware there is no obligation to assign IP space =when someone becomes a customer of an entity served by a LIR. Again, I share this view. = Possible problems when submitting a RIPE-141 document: = =- There is no obligation to process the request True =- The LIR may charge for processing the request True =- The LIR may charge for the assignment Not really. This is seen as "selling" addresses! =- The provider may charge for the routing True = You could opt to ask RIPE for a PI allocation, You could find an LIR that is willing to process PI requests, either for a charge or for free, or you can build your own LIR ;-) =but noone is required to route it for you. True, and for both, PI *and* PA =Regards, = =- marcel Regards, Wilfried.

2 1

IPv6 representation in perl
by Guy Vegoda 26 Feb '01

26 Feb '01

On an entirely different point, I would like to start a separate thread about the best way to represent IPv6 numbers in Perl. I have the following thoughts. Possible ways may be: (1) Using a 128 element binary array, and writing all the binary maths yourself to manipulate that. (2) Using a 4 element array storing four hex characters from 0 to F. Probably far slower than the above method, but smaller for storing many IPs. I know that Perl can natively think in hex, so maybe it would be faster than I think. (3) Having a complex structure, where the IP number is stored in parts - the top /48 (in any of several formats), with variable structure subnets underneath that. Could be tricky for the maths, if the variable bits are badly thought out. (4) Storing four "IPv4-esque" decimal strings in an array, or as part of an object. Then do the maths on each of those separately. Probably fast. (5) Storing a single parant /48 object (in any format) and have child objects with only the bottom parts of the IP to worry about. I wonder how that would work. -------- When I have gone away and read more of Mastering Algorithms with Perl, I will come back and maybe make some more comments. Just as a disclaimer - I am in no way making any comments on Manuel's already excellent libraries. I have already spoken to him about them, and would not want to appear to "go behind his back". This is an entirely intellectual exercise only. In fact, I would very much like to see Manuel post his own thoughts and real world experiences on the subject (of which I have none). I wish every one well, Guy -- Guy Vegoda \ guy(a)vegoda.org *Please do not send html* NIC: GUY-RIPE \ guy(a)cryptography.org.uk *attachments* Unix, Linux Hobbyist \ +44(0)20 7961 8318 (work) www.thenakedfrenchman.com \ +44(0)958 469 532 (cell)

2 1

Re: IP Management Tool - Minimum Requirements
by 'guy＠sirius-cybernetics-corporation.com' 26 Feb '01

26 Feb '01

> Yes I know about asused. It is a good tool for determining overlap > status or some missing attributes/contact informations and to get some > statistical information. I think it will be usefull to access asused from > IPMT. But my main concern was also whether we can find such a > criteria/metric that can be used both RIR's and LIR's ? Here are some > metrics I have thought; > > - Possible largest allocation left in the totall allocation of LIR > - How fragmented the allocation space (may be mapped to above one) > - How summarizable are the address space assigned to a customer. > - How summarizable are total allocations ? > > > Summarizability issues seem to conflict with RIR policies. However > I think that it is a fact of routing world. > > Regards > arif I do not think there is anything wrong with detailed reporting. I think that maybe the program needs a specification before we can really use metrics to measure anything. I too would like to see IPMT eventually give verbose output on the state of the registry. However, will this not to some extent duplicate functionality of programs such as asused-public that already exist? Please clarify what you would like, because I think I am still confused. I think that Maldwyn's comments would be useful here. Guy -- Guy Vegoda \ guy(a)vegoda.org *Please do not send html* NIC: GUY-RIPE \ guy(a)cryptography.org.uk *attachments* Unix, Linux Hobbyist \ +44(0)20 7961 8318 (work) www.thenakedfrenchman.com \ +44(0)958 469 532 (cell)

1 0

RE: IP Management Tool - Minimum Requirements
by Arif OKTAY 26 Feb '01

26 Feb '01

Hi all, I was thinking whether it may be possible -usefull ?- to add some criteria for how succesfull the adress space managed. Regards, arif ao189-ripe -----Original Message----- From: Guy Vegoda To: lir-wg(a)ripe.net Sent: 2/26/01 1:50 PM Subject: Re: IP Management Tool - Minimum Requirements Other than adding that it should be useable simulteniously by multiple users without data corruption, shall I go away and write it now? Guy (Since no one else seems interested) > 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/ > > -- Guy Vegoda \ guy(a)vegoda.org *Please do not send html* NIC: GUY-RIPE \ guy(a)cryptography.org.uk *attachments* Unix, Linux Hobbyist \ +44(0)20 7961 8318 (work) www.thenakedfrenchman.com \ +44(0)958 469 532 (cell)

2 1

IP Management Tool - Minimum Requirements
by Maldwyn Morris 26 Feb '01

26 Feb '01

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

Re: Fixed Boundary (/29) Assignments
by Judith Heffernan 18 Feb '01

18 Feb '01

As an employee of a large broadband provider, I agree with the recommendation of allowing ISPs the ability to provide residential subscribers multiple IP addresses without having the subscriber provide usage-based requirements. It doesn't scale to extend the rules that apply to commercial end users to residential subscribers. This would be equivalent to a tier 1 ISP having to manage the justification of IP address requests of 3million tier 2 ISPs. It doesn't scale. The subscriber should not just be assigned /29 worth of address space when they sign up for the service whether they need it or not. However, if the subscriber sign's up for the service requesting 2 or 3 CPE addresses, they shouldn't have to submit a RIPE-141 form or provide some other justification. It should simply be a service that the ISP can provide. We have many subscribers with multiple CPE addresses - however, that doesn't necessarily mean they have their own subnet. In a broadband cable environment, the subscribers off of the same downstream shares the same broadcast domain. The downstream is assign /24 which the subscribers are addressed out of. A subscriber with two CPE's may not have consecutive IP addresses. Would this mean the subscriber would have to register each /32? Or that the ISP has to ensure that the subscriber gets consecutive addresses (that would be a huge operational overhead for the ISP). The ISP should be responsible of ensuring the /24 is being effectively utilized. And this can be done the same way it is today for one CPE as it can for multiple. -Judith

2 1

RIPE: last call for comments RPSL transition
by SchmitzJo＠aol.com 17 Feb '01

17 Feb '01

Hello all, as you are aware, we are preparing the migration of the RIPE database software to support and deploy the new RPSL format. The required steps have been discussed in depth on various occassions (for references, see end of mail). We are now preparing the most important step, really transitioning from old RIPE-181 to new RPSL format: proposed transition date is 23-Apr-2001. This step, once taken, will not be reversed. The majority of the user community takes a neutral role, while some want an earlier, and a few a later date for migration. During the joint session of Routing and DB WG at RIPE38, the chairmen of both WGs were tasked to file a last call for comments on that date, in particular whether there are serious, unresolvable technical or operational problems which would benefit from a slightly longer warning period. According to consensus at the session: If you are convinced that the transition date as proposed would lead to significant operational problems, please explain and justify why within the next 2 weeks: deadline for transition comments: 1-Mar-2001 Only well founded reasoning (including an educated guess about the time and resources required to resolve the issue) shall be accepted by the community in order to consider postponing the transition. With the discussion about the migration going on for quite some time, and information available from various places, we do not expect a delay, but we would want to give everybody a last opportunity to comment. To summarize the dates, we are looking at: o 23-Apr-2001: switching to the RPSL database - All objects are automatically converted to RPSL format - Queries return RPSL only - Mirroring follows new format and rules at whois.ripe.net, port 4444 - RPSL formatted updates can be submitted to auto-rpsl(a)ripe.net - RIPE-181 updates are still accepted at auto-dbm(a)ripe.net, but are autmatically converted to RPSL - RFC2725 (Routing Policy Security System) rules apply throughout o 14-May-2001: exchanging mail addresses for submitting RIPE181 and RPSL- formatted updates - auto-dbm(a)ripe.net only accepts RPSL updates - RIPE-181 updates are still possible but now go to auto-181(a)ripe.net and are automatically converted to RPSL (again, RFC2725 rules apply here as well) o 15-Oct-2001: RIPE-181 updates are no longer accepted For further reading, please refer to the migration web page http://www.ripe.net/rpsl or for the discussion during the joint session of the DB/Routing WGs please review the minutes. For technical specifications of RPSL please refer to - rfc2622: "Routing Policy Specification Language (RPSL)" Status: PROPOSED STANDARD, - rfc2650: "Using RPSL in Practice" Status: INFORMATIONAL - rfc2725: "Routing Policy System Security" Status: PROPOSED STANDARD Thanks a lot - the RIPE NCC and the chairmen of Routing: Joachim Schmitz DB: Wilfried Woeber LIR: Hans Peter Holen

1 0

SV: Fixed Boundary (/29) Assignments
by Bjarne Carlsen 13 Feb '01

13 Feb '01

> -----Oprindelig meddelelse----- > Fra: Randy Bush [SMTP:randy@psg.com] > Sendt: 9. februar 2001 15:16 > Til: Bjarne Carlsen > Cc: lir-wg(a)ripe.net > Emne: RE: Fixed Boundary (/29) Assignments > > are we? we see folk using dsl at t1 rates to replace p2p t1 lines because > it's a very different cost for the circuit. (here, t1 is expensive and > dsl > is based on old alarm circuit tarrifs) [Bjarne Carlsen] OK - in other words, you don't even see the small difference, that I see on this side of the pond.. > just to push this to the limit. in the states, we usually have free local > dialup. so we have analog "nail up" customers, i.e. they stay dialed up > 7x24. it's just another form of p2p dedicated circuit. and, as far as > address allocation policy goes, treat them the same as an OC12 customer, > they justify what address space they need. [Bjarne Carlsen] Yes, but make it somehow easier for them, since there is one significant difference between private an corporate customers, (at least as seen from this little backwater), namely that the corporate customer usually understands the technical jargon used in documents like RIPE-141 and the private customer invariably says "Huh, er... what is an IP-address??" /Bjarne

8 8

Re: Policy and PR problem
by Marco Davids 13 Feb '01

13 Feb '01

On Tue, 13 Feb 2001, Hans Petter Holen wrote: > -"it is currently very difficult to get IP address space" and as a result of > that we have to plan complex network solutions with a combination of private > and public addresses. > > This claim is very different from the one I tend to make: "you get the > addresses you need as long as you can provide documentation that you realy > need them". I agree with that, although I use to have a hard time convincing my manager to come up with copy's of invoice and all kinds of other 'strategic' information to proof to RIPE that we really needed the IP-space that was required by that time. I wonder what RIPE does with all this information? I trust they destroy it, after the IP-request has been approved? And how about returning IP-space? The procedures there are not very clear to me (except for the case when the LIR does not pay its fee). Can allocated address-blocks for example be transferred to another party without mediation of RIPE after a merge of company's or something of that kind? Cheers, -- Marco

1 0

Re: Policy and PR problem
by Marco Davids 13 Feb '01

13 Feb '01

On Tue, 13 Feb 2001, Hans Petter Holen wrote: > -"it is currently very difficult to get IP address space" and as a result of > that we have to plan complex network solutions with a combination of private > and public addresses. > > This claim is very different from the one I tend to make: "you get the > addresses you need as long as you can provide documentation that you realy > need them". I agree with that, although I use to have a hard time convincing my manager to come up with copy's of invoice and all kinds of other 'strategic' information to proof to RIPE that we really needed the IP-space that was required by that time. I wonder what RIPE does with all this information? I trust they destroy it, after the IP-request has been approved? And how about returning IP-space? The procedures there are not very clear to me (except for the case when the LIR does not pay its fee). Can allocated address-blocks for example be transferred to another party without mediation of RIPE after a merge of company's or something of that kind? Cheers, -- Marco

2 1

Re: Policy and PR problem
by Wilfried Woeber, UniVie/ACOnet 13 Feb '01

13 Feb '01

Hi Nurani, Thanks for your comments, and I agree that your "the Hostmaster Role's" point of view is of interest of course, eventually, but that the community still has to do a bit more thinking and brain-storming before we can wrap up. >However, what I can say is that we at the RIPE NCC are very aware of >how complicated it is for new LIRs to learn all policies and >procedures involved in obtaining IP address space and AS numbers. >(And indeed there are quite a few.) One of the things that adds to complexity (IMHO) is the fact that the policies (you have to make your needs known, and to do so in a way that can be reviewed) are not clearly separated from the procedures involved. While I think the basic *policy* is more or less straightforward: You get what you need and as much as you can reasonably argue for, and we don't interfere with the engineering approach for your networks by making *policy* that cripples certain design approaches. (With a very few exceptions) We do, however require the applicant to think about alternative approaches, and to make a conscious decision in favour of one or another approach, like rfc1918, http 1.1, ... What indeed has become too complex is the *procedures*. What has been appropriate a few years ago, is not necessarily appropriate any longer for every application everywhere. The Internet has changed a bit. There are more diverse entities active now which have to look at some other boundary conditions in addition to network engineering and address space conservation (as the "only" goal) like size, internal structure, business models, investments, security, helpdesk and customer care issues, and last but not least privacy issues.... >Although it has always been seen as part of the hostmaster role to >educate the LIRs, it is not an easy task with the current dramatic >growth of LIRs. We have partly discussed this with the May 17 >Taskforce and we are also constantly discussing it internally at the >RIPE NCC, trying to find more efficient ways of coping with the >workload and the growth. Indeed. >This may be a PR problem. It is also possible that the policies >simply have become too complicated for new members. (Can it be that >the policies which are developed by experienced and clueful members >of the Internet community is not necessarily easy for newer, less >experienced LIRs?) Is the problem possibly a combination of the two? We should put the effort in dealing with the scaling problem of the *procedures*. While I do not know (and do not want to know) which application made Leo "go public", I would like to report to the community that I had a few very interesting private discussions during the last RIPE Meeting with a sizable company planning the roll-out of a "mass-market" product, and they indeed were a) present at the meeting, and b) had *very* sound questions to ask and were looking for input from the community. So "they" are out there, trying to do "the right thing". But the community should try to understand their position as well, and the scaling problems. Otherwise nobody should be surprised to hear the claims, that it is not possible for them to work with and as part of the "established" community, and that "they" have to build something else that fits their needs.... Wilfried.

1 0

Policy and PR problem
by Hans Petter Holen 13 Feb '01

13 Feb '01

Hi, I am just attending a seminar in Broad band networks, and met again the claim that -"it is currently very difficult to get IP address space" and as a result of that we have to plan complex network solutions with a combination of private and public addresses. This claim is very different from the one I tend to make: "you get the addresses you need as long as you can provide documentation that you realy need them". personally I think that we have a serious PR problem here: is it so that the rules and regulations have become so strict and complicated that we, the lirs, tell our customers that this is very difficult and you should realy use private addresses, rather than explaining how the procedures and policies realy work ? Is this what we want ? -hph

6 6

Re: Policy and PR problem
by Denesh Bhabuta 13 Feb '01

13 Feb '01

At 10:27 13/02/2001, Hans Petter Holen wrote: >personally I think that we have a serious PR problem here: is it so that the >rules and regulations have become so strict and complicated that we, the >lirs, tell our customers that this is very difficult and you should realy >use private addresses, rather than explaining how the procedures and >policies realy work ? IMHO, the main problem seems to be clueless salesmen who do not understand RIPEs procedures, and the clueless product managers who will go and design a solution without knowing what procedures they have to follow or restrictions they have when it comes to IP addresses. This leaves the poor hostmaster trying to explain to the company that it can not do what it wants to do and by then it is almost too late.. advertising etc is all done. What may be worth doing is getting 'salesmen' to go to RIPE training courses - as it is these people who talk to customers directly for that signature on the contract. :) What we need to realise is how companies in this industry conduct business nowadays.. (I am not including those companies who have followed the RIPE rules from time immemorial). I have also already spoken to Axel about RIPE maybe looking at an Outreach program (something that Nominet - the .uk not for profit registry - is doing now)... this will be good for PR. The other aspect I have briefly spoken to Axel about and also to Margriet is how to make the new LIR sign up process less administratively heavy. I am not saying that we change the RIPE NCC we have all come to love over the years.. just that we need to be aware of business in this industry and the way it is going. Regards Denesh -- Denesh Bhabuta Chairman, CEO and Principal Consultant Cyberstrider Limited www.cyberstrider.net Internet and E-Commerce: Strategy, Consultancy and Solutions

1 0

RE: Policy and PR problem
by mike.norris＠heanet.ie 13 Feb '01

13 Feb '01

> I am just attending a seminar in Broad band networks, and met again the > claim that > > -"it is currently very difficult to get IP address space" and as a result of > that we have to plan complex network solutions with a combination of private > and public addresses. This might be true if the words "For those who don't take the trouble to understand and follow the agreed procedures," were inserted at the start of the sentence. > > This claim is very different from the one I tend to make: "you get the > addresses you need as long as you can provide documentation that you realy > need them". This is my experience and my expectation of RIPE NCC. > > personally I think that we have a serious PR problem here: is it so that the > rules and regulations have become so strict and complicated that we, the > lirs, tell our customers that this is very difficult and you should realy > use private addresses, rather than explaining how the procedures and > policies realy work ? > > Is this what we want ? You're right, we do need to get the positive message across. RIPE NCC, and RIPE representatives such as yourself, Peter, have been doing this at various levels, and I think the effort is increasing. Perhaps we need to direct some attention to the more popular media, to explain the importance, the function and the challenges of address registration in the European Internet. Regards. Mike

1 0

1. draft minutes of joint Routing/DB wg session RIPE38
by SchmitzJo＠aol.com 13 Feb '01

13 Feb '01

R I P E 3 8 A M S T E R D A M Joint Session DB and Routing 24-Jan-2001 Draft Minutes Chairs: Joachim Schmitz, Wilfried Woeber Scribe: Engin Gunduz Participants: 97 Joint Session of Routing and Database Working Groups Due to the importance of the subject, and the overlap in topic, the chairmen of Routing and Database WG (Wilfried Woeber) decided to have a joint session of both WGs. Joachim introduced the audience to the session, and chaired it together with Wilfried. E. Migration to the new RIPE database (Andrei Robachevsky, RIPE NCC) (20min) [ The presentatino is available at http://www.ripe.net/ripe/meetings/archive/ripe-38/presentations/r38-reimp-a… ei/index.html ] Andrei gave an overview of what to expect for the migration to the new RIPE database. He began with asking who would be affected by the migration, and the answer is: everybody. Reasons are - RPSL format - new access control - new database format - new version mirroring protocol He supported this by a set of examples, and made suggestions on how to prepare for the migration, depending on which usage group a database user belongs to - query users - update users - adaptation of scripts - near real time mirroring Following that a schedule was presented which summarized the proposed final transition dates - 23-Apr-2001: switching to the RPSL database Queries return RPSL only Mirroring follows new format and rules at whois.ripe.net, port 4444 RPSL updates go to auto-rpsl(a)ripe.net RIPE-181 updates are still possible and still go to auto-dbm(a)ripe.net, but are autmatically converted to RPSL - 14-May-2001: exchanging mail addresses auto-dbm(a)ripe.net only accepts RPSL updates RIPE-181 updates are still possible but now go to auto-181(a)ripe.net and are automatically converted to RPSL - 15-Oct-2001: RIPE-181 updates are no longer possible The crucial date is the first one. It will not be possible to go back after that date. The RIPE NCC has prepared a vast set of aides to assist in the transition, and to get used to RPSL format. All details are available at the RIPE-181 to RPSL transition web page http://www.ripe.net/rpsl The presentation led to a vivid discussion, in particular whether the first transition date is too early or too late. Ping Lu was suggesting to move the dates further into the future because - they are using a lot of off-line tools - the downstreams need to be educated He later explains that he himself would transition rather earlier than later but he is worried about their vast customer base. Joachim pointed out that the transition should not be delayed because RADB is already running RPSL since quite some time, making it more complicated for people using both RADB and RIPE. Moreover, he thought that someone had written some tool to perform at least in part some back conversion from RPSL to RIPE-181, which as Wilfried Woeber pointed out would only be possible for a limited number of objects. However, such tool never was available. Christan Panigl reminded the audience that the idea had come up to supply a RAToolSet tutorial at the next RIPE meeting. He suggested to run it before the transition to the RPSL database, essentially before 23-Apr. The audience wants to have this tutorial parallel to the next RIPE meeting. However, this would delay the first transition date into May. A quick poll showed that 10 people in the audience knew RAToolSet, and that actually 2 were using it in conjunction with RADB. It obviously makes sense to have a tutorial -> action 38.R1 on Wilfried Woeber and Joachim Schmitz to organize a RAToolSet tutorial at the RIPE39 meeting Ruediger Volk points out that a transition very shortly after the tutorial does not make much sense. He also stresses that he objects against postponing the transition, because other transition projects within his company have already been delayed due to the not yet factual transition with RIPE. Jake Khuon agrees with Ruediger. He also points out that many of the objects are doubly registered both in RADB and RIPE. Joachim asked the audience who of them are actually using any kind of automated tools in conjunction with the database, and it turned out that these were more or less the same people who also knew RAToolSet. Accordingly, most of the people requesting a tutorial on RAToolSet do not need it right now and are thus also not affected for automation. This decouples the dates of when the tutorial will be held, and the transition to RPSL. Consequently, even though these are only proposed dates, Wilfried suggests to stick to these dates, and people who think that they have real technical problems must speak up to the community to have those reviewed. -> action 38.R2 on Wilfried Woeber and Joachim Schmitz to send around the transition dates, get input from the community, with a following decision on the dates Ping Lu thinking of interaction of databases then brings up the topic of global NIC handles. Wilfried explains that globally unique NIC handles are not related to RPSL, or the transition to RPSL. He has it on his agenda for the Database WG session tomorrow (25-Jan). F. Report from the DB migration task force (Wilfried Woeber, Andrei Robachevsky) Wilfried reported that the DB migration task force did a review and besides a set of questions identified by some active members of the user community, the following open issues were identified - Outreach The RIPE NCC has taken every effort to notify all parties repeatedly who will be affected by the transition. Disappointingly, the feedback on these efforts has been small. - Other items are * broken PGP keys * unprotected aut-num objects * object names not compliant with RPSL which were discussed in a short presentation by Andrei Andrei gave a few statistics on those items, first on their efforts to contact parties which need to be involved, and then on the open issues where Joao Damas explained the proposed solutions. - Broken PGP keys The old PGP programs generated non-compliant PGP keys. Those keys will be refused by version 3 software. It turns out that 7 out of 409 PGP keys are broken. The proposed solution is to delete the key certificates. This does not affect security for a simple reason: If someone wants to apply a change to objects protected that way, the software does not find the corresponding key certificate, and thus rejects the update. The party who wants to submit the change will then be required to contact the RIPE NCC. It was general consensus in the audience to follow that approach. - Unprotected aut-num objects In the past, it had become mandatory to have aut-num objects protected by a maintainer. However, 119 out of 4008 aut-num objects still today do not have a mnt-by attribute. So far, they enjoy a "special" protection: Only ripe-dbm can modify them. Surprisingly, none of them was ever touched in all the time since the original change of requirements. It is still mandatory to have a maintainer with each aut-num object in RPSL. The question is of how to proceed. The proposed solution is to add a special RIPE NCC maintainer. By that way, no security breach is opened, and no change compared to the situation today is introduced. If anybody ever wants to touch that aut-num object again, they still need to contact ripe-dbm. It was general consensus in the audience to follow that approach. - Reserved RPSL names Quite a lot of objects in the database have names which do not comply with RPSL rules. An example are 108 aut-num objects using the reserved prefix "AS-" in the AS-name attribute, or 7 maintainer objects with other reserved prefixes. The proposed solution is to change the names prior to transition in a way which still needs to be agreed upon. A suggestion is to contact all parties who own those objects, and also publish them on appropriate RIPE mailing lists. It was general consensus in the audience to follow that approach. Those results were taken to the Database WG. Ping Lu raised the question whether there was the intention to implement global maintainers. Andrei explained that so far all references must be resolved locally. Andrei also showed which OSs are currently supported for the database software o Solaris 2.8 (Intel & Sparc) o Linux (RedHat, SuSe). o FreeBSD The inquiry from Wilfried showed that this list is accepted by everybody, and no other OSs seem to be used by any company of registry, meaning from that side no problems are expected. Wilfried asked the NCC to release the database software for all platforms without putting too much effort into performance tweaking for each individual OS, just assuring its overall functionality. Anybody who wants to participate in the transition discussion is free to join the migration task force mailing list reimp-mig-tf(a)ripe.net Summary of Open Action Points from the Joint Session of DB and Routing 38.R1 on J.Schmitz, W.Woeber Organize RaToolSet tutorial at RIPE 39 status: new 38.R2 on J.Schmitz, W.Woeber Collect final community input on DB migration dates status: new Engin Gunduz, Joachim Schmitz, February 2001

3 3

Fixed Boundary (/29) Assignments
by leo vegoda 12 Feb '01

12 Feb '01

Dear all, In my presentation to the Working Group at RIPE 38 [0] I brought up the issue of assignment policies for ISPs wanting to assign all customers a fixed size network (/29). The RIPE NCC is experiencing an increase of requests for this type of setup and would therefore like the community's input on this matter. There is no specific mention of broadband connections or fixed-boundary assignments in the current policy. However, we believe that the policy now requires LIRs to make assignments on the usage-based requirements of the subscriber. This is consistent with the RIRs' goal of conservation. The method of assigning a standard prefix size is certainly quite wasteful as one quarter of the space is lost on network and broadcast addresses. The requester justification for this assignment method is an estimation of the number of customers taking IP based services or having multiple Internet connected terminals at home. As a reference, it may be worth noting that in recent discussions on the IETF mailing list, Bernard Aboba estimates [1] that currently 27% of homes have multiple 'PCs'. It is difficult to predict the take-up of non-Internet IP-based services. Based on the above, we would like the Working Group to consider whether: - a standard, fixed-boundary assignment is acceptable for residential broadband connections? Or - should the requester (the LIR) be required to ask the subscriber how many IP devices will be connected and base the assignment upon this? Regards, leo vegoda RIPE NCC Hostmaster [0] http://www.ripe.int/ripe/wg/lir/present/ [1] http://www.ietf.org/mail-archive/ietf/Current/msg10586.html

19 23

RE: Fixed Boundary (/29) Assignments
by Bjarne Carlsen 12 Feb '01

12 Feb '01

> -----Oprindelig meddelelse----- > Fra: Hans Petter Holen [SMTP:hph@online.no] > Sendt: 8. februar 2001 23:15 > Til: lir-wg(a)ripe.net > Emne: Re: Fixed Boundary (/29) Assignments > > > > > why is dsl different, from an address allocation view, than e1, flame > delay, > > point2point, etc. it's just the layer 1 point-to-point technology used > for > > provisioning an end site. > > In my oppinion it is not at should not be different. But what is different > is that we > are rolling out mass marked "always on" products in a larger scale than we > have > seen before. [Bjarne Carlsen] But what is different about it? It is - as Randy said - just the layer 1 point-to-point technology used for provisioning an end site (blatant cut'n paste here). The only real difference from "the good old days" that I can see, is that we are dealing with customers as single persons/families with lesser need for address space instead of companies with comparatively greater needs. > What I don't think the poicies should do is to prevent products like home > lans. > I dont think policies should force providers or the customers to use NAT. [Bjarne Carlsen] I agree, but I still think that the customers should be required by policy to somehow justify their needs for addresses. > So going back to the original question, is it OK to assign a /29 to a home > network > (beeing connected with wathever technology) ? [Bjarne Carlsen] That was not the original question. The question was whether a standard /29 assignment to all DSL/cable/insert-your-own-new-technology users would be feasible. > > I belive the answer is yes. [Bjarne Carlsen] I heartily disagree: With a standard assignment, there is absolutely no justification for the used space. The proposed policy does not even assume that all addresses will actually be used - not even that they will be used eventually. > I also belive that it is probably not > reasonalble to > expect an average customer to fill in the RIPE form. I also have a > tendency > to think > that it is probably not usefull to demand the form to be filled out for a > /29... [Bjarne Carlsen] Right, but the administration will have to be done at some point - whether it is done via a RIPE-141 or it is done some other way. The administrator should be the LIR in my opinion. > So my opinion would be that: > - the policy should not encourage an ISP to make /29 the default product > - the policy should not prevent an ISP from making a product option to > have > more than one IP address in a home network. (enabeled by clicking on a web > page > or some such.) [Bjarne Carlsen] And in my opinion the policy should not even _allow_ a /29 as default product - no tickee, no launly; no justification, no addresses. > - I think it would be a huge vaste of resources if RIPE NCC hostmasters > were > to spend their time reviewing RIPE forms for /29 for dsl, 3G or whatever > connected home¨ networks... [Bjarne Carlsen] Yes, but the administration will still have to be done somewhere in the system... > On the even more general side, I think more and more that we should be > realy > carefull to > create to strong restrictions on the use of address space available to new > and smaller players > today, while there are no such policies in place for legacy address space. > [Bjarne Carlsen] Couldn't have said that better myself. > -hph > /Bjarne

4 5

IP Address Tracking Software
by Jan-Ahrent Czmok 11 Feb '01

11 Feb '01

Hi! After reading through all the mails at nanog and other forums, i am asking: why not we all together work on a software which works together with RIPE, ARIN, APNIC ? Isn't that what internet was build on ? People doing great things. So let's get all ideas together and work together with the registries to solve that "evil" and "old" problem. Just my .2 cents (or euros, whatever) Jan

1 0