The co-authors have discussed Sebasiten's issues off-line and here
is what we decided on the modification in the next version of the draft.
Let's close it on this alias. Please include the folks on the CC list on
your reply, thanks.
In summary, the issues were:
1) IPV6_PREFER_SRC_TUNNEL, IPV6_PREFER_SRC_NATIVE and their
corresponding AI_* flags are unintuitive, because there is
no source address selection rule that maps to destination
address selection rule 7 (prefer native transport).
2) IPV6_PREFER_SRC_*SCOPE flags are not required to set,
because it can be handled by rule 2 for source address selection
(prefer appropriate scope) automatically by default SAS
rules.
3) AI_PREFER_SRC_*SCOPE flags don't make sense as they don't map
to destiantion address selection rules (rule2-prefer matching scope,
rule8- prefer smaller scope)
> I have an additional comment on the draft relating to the four new
> AI_PREFER_* getaddrinfo() flags (new in version 1 of the draft).
>
> AI_PREFER_SRC_LARGESTSCOPE /* Prefer largest scope */
> AI_PREFER_SRC_LOWERSCOPE /* Prefer lower than largest scope */
> AI_PREFER_SRC_TUNNEL /* Prefer address of tunnel interface */
> AI_PREFER_SRC_NATIVE /* Prefer native IPv6 address */
>
> I don't know if this is the right place to be defining these
> preferences. By defining these flags, wouldn't we be suggesting that
> the control of these two destination address selection rules (rules 7
> and 8) belongs to application developers? Preferring larger scope
> destinations rather than smaller scope destinations seems like a
> situational run-time preference, and same with preferring tunnel
Proposals:
Case 1)
Erik pointed out that you can't tell whether the peer has associated
a particular address with a tunnel interface or not. Although 6to4
addresses are distinguishable but that is not true for other types of
tunnels. Also this one cannot control preference of tunnels if multiple
types of tunnels exist ( which still needs to be done by preference table)
Moreover, choice of interface for destination address could be a
function of routing behavior in the system as well. Thus it is hard
to predict the dst addr for a tunnel using this socket option. Since
there is no rule specific to source address selection to this effect,
we decided to drop this set of flags from the API.
Decision : drop IPV6_PREFER_SRC_TUNNEL{NATIVE} and corresponding
AI* flags.
Case 2)
The draft cannot depend on a particular implementation. Thus API
draft needs to provide both socket-option flag and corresponding
AI_PREFER* flag to support different implementations. It is possible
that in some implementations, one of the operations may be a NO-OP.
Case 3)
We need to clarify and map both source address selection rule (rule#2)
and destination addr selection rules(2, 8) separately for *SCOPE.
For all other destination address selection rules, they are covered
by the RFC3484.
So the new proposal:
* change the option name from IPV6_SRC_PREFERENCES
to
IPV6_ADDR_PREFERENCES
* Socket option flags : IPV6_PREFER_SRC_LARGESCOPE
IPV6_PREFER_SRC_SMALLSCOPE
IPV6_PREFER_DST_LARGESCOPE
IPV6_PREFER_DST_SMALLSCOPE
* AI flags : AI_PREFER_SRC_*SCOPE
AI_PREFER_DST_*SCOPE
Requirements: a particular socket option flag and corresponding AI flag
must be set for a correct operation.
Thus it is advisable to set both:
IPV6_PREFER_SRC_*SCOPE | IPV6_PREFER_DST*SCOPE
and corresponding AI flags in order to see
desired results from (SAS #2, DAS #2, #8).
Thanks,
-Samita
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
