March 1993 - lir-wg - mailman.ripe.net

Autonomous Systems Available via RIPE WHOIS
by Daniel Karrenberg 12 Mar '93

12 Mar '93

Autonomous System (AS) information is now available from the RIPE whois server. The server will accept queries for AS<number>. Very basic information about most existing ASes from the NIC and other sources has been entered with a source attribute of INTERNIC and will only be found if the -a flag is passed to the whois server. This information is also available as file from ftp.ripe.net in file ripe/dbase/asn.db.Z. In order to get things going some instances of the new RIPE AS object have also been entered already. For example whois as786 will produce aut-num: AS786 descr: The JANET IP Service descr: UK as-in: AS60 50 AS60 as-in: AS766 100 AS766 as-in: AS1263 45 DEFAULT as-in: AS1275 100 AS1275 as-in: AS1290 50 AS1290 as-in: AS1755 102 RIPE-DB AND NOT (LOCAL AS786) as-in: AS1849 50 AS1849 as-in: AS1930 100 AS1930 as-in: AS2107 100 AS2107 as-in: AS2111 100 AS2111 as-out: AS60 AS786 AS766 as-out: AS766 AS786 AS1755 as-out: AS1263 AS786 AS766 AS1930 AS2107 AS2111 as-out: AS1275 AS786 AS1755 as-out: AS1290 AS786 as-out: AS1755 AS786 AS766 AS1275 AS1930 AS2107 AS2111 as-out: AS1849 AS786 AS1755 as-out: AS1930 AS786 AS1755 as-out: AS2107 AS786 AS1755 as-out: AS2111 AS786 AS1755 default: AS1263 1 guardian: jips-nosc(a)noc.ulcc.ac.uk admin-c: Duncan Rogerson admin-c: Kevin Hoadley tech-c: Duncan Rogerson tech-c: Kevin Hoadley remarks: AS2111 link is not yet active, coming soon. changed: D.Rogerson(a)nosc.ja.net 930226 source: RIPE A description of the AS object can be found in appendix A of document ripe-81. We also accept updates and additions of AS objects in the RIPE database at <ripe-dbm(a)ripe.net>. We urge everyone to send in AS objects a.s.a.p.. They do not necessarily need to include the routing policy information (as-in, as-out, default and guardian). If you want to jump in at the deep end you could read ripe-81 and generate the routing policy as well. We will be happy to help you with this. However don't put off sending in the basic information because of this. There is a real benefit in this being available too. Further plans: The NCC will generate AS objects for all ASes being used in the European Internet and not present in the database during the next week and send them to the suspected contact persons for validation. Shortly after these are installed, a new update procedure for the aut-sys tag of network objects will be anabled. This procedure is described in ripe-81. Basically it means that aut-sys tags will be generated from information supplied by the AS guardians. Initially the NCC will be guardian for all ASes which do not have a guardian yet and process change requests manually. Please do not hesitate to contact us if you have any questions about this. The NCC Staff PS: A new ripe document containing all database templates and update procedures is being prepared and will be released shortly.

2 1

ripe-81 work
by Tony Bates 11 Mar '93

11 Mar '93

