From Daniel.Karrenberg at ripe.net Mon Jul 3 16:52:12 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 03 Jul 1995 16:52:12 +0200 Subject: New Document available: ripe-127 In-Reply-To: Your message of Fri, 30 Jun 1995 21:34:04 MDT. <199506301934.VAA18696@pax.inria.fr> References: <199506301934.VAA18696@pax.inria.fr> Message-ID: <9507031452.AA19933@ncc.ripe.net> > christian.huitema at sophia.inria.fr (Christian Huitema) ecriverat: > > Given that interest for these matters spreads well outside Europe, could > you please consider submitting this as an informational RFC? > > Christian Huitema I have no problem with it whatsoever. I will contact the RFC editor about this. Amicalement Daniel From ncc at ripe.net Tue Jul 4 15:24:41 1995 From: ncc at ripe.net (RIPE NCC Staff) Date: Tue, 04 Jul 1995 15:24:41 +0200 Subject: IMPROTANT: RIPE22 date change Message-ID: <9507041324.AA00304@ncc.ripe.net> Due to accomodation problems, the date of the 22nd RIPE meeting had to be changed from 2-4 October to 11-13 October. We apalogise for any inconvenience this may cause. There is no official announcement for RIPE22 out yet, but this seemed important enough to note already. Kind regards, Roderik Muit RIPE NCC From root at glas.apc.org Wed Jul 5 13:56:00 1995 From: root at glas.apc.org (Operator) Date: Wed, 5 Jul 95 15:56 +0400 Subject: subscription request Message-ID: subscribe alexz at glas.apc.org From Daniel.Karrenberg at ripe.net Fri Jul 7 10:05:19 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 07 Jul 1995 10:05:19 +0200 Subject: Short RIPE NCC Report for June Message-ID: <9507070805.AA01780@ncc.ripe.net> As has been reported earlier this year, the RIPE NCC is currently severely under-resourced. As a consequence, it has been impossible for us to report to you formally and in full about the activities of the RIPE NCC as we have done in the past. While we very much regret the situation we hope to keep you informed with a series of short informal reports. The report below summarises our activities up to July 1995. Summary The registration services still operate at capacity. We are hiring new personnel to cope with this. We have started the training courses for new local Internet registries. A new tool for speeding up reverse domain delegations is now in use. Database improvements are being implemented. We are implementing a request tracking system. Work on next year's charging scheme is behind schedule and progressing slowly. Registration Services (hostmaster) The backlog in registration services has been more or less constant at around 125 messages which equals about 70 requests. We have hired 2.6 FTE of junior hostmasters to help cope with this problem. The current expectation is that this backlog will be cleared during September. Training We have taught the first Local Internet Registry course in Amsterdam. It has been well received. We are currently revising the course according to the excellent feedback received. More courses are scheduled in Germany (full), Austria, the UK, Italy, and at the NCC in Amsterdam. The dates will be announced as soon as they are fixed. If you would like to host such a course and a minimum of six contributing Local IRs are likely to attend, please contact training at ripe.net to see whether we can accomodate you. All courses will be announced on the local-ir mailing list and are open to all contributing registries on a first come first served basis. If there is high demand for a particular course we will have to restrict the number of persons from each registry. Reverse Domain Delegations There is a new mail responder tool at which automatically checks delegation requests for reverse domains, e.g. subdomains of 193.in-addr.arpa and 194.in-addr.arpa. Requests are only forwarded to registration services staff after they have passed all checks. This reduces turnaround times and relieves the registration services staff at the same time. Database We are working on database software enhancements in the areas of hierarchical authorisation and logging/exchange. The former will be a means to authorise creation of objects below a node in a hierarchical key space (domain names, addresses). The main application is to prevent erroneous registration of address space assignments. The improvements in logging will make it possible to run real time secondary copies of databases. Staffing Els Willems has started as new junior hostmaster on July 3rd. She joins us from the Dutch foundation for computer algebra. Els will work part time 4days/week initially reducing to 3days/week later in the year. Unfortunately (for us) Anne Lord will leave us on July 14th and move back to her home country for new challenges at a major service provider. We at the NCC will miss her and her contribution to our success. We hope that Anne can join us at the next RIPE meeting for a 'formal' farewell from the RIPE community. We will advertise to fill Anne's position shortly. In the meantime our UK contingent will be replenished by Nick Reid who has been hired as a full time junior hostmaster. Nick will start August 28th. As reported in Rome we have also hired Hatice Kuey from Turkey as a junior hostmaster. The expectation was that she would join us in June. Unfortunately and unknown to us at the time, Dutch employment laws have changed in April, making it much harder to employ people from outside the EC. We are currently working with the Dutch employment authorities to resolve this. Given the increasing amount of new registries in the Eastern Mediterranean and the Middle East we think it is very important to have this area 'represented' in our staff. Plans for this month Registration services urgently need the improvement of our ticketing system into a real request tracking system. Currently the needed functionality is being specified and we hope to start implementation this month with a gradual phase-in of new functionality. We plan to issue a basic proposal for next years charging model. Due to the staff shortage and pressure on registration services not much work has been done to date. The proposal is thus expected to be simple and basic. If you have any further questions, please do not hesitate to contact me. Regards Daniel Karrenberg RIPE NCC Manager From Daniel.Karrenberg at ripe.net Fri Jul 7 11:11:41 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 07 Jul 1995 11:11:41 +0200 Subject: Aggregation Message-ID: <9507070911.AA02565@ncc.ripe.net> Dear colleagues, it is time for *everybody* to think again about aggregating CIDRable routes. It is *high time* for everyone near the top of the list below and especially those with hosts/route at or around 256. There is lots of potential aggregation here! If you have any further questions, please do not hesitate to contact me. Regards Daniel Karrenberg RIPE NCC Manager /16 block hosts routes hosts addres- / sed route 193.6.0.0 37120 145 256 193.40.0.0 65536 143 458 193.224.0.0 33792 132 256 194.77.0.0 65536 98 668 193.232.0.0 36608 78 469 193.87.0.0 21504 74 290 193.48.0.0 39680 70 566 193.52.0.0 39168 69 567 193.104.0.0 46848 68 688 193.210.0.0 46080 66 698 193.54.0.0 32512 66 492 193.49.0.0 36608 63 581 193.55.0.0 39680 61 650 193.51.0.0 34048 59 577 194.136.0.0 25856 52 497 194.130.0.0 65536 49 1337 193.105.0.0 44032 43 1024 194.44.0.0 11008 43 256 194.142.0.0 11008 43 256 194.57.0.0 30976 40 774 193.50.0.0 25600 40 640 193.84.0.0 49920 39 1280 193.143.0.0 13312 38 350 194.89.0.0 9728 38 256 194.112.0.0 9728 38 256 193.225.0.0 9216 36 256 194.111.0.0 8960 35 256 193.124.0.0 139520 32 4360 194.42.0.0 8448 32 264 193.64.0.0 145408 30 4846 193.226.0.0 20480 30 682 193.211.0.0 7680 30 256 194.98.0.0 9472 29 326 193.8.0.0 65536 27 2427 193.198.0.0 6912 27 256 193.42.0.0 18176 24 757 193.180.0.0 18688 23 812 193.43.0.0 7680 23 333 194.85.0.0 15104 22 686 193.106.0.0 65536 21 3120 193.235.0.0 15104 21 719 193.23.0.0 5376 21 256 194.68.0.0 13568 19 714 193.199.0.0 6144 19 323 193.116.0.0 4864 19 256 193.36.0.0 8960 18 497 194.59.0.0 6400 18 355 193.209.0.0 4608 18 256 193.166.0.0 135936 17 7996 193.35.0.0 16128 17 948 194.49.0.0 5120 17 301 193.234.0.0 4864 17 286 194.55.0.0 11520 16 720 193.101.0.0 8960 16 560 193.56.0.0 4864 16 304 193.142.0.0 4352 16 272 193.121.0.0 4096 16 256 194.97.0.0 65536 15 4369 194.2.0.0 65536 15 4369 194.14.0.0 5888 15 392 193.107.0.0 5632 15 375 193.190.0.0 32768 14 2340 194.90.0.0 24576 14 1755 193.32.0.0 11520 14 822 194.39.0.0 8448 14 603 194.78.0.0 3584 14 256 193.97.0.0 17152 13 1319 193.183.0.0 13312 13 1024 194.8.0.0 8448 13 649 193.95.0.0 3328 13 256 194.87.0.0 65536 12 5461 193.186.0.0 4096 12 341 193.93.0.0 2816 12 234 193.96.0.0 526848 11 47895 193.98.0.0 11520 11 1047 193.128.0.0 264448 10 26444 193.140.0.0 65536 10 6553 193.30.0.0 6656 10 665 193.181.0.0 3328 10 332 194.101.0.0 2560 10 256 193.12.0.0 264960 9 29440 194.45.0.0 65536 9 7281 193.5.0.0 65536 9 7281 193.25.0.0 19968 9 2218 193.22.0.0 8960 9 995 194.140.0.0 7680 9 853 193.182.0.0 6912 9 768 194.15.0.0 6400 9 711 193.188.0.0 5632 9 625 193.102.0.0 4096 9 455 193.125.0.0 2304 9 256 193.195.0.0 65536 8 8192 193.141.0.0 65536 8 8192 193.92.0.0 65024 8 8128 194.50.0.0 46592 8 5824 193.202.0.0 18176 8 2272 193.172.0.0 15872 8 1984 193.37.0.0 11776 8 1472 193.218.0.0 2304 8 288 194.60.0.0 2048 8 256 194.160.0.0 2048 8 256 193.94.0.0 2048 8 256 193.57.0.0 2048 8 256 193.208.0.0 2048 8 256 194.70.0.0 65536 7 9362 194.157.0.0 65536 7 9362 193.66.0.0 65536 7 9362 193.10.0.0 65536 7 9362 194.108.0.0 37888 7 5412 193.162.0.0 19456 7 2779 193.219.0.0 17664 7 2523 194.35.0.0 10496 7 1499 193.26.0.0 5376 7 768 193.103.0.0 3840 7 548 194.76.0.0 2048 7 292 193.138.0.0 1536 7 219 193.38.0.0 29440 6 4906 193.65.0.0 17664 6 2944 193.17.0.0 10240 6 1706 193.16.0.0 9728 6 1621 193.29.0.0 6400 6 1066 194.41.0.0 5376 6 896 193.46.0.0 5376 6 896 193.100.0.0 3328 6 554 194.106.0.0 3072 6 512 194.28.0.0 1536 6 256 194.110.0.0 1536 6 256 193.227.0.0 1536 6 256 194.64.0.0 65536 5 13107 193.77.0.0 65536 5 13107 193.68.0.0 65536 5 13107 193.221.0.0 21248 5 4249 193.3.0.0 9728 5 1945 193.73.0.0 8960 5 1792 193.148.0.0 3072 5 614 194.5.0.0 2304 5 460 194.33.0.0 2304 5 460 194.36.0.0 2048 5 409 193.114.0.0 2048 5 409 194.71.0.0 1536 5 307 193.31.0.0 1536 5 307 194.113.0.0 1280 5 256 193.160.0.0 1280 5 256 193.112.0.0 525824 4 131456 193.184.0.0 131840 4 32960 193.76.0.0 65536 4 16384 193.113.0.0 65536 4 16384 194.104.0.0 17664 4 4416 193.168.0.0 17408 4 4352 194.117.0.0 12288 4 3072 194.109.0.0 6144 4 1536 193.99.0.0 5120 4 1280 194.62.0.0 4352 4 1088 193.28.0.0 3072 4 768 193.175.0.0 3072 4 768 194.99.0.0 2816 4 704 194.149.0.0 2560 4 640 194.127.0.0 1536 4 384 194.10.0.0 1024 4 256 193.53.0.0 1024 4 256 193.39.0.0 1024 4 256 193.252.0.0 1024 4 256 193.122.0.0 196608 3 65536 193.204.0.0 136192 3 45397 194.128.0.0 132352 3 44117 193.72.0.0 131584 3 43861 193.174.0.0 131584 3 43861 194.86.0.0 65536 3 21845 194.58.0.0 65536 3 21845 194.115.0.0 65536 3 21845 193.70.0.0 65536 3 21845 193.69.0.0 65536 3 21845 193.1.0.0 65536 3 21845 194.54.0.0 10240 3 3413 193.9.0.0 4608 3 1536 193.118.0.0 4608 3 1536 194.116.0.0 4096 3 1365 194.32.0.0 2560 3 853 194.155.0.0 2560 3 853 193.24.0.0 2560 3 853 193.130.0.0 2560 3 853 193.117.0.0 2560 3 853 193.187.0.0 2304 3 768 194.164.0.0 1792 3 597 194.107.0.0 1792 3 597 194.165.0.0 1536 3 512 194.40.0.0 768 3 256 194.37.0.0 768 3 256 194.34.0.0 768 3 256 194.29.0.0 768 3 256 194.24.0.0 768 3 256 194.137.0.0 768 3 256 194.132.0.0 768 3 256 194.124.0.0 768 3 256 194.11.0.0 768 3 256 193.63.0.0 768 3 256 193.34.0.0 768 3 256 193.248.0.0 768 3 256 193.243.0.0 768 3 256 194.16.0.0 524544 2 262272 193.44.0.0 132096 2 66048 193.80.0.0 131328 2 65664 194.92.0.0 65536 2 32768 194.72.0.0 65536 2 32768 194.66.0.0 65536 2 32768 194.52.0.0 65536 2 32768 194.51.0.0 65536 2 32768 194.4.0.0 65536 2 32768 193.79.0.0 65536 2 32768 193.78.0.0 65536 2 32768 193.71.0.0 65536 2 32768 193.67.0.0 65536 2 32768 193.59.0.0 65536 2 32768 193.246.0.0 65536 2 32768 193.136.0.0 65536 2 32768 193.120.0.0 65536 2 32768 194.93.0.0 17408 2 8704 194.67.0.0 16384 2 8192 193.7.0.0 16384 2 8192 193.242.0.0 12288 2 6144 193.222.0.0 12288 2 6144 194.53.0.0 8192 2 4096 194.30.0.0 8192 2 4096 194.100.0.0 8192 2 4096 194.158.0.0 3072 2 1536 194.154.0.0 2304 2 1152 193.131.0.0 2048 2 1024 193.115.0.0 1280 2 640 194.61.0.0 768 2 384 194.21.0.0 768 2 384 193.178.0.0 768 2 384 194.56.0.0 512 2 256 194.184.0.0 512 2 256 194.167.0.0 512 2 256 194.152.0.0 512 2 256 194.114.0.0 512 2 256 193.91.0.0 512 2 256 193.47.0.0 512 2 256 193.236.0.0 512 2 256 193.185.0.0 512 2 256 193.161.0.0 512 2 256 193.60.0.0 262144 1 262144 193.88.0.0 131072 1 131072 193.212.0.0 131072 1 131072 193.196.0.0 131072 1 131072 193.170.0.0 131072 1 131072 193.156.0.0 131072 1 131072 193.144.0.0 131072 1 131072 193.134.0.0 131072 1 131072 193.132.0.0 131072 1 131072 194.94.0.0 65536 1 65536 194.91.0.0 65536 1 65536 194.84.0.0 65536 1 65536 194.81.0.0 65536 1 65536 194.80.0.0 65536 1 65536 194.7.0.0 65536 1 65536 194.65.0.0 65536 1 65536 194.47.0.0 65536 1 65536 194.46.0.0 65536 1 65536 194.27.0.0 65536 1 65536 194.178.0.0 65536 1 65536 194.172.0.0 65536 1 65536 194.171.0.0 65536 1 65536 194.163.0.0 65536 1 65536 194.159.0.0 65536 1 65536 194.151.0.0 65536 1 65536 194.150.0.0 65536 1 65536 194.144.0.0 65536 1 65536 194.143.0.0 65536 1 65536 194.139.0.0 65536 1 65536 194.135.0.0 65536 1 65536 194.120.0.0 65536 1 65536 193.90.0.0 65536 1 65536 193.86.0.0 65536 1 65536 193.85.0.0 65536 1 65536 193.83.0.0 65536 1 65536 193.82.0.0 65536 1 65536 193.75.0.0 65536 1 65536 193.74.0.0 65536 1 65536 193.4.0.0 65536 1 65536 193.233.0.0 65536 1 65536 193.207.0.0 65536 1 65536 193.2.0.0 65536 1 65536 193.146.0.0 65536 1 65536 193.127.0.0 65536 1 65536 193.126.0.0 65536 1 65536 194.13.0.0 32768 1 32768 194.9.0.0 16384 1 16384 194.166.0.0 16384 1 16384 194.12.0.0 16384 1 16384 193.230.0.0 16384 1 16384 194.96.0.0 8192 1 8192 194.179.0.0 8192 1 8192 194.148.0.0 8192 1 8192 194.102.0.0 8192 1 8192 193.13.0.0 8192 1 8192 194.141.0.0 4096 1 4096 194.125.0.0 4096 1 4096 193.240.0.0 4096 1 4096 194.88.0.0 2048 1 2048 194.25.0.0 2048 1 2048 194.118.0.0 2048 1 2048 193.27.0.0 2048 1 2048 193.254.0.0 2048 1 2048 193.229.0.0 2048 1 2048 194.6.0.0 1024 1 1024 194.26.0.0 1024 1 1024 194.20.0.0 1024 1 1024 194.153.0.0 1024 1 1024 193.89.0.0 1024 1 1024 193.176.0.0 1024 1 1024 194.177.0.0 512 1 512 194.156.0.0 512 1 512 194.133.0.0 512 1 512 194.126.0.0 512 1 512 193.197.0.0 512 1 512 194.69.0.0 256 1 256 194.170.0.0 256 1 256 194.161.0.0 256 1 256 194.134.0.0 256 1 256 194.103.0.0 256 1 256 193.61.0.0 256 1 256 193.241.0.0 256 1 256 193.223.0.0 256 1 256 193.203.0.0 256 1 256 193.194.0.0 256 1 256 193.163.0.0 256 1 256 193.154.0.0 256 1 256 193.129.0.0 256 1 256 193.119.0.0 256 1 256 From Daniel.Karrenberg at ripe.net Fri Jul 7 11:17:20 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 07 Jul 1995 11:17:20 +0200 Subject: CIDRers Hall of Fame Message-ID: <9507070917.AA02661@ncc.ripe.net> As a companion to my call for CIDRisation, here is a list of the good guys, roughly sorted by 'goodness'. In the name of the Internet community: Thanks folks! Daniel /16 block hosts routes hosts addres- / sed route 194.16.0.0 524544 2 262272 193.60.0.0 262144 1 262144 193.112.0.0 525824 4 131456 193.88.0.0 131072 1 131072 193.212.0.0 131072 1 131072 193.196.0.0 131072 1 131072 193.170.0.0 131072 1 131072 193.156.0.0 131072 1 131072 193.144.0.0 131072 1 131072 193.134.0.0 131072 1 131072 193.132.0.0 131072 1 131072 193.44.0.0 132096 2 66048 193.80.0.0 131328 2 65664 194.94.0.0 65536 1 65536 194.91.0.0 65536 1 65536 194.84.0.0 65536 1 65536 194.81.0.0 65536 1 65536 194.80.0.0 65536 1 65536 194.7.0.0 65536 1 65536 194.65.0.0 65536 1 65536 194.47.0.0 65536 1 65536 194.46.0.0 65536 1 65536 194.27.0.0 65536 1 65536 194.178.0.0 65536 1 65536 194.172.0.0 65536 1 65536 194.171.0.0 65536 1 65536 194.163.0.0 65536 1 65536 194.159.0.0 65536 1 65536 194.151.0.0 65536 1 65536 194.150.0.0 65536 1 65536 194.144.0.0 65536 1 65536 194.143.0.0 65536 1 65536 194.139.0.0 65536 1 65536 194.135.0.0 65536 1 65536 194.120.0.0 65536 1 65536 193.90.0.0 65536 1 65536 193.86.0.0 65536 1 65536 193.85.0.0 65536 1 65536 193.83.0.0 65536 1 65536 193.82.0.0 65536 1 65536 193.75.0.0 65536 1 65536 193.74.0.0 65536 1 65536 193.4.0.0 65536 1 65536 193.233.0.0 65536 1 65536 193.207.0.0 65536 1 65536 193.2.0.0 65536 1 65536 193.146.0.0 65536 1 65536 193.127.0.0 65536 1 65536 193.126.0.0 65536 1 65536 193.122.0.0 196608 3 65536 193.96.0.0 526848 11 47895 193.204.0.0 136192 3 45397 194.128.0.0 132352 3 44117 193.72.0.0 131584 3 43861 193.174.0.0 131584 3 43861 193.184.0.0 131840 4 32960 194.92.0.0 65536 2 32768 194.72.0.0 65536 2 32768 194.66.0.0 65536 2 32768 194.52.0.0 65536 2 32768 194.51.0.0 65536 2 32768 194.4.0.0 65536 2 32768 194.13.0.0 32768 1 32768 193.79.0.0 65536 2 32768 193.78.0.0 65536 2 32768 193.71.0.0 65536 2 32768 193.67.0.0 65536 2 32768 193.59.0.0 65536 2 32768 193.246.0.0 65536 2 32768 193.136.0.0 65536 2 32768 193.120.0.0 65536 2 32768 193.12.0.0 264960 9 29440 193.128.0.0 264448 10 26444 194.86.0.0 65536 3 21845 194.58.0.0 65536 3 21845 194.115.0.0 65536 3 21845 193.70.0.0 65536 3 21845 193.69.0.0 65536 3 21845 193.1.0.0 65536 3 21845 194.9.0.0 16384 1 16384 194.166.0.0 16384 1 16384 194.12.0.0 16384 1 16384 193.76.0.0 65536 4 16384 193.230.0.0 16384 1 16384 193.113.0.0 65536 4 16384 194.64.0.0 65536 5 13107 193.77.0.0 65536 5 13107 193.68.0.0 65536 5 13107 194.70.0.0 65536 7 9362 194.157.0.0 65536 7 9362 193.66.0.0 65536 7 9362 193.10.0.0 65536 7 9362 194.93.0.0 17408 2 8704 194.96.0.0 8192 1 8192 194.67.0.0 16384 2 8192 194.179.0.0 8192 1 8192 194.148.0.0 8192 1 8192 194.102.0.0 8192 1 8192 193.7.0.0 16384 2 8192 193.195.0.0 65536 8 8192 193.141.0.0 65536 8 8192 193.13.0.0 8192 1 8192 193.92.0.0 65024 8 8128 193.166.0.0 135936 17 7996 194.45.0.0 65536 9 7281 193.5.0.0 65536 9 7281 193.140.0.0 65536 10 6553 193.242.0.0 12288 2 6144 193.222.0.0 12288 2 6144 194.50.0.0 46592 8 5824 194.87.0.0 65536 12 5461 194.108.0.0 37888 7 5412 193.38.0.0 29440 6 4906 193.64.0.0 145408 30 4846 194.104.0.0 17664 4 4416 194.97.0.0 65536 15 4369 194.2.0.0 65536 15 4369 193.124.0.0 139520 32 4360 193.168.0.0 17408 4 4352 193.221.0.0 21248 5 4249 194.53.0.0 8192 2 4096 194.30.0.0 8192 2 4096 194.141.0.0 4096 1 4096 194.125.0.0 4096 1 4096 194.100.0.0 8192 2 4096 193.240.0.0 4096 1 4096 194.54.0.0 10240 3 3413 193.106.0.0 65536 21 3120 194.117.0.0 12288 4 3072 193.65.0.0 17664 6 2944 193.162.0.0 19456 7 2779 193.219.0.0 17664 7 2523 193.8.0.0 65536 27 2427 193.190.0.0 32768 14 2340 193.202.0.0 18176 8 2272 193.25.0.0 19968 9 2218 194.88.0.0 2048 1 2048 194.25.0.0 2048 1 2048 194.118.0.0 2048 1 2048 193.27.0.0 2048 1 2048 193.254.0.0 2048 1 2048 193.229.0.0 2048 1 2048 From Daniel.Karrenberg at ripe.net Fri Jul 7 14:43:25 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 07 Jul 1995 14:43:25 +0200 Subject: Wanted at the RIPE NCC: Senior Hostmaster Message-ID: <9507071243.AA05769@ncc.ripe.net> Please distribute this announcement to all possibly interested parties. Thank you Daniel Karrenberg RIPE NCC Manager RIPE: Coordinating the Internet in Europe. Because one of our staff moves on to a major Internet service provider there is an immediate opening at the RIPE NCC for a Senior Hostmaster 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 The specific duties of the vacant position: - to deal with non-routine address space requests - to support local registries where needed - to review assignments made by other registries - to liaise with other senior staff about registry matters - to supervise and support junior staff - to help provide training local registries - to take resoponsibility for one or more other NCC activities The senior hostmaster reports to the NCC manager. 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 - sound engineering knowledge about the Internet - experience with operating Internet networks - experience with Unix and X-windows based computer tools - ability to perform administrative tasks reliably - good knowledge of written and spoken English - good communication skills Desirable - work experience in an international environment - experience with Internet service provision Female applicants and applicants from all European countries are explicitly encouraged to apply. Depending on their ambitions and abilities senior hostmasters can be promoted to more 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 May 1995 1463816 hosts were registered on RIPE coordinated networks. The total number of systems reachable on the Internet worldwide is estimated at more than 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 by 9 full time employees: one NCC manager three senior hostmasters four junior hostmasters (2 of which starting in August) one administrative staff 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 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 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 July 23rd 1995. Applications by electronic mail are perfectly acceptable. We accept plain ASCII or PostScript. All applications by e-mail will be acknowledged. From tim at Relcom.EU.net Fri Jul 7 18:10:26 1995 From: tim at Relcom.EU.net (Andrew Timonin) Date: Fri, 7 Jul 1995 20:10:26 +0400 Subject: Aggregation In-Reply-To: <9507070911.AA02565@ncc.ripe.net>; from Daniel Karrenberg at Fri, 07 Jul 1995 11:11:41 +0200 References: <9507070911.AA02565@ncc.ripe.net> Message-ID: Dear colleagues, In message <9507070911.AA02565 at ncc.ripe.net> Daniel Karrenberg writes: >it is time for *everybody* to think again about aggregating >CIDRable routes. It is *high time* for everyone near the >top of the list below and especially those with hosts/route >at or around 256. There is lots of potential aggregation here! > >If you have any further questions, please do not hesitate to contact me. The main problem is that sometimes after registering one or several networks our customer goes to another service provider. Our blocks are mentioned in the list: > /16 block hosts routes hosts > addres- / > sed route > >193.124.0.0 139520 32 4360 >193.125.0.0 2304 9 256 >194.58.0.0 65536 3 21845 It seems to almost OK with 194.58.0.0/16 block, but 193.124/15 block was delegated for all former Soviet Union. Usually customers are not willing to return their networks to us, because in this case they should 1) writeup some forms to get new networks, and 2) (which is much harder) reconfigure all their hosts and routers. They are also facing with possible DNS problems. The situation is even worse in the case when such networks are abroad Russia. What we may and/or shoud do with all this ? >Daniel Karrenberg >RIPE NCC Manager Regards, -- Andrew Timonin RELCOM Corp. From training at ripe.net Mon Jul 10 13:47:58 1995 From: training at ripe.net (RIPE NCC Training) Date: Mon, 10 Jul 1995 13:47:58 +0200 Subject: Slides from Munich Training Course Message-ID: <9507101147.AA29394@ncc.ripe.net> Dear Local IR's Following the second training course for Local IR's held today in Munich, we are happy to announce that the slides from the course are now available for ftp from the directory: ftp//ftp.ripe.net/ripe/local-ir/training/ The slides are available as one complete course: master-course-slides-MUN-950710.ps.Z or individually per session: intro-slides-MUN-950710.ps.Z ip-slides-MUN-950710.ps.Z db-slides-MUN-950710.ps.Z routing-slides-MUN-950710.ps.Z dns-slides-MUN-950710.ps.Z These slides incorporate comments and suggestions received from participants at the Amsterdam course. Our thanks to them for their constructive feedback. kind regards, Anne Lord & Mirjam Kuehne RIPE NCC Trainming Team. ~ From Anne.Lord at ripe.net Fri Jul 14 10:21:50 1995 From: Anne.Lord at ripe.net (Anne Lord) Date: Fri, 14 Jul 1995 10:21:50 +0200 Subject: Farewell Message-ID: <9507140821.AA12904@ncc.ripe.net> As Daniel mentioned in his short report to you all last week, I leaving the RIPE NCC today. Without making any speeches :), I'd just wanted to say "many thanks" to everyone I have worked with over the last 3 years. It's been an enjoyable 3 years, in which I have had fun in getting to know and working with the RIPE community. Hope to see you at future RIPE meetings! with best wishes, Anne Lord RIPE NCC From nipper at xlink.net Fri Jul 14 12:42:37 1995 From: nipper at xlink.net (Arnold Nipper) Date: Fri, 14 Jul 1995 12:42:37 +0200 (MET DST) Subject: Farewell In-Reply-To: <9507140821.AA12904@ncc.ripe.net> from "Anne Lord" at Jul 14, 95 10:21:50 am Message-ID: <"xlink100.x.339:14.06.95.10.43.35"@xlink.net> Anne Lord wrote: > > > As Daniel mentioned in his short report to you all last week, > I leaving the RIPE NCC today. > > Without making any speeches :), I'd just wanted to say "many > thanks" to everyone I have worked with over the last 3 years. > It's been an enjoyable 3 years, in which I have had fun in getting > to know and working with the RIPE community. > Dear Anne, many thanks to you for your work at RIPE NCC. It was always a great pleasure to work with you. Good luck!! > Hope to see you at future RIPE meetings! > > with best wishes, > > Anne Lord > RIPE NCC -- Arnold Nipper / email: nipper at xlink.net NTG Netzwerk und Telematic GmbH \/ phone: +49 721 9652 0 Geschaeftsbereich Xlink /\ LINK fax: +49 721 9652 210 Vincenz-Priessnitz-Str. 3 /_______ D-76131 Karlsruhe, Germany From alain at netvision.net.il Fri Jul 14 15:54:38 1995 From: alain at netvision.net.il (Alain Golan Goldberg) Date: Fri, 14 Jul 1995 16:54:38 +0300 (IDT) Subject: Farewell In-Reply-To: <9507140821.AA12904@ncc.ripe.net> Message-ID: Thanks Anne for all the support we received from You. I wish You alot of success in your new work. \Alain. On Fri, 14 Jul 1995, Anne Lord wrote: > Date: Fri, 14 Jul 1995 10:21:50 +0200 > From: Anne Lord > To: local-ir at ripe.net, k13 at nikhef.nl > Subject: Farewell > > > As Daniel mentioned in his short report to you all last week, > I leaving the RIPE NCC today. > > Without making any speeches :), I'd just wanted to say "many > thanks" to everyone I have worked with over the last 3 years. > It's been an enjoyable 3 years, in which I have had fun in getting > to know and working with the RIPE community. > > Hope to see you at future RIPE meetings! > > with best wishes, > > Anne Lord > RIPE NCC > Regards, Alain . Alain Golan-Goldberg _#####_ NetVision - Commercial Israeli Internet Provider (--O-O--) ------------------------------------------------------ooO-(_)-Ooo--- USENET, InterCALL (PPP/SLIP), Mail Forward, InterDIRECT Local Internet Registry E-mail: alain at NetVision.net.il Personal address info at NetVision.net.il for information. support at 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 This message was sent by Chameleon. From 100410.2335 at compuserve.com Sat Jul 15 00:32:55 1995 From: 100410.2335 at compuserve.com (Redouane NAJAH SEMLALI) Date: 14 Jul 95 18:32:55 EDT Subject: SUBSCRIBE Message-ID: <950714223255_100410.2335_BHG88-1@CompuServe.COM> subscribe Redouane NAJAH From steiff at NetVision.net.il Sun Jul 16 16:56:32 1995 From: steiff at NetVision.net.il (Shahar Steiff) Date: Sun, 16 Jul 1995 17:56:32 +0300 (IDT) Subject: Establishing a connection between Israel and Europe Message-ID: 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 . Sincerely, Shahar Steiff WAN team - NetVision - Commercial Israeli Internet Provider ----------------------------------------------------------- E-mail: steiff at NetVision.net.il Personal address info at NetVision.net.il for information. support at 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. From Daniel.Karrenberg at ripe.net Thu Jul 20 12:53:35 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 20 Jul 1995 12:53:35 +0200 Subject: Last Resort Registries Message-ID: <9507201053.AA09097@ncc.ripe.net> 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 From ripe-dbm at ripe.net Thu Jul 20 13:34:57 1995 From: ripe-dbm at ripe.net (RIPE Database Manager) Date: Thu, 20 Jul 1995 13:34:57 +0200 Subject: TEST database Message-ID: <9507201134.AA09569@ncc.ripe.net> 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: 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 -------- From fessel at DeTeMobil.de Thu Jul 20 13:53:08 1995 From: fessel at DeTeMobil.de (Jan-Hinrich Fessel) Date: Thu, 20 Jul 1995 13:53:08 +0200 Subject: Last Resort Registries In-Reply-To: Deine Nachricht vom Thu, 20 Jul 1995 12:53:35 +0200. <9507201053.AA09097@ncc.ripe.net> Message-ID: <199507201153.NAA03196@spock.MSRO.DeTeMobil.de> In message <9507201053.AA09097 at ncc.ripe.net>you write: Daniel.Karrenberg at ripe.net said: > 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. Have I missed something? I only know of private address space that is guaranteed not to be routed across the Internet. Any pointers to rfc's etc. concerning this new case of private address space? Gr|_e Oskar ------------------------------------------------------------------------------ Jan-Hinrich Fessel, F424C4, DeTeMobil M|nster Tragbar ist, was nicht herunterfdllt From Daniel.Karrenberg at ripe.net Thu Jul 20 14:07:05 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 20 Jul 1995 14:07:05 +0200 Subject: Last Resort Registries In-Reply-To: Your message of Thu, 20 Jul 1995 13:53:08 MDT. <199507201153.NAA03196@spock.MSRO.DeTeMobil.de> References: <199507201153.NAA03196@spock.MSRO.DeTeMobil.de> Message-ID: <9507201207.AA09929@ncc.ripe.net> > Jan-Hinrich Fessel writes: > In message <9507201053.AA09097 at ncc.ripe.net>you write: > > Daniel.Karrenberg at ripe.net said: > > 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. > > Have I missed something? I only know of private address space that is > guaranteed not to be routed across the Internet. > Any pointers to rfc's etc. concerning this new case of private address spac > e? I intended "end-user *on the Internet*" to mean just that. From bonito at nis.garr.it Thu Jul 20 15:12:20 1995 From: bonito at nis.garr.it (Antonio_Blasco Bonito) Date: Thu, 20 Jul 95 15:12:20 MET DST Subject: Last Resort Registries In-Reply-To: <9507201053.AA09097@ncc.ripe.net>; from "Daniel Karrenberg" at Jul 20, 95 12:53 pm Message-ID: <9507201312.AA16624@re.nis.garr.it> Daniel, > 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. Unfortunately there are still cases of ISPs not providing registry services for their customers. For example US providers selling connectivity in Europe do not provide IP addresses. As far as I know they do not want to be part of the European Regional IR. > 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. I agreee > 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. This can eventually be solved in some way... > 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? I think it could be done but there is a strong need for a document explaining the new address assignment policy. I think this document should have worldwide applicability and be published as an RFC. Local IRs need such a reference when they have to answer to strange address assignment requests eventually coming from network managers or small providers located in dispersed sites around the world. ---------- ---------- Antonio_Blasco Bonito E-Mail: bonito at 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 Telex: 500371 CNUCE I 56126 PISA Italy Fax: +39 (50) 904052 ---------- ---------- From peter at demon.net Thu Jul 20 15:16:14 1995 From: peter at demon.net (peter at demon.net) Date: Thu, 20 Jul 1995 14:16:14 +0100 (BST) Subject: Last Resort Registries In-Reply-To: <9507201053.AA09097@ncc.ripe.net> from "Daniel Karrenberg" at Jul 20, 95 12:53:35 pm Message-ID: <9507201416.aa11427@office.demon.net> > 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. This is understood. > 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? There will always be companies and individuals who have a need for a last resort registry, and as long as the people here agree that the InterNIC can and *will* provide that service than there should not be any problem. However, if the InterNIC is unwilling to take on this responsibility for the geographical area managed by the RIPE on its "behalf" then someone still has to do it. Maybe a declaration from all RIPE members that they will allocate "real" address space free of charge to non-customers (prospective they may be) would then guarentee the continuing of this service in some other shape. Or even have a last resort tariff that does charge for non-service provider based address spaces and then this could fund any admin overhead. Before anyone says it, I do not see the last two paragraphs as contradictions. Regards, -- Peter Galbavy peter at demon.net @ Demon Internet phone://44/181/371_3700 http://www.wonderland.org/~peter/ snail://UK/N3_1TT/London/42_Hendon_Lane/Demon_Internet_Ltd/ From kevin at nosc.ja.net Thu Jul 20 16:54:51 1995 From: kevin at nosc.ja.net (Kevin Hoadley) Date: Thu, 20 Jul 1995 15:54:51 +0100 Subject: Last Resort Registries In-Reply-To: Your message of "Thu, 20 Jul 1995 12:53:35 +0200." <9507201053.AA09097@ncc.ripe.net> Message-ID: <18626.806252091@nosc.ja.net> > 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. Daniel, Some comments: - this would seem to imply that RFC1597 is now *compulsory* for private internets (certainly for those where any member also has a public Internet connection). - does the Internic still give out addresses to end customers ? If so, what is to stop an organisation obtaining addresses from the States, possibly through a US office or subsidiary ? I'm sure organisations are doing this now, but removing the last-resorts registries may well increase its prevalence. - though RIPE could discontinue the official last-resort registries, do we have any protection against providers setting themselves up as de-facto LR registries by selling off part of their provider address space to organisation who do not connect to them ? (this will only punch a hole in the providers aggregates if the organisation the addresses were assigned to decides at a later date to connect to the Internet (via another provider) - I could resell my provider addresses to private Internets without anyone knowing). Non-provider/last-resort address assignments are not currently a major problem on their own - after all the traditional class B's are (almost always) non-provider addresses, yet I don't see anyone suggesting that we should all be renumbering from our B's to addresses within a 193.* or 194.* CIDR block. Granted, we need to avoid allocating lots of long-prefix non-aggregateable addresses - this is the main problem with the last resort registries. Small allocations should be avoidable, as small/medium sized organisations ought to be able to renumber to provider addresses when they connect to the Internet. But equally there is a demand for last-resort addresses from large organisations (certainly within the UK), looking either for a class B or a large block of C's, the typical scenario being a large corporation making the transition from SNA to TCP/IP over the course of a coupel of years, with the intention of connecting to the Internet at the end of this process. Where are these organisations left if the last resort registries are discontinued ? (Answer(?): if they are after a B (certainly, and probably if they want a substantial block of traditional C space) they end up talking to the NCC from day one. Which comes back to Daniel's assertion that last-resort registries use NCC resources without contributing to the NCC; currently last-resort registries do some (albeit sometimes negligible) vetting and frontline processing of class B requests before passing them onto the NCC. Without the LR registries, everything falls on the NCC). Kevin Hoadley, JIPS NOSC From Daniel.Karrenberg at ripe.net Thu Jul 20 16:56:14 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 20 Jul 1995 16:56:14 +0200 Subject: Last Resort Registries In-Reply-To: Your message of Thu, 20 Jul 1995 15:12:20 +0700. <9507201312.AA16624@re.nis.garr.it> References: <9507201312.AA16624@re.nis.garr.it> Message-ID: <9507201456.AA11864@ncc.ripe.net> > bonito at nis.garr.it (Antonio_Blasco Bonito) writes: > > Unfortunately there are still cases of ISPs not providing registry > services for their customers. For example US providers selling > connectivity in Europe do not provide IP addresses. As far as I know > they do not want to be part of the European Regional IR. I do not know of *any* significant cases of this. The issue which regional IR a provider gets allocations from is not relevant in this discussion. > > 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. > > This can eventually be solved in some way... I agree, if we decide to keep them around we will have to charge them like any other registry. Note however, that this is not the main argument for doing away with them. > I think it could be done but there is a strong need for a document > explaining the new address assignment policy. Fully agree! > I think this document > should have worldwide applicability and be published as an RFC. Do not agree. For European Last-Resort registries a RIPE document is sufficient. > Local IRs need such a reference when they have to answer to strange > address assignment requests eventually coming from network managers > or small providers located in dispersed sites around the world. Yep. Daniel From Nigel.Titley at bt.net Thu Jul 20 17:04:38 1995 From: Nigel.Titley at bt.net (Nigel Titley) Date: Thu, 20 Jul 1995 16:04:38 +0100 Subject: Last Resort Registries In-Reply-To: Your message of "Thu, 20 Jul 1995 15:12:20 +0700." <9507201312.AA16624@re.nis.garr.it> Message-ID: <9507201507.AA12025@ncc.ripe.net> > Daniel, > > > 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. > > Unfortunately there are still cases of ISPs not providing registry > services for their customers. For example US providers selling > connectivity in Europe do not provide IP addresses. As far as I know > they do not want to be part of the European Regional IR. As far as I'm concerned this should be left to market forces. Such ISPs deserve to fail, and will do so. Nigel Titley --------------------------------------------------------------------- Nigel Titley --- BTnet Applications Services Manager E-mail: Nigel.Titley at bt.net Tel: +44 1442 237674 From saban at Sigma.ICMP.Lviv.UA Thu Jul 20 17:25:22 1995 From: saban at Sigma.ICMP.Lviv.UA (Alexander Saban) Date: Thu, 20 Jul 1995 15:25:22 +0000 (GMT) Subject: Last Resort Registries Message-ID: <199507201525.SAA26390@Sigma.ICMP.Lviv.UA> 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 at 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 at icmp.lviv.ua From ber at sunet.se Thu Jul 20 19:01:18 1995 From: ber at sunet.se (Bjorn Eriksen) Date: Thu, 20 Jul 1995 19:01:18 +0200 Subject: Last Resort Registries Message-ID: <199507201701.TAA10882@sunic.sunet.se> >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 From poole at eunet.ch Thu Jul 20 19:10:12 1995 From: poole at eunet.ch (poole at eunet.ch) Date: Thu, 20 Jul 1995 19:10:12 +0200 (MET DST) Subject: Last Resort Registries In-Reply-To: <18626.806252091@nosc.ja.net> from "Kevin Hoadley" at Jul 20, 95 03:54:51 pm Message-ID: <199507201710.TAA05695@eunet.ch> > > > 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. > > Daniel, This is all going severely to fast for my taste. Essentially the decision is not to close down the last-resort registries, but not to allocate unique address space anymore except for Internet connected organisations. This is a decision of a magnitude that needs substantially more support than it currently has. > > Some comments: > > - this would seem to imply that RFC1597 is now *compulsory* for private > internets (certainly for those where any member also has a public > Internet connection). There are perfectly good reasons why an organisation might want unique (but not necessarily globably routable) address space, RFC1597 doesn't provide this. Simon From poole at eunet.ch Thu Jul 20 19:29:19 1995 From: poole at eunet.ch (poole at eunet.ch) Date: Thu, 20 Jul 1995 19:29:19 +0200 (MET DST) Subject: Last Resort Registries In-Reply-To: <199507201701.TAA10882@sunic.sunet.se> from "Bjorn Eriksen" at Jul 20, 95 07:01:18 pm Message-ID: <199507201729.TAA05785@eunet.ch> > 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. Simon From ber at sunet.se Thu Jul 20 19:59:37 1995 From: ber at sunet.se (Bjorn Eriksen) Date: Thu, 20 Jul 1995 19:59:37 +0200 Subject: Last Resort Registries Message-ID: <199507201759.TAA18218@sunic.sunet.se> >> 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 From brian at dxcoms.cern.ch Thu Jul 20 20:50:11 1995 From: brian at dxcoms.cern.ch (Brian Carpenter CERN-CN) Date: Thu, 20 Jul 1995 20:50:11 +0200 (MET DST) Subject: Last Resort Registries In-Reply-To: <199507201759.TAA18218@sunic.sunet.se> from "Bjorn Eriksen" at Jul 20, 95 07:59:37 pm Message-ID: <9507201850.AA13677@dxcoms.cern.ch> Bjorn There is no such thing as national rfc1597 coordination. Read 1597 again, or read the infamous IAB guidance in rfc1841 (if I have the right number). this is simply NOT AN OPTION. sorry to shout but you have seriously misunderstood if you think that 1597 needs coordination If two 1597 using private nets are merged then they just have to renumber whichever subnets overlap. that's it. Brian From ber at sunet.se Thu Jul 20 20:56:01 1995 From: ber at sunet.se (Bjorn Eriksen) Date: Thu, 20 Jul 1995 20:56:01 +0200 Subject: Last Resort Registries Message-ID: <199507201856.UAA25414@sunic.sunet.se> >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 From poole at eunet.ch Thu Jul 20 22:59:22 1995 From: poole at eunet.ch (poole at eunet.ch) Date: Thu, 20 Jul 1995 22:59:22 +0200 (MET DST) Subject: Last Resort Registries In-Reply-To: <199507201759.TAA18218@sunic.sunet.se> from "Bjorn Eriksen" at Jul 20, 95 07:59:37 pm Message-ID: <199507202059.WAA06709@eunet.ch> > > 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. If you'd followed the IETF list you would know that I made a comment pointing these problems out a -long- time ago, in particular from the point of collisions RFC-1597 is substantially worse than picking addresses at random (and no better than the time honored tradition of using addresses from Sun). > > 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. Private addres space is -private-: useful for networking all the power meters in Switzerland and similar sensible things, it cannot be an ersatz public address space. In your example: where do you stop? What happens if Big Company wants to connect to companies in Denmark and Norway (and Switzerland and Germany and France and Italy .......)? You ARE creating a second public address space. Simon From Daniel.Karrenberg at ripe.net Fri Jul 21 10:11:15 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 21 Jul 1995 10:11:15 +0200 Subject: Last Resort Registries In-Reply-To: Your message of Thu, 20 Jul 1995 22:59:22 MDT. <199507202059.WAA06709@eunet.ch> References: <199507202059.WAA06709@eunet.ch> Message-ID: <9507210811.AA19115@ncc.ripe.net> > poole at eunet.ch writes: > > > > 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. > > If you'd followed the IETF list you would know that I made a comment > pointing these problems out a -long- time ago, in particular from the > point of collisions RFC-1597 is substantially worse than picking > addresses at random (and no better than the time honored tradition > of using addresses from Sun). There is a serious omission in RFC1597: We did not recommend that people who forsee external connection requirements should choose their RFC1597 addresses at random. We just assumed that people would be clever enough to figure that out by themselves. This will be fixed in the next version of the RFC. However we did say: Groups of organisations which foresee a big need for mutual communication can consider forming an enterprise by designing a common addressing plan supported by the necessary organisational arrangements like a registry. If they choose to have Bjorn do that for them it is perfectly OK. However Bjorn should be *very* clear about the fact that this address space is still "private" and that there is no guarantee of uniqueness outside the set of organisations participating in this voluntary scheme! Of course the guarantee of uniqueness from public address space remains. Can we close this side discussion? Daniel From Daniel.Karrenberg at ripe.net Fri Jul 21 10:40:00 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 21 Jul 1995 10:40:00 +0200 Subject: Last Resort Registries In-Reply-To: Your message of Thu, 20 Jul 1995 19:10:12 MDT. <199507201710.TAA05695@eunet.ch> References: <199507201710.TAA05695@eunet.ch> Message-ID: <9507210840.AA19354@ncc.ripe.net> > poole at eunet.ch writes: > > This is all going severely to fast for my taste. Essentially the decision > is not to close down the last-resort registries, but not to allocate > unique address space anymore except for Internet connected organisations. This is *not* the case! Your observation is right in the sense that there is a clear *trend* in the Internet community towards a situation like this. The particular decision to abandon last-resort registries is not equal to "not allocate unique address space anymore except for Internet connected organisations". All the remaining registries remain free to allocate to non-connected organisations. See ripe-127 for details. > There are perfectly good reasons why an organisation might want unique > (but not necessarily globably routable) address space, RFC1597 doesn't > provide this. I agree with you. However, these organisations should also be aware that such address space may not be automatically routable on the Internet. Again see ripe-127 for details. Again: Abandoning last-resort registries does not mean that it will be impossible to obtain public address space without an Internet connection. Yes it will become more difficult and end-users will be warned better about whaqt they are getting. Daniel From Daniel.Karrenberg at ripe.net Fri Jul 21 10:53:03 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 21 Jul 1995 10:53:03 +0200 Subject: Last Resort Registries In-Reply-To: Your message of Thu, 20 Jul 1995 15:54:51 BST. <18626.806252091@nosc.ja.net> References: <18626.806252091@nosc.ja.net> Message-ID: <9507210853.AA19482@ncc.ripe.net> > Kevin Hoadley writes: > > - this would seem to imply that RFC1597 is now *compulsory* for private > internets No, see my answer to Simon. > - does the Internic still give out addresses to end customers ? If so, > what is to stop an organisation obtaining addresses from the States, > possibly through a US office or subsidiary ? I'm sure organisations > are doing this now, but removing the last-resorts registries may well > increase its prevalence. The only barrier is that the InterNIC will not assign anything if they are clearly in Europe. Deviousness of course is always a possibility. The only attractivenessof the InterNIC at the moment is that it is free. > - though RIPE could discontinue the official last-resort registries, do > we have any protection against providers setting themselves up as > de-facto LR registries by selling off part of their provider address > space to organisation who do not connect to them ? (this will only > punch a hole in the providers aggregates if the organisation the > addresses were assigned to decides at a later date to connect to the > Internet (via another provider) - I could resell my provider addresses > to private Internets without anyone knowing). There is nothing to stop them. Indeed it is perfectly legitimate for provider IRs to assign PI space if they so choose. But it would be against their own interests to punch holes in their CIDR blocks. ripe-127 suggests that they should use seperate parts of the address space for that. It also says that they not normally get allocations for that, but get it from the NCC on an as-needed basis. > Non-provider/last-resort address assignments are not currently a major prob > lem > on their own - after all the traditional class B's are (almost always) > non-provider addresses, yet I don't see anyone suggesting that we should al > l > be renumbering from our B's to addresses within a 193.* or 194.* CIDR block > . I mentioned the main problems im my proposal. > Granted, we need to avoid allocating lots of long-prefix non-aggregateable > addresses - this is the main problem with the last resort registries. Small > allocations should be avoidable, as small/medium sized organisations ought > to be able to renumber to provider addresses when they connect to the Inter > net. > But equally there is a demand for last-resort addresses from large > organisations (certainly within the UK), looking either for a class B or a > large block of C's, the typical scenario being a large corporation making > the transition from SNA to TCP/IP over the course of a coupel of years, wit > h > the intention of connecting to the Internet at the end of this process. > Where are these organisations left if the last resort registries are > discontinued ? They can go to any other IR. > (Answer(?): if they are after a B (certainly, and probably if they want a > substantial block of traditional C space) they end up talking to the NCC > from day one. Which comes back to Daniel's assertion that last-resort > registries use NCC resources without contributing to the NCC; currently > last-resort registries do some (albeit sometimes negligible) vetting and > frontline processing of class B requests before passing them onto the NCC. > Without the LR registries, everything falls on the NCC). That is true only if no provider IRs decide to provide this service. I have strong suspicions that they will provide this service, for a fee of course. Again: The main problem here is perception. It should be made clear to end-users that getting PI space does not guarantee routability on the Internet. Daniel From bonito at nis.garr.it Fri Jul 21 12:11:59 1995 From: bonito at nis.garr.it (Antonio_Blasco Bonito) Date: Fri, 21 Jul 1995 12:11:59 +0200 (MET DST) Subject: Last Resort Registries In-Reply-To: <199507201759.TAA18218@sunic.sunet.se> Message-ID: Bjorn Eriksen writes: > 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 I fully agree. That's the spirit of the Internet. Things do not work automagically. People that think that way are strongly necessary. It's likely that last resort registries (places where to apply for unique non-provider addresses) will disappear. But I think that some guidance and coordination should stay. And the RIPE-NCC alone will probably be not sufficient for this task in the fast growing European Internet. Blasco ---------- ---------- Antonio_Blasco Bonito E-Mail: bonito at 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 Telex: 500371 CNUCE I 56126 PISA Italy Fax: +39 (50) 904052 ---------- ---------- From bonito at nis.garr.it Fri Jul 21 12:34:24 1995 From: bonito at nis.garr.it (Antonio_Blasco Bonito) Date: Fri, 21 Jul 1995 12:34:24 +0200 (MET DST) Subject: Last Resort Registries In-Reply-To: <9507201456.AA11864@ncc.ripe.net> Message-ID: > > bonito at nis.garr.it (Antonio_Blasco Bonito) writes: > > > > Unfortunately there are still cases of ISPs not providing registry > > services for their customers. For example US providers selling > > connectivity in Europe do not provide IP addresses. As far as I know > > they do not want to be part of the European Regional IR. > > I do not know of *any* significant cases of this. > The issue which regional IR a provider gets allocations from > is not relevant in this discussion. I think it *is* relevant: we are talking about CIDR aggregatable addresses. Some US providers do not want to provide addresses to customers in Europe from their own address space to save the possibility of continental aggregation. This is a point which needs to be clarified at least to correctly define the role of Regional registries. > > > I think this document > > should have worldwide applicability and be published as an RFC. > > Do not agree. For European Last-Resort registries a RIPE document is > sufficient. That's not sufficient, I guess. We could start with a RIPE document but I'm convinced the issue is *not* restricted to Europe. RIPE-181 became an RFC for the same reason. Am I right? > > Local IRs need such a reference when they have to answer to strange > > address assignment requests eventually coming from network managers > > or small providers located in dispersed sites around the world. > > Yep. > > Daniel > ---------- ---------- Antonio_Blasco Bonito E-Mail: bonito at 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 Telex: 500371 CNUCE I 56126 PISA Italy Fax: +39 (50) 904052 ---------- ---------- From kevin at nosc.ja.net Fri Jul 21 13:51:38 1995 From: kevin at nosc.ja.net (Kevin Hoadley) Date: Fri, 21 Jul 1995 12:51:38 +0100 Subject: Last Resort Registries In-Reply-To: Your message of "Fri, 21 Jul 1995 10:53:03 +0200." <9507210853.AA19482@ncc.ripe.net> Message-ID: <974.806327498@nosc.ja.net> > > - this would seem to imply that RFC1597 is now *compulsory* for privat > > internets > > No, see my answer to Simon. (I actually meant that as a question, but ...) 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. I'm not sure I see how relocating the registry activities helps global routing. > I mentioned the main problems im my proposal. Re-reading your proposal there appears to be three lines of discussion, which in order of importance are: 1/ last-resort registries allocate non-aggregateable address space (which in the future may be useless as no one will route it). 2/ last-resort registries are less necessary than was the case because of the proliferation of provider registries 3/ last-resort registries do not currently fit into the NCC charging model. and a fourth point, from one of your replies to Simon: 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 (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 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 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 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. Kevin Hoadley, JIPS NOSC. From Daniel.Karrenberg at ripe.net Fri Jul 21 15:22:40 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 21 Jul 1995 15:22:40 +0200 Subject: Last Resort Registries In-Reply-To: Your message of Fri, 21 Jul 1995 12:34:24 MDT. References: Message-ID: <9507211322.AA22342@ncc.ripe.net> > Antonio_Blasco Bonito writes: > > I think it *is* relevant: we are talking about CIDR aggregatable addresses. > Some US providers do not want to provide addresses to customers in Europe > from their own address space to save the possibility of continental > aggregation. This is a point which needs to be clarified at least to > correctly define the role of Regional registries. I only know of one such case and this provider has since changed their mind (regid eu.sprint). > > > I think this document > > > should have worldwide applicability and be published as an RFC. > > > > Do not agree. For European Last-Resort registries a RIPE document is > > sufficient. > > That's not sufficient, I guess. We could start with a RIPE document but > I'm convinced the issue is *not* restricted to Europe. We start with a RIPE document. The problem with an RFCs is that there are many highly contentious issues associated with a successor to RFC1466. This document is not going to be agreed quickly. However we need a revision of ripe-104. So far we have been waiting. ripe-104 is now sufficiently outdated to go ahead with a revision anyway. I just hope that we can agree on one in Europe. I would prefer it to go the other way round but there seems to be little choice. > RIPE-181 became an RFC for the same reason. Am I right? It is an informational RFC about a technology, not about address space policies. Daniel From inaddr at ripe.net Fri Jul 21 15:36:55 1995 From: inaddr at ripe.net (RIPE NCC IN-ADDR. ARPA Role Account) Date: Fri, 21 Jul 1995 15:36:55 +0200 Subject: RIPE automatic inaddr-arpa checking tool available Message-ID: <9507211337.AA22515@ncc.ripe.net> 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 INSTEAD OF 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 . From jcaron at pressimage.net Fri Jul 21 15:40:02 1995 From: jcaron at pressimage.net (Jacques Caron) Date: Fri, 21 Jul 1995 15:40:02 +0200 Subject: Last Resort Registries Message-ID: 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 at pressimage.net | 5/7 rue Raspail | |Tel: +33 (1) 49 88 63 56 | 93108 Montreuil Cedex | |Fax: +33 (1) 49 88 63 64 | France | +-------------------------+------------------------+ From kevin at nosc.ja.net Fri Jul 21 17:09:01 1995 From: kevin at nosc.ja.net (Kevin Hoadley) Date: Fri, 21 Jul 1995 16:09:01 +0100 Subject: Last Resort Registries In-Reply-To: Your message of "Fri, 21 Jul 1995 15:40:02 +0200." Message-ID: <7279.806339341@nosc.ja.net> > >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. I have no major problems with that in general, though it does need to be modified to permit dual-homed connections My complaint is that dropping the last resort registries doesn't achieve that on its own. Nothing improves if all you do is drop the LR registries (other than that we get fewer calls from complete idiots :-)). A coordinated program of discontinuing non-provider registries globally, and discouraging provider registries from allocating numbers to organisations who are unlikely to become their customers, makes more sense. Without this coordination and widened scope, dropping the LR registries within Europe merely obscures the problem, rather than fixes it: we still have non-provider allocations being made, only now by the Internic and by provider registries. Kevin Hoadley, JIPS NOSC. From 100410.2335 at compuserve.com Sat Jul 22 01:08:20 1995 From: 100410.2335 at compuserve.com (Redouane NAJAH SEMLALI) Date: 21 Jul 95 19:08:20 EDT Subject: Infos Message-ID: <950721230820_100410.2335_BHG55-3@CompuServe.COM> Lists Short From lorman at quadat.cz Mon Jul 24 12:08:55 1995 From: lorman at quadat.cz (Jiri Lorman) Date: Mon, 24 Jul 95 12:08:55 MESZ Subject: No subject Message-ID: <9507241208.aa26060@datac.quadat.cz> help From lorman at quadat.cz Mon Jul 24 12:30:21 1995 From: lorman at quadat.cz (Jiri Lorman) Date: Mon, 24 Jul 95 12:30:21 MESZ Subject: No subject Message-ID: <9507241230.aa27268@datac.quadat.cz> 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 at bohemia.net lst-localir: lorman at quadat.cz lst-provs: lorman at quadat.cz lst-contrib: lorman at 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 at quadat.cz bill-proto: E-MAIL bill-categ: SMALL bill-scheme: HALF-YEARLY bill-vatno: without VAT bill-ref: Internet bill-remark: From Daniel.Karrenberg at ripe.net Mon Jul 24 15:15:07 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 24 Jul 1995 15:15:07 +0200 Subject: RIPE NCC Staff Position: Junior Hostmaster (3 days/week) Message-ID: <9507241315.AA16339@ncc.ripe.net> 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 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. From Stephan.Biesbroeck at belnet.be Tue Jul 25 15:22:42 1995 From: Stephan.Biesbroeck at belnet.be (Stephan.Biesbroeck at belnet.be) Date: Tue, 25 Jul 1995 15:22:42 +0200 (MET DST) Subject: Last Resort Registries In-Reply-To: <9507201053.AA09097@ncc.ripe.net> from "Daniel Karrenberg" at Jul 20, 95 12:53:35 pm Message-ID: <9507251322.AA28469@mahler.belnet.be> I am personally in favor of closing down the last resource registry (one reason is of course that it is starting to take up a serious amount of resources for us :-(). BUT documentation is in that case indeed hardly needed since some "callers" are rather agressive, and in that case it is usefull to point them to a general available document. Stephan Daniel Karrenberg wrote : > 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 -- Stephan Biesbroeck Tel: +32(0)2-2383470 stephan at belnet.be Fax: +32(0)2-2311531 Service Support Team of the Belgian National Research Network, BELNET From training at ripe.net Mon Jul 31 11:57:41 1995 From: training at ripe.net (RIPE NCC Training) Date: Mon, 31 Jul 1995 11:57:41 +0200 Subject: Announcement for Local IR Training Course Message-ID: <9507310957.AA04206@ncc.ripe.net> * * * Announcement * * * Local Internet Registries Training Course Date: Friday, 25th August, 1995 Time: 0900 - 1700 Venue: Vienna, Austria The exact address will be announced as soon as possible. -------------- next part -------------- Course Audience --------------- The target audience for this course is personnel of European Local Internet Registries or ISPs planning to set up a local IR. Material Covered ---------------- The course is a one day introduction on Internet name, address and routing policy registration procedures in Europe. It also teaches students how to query and use the information registered for operational purposes. This includes the following material and activities: o Overview of name, address and routing registration procedures. o Responsibilities of both RIPE NCC and Local IR's to each other. o Wider context of the Delegated Registry system and relevant issues (IPv4 address depletion, CIDR) and how this relates to IP requests. o How to use the RIPE NCC Database. o Use of AS numbers, Routing Registry concepts and an introduction to using PRIDE tools. o DNS feedback on commor errors, how to request delegations, and pointers to useful tools. We again stress that this course will *not* teach Local Registries on how to run their business as Internet Service Providers. It is clearly focussed on registration procedures and the interaction between the RIPE NCC and local IR's. A detailed outline is appended below. The course itself will include lunch and will be free. This of course does not include your travel and subsitence ;-). How to Register --------------- Please send an RSVP to if you would like to attend the course. If you have previously approached us about attending this course, we ask you to confirm that you (or a colleague) will be attending. Registrations will be accepted on a first come, first served basis. If the course is oversubscribed, we will give priority to local IRs who have paid the signup fee in 1995. If it is still oversubscribed, we will accept only one person per new local registry. We will provide additional course dates in Amsterdam as necessary. If a number of local registries so request, we will present courses at other European locations. If you would like a local course or have any questions or suggestions, please do not hesitate to contact us. The RIPE NCC Training Team: Mirjam Kuehne, Daniel Karrenberg --- Course Outline -------------- For this second course, we will provide a slidebook and a reader on the day of the course, as well as electronically. Once feedback is received, it is planned to make detailed documentation available in the form of a guide much like the PRIDE guide. The program will divide the actual content into the following sections: 1. Introduction For those unfamiliar with the Delegated Internet Registry system and the RIPE NCC, this section will give a historical overview of how we have arrived at today's model of operation and why training of local IR's is a much needed activity. 2. IP Registry procedures This section will clarify the procedures between the RIPE NCC and local IR's with respect to requests for IP address space. It will take a step by step approach on how to complete documentation, the kind of information that is required, what the "handholding" procedure is, how to deal with very large requests, and very small requests, and more generally what criteria the RIPE NCC and local IR's use for their customers in the context of CIDR and IPv4 address depletion. 3. RIPE NCC Database This section will explain what the RIPE NCC Database is and how it fits into the scheme of other registry databases. It will cover how to create and update RIPE NCC Database objects and will explain how to query the database. 4. Routing Registry procedures This section will examine AS numbers, when you need them and how to request them. This will be set within the context of how AS numbers are used as part of the RIPE Routing Registry. Understanding the basic principles behind the Internet Routing Registry and how registering your policy is an important element in the global schema. This section will also include a brief introduction to the PRIDE tools and how they can be useful to you. 5. DNS procedures Where to request forward and reverse domain delegation. Which documentation should be completed. How reverse domain delegation requests are processed at the RIPE NCC (with a useful tool). We will also take a look at common errors in setting up DNS with respect to relevant RFCs and RIPE recommendations. Feedback Please! Throughout the course there will be ample chance for feedback and discussion with an emphasis for you to tell us how we can improve ;-). -------------- next part -------------- %%%%%%%%%%% PLEASE NOTE %%%%%%%%%%% Our handling of ALL course registrations is fully automated. To register for the course, please complete the registration form and send it to . Please send only the registration form in your reply and edit out all other text. Add in a value in the `box' area marked between the square brackets (i.e. "[" and "]" s). If you have any questions about the training course or your registration form, please contact us at . You will receive a notification message that your request has been processed. Many thanks, and look forward to seeing you, RIPE NCC Training Team ---------------------------------------------------------------------------- %START PART 1 - Registration 1) Your name Enter First name, Last name in FULL e.g. John Doe Mary-Beth Walton # NAME [ ] 2) Your Registry ID (format: country-code.) # REG [ ] 3) Your e-mail address # EMAIL [ ] 4) The course you plan to attend (date and location) # COURSE [ ] %END From ncc at ripe.net Mon Jul 31 13:12:28 1995 From: ncc at ripe.net (RIPE NCC Document Annoucement Service) Date: Mon, 31 Jul 1995 13:12:28 +0200 Subject: New Document available: Message-ID: <9507311112.AA05245@ncc.ripe.net> * * * Announcement * * * Local Internet Registries Training Course Date: Monday, 4th September, 1995 Time: 0900 - 1700 Venue: Consiglio Nazionale delle Ricerche Area della Ricerca di Milano CNR - IFCTR SIAM Via A. M. Ampere, 56 I-20131 Milano Italy -------------- next part -------------- Course Audience The target audience for this course is personnel of European Local Internet Registries or ISPs planning to set up a local IR. Material Covered The course is a one day introduction on Internet name, address and routing policy registration procedures in Europe. It also teaches students how to query and use the information registered for operational purposes. This includes the following material and activities: o Overview of name, address and routing registration procedures. o Responsibilities of both RIPE NCC and Local IR's to each other. o Wider context of the Delegated Registry system and relevant issues (IPv4 address depletion, CIDR) and how this relates to IP requests. o How to use the RIPE NCC Database. o Use of AS numbers, Routing Registry concepts and an introduction to using PRIDE tools. o DNS feedback on commor errors, how to request delegations, and pointers to useful tools. o Practical experience and feedback on how to create, maintain and update various types of information stored in the RIPE database. We again stress that this course will *not* teach Local Registries on how to run their business as Internet Service Providers. It is clearly focussed on registration procedures and the interaction between the RIPE NCC and local IR's. A detailed outline is appended below. The course itself will include lunch and will be free. This of course does not include your travel and subsitence ;-). How to Register Please send an RSVP to if you would like to attend the course. If you have previously approached us about attending this course, we ask you to confirm that you (or a colleague) will be attending. Registrations will be accepted on a first come, first served basis. If the course is oversubscribed, we will give priority to local IRs who have paid the signup fee in 1995. If it is still oversubscribed, we will accept only one person per new local registry. We will provide additional course dates in Amsterdam as necessary. If a number of local registries so request, we will present courses at other European locations. If you would like a local course or have any questions or suggestions, please do not hesitate to contact us. The RIPE NCC Training Team: Mirjam Kuehne, Daniel Karrenberg --- Course Outline For this second course, we will provide a slidebook and a reader on the day of the course, as well as electronically. Once feedback is received, it is planned to make detailed documentation available in the form of a guide much like the PRIDE guide. The program will divide the actual content into the following sections: 1. Introduction For those unfamiliar with the Delegated Internet Registry system and the RIPE NCC, this section will give a historical overview of how we have arrived at today's model of operation and why training of local IR's is a much needed activity. 2. IP Registry procedures This section will clarify the procedures between the RIPE NCC and local IR's with respect to requests for IP address space. It will take a step by step approach on how to complete documentation, the kind of information that is required, what the "handholding" procedure is, how to deal with very large requests, and very small requests, and more generally what criteria the RIPE NCC and local IR's use for their customers in the context of CIDR and IPv4 address depletion. 3. RIPE NCC Database This section will explain what the RIPE NCC Database is and how it fits into the scheme of other registry databases. It will cover how to create and update RIPE NCC Database objects and will explain how to query the database. 4. Routing Registry procedures This section will examine AS numbers, when you need them and how to request them. This will be set within the context of how AS numbers are used as part of the RIPE Routing Registry. Understanding the basic principles behind the Internet Routing Registry and how registering your policy is an important element in the global schema. This section will also include a brief introduction to the PRIDE tools and how they can be useful to you. 5. DNS procedures Where to request forward and reverse domain delegation. Which documentation should be completed. How reverse domain delegation requests are processed at the RIPE NCC (with a useful tool). We will also take a look at common errors in setting up DNS with respect to relevant RFCs and RIPE recommendations. Feedback Please! Throughout the course there will be ample chance for feedback and discussion with an emphasis for you to tell us how we can improve ;-). -------------- next part -------------- %%%%%%%%%%% PLEASE NOTE %%%%%%%%%%% Our handling of ALL course registrations is fully automated. To register for the course, please complete the registration form and send it to . Please send only the registration form in your reply and edit out all other text. Add in a value in the `box' area marked between the square brackets (i.e. "[" and "]" s). If you have any questions about the training course or your registration form, please contact us at . You will receive a notification message that your request has been processed. Many thanks, and look forward to seeing you, RIPE NCC Training Team ---------------------------------------------------------------------------- %START PART 1 - Registration 1) Your name Enter First name, Last name in FULL e.g. John Doe Mary-Beth Walton # NAME [ ] 2) Your Registry ID (format: country-code.) # REG [ ] 3) Your e-mail address # EMAIL [ ] 4) The course you plan to attend (date and location) # COURSE [ ] %END From training at ripe.net Mon Jul 31 13:32:27 1995 From: training at ripe.net (RIPE NCC Training) Date: Mon, 31 Jul 1995 13:32:27 +0200 Subject: Announcement for Local IR Training Course Message-ID: <9507311132.AA05653@ncc.ripe.net> Dear Local IR's, Some of you have just received a message from RIPE NCC Document Announcement with the subject: New Document available. It contained the Announcement for a Training Course in Italy. This was a mistake and you will receive a new message with the correct header. Sorry for the confusion. Kind regards, Mirjam Kuehne RIPE NCC Training Team ------------------------ From training at ripe.net Mon Jul 31 13:36:32 1995 From: training at ripe.net (RIPE NCC Training) Date: Mon, 31 Jul 1995 13:36:32 +0200 Subject: Announcement for Local IR Training Course Message-ID: <9507311136.AA05719@ncc.ripe.net> * * * Announcement * * * Local Internet Registries Training Course Date: Monday, 4th September, 1995 Time: 0900 - 1700 Venue: Consiglio Nazionale delle Ricerche Area della Ricerca di Milano CNR - IFCTR SIAM Via A. M. Ampere, 56 I-20131 Milano Italy -------------- next part -------------- Course Audience --------------- The target audience for this course is personnel of European Local Internet Registries or ISPs planning to set up a local IR. Material Covered ---------------- The course is a one day introduction on Internet name, address and routing policy registration procedures in Europe. It also teaches students how to query and use the information registered for operational purposes. This includes the following material and activities: o Overview of name, address and routing registration procedures. o Responsibilities of both RIPE NCC and Local IR's to each other. o Wider context of the Delegated Registry system and relevant issues (IPv4 address depletion, CIDR) and how this relates to IP requests. o How to use the RIPE NCC Database. o Use of AS numbers, Routing Registry concepts and an introduction to using PRIDE tools. o DNS feedback on commor errors, how to request delegations, and pointers to useful tools. We again stress that this course will *not* teach Local Registries on how to run their business as Internet Service Providers. It is clearly focussed on registration procedures and the interaction between the RIPE NCC and local IR's. A detailed outline is appended below. The course itself will include lunch and will be free. This of course does not include your travel and subsitence ;-). How to Register --------------- Please send an RSVP to if you would like to attend the course. If you have previously approached us about attending this course, we ask you to confirm that you (or a colleague) will be attending. Registrations will be accepted on a first come, first served basis. If the course is oversubscribed, we will give priority to local IRs who have paid the signup fee in 1995. If it is still oversubscribed, we will accept only one person per new local registry. We will provide additional course dates in Amsterdam as necessary. If a number of local registries so request, we will present courses at other European locations. If you would like a local course or have any questions or suggestions, please do not hesitate to contact us. The RIPE NCC Training Team: Mirjam Kuehne, Daniel Karrenberg --- Course Outline -------------- For this second course, we will provide a slidebook and a reader on the day of the course, as well as electronically. Once feedback is received, it is planned to make detailed documentation available in the form of a guide much like the PRIDE guide. The program will divide the actual content into the following sections: 1. Introduction For those unfamiliar with the Delegated Internet Registry system and the RIPE NCC, this section will give a historical overview of how we have arrived at today's model of operation and why training of local IR's is a much needed activity. 2. IP Registry procedures This section will clarify the procedures between the RIPE NCC and local IR's with respect to requests for IP address space. It will take a step by step approach on how to complete documentation, the kind of information that is required, what the "handholding" procedure is, how to deal with very large requests, and very small requests, and more generally what criteria the RIPE NCC and local IR's use for their customers in the context of CIDR and IPv4 address depletion. 3. RIPE NCC Database This section will explain what the RIPE NCC Database is and how it fits into the scheme of other registry databases. It will cover how to create and update RIPE NCC Database objects and will explain how to query the database. 4. Routing Registry procedures This section will examine AS numbers, when you need them and how to request them. This will be set within the context of how AS numbers are used as part of the RIPE Routing Registry. Understanding the basic principles behind the Internet Routing Registry and how registering your policy is an important element in the global schema. This section will also include a brief introduction to the PRIDE tools and how they can be useful to you. 5. DNS procedures Where to request forward and reverse domain delegation. Which documentation should be completed. How reverse domain delegation requests are processed at the RIPE NCC (with a useful tool). We will also take a look at common errors in setting up DNS with respect to relevant RFCs and RIPE recommendations. Feedback Please! Throughout the course there will be ample chance for feedback and discussion with an emphasis for you to tell us how we can improve ;-). -------------- next part -------------- %%%%%%%%%%% PLEASE NOTE %%%%%%%%%%% Our handling of ALL course registrations is fully automated. To register for the course, please complete the registration form and send it to . Please send only the registration form in your reply and edit out all other text. Add in a value in the `box' area marked between the square brackets (i.e. "[" and "]" s). If you have any questions about the training course or your registration form, please contact us at . You will receive a notification message that your request has been processed. Many thanks, and look forward to seeing you, RIPE NCC Training Team ---------------------------------------------------------------------------- %START PART 1 - Registration 1) Your name Enter First name, Last name in FULL e.g. John Doe Mary-Beth Walton # NAME [ ] 2) Your Registry ID (format: country-code.) # REG [ ] 3) Your e-mail address # EMAIL [ ] 4) The course you plan to attend (date and location) # COURSE [ ] %END From training at ripe.net Mon Jul 31 13:54:43 1995 From: training at ripe.net (RIPE NCC Training) Date: Mon, 31 Jul 1995 13:54:43 +0200 Subject: Announcement for Local IR Training Course Message-ID: <9507311154.AA05949@ncc.ripe.net> * * * Announcement * * * Local Internet Registries Training Course Date: Monday, 16th October, 1995 Time: 0900 - 1700 Venue: RIPE NCC Kruislaan 409 1098 SJ Amsterdam The Netherlands -------------- next part -------------- Course Audience --------------- The target audience for this course is personnel of European Local Internet Registries or ISPs planning to set up a local IR. Material Covered ---------------- The course is a one day introduction on Internet name, address and routing policy registration procedures in Europe. It also teaches students how to query and use the information registered for operational purposes. This includes the following material and activities: o Overview of name, address and routing registration procedures. o Responsibilities of both RIPE NCC and Local IR's to each other. o Wider context of the Delegated Registry system and relevant issues (IPv4 address depletion, CIDR) and how this relates to IP requests. o How to use the RIPE NCC Database. o Use of AS numbers, Routing Registry concepts and an introduction to using PRIDE tools. o DNS feedback on commor errors, how to request delegations, and pointers to useful tools. We again stress that this course will *not* teach Local Registries on how to run their business as Internet Service Providers. It is clearly focussed on registration procedures and the interaction between the RIPE NCC and local IR's. A detailed outline is appended below. The course itself will include lunch and will be free. This of course does not include your travel and subsitence ;-). How to Register --------------- Please send an RSVP to if you would like to attend the course. If you have previously approached us about attending this course, we ask you to confirm that you (or a colleague) will be attending. Registrations will be accepted on a first come, first served basis. If the course is oversubscribed, we will give priority to local IRs who have paid the signup fee in 1995. If it is still oversubscribed, we will accept only one person per new local registry. We will provide additional course dates in Amsterdam as necessary. If a number of local registries so request, we will present courses at other European locations. If you would like a local course or have any questions or suggestions, please do not hesitate to contact us. The RIPE NCC Training Team: Mirjam Kuehne, Daniel Karrenberg --- Course Outline -------------- For this second course, we will provide a slidebook and a reader on the day of the course, as well as electronically. Once feedback is received, it is planned to make detailed documentation available in the form of a guide much like the PRIDE guide. The program will divide the actual content into the following sections: 1. Introduction For those unfamiliar with the Delegated Internet Registry system and the RIPE NCC, this section will give a historical overview of how we have arrived at today's model of operation and why training of local IR's is a much needed activity. 2. IP Registry procedures This section will clarify the procedures between the RIPE NCC and local IR's with respect to requests for IP address space. It will take a step by step approach on how to complete documentation, the kind of information that is required, what the "handholding" procedure is, how to deal with very large requests, and very small requests, and more generally what criteria the RIPE NCC and local IR's use for their customers in the context of CIDR and IPv4 address depletion. 3. RIPE NCC Database This section will explain what the RIPE NCC Database is and how it fits into the scheme of other registry databases. It will cover how to create and update RIPE NCC Database objects and will explain how to query the database. 4. Routing Registry procedures This section will examine AS numbers, when you need them and how to request them. This will be set within the context of how AS numbers are used as part of the RIPE Routing Registry. Understanding the basic principles behind the Internet Routing Registry and how registering your policy is an important element in the global schema. This section will also include a brief introduction to the PRIDE tools and how they can be useful to you. 5. DNS procedures Where to request forward and reverse domain delegation. Which documentation should be completed. How reverse domain delegation requests are processed at the RIPE NCC (with a useful tool). We will also take a look at common errors in setting up DNS with respect to relevant RFCs and RIPE recommendations. Feedback Please! Throughout the course there will be ample chance for feedback and discussion with an emphasis for you to tell us how we can improve ;-). -------------- next part -------------- %%%%%%%%%%% PLEASE NOTE %%%%%%%%%%% Our handling of ALL course registrations is fully automated. To register for the course, please complete the registration form and send it to . Please send only the registration form in your reply and edit out all other text. Add in a value in the `box' area marked between the square brackets (i.e. "[" and "]" s). If you have any questions about the training course or your registration form, please contact us at . You will receive a notification message that your request has been processed. Many thanks, and look forward to seeing you, RIPE NCC Training Team ---------------------------------------------------------------------------- %START PART 1 - Registration 1) Your name Enter First name, Last name in FULL e.g. John Doe Mary-Beth Walton # NAME [ ] 2) Your Registry ID (format: country-code.) # REG [ ] 3) Your e-mail address # EMAIL [ ] 4) The course you plan to attend (date and location) # COURSE [ ] %END From ivo.gorkic at quantum.si Mon Jul 31 17:22:15 1995 From: ivo.gorkic at quantum.si (Ivo Gorkic) Date: Mon, 31 Jul 1995 14:22:15 -0100 Subject: Last Resort Registries Message-ID: <9507311220.AA06258@ncc.ripe.net> At 03:22 PM 7/21/95 +0200, Daniel Karrenberg wrote: > > > Antonio_Blasco Bonito writes: > > > > I think it *is* relevant: we are talking about CIDR aggregatable addresses. > > Some US providers do not want to provide addresses to customers in Europe > > from their own address space to save the possibility of continental > > aggregation. This is a point which needs to be clarified at least to > > correctly define the role of Regional registries. > >I only know of one such case and this provider has since changed their >mind (regid eu.sprint). > > > > > I think this document > > > > should have worldwide applicability and be published as an RFC. > > > > > > Do not agree. For European Last-Resort registries a RIPE document is > > > sufficient. > > > > That's not sufficient, I guess. We could start with a RIPE document but > > I'm convinced the issue is *not* restricted to Europe. > >We start with a RIPE document. The problem with an RFCs is that there are >many highly contentious issues associated with a successor to RFC1466. >This document is not going to be agreed quickly. However we need a >revision of ripe-104. So far we have been waiting. ripe-104 is now >sufficiently outdated to go ahead with a revision anyway. I just hope >that we can agree on one in Europe. > >I would prefer it to go the other way round but there seems to >be little choice. > > > RIPE-181 became an RFC for the same reason. Am I right? > >It is an informational RFC about a technology, not about address space >policies. > >Daniel > > > --------------------------------------------------------- Ivo Gorkic Quantum d.o.o. Stegne 21d tel: +386 61 159 72 56 61000 Ljubljana fax: +386 61 159 71 92 Slovenija e-mail: ivo.gorkic at quantum.si ---------------------------------------------------------