[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 rfc5014                               
Network Working Group                                        E. Nordmark
Internet-Draft                                            S. Chakrabarti
Expires: January 13, 2006                         Sun Microsystems, Inc.
                                                             J. Laganier
                                                        DoCoMo Euro-Labs
                                                           July 12, 2005

                 IPv6 Socket API for Address Selection

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on January 13, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).


   The IPv6 default address selection document, RFC 3484, describes the
   rules for selecting source and destination IP addresses, and
   indicates that the applications should be able to reverse the sense
   of some of the address selection rules through some unspecified API.
   However, no such socket API exists in the basic or advanced IPv6
   socket API documents.  This document fills that gap by specifying

Nordmark, et al.        Expires January 13, 2006                [Page 1]

Internet-Draft    IPv6 Socket API for Address Selection        July 2005

   socket level options add new flags for the getaddrinfo() API to
   specify preferences for address selection that modify the default
   address selection algorithm.  The socket APIs described in this
   document will be particularly useful for IPv6 applications that want
   to choose between temporary and public addresses, and for Mobile IPv6
   aware applications that want to use the Care-of-address for

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.   Design Alternatives  . . . . . . . . . . . . . . . . . . . .   6
   3.   Example Usages . . . . . . . . . . . . . . . . . . . . . . .   7
   4.   Additions to the Socket Interface  . . . . . . . . . . . . .   9
   5.   Additions to the protocol-independent nodename translation .  11
   6.   Application Requirements . . . . . . . . . . . . . . . . . .  14
   7.   Implementation Notes . . . . . . . . . . . . . . . . . . . .  16
   8.   Mapping to Default Address Selection Rules . . . . . . . . .  17
   9.   IPv4-mapped IPv6 Addresses . . . . . . . . . . . . . . . . .  19
   10.  Validation function for source address . . . . . . . . . . .  20
   11.  Security Considerations  . . . . . . . . . . . . . . . . . .  22
   12.  Changes from previous version of draft . . . . . . . . . . .  23
   13.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  24
   14.  References . . . . . . . . . . . . . . . . . . . . . . . . .  25
     14.1   Normative References . . . . . . . . . . . . . . . . . .  25
     14.2   Informative References . . . . . . . . . . . . . . . . .  25
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  26
   A.   Intellectual Property Statement  . . . . . . . . . . . . . .  27
        Intellectual Property and Copyright Statements . . . . . . .  28

Nordmark, et al.        Expires January 13, 2006                [Page 2]

Internet-Draft    IPv6 Socket API for Address Selection        July 2005

1.  Introduction

   RFC 3484 [1] specifies the default address selection rules.  This
   document defines socket API extensions that allow the applications to
   override the default choice of address selection.  Privacy
   considerations [7] have introduced "public" and "temporary"
   addresses.  IPv6 Mobility [4] introduces "home address" and "care-of-
   address" definitions in the mobile systems.  Some applications might
   want to control whether large scope [2] or small scope IPv6 addresses
   are preferred.

   The default rules in [1] in summary are that a public address is
   preferred over a temporary address, that a mobile IPv6 home address
   is preferred over a care-of-address, and that a larger scope address
   is preferred over a smaller scope address.  Although it is desirable
   to have default rules for address selection, an application may want
   to reverse certain address selection rules for efficiency and other
   application specific reasons.

   Currently IPv6 socket API extensions provide mechanism to choose a
   specific source address through simple bind() operation or
   IPV6_PKTINFO socket option [6].  Thus in order to use bind() or
   IPV6_PKTINFO socket option, 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.  This can be quite complex for the application,
   since in effect it needs to implement all the default address
   selection rules in order to change its preferences with respect to
   one of the rules.

   The mechanism presented in this document allows the application to
   specify attributes of the source (and destination) addresses it
   prefers while still having the system perform the rest of the address
   selection rules.  For instance, if an application specifies that it
   prefers to use a care-of-address over a home address as the source
   address and if the host has two care-of-addresses, one public and one
   temporary, then the host would select the public care-of-address by
   following the default address selection rule for preferring a public
   over a temporary address.

   A socket option has been deemed useful for this purpose, as it
   enables an application to specify address selection preferences on a
   per-socket basis.  It can also provide the flexibility of enabling
   and disabling address selection preferences in non-connected (UDP)
   sockets.  The socket option uses a set of flags for address
   preferences.  Since source address selection and destination address

