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

Re-registration of the ip address from the closed LIR to new LIR
by Sergey Artjushkin 15 Jul '02

15 Jul '02

Hello colleagues Our company and our partners have faced with one problem. During along time between ours the companies there were very close relations, not only financial, but also technically. Recently a management of both companies have solved to consolidate two companies in one. Both at a financial level and on a technological level. As the technical worker, I can tell, that all clients of our partner pass to us and networks of both companies will be combine. Both companies were registered in RIPE and have received LIR, AS and ip space. As a result of closing the company of our partner LIR registration will be stops and ip addresses will be back. In this connection, technical workers of both companies with horror expect merge of the companies. From one idea, that it is necessary to replace all clients on new ip addresses become badly. Our partners was working during a long time and for this time they have collected the big base of clients. At present, our partners has two blocks of addresses: /19 and /17. Our company will not have not enough ip addresses so we should ask additional ip space. And now my question is: It is theoretically possible to re-register addresses our partners, as belonging to us (new origin in route object and new MNT in network object). How it to make practically? I have sent the letter in RIPE but yet have not received any answer. Thank you for advance for any help. -- With best regards. ------------------------------------------------------------------ Sergey Artjushkin Network Operation Center Phone: +7 (095) 363-22-52 ISP "CARAVAN" Fax: +7 (095) 363-22-52 http://www.caravan.ru

2 1

need help !
by Razavi (Support) 13 Jul '02

13 Jul '02

Dear friends Im a new technical admin and new one in ripe knowledge, newly i heard about the new AS# policy but i didnt understant any thing ! is there some one over there to help me or gives me some information about that? wait for your help, Best Regards, --Razavi.

2 1

RE: [lir-wg] AS Number Policy
by Lu, Ping 12 Jul '02

12 Jul '02

> -----Original Message----- > From: Berislav Todorovic [mailto:beri@kpnqwest.net] > Sent: Wednesday, July 10, 2002 6:38 AM > To: Hank Nussbacher > Cc: Christopher Sharp; lir-wg(a)ripe.net > Subject: Re: [lir-wg] AS Number Policy > > > On Wed, 10 Jul 2002, Hank Nussbacher wrote: > > >> I'd like to make a suggestion. Since these ASNs and IP > blocks are the > >> property of the RIRs, and since organizations are cybersquatting on > >> these resources why shouldn't these RIRs advertise these > IP blocks and > >> ASNs themselves and blackhole them to their routers? > > I'd like to back this idea! > > However, even if ICANN itself suddenly gets stroken by > lightning of technical > wisdom and starts announcing unused /8's - that won't prevent > offenders from > announcing more specific routes, will it? On the other hand, > announcing /24's > will really pollute the global routing table, which is big > enough anyway. I don't think to blackholing traffic is a good idea, especially when bandwidth means money in today's internet. RIRs should publish a list to include all the offending prefixes and the major ISPs will be more than happy to apply the prefix filter to block transit to those prefixes. There is already an IANA bogon filter floating around. RIPE NCC could add a filter-set object, let's say FLTR-RIPE-RESERVED-IPV4 and ARIN should have a FLTR-ARIN-RESERVED-IPV4 object, APNIC also should have a FLTR-APNIC-RESERVED-IPV4 object. Then all major ISPs could apply these filter to block transit traffic for these prefixes. > > Still, having a service like Paul Vixie's AS7777 would help a > lot: an ISP > willing to receive blackhole routes would bring a route > server on their > backbone, establish a peering session with "IANA blackhole > AS" and use the > routes to construct filters etc. > > Regards, > Beri > Blocking is a better idea than blackholing.... Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net

6 14

RE: [lir-wg] AS Number Policy
by BLOCKI,JACEK (HP-Poland,ex1) 11 Jul '02

11 Jul '02

