> 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf