Re: Follow-up work on NAT-PT

[briand@ca.afilias.info]

Margaret wrote (very concisely, I might add):

> Exactly what types of operational problems exist that we need to
> solve?  Why aren't the existing v4/v6 transition mechanisms
> sufficient to resolve those problems?  Where are the gaps that needs
> to be filled?

Here are what I perceive (not just personally, but from a variety of
input e.g. at NANOG, ARIN meetings in ABQ):

1) IPv4 access of *some* flavor from end-networks when end networks no
longer have the ability to get their own IPv4 space (which precludes use
of public IPv4 in a dual-stack environment)
2) Support for (1) from a large ISP perspective when the end-user or
end-network connectivity is not dual-stack
3) Support for all of the above when the end nodes number greater than the
number of IPs available under RFC 1918 (i.e. more IPs than one instance of
all private addresses can cover)

What is *not* needed, IMHO, is any-any IPv4 over the above connection
requirments, e.g. the presumption is any two boxes above will be able to
see each other via IPv6 directly, so P2P stuff should work okay, and the
existing techniques for v4-only apps via private p2p ad-hoc ipv4 over ipv6
tunnels should be presumed to work fine.

The presumption should be:
clients accessing servers, where servers are IPv4, and clients are ipv6,
and the predominant component of the access side of the clients, including
possibly their ISP, and even their ISP's ISP, is v6 only.

(Please see my reply to Brian Carpenters query, several days ago, I will
flesh it out some more, but IPv4-IPv6-IPv4-IPv4NAT-(Internet-v4) with PT,
may be an ugly hack with good scaling characteristics and the ability to
do port-specific ALGs in a way that allows ISP/ISP support for ALGs, i.e.
very attractive scaling characteristics.

Brian D

> I really have no doubt that we could build a purer, cooler, "better"
> version of NAT-PT.  In fact, I even have my own thoughts on how we
> could do that.  But without understanding exactly what problem(s) we
> are trying to solve, I don't think that will be a very useful exercise.
>
> Margaret
>
>
> On Oct 28, 2007, at 7:48 PM, Brian E Carpenter wrote:
>
>> On 2007-10-14 06:28, Jari Arkko wrote:
>>> Thanks for this, Olaf. Indeed, we are considering follow-up work,
>>> and understanding the scenarios & possible need for producing
>>> a revised version of NAT-PT is on the Vancouver agenda (currently
>>> planned to be a discussion in V6OPS, with protocol work to fall
>>> out to an INT area WG).
>>
>> I realise this may be jumping the gun a bit, but since I won't be
>> in Vancouver, here is a sketch of one possible direction.
>>
>>     Brian
>>
>> -------- Original Message --------
>> Subject: I-D Action:draft-carpenter-shanti-00.txt
>> Date: Sun, 28 Oct 2007 18:20:01 -0400
>> From: Internet-Drafts@ietf.org
>> Reply-To: internet-drafts@ietf.org
>> To: i-d-announce@ietf.org
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>> 	Title           : Shimmed IPv4/IPv6 Address Network Translation
>> Interface (SHANTI)
>> 	Author(s)       : B. Carpenter
>> 	Filename        : draft-carpenter-shanti-00.txt
>> 	Pages           : 12
>> 	Date            : 2007-10-28
>>
>> There is a pragmatic need for a packet-level translation mechanism
>> between IPv4 and IPv6, for scenarios where no other mode of IPv4 to
>> IPv6 interworking is possible.  The mechanism defined here uses a
>> shim in both the translator and the IPv6 host to mitigate the
>> problems introduced by stateless translation.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-carpenter-shanti-00.txt
>>
>
>
>