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

0:0.1.*.*.* .ARPA...WIANA - Wireless IANA ?
by Jim Fleming 29 Mar '03

29 Mar '03

> > http://www.communitywireless.org/ > > http://www.locustworld.com/ > > http://wiana.org/faq.php > > What type of addresses and ranges are you allocating? > > Currently, IPv4 style addresses in the 1.x.x.x range. > > =================== ----- Original Message ----- From: "John Palmer" <jp(a)ADNS.NET> To: <ga(a)dnso.org> Sent: Friday, March 28, 2003 3:05 PM Subject: Re: [ga] WIANA - Wireless IANA ? > 1/8 has not been allocated yet, Jim. Bogon filters will catch them. > What does the ICANN Board and their team of technical experts plan to do about it ? http://www.iana.org/assignments/as-numbers http://www.iana.org/assignments/ipv4-address-space ...note the similar problems with 69/8... http://www.merit.edu/mail.archives/nanog/msg08423.html http://www.merit.edu/mail.archives/nanog/msg08580.html > > > > > Jim Fleming > > http://www.IPv8.info > >

1 0

Planned Downtime for LIR Portal Service
by Manuel Valente 21 Mar '03

21 Mar '03

Dear Colleagues, On Monday, 24 March, between 17:00h and 19:00h CET, the RIPE NCC will perform a major OS upgrade affecting some of our internal services. During this period, the LIR Portal will be unavailable. We apologize for any inconvenience that this downtime may cause to your operations. Regards, -- Manuel Valente - Software Manager - RIPE NCC

1 0

Scheduled Downtime for rttquery service
by Manuel Valente 17 Mar '03

17 Mar '03

Dear Colleagues, On Tuesday, 18th of March, between 17h30 and 18h00 CET, the RIPE NCC will proceed to an upgrade of some of our internal services. During that period, the rttquery service will be unavailable, both from the RIPE NCC public website and from the LIR Portal. We apologize for any inconvenience that this downtime may cause to your operations. -- Manuel Valente - Software Manager - RIPE NCC

1 0

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

RIPE 44 LIR WG minutes available - DRAFT 1
by Gert Doering 10 Mar '03

10 Mar '03

Hi, the DRAFT minutes from the LIR-WG working group meeting at RIPE 44 are now available on the web: http://www.ripe.net/ripe/wg/lir/r44-minutes.html Please check the minutes whether we overlooked something, and send comments to the list or to one of the WG chairs personally. The review period ends in 4 weeks, April 10th. Thanks to the RIPE NCC for preparing the minutes. regards, Gert Doering -- LIR WG co-chair -- Total number of prefixes smaller than registry allocations: 57285 (57021) SpaceNet AG Mail: netmaster(a)Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299

1 0

Re: [ipv6-wg@ripe.net] Re: [lir-wg] IXP networks routing
by Peter Galbavy 07 Mar '03

07 Mar '03

> PRIVATE INTERCONNECTS. Real world example follows, which is why my primary > employer has a PI assignment; we interconnect using IPsec VPNs and some > leased lines with a number of other enterprises. We use RFC1918 *internally* > and so do many others. What addressing scheme would you suggest we use to > talk, especially as we DO NOT want this traffic to accidentally leak onto > the public internet ? I notice that my reply has been conveniently ignored. Well, how will you address this issue in the *real* world ? Peter

3 8

RE: [ipv6-wg@ripe.net] Cross posting
by Michel Py 06 Mar '03

06 Mar '03

> David Kessens wrote: > This is request to keep the current discussions regarding > ipv6 on the appropriate list and not to cross post to both > the ipv6 and lir working group lists: > - ipv6-wg > Technical discussions regarding the deployment of ipv6 in > the RIPE region > - lir-wg > policy discussion list including ipv6 allocation policies Agree. Anyway, half of this was a discussion about multihoming that I have heard 10 times already and that has always ended up in the same place: nowhere. If one wants to discuss the topic, one should type "ipv6 multihoming" in the search window of any reputable search engine and go where it's actually happening. Michel.

2 1

PI Space and IXP routing
by Stefan Wahl 06 Mar '03

06 Mar '03

Just my .2 cent question. When there are only a small number of ixp´s in the world (maybe 100) and they are interested to route there networks worldwide (e.g. critical services) and the community has two reasons to not allow this. One reason could be not to put all /24 into my routing table and second i don´t want to get problems in the peering mesh. What could be the solution: a. filterlist in the peering mesh router of the isp and b. give every ixp a /22 or /23 I know we are wasting valueble ipv4 space here, but look at the numbers of ixp and compare them to the /24´s. But then we need a really simple and in every way exact definition of an ixp. Maybe this construct is also possible with ipv6? And please stop to argue that the ixp could get address space from the uplink provider. There are so many companies that broke in the last two years, that the possibility that my uplink goes down is very high in Germany. Then I would request at ripe to takeover the addressspace. The ixp would do this, because he did not want to renumber the peering mesh. Why should ripe not give it right at the start. Comments welcome. Hmmmm..... - Stefan

1 0

RIPE NCC Power Interruption
by RIPE NCC WebMaster 06 Mar '03

06 Mar '03

Dear Colleagues, At approximately 7 a.m. (CET) this morning, the RIPE NCC experienced a temporary power outage affecting external communications. Nuon, the RIPE NCC's electricity provider, began an immediate investigation and restored power to our facilities at approximately 11:15 am (CET). We apologise for any interruption or delay in service and communications. Should you have any concerns regarding this issue please contact <ops(a)ripe.net>. Regards, RIPE NCC Operations

1 0

RIPE NCC Ticketing System problems?
by Hank Nussbacher 06 Mar '03

06 Mar '03

Is it just me or is the Ticketing System query form hanging for others as well? http://www.ripe.net/cgi-bin/rttquery -Hank

1 0