February 2003 - lir-wg - mailman.ripe.net

IXP networks routing
by Kurt Kayser 11 Mar '03

11 Mar '03

Hi, as an IXP-Operator I would like to comment this in three ways: 1. Requesting an Address-space be it v4 or v6 for an IXP-Infrastructure and not making it globally reachable somehow misses the point. It should be clearly reachable - ideally through *all* connected peers of the infrastructure. (they certainly can decide on the security for these destinations) 2. Address-space differs from IXP to ISP substiantially. ISPs hand out IP-addresses to customers and IXPs assign single (or *very* few) addresses to ISPs. That means that address consumption and renewals are very rare. Even the default allocations from the IRRs for IXPs is - to my opinion - far too large. 3. Same with the members fee. Ok, I am speaking for a small IXP, but a RIPE membership cannot be afforded right now. There is in contradiction the need for 1 single AS-number and one small prefix the cost which is normally calculated for the untrained new LIR ISP, who needs training, hostmaster-help, etc. Why not add a special categoy for IXP demands. There is a small number of them (50 in Europe?) and basicall NO effort after giving them their numbers for work. Best regards, Kurt Kayser Lars Erik Gullerud wrote: > On Tue, 2003-02-25 at 16:20, Stephane Bortzmeyer wrote: > >>On Tue, Feb 25, 2003 at 04:11:57PM +0100, >> Petr Baudis <pasky(a)pasky.ji.cz> wrote >> a message of 29 lines which said: >> >> >>>AFAIK they should not be globally routable and they are only for internal usage >>>of the exchange points. >> >>Very bad idea. >> >>1) When you traceroute through an exchange point, the IP addresses you >>get should be routable, for easier debugging. >> >>2) Path MTU discovery may depend on it. >> >>Having IXP addresses not globally routable is as wrong as having RFC >>1918 (or FECO::) addresses at an IXP. > > > No, very GOOD idea. > > We block all inbound route announcements of IXP prefixes we are > connected to on IPv4 for a very good reason, and I don't see what has > changed from IPv4 to IPv6 that should make our routing policy any > different for IPv6 IXP-space. > > Hint - a lot of networks don't use "next-hop-self" on their border > routers toward iBGP peers and instead carry a route for the IXP block in > their IGP so other BGP speakers have next-hop reachability. Some > networks, unfortunately, also do NOT make sure to filter said IXP blocks > properly. What do you think happens when suddenly a route for that IXP > block leaks in on some peering session (on a different router than the > one actually connected to the IXP of course), and eBGP has a lower > administrative distance (preference) than the IGP - which is usually the > default? Can you guess what happens to the traffic that should be going > to a next-hop from that IXP-block? Yes, I've seen this very effect on > several networks I've had the joy of troubleshooting, and could share > some interesting stories on that topic. > > As for your specific objections: > > 1) Why does this make for easier debugging? You get a perfectly valid > ICMP reply from a valid IP address that you should be able to resolve in > DNS without any problems as it is unique (global unicast). If you mean > you would like to use the actual IXP IP-address as a destination for a > traceroute, well - don't. You shouldn't need to anyway. And unless you > are one of the peers I am speaking to over said IXP, you have no valid > reason in my book to send any traffic to my border-router on that > IP-address, and I don't see why I should let you. Hey, services like > echo and chargen were once considered very useful debugging tools too - > that doesn't mean anyone would recommend having said services open to > the world nowadays. > > 2) How would lack of routability of this space break path MTU discovery? > Please show me where in RFC1191 or RFC1981 it says that you would need > to send any packets addressed directly to the IP who sent you a > "Datagram Too Big/Packet Too Big" ICMP message in either IPv4 or IPv6, > respectively, for pMTUd to work. > > /leg > > > -- +++ Kurt Kayser Consulting - ISP & Carrier Netzwerkdesign, Planung, Schulungen *** Heinrich-Müller-Str. 1c, 90530 Röthenbach b.St. Wolfgang, Germany *** Tel: +49 (0) 9129 289315, Fax: +49 (0) 9129 289316, Mobil: +49 (0) 160 5810284

