June 1996 - lir-wg - mailman.ripe.net

Please help: ptp links addresses
by Antonio_Blasco Bonito 11 Jul '96

11 Jul '96

Dear Local Registries, I need some advice on the following: An italian ISP, which we run its delegated LIR, is planning its backbone network where there are *A LOT* of point-to-point links (on leased lines, on channelized lines, on Frame Relay PVCs, etc.). I know about two ways of managing the links in terms of IP addresses: 1- using a /30 subnet for each link: in this way both ends of the link have a unique address (binary 01 and 10), but two addresses (binary 00 and 11) cannot be used, so 50% of the address space used is wasted. This should be avoided if possible because the address space required is really large. 2- using unnumbered interfaces for each link and, on cisco routers, associating another interface IP address (the loopback interface is quite useful for this purpose): in this way addresses are not wasted but certain functionalities are lost, i.e. SNMP monitoring of each physical interface, etc. Are you aware of any other way to deal with this issue so that it is possible to have IP addresses for each interface without wasting address space? Thank you very much in advance. ---------- ---------- Antonio-Blasco Bonito E-Mail: bonito(a)nis.garr.it GARR - Network Information Service c=it;a=garr;p=garr;o=nis;s=bonito c/o CNUCE - Istituto del CNR Tel: +39 50 593246 Via S. Maria, 36 Fax: +39 50 904052 I-56126 PISA Telex: 500371 CNUCE I Italy Url: http://www.nis.garr.it/nis/staff/bonito.html ---------- ----------

7 7

Re: Please help: ptp links addresses
by barak＠netvision.net.il 26 Jun '96

26 Jun '96

--- On Tue, 25 Jun 96 16:01:41 +0100 Mike Norris <mnorris(a)dalkey.hea.ie> wrote: >1- using a /30 subnet for each link: > in this way both ends of the link have a unique address (binary > 01 and 10), but two addresses (binary 00 and 11) cannot be used, > so 50% of the address space used is wasted. This should be > avoided if possible because the address space required is > really large. The usage is actually 75%, as there are effectively three addresses: the two ends (00 and 01) and the broadcast address for the network (11). 10 is the unused address. Mike -----------------End of Original Message----------------- Actually, if you are using Cisco solely, you can always define "ip subnet-zero", and use broadcast AND network addresses. No loss :-) Cheers, Sincerely, \'"'/ Barak Engel ( o o ) ---------------------ooOO-^-oOOo---------- Engel Barak, NetVision WAN team BE-RIPE E-mail: barak(a)netvision.net.il Date: 6/26/96 Time: 8:49:40 AM Phone: +972 4 8550330 Fax: +972 4 8550345 ------------------------------------------

1 0

Re: Please help: ptp links addresses
by Hank Nussbacher 25 Jun '96

25 Jun '96

On Tue, 25 Jun 1996 13:44:34 +0200 (MET DST) you said: >Of course ! You can use RFC1597 addresses which are routed only in your >domain, so that your SNMP managers can reach each Interface. RFC1918. RFC1597 has been obsoleted (although the addresses stay the same). Hank

1 0

Re: Please help: ptp links addresses
by root＠arcadis.be 25 Jun '96

25 Jun '96

> The usage is actually 75%, as there are effectively three addresses: > the two ends (00 and 01) and the broadcast address for the network > (11). 10 is the unused address. You don't waste a broadcast address on a, let's say, /24 network but you have to consider it as waste if you plan to use *a lot* of /30 networks. Still, most of the routing protocols use broadcasting so I guess that's what you meant when you said it wasn't a waste... - Hugh

1 0

Re: Please help: ptp links addresses
by Jean-Francois Stenuit 25 Jun '96

25 Jun '96

