July 1995 - lir-wg - mailman.ripe.net

Infos
by Redouane NAJAH SEMLALI 22 Jul '95

22 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

TEST database
by RIPE Database Manager 20 Jul '95

20 Jul '95

Dear all, Last week, I have installed a test database on test-whois.ripe.net. This database is intended for people who want to play around with some test database objects and to learn how the RIPE database works. Updates should be send to: <testdb(a)ripe.net> Do queries with: whois -h test-whois.ripe.net SearchString The creation of maintainers is allowed for everybody for your (and my) convenience but the software will warn you that maintainer creation is normally done by human intervention. It is possible to update two different databases with source names: source: TEST OR source: TEST2 Of course, I might use this database for some tests I do myself with the database software so don't be surprised to see some new features that are not present in the production database, Kind regards, David Kessens RIPE NCC Database maintainer --------

1 0

Establishing a connection between Israel and Europe
by Shahar Steiff 16 Jul '95

16 Jul '95

Dear Local IR. NetVision, Israel's largest commercial Internet Service Provider, and a Local IR by itself, is gearing up towards establishing a direct network connection to Europe. NetVision currently has a direct link to USA, and we are now seeking a direct link to a European service provider through which we intend to route our European traffic only. By that we will be reducing the mutual share of the load on the USA-Europe lines, from which all will benefit. We are looking forward to your offers and comments, hoping to establish a cooperation. Please send your replies to <wan(a)netvision.net.il>. Sincerely, Shahar Steiff WAN team - NetVision - Commercial Israeli Internet Provider ----------------------------------------------------------- E-mail: steiff(a)NetVision.net.il Personal address info(a)NetVision.net.il for information. support(a)NetVision.net.il for technical support. Gopher: gopher.NetVision.net.il www: http://www.NetVision.net.il/ Phone: +972-4-550330 Fax: +972-4-550345 +972-4-550122 This message was sent by Chameleon.

1 0

SUBSCRIBE
by Redouane NAJAH SEMLALI 15 Jul '95

15 Jul '95

subscribe Redouane NAJAH

1 0