[arin-ppml] ARIN-prop-127: Shared Transition Space for IPv4 Address Extension

[Lee Howard]

TL;DR  Prioritize IPv6 over NAT444 workarounds.



----- Original Message ----
> From: Jack Bates <jbates at brightok.net>
>
> If applications utilize a  mixture of STUN, ICE, and TURN, 
> NAT444 might just happen to work. With NAT64,  hopefully 
> everyone will use the well known prefix, so they can address v4 
> hosts  properly within the v6 addressing.

What well-known prefix?  Do you mean 6to4?  It has huge 
problems:
* Versions of Mac OS X before 10.6.5 prefer 6to4 over 
rfc1918, so it actually breaks NAT444.
* 6to4 is unpredictable, since it uses anycast.  Your nearest
6to4 relay might be 1000ms away, and the nearest relay to the
other end might be another 1000ms away.

I think 6to4 should be considered harmful, or at least
deprecated.  But I'm not going to spend time writing that
internet-draft, because I'm busy deploying IPv6.

Maybe you meant 6in4 or 6over4.  Essentially, there is no
way to get IPv4-only hosts to IPv6, and the ones that
need it most require an ALG which does not exist.

NAT64 generally refers to the collection of work in the
BEHAVE working group:  http://datatracker.ietf.org/wg/behave/


Consumer electronics are the devices most likely to be IPv4
only; computers can generally be upgraded to support IPv6.
If consumer electronics vendors have to choose or even
prioritize between ICE and IPv6 support, IPv6 support is
much more important.

The place where NAT444 is needed, and why I support
this proposal, is in traditional client-server communication,
as in web client/web server, or mail client/mail server.
These applications generally work fine through NAT444,
though with performance problems, legal and security
issues, which have all been documented.  IPv6 is still much
better.

Lee