Nordmark, et al.        Expires January 13, 2006                [Page 3]

Internet-Draft    IPv6 Socket API for Address Selection        July 2005

   ordering need to be partially implemented in getaddrinfo() [3] the
   corresponding set of flags are also defined for that routine.

   As a result, this document introduces several flags for address
   selection preferences that alter the default address selection [1]
   for a number of rules.  It analyzes the usefulness of providing API
   functionality for different default address selection rules; it
   provides API to alter only those rules that are possibly used by
   certain classes of applications.  In addition, it also considers CGA
   [8][9]  and non-CGA source addresses when CGA addresses are available
   in the system.  In the future, more destination or source flags may
   be added to expand the API as the needs may arise.

   The approach in this document is to allow the application to specify
   preferences for address selection and not to be able to specify hard
   requirements.  Thus for instance, an application can set a flag to
   prefer a temporary source address, but if no temporary source
   addresses are available at the node, a public address would be chosen

   Specifying hard requirements for address selection would be
   problematic for several reasons.  The major one is that in the vast
   majority of cases the application would like to be able to
   communicate even if an address with the 'optimal' attributes is not
   available.  For instance, an application that performs very short,
   e.g., UDP, transactional exchanges, might prefer to use a care-of-
   address when running on a mobile host which is away from home since
   this provides a short round-trip time in many cases.  But if the
   application is running on a mobile host that is at home, or running
   on a host which isn't providing Mobile IPv6, then it doesn't make
   sense for the application to fail due to no care-of-address being
   available.  Also, in particular when using UDP sockets and the
   sendto() primitive, the use of hard requirements would have been
   problematic, since the set of available IP addresses might very well
   have changed from when the application called getaddrinfo() until it
   called sendto(), which would introduce new failure modes.

   For the few applications that have hard requirements on the
   attributes of the IP addresses it uses, this document defines a
   verification function which such applications can use so that they
   can properly fail to communicate if their address selection
   requirements are not satisfied.

   Furthermore, the approach is to define two flags for each rule that
   can be modified, 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 (see
   section 3.1).  This approach allows different implementations to have

Nordmark, et al.        Expires January 13, 2006                [Page 4]

Internet-Draft    IPv6 Socket API for Address Selection        July 2005

   different system defaults, and works with getaddrinfo() as well as
   setsockopt().  (For setsockopt a different approach could have been
   chosen, but that would still require this approach for getaddrinfo.)

   This document only specifies the extensions for the socket API since
   the socket API is already specified in RFCs [3].  The intent is that
   this document serve as a model for expressing preferences for
   attributes of IP addresses, that also need to be expressable in other
   networking API such as those found in middleware systems and the Java

Nordmark, et al.        Expires January 13, 2006                [Page 5]

Internet-Draft    IPv6 Socket API for Address Selection        July 2005

2.  Design Alternatives

   Some suggested to have per-application flags instead of per-socket
   flags.  However, this design stays with per-socket flags for the
   following reasons:

   o  While some system have per environment/application flags (such as
      environment variables in Unix systems) this might not be available
      in all systems which implement the socket API

   o  When an application links with some standard library that library,
      unknown to the application, might be using the socket API.
      Mechanisms that would provide per application flags may affect not
      only the application itself but also the libraries creating risks
      of unintended consequences.

   Instead of the pair of 'X' and 'not X' flags for each rule that can
   be modified, the socket option could have been defined to use a
   single 'X' value for each rule.  This would still have allowed
   different implementations to have different default settings as long
   as the applications were coded to first retrieve the default setting
   (using getsockopt()), and then clear or set the 'X' flag according to
   their preferences, and finally set the new value with setsockopt().

   But such an approach would not be possible for getaddrinfo(), because
   all the preferences would need to be expressable in the parameters
   that are passed with a single getaddrinfo() call.  Hence, for
   consistency, the 'X'/'not X' approach is used for both getaddrinfo()
   and setsockopt().

