Hi, I'm Iljitsch van Beijnum. These are general neworking-related posts.
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
Since the announcement was made on the 35th anniversary of the first moon landing, I think it's appropriate to modify Neil Armstrong's famous quote slightly:
"One small step for mankind... but a huge step for ICANN."
Yesterday, ICANN (the Internet Corporation for Assigned Names and Numbers) announced that IPv6 nameservers for .jp and .kr were added to the root zone. Now obviously this is a necessary step for making it possible to resolve domain names using IPv6, but it's really not a big deal as IPv6 delegations have been around lower down the delegation chain for a very long time, and no reasonable DNS implementation has a problem with this. Also, ns.ripe.net has had an IPv6 address for some time now, and this nameserver is secondary for country domains such as .nl and .it, not to mention the reverse mapping of huge slabs of IP address space. The difference between that and the new .jp and .kr delegations is that those also have an AAAA glue record, while ns.ripe.net only has an A glue record.
But the real issue here is having IPv6 addresses for the root servers themselves. There has been considerable experimenting with actually running root service over IPv6 transport. However, in order for an IPv6-only host to be able to get at the root servers, those IPv6 addresses must be published in two places. Number one is the named.root "hints" file, which DNS servers use to find the root servers on startup. It's fairly trivial to add IPv6 addresses to this file. This would allow a DNS server to perform the first query over IPv6. Unfortunately, that first query is for the full set of root servers. Since there are 13 of those, the response to this query comes fairly close to the maximum response size of 512 bytes. Adding IPv6 addresses for all root servers isn't possible without going over this limit, which has the potential to cause several problems. I'm very interested to see how ICANN is going to handle this, and especially when they're going to handle this.
As a bonus, at long last E.F.F.3.IP6.ARPA has been delegated so that 6bone addresses (3ffe::/16) can now enjoy proper reverse service in the DNS.
Permalink - posted 2004-07-21
As I wrote a few weeks ago in an article under the name "no ip unreachables", path MTU discovery doesn't work all that well across the internet in practice. Since then, I've noticed that people end up on this site looking for ways to clear the don't fragment bit in the IP header. So here is an example of how to do this on a Cisco router:
! route-map nodf permit 10 set ip df 0 ! interface FastEthernet2/0 ip policy route-map nodf !
Note that the "ip policy route-map nodf" command must be applied on the interface receiving the packets for which the DF bit must be cleared, and not the interface with the reduced MTU itself, where the packets are subsequently transmitted. See a page at Cisco for additional strategies. Permalink - posted 2004-01-12
I think I'm jinxed. When I put my anti-DoS article up on this site the root name servers were attacked. Then O'Reilly put the article on ONLAMP and the next day there was the MS SQL worm...
A worm in a single 404 byte UDP packet: the net certainly wasn't prepared for that. This worm didn't really harm infected systems all that much: it's the incredible amount of traffic generated by each infected system that caused so much trouble. Obviously dozens of megabits worth of traffic for each affected host will lead to congestion in many places, but it was worse than that: Cisco routers that were doing fast switching rather than Cisco Express Forwarding (CEF) ran out of memory and CPU. It also seems Riverstone routers, which are supposed to be able to do this in hardware, fell flat on their faces. (But I haven't seend this myself.)
Have a look at an article I wrote for the O'Reilly Network about the impact of this worm: Network Impact of the MS SQL Worm. (Note: the link doesn't work anymore, but I saved the article here.) And CAIDA has an in-depth analysis.
Permalink - posted 2003-02-14
This is a post I wrote for O'Reilly back in January 2003 when the SQL Slammer worm hit. It seems it's gone from their site now, so I'm putting it here, including the comments.
Permalink - posted 2003-01-28
At the end of September, the White House published a National Strategy to Secure Cyberspace. It seems that at the last moment, a lot of text was cut and the 60 odd pages PDF document offered for download was made a draft, with the government actively soliciting comments. One of the prime recommendations in the document is:
| R4-1 | A public-private partnership should refine and accelerate the adoption of improved security for Border Gateway Protocol, Internet Protocol, Domain Name System, and others. |
Some people say the government wants Secure BGP (S-BGP) to be adopted. It is unclear how reliable these claims are. In any event, S-BGP has been a draft for two years, with no sign of becoming an RFC or implementations being in the works.
In 2001 4th quarter interdomain routing news I ranted about the general problems with strong crypto in the routing system. It is widely assumed BGP is insecure because "anybody can inject any information into the global routing table." It is true that the protocol itself doesn't offer protection against abuse, but since BGP has many hooks for implementing policies, it is not a big problem to create filters that only allow announcements from customers or peers that are known to be good. However, the Routing Registries that are supposed to be the source of this information aren't always 100% accurate and although their security has greatly improved the last few years, it is not inconceivable that someone could enter false information in a routing database.
In an effort to make BGP more secure, S-BGP goes way overboard. Not only are BGP announcements supposed to be cryptographically signed (this wouldn't be the worst idea ever, although it remains to be seen whether it is really necessary), routers along the way are also supposed to sign the data. And the source gets to determine who may or may not announce the prefix any further. I see three main problems with this approach:
And even if all of these problems can be solved, it gets much, much harder to get a BGP announcement up and running. This will lead to unreachability while people are getting their certificates straightened out. Also, routers in colo facilities aren't the best place to store private keys.
Permalink - posted 2002-10-28