Subject: Re: Clarifications wanted on Basic API (RFC 2553)

From: Jim Bound <[email-masked]>
Date: Tue, 01 Feb 2000 23:37:20 -0500

Hi itojun,

>>Section 6.4 getaddrinfo:
>
>	(addition)
>	When host == NULL, loopback addresses and/or wildcard addresses will
>	be returned.  At this moment KAME getaddrinfo returns all the
>	loopback/wildcard address in address family supported by the kernel.
>	For example, if you are on top of IPv6-only kernel, getaddrinfo will
>	return :: or ::1.  If you are on dual-stack, getaddrinfo will
>	return :: and 0.0.0.0, or ::1 and 127.0.0.1.  Is the behavior okay?

I would say I would like to see consensus on this and hear from other
implementors.  It does not break binary compatibility so if we have
consenus this can be considered.

>	(addition)
>	interaction of NI_NUMERICxxx with AF_LOCAL (AF_UNIX), or other address
>	families where hostname/servname cannot become decimal/hexadecimal
>	digits.
>	(Hideaki YOSHIFUJI pointed this out around Jan 19, 2000)

Can you please recap the point please. thanks.  NI_NUMERICxxx applies
specifically to a situation where a failure has occurred.  Why would
AF_UNIX socket type be a consideration?

>>The precise meaning of  the AI_CANONNAME flag is unclear to me.  It says
>>that if this flag is set, then upon return, the first addrinfo struct's
>>ai_canonname field will point to "a null terminated string containing the
>>canonical name of the specified nodename".  Someone define canonical name
>>for me please.
>
>	(just additional datapoint)
>	KAME code copies hp->h_name returned from getipnodebyname(), or
>	gethostbyname().  Not sure if this is the right answer to "canonical
>	name".  Things gets tricky as
>	- KAME getaddrinfo calls name resolution twice, once for IPv4 and 
>	  once for IPv6
>	- and hp->h_name can be different each time.
>	so KAME code puts ai_canonname for every addrinfo entries, if
>	AI_CANONNAME is given.

If there is a CNAME use it.  like ftp    CNAME ftphost.foo.oohga

>>What am I supposed to do if in the "hints" structure, someone passes in a
>>value for ai_socktype that is at odds with ai_protocol?  (e.g. SOCK_STREAM
>>with UDP).  Is getaddrinfo supposed to check if the particular triple of
>>address family, socket type, and protocol is supported on the system?  The
>>existence of the EAI_ADDRFAMILY error implies that just checking that the
>>address family is supported is enough (which is all I currently do).

>	(similar to the above)
>	The spec does not say how far we need to "glob" the input.
>	When KAME getaddrinfo is called with the following parameter:
>		host = "foo.internet.host"
>		serv = "daytime"
>		hints.ai_family = PF_UNSPEC
>		hints.ai_socktype = hints.ai_protocol = 0
>	the code would return the following four entries:
>		AF_INET, port 13, SOCK_STREAM, IPPROTO_TCP
>		AF_INET, port 13, SOCK_DGRAM, IPPROTO_UDP
>		AF_INET6, port 13, SOCK_STREAM, IPPROTO_TCP
>		AF_INET6, port 13, SOCK_DGRAM, IPPROTO_UDP
>	Past KAME code returned SOCK_STREAM only (2 entries), like:
>		AF_INET, port 13, SOCK_STREAM, IPPROTO_TCP
>		AF_INET6, port 13, SOCK_STREAM, IPPROTO_TCP
>	Which behavior the spec prefer?

We need to add the behavior set to the API similar to the behavior we
had to getipnodebyname.  We pretty much till this point have left
getaddrinfo in tact per Posix.  We now are going to change it.

I believe what you have above is correct IMO returning all AF's and
prototypes.

>	(addition)
>	is SOCK_RAW allowed in hints.ai_socktype?  this is very useful
>	when we write "ping" which is less-dependent to AF
>	(hints.ai_protocol is opaque in this case).

We need to look at the ramifications.  My gut says no use the Advanced
API for such things.

>>Section 6.5 getnameinfo:
>
>	(addition)
>	It is not 100% clear how the code should behave when a short buffer
>	is passed.  RFC2553 seems to me to raise error.  X/Open says to
>	truncate the result and success.  The most recent ipngwg discussion
>	preferred RFC2553 (error), if I remember correctly.

I will support RFC 2553.  So we need to discuss?

