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

Draft minutes from lir-wg at RIPE 41
by Hans Petter Holen 10 Sep '02

10 Sep '02

Dear WG, The RIPE NCC have just finished the draft minutes and published them on the RIPE web site under: http://www.ripe.net/ripe/wg/lir/r41-minutes.html RIPE Meeting: 41 Working Group: LIR Status: 1st Draft Revision Number: 1 Please mail comments/suggestions on: content to the Chair of the working group. format to webmaster(a)ripe.net. ---------------------------------------------------------------------------- --- Draft Minutes of the LIR Working Group session of the RIPE 41 Meeting 14-18 January 2002, at the Krasnapolsky Hotel, Amsterdam, Netherlands. ----------------------------------- Chair: James Aldridge Vice-Chair: Denesh Bhabuta Scribe: Jeannette Decades ----------------------------------- Agenda: A. Admin - scribe, participant list, charter, mailing-lists B. Agenda bashing C. RIPE 39+40 (minutes & actions) D. Report from the RIPE NCC Hostmasters E. RIPE 185 ("European Internet Registry Policies and Procedures") F. Change of policy for Portable address space G. RFC 2050 ("European Internet Registry Policies and Procedures") revision H. Report from The Address Council Y. Any Other Business Z. Open Microphone. Denesh Bhabuta (DB): Hans Petter Holen couldn't make it. So the meeting will have to do with James Aldridge and myself, Denesh Bhabuta. We want to set a ground rule: One of the complaints from the past was that the LIR WG has been fed with too many discussions. Discussions are supposed to happen on the mailing lists and policy decisions are to be made at the meeting. James Aldridge (JA): The agenda was sent out yesterday to the mailing list. ======================== A: Scribe. ======================== DB: Could we have a non-RIPE staff scribe please? No reactions. A RIPE staff member is scribe. ======================== B: Agenda bashing ======================== JA: Are there any additional items for the agenda? No reactions. ======================== C: RIPE 39 and RIPE 40 minutes and actions. ======================== JA: The minutes are on the website since November we think. Actions as it appears on the website, few of them are very old actions from RIPE 35, 36 and 38. Most of these had something happened since the last RIPE meeting. A lot of it is ongoing work. The 38.5 LIR-Allocated, my original suggestion, is now LIR-Partitioned and some email is sent out this week. It is now in the test database and will go live real soon now. Working group chair roles is working fine since Hans Petter Holen is not here and I am. Policy action undivided address space action on the working group to participate on the RFC 2050 is in progress. ======================= D: Report from the RIPE NCC Hostmasters ======================== Presentation of Sabrina Waschke can be found at: http://www.ripe.net/ripe/meetings/archive/ripe-41/presentations/lir-rsreport /index.html Some additional comments from Sabrina on the slides: RS staffing. We have now 5 teams. Three new hostmasters are starting in January. At this point we hope to be fully staffed and can cope with the workload. And as you can see, you have probably seen it before, we also work on future growth. (Sabrina shows her big belly). Number of requests in hostmaster(a)ripe.net. In 2000, we see a peak but now the graph shows a steady growth. We introduced last year the two-day-turnaround time for ongoing tickets. That meant that when your request was picked up out of the wait queue, a hostmaster dealt with it, you replied, you had to wait for 48 hours before you got a response from us again. That means that correctly filled out requests get a faster approval. The special lir-help(a)ripe.net mailbox is not holding up normal requests anymore. We still apply the 'approve but educate' approach. Even not perfect requests got approved and we gave tips and information for improvements to get a faster approval next time. Wait queue. The last 6 months the wait queue is low. The last 2 months it is a bit higher, due to Dutch weather (sickness) and Christmas holidays. Total LIRs per region. The growth is slowing down. We don't expect too many new LIRs. IPv4 Allocation distribution. LIRs that are working all over Europe have the country code EU. Policy development. A message was sent out to the LIR WG concerning the /20 criteria. At RIPE 40 the decision about the Assignment Window (AW) for infrastructure for LIRs was decided upon and it was introduced in December 2001. Already 250 objects have been created in the database with the INFRA-AW extension. Not all of them are valid. Some LIRs have tried to use this to clean up the database. RS services are working on a document that tries to cover everything concerning mergers, take-overs and closures of LIRs. IPv6. The assignments for Exchange Points have been introduced in August 2001. E: RIPE 185 ("European Internet Registry Policies and Procedures") ======================== Nurani Nimpuno (NN): We encourage everyone to look at the document and to give comments. We're speaking about the new policy draft document for IPv4 policies. The document has been out on the web for 5 months and there was very little activity. The couple of comments that have been made have been published on the LIR WG mailing list. JA: I'm not sure how much more we can do. There hasn't been very much discussion on the mailing list about this. My opinion is this, more profitable work is done on the mailing list. Then we can come to the RIPE meetings for final decisions, rather than having long drawn-out arguments and conversations here. But are there any brief comments from anyone here? Because we're actually ahead of schedule and I'm trying to think of anything to fit in a bit of time. I encourage everyone to join the mailing list and to participate in the revision process. The email address is ripe-185bis(a)ripe.net. ======================== F: Change of policy for Portable address space ======================== JA: The question is if people are happy with the new policy? No reaction. DB: Are people aware of the policy change? It's about the requirements of a /22 immediate or the previously use of a /22 to become a new LIR. This was voted on at the last RIPE meeting. Any thoughts? Are people finding it difficult with their customers who want to be mainly multi-homed? Comments? No? We will continue this discussion on the mailing list. ======================== G: RFC 2050 ("European Internet Registry Policies and Procedures") revision ======================== JA: The agenda on the web was wrong about this one. This should be the RFC 2050, the global Internet Registries guidelines, which is being revised and prolong sides the European policy. Again joining the mailing list for participation and discussion is appreciated. Are there any comments for now? Mark Mcfadden (mcf(a)uwm.edu) I'll give a brief update. There is a mailing list available through ARIN for the global RFC 2050 discussion. Part of that working group, there are also some milestones. We're a little bit behind on those because of some things that happened at the end of last year. But we can start see there again is some movement forward. So I encourage anyone who is interested in the discussion of the revision of RFC 2050 to make sure that you're part of that mailing list. Mailing list address: rfc2050-WG(a)arin.net JA: Any questions, comments, anything? Comment from ?: I think that there are more hostmasters here are than LIRs. ======================== H: Report from The Address Council ======================== Barbara Roseman gave a report from the Address Council. Slides can be found at: ======================== Y: Any Other Business ======================== UUNET: There has been a discussion on the mailing list about PI - multihomed issues. The question raised if multi-homed is always needed or not. We have customers that need multi-homing. But not all providers will route small address blocks. JA: I don't know if there's anything that the LIR WG can do to force providers to route any particular address space. I would be inclined, rather than a policy change our of LIRs, have the Routing WG work on this issue and come up with a 'best practice or something'. DB: We can talkabout 'best practice' but there are commercial realities behind this as well. A lot of ISPs have customer requirements to fulfill. You're not the only person who has spoken about this issue with us and it has mainly come up since the last policy change. This was about the minimum requirement of a /22 before we can get address space. Are there any suggestions? UUNET: As far as I can see, the company that I work for, which is UUNET, is thinking about(at least the hostmaster is, which I am not) having a policy where you accept other provider's PA space instead of trying to go the PI route. This is current thinking, this is no decision, but the problem is we don't have a consistent policy across our AS and we'd like to implement one. Before we implement it we'd like to have consistent policy within RIPE. The problem is that whenever we get the discussion, everybody starts jumping and shouting saying: "Multi-homing". Then the discussion dies because multi-homing is the issue. But before we solve that problem we would like to have something implemented that is workable right now instead of waiting until we solve the mult-homing discussion, which seems to be without a logical solution. DB: My suggestion is that we take this up with the Routing WG as well and maybe we can make this into an action item from this meeting. UUNET: I didn't raise it in the Routing WG yesterday, thinking that was more appropriate to the LIR WG. I guess there were some initiatives in the community, but they all died. So I wonder if there's anybody else that feels like this, something we need to resolve rather sooner than later. DB: Any other comments? No reaction. UUNET: I guess there's too much RIPE NCC people here as previously discussed. DB: We'll set it as an action point. JA: This is the first new action point from this RIPE meeting. Any other questions, comments? I think this is about it for this morning. Please participate on the mailing lists. It does make it so much easier if there's been discussion before RIPE meetings. We can then reach final decisions at these WG-meetings.