Nordmark, et al.        Expires January 13, 2006                [Page 6]

Internet-Draft    IPv6 Socket API for Address Selection        July 2005

3.  Example Usages

   The examples 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 [4] 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 selection 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
   generated addresses by default, as in Secure Neighbor Discovery, 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.

   In addition to the above examples, the defined address preference
   flags can be used to specify or alter the system default values for
   largest scope of addresses as well.  An application may want to use
   only link-local source address to contact a node with global
   destination address on the same link, it can do so by setting the
   appropriate source address preference flag in the application.  By
   default the system would have chosen global source address.  This
   example assumes that only link-local and global addresses are

Nordmark, et al.        Expires January 13, 2006                [Page 7]

Internet-Draft    IPv6 Socket API for Address Selection        July 2005

   available on the nodes.

Nordmark, et al.        Expires January 13, 2006                [Page 8]

Internet-Draft    IPv6 Socket API for Address Selection        July 2005

4.  Additions to the Socket Interface

   IPv6 Basic API [3] defines socket options for IPv6.  This document
   adds a new socket option at the IPPROTO_IPV6 level.  This socket
   option is called IPV6_ADDR_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 where each flag indicates an address selection preference
   which modifies one of the rules in the default address selection

   The following flags are defined to alter or set the default rule of
   source and destination address selection rules discussed in default
   address selection specification [1].


      IPV6_PREFER_SRC_HOME    /* Prefer Home Address as source */

      IPV6_PREFER_SRC_COA     /* Prefer Care-Of_address as source */

      IPV6_PREFER_SRC_TMP     /* Prefer Temporary address as source */

      IPV6_PREFER_SRC_PUBLIC  /* Prefer Public address as source */

      IPV6_PREFER_SRC_CGA     /* Prefer CGA address as source */

      IPV6_PREFER_SRC_NONCGA  /* Prefer a non-CGA address as source */

      IPV6_PREFER_SRC_LARGESCOPE /* Prefer larger scope source */

      IPV6_PREFER_SRC_SMALLSCOPE  /* Prefer smaller scope source */

   NOTE: No source preference flag for longest matching prefix is
   defined here because it is believed to be handled by the policy table
   defined in the default address selection specification.

   Flags corresponding to scoped destination address rules are defined
   here as they make sense in the context of a sender.  See section 8
   for more analysis and mapping of rules and different flags.

      IPV6_PREFER_DST_LARGESCOPE /* Prefer larger scope for dest */

      IPV6_PREFER_DST_SMALLSCOPE /* Prefer smaller scope for dest */

   The following example illustrates how it is used on a AF_INET6

Nordmark, et al.        Expires January 13, 2006                [Page 9]

