On 05/08/09 00:44, Girish Moodalbail wrote:
Folks,
How should getaddrinfo() behave if the user requested for AI_CANONNAME
and passes in a literal IP address? (aka CR 6831339)
getaddrinfo(3SOCKET) states:
The getaddrinfo() function performs the *node name to address*
translation.
Therefore if the caller passes in an address and not a name while
including AI_CANONNAME then I think its fair enough to reply with the
IP address as the canonical name when no name is found. Assuming we
agree that the alternative of returning error EAI_BADFLAGS or EAI_NODATA
is not an option.
The CR justification states that this is a standards problem, which
standard is this and what does it say?
Stacey
Today it prints - "IPv4 mapped IPv6 address".
---------
bash-3.2# ./getaddr 10.8.57.21
ai[0]: af=2, len=16 saf=2, IP=10.8.57.21
ai[0]: cname="::ffff:10.8.57.21"
---------------------------
Now, if I fix the above to return 'canonical name' by calling
getipnodebyaddr() inside getaddrinfo() implementation, whenever a
literal address and AI_CANONNAME is used, we get the following result.
--------------
bash-3.2# ./getaddr 10.8.57.21
ai[0]: af=2, len=16 saf=2, IP=10.8.57.21
ai[0]: cname="trigati.east.sun.com"
-----------------------
Everything looks fine, however with the above fix getaddrinfo() fails
for literal addresses for which name service lookup fails. For ex:
link-local IPv6 addresses
bash-3.2# ./getaddr fe80::203:baff:fe94:2f56
getaddrinfo: fe80::203:baff:fe94:2f56: node name or service name not
known
So things which used to work before like below
-----------
bash-3.2# ftp fe80::203:baff:fe4c:f43c
Connected to fe80::203:baff:fe4c:f43c.
220 whitestar4-b.East.Sun.COM FTP server ready.
Name (fe80::203:baff:fe4c:f43c:root):
-----------
would fail, like below.
--------
bash-3.2# ftp fe80::203:baff:fe94:2f56
fe80::203:baff:fe94:2f56: unknown host or invalid literal address
ftp>
-----
From getaddrinfo() manpage we have
"upon successful return the ai_canonname member of the first
addrinfo structure in the linked list will point to a
null-terminated string containing the canonical name of the specified
nodename."
-> "specified nodename" is the key here. So should we conclude that
unless a 'nodename' was specified we will not return 'canonical' name
and accept the current behavior in Solaris.
thanks
~Girish
_______________________________________________
networking-discuss mailing list
[email protected]
_______________________________________________
networking-discuss mailing list
[email protected]