Subject: Re: comments on address selection API

From: Samita Chakrabarti <[email-masked]>
Date: Tue, 7 Oct 2003 20:03:17 -0700 (PDT)

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-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Samita Chakrabarti <[email-masked]>
Date: Tue, 7 Oct 2003 18:41:54 -0700 (PDT)

Proposals:

Case 1)

 Case 2)

 Case 3)

                               

                     
  Thanks,
  -Samita