- lir-wg - mailman.ripe.net

Experimental IPv6 address allocations policy
by Pekka Savola 04 Apr '03

04 Apr '03

Hi, I just recently noted that experimental IPv6 address allocations have been "sneaked in" the policy, as seen in: http://www.ripe.net/ripe/docs/ipv6policy.html#experiment-assignments I must heavily object to this for a few reasons: 1) the intent is to keep the policy uniform, and this has not been discussed in the global-v6 policy mailing list. 2) RIPE43 minutes (posted on Oct 19 2002) list that this should be turned into a draft proposal [note: the URL for the presentation does not work]; There was a draft proposal on 28 Nov 2002 on "DRAFT: Experimental Internet Resource Allocations & Assignments". This is no longer available so I cannot verify the contents. 3) On 22 Jan 2003, new RIPE documents, 263 and 267 are available; these incorporate an experimental addressing policy. To my knowledge and according to my mail archives, neither of these has *ever* been as much as mentioned in the mailing lists (either ipv6 or lir wg) - not a single message. Is this sufficient in determining this is really what community wants? To clarify, are only those organizations which meet the criteria in section 5.1.1 applicable for experimental address allocations in: http://www.ripe.net/ripe/docs/ipv6policy.html#experiment-assignments ? If the others can get experimental blocks, I'd be very much against it. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

3 4

testspace-allocation policy
by Jan.Treufeldt＠berlikomm.net 03 Apr '03

03 Apr '03

Hi all, as I remember there was a discussion about a policy for allocations needed by LIR's for test purposes. I haven't found a document in the ripe-store. Is there something in effect, yet? Is somebody working at it? Cheers, Jan. -- Jan Treufeldt eMail: Jan.Treufeldt(a)berlikomm.net BerliKomm Telekommunikationsgesellschaft mbH Fasanenstr. 85 Phone: +49 30 8188 9916 Berlin 10623 Fax: +49 30 8188 9974

3 2

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