November 2001 - lir-wg - mailman.ripe.net

RIPE-41 announcement
by RIPE NCC Meeting Registration 20 Nov '01

20 Nov '01

Dear Colleagues, It is our pleasure to open registration for the RIPE 41 meeting, to be held from 14th January - 18th January 2002 at hotel Krasnapolsky in Amsterdam, The Netherlands. More information about this meeting and accommodations can be found on this page: http://www.ripe.net/ripe/meetings/current/ripe-41/ Online registration will open on Monday 19th November 2001 and close on Friday 4th January 2002. On-site registration will open on Monday 14th January 2002. Please note the following: To avoid waiting queues at the registration desk on-site we encourage pre-payment by credit card. The registration fee for this meeting is EUR 350.00 (this includes refreshments and lunches) and the dinner fee is EUR 65.00. However, if payment is received before 4 January 2002, the pre-payment cut-off date, you will receive a pre-registration discount of EUR 50.00. Therefore, the fee for attendees paying before the cut-off date is EUR 300.00 for the meeting and 65.00 EUR for the RIPE dinner event. Confirmation of Registration: For your convenience you can register using our secure website at: https://www.ripe.net/cgi-bin/mtgreg (encrypted form) http://www.ripe.net/cgi-bin/mtgreg (non-encrypted form) If you still prefer not to send your credit card number using an encrypted transfer method, we have prepared a fax form. This form is attached to the acknowledgment of your registration. You will receive a second acknowledgment by e-mail as soon your payment has been processed. In addition, you will find the receipt for your payment in your conference envelope. Participants requiring a visa to enter The Netherlands are advised to begin the required procedures as soon as possible. The RIPE Meeting organizers are pleased to provide letters of invitation to those attendees requiring them. Should you have any further questions, please do not hesitate to contact us at <meeting(a)ripe.net>. Dear Colleagues, It is our pleasure to open registration for the RIPE 41 meeting, to be held from 14th January - 18th January 2002 at hotel Krasnapolsky in Amsterdam, The Netherlands. More information about this meeting and accommodations can be found on this page: http://www.ripe.net/ripe/meetings/current/ripe-41/ Online registration will open on Monday 19th November 2001 and close on Friday 4th January 2002. On-site registration will open on Monday 14th January 2002. Please note the following: To avoid waiting queues at the registration desk on-site we encourage pre-payment by credit card. The registration fee for this meeting is EUR 350.00 (this includes refreshments and lunches) and the dinner fee is EUR 65.00. However, if payment is received before 4 January 2002, the pre-payment cut-off date, you will receive a pre-registration discount of EUR 50.00. Therefore, the fee for attendees paying before the cut-off date is EUR 300.00 for the meeting and 65.00 EUR for the RIPE dinner event. Confirmation of Registration: For your convenience you can register using our secure website at: https://www.ripe.net/cgi-bin/mtgreg (encrypted form) http://www.ripe.net/cgi-bin/mtgreg (non-encrypted form) If you still prefer not to send your credit card number using an encrypted transfer method, we have prepared a fax form. This form is attached to the acknowledgment of your registration. You will receive a second acknowledgment by e-mail as soon your payment has been processed. In addition, you will find the receipt for your payment in your conference envelope. Participants requiring a visa to enter The Netherlands are advised to begin the required procedures as soon as possible. The RIPE Meeting organizers are pleased to provide letters of invitation to those attendees requiring them. Should you have any further questions, please do not hesitate to contact us at <meeting(a)ripe.net>. Kind regards, Asha Raghoebarsing RIPE Meeting Co-ordinator <meeting(a)ripe.net>

1 0

Question about more specific route.
by Przemyslaw Mujta 18 Nov '01

18 Nov '01

hello, I have question - what is about announcing PA assignment /24 from example AS1 to AS2 where AS2 maintain PA allocation /16 ? Should I always ask AS2 maintainer whitch give me PA assignmet about aprove announcing my assignment to other AS ? Maybe some RIPE documents describe with details case about announce from AS prefix like more specific route whitch are assignment example from other ISP. best regards, -- Przemyslaw Mujta PM452-RIPE master network administrator +48 22 8606707 Crowley Data Poland

2 1

New/Revised Document available: "Guidelines for Setting up a Local Internet Registry at the RIPE NCC"
by RIPE NCC Document Announcement Service 15 Nov '01

