Subject: Re: Draft on IPv6 source address selection socket API

From: Samita Chakrabarti <[email-masked]>
Date: Thu, 13 Mar 2003 11:25:04 -0800 (PST)

Thanks for your comments.

> My first comment is that an API in that space is badly needed,
> so I fully support an effort to standardize such an API.
>

Yes, I agree. 
 
> My second comment is on the suggested API itself.
> Some of the rules in the address selection RFC
> are common sense, some are really 'suggested practices'
> that make sense in common cases, but not in all.
> So, I would like to see an API that enable
> to change ALL the rules in the second category.
> for example: prefer larger scope, prefer v4 over v6,....
> 

The draft lists whether PREFER_LARGEST_SCOPE and other flags
would be considered in the 'Open Issues' section. Your points
are valid. It may make sense to define a set of additional useful
 flags intially; working group input would be valuable in this
 case.

>  From your list of open question, I would like to see
> a 'request foo' option too. An application may
> say: 'request non IPv4-mapped', or reqest 'global'.
> If such an address in not available at the time,
> the syscall could return an error.
> 

In the second bullet of 'Open Issues', it asks if we need to define
"REQUIRE" flags in addition to "PREFER". I think you are asking
the same. Currently "PREFER" means that the application sends its
choice of PREFERENCE to the kernel, if kernel cannot provide that, the
application gets to use the default system assigned values.

> Another thing I would like to see would be some tie-breakers,
> when a application could say: 'all things beeing equal, I rather like to 
> use x'

Can you provide some concrete example and how this would be
useful in applications ?

Thanks,
-Samita

