- lir-wg - mailman.ripe.net

RIPE NCC Staff Position: Junior Hostmaster (3 days/week)
by Daniel Karrenberg 24 Jul '95

24 Jul '95

Please distribute this announcement to all possibly interested parties. Thank you Daniel Karrenberg RIPE NCC Manager ------------------------------------------------------------------ RIPE: Coordinating the Internet in Europe. Due to the continuing explosive growth of the European Internet there is an immediate opening at the RIPE NCC for a J u n i o r H o s t m a s t e r for 3 days (24 hours) per week. Every host directly connected to the Internet needs an address. NCC hostmasters play a key role in the distribution of the Internet address space throughout Europe. Duties The general duties NCC hostmasters comprise: - to handle all address space related requests - to help maintain the databases the RIPE NCC keeps - to propose new activities, where needed - to report to the RIPE NCC Manager The specific duties of the junior hostmaster are: - to allocate address space to local Internet registries - to support local registries where needed - to assign address space - to review assignments made by other registries - to answer address space related queries - to refer non-routine requests to appropriate senior staff Almost all communications with customers and other organisations involved in Internet address space assignment is via the Internet itself. The position provides an excellent opportunity to work at the very heart of the European Internet industry. Qualifications Essential - willingness to learn quickly about the Internet environment - ability to perform administrative tasks reliably - good knowledge of written and spoken English - good communication skills - ability to learn and use Unix and X-windows based computer tools Desirable - work experience in an international environment - previous exposure to the Internet - basic experience with Unix and X-windows based computer tools The position is suitable both for those with administrative skills willing to learn about the Internet and to recent graduates with Internet experience willing to do administrative work. Female applicants and applicants from all European countries are explicitly encouraged. Depending on their ambitions and abilities junior hostmasters can be promoted to senior positions at the NCC. R I P E RIPE (Reseaux IP Europeens) is a collaborative organisation open to all European Internet service providers. The objective of RIPE is to ensure the necessary administrative and technical coordination to allow the operation of a pan- European IP network. RIPE does not operate a network of its own. RIPE has been functioning since 1989. Currently more than 80 organisations participate in the work. The result of the RIPE coordination effort is that the individual end-user is presented on his desk top with a uniform IP service irrespective of the particular network his or her workstation is attached to. In January 1995 1197911 hosts were registered on RIPE coordinated networks. The total number of systems reachable on the Internet worldwide is estimated at almost five million. R I P E N C C The RIPE Network Coordination Centre supports all those RIPE activities which cannot be effectively performed by volunteers from the participating organisations. Besides supporting RIPE activities in general the NCC provides the following services to network operators: o NETWORK MANAGEMENT DATABASE containing information about address space, routing, DNS domains and contact persons o DELEGATED INTERNET REGISTRY a clearing house distributing IP address space o RIPE INTERNET ROUTING REGISTRY o RIPE DOCUMENT STORE o RIPE INTERACTIVE INFORMATION SERVICE A detailed description of these activities can be found in the RIPE NCC Activity Plan (document ripe-110). This document can be obtained from the RIPE document store. The RIPE NCC is currently staffed as follows: one NCC manager two senior hostmasters (one more is being hired) one junior hostmaster (two more have already been hired) one NCC administrative staff In addition there is a conscienscious objector performing administrative duties. A deputy manager will also be hired this year. The NCC is funded by all Internet service providers in Europe who operate local Internet registries. NCC staff are formally employed by TERENA. TERENA TERENA is the European Association of research networking organisations and their users. TERENA has been created by a merger of the RARE and EARN associations. TERENA carries out technical activities and provides a platform for discussion and education to encourage the development of a high-quality computer networking infrastructure for the European research community. Conditions RIPE NCC personnel is employed by the TERENA association under their standard employment conditions. The salary will depend on qualifications and experience. Costs of relocation to the Netherlands will be met. The open position is part time for 24h/week on three working days. The distribution of the time over the week can be discussed. The appointment will be for one year with possible extension. Location The RIPE NCC is located at the Scientific Center Watergraafsmeer (WCW) in Amsterdam. The offices will be situated at NIKHEF, the Dutch National Institute for Nuclear Physics and High Energy Physics. Further Information For further information about the RIPE NCC, please see the RIPE document store at http://www.ripe.net/ ftp://ftp.ripe.net/ gopher://gopher.ripe.net/ telnet://info.ripe.net/ For further information about this position please contact: Daniel Karrenberg RIPE NCC Manager Kruislaan 409 NL-1098 SJ Amsterdam Netherlands Tel.: +31 20 592 5065 <Daniel.Karrenberg(a)ripe.net> How to Apply Applications, including a CV and references should be submitted in confidence to the address above and should be received no later than Sunday August 13th 1995.

