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

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

JINMEI Tatuya / çæéå wrote:
> As requested, here are my comments about the addrselect-api draft.
>
> First of all, I must say I'm not particularly fascinated by this API.
> As (I think) I said before, I believe this can be useful in very
> limited situations only (especially because applications need to be
> modified - I generally agree with Francis on this point), and most
> applications (and application writers) wouldn't be bothered with using
> the additional feature.  In fact, the only people I've ever seen who
> expressed interest in this API are mobile IP(v6) implementors,
> expecting this API can be used in their mobile IP(v6) specific
> implementations (e.g., ones that negotiate with the home agent).  I
> respect that the draft provides one section showing usage examples,
> but these are not convincing enough to me.

FWIW To me, the public/temporary address knob is just as important, if 
not more important than the home/coa knob.


> 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.
>
>   Is it really okay to provide an easy knob for applications to
>   "reverse" the logic despite the strong requirement?  And, I'm
>   actually not sure in which (practical) case we want to specify the
>   non default rule.  The last paragraph of Section 3 provides an
>   example, but it's not very specific, and cannot be used as a
>   practical example.
>
>   At the very least, I'm not even sure how the logic of Rule 2 is
>   modified if we specify IPV6_PREFER_SRC_SCOPE.  The rule defined in
>   RFC3484 is:
>
>     Rule 2:  Prefer appropriate scope.
>     If Scope(SA) < Scope(SB): If Scope(SA) < Scope(D), then prefer SB
>     and otherwise prefer SA.  Similarly, if Scope(SB) < Scope(SA): If
>     Scope(SB) < Scope(D), then prefer SA and otherwise prefer SB.
>
>   How would this look like with IPV6_PREFER_SRC_SCOPE?

FWIW the semantics of IPV6_PREFER_SRC_SMALLSCOPE would be to invert rule 
2, so that the algorithm instead of prefering the smallest scoped source 
which has a scope of at least the destination address, it would prefer 
the largest scoped source which has a scope which is at most the same as 
the destination address.

But, like you, I question the utility of this.

> SEMI SUBSTANTIAL COMMENTS
>
> 4. Considering the background motivation of the advanced API, I think
>    we should also provide an ancillary-data object corresponding to
>    the proposed socket option in order to control the address
>    selection policy per-packet basis with a single system call (i.e.,
>    sendmsg()).

We can definitely add that.
Although I sometimes wonder how useful ancillary data options are on the 
send side (they are critical on the receive side, so that the 
application can see what was "part of" each received datagram).

> 5. (AFAICS) This document does not explicitly define the return value
>    of getsockopt(IPV6_ADDR_PREFERENCES).  Even though it's pretty
>    trivial, I believe an API specification should generally provide
>    such 'trivial' things very clearly and explicitly.

Do you mean the actual return value (which is 0/-1 according to the Open 
Group standard for getsockopt), or what value is returned in the *optval?

> 6. [1st line of page 4 (continued from page 3)]
>
>      [...]  Since source address selection and destination address
>      ordering need to be partially implemented in getaddrinfo() [3] the
>      corresponding set of flags are also defined for that routine.
>
>    I think this is too strong.  Although destination address ordering
>    (selection) would typically be implemented through getaddrinfo(),
>    the selection rules themselves are quite general and could be
>    realized in some other way.

Yes, the point is that the API shouldn't constrain or assume which parts 
of address selection is implemented in getaddrinfo() or in the kernel. 
We'll make this more clear.
Something along the lines of "should not assume that implementations 
implementa particular aspect of RFC 3484 in getaddrinfo"


> 7. [3rd paragraph of Section 5]
>      [...] Thus when
>      AI_PREFER_SRC_TMP is set , getaddrinfo() returns DA before DB and SA
>      before SB likewise.
>
>    I don't understand this sentence.  What does 'and SA before SB
>    likewise' mean?

Oops. I should say
"Then SA is used when communication to DA, thus the temporary
address gets preferred."


