On Jun 15, 2010, at 5:57 AM, Phillip Hallam-Baker wrote:
But in a Betamax/VHS type contest, attempting to differentiate the new
through obfuscation merely raises barriers to transition. In that
circumstance you want to minimize the differences between the two
technologies so that they can be used interchangeably.
So, things like implementing getaddrinfo() to replace gethostbyname() and as
a result making the applications network layer agnostic. The kind of thing
that not only helps with IPv6 deployment, but makes multi-homing work well
for the IPv4-only application as well, makes solutions like pnat irrelevant,
and all that.
Right general idea, but wrong in the details. The API applications should be
using is one of the connectbyname variants that avoids having to do any
handling of raw addresses of any sort. PHB's suggestions are spot on here.
Among other things, using a connectbyname API provides the abiltiy to easily
implement support for SRV records.
http://www.ietf.org/rfc/rfc2553.txt
2553 Basic Socket Interface Extensions for IPv6. R. Gilligan, S.
Thomson, J. Bound, W. Stevens. March 1999. (Format: TXT=89215 bytes)
(Obsoletes RFC2133) (Obsoleted by RFC3493) (Updated by RFC3152)
(Status: INFORMATIONAL)
http://www.ietf.org/rfc/rfc3493.txt
3493 Basic Socket Interface Extensions for IPv6. R. Gilligan, S.
Thomson, J. Bound, J. McCann, W. Stevens. February 2003. (Format:
TXT=82570 bytes) (Obsoletes RFC2553) (Status: INFORMATIONAL)
Supported in Windows, Mac/BSD, Linux, you name it. Been there a long time.
But still too low level. And the fact that the addrinfo APIs are "supported"
on a lot of platforms doesn't mean code written on top of them interoperates.
Case in point. A few months back I was testing some code that uses the addrinfo
interfaces on a new platform. getaddrinfo worked fine, but getnameinfo, not so
much. After contacting the vendor, I was informed that the length field in the
structure had to match the length field supplied in the parameter list exactly
or the call would fail. The suggested fix was to put a switch statement in
front of the call to fill in the lengths appropriately depending on the address
family in use. That's not exactly futureproofing, is it?
Yes, all we need is application engineers with a network clue. They seem to
be hard to come by.
And tHat's frankly insulting - the main problem isn't new code, which by and
large is being written in languages that support proper connectbyname and
getconnectinfo APIs that hide all this stuff completely. No, the problem is
the vast amounts of old code written long before the addrinfo APIs existed.
Switching all of this stuff over is NOT trivial. An especially pernicious
problem is library code where the source is either unavailable or is available
but you're not allowed to modify it for one reason or another.
And since I'm not in the best of moods I'll also answer in kind by saying us
application engineers might also be waiting for someone with half a clue as to
how to design a proper standard API to come along and do that.
Ned
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf