Subject: Re: IPv6 Issues

Re: IPv6 Issues

From: Daniel Stenberg <daniel_at_haxx.se>
Date: 2005-04-11

On Sun, 10 Apr 2005, codemastr wrote:

> For the most part, IPv6 support seems to be coming along rather nicely. I'm
> starting to begin work on the "addrinfo" (getaddrinfo/getnameinfo) API now,
> seeing as how, at least in my tests, the current functions work pretty well
> with IPv6.

Cool indeed! I haven't yet had much time to try them out... :-(

> 1.) Is inet_net_pton.h the proper place for the in6_addr and friends
> compatibility stuff?

Nah.

> Perhaps a better solution would be to introduce an ipv6.h or something to
> that effect?

Would be better yes. I figure we need ot have that made public and we need to
have configure decide what structs and defines it should include... Right?

> The first thing to note is the use of socklen_t. Not all systems provide
> this type which means that ares.h would need even more system-specific
> defines, or we could just use int but then it is "incompatible" with the
> system getnameinfo.

IMO, we should provide a socklen_t for those that don't have it. In a similar
spirit how we provide structs and defines for them.

> As a result, I was thinking:
>
> void ares_getnameinfo(ares_channel channel, const struct sockaddr *sa,
> socklen_t salen, int flags, ares_nameinfo_callback callback, void *arg);
>
> This models the syntax of the other functions c-ares provides. However,
> there is one hitch here. getnameinfo uses the host/serv parameters to
> determine what to return. For example, if I specify NULL as serv, then it
> means that I only want a host and therefore no service lookup is done.
> However, since ares_getnameinfo does not require the user to specify
> buffers, this can't be handled the same way. Does anyone have any
> suggestions as to how we could handle this? Perhaps we should introduce two
> new flags? NI_ARES_HOSTLOOKUP and NI_ARES_SERVICELOOKUP?

I think that sounds like a good approach. Either that, or an additional
"aresflags" argument, but I think your suggestion feels better.

> 3.) The getnameinfo function has several extensions. I think it would be a
> good idea to support as many of these as possible as it makes switching to
> c-ares easier.

Yes, but focus should be on basics first, as then we can easily work on
extending and fixing that later on.

> The problems come in when looked at in light of the fact that these rely on
> OS specific features. To lookup a service name, we use the getservbyport
> function. Most OSes have no support for SCTP/DCCP. Therefore, a call with
> "sctp" specified will most likely always fail. It won't result in any error
> condition, but it will mean that the call will result in no lookup taking
> place on many systems. So on some systems it will work, on some it will not.

I guess the function simply will have return failure when a given flag bit is
set and cannot be acknowledged/used by c-ares.

> The problem is a bit worse with scope ids. The sockaddr_in6 structure seems
> to have a very ambiguous definition. Two members of this structure seem to
> be particularly suspect, sin6_len and sin6_scope_id. The latter is the
> member that would hold the scope information needed for NI_WITHSCOPEID.
> Furthermore, looking up interfaces is not exactly standard either. According
> to RFC3493 (the same one that defines the addrinfo stuff), there is a new
> function, if_indextoname that we would use to resolve this information. Not
> all systems have this function. So there are two implementation issues here.
> 1.) Does the system even have a sin6_scope_id? and 2.) Does it have
> if_indextoname? Making autoconf checks for both of these is very easy, but
> the issue becomes cross-OS support. On some OSes, NI_WITHSCOPEID will work
> great, on others it won't be able to resolve it to a name and will instead
> return the numeric form. Basically, the problem is that depending on which
> OS you're using c-ares you might get different results from a call to the
> function. If that's OK, then I'll go ahead and add support for it. If not,
> then we need to decide what to do.

Hm, then we are back on providing our own structs that have all the members
and fields we want. I don't think that is such a bad idea anyway, since
c-ares' functions will not (and cannot) be used intermixed with other name
resolving functions anyway. I mean, for example, passing c-ares' getaddrinfo()
results to freeaddrinfo() will never be a good idea.

> 4.) How do we want to handle all the checks for NI_* (and AI_*)? There are
> like 20-30 constants defined by getnameinfo and getaddrinfo that we'll need
> to check for. Do you think it is a good idea to add that many new autoconf
> checks just to determine if the macros exist?

I'm more and more beginning to lean towards providing a totally separate name
space for all these things, like prefixes with ARES or similar, to once and
for all address these issues.

> 5.) We still need to decide a way to return error codes. Do we want to
> implement equivalents to the various RFC3493 defined codes, or do we want to
> just have a catch-all "bad argument" code?

My opinion: start as easy as possible and note the possible improvements in a
TODO or KNOWN_BUGS document to get worked on later.

-- 
   c-ares -- my preferred DNS asynch resolver library
_______________________________________________
http://cool.haxx.se/mailman/listinfo/c-ares
Received on Mon Apr 11 12:58:55 2005