�Hola!
> > for(n = 0; (n < MAX_AF) && res ; res = res->ai_next) {
> > listenfds[n] = socket(res->ai_family, res->ai_socktype,
> > res->ai_protocol);
> > if(listenfds[n] < 0)
> > continue; /* libc supports protocols that kernel don't */
> >
> > if(bind(listenfds[n], res->ai_addr, res->ai_addrlen) != 0)
> > die();
> >
> > if(listen(listenfds[n], 10) != 0)
> > die();
> > n++;
> > }
> i am afraid i don't understand this portion of code. is getaddrinfo
> expected to return one-and-only-one ready-to-be-bound address for
> every AF when called with flag AI_PASSIVE set? there's nothing in
> the drafts that states this:
That's not specified, as far as I can tell. It must return all the
sockaddr's to bind to. If with just one sockaddr is enough that could
be correct. But it's implemented normally as you described.
> The AI_PASSIVE flag in the ai_flags member of the hints structure
> specifies how to fill in the IP address portion of the socket address
> structure. If the AI_PASSIVE flag is specified, then the returned
> address information must be suitable for use in binding a socket for
> accepting incoming connections for the specified service (i.e. a call
> to bind()). In this case, if the nodename argument is null, then the
> IP address portion of the socket address structure will be set to
> INADDR_ANY for an IPv4 address or IN6ADDR_ANY_INIT for an IPv6
> address. If the AI_PASSIVE bit is not set, the returned address
> information must be suitable for a call to connect( ) (for a
> connection-mode protocol) or for a call to connect(), sendto() or
> sendmsg( ) (for a connectionless protocol). In this case, if the
> nodename argument is null, then the IP address portion of the socket
> address structure will be set to the loopback address. This flag is
> ignored if the nodename argument is not null.
> from what i can guess, instead, the expected behaviour for getaddrinfo in
> this case (AI_PASSIVE, AF_UNSPEC and SOCK_STREAM set) is to return a
> ready-to-be-bound ::1 (ipv6) address. am i wrong?
It should be :: (ANY), not ::1 (loopback) and that could be done that way
if all the AFs can be mapped to IPv6, but if there are no mappable protocols
it should return the list.
> if so, your code (which is truly AF-indipendent) is not RFC2553-compliant.
> or better, the API specified by RFC2553 is not AF-indipendent.
I don't understand that.
> > A comment
> > But that's not all.
> > Nor the IPv6 centric nor the AF independent way work as cleanly as I
> > presented them. The IPv6 centric way dies on OS where the IPv6 support
> > is not compiled, so when programming the IPv6 centric way you should
> > check if the socket call fails and then fall back to work as a pure
> > IPv4 server (ie, duplication of code)
> duplication of code is (and - if we're not gonna change the API draft in a
> significant way - will always be) inevitable. there are MANY problems in
> handling both ipv6 and ipv4 (or better, ipv4-mapped) traffic with a single
> AF_INET6 socket, and most of them are related to security.
Yes, that's one of the things why I dislike programming for IPv6.
> moreover, all the ipv6 compliant code that i have seen until now is full
> of preprocessor switches like:
> #ifdef INET6
> /* code that handles both ipv6 and ipv4 */
> /* this code is expected to make a heavy use of get{name,addr}info
> * and to avoid inet_{ntop,pton} when possible.
> */
> #else
> /* ipv4-only (traditional) code */
> /* this code is expected to make heavy use of gethostby{name,addr}
> * inet_{ntoa,aton} etc...
> */
> #endif
That shouldn't be that way. If we wanted to handle old systems with no
get{name,addr}info support that should be tested by configure (or something
like that) and not based on INET6 (BTW, I prefer to write a little wrapper
around gethostby*, instead of the #ifdef's)
> this is NOT AF-indipendent programming, as you have correctly pointed out.
> that's the point. RFC2553 focuses only on ipv6 and ipv4, and its main
> purpose is to extend the BSD API in order to make the transition to
> ipv6 as painless as possible.
> unfortunately, it has completely missed the point. by stating that it's
> possible to receive ipv4 traffic with AF_INET6 sockets, RFC2553 has
> introduced a BIG number of special cases which the programmers must
> handle.
Yes, and I want to make that optional, so the special cases are not needed.
> programming ipv6-compliant software in the RFC2553-compliant way is
> quite a nightmare. if you have some experience in porting apps to ipv6
> under linux (which is, as you state, a RFC2553-compliant OS), you sure
> know what i am talking about.
Yes, that's what has led me to work on this draft.
> > Deprecate IPv4 mapped addresses
> > Maybe the time for IPv4 mapped addresses is over, maybe that was a
> > good mechanism to get things to start rolling but it's time to grow up
> > and left them.
> i would be the best thing to do, IMHO. if we wish to achieve true
> AF-indipendence, we have to cut all the relationships between different
> AF. AF_INET6 sockets shouldn't have any relation with AF_INET sockets.
> it should't be possible to receive ipv4 traffic on a AF_INET6 socket.
I'd like to do that too, but there is yet too much work done based on
that mapping, so it's not reasonable to expect that being possible.
> > But, there is too much work done in the IPv6 centric way, so maybe it
> > isn't prudent to throw them all at once.
> i do not agree here. IPv4 mapped addresses should be deprecated and put in
> disuse as soon as possible.
I'd like that, but that's just impossible.
> > More magic to getaddrinfo
> > Take the Linux approach as the good one (it's the only compliant and
> > non buggy -again, talking just about the issue on topic, i won't judge
> > the general buggyness of any stack here), add a bit more (yet more!)
> > of magic to getaddrinfo so it only returns the INET wildcard sockaddr
> > when the kernel has no support for IPv6, and then the buggy stacks
> > could be corrected with no loss of features and the unworkable one
> > would get workable.
> i don't understand you here. for a true AF-indipendent programming style,
> getaddrinfo should return a ready-to-be-bound address for every AF.
> for all those addresses, it should be possible to call bind without any
> conflicts.
I'm proposing as a (very undesirable) solution that getaddrinfo worked as
you explained before.
> > Add a provision for double stack implementations
> > RFC 2553 targets the dual stack systems, where there is one stack that
> > implements both IPv4 and IPv6 protocols.
> > If the RFC had a little comment telling that there is allowed to have
> > systems with two isolated stacks, and that the IPv4 to IPv6 mapping
> > may be absent on these systems, the non compliant implementations
> > would become compliant and we would have some implementations
> > compliant, non buggy and easy to work with AF-independently.
> that's nonsense. compliant stacks would not be AF-independent, but
> quasi-compliant stacks would be.
I like better the noncompliant systems, but standard compliance is too
important to discard it. So I hope to change the standard to accept
the actually noncompliant behaviour.
HoraPe
---
Horacio J. Pe�a
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
