Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt

From: Jim Bound <[email-masked]>
Date: Thu, 04 Nov 1999 14:29:04 -0500

>> >Why not just use getaddrinfo instead of getipnodebyname?
>> >This might mean changing 20 lines of code compared to 10 lines of code
>> >with getipnodebyname (for a port of trivial example code to the new API).
>>
>> I don't agree.  the inline code to change from gethostbyname to
>> getipnodebyname is much more explicable and supporting addded trans
>> mechanisms.  

>I guess I just have this broken view of converting to getipnodebyname()
>as going from 1 to 2, whereas converting to getnameinfo() as going from
>1 to N.  As the old addage says, "in computer science there are only 3
>interesting numbers, 0, 1 and many".  getipnodebyname() is not going to
>allow a simple application operate over UN*X domain sockets, but
>getnameinfo() can.

And there is an old addage in "engineering" get the job done as quick as
possible.  Its a tradeoff of computer science vs engineering.  Two
different things all together.

Please explain 1 to N.... If you mean more than AF_INET and AF_INET6
then I don't agree and don't care from a business perspective as an
engineer about anything other than v4 or v6.

If you mean getting back a mix of both v4 and v6 addresses
getipnodebyname supports that and returns v4 as v4mapped.

Mabye our approaches of implementing v4mapped and the IP stack for IPv6
are completely different.  

Is there a test to see if I am dealing with a v4 or v6 address not
really the only concern is if I was passed in AF_INET or AF_INET6 to my
server app.  This not a hard condition to maintain and easy to write.
And its self documenting.

Also I don't see AI_ALL and AI_ADDRCONFIG are not part of of
getaddrinfo?

>> see our programming examples at: www.ipv6.zk3-x.dec.com
>> click on "Porting Guide"
>
>It's a nice guide, but I'm not too suprised that it doesn't even
>mention the getaddrinfo()/getnameinfo() functions, so people using
>it won't even know that they exist.  It'd be nice if the guide at least
>mentioned the functions.

Well we believe the two are tied together and await the fixes from XNET
but they will be part of our guide eventually.  We will provide both
choices and one of our ISVs is using getaddr and friends.

>> using getipnodebyname is more familiar to most programmers who use
>> sockets we keep the semantics and the core inline logic of the code
>> remains in tact you add the conditions of v4/v6.
>>
>> getaddrinfo and friends changes the programming paradigm a bit and what
>> you must feed that api engine.

>Hey, in the old days, gethostbyname() only returned one address,
>and people wrote applications with that assumption in mind.  Then,
>along came the ability to for gethostbyname() to return an array
>of addresses, and that required changing the programming paradigm
>to take advantage of trying multiple addresses if the first one
>failed.  Programmers managed to handle that change without too
>much trouble.  I think that most of them will be able to grasp
>how to convert to using getnameinfo(), and are capable of doing
>the minor code shuffling.

It was much more than that it was MT Safeness, additional flags, and a
few more things.

>Of course the main focus of changes between RFC 2133 and RFC 2553
>was getipnodebyname and friends, because the older gethostbyname2()
>and friends were just not up to the task.  There really wasn't much
>that needed to be changed with getaddrinfo() and getnameinfo(), so
>they just naturally weren't part of the discussion.

scoping too.

>I just like to gently remind people that while there has been
>a lot of focus on getipnodebyname() and friends, it is not the
>only game in town.  Personally, I find that when I recode things
>to use getnameinfo(), I get cleaner, more generic code in the end.
>But while I changed ftp to use getnameinfo(), I did the quick
>hack for telnet to use gethostbyname2().  And the telnet code
>is a lot uglier than the ftp code.

But we all know beauty is in the eye of the programmer :--)....

>> I predict most will stay with getipnodebyname and as Sam stated
>> previously its a pain.
>
>The bottom line is that I think that both sets of functions are
>useful.  You may feel that getnameinfo() is a pain, but just
>because you feel that way doesn't mean that everyone else will
>also feel that way.  I will use whichever seems to be more
>appropriate for the task at hand, whereas you just seem to ignore
the getnameinfo()/getaddrinfo() functions or say that they are
>too complex, and you pass that attitude on to others.  That's one
>of the reasons why I periodically keep reminding people that the
>getnameinfo()/getaddrinfo() functions exist.

And that fine and good.

>It all depends on your goals.  One of my main goals is to be able to
>compile a single binary that will support IPv6, but will still run with
>a kernel that does not have IPv6/AF_INET6 support.  Using getnameinfo(),
>I have one call to look up the name and I have all the information to
>create the a socket with the correct address family, and the correct
>sockaddr structure to use for the connect().  If I use getipnodebyname(),
>I have to make two calls, one for IPv4 and one for IPv6, since I can't
>use IPv4-mapped IPv6 addresses, because those depend on AF_INET6 support.
>Or else I have to look at the IPv6 address, check to see if it is an
>IPv4-mapped IPv6 address, and convert it back to an IPv4 address so that
>I can use an AF_INET socket.  It just gets ugly.  But if you don't care
>about building a binary that runs on kernels without IPv6, then your code
>won't have to be that ugly.

Well I don't have the same problem we built IPv6 to support AF_INET6
on down then send IPv4 if its a mapped address.

>I guess the fact that I can make an application IPv6 capable without
>having to make it IPv6 aware is one of the things that I like about
>using getnameinfo().  getipnodebyname() doesn't give you that.

Hmm.  I can change and IP app to use Ipv6 or IPv4 and the stack does not
have to support IPv6.

Anyway.... Each of us have our preferences and I will continue to
advocate use of getipnodebyname, unless its a new app.

/jim

		-David Borman, [email-masked]
--------------------------------------------------------------------
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: Thu, 4 Nov 1999 11:01:15 -0600 (CST)

> From [email-masked] Thu Nov  4 09:44:36 1999
> From: Jim Bound <[email-masked]>
> To: Erik Nordmark <[email-masked]>
> Cc: Sam Manthorpe <[email-masked]>, Jack McCann <[email-masked]>,
>         [email-masked]
> Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt 
> Date: Thu, 04 Nov 1999 10:40:13 -0500
> X-Mts: smtp
>
>
> >> Now, if only struct hostent used sockaddrs porting apps to IPv6 would
> >> be easy.
> >