Subject: Re: draft-ietf-nat-protocol-complications-02.txt

From: "J. Noel Chiappa" <[email-masked]>
Date: Tue, 25 Apr 2000 15:42:31 -0400

> From: Keith Moore <[email-masked]>

IPv6's claimed big advantage - a bigger address space - turns out not to be an
advantage at all - at least in any stage much short of completely deployment.

IPv6 deployment is going to have to be driven by IPv6's *other* features, and
when you take bigger addresses out of the cost/benefit ration, I'm even more
dubious that the features that are left (autoconfiguration, etc) outweigh all
the costs and risks of IPv6 conversion.

It seems that you can postulate whatever level of IPv6 deployment you like (a
long stretch in itself, but just for the sake of argument, let's make it) -
5%, 10%, whatever - and there's still no mechanism to drive further
deployment.

Here's why:

    >> if you have a site which has more hosts than it can get external IPv4
    >> addresses for, then as long as there are considerable numbers of IPv4
    >> hosts a site needs to interoperate with, *deploying IPv6 internally to
    >> the site does the site basically no good at all*.

    > I do think that the main incentive to deploy v6 will come from the need
    > to communicate with global addresses to points *outside* of folks'
    > internal networks.

Huh?

If those outside sites are running IPv4, deployment of IPv6 does the people
who deployed it basically no good at all over IPv4 NAT - because the
fundamental problem (of not having enough external addresses) is the same,
regardless of whether the internal protocol is IPv4 or IPv6.

Thus, the problems caused by that limitation (many of which you so well
articulated in a previous message, such as the need to go through a
rendezvous to set up translation state) will also be the same, regardless of
whether the internal protocol is IPv4 or IPv6.

    > deploying IPv6 internally .. will of course do some good if the site
    > has applications on internal hosts that need to communicate with
    > external hosts using global addresses. if you're .. point [is] that
    > there's little purpose in having your own IPv6 island

Deployment won't do any good if the people it's trying to communicate with
externally are running IPv4 - and I *don't* include only the cases where
there's a local island of IPv6. Here's the logic:

As long as a substantial portion of the Internet is running IPv4 only, any
site is going to have to have some mechanism to communicate with the IPv4
portion of the Internet. It may not be quite as good as native IPv6-IPv6 -
*but it has to be OK, or the company is toast*. As an important corollary,
there may be an incremental improvement in functionality with a pure
IPv6<->IPv6 mode, but that increment is inevitably going to be minimal.

And my new point is that whether the site is running IPv4 or IPv6 internally,
it won't make any big difference to how well that IPv4 interoperation
mechanism operates, since the fundamental problem is the same.

So, if i) a company has an acceptable mechanism to interoperate, ii) they
won't see any big improvement from IPv6<->IPv6 operation, and iii) there's no
advantage in the IPv4 ineroperation mechanism to be gained by deployment of
IPv6 internally - then where's the incentive to deploy?

	Noel

---

From: Keith Moore <[email-masked]>
Date: Tue, 25 Apr 2000 16:18:47 -0400

> advantage at all - at least in any stage much short of completely deployment.

that's an exaggeration.  if you have an app that needs IPv6, you don't 
need complete deployment of IPv6 throughout the whole network to use
that app.  you just need for the hosts that want to support that app 
to have IPv6 (on many hosts the IPv6 stack can be installed at the 
same time as the app itself), and you need a way to route IPv6 packets 
between those hosts.  

and as long as a site has one external public IPv4 address, 6to4 and 
6over4 go a long way toward providing the ability for all of the 
internal hosts at that site to run IPv6 if their local stack supports it.

of course, if the backbone supports v6 natively, that's a nice optimization.

> regardless of whether the internal protocol is IPv4 or IPv6.

I don't see what you're getting at.  the outside sites may be running v4 
with a limited number of external addresses - not enough addresses for 
each host.  but if they are running v6 they will have plenty of external 
addresses.
 
> whether the internal protocol is IPv4 or IPv6.

with 6to4 the mapping is algorithmic so there's no need to go through
a rendezvous, or do a network query, to set up translation state.

> externally are running IPv4 

