Re: IPv6 only host NAT64 requirements?

[Ole Troan <[e-mail]>]

Philip,

>> Yes, that's certainly the bind we are in. Are we going to require all
>> IPv6 only nodes to be able to communicate with IPv4? And what does that
>> entail? Do you have examples of "all kinds of IPv4 issues"?
>> 
>> Apart from the requirement of NAT64 prefix discovery and IPv4
>> synthesising, is there anything you don't need to do anyway?
> 
> One that really breaks my code, and is relevant to 6man is the guarantee in
> IPv6 error ICMPs:
> 
> (c) Every ICMPv6 error message (type < 128) MUST include as much of
>    the IPv6 offending (invoking) packet (the packet that caused the
>    error) as possible without making the error message packet exceed
>    the minimum IPv6 MTU

Right. But when is that an actual issue for applications?
(Where I'm not going to reply with, well ICMPv6 errors a) either don't make it there b) are ignored by the host stack / application c) are heavily throttled d) suffered that faith anyway because of some MPLS link or whatnot...) :-)

>> While I'm also concerned about the consequences of carrying IPv4 debt in
>> all IPv6 implementations, the alternative seems to be that we are stuck
>> with Dual stack forever (for some definition of forever). This would at
>> least allow us to move to single stack IPv6. Which appears to me to be a
>> step forward. And we're very close to that already, and there are
>> millions of devices already implementing it.
> 
> In new applications that are simple from a networking point of view, it should
> be possible to come up with a design that works well for both dual stack and
> NAT64.
> 
> Operators who have lots of legacy devices are likely to run a dual stack
> network. So hosts that are expected to work in such an environment have to
> implement dual stack.
> 
> I'm not sure how (outside 3GPP) anyone can transition to NAT64. You have to
> make sure that all devices that need to connect support NAT64. To do that,
> you probably want to run dual stack for a while to make sure everything
> supports IPv6 properly.
> 
> But for host software there is a lot more incentive to support dual stack then
> to do the extra step for NAT64.
> 
> The big problem I see for NAT64 is that for old IPv4-only applications you
> have to make two fundamental changes to the application. The first to
> make sure that the application handles IPv6 in every possible way. And a
> second pass that makes sure that every place where an IPv4 address literal
> is handled, works with NAT64.
> 
> For an application writer it is better to try to avoid doing the second pass.

Then we are stuck with dual stack.
What Randy and Jen set out to try in the IETF experiment was to figure out if it would be possible to do IPv6 only + NAT64. Identify what was broken and then get that fixed. If we're stuck with dual stack (or IPv4 only), then we're not moving towards the end-goal, are we?

Ole