Network Working Group                                        E. Nordmark
Internet-Draft                                            S. Chakrabarti
Expires: April 25, 2004                           Sun Microsystems, Inc.
                                                             J. Laganier
                                       ENS Lyon / Sun Microsystems, Inc.
                                                        October 26, 2003

                 IPv6 Socket API for Address Selection

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   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-

   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://

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

   This Internet-Draft will expire on April 25, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.


   The IPv6 default address selection document describes the rules for
   selecting default address by the system and indicates that the
   applications should be able to reverse the sense of system preference
   of address selection for that application through possible API
   extensions.  However, no such socket API exists in the basic or
   advanced IPv6 socket API documents.  Hence this document specifies
   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

Nordmark, et al.         Expires April 25, 2004                 [Page 1]

Internet-Draft    IPv6 Socket API for Address Selection     October 2003

   document will be particularly useful when Mobile IPv6 is used, for
   IPv6 applications which want to choose between temporary and public
   addresses, CGA (cryptographically generated addresses) and non-CGA
   addresses, and applications which do not want the default preferences
   with respect to address scopes.

Table of Contents

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

Nordmark, et al.         Expires April 25, 2004                 [Page 2]

Internet-Draft    IPv6 Socket API for Address Selection     October 2003

1. Introduction

   This document defines socket API extensions to support the non-
   default choice of address selection by the applications.  The IPv6
   default address selection [1] document has specified the rules for
   system default 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.  Some applications
   might want to control whether large scope or small scope IPv6
   addresses are preferred.

   Although it is desirable to have default algorithms 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 [5].  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.  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 address selection.  For instance, if an application prefers to use
   care-of-address of a mobile node as the source address and if the
   mobile node has two care-of-addresses (one public and one temporary),
   then the node would select the public care-of-address by following
   the default address selection rule for public and temporary address.

   A socket option has been deemed useful for this purpose, as it
   enables an application to specify addesss selection preferences on a
   per-socket basis.  It can also provide the flexibility of enabling
   and disabling address selection preferences in non-connected sockets.
   The socket option uses a set of flags for 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 several flags for address selection
   preferences that alter the default address selection [1] for a number
   of cases.  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 class of
   applications.  In addition, it also considers CGA [7][8]  and non-CGA
   source addresses when CGA addresses are available in the system.  In

Nordmark, et al.         Expires April 25, 2004                 [Page 3]

Internet-Draft    IPv6 Socket API for Address Selection     October 2003

   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 a 'requirement' for address selection is not adopted at
   the application level due to the nature of unreliable transport
   protocols where the failure of connect() operation may appear late in
   absence of the required attribute of source address in the system.
   This document defines a verification function which applications may
   choose to use before sending data on a connected socket.  By
   "connected" socket we mean that a connect() call is done after
   setting setsockopt() with the preference attributes.  Note that
   connect() can be used in UDP datagram sockets as well.  The purpose
   of checking the validation of address after connect() call ensures
   the availability of the desired address type; an application using
   only sendto() or sendmsg() cannot guarantee the validated address at
   the time of sending data .  The configuration of node may change or
   the address may expire between setsockopt() setting and sendto() or
   sendmsg() call.

   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 (see section 3.1).  For
   example, if setsockopt() with a preference to care-of-address is set,
   but no flag is set to indicate a choice of temporary or public
   address, then temporary vs.  public source address selection will be
   determined from the  default source address selection [1] rules.
   Thus not specifying either of "X" and "not X" leaves the "X" property
   of the address selection at the system default.

   This document only specifies the extensions for the socket API since
   the socket API is already specified in RFCs [2].  The intent is that
   this document serve as a model for the type of address selection
   preferences that need to be expressable in other networking API such
   as those found in middleware systems and the Java environment.

Nordmark, et al.         Expires April 25, 2004                 [Page 4]

Internet-Draft    IPv6 Socket API for Address Selection     October 2003

2. Design Alternatives

   Suggestions have been made that have flags per application instead of
   per socket would be more flexible.  However, this design stays with
   per socket flags for the following reasons:

   - 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

   -  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 would affect not
   only the application itself but also the libraries' use of the socket
   API with a large risk for unintended consequences.