18 74

Re: [lir-wg] Assignment Procedures for multi-homed customers
by Kristofer Sigurdsson 26 Feb '03

26 Feb '03

Hi, Wilson Mehringer, Wed, Feb 26, 2003 at 03:09:03PM +0100 : > > Hi Kristofer, > > I thought that a customer can NOT get an AS# from Ripe without first becoming a LIR!! > Vise versa, he/she can become a LIR without necessarily getting an AS#. > Am I missing out on something?? Only LIRs can request an AS, but they can request one for someone else. The only requirements for a new AS is that a) they have some address space to announce and b) they can specify a minimum of two existing AS's that the new one will peer with. Here's a quote from "Autonomous System (AS) Number Assignment Policies and Procedures" (http://www.ripe.net/ripe/docs/asn-assignment.html): "The RIPE NCC assigns AS Numbers for Autonomous Systems located in the RIPE NCC service region and only accepts requests for AS Numbers from LIRs. LIRs may request AS Numbers on behalf of other organisations. ". You're right about the latter part, though. A LIR does not have to have an AS. It is quite common for LIRs to have their own AS, but by no means necessery. An AS is simply a technical requirement to be able to peer with other entities, in order to exchange dynamic routing tables. On the other hand, being a LIR is a far bigger thing, a Local Internet Registry. LIR's are typically providers who can request allocations from RIPE and then furthermore assign IP numbers to their customers, and well...be an Internet Registry. :-) -- Kristófer Sigurðsson Nethönnun ehf.

1 0

Re: [lir-wg] Assignment Procedures for multi-homed customers
by Wilson Mehringer 26 Feb '03

26 Feb '03

Hi Kristofer, I thought that a customer can NOT get an AS# from Ripe without first becoming a LIR!! Vise versa, he/she can become a LIR without necessarily getting an AS#. Am I missing out on something?? Wilson >>> Kristofer Sigurdsson <kristofer(a)nh.is> 02/26/03 02:15pm >>> Hi, Gernot Schwalm, Wed, Feb 26, 2003 at 01:52:25PM +0100 : > Hi, > > we have a customer who wants to be multihomed in the near future and > therefore needs/wants his own AS. Will he get his own PA-Allocation then or > do we have to request PI-Space for him? There is nothing unusual about announcing PA address space, even if it's not yours (as long as the LIR in question permits it), so your customer should simply go ahead and request for an AS (well, only LIR's can request an AS, but there is nothing wrong with a LIR requesting one for a customer). The LIR would then make the assignment origin in the customer's AS. However, you might want to make your customer sign a legal contract to clearify this point, i.e. that the address space belongs to the LIR, not the customer, in case they want to switch to another upstream provider. -- Kristófer Sigurðsson Nethönnun ehf.

3 2

Assignment Procedures for multi-homed customers
by Gernot Schwalm 26 Feb '03

26 Feb '03

Hi, we have a customer who wants to be multihomed in the near future and therefore needs/wants his own AS. Will he get his own PA-Allocation then or do we have to request PI-Space for him? Thanks in advance, Gernot Schwalm -- noris network AG / Kilianstrasse 142 \ 90425 Nuernberg Tel. 0911-9352-0 / Fax 0911-9352-100 \ info(a)noris.net ~

2 1

RIPE 44 Meeting Report
by Nick Hyrka 19 Feb '03

19 Feb '03