As part of the work we are doing with the ripe-81 database format and tools we have been looking at various aspects of the RIPE database as it stands as compared to what we see within the "real world" (in this case we use the BGP routing table of Amsterdam-EBS1.ebone.net) in terms of autonoumous system numbers. We have a program that generates lists of networks assigned to an AS currently in the database and also one that will "on the fly" do the same thing for a cisco BGP routing table. We have found some interesting results and some we wish to share with you at this stage to maybe get some of this corrected. We compared the BGP derived information with what is in the database. Obviously, a lot of non-Europe routes are not in the database so these are not flagged. The main things of interest are the following. 1) networks in the database flagged as LOCAL and being routing. Can the providers look at these please. Often, people forget to update there entry when they start routing them. 2) networks having an existing AS-number in database but reflected differently in the routing tables (the can sometimes be a config error, even typos in databse ny the looks of it). 3) networks being routed but not yet allocated (here we only look at 193 networks). Please check if you forgot to send in an update/assignment. 4) networks in BGP routing tables with more than more originating AS. These need to be look at and configured accordingly. See Section 5 on Autonomous systems in ripe-81 for reasoning as to why these should only originate in one AS. We intend soon to generate this information daily on our ftp archive for both the database information and router derived information. We will have a more extensive progress report fairly soon as the various other aspects of the ripe-81 work including a "call for policy" information. However, work is progressing extremely well. Sorry if the distribution is quite large but I feel there is information that has relevence to all these groups in the mail. --Tony Bates, RIPE NCC 1) networks in the database flagged as LOCAL and being routing 141.22.0.0 is flagged LOCAL (database) and announced by AS1275 (BGP) 141.56.0.0 is flagged LOCAL (database) and announced by AS517 (BGP) 145.41.0.0 is flagged LOCAL (database) and announced by AS1103 (BGP) 146.105.0.0 is flagged LOCAL (database) and announced by AS1849 (BGP) 164.15.0.0 is flagged LOCAL (database) and announced by AS2111 (BGP) 192.12.54.0 is flagged LOCAL (database) and announced by AS1103 (BGP) 192.16.183.0 is flagged LOCAL (database) and announced by AS1104 (BGP) 192.16.183.0 is flagged LOCAL (database) and announced by AS1890 (BGP) 192.26.121.0 is flagged LOCAL (database) and announced by AS790 (BGP) 192.36.33.0 is flagged LOCAL (database) and announced by AS1653 (BGP) 192.36.34.0 is flagged LOCAL (database) and announced by AS1653 (BGP) 192.36.149.0 is flagged LOCAL (database) and announced by AS1257 (BGP) 192.70.55.0 is flagged LOCAL (database) and announced by AS701 (BGP) 192.70.56.0 is flagged LOCAL (database) and announced by AS701 (BGP) 192.71.15.0 is flagged LOCAL (database) and announced by AS1257 (BGP) 192.71.28.0 is flagged LOCAL (database) and announced by AS1729 (BGP) 192.71.39.0 is flagged LOCAL (database) and announced by AS1257 (BGP) 192.71.85.0 is flagged LOCAL (database) and announced by AS1729 (BGP) 192.71.168.0 is flagged LOCAL (database) and announced by AS1257 (BGP) 192.71.194.0 is flagged LOCAL (database) and announced by AS1257 (BGP) 192.76.147.0 is flagged LOCAL (database) and announced by AS1270 (BGP) 192.83.13.0 is flagged LOCAL (database) and announced by AS544 (BGP) 192.84.13.0 is flagged LOCAL (database) and announced by AS1930 (BGP) 192.84.15.0 is flagged LOCAL (database) and announced by AS1930 (BGP) 192.102.158.0 is flagged LOCAL (database) and announced by AS517 (BGP) 192.108.72.0 is flagged LOCAL (database) and announced by AS786 (BGP) 192.121.25.0 is flagged LOCAL (database) and announced by AS1257 (BGP) 192.121.70.0 is flagged LOCAL (database) and announced by AS1257 (BGP) 192.121.163.0 is flagged LOCAL (database) and announced by AS1257 (BGP) 192.124.249.0 is flagged LOCAL (database) and announced by AS1275 (BGP) 192.129.8.0 is flagged LOCAL (database) and announced by AS786 (BGP) 192.133.1.0 is flagged LOCAL (database) and announced by AS760 (BGP) 192.138.204.0 is flagged LOCAL (database) and announced by AS1930 (BGP) 192.165.173.0 is flagged LOCAL (database) and announced by AS1257 (BGP) 192.165.191.0 is flagged LOCAL (database) and announced by AS1257 (BGP) 192.173.65.0 is flagged LOCAL (database) and announced by AS760 (BGP) 193.59.1.0 is flagged LOCAL (database) and announced by AS1887 (BGP) 193.59.8.0 is flagged LOCAL (database) and announced by AS1887 (BGP) 193.59.9.0 is flagged LOCAL (database) and announced by AS1887 (BGP) 193.59.10.0 is flagged LOCAL (database) and announced by AS1887 (BGP) 193.59.11.0 is flagged LOCAL (database) and announced by AS1887 (BGP) 193.63.65.0 is flagged LOCAL (database) and announced by AS786 (BGP) 193.84.60.0 is flagged LOCAL (database) and announced by AS1902 (BGP) 193.84.61.0 is flagged LOCAL (database) and announced by AS1902 (BGP) 193.87.96.0 is flagged LOCAL (database) and announced by AS1922 (BGP) 193.96.9.0 is flagged LOCAL (database) and announced by AS1270 (BGP) 193.96.10.0 is flagged LOCAL (database) and announced by AS1270 (BGP) 193.96.11.0 is flagged LOCAL (database) and announced by AS1270 (BGP) 193.98.97.0 is flagged LOCAL (database) and announced by AS1270 (BGP) 193.166.24.0 is flagged LOCAL (database) and announced by AS1739 (BGP) 193.166.25.0 is flagged LOCAL (database) and announced by AS1739 (BGP) 193.166.31.0 is flagged LOCAL (database) and announced by AS1741 (BGP) 2) networks having an existing AS-number in database but reflected differently in the routing tables (the can sometimes be a config error). 128.86.0.0 in AS786 (database) and AS1755 (BGP) 128.130.0.0 in AS697 (database) and AS679 (BGP) 131.130.0.0 in AS590 (database) and AS760 (BGP) 131.173.0.0 in AS590 (database) and AS1754 (BGP) 132.146.0.0 in AS1752 (database) and AS1290 (BGP) 132.165.0.0 in AS590 (database) and AS777 (BGP) 132.166.0.0 in AS590 (database) and AS777 (BGP) 132.167.0.0 in AS590 (database) and AS777 (BGP) 132.168.0.0 in AS590 (database) and AS777 (BGP) 132.230.0.0 in AS553 (database) and AS1754 (BGP) 134.47.0.0 in AS1770 (database) and AS224 (BGP) 134.214.0.0 in AS590 (database) and AS789 (BGP) 138.70.0.0 in AS137 (database) and AS1717 (BGP) 139.92.0.0 in AS590 (database) and AS1754 (BGP) 139.128.0.0 in AS137 (database) and AS1717 (BGP) 139.191.0.0 in AS1267 (database) and AS1717 (BGP) 139.191.0.0 in AS1267 (database) and AS559 (BGP) 140.77.0.0 in AS590 (database) and AS789 (BGP) 141.28.0.0 in AS174 (database) and AS517 (BGP) 141.43.0.0 in AS1324 (database) and AS517 (BGP) 141.47.0.0 in AS174 (database) and AS517 (BGP) 141.54.0.0 in AS1324 (database) and AS517 (BGP) 141.137.0.0 in AS137 (database) and AS1717 (BGP) 143.169.0.0 in AS590 (database) and AS1717 (BGP) 143.205.0.0 in AS760 (database) and AS1111 (BGP) 143.224.0.0 in AS760 (database) and AS2036 (BGP) 146.110.0.0 in AS760 (database) and AS2012 (BGP) 147.196.0.0 in AS1899 (database) and AS1717 (BGP) 151.89.0.0 in AS1267 (database) and AS1717 (BGP) 151.90.0.0 in AS1267 (database) and AS1717 (BGP) 153.96.0.0 in AS1324 (database) and AS517 (BGP) 153.97.0.0 in AS1324 (database) and AS517 (BGP) 156.18.0.0 in AS590 (database) and AS789 (BGP) 157.24.0.0 in AS1714 (database) and AS1741 (BGP) 158.152.0.0 in AS1849 (database) and AS1290 (BGP) 159.84.0.0 in AS1717 (database) and AS789 (BGP) 160.103.0.0 in AS1717 (database) and AS789 (BGP) 161.3.0.0 in AS590 (database) and AS789 (BGP) 161.41.0.0 in AS1923 (database) and AS719 (BGP) 192.12.193.0 in AS137 (database) and AS513 (BGP) 192.35.150.0 in AS1274 (database) and AS1275 (BGP) 192.41.218.0 in AS137 (database) and AS1717 (BGP) 192.42.143.0 in AS174 (database) and AS1754 (BGP) 192.44.2.0 in AS174 (database) and AS517 (BGP) 192.44.11.0 in AS174 (database) and AS517 (BGP) 192.44.15.0 in AS174 (database) and AS517 (BGP) 192.44.32.0 in AS174 (database) and AS517 (BGP) 192.44.33.0 in AS174 (database) and AS517 (BGP) 192.44.34.0 in AS174 (database) and AS517 (BGP) 192.44.35.0 in AS1324 (database) and AS517 (BGP) 192.54.104.0 in AS174 (database) and AS517 (BGP) 192.54.197.0 in AS590 (database) and AS789 (BGP) 192.55.105.0 in AS2004 (database) and AS1890 (BGP) 192.58.53.0 in AS1741 (database) and AS544 (BGP) 192.65.184.0 in AS513 (database) and AS1755 (BGP) 192.65.185.0 in AS513 (database) and AS1755 (BGP) 192.70.69.0 in AS789 (database) and AS513 (BGP) 192.70.89.0 in AS1899 (database) and AS1717 (BGP) 192.70.90.0 in AS1899 (database) and AS1717 (BGP) 192.76.246.0 in AS1274 (database) and AS1755 (BGP) 192.82.157.0 in AS760 (database) and AS1112 (BGP) 192.92.104.0 in AS137 (database) and AS1717 (BGP) 192.92.105.0 in AS137 (database) and AS1717 (BGP) 192.92.106.0 in AS137 (database) and AS1717 (BGP) 192.93.155.0 in AS590 (database) and AS789 (BGP) 192.101.28.0 in AS174 (database) and AS517 (BGP) 192.102.147.0 in AS1324 (database) and AS517 (BGP) 192.102.176.0 in AS1324 (database) and AS517 (BGP) 192.106.1.0 in AS1267 (database) and AS1717 (BGP) 192.106.207.0 in AS1267 (database) and AS1717 (BGP) 192.106.217.0 in AS1267 (database) and AS1717 (BGP) 192.106.222.0 in AS1267 (database) and AS1717 (BGP) 192.106.223.0 in AS1267 (database) and AS1717 (BGP) 192.106.228.0 in AS1267 (database) and AS1717 (BGP) 192.106.229.0 in AS1267 (database) and AS1717 (BGP) 192.106.235.0 in AS1267 (database) and AS1717 (BGP) 192.106.239.0 in AS1267 (database) and AS1717 (BGP) 192.106.240.0 in AS1267 (database) and AS1717 (BGP) 192.106.244.0 in AS1267 (database) and AS1717 (BGP) 192.106.249.0 in AS1267 (database) and AS1717 (BGP) 192.106.250.0 in AS1267 (database) and AS1717 (BGP) 192.134.29.0 in AS590 (database) and AS789 (BGP) 192.134.91.0 in AS1899 (database) and AS1717 (BGP) 192.153.173.0 in AS1853 (database) and AS1755 (BGP) 193.1.192.0 in AS2110 (database) and AS1213 (BGP) 193.1.193.0 in AS2110 (database) and AS1213 (BGP) 193.48.8.0 in AS590 (database) and AS777 (BGP) 193.48.137.0 in AS1717 (database) and AS789 (BGP) 193.48.140.0 in AS1717 (database) and AS789 (BGP) 193.48.145.0 in AS1717 (database) and AS789 (BGP) 3) networks being routing but not yet allocated (here we only look at 193 networks). 193.0.0.0 not in database 193.0.1.0 not in database 193.0.2.0 not in database 193.0.4.0 not in database 193.0.5.0 not in database 193.59.44.0 not in database 193.59.45.0 not in database 193.59.46.0 not in database 193.59.47.0 not in database 193.61.100.0 not in database 193.61.101.0 not in database 193.64.34.0 not in database 193.68.160.0 not in database 193.74.254.0 not in database 193.84.50.0 not in database 193.84.51.0 not in database 193.112.27.0 not in database 193.120.248.0 not in database 193.128.85.0 not in database 193.166.40.0 not in database 193.166.64.0 not in database 193.166.66.0 not in database 193.196.9.0 not in database 4) networks in BGP routing tables with more than more originating AS. *** conflict 129.247.0.0 in AS1270 *** conflict 129.247.0.0 in AS1275 *** conflict 134.93.0.0 in AS1270 *** conflict 134.93.0.0 in AS1754 *** conflict 134.104.0.0 in AS1270 *** conflict 134.104.0.0 in AS1754 *** conflict 134.106.0.0 in AS1270 *** conflict 134.106.0.0 in AS1754 *** conflict 134.107.0.0 in AS1270 *** conflict 134.107.0.0 in AS1754 *** conflict 134.222.0.0 in AS286 *** conflict 134.222.0.0 in AS701 *** conflict 138.199.0.0 in AS1104 *** conflict 138.199.0.0 in AS1270 *** conflict 139.191.0.0 in AS1717 *** conflict 139.191.0.0 in AS559 *** conflict 141.2.0.0 in AS1275 *** conflict 141.2.0.0 in AS1754 *** conflict 147.196.0.0 in AS1717 *** conflict 147.196.0.0 in AS1899 *** conflict 148.6.0.0 in AS1955 *** conflict 148.6.0.0 in AS513 *** conflict 158.152.0.0 in AS1290 *** conflict 158.152.0.0 in AS1849 *** conflict 159.72.0.0 in AS1257 *** conflict 159.72.0.0 in AS1729 *** conflict 192.16.183.0 in AS1104 *** conflict 192.16.183.0 in AS1890 *** conflict 192.16.188.0 in AS1103 *** conflict 192.16.188.0 in AS1755 *** conflict 192.16.189.0 in AS1103 *** conflict 192.16.189.0 in AS1104 *** conflict 192.16.192.0 in AS1104 *** conflict 192.16.192.0 in AS786 *** conflict 192.42.129.0 in AS1103 *** conflict 192.42.129.0 in AS1104 *** conflict 192.70.89.0 in AS1717 *** conflict 192.70.89.0 in AS1899 *** conflict 192.70.90.0 in AS1717 *** conflict 192.70.90.0 in AS1899 *** conflict 192.87.4.0 in AS1104 *** conflict 192.87.4.0 in AS1755 *** conflict 192.124.28.0 in AS1275 *** conflict 192.124.28.0 in AS1754 *** conflict 192.134.91.0 in AS1717 *** conflict 192.134.91.0 in AS1899

