Subject: Re: comments about draft-chakrabarti-ipv6-addrselect-api-03

From: Samita Chakrabarti <[email-masked]>
Date: Thu, 20 Oct 2005 15:35:51 -0700 (PDT)

Hi Jinmei,

Thanks for bringing up this point.
Please see my comment below.

> > As requested, here are my comments about the addrselect-api draft.
> 
> One additional comment (I think this has not been pointed out by
> anyone.  sorry if not):
> 
> Using new flags for ai_flags of getaddrinfo() may have a compatibility
> issue.  RFC3493 says:
> 
>    The ai_flags field to which hints parameter points shall be set to
>    zero or be the bitwise-inclusive OR of one or more of the values
>    AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST, AI_NUMERICSERV,
>    AI_V4MAPPED, AI_ALL, and AI_ADDRCONFIG.
> 
> I personally don't think this prohibits the use of other flags, but
> some existing implementations seem to interpret this part in the
> strictest way.  Those return an error of EAI_BADFLAGS if an unknown
> flag is specified in hints.ai_flags.  getaddrinfo contained in BSD
> variants and in the "libbind" library of ISC BIND behave this way.
> For those implementations, applications that use this API extensions
> will simply not be working, which is probably what we want to avoid.
> 

It may vary implementation to implementation. I can't think of any other
way than changing the implementation to support the new API. Those 
implementations that don't support the new AI_* flag will return
EAI_BADFLAGS with getaddrinfo(). I'd say that similar could be true for
new socket options.

> However, I cannot think of any other solutions than having these
> implementations change the behavior.  So, we should probably first
> agree on what the implementation should do for unknown flags and
> describe the clarification in this document.

As you mentioned that RFC3494 already defines :

[EAI_BADFLAGS]  The flags parameter had an invalid value.

Are you implying that the document (RFC3494) should clarify that the
implementation can return EAI_BADFLAGS for unknown flag value?

If so, it makes sense to me. However, I'd interpret unknown value
as invalid value as well.

-Samita

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Mark Andrews <[email-masked]>
Date: Fri, 21 Oct 2005 08:57:39 +1000

> as invalid value as well.

	This really is only a problem when a flag is defined in the
	header file but the implementation doesn't support it or
	one of the old flags is now permitted by getaddrinfo().

	AI_ADDRCONFIG is a example of such a flag.  A little bit
	of looping addresses this however.

	Mark

#ifdef USE_GETADDRINFO
        memset(&hints, 0, sizeof(hints));
        if (!have_ipv6)
                hints.ai_family = PF_INET;
        else if (!have_ipv4)
                hints.ai_family = PF_INET6;
        else {
                hints.ai_family = PF_UNSPEC;
#ifdef AI_ADDRCONFIG
                hints.ai_flags = AI_ADDRCONFIG;
#endif
        }
        hints.ai_socktype = SOCK_STREAM;
#ifdef AI_ADDRCONFIG
 again:
#endif
        result = getaddrinfo(hostname, NULL, &hints, &ai);
        switch (result) {
        case 0:
                break;
        case EAI_NONAME:
#if defined(EAI_NODATA) && (EAI_NODATA != EAI_NONAME)
        case EAI_NODATA:
#endif
                return (ISC_R_NOTFOUND);
#ifdef AI_ADDRCONFIG
        case EAI_BADFLAGS:
                if ((hints.ai_flags & AI_ADDRCONFIG) != 0) {
                        hints.ai_flags &= ~AI_ADDRCONFIG;
                        goto again;
                }
#endif
        default:
                return (ISC_R_FAILURE);
        }

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 21 Oct 2005 08:33:49 +0900

>>>>> On Thu, 20 Oct 2005 15:35:51 -0700 (PDT), 
>>>>> Samita Chakrabarti <[email-masked]> said:

> implementation can return EAI_BADFLAGS for unknown flag value?

Not really.  I said some document (3494bis or addrselect doc or
whatever) should (1) define "unknown flags" clearly and (2) clarify
what getaddrinfo() should do if an "unknown" flag is specified.

Regarding (1), RFC3493 specifies explicit flag names: AI_PASSIVE,
AI_CANONNAME, AI_NUMERICHOST, AI_NUMERICSERV, AI_V4MAPPED, AI_ALL, and
AI_ADDRCONFIG, which could read that any flags other than those listed
are "unknown".  But perhaps the real intent is that "under flags" are
flags that the system (getaddrinfo implementation) does not support.

Regarding (2), it seems to me returning EAI_BADFLAGS is reasonable,
but I don't have a strong opinion on this point.

As for the relevance to the addrselct API, I was confused about one
point.  New applications that support this API would probably test the
availability of the flag first like this:

	hints.ai_flags = 0;
#ifdef AI_NEWFLAG
	hints.ai_flags |= AI_NEWFLAG;
#endif
	getaddrinfo(..., &hints, ..);

Thus, the problem occurs only when the flag definition and the
getaddrinfo() implementation are inconsistent (as Mark pointed out).
It would be fair to say such inconsistency is a bug and ignore such a
case.

I think it's still helpful if the addrselect document assumes the
consistency between the supported flag definitions and the
getaddrinfo() implementation.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 31 Oct 2005 04:57:42 -0800

> getaddrinfo() implementation.

We can add this to the document.

    Erik