>>Section 6.5 getnameinfo:
>>it must be exactly the right size).  The rest of us disagree, because that
>>would mean that you can't call getnameinfo with a pointer to a struct
>>sockaddr_storage and salen set to sizeof(struct sockaddr_storage).  Losing
>>that capability loses a lot of the address independence feature that makes
>>getnameinfo so nice in the first place.  We'd really like to be able to
>>perform a getpeername call, with the result going into a sockaddr_storage,
>>and then be able to just pass that to getnameinfo to find out who we're
>>talking to without having to add any address family specific code.

>	(comment to brian's)
>	by the time you call getnameinfo(), you should have done something like
>		getpeername(sock, &ss, &sslen);
>	and you have the exact length (like sizeof(sockaddr_in)) in sslen.
>	you are not passing sizeof(sockaddr_storage) in 2nd arg in this case.
>		getnameinfo(&ss, sslen, ...)

>	or, if you have sa_len field, this should be okay:
>		getnameinfo(&ss, ss.ss_len, ...)

This is a good point.  If you use &ss and &sslen in getpeername you can
use it later for your socket operation.

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: [email-masked]
Date: Wed, 02 Feb 2000 13:47:20 +0900

>AF_UNIX socket type be a consideration?

	attached. (sorry if you already have a copy)

>We need to look at the ramifications.  My gut says no use the Advanced

	Though behavior of raw socket is defined in advanced API, we need to
	resolve name to use raw socket (for example, to send icmp probe
	to destination we need to get IPv6 address for the destination).
	Advanced API does not define name-to-address translation, it relies
	upon basic API document (getaddrinfo).
	This is the reason why I brought this up here.

>I will support RFC 2553.  So we need to discuss?

	I was just unsure about my memory and would like a confirmation
	from someone.  I think my memory was correct.

itojun

Subject: getnameinfo() with NI_NUMERIC****
From: Hideaki YOSHIFUJI (吉藤英明) <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Wed, 19 Jan 2000 00:55:23 +0900

Hi.

About getnameinfo(), RFC2553 says:

|   The POSIX 1003.1g specification includes no function to perform the
|   reverse conversion from getaddrinfo(): to look up a nodename and
|   service name, given the binary address and port.  Therefore, we
|   define the following function:

|      int getnameinfo(const struct sockaddr *sa, socklen_t salen,
|                      char *host, size_t hostlen,
|                      char *serv, size_t servlen,
|                      int flags);

|   The first argument, sa, points to either a sockaddr_in structure (for
|   IPv4) or a sockaddr_in6 structure (for IPv6) that holds the IP
|   address and port number.  The salen argument gives the length of the
|   sockaddr_in or sockaddr_in6 structure.

The GNU C Library, used as Linux C library, extends getnameindo() 
to accept a pointer to sockaddr_un structure for PF_LOCAL sockets. 
I think this extension is natural because getnamefinfo() is a 
reverse-function of protocol-independent getaddrinfo() function.
But, at this time, there are some issues, and I'd like to discuss 
them on this list.

[1] NI_NUMERICHOST

If we call getnameinfo() with NI_NUMERICHOST, it should returns 
in the numeric form of the host's address if sockaddr_in{,6} 
structure is given.  On the other hand, getnameinfo() of the current 
glibc always returns "localhost" string as a host with sockaddr_un 
even if getnameinfo() is called with NI_NUMERICHOST.
Since "localhost" doen't seem numeric (36-based number??),
applications should be cofused. Which is the most appropriate?
 1) return in an error
 2) return INADDR_LOOPBACK ("127.0.0.1") ?
 3) return IN6ADDR_LOOPBACK ("::1") ?
 4) "-1"
 5) ""
 6) "localhost"
 7) ?

[2] NI_NUMERICSERV

If we call getnemeinfo() with NI_NUMERICSERV, it returns in the 
numeric form of the service address (port number).
The getnameinfo() of the current glibc always returns pathname 
like "/tmp/22", "/tmp/fileasdfgh", or "/whatever/path/to/file".
1st one is from getaddrinfo("localhost", "22") with PF_LOCAL 
(or PF_UNSPEC) hints.  Next one is from getaddrinfo("localhost", 
NULL) (path is automatically selected), and the last one can 
be obttained if you call getaddrinfo("localhost", 
"/whatever/path/to/file"). Which is the most appropriate?
 1) return in an error
 2) return number if pathname matches ^/tmp/([0-9][0-9]*)$.
    (I mean, if "/tmp/22", it returns "22")
    otherwise, return in an error.
 3) current behavior (pathname)
 4) ?