2 1

Corrections in the RIPE Database
by Daniel Karrenberg 09 Mar '93

09 Mar '93

Folks, we have done some cleaning up of the RIPE database in order to preserve only information which the whois server actually displays and to prevent future update errors. The inconsistencies found were mainly unofficial *gd: fields which have been removed. The entries below have been modified in conjunction with the cleanup. Please note this in your records. Daniel *pn: Carmelo Lodato *ad: Centro Universitario di Calcolo (CUC) *ad: Viale delle Scienze *ad: I-90128 Palermo *ph: +39 91 6571984 *fx: +39 91 485872 *em: inox(a)ipacuc.cuc.unipa.it *ch: staff(a)nis.garr.it 930308 *so: RIPE *de: Italy deleted *pn: Giuseppe Puleo *ad: Centro Universitario di Calcolo (CUC) *ad: Viale delle Scienze *ad: I-90128 Palermo *ph: +39 91 6571984 *fx: +39 91 485872 *em: rpcmaint(a)ipacuc.cuc.unipa.it *ch: staff(a)nis.garr.it 930308 *so: RIPE *de: Italy deleted *pn: Massimo Tartamella *ad: Centro Universitario di Calcolo (CUC) *ad: Viale delle Scienze *ad: I-90128 Palermo *ph: +39 91 6571984 *fx: +39 91 485872 *em: max(a)ipacuc.cuc.unipa.it *ch: staff(a)nis.garr.it 930308 *so: RIPE *de: Italy deleted *pn: Maria Tortorici *ad: Centro Universitario di Calcolo (CUC) *ad: Viale delle Scienze *ad: I-90128 Palermo *ph: +39 91 6571984 *fx: +39 91 485872 *em: tortox(a)ipacuc.cuc.unipa.it *ch: staff(a)nis.garr.it 930308 *so: RIPE *de: Italy deleted *dn: nl *de: Top level domain for the Netherlands *de: c/o CWI, Kruislaan 413, NL 1098 SJ Amsterdam *ac: P.C. Baayen *tc: Piet Beertema *zc: Daniel Karrenberg *ns: sering.cwi.nl mcsun.eu.net sunic.sunet.se *ns: brouilly.inria.fr ns.uu.net aos.brl.mil *sd: 400net *sd: aasup abd ace agro agrobtc aha ahold aie akam alliant amolf and *sd: antenna archis artmediatech ascad ashton-tate asml asser atcmp *sd: audacter azn azr *sd: baan baltzer bazis bimbv bmc borsu brinkman bso bssi bull *sd: can cbm cbs cbsc ccsom chess chw cipher comcons compunication comtecno *sd: consul convex cpb cpu cri ctg cti-software cwi *sd: dasc dataman dcmr delftgeot delgeo dg digicash digitalis diho dobdh *sd: dupaco *sd: ecn eim elsevier encore esa eur *sd: fokker fom force5 fourc fousupp foxim frame franciscus *sd: gbsp gbu getronics geveke ghbo gig gli gobe group gti-ia *sd: hacktic harris hbg hbo-raad hcsvt hen hes-rdam hhg hhs hivnet *sd: hkl hku hmb hny hobby hro hsa hsbos hsdehorst hse hut hwb hzeeland *sd: iaf iahl iamcr ibmx400 ice icgned icim icin icl icodo ict idg ifla *sd: ihe impact inducom ingres integrity ioo irdeto isc island ita itc *sd: ittpub ixonet *sd: jason jrc *sd: kap kema khzeist kim kitlv knaw-bibl kncv knmi koha konbib ksepl *sd: ksla ktibv kub kun kvi *sd: leidenuniv li logos *sd: marin meteocon mey mh minow mmph motorola mpi *sd: nacee nbd nblc nboi ncs neabbs neddata nedlloyd neogeo nfra nhl nhtv *sd: nias nidi nih nijenrode nikhef nimex niob nioz nki nlbb nlbc nlr nluug *sd: nmi nota nrv ns nuclint nucphys nwo *sd: oba obdov obr obtilburg oce oceonics olivetti open-i oracle origin ouh *sd: pact parcom pbf pecoma pggm philips pica positronika prismia propell *sd: prvnh psyline ptt pttnwb pttrnl *sd: q8 *sd: rabo radix raet rare rcc-ivev rdm repko rgd rhg rhij rigo rijnh riks *sd: rivm rodelco rtm rug rulimburg ruu rvb rws *sd: sagan sara scp serc sgi sierra signaal skferc source spc spex stam stc *sd: stegge stork stw suaa sun surfbureau surfdiensten surfnet suub svo swets *sd: swidoc swov syllogic *sd: tasking technolution term1 thijssen thu-k tmu tno tpsc transfer *sd: translogic trc trendbox tudelft tue txbase *sd: uniface unisys univforhuman usn utwente uva *sd: valkieser vdl vdvalk vimec vmx vsnu vu *sd: wau west wkap wldelft wlink wmt wsf *sd: xelion xirion *sd: y-net yaupon *rm: fully-managed *ch: piet(a)cwi.nl 930303 *so: RIPE *em: hostmaster(a)cwi.nl deleted *in: 146.48.0.0 *na: CNR-FRASCATI *cy: IT *ac: Antonio_Blasco Bonito *tc: Pierluigi Zangari *co: CNR GARR RIPE EASI NSF *as: 137 *gw: cern *rz: 146.48.1.2 titan.ias.fra.cnr.it *rz: 192.12.192.4 nameserver.cnr.it *rm: Network of the CNR institutes in Frascati (Roma) *rm: Multiple-lan *rm: This net belongs to the nation-wide CNRnet, coordinated *rm: thru the cnr-core working group. CNRnet is member of GARR. *ch: ip-reg(a)nis.garr.it 920927 *ch: ripe-dbm(a)ripe.net 920927 *so: RIPE *zc: Pierluigi Zangari deleted