Internet-Draft    IPv6 Socket API for Address Selection        July 2005

       uint32_t flags = IPV6_PREFER_SRC_COA;

       if (setsockopt(s, IPPROTO_IPV6, IPV6_ADDR_PREFERENCES,
           (char *) &flags, sizeof (flags)) == -1) {
               perror("setsockopt IPV6_ADDR_REFERENCES");

   When the IPV6_ADDR_PREFERENCES is successfully set with setsockopt(),
   the option value given is used to specify address preference for any
   connection initiation through the socket and all subsequent packets
   sent via that socket.  If no option is set, the system selects a
   default value as per default address selection algorithm or by some
   other equivalent means.

   Setting conflicting flags at the same time results in the error
   EINVAL.  For example, setting 'X' and 'not X' is not allowed at the
   same time.  If flag is set as combination of 'X' and 'Y', and if 'Y'
   is not applicable or available in the system, then the selected
   address has attribute 'X' and system default for the attribute 'Y'.
   For example, a possible valid combination of flags can be:


Nordmark, et al.        Expires January 13, 2006               [Page 10]

Internet-Draft    IPv6 Socket API for Address Selection        July 2005

5.  Additions to the protocol-independent nodename translation

   Section 8 of Default Address Selection [1] document indicates
   possible implementation strategies for getaddrinfo() [3].  One of
   them suggests that getaddrinfo() collects available source/
   destination pair from the network layer after being sorted at the
   network layer with full knowledge of source address selection.
   Another strategy is to call down to network layer to retrieve source
   address information and then sort the list in the context of

   This implies that getaddrinfo() needs to be aware of the address
   selection preferences of the application, since getaddrinfo() is
   independent of any socket the application might be using.

   Thus if an application uses setsockopt() with the
   IPV6_ADDR_PREFERENCES option to alter the default address selection
   rules, the application must also use the corresponding flags with its
   getaddrinfo() call.  The AI_PREFER_* flags that correspond to the
   IPV6_PREFER_* flags are defined below.

   There is no corresponding destination address selection rule for
   source address selection rule 7, in default address selection
   document.  However, this API provides a way for an application to
   make sure that the source address preference set in setsockopt() is
   taken into account by the getaddrinfo() function.  Let's consider an
   example to understand this scenario.  DA and DB are two global
   destination addresses and the node has two global addresses SA and SB
   through interface A and B respectively.  SA is a temporary address
   while SB is a public address.  The application has set
   IPV6_PREFER_SRC_TMP in the setsockopt() flag.  The route to DA points
   to interface A and route to DB points to interface B. Thus when
   AI_PREFER_SRC_TMP is set , getaddrinfo() returns DA before DB and SA
   before SB likewise.  Similarly, getaddrinfo() returns DB before DA
   when AI_PREFER_SRC_PUBLIC is set in this example.  Thus the source
   address preference is taking effect into destination address
   selection and as well as source address selection by the
   getaddrinfo() function.

   The following numerical example clarifies the above further.

   Imagine a host with two addresses:

      1234::1:1 public

      9876::1:2 temporary

   The destination has the following two addresses:

Nordmark, et al.        Expires January 13, 2006               [Page 11]

Internet-Draft    IPv6 Socket API for Address Selection        July 2005



   By default getaddrinfo() will return the destination addresses in the



   because the public source is preferred and 1234 matches more bits
   with the public source address.  On the other hand, if
   AI_PREFER_SRC_TMP is set, getaddrinfo will return the addresses in
   the reverse order since the temporary source address will be

   The following flags are added for the ai_flags in addrinfo data
   structure defined in Basic IPV6 Socket API Extension [3].

      AI_PREFER_SRC_HOME        /* Prefer Home Address */

      AI_PREFER_SRC_COA         /* Prefer COA  */

      AI_PREFER_SRC_TMP         /* Prefer Temporary Address */

      AI_PREFER_SRC_PUBLIC      /* Prefer Public Address */

      AI_PREFER_SRC_CGA         /* Prefer CGA Address */

      AI_PREFER_SRC_NONCGA      /* Prefer address other than CGA */

      AI_PREFER_SRC_LARGESCOPE  /* Prefer larger scope src */

      AI_PREFER_SRC_SMALLSCOPE  /* Prefer smaller scope src */

      AI_PREFER_DST_LARGESCOPE  /* Prefer larger scope dest. */

      AI_PREFER_DST_SMALLSCOPE  /* Prefer smaller scope dest.*/

   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.

   If conflicting flags such as AI_PREFER_SRC_HOME and AI_PREFER_SRC_
   COA are set, the getaddrinfo() fails with an error EAI_BADFLAGS [3].

   Some valid combinations of flags are:

Nordmark, et al.        Expires January 13, 2006               [Page 12]

Internet-Draft    IPv6 Socket API for Address Selection        July 2005










   All the constants mentioned in this section for ai_flags are defined
   in <netdb.h>.

Nordmark, et al.        Expires January 13, 2006               [Page 13]

Internet-Draft    IPv6 Socket API for Address Selection        July 2005

6.  Application Requirements

   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.  An application which
   does not have this requirement can just use getaddrinfo() to specify
   the preferences, followed by:

        uint32_t flags;

         flags = IPV6_PREFER_SRC_TMP;
         if (setsockopt(s, IPPROTO_IPV6, IPV6_ADDR_PREFERENCES,
             (char *) &flags, sizeof (flags)) == -1) {
                 perror("setsockopt IPV6_ADDR_REFERENCES");

   An application which needs to be able to restore the default settings
   on the socket would instead do this:

        uint32_t save_flags, flags;
        int optlen = sizeof (save_flags);

        /* Save the existing IPv6_ADDR_PREFERENCE FLAG now */

        if (getsockopt(s, IPPROTO_IPV6, IPV6_ADDR_PREFERENCES,
            &save_flags, &optlen) == -1 {
                perror("getsockopt IPV6_ADDR_REFERENCES");

         /* Set the new flags */
         flags = IPV6_PREFER_SRC_TMP;
         if (setsockopt(s, IPPROTO_IPV6, IPV6_ADDR_PREFERENCES,
             (char *) &flags, sizeof (flags)) == -1) {
                 perror("setsockopt IPV6_ADDR_REFERENCES");

         /* Do some work with the socket */
         / Restore the flags */
         flags = IPV6_PREFER_SRC_TMP;
         if (setsockopt(s, IPPROTO_IPV6, IPV6_ADDR_PREFERENCES,
             (char *) &save_flags, sizeof (save_flags)) == -1) {
                 perror("setsockopt IPV6_ADDR_REFERENCES");

   Application must not set conflicting flags; the only conflicts that
   are checked for are flag X and flag not-X being set at the same time.

Nordmark, et al.        Expires January 13, 2006               [Page 14]

Internet-Draft    IPv6 Socket API for Address Selection        July 2005

   Example of conflicting flags: IPV6_PREFER_SRC_TMP |

   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

   It is envisioned that Mobile IPv6 applications may want to choose
   Care-of-Address as source for short transaction (for efficiency)
   while roaming, but still keep Home address as source address for long
   lived communication for address stability.  Thus it is recommended
   that applications take this idea into consideration and use the
   source address selection API for home-address and care-of -address
   selection appropriately.  Similarly, an application may choose to set
   IPV6_PREFER_SRC_COA flag for datagram services; it uses home-address
   as source when at home and uses care-of-address outside home-network
   for short datagram transactions.  This is an advantage of having
   flexibility of "preference" vs. "requirement".

Nordmark, et al.        Expires January 13, 2006               [Page 15]

Internet-Draft    IPv6 Socket API for Address Selection        July 2005

7.  Implementation Notes

   o  If either bind() or IPV6_PKTINFO socket option is set with a
      specific source address in the same application along with the
      address preference socket option, then bind() or IPV6_PKTINFO
      option takes precedence.

   o  setsockopt() should silently ignore any address preference flags
      that are not supported in the system.  For example, a host which
      does not implement Mobile IPv6, should not fail setsockopt() or
      getaddrinfo() that specify preferences for home or care-of-
      addresses.  The socket option calls should return error when
      invalid flag values are passed to them.  The invalid flag values
      are: flag X and flag not-X (set at the same time).

   o  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.

   o  Implementation supporting this API must implement both AI flags
      and socket option flags processing for portability of

   o  An implementation may choose to set the following flags by default
      on the system (which is consistent with [1] defaults):






Nordmark, et al.        Expires January 13, 2006               [Page 16]

Internet-Draft    IPv6 Socket API for Address Selection        July 2005

8.  Mapping to Default Address Selection Rules

   This API defines only those flags that are deemed to be useful by the
   applications to alter default address selection rules.  Thus we
   discuss the mapping of each set of flags to the corresponding rule
   number in the address selection document[1].

      Source address selection rule #4 (prefer home address):

      IPV6_PREFER_SRC_HOME (default)


      AI_PREFER_SRC_HOME (default)


      Source address selection rule #7 (prefer public address) :

      IPV6_PREFER_SRC_PUBLIC (default)


      AI_PREFER_SRC_PUBLIC (default)


      Source address selection rule #2 (prefer appropriate scope):





      The LARGESCOPE default above is to prefer source addresses that
      have a scope equal or larger than the scope of the destination
      address.  The inverse is to prefer source address that have a
      scope smaller than the scope of the destination address.

      Destination address selection rule #8 ( prefer smaller scope):



Nordmark, et al.        Expires January 13, 2006               [Page 17]

Internet-Draft    IPv6 Socket API for Address Selection        July 2005



   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.  The flags defined for source
   address selection rule #4 ( prefer home address) should also take
   care of destination address selection rule #4.  Thus at this point,
   it was decided not to define flags for these destination rules.

   Other source address rules (that are not mentioned here) were also
   deemed not applicable for changing its default notion per-application

Nordmark, et al.        Expires January 13, 2006               [Page 18]

Internet-Draft    IPv6 Socket API for Address Selection        July 2005

9.  IPv4-mapped IPv6 Addresses

   IPv4-mapped IPv6 addresses, which are IPv4 addresses in a form that
   can be used on an AF_INET6 socket, are supported in this API.  In
   some cases the IPv4-mapped addresses may not make much sense because
   the attributes are IPv6 specific.  For example, IPv6 temporary
   addresses are not the same as private IPv4 addresses.  However, the
   IPv4 mapped-address support may be useful for mobile home address and
   care-of-address.  At this point it is not understood whether this API
   has any value to IPv4 addresses or AF_INET family of sockets.

Nordmark, et al.        Expires January 13, 2006               [Page 19]

Internet-Draft    IPv6 Socket API for Address Selection        July 2005

10.  Validation function for source address

   Sometimes an application may have a requirement to only use address
   with some particular attribute, and if no such address is available
   the application should fail to communicate instead of communicating
   using the 'wrong' address.  In that situation, address selection
   preferences do not guarantee that the application's requirements are
   met, but instead the application has to explicitly verify that the
   chosen address satisfies its requirements.  Such an application would
   go through the following steps:

   1.  The application specifies one or more AI_PREFER_* flags with

   2.  The application specifies the corresponding IPV6_PREFER_* flags
       with setsockopt()

   3.  The application calls connect().  This applies even for datagram
       (UDP) sockets, as the connect call results in the stack selecting
       a source address, for TCP as well as UDP.

   4.  Retrieve the selected source address using the getsockname() API

   5.  Verifying that the retrieved address is satisfactory as specified
       below.  If not, abort the communication e.g., by closing the

   If the application has hard requirements on the scope of the source
   address, then it can perform the verification using the APIs
   specified in [3] such as IN6_IS_ADDR_LINKLOCAL.

   The verification of temporary vs. public, home vs. care-of, CGA vs.
   not, are performed by a new function defined for this purpose:

      #include <netinet/in.h>

      boolean_t  inet6_is_srcaddr(struct sockaddr_in6 *srcaddr,
                                  uint32_t flags);

   Where the flags contain the specified source preference flags.  The
   function expects a non-NULL input for srcaddr. sockaddr_in6 structure
   must contain AF_INET6 as sin6_family.  It also must contain the
   scope_id information if the source address is a link-local address.

   The function returns true when srcaddr corresponds to a valid address
   in the node and that address type satisfies the preference flag(s).
   If srcaddr input value does not correspond to any address in the node

Nordmark, et al.        Expires January 13, 2006               [Page 20]

Internet-Draft    IPv6 Socket API for Address Selection        July 2005

   or it does not match an address which satisfy the preferences
   indicated, the function returns false.

   This function can handle multiple valid flags combination as its
   second parameter, for example IPV6_PREFER_SRC_COA |
   IPV6_PREFER_SRC_TMP, which means that all flags must be satisfied for
   the result to be true.  Invalid flag values result in false return

   The function will return true for IPV6_PREFER_SRC_HOME even if the
   host is not implementing mobile IPv6, as well as for a mobile node
   which is at home (i.e., does not have any care-of-address).

Nordmark, et al.        Expires January 13, 2006               [Page 21]

Internet-Draft    IPv6 Socket API for Address Selection        July 2005

11.  Security Considerations

   This document conforms to the same security implications as specified
   in IPv6 Basic Socket API [3] document.  Allowing applications to
   specify a preference for temporary addresses provides per-application
   (and per-socket) ability to use the privacy benefits of the temporary

Nordmark, et al.        Expires January 13, 2006               [Page 22]

Internet-Draft    IPv6 Socket API for Address Selection        July 2005

12.  Changes from previous version of draft

      include destination address preference for scope and for further
      future enhancement which may include both source and destination

   o  Added implementation and application requirements.

      there is no corresponding source address rule in RFC3484.
      Moreover it doesn't seem to make sense to add preference flags for
      this destination addresses since:

      *  The local system doesn't in general know whether there is a
         tunnel at the destination end and

      *  In the case (6to4) where the local system can tell there will
         be a tunnel for a destination address the default policy table
         already has a rule (for the 6to4 prefix).

      Perhaps there should have been a source rule for tunnel vs. native
      interface in default address selection specification in which case
      it might have made sense to add a preference flag for that.

   o  Added section on default address selection rule mapping.

   o  Added comments on using JAVA API.

   o  Added four new flags for destination scoped addresses as some
      working group members felt the requirement of altering default
      destination address scope.

   o  Clarified when getsockopt needs to be used.  Removed text that
      said a setsockopt with flags=0 would restore the preferences to
      the system defaults.

   o  Added text showing the different ways the validation can be
      performed.  The validation of scope is quite different than the
      validation function for other address selection preferences.

Nordmark, et al.        Expires January 13, 2006               [Page 23]

Internet-Draft    IPv6 Socket API for Address Selection        July 2005

13.  Acknowledgments

   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, Francis Dupont, Michael Hunter, Sebastien
   Roy, Robert Elz, Jinmei Tatuya, Pekka Savola, Itojun, Jim Bound, Jeff
   Boote and Mika Liljeberg for useful discussions and suggestions.

Nordmark, et al.        Expires January 13, 2006               [Page 24]

Internet-Draft    IPv6 Socket API for Address Selection        July 2005

14.  References

14.1  Normative References

   [1]  Draves, R., "Default Address Selection for IPv6", RFC 3484,
        August 2002.

   [2]  Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
        Addressing Architecture", RFC 3513, April 2003.

   [3]  Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
        Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493,
        March 2003.

14.2  Informative References

   [4]   Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
         IPv6", RFC 3775, June 2004.

   [5]   Deering, S. and R. Hinden, "Internet Protocol, Version 6
         (IPv6), Specification", RFC 2460, December 1998.

   [6]   Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, "Advanced
         Sockets API for IPv6", RFC 3542, May 2003.

   [7]   Narten, T. and R. Draves, "Privacy Extensions for Stateless
         Address Autoconfiguration in IPv6", RFC 3041, January 2001.

   [8]   Aura, T., "Cryptographically Generated Addresses (CGA)",
         draft-ietf-send-cga-01.txt (work in progress), August 2003.

   [9]   Montenegro, G. and C. Castelluccia, "Statistically Unique and
         Cryptographically Verifiable  (SUCV) Identifiers and
         Addresses.", NDSS 2002, February 2002.

   [10]  Chakrabarti, S. and E. Nordmark, "Extension to Sockets API for
         Mobile IPv6", draft-ietf-mip6-mipext-advapi-03.txt (work in
         progress), September 2004.

Nordmark, et al.        Expires January 13, 2006               [Page 25]

Internet-Draft    IPv6 Socket API for Address Selection        July 2005

Authors' Addresses

   Erik Nordmark
   Sun Microsystems, Inc.
   4150 Network Circle, UMPK17-308
   Santa Clara, CA 95054

   Email: Erik.Nordmark@Sun.COM

   Samita Chakrabarti
   Sun Microsystems, Inc.
   4150 Network Circle, UMPK16-157
   Santa Clara, CA 95054

   Email: Samita.Chakrabarti@Sun.COM

   Julien Laganier
   DoCoMo Communications Laboratories Europe GmbH
   Landsberger Strasse 312
   Munich  80687

   Phone: +49 89 56824 231
   Email: julien.ietf@laposte.net
   URI:   http://www.docomolab-euro.com/

Nordmark, et al.        Expires January 13, 2006               [Page 26]

Internet-Draft    IPv6 Socket API for Address Selection        July 2005

Appendix A.  Intellectual Property Statement

   This document only defines a source preference flag to choose
   Cryptographically Generated Address (CGA) as source address when
   applicable.  CGA are obtained using public keys and hashes to prove
   address ownership.  Several IPR claims have been made about such

Nordmark, et al.        Expires January 13, 2006               [Page 27]

Internet-Draft    IPv6 Socket API for Address Selection        July 2005

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Nordmark, et al.        Expires January 13, 2006               [Page 28]