why same names, was Re: NANOG 40 agenda posted
Iljitsch van Beijnum
iljitsch at muada.com
Wed May 30 08:00:55 UTC 2007
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.
More information about the NANOG