Nordmark, et al.         Expires April 25, 2004                 [Page 5]

Internet-Draft    IPv6 Socket API for Address Selection     October 2003

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

   Besides 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 available on the nodes.

Nordmark, et al.         Expires April 25, 2004                 [Page 6]

Internet-Draft    IPv6 Socket API for Address Selection     October 2003

4. 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_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 small(link-local) scope */

   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 for altering Scope of destination addresses:

   Flags corresponding to other destination address rules are not
   defined in this document at this point.  See section 8 for more
   analysis and mapping of rules and different flags.

   IPV6_PREFER_DST_LARGESCOPE /* Prefer larger scope for destination */

   IPV6_PREFER_DST_SMALLSCOPE /* Prefer small scope for destination */

Nordmark, et al.         Expires April 25, 2004                 [Page 7]

Internet-Draft    IPv6 Socket API for Address Selection     October 2003

   The following example illustrates how it is used on a AF_INET6

   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 contains property of 'X' and system default for the property
   of 'Y'.  For example, a possible valid combination of flags can be:


Nordmark, et al.         Expires April 25, 2004                 [Page 8]

Internet-Draft    IPv6 Socket API for Address Selection     October 2003

5. Changes to the protocol-independent nodename translation

   Section 8 of Default Address Selection [1] document indicates
   possible implementation strategies for getaddrinfo() [2].  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

   Thus if an application sets setsockopt() IPV6_ADDR_PREFERENCES option
   to alter the default address selection rules , it is required that
   the application calls getaddrinfo() with the corresponding
   AI_PREFER_* flags specified in this section.  This ensures that
   getaddrinfo() function implementation has considered the address
   preference desired by the application, as the destination address
   selection rule is influenced by the order of source address
   selection.  This document also defines AI flags for destination SCOPE
   which has direct impact on getaddrinfo() and destination address
   selection interaction.

   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

Nordmark, et al.         Expires April 25, 2004                 [Page 9]