1 0

None
by Jiri Lorman 24 Jul '95

24 Jul '95

regid: cz.bohemia org: BOHEMIA-NET Czech Republic type: PROVIDER community: Customers of BOHEMIA-NET Czech Republic address: datac CS Ltd. address: Za papirnou 5 address: Prague 7 address: 170 00 country: CZ admin-c: JL21-RIPE tech-c: JL21-RIPE tech-c: JP15-RIPE phone: +42 2 66712639 fax-no: +42 2 66712638 e-mail: hostmaster(a)bohemia.net lst-localir: lorman(a)quadat.cz lst-provs: lorman(a)quadat.cz lst-contrib: lorman(a)quadat.cz bill-addr: Datac CS s r. o. bill-addr: Jiri Lorman bill-addr: Za papirnou 5 bill-addr: 170 00 Praha 7 bill-addr: Czech Republic bill-mail: lorman(a)quadat.cz bill-proto: E-MAIL bill-categ: SMALL bill-scheme: HALF-YEARLY bill-vatno: without VAT bill-ref: Internet bill-remark:

1 0

None
by Jiri Lorman 24 Jul '95

24 Jul '95

help

1 0

Infos
by Redouane NAJAH SEMLALI 21 Jul '95

21 Jul '95

Lists Short

1 0

Re: Last Resort Registries
by jcaron＠pressimage.net 21 Jul '95

21 Jul '95

