Re: [tae] The internet architecture

Keith Moore <moore@network-heretics.com> 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
_______________________________________________
tae mailing list
tae@ietf.org
https://www.ietf.org/mailman/listinfo/tae