(Apologies for any duplicate mails.) Dear Colleagues: The RIPE 44 Meeting was held recently at the Krasnapolsky Hotel from 27 - 31 January 2003 in Amsterdam. There were a total of 360 attendees comprised of the RIPE NCC membership, the RIPE community and government representatives. Attendees also included representatives from APNIC, ARIN, LACNIC, and ICANN. Members from the U.K. had the highest number of representatives (53), followed by Germany (50), the Netherlands (37) and the U.S.A (42). Additionally, there were more representatives from Eastern European countries than ever before. Highlights of RIPE 44 included the open discussion during the Plenary on the RIPE NCC 2002 membership survey results, the first report by LACNIC after being granted official RIR status, and the first webcasting trial of the RIPE 44 sessions held in the Grand Ballroom. Version 1.0 of the RIPE NCC LIR Portal was also showcased at RIPE 44. Portal features and benefits were noted at a presentation given at the LIR and Tools Working Groups sessions. The RIPE NCC would like to thank SURFnet, Afilias, NIKHEF, KPN EuroRings, and AMSIX for the support they provided to the meeting. A summary of the RIPE 44 highlights follows: LIR === * Denesh Bhabuta (Aexiomus Limited) stepped down as co-chair of the LIR Working Group. Gert Döring (SpaceNet) and Andrea Borgato (I.Net S.p.A.) were selected as new co-chairs. * A search for a new name for the LIR Working Group was started. Rob Blokzijl (RIPE Chair) will publish a proposal for a new name. * The LIR Working Group Chairs will draft a new charter for the working group. * The sub-allocation policy document was approved. No changes were made. * A task force and mailing list was formed to investigate changes to the PI policy. * The RIPE NCC was tasked to publish a draft document on status values in inetnum objects. DATABASE ========= * IPv6 support for querying the Whois Database has been implemented. * References by name have been cleaned from the database and an organisation: object was proposed. * The RIPE NCC was tasked to: - document the mirroring protocol and its operational requirements. - add inverse lookups to all attributes that have integrity constraints. - propose and implement "reclaim:"-like functionality to the database. - add contact data to key-cert objects. IPv6 === * Enhanced IPv6 support for the new IPv6 Whois proxy has been implemented. * Test Traffic Measurement test-boxes now fully support IPv6. * Gert Döring (SpaceNet) proposed discussions to enable IPv6 access to the root servers and AAAA records for TLD in the root zone. * Bernard Tuy (RENATER) was tasked to co-ordinate an IPv6 routing guideline document. * The RIPE NCC was tasked to: - enable reverse delegation for 6bone under ip6.arpa. - investigate increasing the size of RIR allocations to rationalise routing with the IANA. ROUTING ======= * Joao Silva Damas (ISC) was announced as co-chair of the Routing Working Group. A second co-chair is being sought. * The Routing Registry Consistency Check utility implemented by the RIPE NCC was finalised. The source code is available on the RIPE NCC ftp server at: ftp://ftp.ripe.net/ripe/dbase/software/RRCC-0.2.tar.gz * A list of IP address space allocated by the RIPE NCC, useful for filtering unallocated address space on routers, was published on the RIPE NCC ftp server at: ftp://ftp.ripe.net/ripe/stats/issued/ * As a part of the RIS Beacon Project the RIPE NCC was tasked to look into the behaviour of a second BGP announcement whilst the first one has not yet converged. * The RIPE NCC was tasked to analyse RIS data to approximate how much of the Internet is seen by RIS route collectors. DNS ==== * Johan Ihren (Autonomica AB) presented a proposal for experimentally signing the root-zone. The RIPE NCC was tasked to discuss the idea with the RIRs and propose technical and political recommendations. * Andrei Robachevsky (RIPE NCC) presented a report on IPv6-related DNS issues. The RIPE NCC requests feedback on freezing delegations in the ip6.int space, reverse 6to4 delegations and support of 6bone space reverse delegations under ip6.arpa. TTM & RESEARCH =============== * A new Chair is being sought for the Test Traffic Working Group. * Test Traffic Measurement test-boxes now fully support IPv6, making TTM the first measurement product on the market to do so. * CDMA is now fully supported as an alternative clock source. * Mailing list discussions have begun on upgrading TTM to the IPv6 version as well as on new business models for TTM. TECHSEC ======== * Erik Rozendaal (NLnet Labs) presented a new project at NLnet Labs called Donkey. It intends to provide a general purpose distributed public key database. The presentation can be found at: http://www.ripe.net/ripe/meetings/archive/ripe-44/presentations/ripe44-tech… ANTI-SPAM ========= * More spam problems with proxies than open relays were reported. * Assured Path Messaging was noted as a possible alternative e-mail service. PRESENTATIONS ============== * SQL Slammer Worm Attack / Rene Wilhelm (RIPE NCC) - Analysis of data collected around the time of this attack, showing clear effects but also that most of the Internet backbone infrastructure survived: http://www.ripe.net/ripe/meetings/archive/ripe-44/presentations/ripe44-tt-s… * Improved Secure Communication System for RIPE NCC Members / Andrei Robachevsky (RIPE NCC) - An initial proposal was presented on how to improve the current system by using a X.509-based PKI model: http://www.ripe.net/ripe/meetings/archive/ripe-44/presentations/ripe44-plen… * The RIPE NCC LIR Portal v.1 / Leo Vegoda and Manuel Valente (RIPE NCC) - The new portal services features were explained in a live demonstration: http://www.ripe.net/ripe/meetings/archive/ripe-44/presentations/ripe44-lir-… TUTORIALS ========= * The RIPE NCC IP Request Tutorial, given by the RIPE NCC staff, was presented. It explained address space assignment and allocation procedures in the RIPE NCC region: http://www.ripe.net/ripe/meetings/archive/ripe-44/tutorials/ * The NetFlow Services tutorial, given by Benoit Claise (Cisco Systems), on reviewing the design, configuration, tuning and troubleshooting of NetFlow versions was presented during the EOF: http://www.ripe.net/ripe/meetings/archive/ripe-44/presentations/ripe44-eof-… * The BGP Troubleshooting tutorial, given by Philip Smith (Cisco Systems), covering common problems ISPs face when deploying BGP within their networks was also presented during the EOF: http://www.ripe.net/ripe/meetings/archive/ripe-44/presentations/ripe44-eof-… FIRST RIPE MEETING WEBCASTING ============================ The first RIPE Meeting webcast was held at RIPE 44. Recordings of sessions held in the Grand Ballroom have been archived and can be accessed at: http://www.ripe.net/ripe/meetings/archive/ripe-44/multicast.html HOSTMASTER CENTRE ================== The RIPE NCC Hostmaster Centre was open during RIPE 44. The centre continues to be a useful facility for the meeting attendees and will be provided at RIPE 45. RIPE 44 REFERENCE PAGE ====================== A complete list of RIPE 44 sessions, tutorials and presentations can be found at: http://www.ripe.net/ripe/meetings/archive/ripe-44/ RIPE 45 ====== RIPE 45 will be held in Barcelona, Spain from 12 to 16 May 2003. Information on RIPE 45 will be available at: http://www.ripe.net/ripe/meetings/ripe-45/ New LIRs please note: LIRs who signed up in 2002 are entitled to two (2) free tickets to attend RIPE 45. The tickets cover registration only and do not apply to the RIPE dinner, your travel or hotel accommodations. More information on the new LIR tickets can be found at: http://www.ripe.net/ripe/meetings/ripe-45/new-lir.html Or contact <meeting(a)ripe.net>. END

