In an IPv6 future, how will you solve IPv4 connectivity?

[Ted Mittelstaedt]

On 10/11/2010 12:56 PM, Erik Kline wrote:
> On 11 October 2010 09:49, Ted Mittelstaedt<tedm at ipinc.net>  wrote:
>> On 10/10/2010 11:42 PM, marcelo bagnulo braun wrote:
>>>
>>> El 11/10/10 7:15, Ted Mittelstaedt escribió:
>>>>
>>>>
>>>> I really see very little point in fielding a proxy server that will
>>>> allow a IPv6-only customer to surf the IPv4 Internet - if they can
>>>> do IPv6 then they can dual-stack. I may do this though if we have
>>>> early adopters that demand IPv6 only.
>>>>
>>> Right, the requests of some of these early adopters was what triggered
>>> the work on NAT64 on the IETF.
>>> The rationale, as i understood it, is that they don't want to have to
>>> pay the cost of managing both a v4 and a v6 network.
>>>
>>
>> That is the same logic that Novell used to try to push that silly product of
>> theirs that allowed you to run a "pure IPX" network.  It
>> didn't last, and neither will NAT64 if that is the rationale behind
>> selling it.
>
> As someone who attended the interim IPv6 IETF meeting in Montreal in
> October 2008 where much of this was discussed, I can say that my
> motivation was more about enabling IPv6-only networks to be deployed
> without having to pay an IPv4 deployment tax.  I felt it was important
> for an organization to be able to move forward and deploy an all IPv6
> network if it wanted, and only worry about the translation to IPv4 at
> the edge, to the extent practical, similar to most (non-residential,
> and I suppose non-colo) IPv4 deployments today.
>
> You seem to be drawing an analogy between IPv6 and IPX.

Correct.  NAT44 is very established, no vendor that produces network 
software for use on the Internet today can afford to ignore it and
not test their products with all manner of NAT44 implementations.

NAT64 is entirely different and if software vendors don't test, there
will be problems.

I think that a lot of people don't understand just how much hacky
code is in a NAT44 implementation.  It's not just flipping bits around
in the header to change numbers.  The good NAT implementations have a 
large number of subroutines for different applications and reach deep 
into the payloads to flip bits around on some of them.  All that has
to be duplicated for a NAT64 implementation and it remains to be seen
how well leveraging an existing NAT44 engine into doing this will work
out.

NAT of any kind ought to send most knowledgeable admins running away!!!

Ted

I suppose
> only time will tell.
>