At 13:15 25/06/96 DST, Antonio_Blasco Bonito wrote: >Dear Local Registries, > > >I need some advice on the following: > >An italian ISP, which we run its delegated LIR, is planning its >backbone network where there are *A LOT* of point-to-point links (on >leased lines, on channelized lines, on Frame Relay PVCs, etc.). > >I know about two ways of managing the links in terms of IP addresses: > >1- using a /30 subnet for each link: > in this way both ends of the link have a unique address (binary > 01 and 10), but two addresses (binary 00 and 11) cannot be used, > so 50% of the address space used is wasted. This should be > avoided if possible because the address space required is > really large. > >2- using unnumbered interfaces for each link and, on cisco routers, > associating another interface IP address (the loopback interface > is quite useful for this purpose): > in this way addresses are not wasted but certain functionalities > are lost, i.e. SNMP monitoring of each physical interface, etc. > > >Are you aware of any other way to deal with this issue so that it >is possible to have IP addresses for each interface without wasting >address space? > >Thank you very much in advance. Of course ! You can use RFC1597 addresses which are routed only in your domain, so that your SNMP managers can reach each Interface. The problem is for somebody from the outside wanting to address the interface (which is frequent with tools like traceroute), who will not see any answers from your routers. Anyway, this is a good solution if you want access to your interfaces only from you domain (and, as a side effect, it increase security on your routers). We are currently using this scheme for our ISDN links. Regards, -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> /Jean-Francois "Jef" Stenuit | Interpac Belgium NV/SA | Solaris 2.x \ \Internet administrator | 350/358 Avenue Louise Box 11 | Cisco / /Phone (32)(2) 646-6000 | B-1050 Brussels | Netblazer \ \Fax (32)(2) 640-3638 | Belgium | / /Email stenuit(a)interpac.be | | expert ... \ <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

1 0

URGENT: database ftp mirror problems and changes on the ftp site
by David.Kessens＠ripe.net 21 Jun '96

21 Jun '96

Dear all, We had this morning troubles with copying our database files to the ftp site for people that run a secondary mirror. The problems are solved right now. However, I needed to make some changes in the procedures that affect all people that use our non 'gzipped' files. Since I wanted to make these changes anyway, I want to ask you if they are acceptable for you: I only make the 'gzipped' files available from now on. This causes less confusion between the different files available, less network traffic, faster availability of the database files on the ftp server and less load on the database server. Please let me know if you really need the uncompressed or .Z compressed files available and I will change this back. If you have any further questions, please don't hesitate to contact me again, Kind regards, David Kessens RIPE NCC

1 0

RE: FYI: David K. will be leaving the RIPE NCC
by Wilfried Woeber, UniVie/ACOnet 19 Jun '96

19 Jun '96

Hi David ! >Dear all, > >After working for nearly 2 years at the RIPE NCC, I feel it is time for a >change. I have found a new job at ISI (Los Angeles) where I will be >involved with the RA project. I will leave the RIPE NCC at the end of July. As I said previously in a private message, sometimes it's a pity staying behind at the wrong side of the pond... I don't want to add to Mike's general praise - he has worded it much better than I could. Instead I'd like to extend our thanks to you wearing my hat as the RIPE-DB-WG convenor. It was, and still is, a pleasure to work with you, both professionally and personally. All the best for your new position! I sincerely hope to keep in contact and to continue the successful collaboration as close as possible. Again - both personally and professionally! Cheers, Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 --------------------------------------------------------------------------

1 0

New Document available: ripe-136++
by RIPE NCC Document Annoucement Service 19 Jun '96

19 Jun '96

