Image link - posted 2005-01-14
When I talk about IPv6 I like to bring up two pictures of a web site, one seen over IPv4 and the other over IPv6. Obviously, the two pictures are identical. Because of this invisibility, it's hard to know what kind of deployment progress there is with IPv6. A few years ago I decided to visit all the web sites of all AMS-IX members and see which ones I could reach over IPv6. The results weren't all that impressive back then, but things have started to change over the past year. In april 2004 the web sites of four members were reachable over IPv6 (with one other having an unreachable address) and in march 2005 this was nine out of 213.
For many organizations making their web site available over IPv6 is a serious commitment, so the number of AMS-IX members that run IPv6 is even higher. According to the AMS-IX member list in march 2005, for 213 members with 343 ports there were 59 IPv6 addresses present on the exchange.
However, the AMS-IX membership isn't exactly representative of the net as a whole. I also had a look at a self-proclaimed list of the top 100 English language web sites but out of those not a single one was reachable over IPv6.
One (http://www.alibaba.com/) suffered from the "doubleclick syndrome" and didn't reply to AAAA DNS queries, which introduces a 10 second delay when visiting this site with an IPv6-enabled WWW browser. This is the reason why many people are disabling IPv6 in Firefox.
My conclusion: IPv6 deployment is happening, but it has a very long way to go.
Permalink - posted 2005-04-17
Because some IETF documents such as RFC 3489 and draft-ietf-sipping-nat-scenarios-00.txt talk about ISPs putting their customers behind a Network Address Translation device, Philip Matthews posed the question to the NANOG list about how wide spread this practice is.
Some people followed up with examples. Most of these are for things such as GPRS and 802.11, but there are also a few ISPs that do this for "regular" services such as DSL. According to Philip in a summarization of private replies:
"It seems that there are quite a few providers who do this. I was told of at least 24 providers in the U.S., as well as providers in Canada, in Central America, in Europe, and in Africa which which do this."
Unfortunately, there is little or no information why service providers do this except for examples where small ISPs are unable to get enough addresses or get their own address block routed from a large incumbent telco/ISP in non-deregulated markets.
In the IETF, NAT has a bad reputation because it breaks many protocols and because it's hard (if possible at all) to run services on NATed systems. Users who run their own NAT device (which is probably the majority of all "always-on" IP users) can configure their NAT to allow certain incoming traffic, but this won't work with service provider NAT because a single port number must be shared across several customers.
Permalink - posted 2005-04-23
Paul Wilson, Director General of the Asia Pacific Network Information Centre (APNIC), and Geoff Huston, Senior Internet Research Scientist at APNIC, have written an article published on CircleID which was well- received on the NANOG list:
Could IP Addressing Benefit from the Introduction of Competitive Suppliers?
Today, IP addresses are distributed by five Regional Internet Registries that each serve part of the world:
In the article Paul and Geoff argue that competition between IP address suppliers would lead to a "race to the bottom": the only aspect on which these suppliers can compete is the (de facto) ease of getting addresses, so the current policies that are in place to conserve the 1.2 billion remaining IPv4 addresses (out of 3.7 billion usable ones) but at the same time allow legitimate use would cease to exist and the remaining IPv4 space would be used up a lot faster.
On the other hand, if the ITU gets its way, each country gets to do this on their own which can lead to both competition as some countries give out addresses to foreign businesses, or hoarding and buying/selling addresses, which leads to addresses not being used. (And the fragmentation of the address space leads to a larger routing table which mean more expensive routers for all ISPs, which is one of my main concerns here.)
Permalink - posted 2005-04-28
The MIT Advanced Network Architecture Group runs a Spoofer project. You can view the results and/or download a client in order to participate.
The goal of this research project is to determine to what degree hosts connected to the internet can spoof source addresses in outgoing packets. The problem with spoofing is that it can be used to hide the true origin of malicious packets that are used in denial of service (DoS) or distributed denial of service (DDoS) attacks.
The current wisdom was/is that DDoSers have such an easy time launching their attacks from compromised hosts ("zombies") under their control, that spoofing isn't worth the trouble these days. (And NATs may rewrite the spoofed address into a non-spoofed address.) Unfortunately, there is little public information about the (D)DoS problem, but anecdotal evidence suggests that most DDoS attacks indeed use real addresses, but there is still a class of attacks that uses spoofed addresses.
Note that the trouble with spoofing is not just that the source remains hidden, but also that it's impossible to filter out the packets based on source address. Some people argue that the number of sources is so large that this doesn't matter, but I'm not convinced by this argument.
Anyway, it's interesting to see that many networks don't allow outgoing packets with spoofed sources, but there is also a large class of networks that allows them. And it's not entirely a binary thing: some networks filter, but not with 100% success.
It's interesting to note that as of Service Pack 2 Windows XP no longer allows programs to send spoofed packets. (But taking part in the Spoofer project is still encouraged for WinXPSP2 users because it shows important data points.)
Permalink - posted 2005-05-06
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
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
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
Mijn foto's van What The Hack (WTH).
Read the article - posted 2005-07-30
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
My photos from Electric Picnic 2005.
Read the article - posted 2005-09-05
Image link - posted 2005-10-28
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
Image link - posted 2005-12-08
I wanted to write something about 32-bit AS numbers. But Geoff Huston pretty much said it all.
Note however, that at the time of this writing 33580 AS numbers have been assigned by the RIRs. So there are still nearly 31000 available in the IANA global pool and in the RIR's pools combined. The 32-bit AS number capability should show up in routers fairly soon. It turns out that for routing protocols the IETF has more strict rules about publishing RFCs: there must be two interoperating implementations before the RFC may be published. This makes no sense whatsoever (but has that stopped the IETF before?) because this means there is no long-term document for these implementers to work off of, as the drafts (the stage before something becomes an RFC) are removed after 6 months.
The 32-bit AS number draft (called "as4bytes", which is strange as the IETF never uses "byte" but rather "octet", after all 25 years ago there were computers that used "bytes" that weren't 8 bits). As I was saying, the 32-bit AS number draft has been around since at least the year 2000, but it couldn't progress because of the two implementations rule. Turns out that Juniper and Redback actually did implement the draft without telling anyone. When this was discovered the RFC publication process was put into motion. I'm interested to see how long it takes for the RFC to become available.
Permalink - posted 2005-12-11
Image link - posted 2005-12-15
Apress, Berkeley, CA, 2005. ISBN 1-59059-527-0
Iljitsch van Beijnum
(publisher) (Amazon) (Google preview)