why same names, was Re: NANOG 40 agenda posted

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.