Re: [v6ops] draft-ietf-v6ops-icp-guidance WGLC

[Mark ZZZ Smith <[e-mail]>]

Hi Gert,


----- Original Message -----
> From: Gert Doering <[e-mail]>
> To: Mark ZZZ Smith <[e-mail]>
> Cc: Fred Baker (fred) <[e-mail]>; "[e-mail]" <[e-mail]>; V6ops Chairs <[e-mail]>; Ron Bonica <[e-mail]>
> Sent: Tuesday, 7 August 2012 10:11 PM
> Subject: Re: [v6ops] draft-ietf-v6ops-icp-guidance WGLC
> 
> Hi,
> 
> On Tue, Aug 07, 2012 at 02:24:58AM -0700, Mark ZZZ Smith wrote:
>>  As for usefulness to it's target audience, I think it will be
>>  very useful, as perhaps it may have prevented the following ICP
>>  choosing to deploy an IPv6 only production network and then completely
>>  misusing NAT64 to try to provide IPv4 and IPv6 client facing services.
> 
> So how exactly would that be "misuse"?
> 
> It's quite reasonable to run single-stack inside, and if you need lots

> of addresses, make that IPv6-only.  The outside needs to be dual-stacked,
> and NAT64 (with preconfigured mappings) will do that for you, in a 
> nice and stateless way.
> 

I think when you use something outside of the scenario it was designed for, there is a risk that things won't work well.

According to RFC6145, 

   This document describes stateful NAT64 translation, which allows
   IPv6-only clients to contact IPv4 servers using unicast UDP, TCP, or
   ICMP.  One or more public IPv4 addresses assigned to a NAT64
   translator are shared among several IPv6-only clients.  When stateful
   NAT64 is used in conjunction with DNS64, no changes are usually
   required in the IPv6 client or the IPv4 server.

So NAT64 wasn't designed for a scenario where IPv4-only clients contact IPv6 servers. That's not to say it won't work, but it may not work well, and with their very general conclusion that "IPv6 is hard" (and plenty of people's experience is that it isn't anywhere near as hard as their story suggests), it didn't work well for them. That says to me that they weren't using the right tool for the job. They were misusing the tool by choosing the wrong one.

I think they developed or were given false expectations of what NAT64 would do for them, and that is where they were let down. Unfortunately some brief Internet searching on deployment choices or advice, or even an email to the mailing list they posted their story to, asking people's advice, would probably have saved them a lot of grief. This draft should hopefully prevent those sorts of false expectations, and false conclusions about how hard or not IPv6 is deploy in the future.

Regards,
Mark.