Subject: Re: myth of the great transition (was US Defense Department formally adopts IPv6)

From: "J. Noel Chiappa" <[email-masked]>
Date: Tue, 17 Jun 2003 08:14:03 -0400

> From: Tim Chown <[email-masked]>

    > But a year ago we didn't have ... Things are moving on.

Got a big stack of these too.

	Noel

---

From: "Peter Ford" <[email-masked]>
Date: Tue, 17 Jun 2003 08:03:39 -0700

If you think of IPv6 as an end to end technology that can gracefully ride on top of the global IPv4 ISP provided infrastructure, you don't have to have the "Internet Infrastructure" transition to IPv6 for a long, long time.  
 
Peer to Peer applications are going to be sufficient to get people to upgrade their "NAT infrastructures" to support IPv6 over IPv4 tunneling.  This is all aided by the plummeting cost of NAT replacement (e.g. < $50, which is a lot cheaper than the early Internet upgrade days of modem replacement for v.34, v.90, cable modem, etc.).    Thus, the tunnel phase of IPv6 is quite viable, and has the FEATURE that you don't need massive shifts/upgrades in public Internet infrastructure.   This is relatively simple to promote to end users as well: your old and new can work together  ...  ( I have observed: not too many end users are into the "management" of their networks.)
 
IPv6 only networks can be created to support closed IPv6-only device networks such as the cell phone networks.  Thus, HUGE networks with application relays/proxies between ipv6 and ipv4 infrastructures will be created where global interop is essential, such as email, web browsing, etc.  The incentives to the cell phone operators are obvious.  One might also observe: the cell phone operators and their suppliers are not keen on building open host platforms for deployment of arbitrary applications and protocols.  This will turn out to be a feature for IPv6 deployment.  Thus, a new breed of ISPs will drive IPv6 deployment in ISP space.
 
Enterprises will be last to go.  Why?  Because in fact they run relatively small networks, and the core value of IPv6 is large addressability.   The extent to which better security is available for IPv6 may be a sufficient draw for many companies, but not all.  Thus, the current "revenue champion" for networking will not be the early revenue driver for IPv6 as we have seen for routers and ethernet switches.  Since enterprise also drives a huge amount of ISP deployments, I would not expect the current ISPs to be the first to transition to, or augment with, IPv6.
 
The transition will occur based on technologies and deployments as  discussed and planned in the IETF oh so long ago.   Much like it took the world many, many years to realize the value of transitioning to IPv4 in the first place, transition to a new infrastructure protocol is going to take a long time.   IPv6 was created for a world with tons and tons of hosts and devices.  That time is almost here, so it is only now that IPv6 deployment is going to be economically relevant and viable.  Pushing in front of this time horizon is good for getting the deployment issues worked out, but people can't expect that just because the technology is good to go, that it will just go.
 
regards,
 
peterf
 
P.S.   The IETF might want to spend more time working on topics germane to the cell phone industry. Not that IPv6 hasn't taken a lot of time ... :-)

---

From: "Christian Huitema" <[email-masked]>
Date: Tue, 17 Jun 2003 08:17:11 -0700

> % > If you want to keep running IPv4, with or without NAT,
> % > feel free.
> %
> % That's exactly what people will do, until and unless they encounter
a
> % problem with IPv4 that can only be solved by IPv6.
> 
> 	Your sweeping generalization does not ring true.
> 
> 	However with a willing suspension of disbelief, this
> 	might be why the DoD has decided to adopt IPv6.
> 	It wants to do things that can't be done w/ IPv4.
> 	And the IETF should be excited that someone is actually
> 	considering adopting an IETF work product.

It's amusing how a relatively minor DoD pronouncement can generate so
much argument on the IETF list. What the DoD announcement boils down to
is a requirement that new products bought by the DoS be IPv6 capable.
Guess what? Most of the products bought by the DoD today are already
IPv6 capable. In fact, it is probably that very observation that caused
the DoD to issue such requirement with confidence. This is not really a
watershed event, but it is also definitely a push for IPv6 deployment --
after all, the DoD is not putting a press release saying that it will
wait another 10 years before considering IPv6.

