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.
|
