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

From: Brian Zill <[email-masked]>
Date: Sun, 30 Jan 2000 19:19:23 -0800

Thanks Itojun, for the detailed reply!

Comments below...

> >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?
  
If there are no hints, or ai_family == PF_UNSPEC, then we do the exact same
thing (v6 address in first record, v4 address in the second).  Although we
currently assume you're on a dual-stack and always return both instead of
checking which stacks are available, we need to fix that.

> (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.

Ohhh, good point.  We currently return the name associated with the first
successful query, and don't check to see if the name is different for later
queries.  Like you, we also issue separate A and AAAA queries since we were
seeing broken DNS implementations out on the Internet -- some DNS servers
would respond to queries for type ANY with just the cached result from an
earlier A query, thus losing any other records (like AAAA) that a real ANY
query would return.  Has anyone else seen this?  I think this is a potential
problem for v4 to v6 transition since it slows down name lookup for v4 hosts
on machines that are v6 enabled (since you have to wait for the v6 lookup to
fail).

> so KAME code puts ai_canonname for every addrinfo
> entries, if AI_CANONNAME is given.

We could do that, I suppose.  Right now we only put it in the first one.

> >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 don't do either of those.  You're right, the spec isn't clear here at all
and we're doing quite different things.  For your example (assuming
foo.internet.host resolves to both a v4 and a v6 address) we'll return two
entries:
    AF_INET, port 13, socktype 0, protocol 0
    AF_INET6, port 13, socktype 0, protocol 0
My feeling was that addrinfo isn't responsible for checking supported
triples, so we should treat someone calling addrinfo with an unspecified
socket type and/or protocol the same way as the socket call does (and if our
caller passes the addrinfo output directly to socket(), then they will get
whatever that behavior is).  However, if ai_socktype is unspecified, and
there is a service name lookup, then I will perform a service lookup using
both types and if one fails, I will set ai_socktype to be the one that
worked.  If both succeed but yield different port numbers, I return the one
for TCP and set ai_socktype to be SOCK_STREAM.  Otherwise, I return the
unspecified ai_socktype.  As for ai_protocol, I always blindly pass out
whatever I was given (or zero if it was left unspecified in the hints).

> (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).

Good point.  We don't currently allow SOCK_RAW.

> >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.

We return an error.  The "truncate and return success" behavior seems very
dangerous to me.

> >Section 6.5 getnameinfo:
> >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.

Good point.  I should have thought of that.  Just out of curiosity, do you
require it to be the exact size, or just that it is big enough to hold a
sockaddr of the appropriate type?  And does KAME use 4.4 style sockaddrs
with the socket length field, or the 4.3 style?

> >The spec doesn't say anything about the error code 
> >namespace, so I used the regular system one.
> 
> 	KAME code defined NI_xxx and uses them.

Francis also mentioned in his reply that he uses this same ENI_xxx
namespace.  Is this something that other implementations do, or just you
two?  If there is consensus on this in the working group, it'd be nice to
get it into the spec.

> itojun

Thanks again,
--Brian 
--------------------------------------------------------------------
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: Jun-ichiro itojun Hagino <[email-masked]>
Date: Mon, 31 Jan 2000 13:17:55 +0900

>We could do that, I suppose.  Right now we only put it in the first one.

	We still need the definition of "canonical name", or some reference
	to genuine document.  Francis ciarified it a bit, but I'm still not
	sure what should I put to ai_canonname against
	getaddrinfo("ftp.kame.net"), while having the following records
	on DNS.  I agree this is not a good example (maybe incorrectly
	configured), but we somehow need to fill in ai_canonname field.

ftp.kame.net.		1H IN A		203.178.141.212
ftp.kame.net.		1H IN AAAA	3ffe:501:4819:2000:5254:ff:fedc:50d2

kame212.kame.net.	1H IN AAAA	3ffe:501:4819:2000:5254:ff:fedc:50d2
kame212.kame.net.	1H IN A		203.178.141.212
212.141.178.203.in-addr.arpa.  1D IN PTR  kame212.kame.net.

pine.v6.kame.net.       1H IN AAAA      3ffe:501:4819:2000:5254:ff:fedc:50d2
2.d.0.5.c.d.e.f.f.f.0.0.4.5.2.5.0.0.0.2.9.1.8.4.1.0.5.0.e.f.f.3.ip6.int.  1H IN PTR  pine.v6.kame.net.

	KAME getaddrinfo would return the following two records, because
	gethostbyname2 returns them in hp->h_name:
		ai_addr: 3ffe:501:4819:2000:5254:ff:fedc:50d2
		ai_canonname: "pine.v6.kame.net"

		ai_addr: 203.178.141.212
		ai_canonname: "kame212.kame.net"

(getaddrinfo globbing)
>whatever I was given (or zero if it was left unspecified in the hints).

	I see, I think it is fair to leave ai_protocol opaque.  That will
	simplify the code a bit.

>Good point.  We don't currently allow SOCK_RAW.

	4.4BSD has more socktypes, SOCK_RDM and SOCK_SEQPACKET in sys/socket.h.
	I'm not sure what should I do against them.

>with the socket length field, or the 4.3 style?

	*BSD uses 4.4 style sockaddr (with sa_len), so KAME obeys it.
	KAME getaddrinfo requires salen (2nd arg to getnameinfo) to be the
	same as sa_len.

>two?  If there is consensus on this in the working group, it'd be nice to

	Attached is the current ENI_xxx definition on KAME. 
	At this moment those #define are
	not exported to users (local decl in getnameinfo.c).  We also don't
	support ENI_xxx by gai_strerror().

	If we would like to take this route further,
	- we need to define which result should be returned in which situation
	  (like EAI_xxx). 
	- do we need support for ENI_xxx in gai_strerror(), just unify ENI_xxx
	  into EAI_xxx and use gai_strerror(), or add gni_strerror()?

itojun

---
#define ENI_NOSOCKET 	0
#define ENI_NOSERVNAME	1
#define ENI_NOHOSTNAME	2
#define ENI_MEMORY	3
#define ENI_SYSTEM	4
#define ENI_FAMILY	5
#define ENI_SALEN	6

---

From: Robert Elz <[email-masked]>
Date: Mon, 31 Jan 2000 17:36:37 +1100

Date:        Mon, 31 Jan 2000 13:17:55 +0900
    From:        Jun-ichiro itojun Hagino <[email-masked]>
    Message-ID:  <[email-masked]>

  | 
  |     Francis ciarified it a bit, but I'm still not
  | 	sure what should I put to ai_canonname against
  | 	getaddrinfo("ftp.kame.net"),

"ftp.kame.net"

The only time you'd change what the application gives you is if it gives
you an alias (something with a CNAME record as a value, or something in
some locally defined aliases form - eg: a name with no dots that gets searched 
for, or something found in .hostaliases, or whatever...)

Values of PTR records are irrelevant.

kre

---

From: [email-masked]
Date: Mon, 31 Jan 2000 15:42:20 +0900

>	gethostbyname2 returns them in hp->h_name:

	sorry I've tried it with our old library.  The result KAME getaddrinfo
	will return is:
		ai_addr: 3ffe:501:4819:2000:5254:ff:fedc:50d2
		ai_canonname: "ftp.kame.net"

		ai_addr: 203.178.141.212
		ai_canonname: "ftp.kame.net"

	Are there more tricky examles?

itojun

---

From: Francis Dupont <[email-masked]>
Date: Mon, 31 Jan 2000 09:48:53 +0100

In your previous mail you wrote:

=> We added SOCK_CONTROL which is the same thing than SOCK_RAW but
with restrictions on what is allowed and available to ordinary users
(useful for a node information service (using ICMPv6 info packets)
in user mode).

   

=> I think we should take it!

=> gni_strerror().

   #define ENI_NOSOCKET 	0
   #define ENI_NOSERVNAME	1
   #define ENI_NOHOSTNAME	2
   #define ENI_MEMORY	3
   #define ENI_SYSTEM	4
   #define ENI_FAMILY	5
   #define ENI_SALEN	6

Thanks

[email-masked]