Now, I certainly share a lot of the concerns that were expressed by Noel
and others. Those who rely on governments for pushing a technology have
seldom been rewarded with success. I remember the time when we could not
get a European research funded unless it mentioned ATM... 

IPv6 will be deployed if it solves at least some of the current problems
with IPv4, and if applications get written that take advantage of the
way IPv6 solves these problems. I personally believe so, and I am busy
enabling application writers doing that. We shall see...

-- Christian Huitema

---

From: "Michel Py" <[email-masked]>
Date: Tue, 17 Jun 2003 11:09:55 -0700

Phill,

> Hallam-Baker, Phillip
> Simply repeating the end to end dogma is not going to provide
> a solution. The internet people are using is not end to end.
> NAT boxes and firewalls play an important and necessary
> security role. We need a standard for a superNAT box that
> provides both security and protocol bridging functions.

This is a politically courageous post but I'm afraid that the end-to-end
dogma _is_ the IETF. WRT IPv6, the pragmatic point of view of doing
something along the lines of what you proposed is that it will raise so
much opposition that it will go nowhere, so why bother in the first
place?

Michel.

---

From: "Christian Huitema" <[email-masked]>
Date: Wed, 18 Jun 2003 08:26:12 -0700

> At the start of the GOSIP nonsense, that might have been a reasonable
> charge.  By the middle, there were at least as many ISO OSI
> applications as there are now IPv6 applications, and there was a
> lot of real OSI traffic in Europe.  (A "lot" for that era if not
> today.)  Major host vendors were supporting OSI protocols by the
> end of GOSIP as well as they are now supporting IPv6.  OSI support
> was a required checklist item in a lot of sales situations.

Well, you have to seriously qualify what you call "a lot". The only
non-TCP-IP network service that got widely deployed in Europe was X.25.
Most of its use was not strictly OSI: asynchronous modem connections
according to X.28 and X.29, or enterprise networks using X.25 as a lease
line replacement, much like modern-day VPN. Some of that is still in use
today, e.g. for the French "Minitel" service.

The only OSI service that had significant deployment was the mail
system, X.400. It was used for some research networks, very often
through gateways with SMTP mail. It was also used for exchange of
documents between enterprises in specialized EDI networks.

An aggravating factor in the GOSIP story was the lack of agreement on
the network + transport stack. The US proposed the IP-like CLNP and the
TCP-like TP4, the European X.400 deployments mostly used X.25 and TP0
(null transport), and ECMA was pushing a null network layer combined
with TP4 for European enterprise networks. 

The academics who were using X.400 and experimenting with X.500 quickly
moved to a combination of TCP-IP and TP0 (RFC 987, RFC 1006), because
TCP-IP was more accessible than either X.25 or CLNP. Most X.400 MTA used
in academic networks where dual stack, i.e. able to translate between
X.400 and RFC 822, and most of the traffic moved quickly to plain SMTP.
Similarly, the X.500 experiments resulted in LDAP, i.e. a TCP-IP
application.

Bottom line, there never was a significant usage of CLNP in Europe.

-- Christian Huitema

---

From: "Michel Py" <[email-masked]>
Date: Mon, 23 Jun 2003 15:05:49 -0700

Jonathan,

> Jonathan Hogg wrote:
> Aren't Microsoft already "standardizing" this with their Universal
> Plug and Play (UPnP) architecture?
> I'm a little fuzzy on the details, but I believe the concept is
> that applications that understand this can communicate with the
> router (the NAPT box in the case of SoHo networks) and request
> ports to be opened externally and forwarded back to the host. I
> think Microsoft's NetMeeting conferencing program supports this
> already and there are a few ADSL modem/routers that implement it.

That is the little my feeble understanding of it has grasped too.
However, I still don't fully understand how it resolves the problem of
originated-from-the-outside connections: Let's say there are 3 web
servers in the inside, all three talk to the NAPT box and all three have
the NAPT box open a translation port. The part I don't get is where the
NAPT box chooses which one of the three gets the traffic without
something like decapsulating the http header.

Michel.