15 Nov '01

New/Revised RIPE Document Announcement -------------------------------------- A new/revised document is available from the RIPE document store: "Guidelines for Setting up a Local Internet Registry at the RIPE NCC" (ripe-230) Short content description ------------------------- The "Guidelines for Setting up a Local Internet Registry at the RIPE NCC" aims to provide the necessary information for those who are considering setting up a Local Internet Registry (LIR) with the RIPE NCC. In this document, some initial guidelines are given on which organisations usually set up an LIR. Further, the steps necessary to set up an LIR are described. Finally, the RIPE NCC IP address allocation and assignment policies are discussed. Accessing the RIPE document store --------------------------------- 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-230.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-230.txt plain text version You can also access the RIPE documents in HTML format via WWW. RIPE-230 is available from the WWW at the following URL: http://www.ripe.net/docs/new-lir.html

2 1

FreeIPdb Released
by David R Huberman 13 Nov '01

13 Nov '01

Hello, As promised, Global Crossing API is pleased to announce the release of FreeIPdb Version 1.0 at: http://www.freeipdb.org FreeIPdb is an open-source suite of tools allowing you to manage your IPv4 and IPv6 address space and address space assignments in the most efficient manner possible. Future versions will incorporate RWHOIS, SWIP, and inetnum capabilities. Enjoy the tools and please subscribe to the mailing lists for support and to provide us feedback. /david *--------------------------------* | Global Crossing API | | Manager, Global IP Addressing | | (703) 627-5800 | | huberman(a)gblx.net | *--------------------------------*

1 0

Re: RIPE-227?
by Sabrina Waschke 13 Nov '01

13 Nov '01

Hank, The robot has now been fixed and recognizes all templates when using the correct titles including the '#'. Please do *NOT* remove the template titles as presented on the request form(s). The robot will not recognize the form and set it to a lower priority. As I said in my previous message the robot gave a warning (not an error) for the templates #[ANNOUNCED ADDRESS RANGES]# and #[PEERING CONTACTS]# and the requests were immediately forwarded to a hostmaster for processing. Requests containing errors should be corrected and resent, the keyword NOAUTO can be used to bypass the robot. Kind regards, Sabrina Waschke -- o------------------------------------------o | Sabrina Waschke sabrina(a)ripe.net | | Registration Services Operations Manager | | | | RIPE NCC tel +31 20 535 4444 | | www.ripe.net fax +31 20 535 4445 | o------------------------------------------o Hank Nussbacher <hank(a)att.net.il> writes: * At 17:37 09/11/01 +0100, Sabrina Waschke wrote: * * >The robot doesn't recognize these two templates yet. This will be fixed. * >Thanks for reporting it, Hank. * * So I stripped off the template tags and resubmitted and got back: * * >PLEASE NOTE: * >This ticket has *NOT* been identified as a request for IP * >addresses or AS numbers. * >We will handle this message with lower priority than a request for IP * >addresses / AS numbers. If your mail in fact is a request for IP * >addresses / AS numbers, there are most likely missing / incorrect * >fields in your mail. Please make sure to correct and complete your * >request so that we can give it appropriate priority. * * So if I submit with ASN template tags, your robot flags it as an error and * returns it. If I strip off the ASN tags then it gets sent to a lower * priority queue. What is the magic sequence that will allow my ASN request * to enter a normal queue? * * -Hank * * * * * >FYI: * >The RIPE NCC Database and Software Department are working on a whois * >library which will be able to parse and validate whois objects of any * >type - that will include multi-line fields, and strictly adhere to the * >internal format of the objects in the whois DB. * > * >Kind regards, * > * >Sabrina Waschke * > * >-- * > * >o------------------------------------------o * >| Sabrina Waschke sabrina(a)ripe.net | * >| Registration Services Operations Manager | * >| | * >| RIPE NCC tel +31 20 535 4444 | * >| www.ripe.net fax +31 20 535 4445 | * >o------------------------------------------o * > * > Hank Nussbacher <hank(a)att.net.il> writes: * > * Does anyone know if the RIPE robot supports RIPE-227 templates? This * > * fairly new template (Oct 2, 2001) for ASN requests. The robot saw it * > * as of the 'RIPE147' type and then proceeded to flag as warnings: * > * * > * >-ANNOUNCED ADDRESS RANGES- * > * > * > * > * > * >Warning #1 * > * > * > * >Template was not recognised and *not* processed. Please * > * >check your spelling! * > * > * > * > * > * >-PEERING CONTACTS- * > * > * > * > * > * >Warning #2 * > * > * > * >Template was not recognised and *not* processed. Please * > * >check your spelling! * > * * > * So either the template as listed in RIPE-227 is wrong or the robot is * > broken * > * . * > * * > * Thanks, * > * Hank * > * * > * *