2 1

AS Number Policy - continued
by leo vegoda 02 Aug '02

02 Aug '02

Dear Colleagues, Thank you for your comments on my initial questions and the wide ranging discussion that took place. I would like to continue this discussion by asking two more questions: 1. Should the RIPE NCC check whether Autonomous System Numbers it has assigned become multi-homed within six months? If you would like us to do this, the RIPE NCC proposes to do so by looking at routing policies registered in the Routing Registry. 2. Should the policy be changed so that AS numbers not in use can be reclaimed? If there is consensus on this we propose to reclaim AS numbers of networks not multi-homed after six months. Kind regards, -- leo vegoda RIPE NCC Registration Services

11 23

PGP support
by Christakis Christophorou 30 Jul '02

30 Jul '02

Dear colleagues, I would like to implement a PGP authentication scheme with RIPE. I would appreciate any help including suggestions about any plugin to be used with an existing email client software (outlook express etc) or any completely independent software. I have tried PGP Freeware with success but keys state that this version is for "non commercial use" and Network Associates does not support it any more. I have also tried GnuPG but without any success (keys are created with 0 bytes). Thanks Chris

1 0

Re: New draft: "New Values of the 'status:' attribute for inet6num Objects"
by Wilfried Woeber, UniVie/ACOnet 26 Jul '02

26 Jul '02

Dear Leo and "Team", >The new draft is available from our web site at: > ><http://www.ripe.net/ripe/draft-documents/new-value-status.html> Looks good! >We would welcome comments on this new draft until Thursday, 1 August >2002. All comments and suggestions should be sent to <lir-wg(a)ripe.net>. Procedural question: How are we going to modify existing objects to conform to this proposal? Right now the template query returns: bash-2.05a$ wripe -t inet6num [ ... ] inet6num: [mandatory] [single] [primary/look-up key] [ ... ] status: [generated] [single] [ ] [ ... ] and it seems to be "optional" for the (new) ALLOCATED-BY-RIR case: bash-2.05a$ wripe -r 2001:0628::/35 [ ... ] inet6num: 2001:0628::/35 netname: AT-ACONET-19990920 descr: ACOnet Sub-TLA block country: AT admin-c: WW144 tech-c: WW144 tech-c: WK42 tech-c: CP8-RIPE notify: Domain-Admin(a)UniVie.ac.at mnt-by: RIPE-NCC-HM-MNT mnt-lower: ACONET-LIR-MNT changed: hostmaster(a)ripe.net 19990920 changed: hostmaster(a)ripe.net 20011019 source: RIPE Is this going to change? E.g. to: status: [mandatory] [single] [ ] The wording used in the draft seems to indicate [optional] [single] [ ]. I think some clarification would be helpful. Thanks, cheers, Wilfried. _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

3 2

