ietf
[Top] [All Lists]

Re: The IPv6 Transitional Preference Problem

2010-06-20 10:32:33
And those failed lookups have a real support overhead cost. Among other 
things,
they create entries in appliction and firewall logs.

I would think the delays implied by IPv6-then-IPv4 communication setup
failure would result in _far_ more calls than calls from the (relatively) few
people who look at application and firewall logs (ever look at the console log
on your average MacOSX system? I doubt Apple gets many calls despite the
tremendous amount of noise that gets logged).

I never said that the approach of trying IPv6 then IPv4 was any better. In fact
I said exactly the opposite in the part you quote below - I said that right now
it's extremely ill-advised to ship products that have IPv6 support enabled by
default. This is one of the many reasons for this.

And Apple isn't proof of much of anything. What they've done is basically hide
these logs so that nobody even knows they're even there. How they manage to
avoid the issue that when things start to go wonky nobody knows until it's too
late is an interesting point, but it's hardly relevant to the current
discussion.

At this point I wouldn't consider shipping an application that doesn't 
support
at least basic IPv6 connectivity, but there's also no way I'd consider 
shipping
an application that has that support enabled by default, because it's
guaranteed to be a support call generator.

An understandable and conservative approach, however won't the implication of
taking this route be that in the longer term, your products will, by default,
generate support calls as customers will not be able to connect to IPv6-only
sites (or connect sub-optimally to multi-layer NATv4 sites)?

First of all, one of the main points I'be been trying to make is that right now
transitioning to IPv6 is far too difficult. The response I've been getting to
that isn't, "Yes, you're right, we need to work on making that transition
seamless", but rather, "Yes it's a pain, but eventually the benefits of using
IPv6 will be so manifest that everyone will be forced to do it no matter how
painful, so suck it up." At present the transition is far from seamless that
the need to switch on IPv6 support in a particular application by flipping a
well-documented switch is completely lost in the noise.

But now let's suppose that people wake up and start trying to address the
transition problems, and end up making the process more seamless. Well, guess
what? One aspect of that needs to be to provide applications with information
about whether or not to enable IPv6 suppport. (This is actually quite tricky to
do because you cannot deploy new operating system level APIs in the necessary
time frame, but other approaches are possible.)

In other words, fix the transition problems, and you also eliminate the need
for IPv6 support to be off by default. Don't fix them, and the tradeoffs remain
in favor of off by default.

But let's suppose, for the sake of argument, that I'm totally wrong about this,
and that having IPv6 support off is going to rise way above the noise and
generate lots of support calls at that hoped-for infection point some years
from now when everyone has to have IPv6.

So how is this conversation with my managenent today supposeed to go exactly? I
say, "We need to enable IPv6 support by default despite the fact that it's
going to generate a fair number of support calls in the near term. The reason
is it will prevent even more calls in the longer term." They then ask, "How
near is near, and how far out is the longer term?" I say, "Well, the near term
is the next couple of years, and the longer term, well, that's hard to say, but
it's at least past those couple of years, if not more. Or it may not happen
that way at all."

Keeping in mind that these days it is  rare for any company to look further
ahead than the next quarter, what do you think the response is going to be?

[On APIs]
At this point the work is really too little too late.

I've read long ago that back in the 80s, the guy who wrote make(1) realized
that makefile's use of whitespace was problematic, but the user base of about
50 people was too large to make any changes...

Which is why I was careful to qualify my statements about the value of such
work in terms of what you're actually attempting to accomplish. If your goal is
simply to make the world a better place for application developers in the long
term, then sure, go for it. But that' wasn't why the idea of an API update came
up. It was specifically to assist in the transition to IPv6 in the short term.
If that's your goal, then IMO it's a pointless exercise.

                                Ned
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf