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@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