ietf
[Top] [All Lists]

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

2000-04-25 14:50:02
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.

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.

    >> 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.

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.
 
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.

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.

    > 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 

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.

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?

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