Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient

On Fri, Apr 3, 2015 at 7:23 AM, George, Wes <wesley.george@twcable.com>
wrote:

>
>    From: James Woodyatt <jhw@nestlabs.com>
> Date: Thursday, March 26, 2015 at 6:23 PM
> To: IPv6 Ops WG <v6ops@ietf.org>
> Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions
> -- NAT64/DNS64 remains insufficient
>
>  There is only one thing applying any pressure of any kind to developers
> currently using IPv4 literals in their application protocols: that their
> applications FAIL on Apple operating systems when those devices connect to
> IPv6-only+NAT64 networks.
>
>  If Apple caves on this, as every other major vendor of mobile device
> operating systems has already caved, then developers will continue to rely
> on the viability of IPv4 literals as a protocol element for the foreseeable
> future. Those applications that do so will continue shipping with a
> reliance on 464XLAT for years to come, and they will continue to be used in
> critical processes for years after that when they are no longer under
> maintenance. There are people today scrubbing web pages and application
> protocols of their IPv4 literals, and they are mainly motivated to continue
> doing this by the need to deal with the fact that 464XLAT isn't universally
> deployed on all the major mobile platforms yet. Apple is the last
> noteworthy holdout.
>
>  Publishing a BCP that entails telling developers that IPv4 literals are
> legitimate for use as application protocol elements is unnecessary and
> counter-productive to the interests of the IETF in promoting adoption of
> IPv6. Instead it would communicate to developers that IETF is capitulating
> on IPv6, that it doesn't really believe in it anymore, and application
> developers should feel safe ignoring it for the foreseeable future.
>
> WG] interestingly, most of the above statement still works if you do
> %s/IPv4 Literals/Adobe Flash/g, though Android has hopped on that
> particular bandwagon too.
>
>  You're simply advocating for pushing this problem and therefore all
> efforts to motivate people to stop using IPv4 literals back onto the
> carriers, because you know full well that unlike Apple/Android did with
> flash, the carriers aren't going to intentionally break their user's
> experience to prove a point until the risk is vanishingly small, so they
> simply won't deploy IPv6-only+NAT64, because doing so will make the phone
> ring.
>
>  Perhaps if Apple believes that the developers need more motivation,
> there should be explicit guidance in the App store guidelines that apps
> using IPv4 literals, even on the server side, are unacceptable? (yes, I
> realize you no longer work there James). Lorenzo, does Android have such
> guidance? Even with 464xlat support, if that's there, then we're continuing
> the pressure on fixing it while acknowledging the operational reality of
> making a decent user experience until it's fixed properly.
>
>  Wes George
>
>
Talk is cheap, so are guidelines.  If it works, it ships.  We have been
waving the guidelines that people should turn on ipv6 for years, they don't
work.  Anyone who has turned on ipv6 has done it because they saw a
straight-line to risk and cost mitigation.

And again, there are ipv4 literals on major top 100, top 1000, top 1M
websites.... App store guidelines and even hard  requirements won't fix the
free and open web.

Releasing guidelines was soooo 2005. And, soooo ineffective at making real
ipv6-only ipv4-socket-free deployment possible.  In fact, we are pretty
sure no major (or minor) network or operating environment of any sort is
ipv4-free.

Meaning, nobody has even started.

Conclusion:  IPv4 sockets need to be supported on hosts that operate in
IPv6-only networks.

CB

> ------------------------------
> This E-mail and any of its attachments may contain Time Warner Cable
> proprietary information, which is privileged, confidential, or subject to
> copyright belonging to Time Warner Cable. This E-mail is intended solely
> for the use of the individual or entity to which it is addressed. If you
> are not the intended recipient of this E-mail, you are hereby notified that
> any dissemination, distribution, copying, or action taken in relation to
> the contents of and attachments to this E-mail is strictly prohibited and
> may be unlawful. If you have received this E-mail in error, please notify
> the sender immediately and permanently delete the original and any copy of
> this E-mail and any printout.
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>
>