Hi, I'm Iljitsch van Beijnum. This page has all posts about all subjects.
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
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
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
FYI - my book is now also available in Japanese. The translation is published by Ohmsha.
Update: this is what it looks like.
So apparently Japanese for "gazelle" (as on the cover of the English version) is "mule"...
Permalink - posted 2004-08-21
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
Image link - posted 2004-06-13 in