If we need AS revocation policy and cannot agree on usage auditing based on technical wisdom, we can consider some old fashioned administrative measures such as AS subscription fee paid to RIR. Make it 1$/year AS maintenance fee paid to RIR (similar to LIR fee). It will at least allow to identify ASes assigned to terminated organizations. Feel free to flame me ;-) Regards, Jacek

1 0

RE: [lir-wg] AS Number Policy
by Wilfried Woeber, UniVie/ACOnet 11 Jul '02

11 Jul '02

>I think that this is up to the definition of "publicly visible". If I have >one upstream and several peers, that is to me "public". I see few (no?) >other real reasons for assigning an AS that is not seen through two or more >paths in the global routing table. It is not that rare. For example we do have some universities which have one upstream (us, ACOnet) and peerings with other ISPs (for whatever reason) _but no transit_ from them. Some of them would be "visible" (e.g. those with legacy class B space), others would be proxy aggregated into our /15 and "disappear". But, to come back to another comment: we're discussing details of routing configuration (because that's "easy"?) but I haven't seen any comment yet on my question on price/effort vs. (expected) result ratio (maybe because it's a bit more difficult? ;-). Wilfried.

2 1

RE: [lir-wg] AS Number Policy
by Lu, Ping 11 Jul '02

11 Jul '02

> -----Original Message----- > From: Kurt Erik Lindqvist [mailto:kurtis@kurtis.pp.se] > Sent: Thursday, July 11, 2002 6:41 AM > To: lir-wg(a)ripe.net > Subject: RE: [lir-wg] AS Number Policy > > > > > A customer can have a peer with the default transit, which > aggregates the > > adresspace from the customer, and the customer can have > other peerings > > via some ix:es, and the customer could perform transit > to/from the ix:es > > to the default transit, in this scenario the customer MUST > have a public > > AS, which you will not see in the public space, since > removing private > > AS in the AS-path will result in somewhat unpredictable > behaviour if there > > are several private AS involved at the customer premises. > > Yes, but this still makes the AS publicly visible. > > Best regards, > > - kurtis - > As we already seen some real examples, the correct USED ASN will only be seen from their upstream (it is public no matter what) but not outside to other peers (may due to CIDR, may due to inactive route). This has nothing to do with private ASN but make it impossible to enforce the proposed policy just by looking at the RIS. I agree that RIPE NCC need to have an ASN revoke policy but just can NOT based on the RIS info only. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net

1 0

A quick question.
by Stephen Burley 11 Jul '02

11 Jul '02

HI I have a question about the RIPE meetings. Due to the nature of the business we are all in at the moment (myself probably more than others ATM), would it not be possable the webcast the RIPE meetings allowing input from outside via phone, email, or other means. The reason i ask this is that the meetings are open to all IF and its a big IF you can attend the meeting in the exotic locations we have met in the past. I am not against the meetings moving about and a meeting in Amsterdam will be just as hard to get to for some one in North Africa as a meeting in North Africa for those in Amsterdam. What i am asking is could we make it more accessable to those who for what ever reason (ahem) can not make the meeting, otherwise it might not have the coverage and diversity of people having input. Just a thought. Regards, Stephen Burley WorldCom EMEA Hostmaster SB855-RIPE

2 1

RE: [lir-wg] AS Number Policy
by Lu, Ping 11 Jul '02

11 Jul '02

