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

[Erik Nordmark <erik.nordmark at sun.com>]

Jinmei,

Thanks for your careful comments on the draft.

>    So, if possible, I'd like to realize the API's goal without messing
>    ai_flags further.  I admit this would be difficult in the current
>    interface to getaddrinfo() though.  At least I don't have a clear
>    idea about how to do that.  Possible random thoughts at this moment
>    (while those are not a perfect solution) include:
>    - reduce the number of additional flags by the '1 flag per rule'
>      approach (comment #1)
>    - add another member to the addrinfo structure for additional
>      (particularly protocol dependent) flags.  note that we could do
>      this without breaking (binary) backward compatibility since
>      multiple addrinfo structure are combined as a linked list.

That is a good idea, but I think we still need to define one flag in 
order to provide compatibility for unmodified applications (at the 
binary as well as source level). I'd like you comments on the approach 
below:

We add a field to the struct addrinfo (to the end so that the offsets of 
the existing fields are not changed, since this would break existing 
binaries) called ai_preferences.

In this ai_preferences we can then put all the preference related flags.

We also define a single new AI_ flag, call it AI_PREFERENCES. This flag 
indicates that the application has initialized the ai_preferences field 
(either to zero, or set some of the preferences flags).

The getaddrinfo() implementation will only look for flags when 
AI_PREFERENCES is set; this avoids looking in a ai_preferences field 
that was not initialized by the application (to provide compatibility 
for old applications, or those that do not wish to express any preferences).

This means that struct addrinfo gets larger, but that will not cause any 
applications to break, since they use freeaddrinfo() to free the 
returned list of addrinfo structures.

> 3. I suspect the necessity of IPV6_PREFER_SRC_{LARGE,SMALL}SCOPE.
>    Those might actually be even harmful.  The API draft says these
>    correspond to Rule 2 of the source address selection defined in
>    RFC3484.  But the RFC says:
>
>      Rule 2 (prefer appropriate scope) MUST be implemented and given high
>      priority because it can affect interoperability.

In the past there was requests to add flags for the SCOPE, for both 
source and destinations. I can't say I'm a big fan of these flags.

If there is consensus that we don't need them (Hint: those that want
*PREFER_*_SCOPE should speak up now), I don't have a problem dropping them.

I'll comment on your other points in a separate mail once we can get 
past the above issues.

   Erik

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------