New draft: "New Values of the 'status:' attribute for inet6num Objects"
by leo vegoda 25 Jul '02

25 Jul '02

Dear Colleagues, Thank you for the comments we have received on the draft document "New Values of the 'status:' attribute for inet6num Objects". We have revised it to incorporate the suggestions you have made. The meaning of the labels has been made clearer, in line with the comments received. ALLOCATED-BY-RIR - For allocations made by an RIR to an LIR. ALLOCATED-BY-LIR - For allocations made by an LIR or an LIR's downstream customer to another downstream organisation. ASSIGNED - For assignments made to End User sites The new draft is available from our web site at: <http://www.ripe.net/ripe/draft-documents/new-value-status.html> We would welcome comments on this new draft until Thursday, 1 August 2002. All comments and suggestions should be sent to <lir-wg(a)ripe.net>. Regards, -- leo vegoda RIPE NCC, Registration Services Assistant Manager

1 0

Mntners with only MAIL-FROM auth
by Andrei Robachevsky 25 Jul '02

25 Jul '02

Attention owners of mntner objects using _only_ MAIL-FROM authentication method. Dear Colleagues, We recently sent out a message to all contacts for maintainers that still used MAIL-FROM as the ONLY means of authentication. This method is no longer valid and no updates can be authorised if any of the maintainers checked are in this situation. The message pointed to the proposed procedure on how to fix such situation (http://www.ripe.net/db/mailfrom.html) The RIPE-DBM support team has been overwhelmed with fax requests to update these maintainers. At the moment we are not able to respond to these requests as quickly as we would like to do. We have found it necessary to give a higher priority to other support requests. Therefore the response time for updates to maintainer authentication may be 5 to 10 working days. Please do not send repeat faxes unless we ask for them and do not send e-mails asking for a status update on the changes. This only slows the whole process down. We will reply to each request as soon as we make the change or find that we need additional information. This message will also be sent to all contacts for maintainers that still use MAIL-FROM as the ONLY means of authentication. Please bear with us on this and we apologise for the delay. Regards, Andrei Robachevsky DB Group Manager RIPE NCC

1 0

Question to a multihomed PA-space connection
by "Thoß, Janko" 25 Jul '02

25 Jul '02

Hello, I have "little" question (but notice that I'm not a guru in BGP-routing and RIPE-problems). We want to connect a customer which don't want to register as a new AS. But he wants a connect to 2 provivers (different AS's). We have tried to get PI-space from RIPE but the automaticly response told us the following: -------- Quote -------- 1. Why is PI space required rather than PA space? - If PI is requested for multi-homing please explain why the second provider cannot route PA space as a more specific route(with the PA block holder adding a more specific route too). - The same policies apply to PI space as PA. Administrative ease and/or routing are not reasons for PI. Please read the information about PA/PI from the RIPE Document, IPv4 Address Allocation and Assignment Policies in the RIPE NCC Service Region, Sections 5.1.5 and 5.1.6: -------- Unquote -------- Can anyone tell me what is to do for that the second provider is able to announce the /24-PA from the first provider (to emulate a multihomed connection) or is it only possible to use the second provider for backup with the same space? wait hopefully for tips or hints regards, Janko Thoß -- envia.tel GmbH Projektmanager Leipziger Str. 116 b 04425 Taucha Tel.: +49 (0) 341 / 120 7069 Fax: +49 (0) 341 / 120 7052 Mobil: +49 (0) 173 / 379 0048 eMail: janko.thoss(a)envia-tel.de Web: http://www.envia-tel.de

2 1

join two objects
by Mohamed Ibrahem 24 Jul '02

24 Jul '02

Dear all I have some objects for the same customer and I want to merge them in one object. Please advise THANX Mohamed Ibrahim Ali Data Communication ENG

1 0

RE: Help Again Please !
by Razavi (Support) 23 Jul '02

23 Jul '02

I know about this site and i have some documents, but the problem is they dont help and dont give enough information, even i have training course booklet but its not clear ! Regards, --Cathy Razavi. -----Original Message----- From: Stephane Bortzmeyer [mailto:bortzmeyer@gitoyen.net] Sent: Thursday, July 18, 2002 5:00 PM To: Razavi (Support) Cc: bortzmeyer(a)gitoyen.net Subject: Re: Help Again Please ! On Mon, Jul 15, 2002 at 03:20:50PM +0430, Razavi (Support) <krazavi(a)dpimail.net> wrote a message of 9 lines which said: > How can i change our Database or how can i have access to our DB ? i want > to change the information about technical person and get a new Nichhandle ! Read RIPE's documentation. www.ripe.net, it is well organized.

2 1

Re: NCC#2002069654 HMQUESTION
by Knowtion Hostmaster Role Account 23 Jul '02

23 Jul '02

> You are correct to say that you can not remove a maintainer from a <aut-num> > object without adding a new one. > > The attribute <mnt-by> in the <aut-num> object is mandatory, the AS number > AS9179 is part of the <as-block> from the RIPE NCC, and if correct the > maintainer <AS9179-MNT> is being maintained by yourselves. How can I phrase this better ? AS9179-MNT (me / my company) is the current but out-of-date maintainer on an object. Without deleting the object (as it is not relly mine) how can I cease being associated with it ? I (AS9179-MNT) no longer am the maintainer of various objects that really belong to the company X in the UK. My company has not been associated with them or provided services to them for sometime. Is it good and recommended practice therefore for me to just delete the objects - this may affect someones service ? cc'ed to lir-wg in case anyone has a better idea... Petr

5 5

Draft document "New Values of the 'status:' attribute for inet6num Objects" is available
by Andrei Robachevsky 23 Jul '02

23 Jul '02

Dear Colleagues, [apologies for duplicate messages] The draft document "New Values of the 'status:' attribute for inet6num Objects" is available on the RIPE NCC website at: http://www.ripe.net/ripencc/draft-documents/ This document describes the new values of the "status:" attribute for inet6num objects and their impact on database operation. The deadline for comments and suggestions is Wednesday, 24th July. After incorporating any suggested changes to the document the final document will be published as a RIPE Document. On Thursday, 25th July, subject to any additional comments, the described Database functionality will be put in to practice. Please send your comments and suggestions to <lir-wg(a)ripe.net>. Regards, Andrei Robachevsky RIPE NCC

2 2

New address announcement
by RIPE NCC Staff 19 Jul '02

19 Jul '02

Dear Colleagues, The RIPE NCC has a new postal address. The new address is: RIPE NCC P.O. Box 10096 1001 EB AMSTERDAM THE NETHERLANDS The new address should be used for all postal contacts. Please update your records to reflect this change. Kind Regards, The RIPE NCC

1 0

Re: [lir-wg] rfc-ignorant.org
by Wilfried Woeber, UniVie/ACOnet 19 Jul '02

19 Jul '02

>Oh, yes, I have no illusions about whether this will actually be a >universal solution to any problem other than as a means to get the >rfc-ignorant.org folks off our collective backs. People unwilling to >provide a usable e-mail address will just fill in a non-usable >(/dev/null'ed?) e-mail address. It's not going to get anybody anywhere, unless we go to the extreme of a 3-way verification as a precondition to holdership of resources registered in the DB, and a recurring verification procedure. If you force a "usable address" you might as well end up with an anon mailer at yahoo, hotmail, gmx,... And if you block those, then nobody prevents me from simply picking an address which is contained in a different, randomly chosen, object. Pretty cheap DoS mechanism, in the end ;-) And last but not least, with the procedures in place for many (most?) ISPs these days, and the channnel-hopping behaviour of users/sites in the domain name space, there is no basis any longer for consistency *and actually getting a human being look at the message*. If rfc-ignorant.org folks don't understand that, then we should suggest a default entry being put in by the DB software (how about postmaster(a)rfc-ignorant.org ?). A maybe more heplful question would be: what do they want to achieve, and is there reasonable merit in those goals to have the community find a sound mechanism for implementation? Wilfried.

1 0

New Document available: RIPE-254
by RIPE NCC Document Announcement Service 19 Jul '02

19 Jul '02

New RIPE Document Announcement -------------------------------------- A new document is available from the RIPE document store. "IRT Object in the RIPE Database" (ripe-254) Short content description ------------------------- This document describes the irt object and related functionality in the RIPE Database. The irt object is used to provide information about a Computer Security Incident Response Team (CSIRT). This document also describes the creation procedure for the irt object. Accessing the RIPE document store --------------------------------- The document is on-line at the following URL: http://www.ripe.net/ripe/docs/irt-object.html The RIPE document store is available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-254.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-254.txt plain text version Kind Regards, RIPE NCC Document Announcement Service

1 0

RE: [lir-wg] rfc-ignorant.org
by Pieterjan d'Hertog 18 Jul '02

18 Jul '02

What about RFC954 dating from 1985... <snip> WHO SHOULD BE IN THE DATABASE DCA requests that each individual with a directory on an ARPANET or MILNET host, who is capable of passing traffic across the DoD Internet, be registered in the NIC WHOIS Database. MILNET TAC users must be registered in the database. To register, send via electronic mail to REGISTRAR(a)SRI-NIC.ARPA your full name, middle initial, U.S. mailing address (including mail stop and full explanation of abbreviations and acronyms), ZIP code, telephone (including Autovon and FTS, if available), and one network mailbox. Contact the DDN Network Information Center, REGISTRAR(a)SRI-NIC.ARPA or (800) 235-3155, for assistance with registration. </snip> Shouldn't it be made obsolete ?

4 4

RE: [lir-wg] rfc-ignorant.org
by Wilfried Woeber, UniVie/ACOnet 18 Jul '02

18 Jul '02

> The IP address block 194.78.245.172/30 has a WHOIS contact, > RD3539-RIPE, which lacks an email address. > wripe -t person % This is the RIPE Whois server. % The objects are in RPSL format. % Please visit http://www.ripe.net/rpsl for more information. person: [mandatory] [single] [lookup key] [ ... ] e-mail: [optional] [multiple] [lookup key] [ ... ] ^^^^^^^^ And if we would make it required (I would not object, btw!) - how about registering the.pope(a)holy.see.vt ;-) When and how would we check the usefulness of the eMail entry? And how to deal with race conditions for new sites/networks? Puzzled. Wilfried.

2 1

Re: [lir-wg] rfc-ignorant.org
by Mally Mclane 18 Jul '02

18 Jul '02

On Thu, 18 Jul 2002, D'HERTOG Pieterjan wrote: > Did someone else receive such emails from rfc-ignorant.org? : You may find apnic's APOPs list and the rfc-ignorant discussion list helpful for background: http://www.apnic.net/mailing-lists/apops/archive/2001/10/msg00008.html http://lists.megacity.org/pipermail/rfci-discuss/2001-October/000054.html Do feel free to make your opinion about them and the service they offer. We personally haven't been contacted by them (afaik), but we often get others threatening to submit us to them. Cheers, Mally

1 0

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

18 Jul '02

>> 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? ;-). > >I am not sure this has anything to do with routing configuration vs >pricing. I agree. >It has to do with application of AS-numbers and who are entiled to >get/have one. > >- kurtis - My point is that any attempt to actively reclaim AS#s is going to *cost money*, both on the NCC's end as well as on the community's end. And as many(?) of the ASs which we are presumably talking about have been distributed _before_ the RIRs have been established, there is probably no (longer) a direct AS#/LIR/RIR (i.e. funding) relationship. And even if, we are talking about *our* (the LIRs') money! That's the reason why I'd like to find out about the expected cost, and even more about any educated guess relating to the number of ASs that can likely be reclaimed. And what a difference that number would make in the context of avoiding the introduction of AS#s with more than 16 bits. I hope I was able this time to get my point across ? Wilfried.

8 9

rfc-ignorant.org
by D'HERTOG Pieterjan 18 Jul '02

18 Jul '02

Did someone else receive such emails from rfc-ignorant.org? : > -----Original Message----- > From: > bounce-ripe+194.78.245.172_ripe_skynet.be(a)beatrice.rutgers.edu > > [mailto:bounce-ripe+194.78.245.172_ripe_skynet.be@beatrice.rut > gers.edu] On Behalf Of > reply-ripe+194.78.245.172_ripe_skynet.be(a)beatrice.rutgers.edu > Sent: donderdag 18 juli 2002 0:18 > To: submit-ipwhois(a)rfc-ignorant.org > Cc: ripe(a)skynet.be; noc(a)skynet.be > Subject: 194.78.245.172/30 > > > > The IP address block 194.78.245.172/30 has a WHOIS contact, > RD3539-RIPE, which lacks an email address. This CIDR block is > therefore subject to listing on the blacklist > ipwhois.rfc-ignorant.org (see http://www.rfc-ignorant.org) > This email is CCd to the following locatable responsible parties: > ripe(a)skynet.be > noc(a)skynet.be > See below for the WHOIS data. > > -Allen > > inetnum: 194.78.245.172 - 194.78.245.175 > netname: SKY-1869366 > descr: Friends Of The Earth > country: BE > admin-c: RD3539-RIPE > tech-c: SN2068-RIPE > rev-srv: ns1.skynet.be > rev-srv: ns2.skynet.be > rev-srv: ns3.skynet.be > rev-srv: ns4.skynet.be > status: ASSIGNED PA > mnt-by: SKYNETBE-MNT > changed: ripe(a)skynet.be 20010806 > source: RIPE > > role: Skynet NOC administrators > address: Belgacom Skynet SA/NV > address: rue colonel Bourg 124 > address: B-1140 Brussels > address: Belgium > phone: +3227061311 > fax-no: +3227269311 > email: ripe(a)skynet.be > admin-c: JFS1-RIPE > tech-c: PDH16-RIPE > nic-hdl: SN2068-RIPE > remarks: ------------------------------------------ > remarks: Abuse notifications to: abuse(a)skynet.be > remarks: Network problems to: noc(a)skynet.be > remarks: Peering requests to: peering(a)skynet.be > remarks: ------------------------------------------ > notify: noc(a)skynet.be > mnt-by: SKYNETBE-MNT > changed: ripe(a)skynet.be 20010907 > source: RIPE > > person: Roger Doiron > address: Friends Of The Earth > address: Rue Blanche 29 > address: 1060 Bruxelles > phone: +32 25420180 > nic-hdl: RD3539-RIPE > remarks: SKYNET-SKYNET-1602730 > notify: noc(a)skynet.be > mnt-by: SKYNETBE-MNT > changed: Ripe(a)skynet.be 20010802 > source: RIPE > > > -- > Allen Smith http://cesario.rutgers.edu/easmith/ > September 11, 2001 A Day That Shall Live In Infamy II > "They that can give up essential liberty to obtain a little > temporary safety deserve neither liberty nor safety." - > Benjamin Franklin > --- Pieterjan d'Hertog, Senior Network Engineer Belgacom Skynet NV/SA, 2 Rue Carli, B-1140 Brussels Phone +3227061311 Fax +3227061150 http://www.skynet.be PGP fingerprint: D9AB CD6A 2A78 73CC 68BF 0AFA 8FB3 5821 E4BB 9D2E

1 0

Anna Skyllberg/Tele2 is out of the office.
by anna.skyllberg＠tele2.se 18 Jul '02

18 Jul '02

I will be out of the office starting 2002-06-21 and will not return until 2002-08-12. I will respond to your message when I return.

1 0

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

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

11 Jul '02

See the inline comment. 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 4:16 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 03:57:49PM -0400, Lu, Ping wrote: > >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. > > What is the reason (or advantage) in using AS numbers from > PUBLIC pool for > confederate ASes, if they are not visible outside of confederation? > Why do you think confederate AS should belong to the same company ? And you can force one of them to use private AS ? > >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). > > Again - what is the reason in using AS numbers from PUBLIC pool for > customer's ASes if this ASes will never appear outside of upstream ISP > network? > Huh ? RIPE NCC always recommends that the end user should use PA address from the upstream ISP so only the less specific CIDR (with ISP's AS number) will appear in the GLOBAL routing table and the more specific prefixes (with end user's AS number) WON'T POLLUTE the GLOBAL routing table.Now in order to show their assigned AS numbers, end user will have to POLLUTE the GLOBAL routing table with their more specific prefixes. > I may imagine only one case - customer's AS peering with public IX. > Yes, IX is another example that AS is originated but not visible in the GLOBAL routing table. > >Technically I don't see how RIPE NCC can possibly find all > the ASes that are > >originated but invisible to the public route server. > > Agree. But there are also administrative possibilites. > > -- > Regards, > Vladimir. >

2 1

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

11 Jul '02

> -----Original Message----- > From: Christopher Sharp [mailto:ripe-lir-wg@chriss.net] > Sent: Wednesday, July 10, 2002 11:32 AM > To: lir-wg(a)ripe.net > Cc: Lu, Ping > Subject: Re: [lir-wg] AS Number Policy > > > On Wed, 10 Jul 2002 11:22:29 -0400, "Lu, Ping" <PLu(a)cw.net> wrote: > > >I don't think to blackholing traffic is a good idea, especially > >when bandwidth means money in today's internet. > > I agree. Neither do I think the community should be paying > to provide the > bandwidth for such a service. > > Encouraging people to filter out these netblocks/ASNs does > make it very hard to > re-allocate them in the short term. However, most people who > maintain good > bogon filters also update them frequently, so hopefully would > remove any such > filters in plenty of time for ASNs to be re-allocated after > 12/24/36 months. > The major ISPs usually update these filters daily and if the tier-1 ISPs all have these filters then smaller ISPs don't have to filter them again. > >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. > > This was my suggestion in a nutshell. I believe the most > commonly observed > bogon list is maintained by Rob Thomas > (http://www.cymru.com/Documents/bogon-list.html) > draft-iana-special-ipv4-03 is > IANA's most comprehensive list of special use netblocks > (http://www.ietf.org/internet-drafts/draft-iana-special-ipv4-03.txt) > Maybe we can have an official filter-set object so people don't have to update these info manually. > >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. > > This sounds excellent but doesn't cover prefixes IANA have > not yet allocated to > an RIR. This is why I would encourage frequent sharing of > this data with the > networking community and especially the maintainers of public > bogon lists on > which many people filter. > In the IANA assigned RIR range, we still need RIRs to tell us what range under their authority are not allocated yet thus should be filtered. > >Blocking is a better idea than blackholing.... > > C. > Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net

3 2

RE: [lir-wg] AS Number Policy
by Hank Nussbacher 10 Jul '02

10 Jul '02

At 11:22 AM 10-07-02 -0400, Lu, Ping wrote: > > -----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. As mentioned earlier by someone, I'd hate to get an ASN or IP block that happened to be in the past inside such a published list. You can bet that somewhere, someplace, sometime, such a filter list will not be updated and will end up blocking someone inadvertantly. -Hank >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

1 0

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

10 Jul '02

>Lets see the following example: > > +-----------+ +-------+ > | AS-UPLINK | | AS-IX | > +---------o-+ +o------+ > | | > +o-----------o+ > | AS-CUSTOMER | > +-------------+ > >[ ... ] > >Should AS-CUSTOMER be considered as multihomed? Definitely, as they'd probably have more then one eBPG session, and probably a different routing policy. I don't see any reason to treat "customer" status (i.e. packets shipped for money) different from "peering" status (i.e. packets shipped for "free"). >-- >Regards, >Vladimir. Wilfried.

3 3

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

10 Jul '02

>1. How long does the community believe it is reasonable to take to > bring an AS 'on-line'? What is the definiton of "on-line" here? Wilfried. _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

6 6

Re: [lir-wg] AS Number Policy
by Hank Nussbacher 10 Jul '02

10 Jul '02

On Tue, 9 Jul 2002, Christopher Sharp wrote: > On Tue, 09 Jul 2002 12:57:46 +0300, Hank Nussbacher <hank(a)att.net.il> wrote: > > >At 11:53 AM 09-07-02 +0200, leo vegoda wrote: > >>1. How long does the community believe it is reasonable to take to > >> bring an AS 'on-line'? > >3 months. > > > >>2. After how many months of not being in use should an AS be > >> returned? > >3 months. > > > >3.After how many months of being single-homed should an AS be returned? > >9-12 months. > > I agree with the time scales for unused ASes and think Hank has raised a very > valid point about those in use.I would be in favour of a 6 month timescale for > return of these 'unless intent can be proven to re-multi-home within 3 months'. > > Producing an easily enforceable policy covering those AS in use may be a little > more complicated.I think most offenders who have become single-homed are > likely to ignore warnings of an approaching return date until it arrives.I > suggest a 6 month period of warning followed by a formal request for return and > a 3 months for them to depreciate use of the AS and return it.The net result > is a 9 month period of return with plenty of warning to depreciate use of a > single-homed AS. > > C. > The problem I foresee will be removing an ASN. RIPE has a policy of not changing mntner objects or overriding them so if the ASN just ignores RIPEs emails and continues to use the ASN - then what? And even if RIPE manages to have a procedure for removing an ASN against the will of the organization it was allocated to, what is to stop the organization to continue to use it? Those that follow NANOG have seen a case of AS5757 which is not listed in any DB and it has been announced for the past 3 years. Hank Nussbacher

5 7

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

10 Jul '02

>Again - what is the reason in using AS numbers from PUBLIC pool for >customer's ASes if this ASes will never appear outside of upstream ISP >network? How do you define "never" in today's or tomorrow's Internet ?! ;-) -w

2 1

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

09 Jul '02

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 ? Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net > -----Original Message----- > From: Wolfgang Tremmel, WT5-RIPE [mailto:wtremmel@vianetworks.com] > Sent: Tuesday, July 09, 2002 1:27 PM > To: Lu, Ping; 'Matthew Robinson'; Vladimir A. Jakovenko > Cc: Wilfried Woeber, UniVie/ACOnet; lir-wg(a)ripe.net > Subject: RE: [lir-wg] AS Number Policy > > > If it is nowhere advertised you could use a privat AS-number... > > Wolfgang > > > > -----Original Message----- > > From: owner-lir-wg(a)ripe.net > [mailto:owner-lir-wg@ripe.net]On Behalf Of > > Lu, Ping > > Sent: Tuesday, July 09, 2002 6:55 PM > > To: 'Matthew Robinson'; Vladimir A. Jakovenko > > Cc: Wilfried Woeber, UniVie/ACOnet; lir-wg(a)ripe.net > > Subject: RE: [lir-wg] AS Number Policy > > > > > > 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 > > > >

2 1

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

09 Jul '02

Beri, I agree with most of your statements, in particular your assessment of the "credibility" of RIS data *) to base such important decisions on - as well as the suggestion to accept a "statement of use" as sufficient. However, doing so leaves me with a cost vs. benefit ratio for the whole exercise! I guess there is a considerably big number of AS#s the RIR/LIR tree does not have authority over (or rather: distribution predating existence of those structures). And, unless we have a _clear consensus_ that going through this exercise can avoid the introduction of AS#s with more than 16 bits _altogether_ (or at least extends the lifetime of the 16bit version *considerably*), the whole issue might be mute... Wilfried. *) this is not questioning the usefulness or utility of RIS data, but it seems to be the wrong tool for obtaining a reliable reading for this context. And I guess it's pretty easy to fake... ______________________________________________________________________ Date: Tue, 9 Jul 2002 15:33:53 +0200 (CEST) From: Berislav Todorovic <beri(a)kpnqwest.net> To: leo vegoda <leo(a)ripe.net> CC: lir-wg(a)ripe.net Subject: Re: [lir-wg] AS Number Policy On Tue, 9 Jul 2002, leo vegoda wrote: >> We would be grateful if the community would clarify the policy so >> that it is clear when an unused AS number should be returned to >> the pool. Let's try to summarize things a bit: this issue is not only about numbers and timescale. A complete AS number revokation policy must comprise of 4 components: * Audit policy on AS number usage. * Clear definition of policy violation. * Revoking AS numbers from customers violating AS number usage policies. * Reusing revoked AS numbers. RIPE NCC reserves the right to perform periodic audits on AS number usage and take appropriate actions if necessary, to enforce compliance with ripe-245 and RFC 1930. RIPE NCC will use RIS to check if an AS number is used with compliance with those documents. RIPE NCC must never consider RIS as the ultimate source and must always raise an audit ticket towards the LIR and/or an end customer of an AS before taking any further action. A possible violation of the policy happens if an AS number: (1) Does not appear in the routing table at all: (a) Assigned, but never appeared (startup case) within S months. (b) Missing completely for more than D months. (2) Appears in the routing table via a single AS path for more than M months. While we can discuss on the values of S, D and M special care must be taken on revokation and reusal policy. For (1a) - there seems to be a consensus that S would be 3 months. For (1b) - just to be on the safe side D should be at least 6 months. For (2) - also to be on the safe side M should be at least 12 months. If a violation if found, RIPE NCC reserves the right to notify the LIR that requested the AS number about violation and ask them to provide additional evidence that the AS number is still in valid use. A clear statement from the LIR that the AS number is still used in compliance with the policy MUST be enough to close the audit ticket. No further action should be taken in that case. If there is no response from the LIR, RIPE NCC should contact the admin-c and tech-c specified in the aut-num object. In a lot of cases an AS number is issued by a LIR that doesn't have anything to do with the customer any more. If no response counting from notification date is received from the end customer: * In the case (1a) - within 3 months, * In the case (1b) - within 6 months, * In the case (2) - within 12 months the AS number may be revoked by RIPE NCC. AS number reusage policy - a revoked AS number may be reused after certain period of time, defined as: * In the case (1a) - 3 months after it is revoked from the end customer. * In the case (1b) - same time period that elapsed between revokation date and initial assignment date of the AS number. That should give enough time to all people to cleanup their configurations, policies etc. * In the case (2) - same as (1b). Regards, Beri --------------------------------------------------------------------------------

1 0

AS Number Policy
by leo vegoda 09 Jul '02

09 Jul '02

Dear Colleagues, Within the RIPE community the AS policy (ripe-245) is based upon RFC 1930. The RIPE policy states that "a network [is required] to be multihomed for an AS number to be assigned". However, there is no clear policy on returning unused AS numbers to the pool. We would be grateful if the community would clarify the policy so that it is clear when an unused AS number should be returned to the pool. Specific questions we would like to ask are: 1. How long does the community believe it is reasonable to take to bring an AS 'on-line'? 2. After how many months of not being in use should an AS be returned? Due to a lack of time in the LIR Working Group session at RIPE 42 (May 2002) we were not able to discuss the community's policy for AS numbers. We would like to raise the issue now so that there is ample time for a discussion before RIPE 43, on Rhodes, in September. We welcome the community's input on this policy matter. Kind regards, -- leo vegoda RIPE NCC, Registration Services Assistant Manager

7 7

RE: [lir-wg] Discussion Summary: Status field for inet6num object s
by Guy Davies 08 Jul '02

08 Jul '02

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I would prefer RIR-LIR-ALLOCATED, LIR-SUB-ALLOCATED and LIR-USER-ASSIGNED (or similar) if we must keep ALLOCATED and ASSIGNED in the descriptions. I don't think that it is immediately clear from the proposals below whether LIR-ALLOCATED is allocated by an LIR or to an LIR. Regards, Guy > -----Original Message----- > From: Gert Doering [mailto:gert@space.net] > Sent: Monday, July 08, 2002 1:42 PM > To: leo vegoda > Cc: ipv6-wg(a)ripe.net; lir-wg(a)ripe.net; db-wg(a)ripe.net; > sig-db(a)apnic.net; > policy-db(a)apnic.net; apnic-talk(a)apnic.net > Subject: Re: [lir-wg] Discussion Summary: Status field for inet6num > objects > > > Hi, > > On Mon, Jul 01, 2002 at 06:21:24PM +0200, leo vegoda wrote: > > The RIPE NCC needs to implement a new status attribute for the > > inet6num object to reflect the new policy agreed by the RIPE, > > ARIN and APNIC communities. > > > > The RIPE NCC suggested the following new status attributes for > > the inet6num objects: > > > > - RIR-ALLOCATED > > (For allocations made by an RIR to an LIR) > > > > - LIR-ALLOCATED > > (For allocations made by an LIR or an LIR's downstream > > customer > > to another downstream organisation) > > > > - ASSIGNED > > (For assignments made to End User sites) > > I haven't seen any replies to this so far. > > I want to express that I like this proposal. It doesn't introduce > any new and yet-undefined terms, but makes clear what the status of > a given network is. > > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations: > 45809 (45931) > > SpaceNet AG Mail: netmaster(a)Space.Net > Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 > 80807 Muenchen Fax : +49-89-32356-299 > -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.1 iQA/AwUBPSmLLo3dwu/Ss2PCEQIJdQCeOKDqqTLKCuB+o3pWMj/XJ41QJMQAnROW EWRBiRI4rPpF9DRbhrxYcK0S =Rab7 -----END PGP SIGNATURE----- This e-mail is private and may be confidential and is for the intended recipient only. If misdirected, please notify us by telephone and confirm that it has been deleted from your system and any copies destroyed. If you are not the intended recipient you are strictly prohibited from using, printing, copying, distributing or disseminating this e-mail or any information contained in it. We use reasonable endeavors to virus scan all e-mails leaving the Company but no warranty is given that this e-mail and any attachments are virus free. You should undertake your own virus checking. The right to monitor e-mail communications through our network is reserved by us.

2 1

Status field for inet6num objects
by Joao Luis Silva Damas 08 Jul '02

08 Jul '02

[** Mail posted to both APNIC and RIPE lists in the hopes of trying to find a solution suitable for all users of RIPE or RIPE-derived software **] Dear all, the inet6num, like the inetnum object, has a field named "status" which stores some information about the nature or position of a block of addresses in the delegation chain, from the RIR through to the end user. Currently, the status field for inet6num object is generated by the Database software based on the size of the address block and its possible values are: o TLA o SubTLA o NLA o SLA This notation has been deprecated and it is time to adapt the database. Discussions on this matter have identified the usefulness of having the capability to distinguish between allocations made by the RIR, allocations made by an LIR or their customers and assignments to end users. As such, we propose to modify the "status" attribute of the inet6num object to be: a) not-generated. This means users must assign a value to the status attribute when creating the object, just as in the inetnum object b) have the following possible values: RIR-allocated LIR-allocated Assigned to be used according to the following set of rules: The RIR-allocated status can only be used in objects representing allocations created directly by the RIR. The LIR-allocated status can be used by LIRs and their customers to represent blocks of addresses that are not assigned to specific end users. There can be several levels of objects with this status. The Assigned status must be used in objects representing assignments to end users (households, companies, enterprises, etc) We hope that with this modification the information in the Database will more accurately describe the registration of IPv6 address space. A possible transition to the new values could be: 1) RIRs modify status fields for allocations 2) Any new objects and modifications to existing ones must have a value for the status field corresponding to the ones described above. Otherwise the update will fail. 3) RIRs contact LIRs to have the status of assignments and sub-allocations updated. Best regards, Joao Damas RIPE NCC