if the remote sites are *only* running IPv4, having v6 locally won't help
much.  but the fact that they're running v4 makes it easy for them to
bootstrap to v6 by using 6to4.

but it's generally true that if you're talking between a v6-only and 
v4-only host you have to accept the limitations of NAT.

> IPv6 internally - then where's the incentive to deploy?

as I see it the incentives to deploy v6 include the following:

a) ability to run applications that won't work over IPv4 in practice
   due to a shortage of addresses and the resulting inability to
   use addresses as connection endpoint identifiers; ability to
   write distributed apps that scale better than hub-and-spoke apps.
   (distributed games, conferencing systems, instant messaging,
    high performance distributed computations)

b) ability to deploy new networks which can directly address large
   numbers of devices, where this would be infeasible using IPv4
   (might include traditional Internet in emerging areas of the globe,
   IP-enabled cellphones and mobile devices, and new networks intended 
   to support instrumentation/telemetery - e.g. monitoring of power meters)

c) ability to individually and remotely address every device in a 
   network which is currently accessible only via a NAT or not at all -
   i.e. change a NAT-based client-only LAN into a LAN which can 
   potentially support client and/or server operation from every host.
   doing this gives you the ability to support new applications
   or support existing applications more efficiently
   (internet phone, fax to the desktop, instant messaging, etc.);
   it also allows you to do new things with your network
   (e.g. for home networks; be able to program or diagnose your vcr 
   remotely) 

d) ability to communicate with the new networks in (c) and (d)
   from the rest of the Internet.

e) ability to deploy new applications without installing a new ALG
   in the NAT....6to4 becomes the universal ALG.

if the Internet were going to stay just like it is today -
email and web - there would be no need to deploy v6.  but the
Internet won't stay like it is today.  there are too many
useful things that can be done with the Internet (and
lots of money to be made in the process) if it had the ability to 
directly address every host.  so people are going to provide that
ability, and the most obvious way to do it is to use IPv6.

Keith

---

From: Thomas Narten <[email-masked]>
Date: Wed, 26 Apr 2000 09:32:45 -0400

> IPv6's claimed big advantage - a bigger address space - turns out
> not to be an advantage at all - at least in any stage much short of
> completely deployment.

Not surprisingly, I disagree.

>     >> the site does the site basically no good at all*.

Actually, in the above scenario, NAT is already a requirement for IPv4
communication with the outside world. So, if you switch to IPv6
internally, use IPv6-IPv4 NATPT (i.e., combination of NAT and IPv6 to
IPv4 translation) you have pretty much the same
functionality/limitation as with IPv4 NAT.

Now, consider someone in the process of deploying massive numbers of
devices (100's of millions) together with the infrastructure to
support them (e.g., wireless). With IPv4, they face not only the
necessity of using NAT to get to outside destinations, but also the
use of NAT _internally_ because there isn't enough private address
space to properly number the internal part of the infrastructure.

In this scenario, IPv6 internally at least gives them end-to-end ness
internally (plus scalability, more robustness, etc., etc.), something
the can't get with IPv4. And it gives them the same set of
issues/headaches when talking to the outside world that they would
have if just using IPv4.

I don't know about you, but it scares me to read the various forecasts
about how wireless will transform the landscape over the next few
years. E.g., more wireless phones with internet connectivity than
PCs. The numbers are just staggering and the associated demand for
addresses will be astonishing. We ain't seen nothing yet.

Thomas

---

From: Jon Crowcroft <[email-masked]>
Date: Wed, 26 Apr 2000 15:43:54 +0100

>>Not surprisingly, I disagree.

right, noels wrong.

the amount of address translation
state you have to keep (and syncronise between failover NATs etc)
 per active session decreases as
the percentage of hosts that are native IPv6 increases, 
(and obviously also
decreases as the absolute number of hosts increases but new hosts
are all v6) - in your scenario (a likely wireless 3G deployment one,
this could happen pretty fast

the amount of disconnect the v4 legacy machines will see because the
state maintenance will fail (as any large system does partially, ALL THE TIME),
will increase, and possibly quite fast...routing state is already in a
bad enough state....without adding address translation state to it...

NATs are not only bad e2e karma, they are bad tech, just like x.25 and atm.

 >>addresses will be astonishing. We ain't seen nothing yet.

 cheers

   jon

---

From: "Brijesh Kumar" <[email-masked]>
Date: Wed, 26 Apr 2000 12:45:07 -0400

In his previous mail, Thomas Narten writes:

> addresses will be astonishing. We ain't seen nothing yet.

The basic assumptions in your answer are:

1) wireless devices will need an IP address.
2) Wireless devices will need to run TCP over IP for doing file transfer,
web browsing etc.

