Subject: (ngtrans) Application transition

From: Dancer <[email-masked]>
Date: Tue, 13 Jul 1999 17:48:40 +1000

I've been scanning the BIS discussion, as well as the related issues,
and thought I'd speak up and throw my two bits into the ring about
application conversion/transition and the encouragement and issues
thereof.

I've developed all sorts of stuff over the years, and in the last few
months I've been quietly encouraging or badgering application developers
to convert to protocol independant code (or at the very least add V6
support to their apps).

The whole V6 (I hestitate to use the overloaded word) 'scene' is
geek-territory once more...like the internet when I first crawled onto
it in 1979 (and haven't been seen since, so they say), it's a rarefied
and rather heady atmosphere at present. The tourists haven't gotten here
yet, and the temple is still sacred.

In my experience, and from discussions with app developers (I'm working
on dragging the main squid source-tree kicking and screaming into the
world of protocol independance, and IPv6...don't ask me how it's going.
Slowly. There's MUCH code needs to be reworked) the impression everyone
seems to have about v6 is 'why? Why should I do all this work? V6 is the
same as v4 with more addresses. Who cares? It'll never catch on in the
forseeable future...I mean, how many apps are there for it? Hardly any!'

It's a bootstrap problem. Ever been involved with a company that was
developing 3d video accelerators a couple years ago? You can't interest
the developers (except with bribery) in developing code specific to your
card because nobody's been buying them, and nobody's buying them because
there's no stuff specifically supporting them. API standards were the
key to success there (with the exception of glide, of course). The API
you coded for was supported by new cards, and the API incrementally
evolved.

I'm the company's V6 advocate, and like one of our marketers says:
"Where's the value?"

V4 will remain interoperable for some time. Companies will be reluctant
to shift into v6-only address space, if all their _potential_ customers
cannot get at their boxen. The benefit to people currently appears to be
zero, and the cost of change while small is not insignificant.

We need to be able to _show_ value to people. The whole Wintel world
won't move to v6 until their favourite
ftp/telnet/ssh/email/WWW/multicast/unicast/anycast clients can all talk
to it. Not just one application. MANY applications (Everyone's got their
favourites). Bizarre, isn't it, how the whole choice-free Wintel world
hinges on choice?

So, the people we've got to show value to are the developers. Why should
they spare the effort? Are the new socket API's simpler to code for?
(getaddrinfo and friends) _I_ think so. _THEY_ have no idea. Are there
standardizable abstractions we can develop to make them simpler still
for developers who don't have complex communications needs? I think so,
yes. Show someone an API where he can make a connection to a remote host
in two lines of code instead of twenty, and tell him it's a standard,
and he'll go with it, I'm sure. The long-form of the API is there for
folks who need more control. A no-brain API would get things moving.

Herding cats: First get all the cats moving in the same direction.

BIS would get things moving too. Not at the application redevelopment
end (yet), but if you can _SELL_ the benefits of V6, you can make noise
about how much _better_ their app would work with native support instead
of BIS support. Simpler socket APIs couldn't hurt at this point...even
if it was a freeware library. God knows, enough protocols have reference
libraries lurking around. A well-documented, freeware, highly-available,
highly-portable socket library could do it, and you wouldn't need to
call it a 'standard' if doing so hurt any principles.

IMHO: Simple is not enough. Attractive is not enough. Simple and
attractive combined would do it. Face it...we're not salespeople...we're
engineers...but this is really a marketing thing. If V6 gets the right
marketing, people will knock down our doors to find info on converting
their applications, and we could be a V6 world before the end of 2000 (I
really think it's possible).

D

---

From: Dancer <[email-masked]>
Date: Wed, 14 Jul 1999 00:01:59 +1000

1,2,3...agree. But as I was just saying to someone else. We _have_ ipv6.
How do we make people _want_ ipv6? Folks I talk to: Engineers and
network admins, system ops, and network techs either don't know about
it, or don't _want_ to know. Surprised? Most organisations I come into
contact with have one or two folks who know something. They've deployed
a v6 box or two or three inside the company. They (like me) tout and
espouse it's manifold virtues...but the key engineers aren't shifting.
They think, and I'll quote the senior network engineer from our national
phone company, who runs our country's internet backbone: "Yeah, we're
kind of hoping it'll all go away. It will, you know. We'll come up with
other solutions within the existing framework."

And, really, I see all too much of that. My boss (who is actually a
technically savvy sort of fellow for an administrator) about two hours
ago, after I did a presentation: "I don't think it'll catch on. Nobody's
talking about this."

Our network and systems guys: "It'll be ten years or more before even
small-scale changeover, and we'll be with the current IP for the
forseeable future. We don't need to do anything about it."

My co-senior engineer: (groaning and banging his head on the table) "Oh,
no. Another IP to learn. Take it away!"

..and this attitude is more or less prevalent with _most_ groups I speak
to. The backbone operators won't even _start_ an IPv6 deployment (they
say) until IPv4 is shut off. (but that's actually a typical sort of
comment from them. Don't get me started). Assorted ISP's have it set up,
but see no point to it all.

The best thing that's happened in public perception (microscopic though
it has been) in Australia of IPv6 is Peter@Trumpet, who's now made the
national newspapers a couple times. I had a networking buddy call me up
this-evening and ask about IPv6, in gosh-wow terms. His boss is asking,
after having read the papers.

My advice (and it may be poor advice. Who knows?) is to make a little
noise. It worked for Y2K, didn't it? It worked for Java? (I mean every
man and his mouse has a java VM these days, whether they use it or not
and all because it got the press' attention as The Next Big Thing).

IPv6 _is_ The Next Big Thing...but nobody's going to know that unless
their magazines and newspapers and IT-columns say so. And much as we
might want to, few are the bosses who will let us deploy it until then.

(Yeah, I'm a little preachy today. Three V6 presentations fell flat from
studied disinterest. Or perhaps my stunning lack of talent as a
presenter. Either way...interest near zero. People don't want to go)

Keith Moore wrote:
> 
> reasons to deploy IPv6:
> 
> 1. essentially, we are already out of IPv4 addresses.  due to
> inherent inefficiencies in the way v4 addresses are allocated,
> the total number of available addresses isn't 4+ billion, it
> is a few hundred million.  if there aren't already that many
> hosts on the Internet, there will be soon.
> 
> NATs are a best a stopgap measure, as many applications that
> people want to deploy inherently require globally routable
> endpoint addresses, and NATs cannot create more endpoint addresses.
> 
> 2. many new network technologies that are just now starting to be widely
> deployed, including mobile networks, are "always on" and want to support
> applications that are "always on".  this will drastically increase the
> rate of consumption of available v4 addresses.
> 
> 3. for parts of the world which are just starting to get on the
> Internet in a big way, and which will likely deploy very quickly
> rather than incrementally as in the west, there are not enough v4
> addresses to meet their demand.
> 
> ad hoc solutions can will be concocted in an attempt to address
> these problems, but this will create a net which is very restricted
> in the kinds of new applications that can be supported, and also
> one which increases the variety of operating environments with
> which a mass-marketed application must cope.  either way, the market
> for applications in a v4-only world is much smaller  than the market
> in a world that supports v6.
> 
> v4 will be with us for a long time to support legacy apps.  the
> driving forces for v6 will be new networks, new technologies, and
> new applications.  but the rest of the world will want to talk to
> these new networks, technologies, and applications, and that will
> provide incentive for global v6 deployment.
> 
> it's a mistake, however, to think of everything transitioning to v6
> in parallel.  hosts need to support it now, and we need 6to4 or
> something like it to be supported in nat boxes and border routers.
> applications can migrate to v6 as needed.
> 
> Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 13 Jul 1999 08:09:29 -0400

reasons to deploy IPv6:

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 14 Jul 1999 04:10:10 -0400

> other solutions within the existing framework."

I would believe this except that I see people demanding more and more 
application-specific hacks for NATs.  Sooner or later we need a generic
NAT multiplexing and demultiplexing protocol that can be used by large
numbers to reach individual hosts behind a NAT, and IPv6 is the best
candidate for such a protocol.  And naturally I believe that 6to4,
if accepted, can break the deployment logjam because with 6to4 you 
can deploy v6 applications without waiting for the ISPs to support v6.

The "other solutions" are indeed being deployed in the form of NATs but 
these mainly support legacy apps.  There is still considerable market 
demand for applications requiring end-to-end transparency and/or 
global addressing, and we're already pushing the limits of what can be
done with NATs alone without having support in the end-hosts and
applications.  Once we do that, might as well go to v6.

> ago, after I did a presentation: "I don't think it'll catch on. Nobody's

It's still past most folks' horizons.  Also, IPv6 has been oversold
in the past.  In an attempt to make it more attractive its designers
promised lots of new features.  By now, the features are either in 
IPv4 (dhcp, ipsec) or they are untried and therefore somewhat dubious
(renumbering).  

IPv6 is a long-term transition plan, but people tend to gauge whether
something is successful or not by how many people are talking about it
a year after it is announced.  This rationale might make sense for 
commercial products but it doesn't make sense for IPv6.  Still, that's 
the way the market thinks, and we had better learn to deal with it.

This is why it's a bad idea to try to sell IPv6 as a solution to
all of the world's problems, and one that needs to be adopted en masse.  
it needs to be seen as a fix that can be incrementally deployed but 
will allow the net to grow without drastically impeding the kinds of
new applications that the net can support.  And we as engineers need
to make sure we have worked out all of the details on how to make this 
incremental deployment work.

Keith

---

From: Steve Deering <[email-masked]>
Date: Wed, 14 Jul 1999 11:38:48 -0700

Keith,

I agree with most of what you wrote, but I take exception to the
following:

>Also, IPv6 has been oversold in the past. In an attempt to make it 
>more attractive its designers promised lots of new features. By now, 
>the features are either in IPv4 (dhcp, ipsec) or they are untried and 
>therefore somewhat dubious (renumbering).

Its designers have attempted to be scrupulously honest about what it
does and does not do, about which features could also be done in IPv4
(and in what respects they can be done better in IPv6), and about which
features of IPv6 are more speculative.  I believe that much of the
"oversold" perception, especially in the IETF community, in fact arises
from the critics of IPv6, from interactions like the following:

  critic:	If IPv6 doesn't solve the automatic renumbering problem,
		it will be useless.

  designer:	You underestimate the the difficulty of automatic
		renumbering.  We will do what we can to make renumbering
		easier, but we can't promise to make it completely
		painless.  Even if we can't completely solve renumbering,
		IPv6 is not useless, because it solves other critical
		problems.

  <time passes>

  designer:	We have developed mechanisms to support automatic
		renumbering of the IP layer and the DNS, but we are
		still a long way from making renumbering completely
		painless.

  critic:	But you promised to solve the renumbering problem!
		You lied and you failed.  IPv6 is useless!

Repeat the above process, replacing "the automatic renumbering problem"
with other problems that no one knows how to solve, like "the routing
problem", "the multihoming problem", "the QoS problem", etc.

Now this isn't the only source of exaggeration of IPv6's capabilities;
some of it has come from the press doing its normal "simplifying" of
engineers' careful explanations, and some has come from over-enthusiastic
fans of IPv6.  But the accusation that the IPv6 designers ever promised
more than they could deliver is false.

Steve

---

From: Keith Moore <[email-masked]>
Date: Thu, 15 Jul 1999 01:02:07 -0400

> from the critics of IPv6, from interactions like the following:

Steve,

I expect you are correct in your assessment. I did not intend to say
that IPv6 was oversold by its designers.

Keith

---

From: Steve Deering <[email-masked]>
Date: Wed, 14 Jul 1999 22:09:51 -0700

>that IPv6 was oversold by its designers.

In that case, sorry for my misinterpretation.  I'll have to do something
about the sensitivity of that hot button.

Steve