New book: Running IPv6

I've written another book!

It's called "Running IPv6" and the title pretty much says it all. If you're interested in learning more about running IPv6 on Windows XP, MacOS X, FreeBSD, Linux or on Cisco or Juniper routers, check out the book at www.runningipv6.net. I'll also be moving IPv6 stuff to that site, so BGPexpert.com can focus more on BGP.

And I've started a blog (not too fond of that word, though) at Apress, the publisher of the new book. I just posted an entry about running out of IPv6 addresses. Seasoned visitors of this site may want to jump directly to Numerology on Geoff Huston's site www.potaroo.net, where Geoff leaves no IPv4 addressing stone unturned.

Permalink - posted 2005-11-21

IPv6 misinformation

From time to time, I like to go to news.google.com and type "ipv6". This way I get to read interesting articles such as Mad as Hell XII: IPv6. However, there are also sometimes stories that get important facts wrong, such as CIO Today's IPv6: Time Is Still Not Right article.

They don't think IPv6 is very useful at this point, they don't take the US government IPv6 position very seriously and they think NAT is actually a good idea because it hides addresses. So far so good: those are all opinions.

I'm not even going to mention the whole "other countries suffer from address scarcity" thing, which is thoroughly debunked elsewhere.

The part that really annoyed me is:

However, this feature isn't exactly free. Quadrupling the address space dramatically increases the bandwidth required to transport each packet. Sending a 64-byte message, for instance, requires 250 percent more bandwidth in IPv6 than in IPv4.

It seems like they're saying a packet with 64 data bytes will be 3.5 times as large in IPv6 as it is in IPv4. But even if we generously assume they meant that the overhead is 2.5 times as large, they're wrong. An IPv6 header is twice as big as an IPv4 header: 40 rather than 20 bytes. But in the real world, there is other overhead as well: TCP (20 bytes) or UDP (8 bytes) as well as ethernet, which has 18 visible and 20 invisible bytes of overhead. So an IPv4 packet with 64 data bytes uses up at least 64 (data) + 20 (IP) + 8 (UDP) + 38 (ethernet) bytes or 130 bytes worth of ethernet bandwidth. (That's 103% overhead.)

The same 64 bytes of data on the same ethernet but now using IPv6 takes up 150 bytes of bandwidth, which is 15.4% more than its IPv4 counterpart. The average size of packet on the internet is around 500 bytes. 20 extra bytes means an additional overhead of 4%. Yes, the extra bandwidth use is annoying, but it's a far cry from "250 percent more bandwidth".

For low-speed links there shouldn't be an issue as the IPv6 header can be compressed, just like the IPv4 header. (However, I'm not sure if this is actually implemented in available products at the moment.)

Permalink - posted 2005-08-30

US government to adopt IPv6 by mid-2008?

According to news reports, the US federal government is adopting IPv6 within the next three years.

However, the reactions are as expected. On the NANOG list, the 1990s efforts by the US federal government to get OSI networking off the ground (see GOSIP) were brought up to underscore the assumption that this effort would fail as well.

As always, the discussion on Slashdot quickly deteriorated to the level of "NAT is good enough" and "We don't need that many addresses anyway".

Makes you wonder what a modern Thomas Edison would do. Give up after the first try and stick with gas light, I expect. (Edison tried thousands of different materials as filaments in light bulbs before he found something that was reliable enough to be useful.)

To be fair, others on the NANOG list pointed out important differences between OSI/GOSIP and IPv6 that make this effort very different.

Permalink - posted 2005-07-04

IPv6 on Linksys WRT54G

EarthLink Research and Development has released experimental firmware for the Linksys WRT54G wireless residential gateway that supports IPv6. See the announcement.

This is good news because the residential gateway (forgive me for not saying "router", I know what a real router looks like and these things ain't it) is often the thing that makes it hard to get IPv6 connectivity. Obviously it's always possible to use a Cisco 82x SOHO ADSL router for this, but most home users find those too expensive. Because residential gateways invariably use network address translation (NAT), it's hard to set up an IPv6 tunnel through them. This is especially true for 6to4 automatic tunneling, which works completely automatically without NAT.

I'm not sure if Earthlink's firmware for the WRT54G supports tunnels, but it does support native IPv6 routing, and, apparently, DHCPv6 prefix delegation, and you can sign up for that as an experimental service on their network.

(Also see the WRT54G article on Wikipedia.)

Permalink - posted 2005-05-27

MacOS 10.4 Tiger IPv6 compatibility

The first thing I did after installing Tiger was check out the new IPv6 features. That didn't take long... It doesn't look like there is more IPv6 functionality in Tiger than in Panther, except for one thing:

Unlike earlier versions (including the recent 1.3 release) Safari 2.0 now uses IPv6 by default (when available, of course).

This is very nice: no more mucking about with the debug menu. It also means that you get to use session keepalive with IPv6: rather than open a new TCP session for each HTTP request, Safari will try to keep sessions open and reuse them for subsequent requests. This can be very helpful if you don't have a high bandwidth, low delay link because you don't have to suffer the TCP setup and slow start delays for every single image on a page.

Looking at this stuff in tcpdump I can't help but notice that HTTP is a very wasteful protocol. A GET can easily be 700 bytes, and many web designers use images that are only 100 bytes...

I also noticed that Safari now says Accept-Language: en, while I have English, Dutch and German (ok, slight case of hybris for that last one) set up as my languages in the system preferences. This is a shame, because my carefully crafted language detection at http://www.muada.com/ now no longer knows I speak Dutch so it shows me the English version of the page.

However, the switch to Tiger wasn't entirely problem-free in the IPv6 department: the new Mail has a pretty serious bug: SMTP won't work over IPv6 anymore. To add insult to injury, Mail won't all back on IPv4 for SMTP, so if your SMTP server has an AAAA record in the DNS and you have IPv6 connectivity, you won't be able to send mail. The workaround is to configure a DNS name for the SMTP server that doesn't have an AAAA record, or the SMTP server's IPv4 address. See bug 4113850 in Apple's bug reporter (you must have a developer account to log in) for more details.

Permalink - posted 2005-05-16

RIPE 46 Tuesday - EOF, geo aggregation, security BOF

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.

Permalink - posted 2003-09-01

older posts - newer posts