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

[Iljitsch van Beijnum <[e-mail]>]

On 28 jul 2008, at 7:52, <[e-mail]> <[e-mail] 
 > wrote:

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

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.

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

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

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.

> Or can we assume applications to be IPv6-capable in timeframe operator
> 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.

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

I think in many cases that makes sense, yes.