1 0

Internet connection wanted
by Anne Lord 05 Mar '93

05 Mar '93

Dear Mr Gleave, The RIPE NCC is an impartial organisation, so we are not able to recommend any particular service provider to you. We do however keep a mailing list to which any service provider can subscribe, and to which we forward all queries like yours. Someone from the list should be in touch with you shortly. If you have any further queries do not hesitate to contact us. Regards, Anne Lord RIPE NCC ------- Forwarded Message Date: Fri, 5 Mar 93 13:30:17 +0100 From: gleave(a)bouncr.enet.dec.com (05-Mar-1993 1226) To: ncc(a)ripe.net cc: gleave(a)VboRMC.vbo.dec.com Subject: How to obtain a connection to the Internet ? Hi, Just received this (>)paragraph as part of a response from NIC to my attached query. Anything further you can add ? Many thanks, John Gleave - ------------------------------------------------------------------------------- - ------------------ >I am attaching the latest list of Internet service providers. All address >registration for Europe is handled by the Network Coordination Center at >RIPE in The Netherlands. Their E-mail is "ncc(a)ripe.net". They may be able >to give additional assistance on providers. - ------------------------------------------------------------------------------- - ------------------ To: nm%vbormc::"nic(a)nic.ddn.mil" CC: gleave Subj: How to obtain a connection to the Internet ? Hi, I've just been checking through several of the documents available on "the Inte rnet" but can't seem to find any information on how to set up a physical connection. I have several customers here in the UK who would like to establish a connectio n (after obtaining official addresses of course). What are the options available to them ? Do they have to negotiate with a local education site (university, college) whi ch has access, or is there a commercial connection service available in the UK ? Are there other options available for private individuals ? I'd be grateful for any advice/pointers. Thanks in advance, John Gleave. UK CSO Service Centre, Digital Equipment Corporation ------- End of Forwarded Message

