On 29-mei-2007, at 21:53, David Conrad wrote:
We have tried to overlay the same transport and presentation layer onto a new network layer, but have not engineered the new network layer to facilitate this. We have new APIs and new naming attributes, requiring applications to do the heavy lifting while at the same time, not providing any reasonable mechanism to relay information back to the applications when it turns out that heavy lifting is in vain.
Yeah, this "unreliable datagram service" can never work, let's all stick with X.25. The transition from IPv4 to IPv6 is hard enough as it is. Having different DNS names tied to each protocol pretty much guarantees it's never going to happen, because you can't expose IPv4-only users to IPv6-only names. And clients figuring out whether they have working IPv6 reachability is exactly the part that you have a problem with, so you can't use that either. The problem with applications is that many of them still manage IP addresses "manually". In that case, it's unavoidable that the application must be updated for a new version of IP. But a Java app will never know the difference because the Java language simply redefined "IP address". It's now a superclass with IPv4 and IPv6 subclasses. Ain't object orientation grand? Most higher level languages can hide the difference between IPv4 and IPv6 from most applications, leaving just the implementation of protocols that require knowledge of IP addresses, such as SIP.
I would agree that in the ideal world, an end user should be able to point their browser to a given URL and get back the same content irrespective of the underlying network layer protocol being used. However, in the world I live in, it doesn't work like this.
Repeat after me: "don't block ICMP packet too big". That's 80% of your trouble right there. I've been living the IPv6 life for some years now, and occasionally, problems crop up. This seems to be a particularly bad month, because in addition to the long standing problem with www.apnic.net where sessions start but get slower and slower until they don't move any data any more (still have to talk to the APNIC NOC about that) I can't seem to reach www.ietf.org over IPv6 these days and I have to wait 10 seconds before I fall back to IPv4. By and large, it works well enough that I'm not tempted to turn off IPv6, but I wouldn't migrate millions of unsuspecting users just yet. If a few more content people can bring up IPv6 people like me will happily provide feedback about what doesn't work and in another year or two, things will be stable enough for a wider audience.
Of course you can argue that the only way we'll be able to get to the ideal world is by forcing people to deal with the breakage so that it'll be fixed, but I'd point to Vijay's presentations. The problem is, if you're a large scale ISP, how many calls to your help desk will it take until your helpdesk staff says "turn off IPv6"?
Not many. That's why we need to proceed with caution. But there is still time, making rash decisions based on the current situation would be a mistake. The IPv6 internet and applications grow more mature every year.