Subject: about the coexistance scenarios in draft-ietf-v6ops-nat64-pb-statement-req-01

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 25 Jul 2008 16:48:15 +0200

Hi Teemu,

I am trying to intergrate the text you proposed to the draft 
draft-ietf-v6ops-nat64-pb-statement-req-01

the last text we come up with was:

to add a new scenario:

   o  a dual stack system connected to a IPv6 domain that is connecting
      to an IPv4 system.

and to add new text in the tunnel section:

   Another scenario that does not involves translation is the case where
   a dual stack node is connected to an IPv6-only domain and it is
   communicating with a IPv4-only node as depicted in Figure 2.

                                             ,-----.                 ,-----.
                                           ,'       `.             ,'       `.
                                          /           \           /           \
                                         /   IPv6-only \         /   IPv4-only \
                                        /    Domain   +-----------+  Domain     \
                                       ;              |    Tunnel |              :
                                       |              |  endpoint |              |
                                       :     +-----+  +-----------+              ;
                                        \    |Dual |    /       \     +----+    /
                                         \   |Stack|   /         \    |IPv4|   /
                                          \  |Host |  /           \   |Host|  /
                                           `.+-----+,'             `. +----+,'
                                             '-----'                 '-----'

         Figure 2: Dual stack with IPv4 application in IPv6 domain

   In this case, the dual stack host needs to establish a IPv4 in IPv6
   tunnel to the tunnel endpoint.  In addition to that, the dual stack
   needs to obtain a IPv4 address that is valid in the IPv4-only domain.
   The simplest option is for the dual stack to obtain an IPv4 public
   address.  However, this may not be possible due to the shortage of
   IPv4 public addresses.  The other option is to use an IPv4 private
   address (and potentially in conjunction with IPv4 NAT).  The other
   option is for the dual stack to obtain one or more public IPv4
   transport addresses.  In all the cases, the acquisition of the
   address can be performed dynamically.

the problem that i find is that the scenario described above is simply 
too broad to what we mean here.
I think that something you mentioned in your original mail got lost in 
the way, basically that this scenario is about dual stack hosts running 
v4 only apps that are nat aware, that is the main reason why you need 
them to learn the v4 public address. Dan mentioned that for instance 
bittorrent is in this situation.

So, i think we need to express this somehow.
I think that the scenario that we are handling now is

   o  a dual stack system with a NAT-aware IPv4-only application connected to a IPv6 domain that is connecting
      to an IPv4 system.

Now, i am wondering if this is not a bit too far off the simple scenario 

Regards, marcelo

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 27 Jul 2008 22:50:22 +0100

>  o  a dual stack system connected to a IPv6 domain that is connecting

Point of terminology:

Could we please all agree on what "dual stack" means?

The way I've always used the term is "a system that has both IPv4 and  
IPv6 connectivity, which is global in nature unless explicitly stated  
that it's only local or site-local". However, the above seems to use  
it in the sense "a system that is capable of using both IPv4 and IPv6".

The set of systems conforming to the former definition is obviously a  
subset of those conforming to the latter.

I contend that in 99% of all our discussions, it's useless to make the  
distinction between systems that have certain reachability for  
operational reasons and systems that have certain reachability because  
they don't support both IP versions. Using my definition of "dual  
stack" avoid wasting time in that 99% of cases.

Note also that the use case cited above is based on an unstated  
assumption, which is that if a host supports the second definition of  
dual stack, it must therefore be connected to the IPv4 internet.

The situation we want to reach is where hosts can have just IPv6  
connectivity and still be fully functional.

---

From: <[email-masked]>
Date: Mon, 28 Jul 2008 09:52:41 +0300

>The situation we want to reach is where hosts can have just 
>IPv6 connectivity and still be fully functional.

Assuming all applications are supporting IPv6, or also including cases
where host may be running IPv4-only apps?

What I'm wondering is that if a translation solution is designed to
assume fully IPv6-capable host (including all random third party
softwares), then it might be less usable in near future than tunneling
based solutions. I mean if for v4-only applications host needs to anyway
find a way to provide IPv4-connectivity, for what purpose it would need
translation services? For IPv6-only applications? I would assume it
takes quite a while before all applications are IPv6-capable, and that
all devices behind a host (such as gaming consoles etc) are also
IPv6-capable.

Or can we assume applications to be IPv6-capable in timeframe operator
would be interested to provide IPv6-only connectivity?

Or should a host internally implement v4->v6 translation, thus making a
host look like fully IPv6-capable towards network?

	Teemu

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 28 Jul 2008 19:00:10 +0100

On 28 jul 2008, at 7:52, <[email-masked]> <[email-masked] 
 > wrote:

> where host may be running IPv4-only apps?

Well obviously we don't want to support IPv4-only apps until the end  
of time.

But we will have to in the short term.

> based solutions.

If the host knows the prefix for the translator, it can easily  
internally make IPv4 API calls create IPv6 packets that will be  
translated to IPv4 by the remote translator. One approach is to simply  
create IPv4 packets and encapsulate those in IPv6, but the extra IPv4  
header provides no actual functionality so we can probably optimize it  
away without too much trouble. So the NAT464 translation scenario and  
the dual stack light scenario are pretty much the same thing.

In the case of a CPE handling internal hosts that actually create IPv4  
packets the tradeoff between encapsulation and translation may be  
somewhat different.

> for what purpose it would need

Don't forget that higher level APIs hide the differences between IPv4  
and IPv6, so very many applications can work over IPv6 without having  
specifically be designed to do so.

> would be interested to provide IPv6-only connectivity?

I'm not familiar with cellular operations, but I would assume that  
running IPv4 and IPv6 over the cellular network concurrently is far  
from ideal, just providing IPv6 and then use an IP layer mechanism to  
let the applications talk to the IP world would be helpful.

> host look like fully IPv6-capable towards network?

I think in many cases that makes sense, yes.