> Samita Chakrabarti wrote:
> 
> >We have had discussion about requirement of having a socket-API
> >on source address selection, in this alias.
> >
> >A draft has been submitted to address source address selection at
> >the per-socket (and per apps) basis. Currently it discusses preferences
> >of source address selection by the application for privacy addresses,
> >mobileipv6 addresses and Cryptographically generated addresses.
> >Thus the application can reverse the sense of default source address
> >selection by using the proposed APIs.
> >
> >
> >Please provide your comments/feedback on the alias and to the authors.
> >
> > 
> >We have listed some open issues in the draft as well to seek suggestions
> >from the working group for further enhancement of the draft.
> >
> >The draft will be available in the draft directory shortly, however, I am
> >including the text file here.
> >
> >
> >Thanks,
> >-Samita
> >  
> >
> >------------------------------------------------------------------------
> >
> >
> >
> >
> >
> >
> >
> >INTERNET-DRAFT                                    Erik Nordmark 
> >Expires: August, 2003                             Samita Chakrabarti 
> >                                                  Sun Microsystems, Inc.
> >					          Julien Laganier
> >                                                  Sun Microsystems, Inc.
> >	                                          LIP / ENS-Lyon
> >						  February, 2003
> >
> >              IPv6 Socket API for source address selection
> >
> >
> >
> >Status of this Memo
> >
> >   This document is an Internet-Draft and is subject to
> >   all provisions of Section 10 of RFC2026.
> >
> >   Internet-Drafts are working documents of the Internet Engineering
> >   Task Force (IETF), its areas, and its working groups.  Note that
> >   other groups may also distribute working documents as Internet-
> >   Drafts.
> >
> >   Internet-Drafts are draft documents valid for a maximum of six months
> >   and may be updated, replaced, or obsoleted by other documents at any
> >   time.  It is inappropriate to use Internet-Drafts as reference
> >   material or to cite them other than as "work in progress."
> >
> >   The list of current Internet-Drafts can be accessed at
> >   http://www.ietf.org/ietf/1id-abstracts.txt
> >
> >   The list of Internet-Draft Shadow Directories can be accessed at
> >   http://www.ietf.org/shadow.html.
> >
> >   This Internet Draft expires August, 2003.
> >
> >Copyright Notice
> >
> >   Copyright (C) The Internet Society (2003).  All Rights Reserved.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >draft-chakrabarti-ipv6-addrselect-api-00.txt                    [Page 1]
> >
> >INTERNET-DRAFT  IPv6 Socket API for source address selection  Feb., 2003
> >
> >
> >Abstract
> >
> >    The IPv6 default address selection document describes the rules for
> >    selecting default source address by the system and indicates that
> >    the applications should be able to reverse the sense of system
> >    preference of source address selection for that application through
> >    possible API extensions. However, no such socket APIs exist in the
> >    basic or advanced IPv6 socket API documents. Hence this document 
> >    specifies socket level options to prefer a particular source 
> >    address as per the choice of the applications. It also discusses 
> >    implications on the name-to-address translation API that performs
> >    part of the default address selection. The socket APIs described in
> >    this document will be particularly useful for Mobile IPv6 enabled
> >    applications and other IPv6 applications which want to choose 
> >    between temporary and public addresses, CGA (cryptographically 
> >    generated addresses) and non-CGA addresses etc..
> >    
> >
> >
> >
> >Table of Contents
> >
> >    1. Introduction ...........................................  3
> >
> >    2. Example Usage ..........................................  4
> >
> >    3. Changes to the Socket Interface ........................  5
> >
> >    4. Changes to the protocol-independent
> >              nodename  translation ............................ 6
> >
> >    5. IPv4-Mapped IPv6 Addresses .............................. 7
> >
> >    6. Security Considerations ................................. 7
> >
> >    7. Open Issues ............................................. 7
> >
> >    8. References .............................................. 8
> >    
> >    9. Acknowledgements ........................................ 8
> >
> >   10. Authors' Addresses ...................................... 9
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >draft-chakrabarti-ipv6-addrselect-api-00.txt                    [Page 2]
> >
> >INTERNET-DRAFT  IPv6 Socket API for source address selection  Feb., 2003
> >
> >
> >1.  Introduction
> >
> >   This document defines socket extensions to support the non-default
> >   choice of source address by the applications. The IPv6 default
> >   address selection [1] document has specified the rules for system
> >   default source address selection for an outbound IPv6 packet.
> >   Privacy considerations [6] have introduced "public" and "temporary"
> >   addresses. IPv6 Mobility [3] introduces "home address" and "care-
> >   of-address" definitions in the mobile systems. Although it is 
> >   desirable to have default algorithms for the system to choose the
> >   source address of the outgoing IPv6 packet, an application may want
> >   to reverse that rule for efficiency and other application specific
> >   reasons. Currently IPv6 socket API extensions does not provide a
> >   mechanism to choose a particular source address other than simple
> >   bind() operation. The bind() operation allows an application to
> >   specify a particular source address. Thus in order to use bind() 
> >   the application itself must make sure that the source address is
> >   appropriate for the destination address (e.g., with respect to the
> >   interface used to send packets to the destination). The application
> >   also needs to make sure about the appropriate scope of source address
> >   with respect to the destination address and so on. The mechanism
> >   presented in this document allows the application to specify 
> >   attributes of the source addresses it prefers while still having the
> >   system do the rest of the default address selection.
> >
> >   A socket option has been deemed useful for this purpose, as it
> >   enables an application ability to make a choice of source address at
> >   per-socket basis as well as it can provide flexibility of enabling
> >   and disabling choice of source addresses in non-connected sockets.
> >   The socket option uses a set of flags for source address preferences.
> >   Since source address selection and destination address ordering need
> >   to be partially implemented in getaddrinfo() [2] the corresponding
> >   set of flags are also defined for that routine.
> >
> >   Thus this document introduces different flags for source address
> >   selection that can be used by the applications for Mobility [3],
> >   Privacy Extension [6] and CGA [7] scenarios. In future, more flags
> >   can be added to designate a choice for a certain type of source
> >   address as the needs may arise.
> >
> >   
> >   The approach in this document is to allow the application to specify
> >   preferences on source addresses and not to be able to specify hard
> >   requirements. Thus for instance an application can specify that it
> >   prefers temporary addresses but if no temporary addresses are 
> >   available to the default address selection algorithm, a public
> >   address would be chosen instead.
> >
> >
> >
> >
> >
> >
> >
> >draft-chakrabarti-ipv6-addrselect-api-00.txt                    [Page 3]
> >
> >INTERNET-DRAFT  IPv6 Socket API for source address selection  Feb., 2003
> >
> >
> >
> >   Furthermore, the approach is to define two flags for each purpose, 
> >   so that an application can specify either that it prefers 'X' or
> >   prefers 'not X', or it can choose not to set either of the flags
> >   relating to 'X' and leave it up to the system default, perhaps while 
> >   specifing its preferences for some other attribute of the source
> >   addresses.
> >
> >
> >2. Example Usages 
> >
> >
> >   The examples of usages discussed here are limited to applications
> >   supporting Mobile IPv6, IPv6 Privacy Extensions and Cryptographically
> >   Generated Addresses. Address selection document [1] recommends that
> >   home addresses should be preferred over care-of-address when both are
> >   configured. However, a mobile node may want to prefer care-of-address
> >   as source address for DNS query in the foreign network as it normally
> >   means a shorter and local return path compared to the route via the
> >   mobile node's home-agent when the query contains home-address as 
> >   source address. Another example is IKE application which requires
> >   care-of-address as its source address for the initial security 
> >   association pair with Home Agent [3] while the mobile node boots up
> >   at the foreign network and wants to do the key exchange before a
> >   successful  home-registration. Also a Mobile IPv6 aware application 
> >   may want to toggle between home-address and care-of-address
> >   depending on its location and state of the application. It
> >   may also want to open different sockets and use home-address as
> >   source address for one socket and care-of-address for the others. 
> >
> >   In a non-mobile environment, similarly an application may prefer to
> >   use temporary address as source address for certain cases.
> >   By default, the source address selction rule selects "public"
> >   address when both are available. For example, an application
> >   supporting web browser and mail-server may want to use "temporary" 
> >   address for the former and "public" address for the mail-server as a
> >   mail-server may require reverse path for DNS records for anti-spam
> >   rules.
> >
> >
> >   Similarly, a node  may be configured to use the cryptographically
> >   genenerated addresses by default, but an application may prefer not
> >   to use it.  For instance, fping, a debugging tool which tests
> >   basic reachability of multiple destinations by sending packets in
> >   parallel, may find that the cost and time incurred in proof-of-
> >   ownership by CGA verification is not justified.
> >   On the other hand, when a node is not configured for CGA as default, 
> >   an application may prefer using CGA by setting the socket option. It 
> >   may subsequently verify that it is truly bound to a CGA by first 
> >   calling getsockname() and then recomputing the CGA using the public
> >   key of the node.
> >   
> >
> >				 
> >
> >
> >
> >
> >draft-chakrabarti-ipv6-addrselect-api-00.txt                    [Page 4]
> >
> >INTERNET-DRAFT  IPv6 Socket API for source address selection  Feb., 2003  
> >
> >
> >3.  Changes to the Socket Interface
> >
> >    IPv6 Basic API [2] defines socket options for IPv6. This document
> >    adds a new socket option at the IPPROTO_IPV6 level. This socket
> >    option is called IPV6_SRC_PREFERENCES. It can be used with
> >    setsockopt() and getsockopt() calls. This socket option takes a
> >    32bit unsigned integer argument. The argument consists of a number
> >    of flags which indicate the choice of source address selection.
> >
> >    The flags defined in this document are:
> >
> >    IPV6_PREFER_SRC_HOME
> >    IPV6_PREFER_SRC_COA
> >    IPV6_PREFER_SRC_TMP
> >    IPV6_PREFER_SRC_PUBLIC
> >    IPV6_PREFER_SRC_CGA
> >    IPV6_PREFER_SRC_NONCGA
> >
> >
> >    The following example illustrates how it is used:
> >
> >    uint32_t flags = IPV6_PREFER_SRC_COA;
> >
> >    if (setsockopt(s, IPPROTO_IPV6, IPV6_SRC_PREFERENCES,
> >	    (char *) &flags, sizeof (flags)) == -1) {
> >     	   perror("setsockopt IPV6_SRC_REFERENCES");
> >    }
> >
> >
> >    When the IPV6_SRC_PREFERENCES is successfully set with setsockopt(),
> >    the option value given is used to specify source address for any 
> >    connection initiation through the socket and all subsequent packets
> >    sent via that socket. If the option is not set, the system selects
> >    a default value. Setting conflicting flags at the same time results
> >    in the error EINVAL.
> >
> >    It is recommended that the application does a getsockopt() prior
> >    calling to setsockopt() call so that it can save the existing
> >    source address preference value, in the cases when the application
> >    might need to restore the preferences.
> >      
> >
> >
> >
> >    The constants mentioned in this section are defined in 
> >    <netinet/in.h>.
> >
> >
> >
> >
> >
> >
> >
> >draft-chakrabarti-ipv6-addrselect-api-00.txt                    [Page 5]
> >
> >INTERNET-DRAFT  IPv6 Socket API for source address selection  Feb., 2003  
> >
> >
> >
> >4.  Changes to the protocol-independent nodename translation
> >
> >    Section 8 of Default Address Selction [1] document indicates about
> >    possible implementation strategy for getaddrinfo() [2]. 
> >    getaddrinfo() collects available source addresses from the network
> >    layer and then it sorts the list of source addresses as per source
> >    address selection rules. Thus if an application sets setsockopt()
> >    IPV6_SRC_PREFERENCES option to alter the default address selection
> >    rules , it must make sure that it calls getaddrinfo() with the
> >    corresponding flags specified in this section. This will ensure
> >    correct behavior of getaddrinfo() destination address selection
> >    based on the sorted list of source addresses as per the socket
> >    source address selection preferences. 
> >
> >    The following flags are added for the ai_flags in addrinfo data
> >    structure defined in Basic IPv6 Socket API Extension [2].
> >
> >     AI_PREFER_SRC_HOME
> >     AI_PREFER_SRC_COA
> >     AI_PREFER_SRC_TMP
> >     AI_PREFER_SRC_PUBLIC
> >     AI_PREFER_SRC_CGA
> >     AI_PREFER_SRC_NONCGA
> >       
> > 
> >    The above flags are ignored for the AF_INET address family. If a
> >    returned address is an IPv4 address (either as AF_INET6 when
> >    AI_V4MAPPED, or as AF_INET) then the source preference flags have
> >    no effect. 
> >
> >    If conflicting flags such as AI_PREFER_SRC_HOME and AI_PREFER_SRC_
> >    COA are set, the getaddrinfo() fails with an error EAI_BADFLAGS[2].
> >
> >     Some valid sequences of flags would be:
> >
> >     AI_PREFER_SRC_HOME | AI_PREFER_SRC_PUBLIC
> >     AI_PREFER_SRC_COA  | AI_PREFER_SRC_PUBLIC
> >     AI_PREFER_SRC_HOME | AI_PREFER_SRC_CGA
> >     AI_PREFER_SRC_HOME | AI_PREFER_SRC_NONCGA
> >     AI_PREFER_SRC_COA  | AI_PREFER_SRC_CGA
> >     AI_PREFER_SRC_COA  | AI_PREFER_SRC_NONCGA
> >
> >
> >
> >    All the constants mentioned in this section for ai_flags are defined
> >    in <netdb.h>.
> >
> >
> >
> >
> >draft-chakrabarti-ipv6-addrselect-api-00.txt                    [Page 6]
> >
> >INTERNET DRAFT   IPv6 Socket API for source address selection Feb., 2003
> >
> >
> >5. IPv4-Mapped IPv6 Addresses
> >
> >   IPv4-Mapped IPv6 addresses are not supported for setting preference
> >   on home, care-of-address, CGA, non-CGA, public or privacy auto-
> >   configured addresses as source addresses. Because they are all pure
> >   IPv6 addresses. 
> >
> >
> >6. Security Considerations
> >
> >   This document conforms to the same security implications as specified
> >   in IPv6 Basic Socket API [2] document. It is also recommended that
> >   the applications set IPV6_V6ONLY IP level socket option to permit
> >   the nodes to not process IPv4 packets as IPv4 Mapped addresses.
> >   Allowing applications to specify a preference for temporary
> >   addresses provides per-application (and per-socket) ability to use
> >   the privacy benefits of the temporary addresses.
> >
> >
> >
> >7. Open Issues
> >
> >   - Are there more flags we should define at this point in time?
> >     For instance, PREFER_LARGEST_SCOPE?
> >
> >   - Is there a need for REQUIRE flags in addition to or instead of the
> >     PREFER flags? Note that in general it isn't possible to verify 
> >     that a requirement can be satisfied until sendto() or connect()
> >     (when the destination address is known) thus this would result
> >     in late errors being reported to the application.
> >
> >   - Is there a need for "validation" functions to go with these
> >     preferences such as functions that check whether an address is
> >     a temporary address?
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >draft-chakrabarti-ipv6-addrselect-api-00.txt                    [Page 7]
> >
> >INTERNET-DRAFT  IPv6 Socket API for source address selection  Feb., 2003
> >
> >
> >8. References
> >
> >Normative references:
> >
> >[1]    Richard Draves, "Default Address Selection for IPv6", 
> >           draft-ietf-ipv6-default-addr-select-09.txt, August 6, 2002.
> >  
> >[2]    R.E. Gilligan, S. Thomson, J. Bound, J. McCann, W. R. Stevens,
> >           "Basic Socket Interface Extensions for IPv6", 
> >            draft-ietf-ipngwg-rfc2553bis-10.txt, December, 2002.
> >
> >Informative references:
> >
> >[3]    Johnson, D., Perkins, C., Arkko, J., "Mobility Support in IPv6"
> >           draft-ietf-mobileip-ipv6-20.txt, January, 2003.
> >
> >[4]    Deering, S., Hinden, R., "Internet Protocol, Version 6
> >           (IPv6), Specification", RFC 2460, Dec. 1998.
> >
> >[5]    Stevens, W. R, Thomas, M., Nordmark, E., Jinmei, T., "Advanced
> >           Sockets API for IPv6", draft-ietf-ipngwg-rfc2292bis-07.txt  
> >           April 19, 2002.
> >
> >[6]    Narten, T. and R. Draves, "Privacy Extensions for Stateless
> >       Address Autoconfiguration in IPv6", RFC 3041, January 2001.
> >
> >[7]    Montenegro, G. and C. Castelluccia, "Statistically Unique and
> >       Cryptographically Verifiable (SUCV) Identifiers and Addresses.", 
> >       NDSS 2002, February 2002.
> >
> >[8]    Castelluccia, C. and G. Montenegro, "Securing Group Management
> >       in IPv6 with  Cryptographically Generated  Addresses",
> >       draft-irtf-gsec-sgmv6-01 (work in progress), July 2002.
> >
> >
> >
> >9. Acknowledgements
> >
> >   The authors like to thank members of mobile-ip and ipv6 working 
> >   groups for useful discussion on this topic. Richard Draves and
> >   Dave Thaler suggested that getaddrinfo also needs to be considered
> >   along with the new socket option. Gabriel Montenegro suggested that
> >   CGAs may also be considered in this document. Thanks to Alain Durand,
> >   Renee Danson, Alper Yegin and Francis Dupont for useful discussions.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >draft-chakrabarti-ipv6-addrselect-api-00.txt                    [Page 8]
> >
> >INTERNET-DRAFT  IPv6 Socket API for source address selection  Feb., 2003
> >
> >
> >
> >10.  Authors' Addresses
> >
> >
> >    Erik Nordmark
> >    Sun Microsystems Laboratories, Europe
> >    180 Avenue de l'Europe
> >    38334 Saint Ismier, France
> >    Email: [email-masked]
> >
> >
> >
> >    Samita Chakrabarti
> >    Sun Microsystems, Inc. 
> >    4150 Network Circle 
> >    Santa Clara, CA 95054, USA
> >    Email: [email-masked]
> >
> >
> >
> >    Julien Laganier 
> >    Sun Microsystems Laboratories, Europe
> >    180 Avenue de l'Europe
> >    38334 Saint Ismier, France
> >    Email: [email-masked]
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >draft-chakrabarti-ipv6-addrselect-api-00.txt                    [Page 9]
> >
> >  
> >
> 
> 
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page:                      http://playground.sun.com/ipng
> FTP archive:                      ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [email-masked]
> --------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Alain Durand <[email-masked]>
Date: Thu, 13 Mar 2003 12:48:34 -0800

>Can you provide some concrete example and how this would be
A node with 2 interfaces, configured with global addresses.
The 2 interfaces have different properties (fast/slow, free/expensive,...)
and the apps knows about that. The App would like to say
something like "All things equal, prefer interface X".

    - Alain.