Subject: (IPng 7289) Re: Ipv6 Migration

From: Jim Bound <[email-masked]>
Date: Fri, 05 Mar 1999 16:11:32 -0500

David,

Forgot to put my :-) face on the statement.  

And we support getaddrinfo too it is required.

But I don't care about any address family but AF_INET and AF_NET6.

if another one is invented I won't work on it, and that means IPv6
failed.  If that happens I probably will go fishing.

I don't care if folks use getaddrinfo.  I won't though.

thanks
/jim
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: David Borman <[email-masked]>
Date: Fri, 5 Mar 1999 14:53:21 -0600 (CST)

> From [email-masked] Fri Mar  5 13:34:09 1999
> From: Jim Bound <[email-masked]>
> Date: Fri, 05 Mar 1999 14:33:52 -0500
> ...
> I hate getaddrinfo ... so I did not mention it or want it proliferated.

And that's really too bad.  The getaddrinfo() function is a very
useful function that allows you to do protocol independent address
lookups.  If (heaven forbid...) a new address family is added,
applications that have been modified to use getaddrinfo() will not
need any changes to support the new address family (assuming, of
course, that the application itself doesn't care about the addresses).

I don't have any objections to getipnodebyname(), because it does
serve a useful purpose.  But it is not the ultimate solution, since
it cannot return a mixed bag of IPv4 and IPv6 addresses (in both
sockaddr_in and sockaddr_in6 structures).

I don't have any problem if others wish to limit their applications
to using getipnodebyname(), as long as those providing the library
function also include getaddrinfo().  The getaddrinfo() function
is part of the API spec, and thus will proliferate to the same extent
as getipnodbyname() or any other function in the spec.

And getipnodebyname() *is* limited, because it is not protocol independent.
Yes, you can ask for different types of addresses, but in the end you
will only get *one* type of address back.  The only reason it works
for both IPv4 and IPv6 addresses is that you can return IPv4 addresses
as IPv4-mapped IPv6 addresses.  But you are still only dealing with
one sockaddr form.  If your application is to work with IPv6 addresses,
you have to use sockaddr_in6, which means it will not work on kernels
that don't have IPv6 built into them.  Or else you need to have code
that makes two getipnodebyname() calls, for both IPv6/IPv4 and IPv4-only.
That makes the ability to have IPv4-mapped addresses returned or the
successive call for AF_INET addresses redundant.

Using getaddrinfo(), you make one call and then loop down the list
of returned addresses, trying each.  A staight forward loop, and
the application doesn't even have to know about the different
sockaddr formats.

The bottom line for me is that I want applications that are not
filled with "ifdef INET6" or have lots of redundant/duplicated
code, and once compiled will run on both IPv6 aware and IPv4-only
kernels.  I can do that a whole lot more cleanly using getaddrinfo()
than getipnodbyname(), because using the latter I have to have two
calls to getipnodebyname(), one for each address family format.

I do not object to anyone using getipnodebyname(), but I don't
appreciate attempts to stifle it (and I *WILL* scream loudly if any
attempts are made remove getaddrinfo(), (which has not happened,
and I don't expect it to happen)).  Both functions are useful, as
they provide different capabilities.  I happen to think that
getaddrinfo() provides a cleaner coding solution to the problem of
supporting multiple protocol families.

			-David Borman, [email-masked]