1 0

RIPE NCC Outage Today at 18:00 GMT+1
by RIPE NCC Staff 05 Mar '93

05 Mar '93

Colleagues, All NCC machines will be out of service today Friday March 5th at 18:00 GMT+1 for installation of additional disks and major file system rearrangements For this purpose, which we cannot just do in single user mode for those wondering, we will shutdown the complete NCC ethernet to avoid the loss of database updates or other messages when moving filesystems around. We think this whole operation will take some 2 hours, after which we will be back on the air. Apologies for any inconvenience, NCC Staff

1 0

in-addr.arpa zone data in RIPE database
by Daniel Karrenberg 03 Mar '93

03 Mar '93

Folks, since we have observed many inconsistencies between the RIPE database and the DNS regarding reverse mapping zones in in-addr.arpa we have developed a little checking script. The current output can be found in ftp.ripe.net:ripe/ripe-op/in-addr.check It lists all networks for which discrepancies have been detected as follows: First the RIPE database entry in short format: *in: 128.131.0.0 *na: TUNET-F *de: LAN Technical University of Vienna *cy: AT *ac: Johannes Demel *tc: Johannes Demel *co: LOCAL *as: 697 *rz: tunamea.tuwien.ac.at tunameb.tuwien.ac.at *ch: demel(a)noc.tuwien.ac.at 930202 *so: RIPE Then a list of all reverse servers as listed in the database: DB servers: tunamea.tuwien.ac.at tunameb.tuwien.ac.at Then a list of all reverse servers found in the DNS: DNS servers: Then a diagnostic each server which has something wrong: tunamea.tuwien.ac.at: only in DB and not reverse server for 128.131.0.0! tunameb.tuwien.ac.at: only in DB and not reverse server for 128.131.0.0! Then a list of suggested actions to resolve the inconsistency: DB remove 128.131.0.0: tunamea.tuwien.ac.at tunameb.tuwien.ac.at Note that the recommended actions are not the only way to resolve the problem. In the example above one could also set up the name servers and register them in the DNS. The script tries the shortes path. Please go through the list and see wether any of your nets needs action. Questions: Should we automatically make the suggested changes in the RIPE database? Or should we send mail to the technical contacts asking them to change things? We have asked the NIC accept change notices from us, so that registration of reverse servers in the database would be enough to get them into the DNS. Is this desirable? Daniel By way of example here is the start of the current file: *in: 128.131.0.0 *na: TUNET-F *de: LAN Technical University of Vienna *cy: AT *ac: Johannes Demel *tc: Johannes Demel *co: LOCAL *as: 697 *rz: tunamea.tuwien.ac.at tunameb.tuwien.ac.at *ch: demel(a)noc.tuwien.ac.at 930202 *so: RIPE DB servers: tunamea.tuwien.ac.at tunameb.tuwien.ac.at DNS servers: tunamea.tuwien.ac.at: is only in DB and is not reverse server for 128.131.0.0! tunameb.tuwien.ac.at: is only in DB and is not reverse server for 128.131.0.0! DB remove 128.131.0.0: tunamea.tuwien.ac.at tunameb.tuwien.ac.at *in: 129.177.0.0 *na: BERGEN-NET *de: Bergen University, Norway *cy: NO *ac: Kenneth Hostland *tc: Kenneth Hostland *co: NORDU RIPE NSF *as: 224 *gw: kth *rz: alf.uib.no eik.ii.uib.no aun.uninet.no *ch: ripe-dbm(a)ripe.net 920914 *so: RIPE DB servers: alf.uib.no aun.uninet.no eik.ii.uib.no DNS servers: alf.uib.no aun.uninett.no eik.ii.uib.no aun.uninet.no: is only in DB and does not exist! aun.uninett.no: is only in DNS and is OK DB add 129.177.0.0: aun.uninett.no DB remove 129.177.0.0: aun.uninet.no note: obiously a spelling error in the database *in: 129.206.0.0 *na: HD-NET *de: University of Heidelberg *de: BelWue *cy: DE *ac: Michael Hebgen *tc: Lothar Binding *tc: Peter Merdian *co: RIPE NSF WIN *rl: HEPNET *bl: DESY *as: 553 *gw: crn *rz: sun0.URZ.Uni-Heidelberg.DE sun1.URZ.Uni-Heidelberg.DE noc.BelWue.DE ns.Germany.EU.net deins.Informatik.Uni-Dortmund.DE *ch: rv(a)Informatik.Uni-Dortmund.DE 920530 *ch: ar(a)deins.Informatik.Uni-Dortmund.DE 920601 *ch: ripe-dbm(a)ripe.net 920602 *so: RIPE DB servers: deins.informatik.uni-dortmund.de noc.belwue.de ns.germany.eu.net sun0.urz.uni-heidelberg.de sun1.urz.uni-heidelberg.de DNS servers: sun0.urz.uni-heidelberg.de sun1.urz.uni-heidelberg.de deins.informatik.uni-dortmund.de: is only in DB and is OK noc.belwue.de: is only in DB and is OK ns.germany.eu.net: is only in DB and is OK DNS add 129.206.0.0: deins.informatik.uni-dortmund.de noc.belwue.de ns.germany.eu.net note: the DNS is missing some servers *in: 130.37.0.0 *na: VU-NET *de: Vrije Universiteit Amsterdam *de: Amsterdam *cy: NL *ac: Jacques Schuurman *tc: Jacques Schuurman *co: RIPE NSF SARA SURF *gw: cwi *rz: ohrid.cca.vu.nl *rz: star.cs.vu.nl *ch: dfk(a)cwi.nl 900802 *ch: Erik-Jan.Bos(a)surfnet.nl 920708 *ch: Erik-Jan.Bos(a)surfnet.nl 920708 *ch: ripe-dbm(a)ripe.net 920708 *ch: martijn(a)nluug.nl 921110 *so: RIPE DB servers: ohrid.cca.vu.nl star.cs.vu.nl DNS servers: hardy.nat.vu.nl ohrid.cca.vu.nl star.cs.vu.nl hardy.nat.vu.nl: is only in DNS and is OK DB add 130.37.0.0: hardy.nat.vu.nl *in: 130.192.0.0 *na: TORINO-IT-LAN *de: Politecnico di Torino *de: CISIP *cy: IT *ac: Silvano Gai *tc: Antonio Lioy *co: GARR *as: 137 *rz: 130.192.2.91 leonardo.polito.it *rz: 130.192.2.117 galileo.polito.it *rz: 130.192.3.1 ercole.polito.it *rz: 192.12.192.5 dns.nis.garr.it *rm: LAN's and MAN connecting University departments and *rm: research institutes located in or near Torino *rm: fully managed *ch: ip-reg(a)nis.garr.it 930115 *so: RIPE DB servers: dns.nis.garr.it ercole.polito.it galileo.polito.it jolly.nis.garr.it leonardo.polito.it DNS servers: dns.nis.garr.it ercole.polito.it galileo.polito.it leonardo.polito.it jolly.nis.garr.it: is only in DB and is OK DNS add 130.192.0.0: jolly.nis.garr.it note: the addresses in the database are not conforming to the database format, but the script resolves them and deletes duplicate entries *in: 130.231.0.0 *na: OUNET *de: University Ethernet network *de: Oulu University *de: Oulu *cy: FI *ac: Kaisu Ranta *tc: Raimo Salo *co: NORDU RIPE NSF FUNET *as: 1741 *rz: ousrvr.oulu.fi *ch: lk-kr(a)finou.oulu.fi 930119 *so: RIPE DB servers: ousrvr.oulu.fi DNS servers: hydra.helsinki.fi ousrvr.oulu.fi hydra.helsinki.fi: is only in DNS and is OK DB add 130.231.0.0: hydra.helsinki.fi *in: 130.251.0.0 *na: GENUANET *de: Universita' degli Studi di Genova *cy: IT *ac: Pier Paolo Puliafito *tc: Tiziana Podesta' *co: GARR *as: 137 *rz: 192.148.193.8 sun.cisi.unige.it SUN UNIX *rz: 130.251.1.4 dist.dist.unige.it SUN UNIX *rm: Multiple interconnected LANs of academic institutes *rm: located in Genoa *ch: ip-reg(a)nis.garr.it 930210 *so: RIPE DB servers: dist.dist.unige.it sun sun.cisi.unige.it unix DNS servers: carla.dist.unige.it dist.dist.unige.it nameserver.cnr.it carla.dist.unige.it: is only in DNS and is not responding! nameserver.cnr.it: is only in DNS and is OK sun: is only in DB and does not exist! sun.cisi.unige.it: is only in DB and is OK unix: is only in DB and does not exist! DB add 130.251.0.0: nameserver.cnr.it DNS add 130.251.0.0: sun.cisi.unige.it DB remove 130.251.0.0: sun unix note: "interesting" syntax server data seems out of date *in: 131.114.0.0 *na: PISA-NET *de: Consiglio Nazionale delle Ricerche *de: Pisa *cy: IT *ac: Marco Sommani *tc: Vittorio Miori *co: GARR *as: 137 *rz: 192.12.192.4 nameserver.cnr.it *rz: 128.84.254.152 odin.cs.cornell.edu *rz: 131.114.1.32 itgbox.cnuce.cnr.it *rz: 192.65.81.6 ns.surfnet.nl *rz: 131.114.21.10 serra.unipi.it *rm: Multiple-Lan of CNR institutes and University departments in Pisa *rm: This net belongs to the nation-wide CNRnet, coordinated *rm: thru the cnr-core working group. CNRnet is member of GARR. *ch: ip-reg(a)nis.garr.it 930204 *so: RIPE DB servers: itgbox.cnuce.cnr.it nameserver.cnr.it ns.surfnet.nl odin.cs.cornell.edu serra.unipi.it survey.surfnet.nl DNS servers: itgbox.cnuce.cnr.it nameserver.cnr.it ns.surfnet.nl odin.cs.cornell.edu serra.unipi.it survey.surfnet.nl: is only in DB and is OK DNS add 131.114.0.0: survey.surfnet.nl *in: 131.155.0.0 *na: TUENET1 *de: Technische Universiteit Eindhoven *de: Eindhoven *cy: NL *ac: Joop Schillemans *tc: Joep Brand *co: RIPE NSF SURF *ni: 1=590 *rz: tuegate.tue.nl *ch: piet(a)cwi.nl 910501 *so: RIPE DB servers: tuegate.tue.nl DNS servers: rc6.urc.tue.nl tuegate.tue.nl rc6.urc.tue.nl: is only in DNS and is OK DB add 131.155.0.0: rc6.urc.tue.nl *in: 131.174.0.0 *na: NUNET *de: Universiteit Nijmegen *de: Nijmegen *cy: NL *ac: Jos Alsters *ac: Peter van Campen *tc: Jos Alsters *tc: Peter van Campen *co: RIPE NSF SURF *ni: 1=590 *rz: wn1.sci.kun.nl *rz: wn3.sci.kun.nl *ch: piet(a)cwi.nl 910501 *so: RIPE DB servers: wn1.sci.kun.nl wn3.sci.kun.nl DNS servers: wn0.sci.kun.nl wn3.sci.kun.nl wn0.sci.kun.nl: is only in DNS and is OK wn1.sci.kun.nl: is only in DB and does not exist! DB add 131.174.0.0: wn0.sci.kun.nl DB remove 131.174.0.0: wn1.sci.kun.nl *in: 131.211.0.0 *na: RUUNET *de: Universiteit Utrecht *de: Utrecht *cy: NL *ac: Dre Hopmans *tc: Dre Hopmans *co: RIPE NSF SURF *ni: 1=590 *rz: accucx.cc.ruu.nl *rz: praxis.cs.ruu.nl *ch: piet(a)cwi.nl 910501 *so: RIPE DB servers: accucx.cc.ruu.nl praxis.cs.ruu.nl DNS servers: accucx.cc.ruu.nl infix.cs.ruu.nl kali.cc.ruu.nl infix.cs.ruu.nl: is only in DNS and is OK kali.cc.ruu.nl: is only in DNS and is OK praxis.cs.ruu.nl: is only in DB and is not responding! DB add 131.211.0.0: infix.cs.ruu.nl kali.cc.ruu.nl