I guess that most of the issues here are based on the fact that once you get address space, you keep it. Looks like it shouldn't be the case anymore, as was outlined in the Internet Draft on address space ownership. To put it simply: - if you have private address space, and wish to connect to the Internet (or some internet or other), you [might] have to renumber - if you get address space from provider A, and switch to provider B, you will have to renumber So, in any case, you can only use address space provided by your provider, and will have to renumber in case of change. In fact, one could imagine it as address space belonging to providers, exactly the same way it works for the telephone: you can't think of switching phone operator without changing phone numbers, can you? Or even move from one place in the country to another without renumbering? [I know there are some initiatives in favor of an "assigned-for-life" phone number, but its equivalent in the Internet should be reserved for IPv6, I guess]. At 12:51 21/07/95, Kevin Hoadley wrote: >So dropping the last resort registries does little or nothing to reduce >non-provider addresses, since organisations can still acquire address space >from one provider and connectivity from another. The allocation of addresses >that may not be aggregateable continues, only now by different registries. Nope. A provider should not route address space coming from another provider, or even coming from a LR registry. > 1/ last-resort registries allocate non-aggregateable address space > (which in the future may be useless as no one will route it). No one will route it. That's *the* point. > 2/ last-resort registries are less necessary than was the case because > of the proliferation of provider registries And anyway, what use is there to have address space without connectivity? Yep, avoiding a renumber. But that won't be an option anymore. > 4/ "end-users will be warned better about what they are getting" if > they obtain their addresses from provider registries, rather than > last resort registries They'll be warned in any case: if you get address space from A and connectivity from B, it won't work, you'll have to renumber into B's address space, whatever A might B (a LRR or another provider). >(Have I missed anything ?) > >Going through these points, I don't believe dropping last-resort registries >solves #1, as non-aggregateable address will still be allocated albeit by >different registries. #2 is true, but not necessarily a reason to drop the Should be refused to be routed. >LR registries: less demand for them is not the same as no demand. A similar >argument can be advanced against #3 - the fact that the charging model may Why is there demand? There isn't a reason to get address space without connectivity anymore (well, won't be). >need to be modified to accommodate the LR registries is not by itself >sufficient reason to drop the registries. >I'm not at all convinced by #4. Consider the following scenario: a provider >registry allocates a block of addresses to a private internet, that claims >it has no intention of connecting to the global Internet. The provider >registry levies a charge for this (they win). 18 months later the private >internet then decides it does wish to connect to the global Internet. However >now they find that the only provider prepared to carry their addresses is >the one that allocated them in the first place. Hence unless they are >prepared to renumber they are locked into the first provider (thus the >provider wins again). The same would have been true had they acquired the They have to renumber. >addresses from a last-resort registry, however unlike the last-resort >registries it is in the provider's interest *NOT* to tell the customer about >the possible restrictions in the use of the addresses. > >I'm happy to see the last-resort registries disappear (we'd be *extremely* >happy to get shot of the load from our LR registry :-) ) if it is brings >significant benefit to the community. However on the basis of the arguments >I've seen here, I personally think that the benefit is not yet proven. In fact, the whole point is: - until now, it was considered better to add a route and not renumber. - from some point in the [near] future, adding a route will not be an option. You will have to renumber. Of course, things cannot be that categorical: - a period of transition should be permitted (without the need for the client to keep both connections during that time) - dual-homed networks are another problem - and *BIG* networks may be hard to renumber, but such *BIG* networks usually already have *BIG* CIDR blocks, their own AS, multiple connexions to the Internet, etc, so I guess they won't need to renumber (though they might be asked to replace a bunch of nets they got here and there over the course of time with a big CIDR block). This might be simplistic, but, if my understand is correct, that is the point of the Internet Draft on the subject, which was discussed at the IETF, and seems to be the new way to think about it (quite a radical change from previous assumptions, I agree). But, well, I'm a young new provider registry, so maybe over time I'll think about it differently..... Jacques. +-------------------------+------------------------+ |Jacques Caron | Pressimage Telematique | |jcaron(a)pressimage.net | 5/7 rue Raspail | |Tel: +33 (1) 49 88 63 56 | 93108 Montreuil Cedex | |Fax: +33 (1) 49 88 63 64 | France | +-------------------------+------------------------+

2 1

RIPE automatic inaddr-arpa checking tool available
by RIPE NCC IN-ADDR. ARPA Role Account 21 Jul '95

21 Jul '95

Dear all, After many requests I have published the inaddr-arpa checking tool I developed at the RIPE NCC. We use it now at RIPE NCC quite for some time and it really saves us a lot of time, although the program is not perfect and still needs some polishing. Beware of changing/adapting the tool too much since I expect to make some big changes in the output format to facilitate further automatic processing. Furthermore, I want to split it in some smaller files and a config file for better maintainability. Of course comments and bug reports are welcome. Please read the included README file for more details. Kind regards, David Kessens RIPE NCC PS I am on vacation during the next two weeks, but I will certainly deal with any comments/bug reports when I return! -------- README for the inaddrtool v0.1 Date: 950719 Author: David Kessens, RIPE NCC NOTE: THE TOOL HAS BEEN MADE PUBLICLY AVAILABLE BECAUSE OF THE LARGE NUMBER OF REQUESTS OF OUR CUSTOMERS TO DO SO. THE TOOL ITSELF HAS PROVEN IT'S USEFULNESS, BUT NOTE THE FACT THAT I EXPECT TO MAKE SOME BIG CHANGES BEFORE RELEASING A FINAL VERSION. ALSO SOME ADD-ON PROGRAMS THAT WILL MAKE IT POSSIBLE TO ADD THE REVERSE DELEGATION CHANGES/REQUESTS AUTOMATICALLY TO (Y)OUR ZONEFILES ARE STILL MISSING. THE PROGRAM IS DESIGNED AS SITE INDEPENT AS POSSIBLE. PLEASE USE THE NORMAL PROCEDURE AS DESCRIBED IN RIPE-105 IF YOU WANT TO DO A REVERSE DELEGATION REQUEST FOR A REVERSE DOMAIN MANAGED BY THE RIPE NCC, BUT SEND YOUR REQUEST TO <AUTO-INADDR(a)RIPE.NET> INSTEAD OF <HOSTMASTER(a)RIPE.NET> Reverse delegation tool (Alpha version!) ---------------------------------------- As of today the RIPE NCC offers an automated method for the submission of reverse zone delegations in 193.in-addr.arpa and 194.in-addr.arpa. The reverse delegation requests and the zone files on all nameservers will be checked automatically. The diagnostics generated by these checks will be returned to you automatically too. This will make you aware of any problems very quickly, so that you can correct them and re-submit your request. The most recent version of the tool is now publicly available at: ftp://ftp.ripe.net/tools/inaddrtool0.1.tar.gz The tool uses some other external programs for gathering the information it needs for checking your zone files: ftp://ftp.ripe.net/tools/ping.tar.Z ftp://ftp.ripe.net/tools/dns/host.tar.Z ftp://ftp.ripe.net/pride/tools/prtraceroute-2.0beta3.shar.gz Installing the software: - uncompress/unzip and untar the tool and the external programs - edit the variables in the source code (if needed): $TESTMODE=1 for testing, 0 for normal use $UPDLOGDIR="Directory for logging the incoming requests"; $ACKLOGDIR="Directory for logging the outgoing acknowledgements"; $FWLOGDIR="Directory for logging the outgoing approved requests"; $MSGQUEUEDIR="Directory for temporarily storing the requests"; $NSNAME="The name of your nameserver"; $NAMESERVERCHECK=; see for details the source code $MAILCMD=; see for details the source code $NICECMD="Your nice program if you want" else use ""; $HUMANMAIL="The E-mail address of the human processing the approved requests and answering questions. When $TESTMODE=1, all mail will be send to this address"; $AUTOMAIL="The E-mail address of the mail box that will auto process incoming requests"; - Put something like: "|/home/user/bin/inaddrtool 2>/dev/null" in the .forward file of user $AUTOMAIL Note: there is *NO* queuing mechanism yet, so beware of overloading your machine with a large number of requests. The input: The tool expects to read an E-mail message from standard input although there is no problem when using it stand-alone. The E-mail message should contain a valid RIPE database object as described in the ripe-105 (ftp://ftp.ripe.net/ripe/docs/ripe-105) procedure. When the automated procedure does not detect any errors, the request is forwarded to the $HUMANMAIL role account person for some additional manual checks and the processing of the delegation itself. An acknowledgement of this fact is also sent to the people mentioned in the From:/Reply-To: and Cc: field in the E-mail message. The tool will return an error report if errors are found. If $TESTMODE=1 all mail will be send to $HUMANMAIL. You can use some keywords in the 'Subject:' line of your E-mail to control the checking process. The use of the LONGACK keyword is very recommended. HELP - will send you a (patched) ripe-105 document CHANGE - is needed if you want to change an existing reverse delegation LONGACK - will give you the most verbose output as possible TEST - do the checks, but sent only a report back to the user even if no errors are found You also might want to use the special variable NSNAME that's documented in the source code itself (for experts only). RIPE document ripe-105 requires you to send in a RIPE database 'inetnum' object with a 'rev-srv' attribute for each nameserver for single/multiple C's reverse delegation requests and for whole blocks 'domain' objects with 'nserver' attributes for each nameserver. I am neither a DNS expert or native English writer ;-) so all your comments are welcome! Please send them together with complaints, bug reports or special requests to <inaddr(a)ripe.net>.

1 0

Re: Last Resort Registries
by Bjorn Eriksen 21 Jul '95

21 Jul '95

>> and where RFC 1597 might be a problem, as there is no coordination who >> has picked something from RFC 1597 (perhaps a new task for last-resorts >> to coordination the national use of RFC 1597), then it does happen that >HELP! So we suddenly make -private- address space semi-public, then >we might just as well start allocating the current address space a second >time. Perhaps you don't have big companies in Switzerland, whatever do I know about Switzerland. But there are cases when Big Company connect to a small outside company, providing something special and as Small Company don't connect to Internet they must use RFC 1597 and eventually Small-2 has been told the same story and use the same first numbers from RFC 1597, but when Big Company want to have a link to Small-2 as well, this becomes a problem. Simon, you don't seem to understand the real problem. Coordination has to be done on every possible level. Personally I don't care whatsoever about those that we force to use private address space, but they will eventually run into problems, so beeing last-resort we ouht to take our responsibilty and coordinate thing that are currently in a mess. --Bjorn

5 4

Re: Last Resort Registries
by Bjorn Eriksen 20 Jul '95

20 Jul '95

>If two 1597 using private nets are merged then they just have >to renumber whichever subnets overlap. that's it. That's what a national coordination could avoid. --Bjorn

1 0

Re: Last Resort Registries
by Bjorn Eriksen 20 Jul '95

20 Jul '95

>Consequently it has been proposed several times already to close down >the Last-Resort registries. I think it is now time to finally take >such a step with a timeframe of end Q3/95 or at the end of the year. This seems to be in line with the current activities we have had as beeing the last-resort for Sweden. During the past 5-6 month we have assigned very few IP numbers. We do get lots of requests, but the standard answers are a. If you are connected to or plan to connect to a service provider, apply for IP numbers from them. If you don't know who to connect to, then find out. b. If you have no plans at all to connect and/or announce your network to to global Internet, then use RFC 1597. Between a and b there is almost nothing (catch 22). There are some rare cases with someone connecting to someone that has Internet connectivity and where RFC 1597 might be a problem, as there is no coordination who has picked something from RFC 1597 (perhaps a new task for last-resorts to coordination the national use of RFC 1597), then it does happen that we still assign numbers but everyone is then told that they will most certainly have to renumber in case they connect for real. Checking the current statistics it's a clear decrease in our last-resort assigned class C numbers 9501 160 9502 95 9503 65 9504 56 9505 66 9506 34 9507 27 --Bjorn

2 1

Last Resort Registries
by Alexander Saban 20 Jul '95

20 Jul '95

Daniel, Yes, we see serious problems with your proposal to be implemented in Ukraine. I understand and recognize your reasons, and I beleive that they are valid for most European countries, however, I am not that sure they do apply to Ukraine. The problem in Ukraine is there is almost no service providers here in European meaning of this word. The networking is still underdeveloped due to poor economy of transition period. Ukrainian service providers (except for one recent example) are not able to contribute to RIPE activities. Therefore, UA LR registry is the only source for address space in this country. We try to run the registry in the way providing smooth transition to aggregate routing once it will be implemented at external links. The consequense of the proposed measures for UA will be that new users will have to apply directly to RIPE for address space which is probably not the goal. Otherwise, they will discrimination because of difficulties with allocation of the address space they request. I would like to suggest a differentiated approach to LRs in different countries. Perhaps, by the end of the year we shall be able to find another solution. Hope to hear from you more, Alexander > > > Last-Resort local IRs have been established to serve end-users who do > not have access to another local IR either because they do not connect > to the Internet yet or because Internet service providers were not yet > providing registry services. > > Recently the introduction of route aggregation (CIDR) and the > proliferation of local IRs operated by service providers greatly reduce > the usefulness of Last-Restort local IRs. Even worse, the routing of > non-aggregatable address space negatively impacts the Internet routing > system. Such space either is or shortly will be less then useful for > the end-user because they have to renumber when connecting. Also there > is now private address space available for use of end-users who want > address space that is guaranteed not to be used by another end-user on > the Internet. > > Additionally the Last-Resort registries form an anomaly in the RIPE NCC > charging system, because they do not contribute to NCC funding while > using NCC resources. > > Consequently it has been proposed several times already to close down > the Last-Resort registries. I think it is now time to finally take > such a step with a timeframe of end Q3/95 or at the end of the year. > > Are there any serious problems with this step? > > Daniel > -- ============================================================== Dr. Alexander Saban, Inst. Cond. Matter Physics 1 Svientsitsky St., Lviv, 290011 Ukraine Tel/fax +380(322)761978, tel +380(322)760614 email saban(a)icmp.lviv.ua -- ============================================================== Dr. Alexander Saban, Inst. Cond. Matter Physics 1 Svientsitsky St., Lviv, 290011 Ukraine Tel/fax +380(322)761978, tel +380(322)760614 email saban(a)icmp.lviv.ua

1 0