These are neither necessary, nor desirable solutions for wireless data
or voice devices providing data. Most end user don't care whether their 
wireless email comes using an IP address or using a GSM ID or a Re-FLEX 
capcode. Wireless standards folks, if they want, can continue to keep NAT 
and IPv6 addresses away from end wireless devices.

Cheers,

--brijesh
Ennovate Networks Inc.,

---

From: Matt Holdrege <[email-masked]>
Date: Wed, 26 Apr 2000 10:07:29 -0700

>addresses will be astonishing. We ain't seen nothing yet.

It seems to be a given now that 3G phones will be IPv6 (at least outside 
the U.S.) when they roll out over the next few years. But we should make 
people clearly aware of what to expect when they NAT their way back to the 
IPv4 Internet or IPv4 intranets. That is one of the purposes of this draft. 
(oh yeah, this thread is supposed to be about contributing to the draft in 
the subject line)

---

From: "Eliot Lear" <[email-masked]>
Date: Wed, 26 Apr 2000 10:41:54 -0700

Thomas,

I think you're actually both right.

Noel's comment was meant as a general case for even a very large
enterprise.  You provided a counterexample of some number of providers that
will need huge amounts of address space.  Much as I dislike NAT I believe
it's an unproven assertion that those providers won't find a way to molest
the architecture further to make it work.  Really all that is required is
some small percentage of public addresses, based on usage patterns.  Any
Bell Heads want to take a stab at that percentage?

My hope is, however, that a NAT deployment would be 6-4, so that they could
at least have the pipe dream that those NATs might some day become
unnecessary.

Also, many people have made claims of grand visions when it comes to usage
of address space, and these grand visions have been rebutted with "it
hasn't happened yet."  In some cases it hasn't happened because it couldn't
happen.  Fred tells the story of China.  I can tell the story of a cable
provider, back in 1993, who were planning a large scale Cable-IP
deployment.  They were ahead of their time, but not by that much.

Eliot

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 30 Apr 2000 14:53:32 +0859 ()

Matt;

> (oh yeah, this thread is supposed to be about contributing to the draft in 

The reality is that mobile phones are using non-IP protocols.

If you use NAT, you have no reason to use IP.

In Japan, there are more than 5 million non-IP mobile WWW browsers
served by a single application gateway.

							Masataka Ohta

---

From: "vinton g. cerf" <[email-masked]>
Date: Sun, 30 Apr 2000 06:20:48 -0400

that's right - they use iMODE on the DOCOMO mobiles. iMODE and
WAP seem to have that in common: a non-IP radio link protocol
and an application gateway. Of course, this limits the applications
to those that can be "translated" in the gateway, while an end to
end system (such as the Ricochet from Metricom) would allow 
essentially any application on an Internet server to interact
directly with the mobile device because the gateway would merely
be an IP level device, possibly with NAT functionality.
With a JAVA interpreter or other similar capability in the
mobile, one could imagine considerable competition for development
of new applications. As it stands, only the applications NTT
chooses to implement in the translating gateway are accessible.

Since HTTP is one of the "applications" served, there is still
a lot of room for competition, I suppose.

vint

>served by a single application gateway.

=================================================================
I moved to a new MCI WorldCom facility on Nov 11, 1999

MCI WorldCom
22001 Loudoun County Parkway
Building F2, Room 4115, ATTN: Vint Cerf
Ashburn, VA 20147
Telephone (703) 886-1690
FAX (703) 886-0047

"INTERNET IS FOR EVERYONE!" 
See you at INET2000, Yokohama, Japan July 18-21, 2000
http://www.isoc.org/inet2000