Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> writes: > There were also a bazillion deployed applications that would never be > upgraded to deal with Y2K. Somehow people managed. But part of how > they managed was by replacing some applications rather than > upgrading them. There were clear business motivations for ensuring that apps survived Y2K appropriately. There is no similar brick wall with IPv4 address exhaustion. > I certainly won't argue that it's not a significant challenge to edit > each application, recompile it, retest it, update its documentation, > educate tech support, and release a new version. But you'd have all of > those issues with moving to IPv6 even if we had already had a socket API > in place where the address was a variable-length, mostly opaque, > object. I didn't say a better API would have "variable-length, mostly opaque objects". I think others have already chimed in that hiding the details from the applications is the key to a better API. And I understand that Apple has a "more modern" API, and it made upgrading their applications to support IPv6 that much easier. > Consider also that the real barrier to adapting many applications to > IPv6 (and having them work well) isn't the size of the IPv6 address, or > adapting the program to use sockaddr_in6 and getaddrinfo() rather than > sockaddr_in and gethostbyname(). Actually, the real barrier to upgrading applications is lack of incentive. No ROI. It's not about technology at all. It's about business cases. Wouldn't it be nice if existing apps could run over IPv6 (perhaps in a degraded form) with no changes? That would change the challenges of IPv6 deployment rather significantly. > And at least from where I sit, almost all of the applications I use > already support IPv6. (I realize that's not true for everybody, but it > also tells me that it's feasible.) Huge numbers of important applications in use today do not support IPv6. Think beyond email, ssh and a browser. Think business applications. Talk to someone who works for a software company about the challenges they have upgrading their software to support IPv6 (or fixing bugs, or doing any work to "old" software). It's less about technology than business cases. Case in point. There is apparently still significant amounts of deployed software that cannot handle TLDs of more than 3 characters in length. That means DNS names with a TLD of .info or .name don't work in all places and can't be used reliably. I heard just this week that yahoo can't handle email with .info names. .info has existed as a TLD for 7 years. Fixing this is not a "technical" problem, it's a business problem (i.e., incenting the parties that need to upgrade their software). Thomas _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf