My new BGP book: 'Internet Routing with BGP' by Iljitsch van Beijnum BGPexpert My BGP book from 2002: 'BGP' by Iljitsch van Beijnum

Home · BGP Expert Test · What is BGP? · BGP Vendors · Links · Archives · Books · My New BGP Book

BGP (advertisement)
RIPE 46 Tuesday - EOF, geo aggregation, security BOF (posted 2003-09-01)

Tuesday

Sometimes everything seems like routing

It seems the IETF doesn't like to organize its meetings around San Francisco because those meetings tend to be "zoos" because they attract too many "local tourists". Well, a local tourist is what I kind of am at the RIPE meeting this week. But unfortunately I'm not completely local: I take the train from The Hague to Amsterdam each morning. Today, after the NSF Security BOF (more on that below) I walked to the Amsterdam Central Station to take the train back home. But there was a power outage in Leiden, so I've been rerouted over Utrecht. Obviously there is lots of congestion and increased delay, but so far no commuter loss. So I'm typing this sitting on the floor of a hugely overstuffed train, two hours after I got to the train station, still no closer to home.

Anyway... More EOF

This morning's two sessions concluded the EOF part of this week's RIPE meeting. First we heard from David Malone from tcd.ie in Dublin, and in the second session from Dave Wilson, his ISP, about their efforts to enable IPv6. Some good stuff: don't use a stateless autoconfigured address (with a MAC address in it) for the DNS you register with your favorite registries: you don't want to have to change the delegation when you replace the NIC. And since there are more than enough subnets, why not splurge on a dedicated /64 for this? Makes it easy to move the primary/secondary DNS service around the network. They also talked about possible multicasting problems with switches that do ICMP snooping but are unaware of IPv6, and about next hop troubles when exchanging IPv6 routes over a BGP session with IPv4 transport or the other way around, but in both cases I think this is supposed to work, so I'll look into this to see what the real story is. Next week, that is.

Geographical aggregation

During the routing working group session in the afternoon, I once again presented my provider-internal geographical aggregation draft. (See my presentations page for a link.) I have added some stuff on why this is still useful even if we can have multihoming using multiple addresses per host:

  • We can deploy multihoming using geographical aggregation really fast, because we start multihoming as soon as a suitable address assignment system is operational, and clean up the routing table later in individual networks by implementing the necessary filtering.
  • Because optical (fiber path) switching is so cheap relative to layer 2 switching or routing (Cees de Laat of the University of Amsterdam says it's even 100 : 10 : 1) it's entirely possible we'll see on-demand fiber links. Routing obviously has to deal with this, and if we can aggregate away the uninteresting stuff we're in much better shape for this.
  • If a host gets several addresses with different geographical properties, the host has the opportunity to do some elimentary source routing and use the address with the shortest (or highest bandwidth) path.

Unfortunately, the room didn't seem all that receptive. Well, too bad. I guess the routing crowd isn't ready for IPv6 stuff in general and somewhat non-mainstream IPv6 stuff in particular.

NSP Security BOF

At six, there was the NSP Security Birds of a Feather session. It seems there is a special mailinglist for operators who deal with denial of service, but they keep membership limited to a few key people per ISP. Obviously that means discussing who is allowed on the list and who is kicked off takes a lot of time.

After that there was an hour-by-hour account from a Cisco incident response guy (Damir Rajnovic) about the input queue locking up vulnerability that got out in june. It seems they spend a lot of time keeping this under wraps. I'm not sure if I'm very happy about this. One the one hand, it gives them time to fix the bug, on the other hand our systems are vulnerable without us knowing about it. They went public a day or so earlier than they wanted because there were all kinds of rumours floating around. It turned out that keeping it under wraps wasn't entirely a bad idea as there was an exploit within the hour after the details got out. But I'm not a huge fan of them telling only tier-1 ISPs that "people should stay at the office" and then disclosing the information to them first. It seems to me that announcing to everyone that there will be an announcement at some time 12 or 24 hours in the future makes more sense. In the end they couldn't keep the fact that something was going on under wraps anyway. And large numbers of updated images with vague release notes also turned out to be a big clue to people who pay attention to such things. One thing was pretty good: it seems that Cisco itself is now working on reducing the huge numbers of different images and feature sets, because this makes testing hell.