On Fri, 22 Jun 2001 [EMAIL PROTECTED] wrote:
> 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:
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?
if so, your code (which is truly AF-indipendent) is not RFC2553-compliant.
or better, the API specified by RFC2553 is not AF-indipendent.
> 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.
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
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.
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.
> Conclusion: there's no good implementations of RFC 2553
>
> If my classification is not exhaustive and there is a non-buggy, fully
> compliant implementation of the RFC 2553 bind semantics that doesn't
> cause problems to programs written in an AF independent way, I'd be
> very pleased to know them and learn how they have avoided all that
> problems. But I believe that the cause is that the RFC is not very
> good on that point and should have more work done on that.
you are absolutely right.
> Possible solutions
[...]
> 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.
> Itojun has mentioned in their ipv6-transition-abuse draft many other
> problems that the IPv4 mapped addresses have.
that's another reason for removing IPv4 mapped addresses.
> 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.
> Deprecate IPV6_V6ONLY, add IPV6_ACCEPTV4MAPPED option
>
> Then the IPv6 sockets would have to be explicitly allowed to accept
> IPv4 connections. So the programs that use the IPv6 centric way have
> to be modified a bit, but the buggy implementations and the unworkable
> one could be corrected without losing features. Just making
> IPV6_V6ONLY default to on would have the same results.
no. all of this should also be deprecated, IMHO. AF_INET6 sockets should
be IPV6_V6ONLY and there shouldn't be any chance to change this behaviour.
> 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.
> 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.
IMHO, a best choice would be to re-define the behaviour of AF_INET6
sockets in order to cut all the relationships with ipv4.
AF-indipendence would be a great achievement.
--
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]
--------------------------------------------------------------------
