- lir-wg - mailman.ripe.net

A Question
by SAEED KHADEMI 06 Feb '01

06 Feb '01

[ Moderator note: changed local-ir(a)ripe.net -> lir-wg(a)ripe.net ] Hello, Dear coleagues, Please excuse me if this is not the right place for this kind of questions. I am working as a LIR hostmaster since 5 years ago. Due to the act of people of another LIR, a question has rised in my mind. And I want to know about any defined regulation in this regard. The Question: Is it legal that technical persons of one LIR, ask their customer to return other LIR assignments, because the customer has asked for new IP assignment? This has been accured many times. Customer having some IP assignments from LIR-1, are applying for new IP assignments from LIR-2. But people at LIR-2 are saying that if you want new IP assignments, you HAVE TO return LIR-1 assignments !!!!!!! Any comment? Kind Regards, IPM LOCAL REGISTRY, Tehran/Iran Saeed.

4 3

RE: A Question
by SAEED KHADEMI 05 Feb '01

05 Feb '01

>As far as I know, there are two feasible cases: > >1. The customer MOVES from one ISP to another >2. The customer connects to ANOTHER ISP, while using the other ISP Hi, Many Thanks for all comments. The case I meant was exactly the 2nd one. Customer has an old connectivity to LIR-1 and have got a new connection from LIR-2. >2 is usually performed either by the use of BGP or by the use of static >asymmetric routing, or RADWare's LinkProof. That's the case. >In the 2nd case, the reason here is usually high availability and/or load >balancing between links/ISPs. In this situation, the customer NEEDS both the >assignments. In this case, what should people at LIR-1 Do? Can they ask LIR-2 people to stop forcing customers? And if the answer is positive, What's the rule, if LIR-2 people continue to behave like that? >I believe that 'legal', a LIR cannot just 'demand' that a customer would >return their previously-assigned IPs unless there's a reason (i.e., the >situation is case #1). It might be that that specific LIR is having problems >with its AW (let's say their AW is 256 ips, and the customer already has >IPs, it might be that the 'new' LIR needs to send a RIPE-141 to RIPE - and >they might be too lazy to do that). I agree. Another possiblity is that LIR-2's people are trying to fulfill their own test period ( according to RIPE NCC slow starting ) and somehow attack to LIR-1 reputation. Kind Regards, IPM LOCAL REGISTRY, Tehran-Iran Saeed.

1 0

RE: A Question
by Yuval Shchory 05 Feb '01

05 Feb '01

As far as I know, there are two feasible cases: 1. The customer MOVES from one ISP to another 2. The customer connects to ANOTHER ISP, while using the other ISP 2 is usually performed either by the use of BGP or by the use of static asymmetric routing, or RADWare's LinkProof. In the 1st case, there's no reason to continue the assignment, the customer is holding addresses which they cannot use. Period. In 99.9% of the cases a customer receives a fraction of a larger aggregate, and there's no reason/possibility that the new ISP will be able to route that fraction via BGP to the world. This means - no packets would arrive to that customer (with destination IP of the old IPs), which leads us to the conclusion that the assignment should be returned. In the 2nd case, the reason here is usually high availability and/or load balancing between links/ISPs. In this situation, the customer NEEDS both the assignments. I believe that 'legal', a LIR cannot just 'demand' that a customer would return their previously-assigned IPs unless there's a reason (i.e., the situation is case #1). It might be that that specific LIR is having problems with its AW (let's say their AW is 256 ips, and the customer already has IPs, it might be that the 'new' LIR needs to send a RIPE-141 to RIPE - and they might be too lazy to do that). Just my $0.0000000000002 Regards, --- Yuval Shchory Manager Security Group NetVision Ltd. interFax: +972-3-5480255 -----Original Message----- From: Andre Koopal [mailto:andre@NL.UU.NET] Sent: Monday, February 05, 2001 11:45 AM To: lir-wg(a)ripe.net Subject: Re: A Question On Mon, Feb 05, 2001 at 11:58:47AM +0330, SAEED KHADEMI wrote: > [ Moderator note: changed local-ir(a)ripe.net -> lir-wg(a)ripe.net ] > > > Hello, > Dear coleagues, Please excuse me if this is not the right place for > this kind of questions. > I am working as a LIR hostmaster since 5 years ago. Due to the act of > people of another LIR, a question has rised in my mind. And I want to > know about any defined regulation in this regard. > The Question: > > Is it legal that technical persons of one LIR, ask their customer to > return other LIR assignments, because the customer has asked for new > IP assignment? > This has been accured many times. Customer having some IP assignments > from LIR-1, are applying for new IP assignments from LIR-2. But people > at LIR-2 are saying that if you want new IP assignments, you HAVE TO > return LIR-1 assignments !!!!!!! > > Any comment? > Some thoughts on this from me, not neccesarely the truth. As LIR they can say that if you don't return space, you have to much space, so the request isn't justified. If the customer can proof he has the need for both chunks of space ... As an ISP you can (and should) refuse the customer to route his ip-space from his old provider. Both together mean that in the ordinary case of a customer migrating from one ISP to another they can force the customer to return his old space. Regards, Andre

1 0

RE: A Question
by Marian Kruydenhof 05 Feb '01

05 Feb '01

Hello Saeed, To my knowledge it is possible for a customer to have assignments from 2 LIR's. if the customer is requesting ip space from LIR2, LIR2 should make sure that the customer will not use the ip space for the same purpose as the ip space from LIR1. for example, the customer can not address a host with ip space from both LIR1 and LIR2. How the customer will use the address space is specified in the addressingplan template. You should take this into account when evaluating the addressingplan template. What you describe below is not our policy. regards Marian Kruydenhof KPN Telecom, Netherlands -----Original Message----- From: SAEED KHADEMI [SMTP:saeed@vax.ipm.ac.ir] Sent: Monday, February 05, 2001 9:29 AM To: local-ir(a)ripe.net Subject: A Question [ Moderator note: changed local-ir(a)ripe.net -> lir-wg(a)ripe.net ] Hello, Dear coleagues, Please excuse me if this is not the right place for this kind of questions. I am working as a LIR hostmaster since 5 years ago. Due to the act of people of another LIR, a question has rised in my mind. And I want to know about any defined regulation in this regard. The Question: Is it legal that technical persons of one LIR, ask their customer to return other LIR assignments, because the customer has asked for new IP assignment? This has been accured many times. Customer having some IP assignments from LIR-1, are applying for new IP assignments from LIR-2. But people at LIR-2 are saying that if you want new IP assignments, you HAVE TO return LIR-1 assignments !!!!!!! Any comment? Kind Regards, IPM LOCAL REGISTRY, Tehran/Iran Saeed.

1 0

Draft agenda lir-wg: regional issues
by Hans Petter Holen 24 Jan '01

24 Jan '01

Dear lir-wg, here is a draft agenda for tomorrows meeting. My sincere appologies for this late submission. A draft agenda for todays lir-wg global issues will follow shortly. Note that some of the issues have status pending due to lack of confirmation from the speakers. Note also that I have put the issue "management of the working group on the agenda." Here you will have the oportunity to suggest improvements to the running of this wg. Do not forget this is your forum to set and change policy ! Sincerely, Hans Petter Holen 1 Admin - scribe, participant list, charter, mailing-lists 2 Agenda - moved reports top plenary only 3 RIPE 37 minutes & actions 4 Report from the RIPE NCC Hostmasters by Nurani Nimpuno incl. Meet the hostmasters 5 Discussion on service level improvements, 17th of may task force 6 Management of working group x-X-x Break xX-x 7 IPv4 address exhaustion, by Tony Holmes and Paul Mylotte 8 Ip addressing for mobile handsets (to be confirmed) 9 Provider Independent addresses (to be confirmed) 10 36.5 Assignment window applied on infrastructure (to be confirmed) 11 36.7 Transfer of pre RIR address space to LIR 12 Preparing the plenary AC election: candidates, proceudres 13 PGP Key Exchange (to be confirmed) 14 Restoring the transparency (continued, to be confirmed) EOM

1 2

Delays in RIPE Database updates
by RIPE Database Administration 22 Jan '01

22 Jan '01

Dear All, As some of you may have already noted, we are experiencing delays with the processing of updates in the RIPE Database. This is due to the fact that the last week-end, the reindexing of person objects took much longer than expected; in the meanwhile, no updates could be processed, so they remained blocked in the queue. As of now, the updates are being regularly processed. We want to stress the fact that your updates will be eventually processed and there is no need to resend your update messages; this will have the sole effect of adding load to the update queue. To check the current wait time for updates and other operational statistics for the RIPE Whois Database server, please see: http://www.ripe.net/ripencc/pub-services/db/mrtg/whois.html We apologize for any inconvenience this may cause or have caused. If you have any questions, please don't hesitate to contact <ripe-dbm(a)ripe.net>. Regards, Daniele Arena ____________________________ RIPE Database Administration.

1 0

X-NCC-RegID:es.uni2
by Mijangos Rodriguez, Carmen 22 Jan '01

22 Jan '01

Hello: I'm not sure if I can ask the next questions in this mail-box, if It is not possible my apologise. I have some questions: 1) When we ask for a group Address assignment, have we to detail how many objects we are going to create?, or if all the objects have the same netname is enough with one object? 2) When we ask for some Address assignment and a hostmater send us a mail to accept this request, A- We have to create the objects of all this addresses very soon or we have some time to create the objects? How much time? B- Can we combine this approved address with other existing assignments ? 3) About the reverse delegation, we have two objects domain: 37.62.in-addr.arpa .... nserver: m2dnsnet1.net.uni2.es .... domain: 36.62.in-addr.arpa .... nserver: m2dnsnet1.net.uni2.es With this objects when arrive to RIPE a request reverse delegation of this address RIPE send to our "nserver: m2dnsnet1.net.uni2.es" this request. If we create other reverse delegation in RIPE of our addresses for a customer, for example: domain: 255.37.62.in-addr.arpa nserver: "customer_server" nserver: m2dnsnet1.net.uni2.es Now when arrive to RIPE a request reverse delegation of this address, 62.37.225.0 - 62.37.225.255 RIPE send to "customer_server" this request, and the rest of the request of address 62.36.0.0 - 62.37.255.255 are sent to our "nserver: m2dnsnet1.net.uni2.es". Is correct all this?? Thanks in advance Kind regards Carmen Mijangos Carmen Mijangos UNI2 - Técnico de Servicios de datos Dirección Técnica Teléfono : +34 912520972 / Móvil: +34 667493879 e-mail: CMijangosR(a)uni2.es http://www.uni2.es

2 1

URGENT: Database problems?
by Berislav Todorovic 21 Jan '01

21 Jan '01

Dear RIPE NCC colleagues, I'm sure yo have a lot of work to do regarding the forthcoming RIPE Meeting, but can someone, please, take a look on the database update queue? Either the queue is full or the automatic email robot is broken. We sent an update of AS-KPNQWESTRO few times since Friday and no answer we got from the robot. That's 3 (three) days !!!!!!!!! Thanks! Beri --------- Berislav Todorovic, Network Engineer --------- ------- KPNQwest N.V. - IP NOC (formerly EUnet NOC) ------- ---- Wilhelmina van Pruisenweg 78, 2595 AN Den Haag, NL ---- --- Phone: +31-70-379-3990; Mobile: +31-651-333-641 --- -- Email: beri(a)kpnqwest.net <=> beri(a)EU.net -- --- _ _ ____ _ .--. ____ ____ __/_ --- ----- /__/ /___/ /\ / / / | / /___/ /___ / ------ ------ _/ \_ / _/ \/ (__.\ |/\/ /___ ____/ (__. -----

3 2

RE: Announcement: RIPE Whois Database Version 3.0beta2 released
by Sam Mortimer 19 Jan '01

19 Jan '01

> From: Nipper, Arnold [mailto:arnold.nipper@de-cix.net] > Sent: 19 January 2001 14:10 > > rpsl.ripe.net doesn't seem to exist ... > > whois -h whois rpsl.ripe.net Daniele Arena > whois: whois: Unknown host: Datei oder Verzeichnis nicht gefunden > > Let's have a look ... > > ;; ANSWER SECTION: > rpsl.ripe.net. 1d23h59m55s IN CNAME reimp.ripe.net. > reimp.ripe.net. 1d23h59m55s IN CNAME orange.ripe.net. > orange.ripe.net. 1d23h59m55s IN A 193.0.1.239 > > Yeah, don't do that. Don't use CNAME to CNAME. Pls fix, CNAME to CNAME is fine. it's used all the time with reverse DNS. works fine for me. Regards, -Sam.

2 1

Announcement: RIPE Whois Database Version 3.0beta2 released
by RIPE Database Announcements 19 Jan '01

19 Jan '01

Dear All, This mail is to inform you that version 3.0beta2 of the RIPE Whois Database software has been released. This is mainly a bugfix release in respect to the "beta1" version. We remind you that the RIPE Database is about to change its data format, from RIPE181 to RPSL (the Routing Policy Specification Language, see RFC2622). This will affect all object types, including "person", "domain" and "inetnum". We suggest you to start to get used to RPSL and version 3.0 . Please check our RIPE-181 to RPSL Migration page at: http://www.ripe.net/rpsl/ You can test your skills with RPSL and the functionality of the new beta release in the following ways: - Query rpsl.ripe.net at port 43. You will find there exactly the same objects that are in whois.ripe.net, mirrored live and in RPSL format. - If you have any script that runs by querying whois.ripe.net, test it by pointing it to rpsl.ripe.net and make it v3.0-compliant. - Try our CGI interface to the RPSL server: you can find it at http://www.ripe.net/ripencc/pub-services/db/reimp/. - Get to know the new update path: use our "sandbox" database for RPSL updates. Send your updates to <auto-rip(a)ripe.net> and query the corresponding database at rpsl.ripe.net, port 4343 . Remember that in a few months, that's the way the RIPE Database will be running; so the earlier you start working with it, the less likely you are to be unpleasantly surprised later. For those running Near-Real-Time Mirrors of the RIPE Database, please be advised that as soon as the RIPE Database changes its data format, you will not be able to mirror the RIPE Database using the version 2 of the Software, since it is not RPSL-compliant. You will have to upgrade to version 3 to mirror the RIPE Database. Please contact <ripe-dbm(a)ripe.net> for detailed information. Please note that the software is still in a "beta" phase. So we need your feedback! If you happen to find something that looks like a bug when you are testing the RPSL database, don't hesitate... Send us a bug report at <dbrip(a)ripe.net> ! If you want to actively participate to the migration effort, you could join the "RIP migration Task force" and let yourself be heard. Just write to <ripe-dbm(a)ripe.net> and ask to join the Task Force. You can download the latest release of the source code at the following URL: ftp://ftp.ripe.net/ripe/dbase/reimp/ripe-dbase-3.0beta2.tar.gz You can also join a discussion list related to version 3.0 beta of the RIPE Database Software. To subscribe to this list, send a message to <majordomo(a)ripe.net> with the line: subscribe db-beta in the body of your letter. It is a moderated mailing list so some delays in subscription are possible. Regards, Daniele Arena ___________________ RIPE Database Group RIPE NCC

2 1