5 15

Re: in-addr.arpa zone data in RIPE database
by jalm＠spirou.puug.pt 03 Mar '93

03 Mar '93

...... Still, there are the issues of the DNS versus the DB, but I feel that others are already dealing with that one ;-) In the previous discussion concerning DNS and RIPE database coherence, I think that we should try to keep separate different issues (DNS and RIPE dbm). 1) We have a system designed to deal with addressing, naming servers, etc. the DNS. We should concentrate on this system for this purpose. It should be considered the real source of information for the data it as been designed to deal with. So, the place were I can find the information about servers, addresses, etc. is in the DNS. Well, DNS has been designed to be managed in a decentralized way. This is a very good point but it has a very bad point: in general it contains lots of errors and inconsistencies. Conclusion: we should invest in tools to detect such errors and notify the administrators concerned. There are some of these tools available in the archive of RIPE. Anyway, I, as an administrator, would prefer to have a single point of focus for stating which are the servers running authoritative for my domain or for the reverse mapping of my network and that is the DNS, nothing more. 2) We have the RIPE database: this is a very good tool to deal with some administrative data. Well, lets use it for this purpose. Anyway, we should avoid to have to deal manually with DUPLICATE data. So, we should avoid to have information about servers and addresses of those servers in the RIPE dbm. My suggestion is: use the RIPE dbm to deal * only * with those informations that cannot be effectively registered in the DNS. If we decide to maintain in the RIPE dbm information about DNS servers, those fields should be automatically updated from the DNS on a (for example) monthly basis. And its semantics should be seen as "the vison about this subject that the tools of the RIPE NCC have been able to extract from the DNS some XXX days ago". I do not believe on centralized repositories and management unless I have no other way to avoid it. I do not believe in consistency maintained mannually by hundreds (thousands ?) of administrators. Jose'

