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

["Metzler, Dan J" <[e-mail]>]

From: v6ops [mailto:[e-mail]] On Behalf Of Ca By
Sent: Friday, April 3, 2015 9:36 AM
To: George, Wes
Cc: IPv6 Ops WG
Subject: 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 <[e-mail]<mailto:[e-mail]>> wrote:

From: James Woodyatt <[e-mail]<mailto:[e-mail]>>
Date: Thursday, March 26, 2015 at 6:23 PM
To: IPv6 Ops WG <[e-mail]<mailto:[e-mail]>>
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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/v6ops