On Mon, 25 Jun 2001, Jun-ichiro itojun Hagino wrote:
> >> 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!)
why don't we include this as a note in RFC2553 addressing implementers?
> >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.
i think that without the definition of a single standard behaviour for
bind and getaddrinfo, developers will have big problems writing portable
software.
i propose to add a paragraph to RFC2553 that explains the two allowed
behaviours for getaddrinfo and bind, and defining a constant that
can be examined to know the actual behaviour of our system at compile
time. something like:
#ifdef AF64_ORTHOGONALITY
/* the system behaves like *BSD */
#else
/* the system behaves like linux */
#endif
the same thing can be achieve in a better way if we define a new
read-only socket option:
getsockopt(sock, IPPROTO_IPV6, AF64_ORTHOGONALITY, &value, sizeof(int));
this works at run time.
--
Aequam memento rebus in arduis servare mentem...
Mauro Tortonesi [EMAIL PROTECTED]
Ferrara Linux User Group http://www.ferrara.linux.it
Project6 - IPv6 for Linux http://project6.ferrara.linux.it
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