2 1

Re: draft IP request template
by Anne Lord 03 Mar '93

03 Mar '93

> > I have only one remark which I already made in Prague, I think. > iso-cc is not a good name for the network location tag, it is far too > criptic. I propose net-country. accepted and changed. > I have a comment on: > > This document is valid until <expiry date>. An updated document can be > We need to define a revision schedule to be able to specify an expiry date, > I think. I would try to avoid different expiry dates for different countrie > s > or different service providers. We all need to know which is the right > version of template to be given to requestors at a certain date. Well i would be responsible for sending out to all local registries via the local-ir list, the updated copy both .lpr and .ps versions at say 3 monthly intervals (just after RIPE meetings I propose). I would also of course ensure that the most up to date document is in the document store. It would be up to each local registry to maintain their local language versions. However, the NCC version of the template will be slightly different from the one that will be used by local registries (it is more verbose), so either we maintain two documents : the RIPE NCC template and one for local registries OR local registries delete the parts that dont apply. It would probably be less confusing to have 2 separate documents. But you will in any case have to add your own contact details to the template. > > > Then, I found some typos; look below for replacement lines beginning with $ > $ corrected all the typos. Many thanks for your comments. Anne.

1 0

RE: in-addr.arpa zone data in RIPE database
by Wilfried Woeber, UniVie/ACOnet, +43 1 436111 355 02 Mar '93