[3]

When I complained about above issues, Ulrich Drepper at gnu.org / 
cygnus.com said,
|I've looked a bit closer at the specification and found that it only
|mentions AF_INET and AF_INET6.  So whoever calls getnameinfo for
|AF_LOCAL must expect everything since the behaviour is unspecified.

How do you think about this opinion?

Thanks in advance.

-- 
Hideaki YOSHIFUJI <[email-masked]>
Web Page: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/
PGP5i FP: F731 6599 5EB2 BBA7 1515  1323 1806 A96F 5700 6B25 
--------------------------------------------------------------------
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: Bill Manning <[email-masked]>
Date: Tue, 1 Feb 2000 22:53:37 -0800 (PST)

% Hi itojun,
% 
% >>Section 6.4 getaddrinfo:
% >
% >	(addition)
% >	When host == NULL, loopback addresses and/or wildcard addresses will
% >	be returned.  At this moment KAME getaddrinfo returns all the
% >	loopback/wildcard address in address family supported by the kernel.
% >	For example, if you are on top of IPv6-only kernel, getaddrinfo will
% >	return :: or ::1.  If you are on dual-stack, getaddrinfo will
% >	return :: and 0.0.0.0, or ::1 and 127.0.0.1.  Is the behavior okay?

	Once, in an early ngtrans mtg (Memphis?) the following form was also
	considered "legal"  ::127.0.0.1

--bill

---

From: [email-masked]
Date: Wed, 02 Feb 2000 16:04:53 +0900

>	considered "legal"  ::127.0.0.1

	that is 127.0.0.1 as IPv4 compatible address (RFC1933) - correct?
	This is not listed in RFC2373 as being loopback address and I don't
	think we need to list that one.  If you use ::127.0.0.1, the node
	would tunnel IPv6 packet (from/to ::127.0.0.1) into IPv4 packet 
	(from/to 127.0.0.1) packet and send that to loopback interface.
	I don't see benefit in it except for debugging purposes.

	getaddrinfo tries to return ai_addr portion that exactly matches
	with ai_family.  So I think returning ::1 (for AF_INET6) and 127.0.0.1
	(for AF_INET) is more correct.

	(for post-2553 getadrinfo, if ai_family is PF_INET6 and ai_flags has
	AI_ALL|AI_V4MAPPED, story may go different - you will get ::1 and
	::127.0.0.1)

itojun

---

From: [email-masked]
Date: Wed, 02 Feb 2000 16:06:02 +0900

>	AI_ALL|AI_V4MAPPED, story may go different - you will get ::1 and

	the last line should read ::ffff:127.0.0.1 (v4 mapped).

itojun

---

From: Jim Bound <[email-masked]>
Date: Wed, 02 Feb 2000 17:15:54 -0500

Hi Itojun,

Ah Ha...yes that is a different model than using gethostbyname today
before doing the raw socket.  I think we need to consider this and what
the ramifications are to the adv api.  It seems Francis believes this is
doable too.

Has Kame code done this yet?

>	from someone.  I think my memory was correct.

OK.  I just found out that XNS folks agree with us we should not
truncate the name.

>But, at this time, there are some issues, and I'd like to discuss 

So this wants to add PF_LOCAL as AF argument?
I would argue this is out-of-scope for rfc2553bis because PF_LOCAL is
not an Internet communications problem but local to the implementation?
It also does not aid in the solution to Internet problems (or Intranet)
as does if*index functions.

> 3) return IN6ADDR_LOOPBACK ("::1") ?

I would say glibc is an extension we cannot standardize in the IETF or
XNS.

But also look at the XNS 5.2 spec as they defined an error space for
getnameinfo we need to do for rfc2553bis.

> 3) current behavior (pathname)

Same answer as above.

>|AF_LOCAL must expect everything since the behaviour is unspecified.

AF_LOCAL likewise is out-of-scope.  Its an implementation matter on each
platform.  

>How do you think about this opinion?

I think I answered above.

thanks
/jim

---

From: [email-masked]
Date: Thu, 03 Feb 2000 09:29:49 +0900

>Has Kame code done this yet?

	KAME code already does it, and it is very useful when I write
	various userland code.

itojun