Re: Tunnel-to-NAT scenario

[Alain Durand <alain_durand@cable.comcast.com>]

Brian,

Please note that this work (464pb statement & solution) is taken to
softwires.

  - Alain.


On 6/16/08 9:06 PM, "Brian E Carpenter" <brian.e.carpenter@gmail.com> wrote:

> Alain,
> 
> That's encouraging.
> 
> I think we need a decision at the level of the
> problem statement, however.
> 
>    Brian
> 
> On 2008-06-17 12:21, Alain Durand wrote:
>> Brian,
>> 
>> It appears that the 'crude diagram below' is identical to the latest
>> iteration of 464.
>> 
>>   - Alain.
>> 
>> 
>> On 6/16/08 7:09 PM, "Brian E Carpenter" <brian.e.carpenter@gmail.com> wrote:
>> 
>>> Hi,
>>> 
>>> draft-bagnulo-behave-nat64-00.txt is being discussed
>>> over on the BEHAVE list, and covers the case of an IPv6-only
>>> initiator reaching an IPv4-only server.
>>> 
>>> I believe that we also need to come up with a solution for an
>>> IPv4 initiator reaching a server with IPv6-only connectivity.
>>> My question is whether we can be satisfied with a solution
>>> that requires that server to be dual stack, so that it can
>>> tunnel IPv4 in IPv6 to a conventional IPv4-to-IPv4 NAT.
>>> (Crude diagram below.)
>>> That seems a lot simpler than developing complete MNAT-PT
>>> or SHANTI solutions, which in can case can never really
>>> offer more transparency that conventional NAT.
>>> 
>>> If so, we could incorporate a tunnel-to-NAT scenario in
>>> draft-ietf-v6ops-nat64-pb-statement-req.
>>> 
>>>     Brian
>>> 
>>> +------+-----+-------+          +------+-----+          +-----+------+
>>> |Server|IPv4 |Encaps |__________|Decaps|NAT44|__________|IPv4 |Client|
>>> |      |stack|in IPv6| IPv6 net |      |     | IPv4 net |stack|      |
>>> +------+-----+-------+          +------+-----+          +-----+------+
>>> 
>>> 
>> 
>> 
>>