02 Mar '93

>Questions: Should we automatically make the suggested changes in the > RIPE database? No. > Or should we send mail to the technical contacts asking them > to change things? Yes, however it could be a good idea to CC to the local-ir contacts. At least for ".AT" I'd like to have this information. >DB remove 129.177.0.0: aun.uninet.no > > note: obiously a spelling error in the database :-)) Wilfried.

1 0

Re: in-addr.arpa zone data in RIPE database
by keith＠pipex.net 02 Mar '93

02 Mar '93

In <9303021347.AA06706(a)mcsun.EU.net>, <Piet.Beertema(a)mcsun.EU.net> wrote: > Interaction is fine. But RIPE stepping into someone else's > authority is quite something different! > I don't see any problem with that as long as we (european > networking people) agree to send update to the RIPE-NCC > instead of sending them to the NIC. > RIPE-DB and DNS are entirely different objects. I would > like RIPE to notify me *in some cases* about discrepancies > between my entries in the RIPE-DB and my DNS entries, but > I do *NOT* want RIPE to step into my authority by asking > or telling the NIC to change *MY* DNS info because they > found discrepancies: I may well have good reason why those > discrepancies exist. This is a bit of an aside to the debate above, but there is something that has struck me as obvious which would make the management of in-addr.arpa much easier for everyone, and help with the above issue. Why not get all of 193.in-addr.arpa delegated to the RIPE NCC, and have it in turn delegate xx.193.in-addr.arpa to the service providers ? That way we don't have to deal directly with the creaking NIC, but authority is still delineated clearly by existing DNS mechanisms. This has not been possible in the past, due to the restriction of in-addr DNS delegations needing to be on byte boundaries, *but* that is exactly how the RIPE supernet block is being assigned. Or have I missed a good reason why this won't work ? Keith Mitchell Network Manager Public IP Exchange keith(a)pipex.net 216 The Science Park keith(a)unipalm.co.uk Cambridge, UK Phone: +44 223-424616 Fax: +44 223-426868

3 2