[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Tunnel-to-NAT scenario
- To: IPv6 Operations <v6ops@ops.ietf.org>
- Subject: Tunnel-to-NAT scenario
- From: Brian E Carpenter <brian.e.carpenter@gmail.com>
- Date: Tue, 17 Jun 2008 11:09:11 +1200
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; b=QZc0nDRIC12dv0omL1nfrY+2D94wITfLdir6irCIBja+WlRtuknPtxh64wj20YaZJ6 sLRtbyquCFE7kXSqGbyjF51ENJ47Wnu7uokoXrqLorm1oYUq+3UAJC5eS2IDORR2uU4u Q7uHoTJZoVrTHVdj0mRBeHWEuO/d22JctZIXk=
- Organization: University of Auckland
- User-agent: Thunderbird 2.0.0.6 (Windows/20070728)
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| |
+------+-----+-------+ +------+-----+ +-----+------+