1 0

Re: RIPE-227?
by Sabrina Waschke 12 Nov '01

12 Nov '01

The robot doesn't recognize these two templates yet. This will be fixed. Thanks for reporting it, Hank. FYI: The RIPE NCC Database and Software Department are working on a whois library which will be able to parse and validate whois objects of any type - that will include multi-line fields, and strictly adhere to the internal format of the objects in the whois DB. Kind regards, Sabrina Waschke -- o------------------------------------------o | Sabrina Waschke sabrina(a)ripe.net | | Registration Services Operations Manager | | | | RIPE NCC tel +31 20 535 4444 | | www.ripe.net fax +31 20 535 4445 | o------------------------------------------o Hank Nussbacher <hank(a)att.net.il> writes: * Does anyone know if the RIPE robot supports RIPE-227 templates? This * fairly new template (Oct 2, 2001) for ASN requests. The robot saw it * as of the 'RIPE147' type and then proceeded to flag as warnings: * * >-ANNOUNCED ADDRESS RANGES- * > * > * >Warning #1 * > * >Template was not recognised and *not* processed. Please * >check your spelling! * > * > * >-PEERING CONTACTS- * > * > * >Warning #2 * > * >Template was not recognised and *not* processed. Please * >check your spelling! * * So either the template as listed in RIPE-227 is wrong or the robot is broken * . * * Thanks, * Hank * *

2 3

RIPE-227?
by Hank Nussbacher 09 Nov '01

09 Nov '01

Does anyone know if the RIPE robot supports RIPE-227 templates? This fairly new template (Oct 2, 2001) for ASN requests. The robot saw it as of the 'RIPE147' type and then proceeded to flag as warnings: >-ANNOUNCED ADDRESS RANGES- > > >Warning #1 > >Template was not recognised and *not* processed. Please >check your spelling! > > >-PEERING CONTACTS- > > >Warning #2 > >Template was not recognised and *not* processed. Please >check your spelling! So either the template as listed in RIPE-227 is wrong or the robot is broken. Thanks, Hank

1 0

RE: FW: more specific routes in today reality
by Koepp, Karsten 08 Nov '01

08 Nov '01

Hi Gert, > -----Original Message----- > From: Gert Doering [mailto:gert@space.net] > Sent: Wednesday, November 07, 2001 5:18 PM > To: Koepp, Karsten > Cc: 'Vladimir A. Jakovenko'; 'lir-wg(a)ripe.net' > Subject: Re: FW: more specific routes in today reality > > > Hi, > > On Wed, Nov 07, 2001 at 03:48:20PM +0100, Koepp, Karsten wrote: > > All I am saying is, regardless of whether we want this type > of multi-homing > > or not, networks originating from different AS should use > PI space. It does > > neither save a route nor address space to make pieces of a PA block > > multi-homed. It only binds the network to the provider > assigning the PAs. > > That's why I was up-set. > > Whether or not an announcement is PI or PA has no influence > on the number > of routes visible in the global table. What I said before. > Using a sub-block from PA space has two advantages: > > - more flexible in block size (what if the customer comes back later > and needs twice the space?) Means the customer has to renumber to a bigger network. Can be done. > - more robust concerning filtering / dampening (the ISPs PA > space will > most likely be still visible, even if the sub-network is filtered > somewhere) I admit this is an advantage. > - if the customer goes away, the network can be given back and the > route will disappear -> good for conservation *and* aggregation. I don't follow that this will decrease routes. > The only benefit of PI is "you can keep your network if you > change ISPs", > which is convenient for the end customer but very expensive > on the global > routing system. > > This is why people actually ask for "stop handing out PI at > all" (which > I am *not* advocating here, but think about it). > > - and due to this pros and cons, which most people agree > upon, the RIPE recommendations make sense. Gert, after all you are convincing. This means in turn, it would be conform to the rules to multi-home PA addresses and it just depends on the service providers co-operating to create the route objects. Is this really current practice? Where or when is this gonna be reflected in RIPE docs? Karsten Total number of questions concerning RIPE policies: 73128 > > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations: 73128 > > SpaceNet AG Mail: netmaster(a)Space.Net > Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 > 80807 Muenchen Fax : +49-89-32356-299 >

