[ipv6-wg] Implications of NAT/NAT64 and similar (was: Re: IPv6 only as default for next meeting)

On 15-May-2015 02:25 am, Benedikt Stockebrand <bs at stepladder-it.com> wrote:
> 
> Hi folks,
> 
> this is admittedly a pet peeve of mine, so apologies right in advance
> to anybody getting offended by this, but I'd like to rephrase 
> 
> "Marc Blanchet" <marc.blanchet at viagenie.ca> writes:
> 
>> I think the technology (v6only-nat64-dns64) is mature enough. The
>> problem is that various applications and services are not compatible
>> with it (usually IPv4 addresses negotiated in the payload)
> 
> as this: 
> 
>    I think the technology (v6only-nat64-dns64) is inherently broken by
>    design.  By design it doesn't support a range of important and
>    widely used existing applications and services that it should be
>    compatible with to be considered "working".
> 
> With NAT, NAT64 or whatever other application unaware translation hack
> being around, a lot of extra complexity is pushed towards the
> application layer.  NAT* doesn't solve any problems, it just puts the
> burden on others who is unlikely in a situation to defend themselves
> (the app. developers) ; the overall effect is counterproductive.
> 
> Aside from that, once we talk not full-blown computers but embedded
> devices, adding support for NAT penetration (STUN or whatever) is a
> major problem.  The original Arduino uses a microcontroller with 32KB
> of flash (for program code) and 2KB of RAM, and that's already a fairly
> big one.  Adding STUN support there is a serious problem.
> 
> 
> Again, this isn't meant as a flame or anything, but to show that
> these technologies have serious implications for others.

To avoid some of that, they can go IPv6-only, including their servers and all peers they communicate with, then there doesn't need to be NAT64 for their traffic.  But even IPv6-only they will need firewall traversal support, as firewalls by default will block unsolicited incoming traffic (RFC6092).
 
-d