> 8. [page 12 (Section 5), just after the flag list]
>
>      The above flags are ignored for the AF_INET address family as the
>      address selection algorithm defined in section 5 of [1] only applies
>      to the IPv6 addresses.
>
>    This is not really true.  RFC3484's destination address selection
>    considers both IPv4 and IPv6 addresses (See Section 3.2 of
>    RFC3484).

The statement was try when there was no DST flags.
So we can correct it to say "the above SRC flags ... as the source 
address selection ..."

>    Besides, even if RFC3484 only considered IPv6 addresses, the API
>    statement would still not be very accurate: what if we have
>    IPv9?:-)

Currently the document is silent on AF_INET9 semantics; did you want it 
to say something specific about it? ;-)

> 9. [first paragraph of Section 6]
>
>      An application only needs to call getsockopt() prior calling
>      setsockopt() if the application needs to be able to restore the
>      socket back to the system default preferences.
>
>    This seems odd.  Shouldn't the application just be able to reset
>    the rules to the default by specifying the all-0 flags?  If not,
>    why do we need the sets of two flags to begin with?

We need two flags per feature in order handle getaddrinfo() without 
casting the default flags in concrete and not introducing some new
getaddrinfo_default_preferences() function.
To me it makes sense to have setsockopt work the same way conceptually 
as getaddrinfo, so as long as getaddrinfo has two flags per feature, 
then setsockopt should have the same.

With two flags then for any X/not-X pair, the semantics of setting 
neither X or not-X is a no-op.
This implies that setting no flag at all must also be a no-op.

> 10. [second code fragment shown in Section 6]
>
>    This does not seem to be very accuratete or consistent.  According
>    to manual pages (available around me), the third arguments of
>    getsockopt() and setsockopt() are 'void *' and 'const void *',
>    respectively.  On the other hand, this example code casts the
>    arguments to setsockopt() as 'char *' while it simply passes
>    'uint32_t *' to getaddrinfo().  If we ignore minor type-matching
>    issues for brevity, I'd simply remove all the cast.  If we're
>    willing to show casting for accuracy, we should be consistent and
>    use accurate casting for all the examples.

Will fix.

> 11. [second to last paragraph of Section 6]
>
>      In order to allow different implementations to do different parts of
>      address selection in getaddrinfo() and in the protocol stack, this
>      specification requires that applications set the same flags when
>      calling getaddrinfo() and when calling setsockopt().  For example,if
>      the application sets IPV6_PREFER_SRC_COA flag, it must use
>      AI_PREFER_SRC_COA flag when calling getaddrinfo().  If applications
>      are not setting the same flags the behavior of the implementation is
>      undefined.
>
>   The phrase of "the same flags" (there are two occurrences) is not
>   very accurate, since these are actually different, at least as macro
>   names.

Correct.
The same flag at the semantic level, which correspond to different flags 
for the two API parts.

But if we do a ai_preferences type field, then we can actually use the 
same flag constants in both places (IPV6_PREFER_...) if we want to. This 
would make the document shorter, and might be a simplication for the users.