Internet-Draft    IPv6 Socket API for Address Selection     October 2003

   The destination has the following two addresses:



   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 [2].

      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 large(global) scope */

      AI_PREFER_SRC_SMALLSCOPE  /* Prefer small(local) scope */

      AI_PREFER_DST_LARGESCOPE  /* Prefer large(global) scope dest.  */

      AI_PREFER_DST_SMALLSCOPE  /* Prefer small(local) 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 [2].

Nordmark, et al.         Expires April 25, 2004                [Page 10]

Internet-Draft    IPv6 Socket API for Address Selection     October 2003

   Some valid sequences of flags are:










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

Nordmark, et al.         Expires April 25, 2004                [Page 11]

Internet-Draft    IPv6 Socket API for Address Selection     October 2003

6. Application Requirements

   An application SHOULD call getsockopt() prior calling setsockopt() to
   a particular address preference, in order to save the existing system
   default values or the current values of the address preference flags.
   However, setsockopt() with a flag value 0 resets the address
   selection to the system default policy.


   uint32_t save_flag, flags;

   int optlen = sizeof (save_flag);

   /* Save the existing IPv6_ADDR_PREFERENCE FLAG now */

   if (getsockopt(s, IPPROTO_IPV6, IPV6_ADDR_PREFERENCES,

         &save_flag, &optlen) == -1 {

                perror("getsockopt IPV6_ADDR_REFERENCES");


   flags = save_flag;

   flags &= ~IPV6_PREFER_SRC_PUBLIC;

   flags |= IPV6_PREFER_SRC_TMP;

   if (setsockopt(s, IPPROTO_IPV6, IPV6_ADDR_PREFERENCES,

       (char *) &flags, sizeof (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.
   Example of conflicting flags :

   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

Nordmark, et al.         Expires April 25, 2004                [Page 12]

Internet-Draft    IPv6 Socket API for Address Selection     October 2003

   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 April 25, 2004                [Page 13]

Internet-Draft    IPv6 Socket API for Address Selection     October 2003

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 preferenc e socket option, then bind() or IPV6_PKTINFO
      option takes precedence.

   o  setsockopt() and getsockopt() SHOULD ignore any address preference
      flags for type of addresses that are not supported in the system.
      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), some flag that is not known
      to the implementation.

   o  If an implementation supports both streams and datagram sockets,
      it should implement the address preference mechanism API described
      in this document on both cases.

   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.  However, an implementation may choose to clear the
      address preference flags by default indicating that system is
      following default address selection rules.Thus it sets the address
      preference flags only when it is set by the application.  Thus the
      change in address preference flag is only visible by that






Nordmark, et al.         Expires April 25, 2004                [Page 14]

Internet-Draft    IPv6 Socket API for Address Selection     October 2003

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):





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





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





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





   Other destination rules  (#4-prefer home address; #7-prefer native

Nordmark, et al.         Expires April 25, 2004                [Page 15]

Internet-Draft    IPv6 Socket API for Address Selection     October 2003

   interfaces) could have been applicable.  But the problem is that the
   local system does not know about 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

   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 April 25, 2004                [Page 16]

Internet-Draft    IPv6 Socket API for Address Selection     October 2003

9. IPv4-mapped IPv6 Addresses

   IPv4-mapped IPv6 addresses 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 April 25, 2004                [Page 17]

Internet-Draft    IPv6 Socket API for Address Selection     October 2003

10. Validation function for source address

   Sometimes an application may have a requirement to set a specific
   source address without which it chooses to fail.  In that situation,
   'preferred' addresses do not guarantee the application requirement.
   An application which requires to set a specific type of source
   address must verify that the system indeed has  a valid source
   address for the desired source address type.  A validation function
   is defined for this purpose:


   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.  It returns true when
   srcaddr corresponds to a valid address in the node and that address
   type  satisfies the preference flag.  If srcaddr input value does not
   correspond to any  address in the node or it does not match an
   address which satisfy the preferences indicated, the function returns
   false.  Currently, the validation function seems meaningful only for
   IPV6_PREFER_SRC_[NON]CGA flags.  See the section on "Application
   Requirements" for usage of preference flags in Mobile IPv6
   applications.  The scope preference flags do not guarantee validation
   of largest scope when more than two scopes are configured.  Thus the
   above temporary/public and CGA/non-CGA flags are the predictable
   choices for the validation function.

   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.

   This function should be able to handle multiple valid flags
   combination as its second parameter.  Invalid flag values result in
   false return value.

   The verification function can be useful for both TCP and UDP socket
   applications that use connect().

Nordmark, et al.         Expires April 25, 2004                [Page 18]

Internet-Draft    IPv6 Socket API for Address Selection     October 2003

11. Security Considerations

   This document conforms to the same security implications as specified
   in IPv6 Basic Socket API [2] 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

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

   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.

Nordmark, et al.         Expires April 25, 2004                [Page 19]

Internet-Draft    IPv6 Socket API for Address Selection     October 2003

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.

Normative References

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

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

Informative References

   [3]  Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
        IPv6", draft-ietf-mobileip-ipv6-24.txt (work in progress), June

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

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

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

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

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

Nordmark, et al.         Expires April 25, 2004                [Page 20]

Internet-Draft    IPv6 Socket API for Address Selection     October 2003

Authors' Addresses

   Erik Nordmark
   Sun Microsystems, Inc.
   180, avenue de l'Europe
   38334 Saint Ismier CEDEX

   EMail: Erik.Nordmark@Sun.COM

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

   EMail: Samita.Chakrabarti@Sun.COM

   Julien Laganier
   ENS Lyon / Sun Microsystems, Inc.
   180, avenue de l'Europe
   38334 Saint Ismier CEDEX

   EMail: Julien.Laganier@Sun.COM

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 April 25, 2004                [Page 21]

Internet-Draft    IPv6 Socket API for Address Selection     October 2003

Full Copyright Statement

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an


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

Nordmark, et al.         Expires April 25, 2004                [Page 22]