6 8

New Document available: RIPE-244
by RIPE NCC Document Announcement Service 05 Jul '02

05 Jul '02

New RIPE Document Announcement -------------------------------------- A new document is available from the RIPE document store. Ref: ripe-244 Title: Policy for Reverse Address Delegation under in-addr.arpa in the RIPE NCC Service Region Author: Joao Luis Silva Damas, Leo Vegoda Date: 4 July 2002 Format: PS=13515 TXT=4723 Obsoletes: Obsoleted by: Updates: Updated by: Short content description ------------------------- This document describes the policy for reverse delegation of IPv4 assignments and allocations in the RIPE NCC service region. Accessing the RIPE document store --------------------------------- You can access the "Policy for Reverse Address Delegation under in-addr.arpa in the RIPE NCC Service Region" in HTML format at the following URL: http://www.ripe.net/ripe/docs/rev-del.html The RIPE document store is also available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-244.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-244.txt plain text version

2 1

New IPv6 policy implemented on 1 July 2002
by Paul Rendek 01 Jul '02

01 Jul '02

Dear Colleagues, The RIPE NCC is pleased to announce the implementation of the new IPv6 policy effective 1 July 2002. This IPv6 policy was accepted by consensus at RIPE 42 and is common to all Regional Internet Registry communities - APNIC, ARIN, and the RIPE NCC. The new policy replaces the provisional IPv6 policy launched in 1999. The IPv6 Policy documentation is available from the RIPE document store at: http://www.ripe.net/ripe/docs/internet-registries.html The current set of IPv6 documents are: - IPv6 Address Allocation and Assignment Policy - Initial IPv6 Allocation Request Form in the RIPE NCC Service Region - Supporting Notes for the Initial IPv6 Allocation Request Form in the RIPE NCC Service Region - IPv6 End User Site Assignment Request Form in the RIPE NCC Service Region - Supporting Notes for the IPv6 End User Site Assignment Request Form in the RIPE NCC Service Region Key points of the new IPv6 policy you should be aware of: - The minimum allocation size is /32; - LIRs currently holding a /35 have the option of expanding their allocation to a /32 on request; - In 2002, no additional fees are charged for IPv6 address space in the RIPE NCC service region. The RIPE NCC IPv6 web pages can be found at: http://www.ripe.net/IPv6/ Regards, Paul Rendek Communications Manager RIPE NCC

2 1