> 12. [second bullet of Section 7]
>
>   What would getsockopt() return for preference flags that are not
>   supported in the system? (see also comment #5)

I think it makes sense to return the defaults per RFC 3484 and its 
future updates. Thus IPV6_PREFER_SRC_PUBLIC would be set even if 
temporary addresses are not implemented, and IPV6_PREFER_SRC_HOME set 
even if mobile IPv6 is not implemented.
But this is more from a consistency reason than by necessity; returning 
0 for those flags would be ok as well assuming the application just 
turns flags on and off.

> 13. [third bullet of Section 7]
>
>       If an implementation supports both stream and datagram sockets, it
>       should implement the address preference mechanism API described in
>       this document on types of sockets.
>
>   I simply don't understand what this means...could you elaborate?
>   (BTW: perhaps 'on types of sockets' should be 'based on types of
>   sockets'?  Even if so, I still don't understand what this means,
>   though)

Oops - should say "on both types of sockets."


> 14. [second to last paragraph of Section 8]
>
>      Other destination rules (#4-prefer home address; #7-prefer native
>      interfaces) could have been applicable.  But the problem is that the
>      local system does not know whether a destination address is a tunnel-
>      address for destination rule #7.  It can only know for sure if the
>      destination address is one of its own.
>
>   I don't think this is really correct.  First, destination rule #7 is
>   'Prefer native transport' not 'interfaces'.

Correct. Will fix.

>  Second, the
>   implementation can syntacatically identify 'non-native' destinations
>   in some cases (e.g., for 6to4 addresses). 

Yes, but we have the preference table to handle that, without any 
explicit rules on the nativeness of the transport.
(It might be a defect in 3484 that it has both the "prefer native 
transport" and the 6to4 addresses in the table. What happens when they 
conflict?)

> Third, at least in
>   theory, the local implementation (even an application) could
>   identify the outgoing interface for a given destination, and might
>   be able to identify it's a tunneling interface.  I do not
>   necessarily require this API consider destination rule #7, but the
>   "excuse" for not doing so should be accurate and convincing.

Sure, at the local end.
But the text in RFC 3484 can be interpreted to mean that by magic the 
host can determine whether there is some IPv6 in IPv4 tunnel somewhere 
between the host and a particular destination address. It can only do 
that if 1) the destination syntactically indicates it does tunneling as 
in the case of 6to4, or 2) the tunnel starts on the host itself.

What do you suggest we clarify to make this more accurate?

> 15. [Section 10]
>   Do we really need (standardize) a separate function like
>   inet6_is_srcaddr()?  Perhaps I'm pretty dubious about this
>   just because I'm dubious about the usefulness of the entire API in
>   the first place, but I'd suggest confirming this point with other
>   implementers, particularly with those who are interested in this
>   API.

I guess the feedback we've gotten doesn't capture whether or not it is 
necessary; only whether or not it is accurately described.
I don't recall anybody else arguing against this function. So I'm 
interested in the opinion of others.

And since you're dubious about the entire API, I guess you could argue 
we should remove all the other aspects of the API as well ;-)
Can't do it a function at a time.

> 16. [last paragraph of page 20]
>      The function returns true when srcaddr corresponds to a valid address
>      in the node and that address type satisfies the preference flag(s).
>
>   I don't think 'that address type satisfies the preference flag' is
>   well-defined, although it is intuitively understandable.  Please be
>   more precise (c.f. comment #5).  There may actually be subtle cases:
>   e.g., what does it mean if I specify IPV6_PREFER_SRC_SMALLSCOPE as
>   'flags'?  That is, 'small' is only meaningful when we are comparing
>   multiple things, while this function takes only one address.  I
>   suspect this indicates we should reconsider the function design.

We tried to make it clear which flags can and can not be tested, but I 
see the text is still not clear on this. The SCOPE aspects can not be 
tested with inet6_is_srcaddr(), but can be tested with 
INET6_IS_LINKLOCAL etc.

> 17. [regarding inet6_is_srcaddr() in general]
>
>   If we really need this function (see comment #15), I believe we
>   should clearly separate error cases, i.e., we should not overload
>   the 'false' return value.  This might sound a matter of taste, but I
>   believe it's a common and well-known practice.

OK.

There are two different ways to do this and I'd appreciate your opinion 
on which one to choose.
1. A function which returns 3 values: true, false, failure. E.g
	int inet6_is_srcaddr(struct sockaddr_in6 *srcaddr,
		uint32_t flags);
   with 3 defined constans for the 3 possible return values.
   A special case is true=1, false=0, fail=-1.
2. A function which returns 0/-1 for ok/fail (like most library calls), 
and has an extra result parameter for the true/false response. For example,
	int inet6_is_srcaddr(struct sockaddr_in6 *srcaddr,
		uint32_t flags, int *resultp);


     Erik


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