2 1

New Mailing List: lirportal@ripe.net
by RIPE NCC Mailing List administration 19 Feb '03

19 Feb '03

Dear All, (Apologies for any duplicate mails). In response to the community's request during the Tools Working Group at RIPE 44 we are pleased to announce a new mailing list specifically for the RIPE NCC LIR Portal. This mailing list will provide an opportunity to discuss any issues related to the LIR Portal including the features offered and issues concerning the application. You can join the LIR Portal mailing list <lirportal(a)ripe.net> by following the instructions at: http://www.ripe.net/mailman/listinfo/lirportal For more information about the LIR Portal please refer to our previous announcement found at: http://www.ripe.net/ripencc/mem-services/lir-portal.html Regards, RIPE NCC Mailing List administration

1 0

Sub-allocations, how and when?
by Kristofer Sigurdsson 18 Feb '03

18 Feb '03

Hello, I am currently doing some work for a small ISP with a fair number of clients, that wants to get a sub-allocation (in accordance with the new sub-allocations policy). We are going to request a /20 allocation from our primary uplink. However, we may have difficulties in showing usage for a /20 assignment for ourselves and our current customers (we're not far from it, though), but we need this allocation to deal with near-future customers. We are also going to request an AS in order to be properly multi-homed, which means we need the /20 right away to avoid prefix filters. We could of course, in accordance with the RIPE community's "slow-start" mechanism, start with a smaller allocation, or even just request assignments for ourselves, our customers, and then new customers as we go along, but this would mean lots of CIDR blocks, instead of just one /20. We are also going to request an AS in order to be properly multi-homed, due to prefix filters, having many small blocks is not an option. Becoming a LIR is not an option just now, due to various financial and political reasons. Now, my question to the list is, when will the sub-allocation policy be operational, and how will one request such an allocation? Presumably, RIPE will provide a sample allocation request form, any idea when? Any ideas on how to do this without a sub-allocation? Any way for our uplink to "reserve" a /20, which would then origin from our AS, and then assign chunks of it to us as we go along, maybe? Our uplink's AW is /24, and they don't have any room within their current allocations to give us a /20, so they would have to request this specifically from RIPE. Thanks in advance for any comments and/or suggestions. -- Kristófer Sigurðsson

3 6

New Document available: RIPE-269
by RIPE NCC Document Announcement Service 17 Feb '03

17 Feb '03

New RIPE Document Announcement -------------------------------------- A new document is available from the RIPE document store. Ref: ripe-269 Title: Smallest RIPE NCC Allocation / Assignment Sizes Author: Joao Luis Silva Damas, Leo Vegoda Date: 17 February 2003 Format: PS=10901 TXT=2159 Obsoletes: ripe-222, ripe-242, ripe-259. ripe-264, ripe-266 Obsoleted by: Updates: Updated by: Short content description ------------------------- This document contains the size of the minimum and default allocations made by the RIPE NCC to Local Internet Registries (LIRs) and End Users from IPv4 and IPv6 CIDR blocks allocated to the RIPE NCC by the Internet Assigned Numbers Authority (IANA). The new 2001:1400::/23 IPv6 allocation and its routing policy have been added. Accessing the RIPE document store --------------------------------- You can access the RIPE documents in HTML format via our website at the following URL:. http://www.ripe.net/docs/smallest-alloc-sizes.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-269.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-269.txt plain text version Kind Regards, Jeroen Bet RIPE NCC Web Content Manager

1 0

APNIC new block of addresses
by leo vegoda 14 Feb '03

14 Feb '03

FYI -- leo vegoda RIPE NCC Registration Services

1 0

APNIC new block of addresses
by John Tran 14 Feb '03

14 Feb '03

Dear colleagues APNIC received IPv4 address blocks 222/8 and 223/8 from IANA in February 2003 and will be making allocations from these ranges in the near future. This announcement is being made for the information of the Internet community so that network configurations such as routing filters may be updated as appropriate. For more information on the resources administered by APNIC, see: http://www.apnic.net/db/ranges.html For information on the minimum allocation sizes within address ranges administered by APNIC, see: http://www.apnic.net/db/min-alloc.html Kind regards Son ____________________________________________________________________ Resources Services Manager <Son(a)apnic.net> Asia Pacific Network Information Centre phone: +61 7 3858 3100 http://www.apnic.net fax: +61 7 3858 3199 Helpdesk phone: +61 7 3858 3188 email: helpdesk(a)apnic.net Please send Internet Resource Requests to <hostmaster(a)apnic.net> _____________________________________________________________________

1 0