Revised RIPE Document Announcement -------------------------------------- A revised/new document is available from the RIPE document store. Ref: ripe-136++ Title: European Internet Registry Policies and Procedures Author: Local IR Working Group Date: 19 June 1996 Format: PS=923189 TXT=209542 bytes Obsoletes: ripe-104, ripe-105 Short content description ------------------------- A new document, ripe-136++ is now available in the RIPE document store. The contents of the first five sections of this document regarding the policies and procedures for the distribution of public IP address space in Europe and surrounding areas, were approved by the RIPE community during the RIPE-23 meeting held in January 1996. This document is an updated version of the original ripe-136 document with sections added on Internet Registry operations, AS number assignment procedures and Routing Registry policies and procedures. A table has also been added to section 5 to give a quick overview of reverse delegation procedures. Other changes made to the first five sections are minor. Please review this document and send your comments to me or to the lir-wg by 12 July, 1996. We will then review the comments and incorporate them before we officially publish the document. Paula Caslav RIPE NCC FTP Access ---------- All RIPE documents and Internet RFC`s are available via anonymous FTP from host ftp.ripe.net. Type "ftp ftp.ripe.net". Login with username "anonymous" supplying your email address as the password. After logging in, type "cd ripe/drafts/" followed by the command "get filename". The relevant filenames for this document are: ripe-136++.txt for the ASCII version ripe-136++.ps for the PostScript version Electronic Mail Retrieval of Documents -------------------------------------- Documents can also be retrieved from the RIPE document store using a mail server program. For more information on how to use the program, send email to: mail-server(a)ripe.net with "send HELP" in the body text. RIPE NCC Interactive Information Server --------------------------------------- Type "telnet info.ripe.net". This is a menu driven service allows the document store to be browsed. After reading documents you are prompted as to whether you would like to receive an email copy of the document you have just read. If you would, you simply enter your email address and the document will be mailed to you. Below are details of alternative methods of access. Gopher Access ------------- The same documents are available via a "gopher" server at "gopher gopher.ripe.net". WAIS Access ----------- There is also a "WAIS" server at wais.ripe.net, where there is a WAIS index for RIPE documents "ripe-docs.src" WWW Access ---------- For those who wish to add this home page at the RIPE NCC to their own customized home pages, it can be accessed as: ftp://ftp.ripe.net/ripe/drafts/ MIME Mail Reader ---------------- Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the RIPE document by FTP or mail server. SEND ripe/drafts/ripe-136++.txt

1 0

FYI: David K. will be leaving the RIPE NCC
by David.Kessens＠ripe.net 19 Jun '96

19 Jun '96

Dear all, After working for nearly 2 years at the RIPE NCC, I feel it is time for a change. I have found a new job at ISI (Los Angeles) where I will be involved with the RA project. I will leave the RIPE NCC at the end of July. As for the RIPE database: We currently plan to bring out the long expected 2.00 release version as soon as possible to keep some time left while I am still at the RIPE NCC in case problems arise. You can soon expect a message from me at the database working group maillist with all the open proposals (as promised during the last RIPE meeting). I would like to thank the RIPE community for their support of and input on my development work on the RIPE database and the reverse delegation tool. I hope that I will be able to collaborate as productively with you in my new job as we have in the past. Kind regards, David K. RIPE NCC ----

4 3

(no subject)
by RIPE NCC Staff 14 Jun '96

14 Jun '96

Dear RIPE Community, Since the Local IR mailing list <local-ir(a)ripe.net> is a closed list and only open for contributing registries, it was requested to create a new mailing list for the Local IR Working Group that is open to everyone interested. This new mailing list is called <lir-wg(a)ripe.net> Below you find a short summary to clarify the difference between these two lists: local-ir(a)ripe.net - All issues that only concern contributing Local IR's are send to this list - is a CLOSED list, only open to contributing Local IR's - Subscription is not managed by majordomo, but maintained manually by the RIPE NCC - All contributing LIR's are automatically subscribed lir-wg(a)ripe.net: - All issues related to the LIR Working Group like Meeting Agendas, document revisions and such are sent to this list - All LIR Working Group discussions take place on this list - is an OPEN list, everyone can subscribe - Subscription is managed by majordomo - <local-ir(a)ripe.net> is automatically subscribed to this list, so - contributing registries don't need to be subscribed to both lists - mail does not need to be sent to both lists All 'guests' that were previously subscribed to local-ir have now been moved to lir-wg. I don't expect this to be much of a problem, but if it is: flames to me please. Kind regards, Roderik Muit RIPE NCC

1 0