2 1

Re: FW: more specific routes in today reality
by Sabrina Waschke 08 Nov '01

08 Nov '01

The role of the RIPE NCC in this matter is to simply point out the different options, so that network operators can take them into account when requesting address space. It is the ISPs that decide what gets routed. The RIPE NCC has no influence on this. We will continue to assign PI address space unless the RIPE community revises this policy. However, if there are clear recommendations from the community, the RIPE NCC will certainly make these recommendations known to its members. Kind regards, Sabrina Waschke -- o------------------------------------------o | Sabrina Waschke sabrina(a)ripe.net | | Registration Services Operations Manager | | | | RIPE NCC tel +31 20 535 4444 | | www.ripe.net fax +31 20 535 4445 | o------------------------------------------o "Koepp, Karsten" <Karsten.Koepp(a)lambdanet.net> writes: * Nurani, * * I was missing a RIPE NCC hostmaster statement to this e-mail. * Sascha quoted a hostmaster. * * > -----Original Message----- * > From: Sascha E. Pollok [mailto:sp@iphh.net] * > Sent: Tuesday, October 09, 2001 12:33 PM * > To: Gert Doering; Vladimir A. Jakovenko * > Cc: lir-wg(a)ripe.net; routing-wg(a)ripe.net * > Subject: Re: more specific routes in today reality * * <SNIP> * > * > "- 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)." * > * > This was suggested from a RIPE NCC Hostmaster when sending a * > PI-space req. This looks a little contrary to your opinion doesn't * > it? * > * > Sascha * > * * Has this been a mistake, or is this the default answer to PI requests * sent to the NCC nowadays? Is the NCC seriously going to recommend this * to the members? * I don't recommend the use of PI to customers either, and I don't want * to roll up the multi-homing discussion. But PI should remain provider- * independent and PA should remain provider-aggregatable. * * Regards Karsten * * Sorry for the late posting in this thread... *

1 0

RE: FW: more specific routes in today reality
by Koepp, Karsten 07 Nov '01

07 Nov '01

Vladimir, > -----Original Message----- > From: Vladimir A. Jakovenko [mailto:vovik@lucky.net] > Sent: Wednesday, November 07, 2001 2:34 PM > To: Koepp, Karsten > Cc: 'nurani(a)ripe.net'; 'lir-wg(a)ripe.net' > Subject: Re: FW: more specific routes in today reality > > > On Wed, Nov 07, 2001 at 01:55:01PM +0100, Koepp, Karsten wrote: > >Nurani, > > > >I was missing a RIPE NCC hostmaster statement to this e-mail. > >Sascha quoted a hostmaster. > [..skipped..] > ><SNIP> > >> > >> "- 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)." > >> > >> This was suggested from a RIPE NCC Hostmaster when sending a > >> PI-space req. This looks a little contrary to your opinion doesn't > >> it? > >> > >> Sascha > >> > > > >Has this been a mistake, or is this the default answer to PI requests > >sent to the NCC nowadays? Is the NCC seriously going to > recommend this > >to the members? > >I don't recommend the use of PI to customers either, and I don't want > >to roll up the multi-homing discussion. But PI should remain > provider- > >independent and PA should remain provider-aggregatable. > > Quote from RFC1930, "Guidelines for creation, selection, and > registration > of an Autonomous System (AS)", page 7: > > "With the introduction of aggregation it should be noted that > a prefix may > be represented as residing in more than one AS, however, this > is very much > the exception rather than the rule". > RFC1930 does not know PA or PI address categories, just routes. > Quote from RFC2725, "Routing Policy System Security", page 9: > > "Route objects may exist for the same prefix with multiple > origin AS values > due to common multihoming practice that does not require a > unique origin AS". RFC2725 does mention PI, but not the case where PA addresses are being multi-homed. All I am saying is, regardless of whether we want this type of multi-homing or not, networks originating from different AS should use PI space. It does neither save a route nor address space to make pieces of a PA block multi-homed. It only binds the network to the provider assigning the PAs. That's why I was up-set. Still waiting for the NCC to answer... Karsten

2 1