>> we really need to convince random book authors to update their
>> programming examples, from gethostbyname() to getnameinfo()...
>how can you expect them do so, when there's so much difference between
>the behaviour of the various TCP/IPv6 stacks?
yes, that is the issue. i was trying to suggest example be using
getaddrinfo(3) loop, which should work for the most cases.
if OS designers are sane enough to design bind(2) behavior and
getaddrinfo(3) behavior with care, getaddrinfo(3) loop has a good
chance to work in many cases.
we need to document platform differences, of course.
for exaplme, for server side, assume that the goal is to accept both
IPv4 and IPv6 traffic.
- if getaddrinfo(3) returns :: and 0.0.0.0, the code will work
for the following cases:
bind(2) in any order is permitted, traffic accepted as
necessary
bind(2) of 0.0.0.0 prohibited after ::, AF_INET6 socket
grabs IPv4 traffic
but not for the following case:
bind(2) of 0.0.0.0 prohibited after ::, AF_INET6 socket
does not grab IPv4 traffic (seems very broken to me)
- if getaddrinfo(3) returns :: only, it will work for the following
cases:
AF_INET6 socket grabs IPv4 traffic
but not for the following cases:
AF_INET6 socket does not grab IPv4 traffic (getaddrinfo seems
broken to me on this platform)
(note to OS imlementers - so getaddrinfo(3) behavior has to be
carefully designed consdidering your bind(2) and IPv4 mapped addr
behavior!)
>IMHO, draft-ietf-ipngwg-rfc2553bis-03.txt should specify what is the
>correct behaviour for bind(2). i vote for the *BSD one: by having two
>different sockets binding indipendently one from the other, we can
>get rid of all the problems given by IPv4-mapped IPv6 address, and
>have true af-indipendence. the IPV6-ONLY option and IPv4-mapped IPv6
>address should not be deprecated, but their use should be unrecommended.
>this policy would lead to the best result with only minor changes in the
>draft and in the existing ipv6 implementations.
I have been trying SO HARD to suggest it in api discussion group (which
is a small group of people who contributed 2553bis-03 updates), but
was rejected. it is a holy war where there's no end. one side
advocates AF_INET6 only world, one side advocates AF_INET6/AF_INET
splitted socket (or at least make the default behavior so).
I'm of course in the second camp.
in fact, as far as i understand, there's no good standard document
on bind(2) interaction between two IPv4 sockets. so defining it
for IPv4/v6 interaction would be a big task.
>in fact, when called with AI_PASSIVE flag set and AF_UNSPEC protocol
>family, in a both ipv4- and ipv6-compliant system, getaddrinfo should
>return two different results (::1 for ipv6 and 127.0.0.1 for ipv4).
>moreover, calling getaddrinfo with AF_UNSPEC protocol family should
>produce a result that's the sum of the results of two getaddrinfo
>calls (one for AF_INET and one for AF_INET6).
>
>getnameinfo does not need to be modified.
it is what i have been believed, but there are people believing in
different behavior.
>> it is a bit dated, but the content should be still valid.
>> do you have any suggestions for improvements?
>some code examples would be useful. the paper doesn't explain how to
>handle IPv4-mapped IPv6 address and the IPV6_ONLY option, for example.
aha, I was biased to independent AF_INET/AF_INET6 implementation ;-)
as IPV6_V6ONLY support is still rare, not sure if it worth document it.
thanks anyways.
itojun
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------