Several examples: 1. Confederate AS : only the top level AS number is announced by design, all member ASes should not be visible outside the confederate. 2. CIDR aggregate : If customer's address got aggregated by upstream ISP, usually you won't see their AS numbers from the upstream ISP's CIDR (especially for those people like to filter on allocation boundary). Technically I don't see how RIPE NCC can possibly find all the ASes that are originated but invisible to the public route server. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net > -----Original Message----- > From: Vladimir A. Jakovenko [mailto:vovik@lucky.net] > Sent: Tuesday, July 09, 2002 3:26 PM > To: Lu, Ping > Cc: 'wtremmel(a)vianetworks.com'; 'Matthew Robinson'; Wilfried > Woeber, UniVie/ACOnet; lir-wg(a)ripe.net > Subject: Re: [lir-wg] AS Number Policy > > > On Tue, Jul 09, 2002 at 02:01:26PM -0400, Lu, Ping wrote: > >This has nothing to do with the private AS-number. > > > >If an AS number existed in our backbone (public to CW) but not to > >RIPE NCC's route server. Will that be considered NOT USED ? > > Could you possibly provide us with more examples in which > circumstances someone > may need to use AS number from the PUBLIC range instead of > using AS number from > PRIVATE range in the case when there is no need to advertise > any prefixes > originated by such AS-number to the PUBLIC Internet (i.e. > this AS number will > never be visible outside of some private network)? > > I can remind only one case - some kind of IX, are used by > some ASes to > exchange routing information localy. Generaly speaking IX-AS > may not be > visible from PUBLIC, but in the most cases, especialy if we > are talking > about enterprise networks, same results may be achieved by > using AS-number > from private range. > > By way of proof - AS15645 is used for the public Ukrainian > Internet-Exchange. > Appearance of any prefixes originated by this AS outside of > IX members networks > violates IX rules and should be avoided. > > Lets summarise - there ARE circumstances when AS number from > PUBLIC range may > be requested and used being invisible from the majority of > the Internet. > > It would be nice to mention that in policy and provide some examples. > > -- > Regards, > Vladimir. >

5 7

RE: [lir-wg] AS Number Policy
by Lu, Ping 11 Jul '02

11 Jul '02

Definitely there is AS number being used within our backbone but not advertised to public network. So the AS number should be allowed to be registered but not advertised the same way as IP address is treated. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net > -----Original Message----- > From: Matthew Robinson [mailto:matthew@crescent.org.uk] > Sent: Tuesday, July 09, 2002 9:57 AM > To: Vladimir A. Jakovenko > Cc: Wilfried Woeber, UniVie/ACOnet; lir-wg(a)ripe.net > Subject: Re: [lir-wg] AS Number Policy > > > In the documentation for address space provision is made for > assigning addresses to organisations that will NEVER be > connected to the Internet but require uniqueness from private > address space. > > Whilst I can't think of a specific example to apply to AS > numbers, should this uniqueness be extended to AS numbers > that do not show up in the routing table but are very much on-line? > > I also recon 3 months to get online although given the length > of time it can take a big comapany to integrate a small one > lets say 12 months for returning. > > Kind regards > > Matthew >

6 8

RE: [lir-wg] AS Number Policy
by Lu, Ping 11 Jul '02

11 Jul '02

[snip] > > Yes. I had recently a lengthy "discussion" with RIPE hostmasters about > a multihomed AS of a customer. Primary upstream with us, secondary > upstream with AS702. Using 702:80 community to lower localpref within > 702, making the backup link real backup. As 702 announces best path > (which is via their peering to us to the customer), RIPE was unable to > see the 702 backup announcement anywhere. Explanation of BGP basics by > myself were not understood or ignored. Or both. They also did not > contact AS702 for simple confirmation of what I've told them. > Took three > or four emails to get that finally sorted out. Whom do I bill > those 30-45 > minutes to (rhetoric question)? ;-> > This is another good example why AS number is originated but invisible to the global routing table. > End of the story was that they finally said "We have found AS21197 in > the import policy of AS702 and going to close this ticket now." :-]]] > > IF they really want to enforce ASN assignment policy, they > should REALLY > have to have a clue about BGP. Looking at some random looking glasses > or RIS data and not understanding it is NOT enough for a > policy-enforcing agency. And someone should explain them the > difference > between a looking glass and a traceroute server. > > Let's say... Halabi as compulsary lecture for hostmasters who have to > evaluate ASN assignment policy compliance. :-) > > > Regards, > Daniel > It is almost impossible for RIPE NCC to look into all upstream ISP's routing table and verify that an AS is being used properly. If RIPE NCC can't find a way to reduce the false alarm of AS verification, the enforcement will become more likely an harassment. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net

3 2