GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5014

Network Working Group E. Nordmark Request for Comments: 5014 Sun Microsystems, Inc. Category: Informational S. Chakrabarti

                                                       Azaire Networks
                                                           J. Laganier
                                                      DoCoMo Euro-Labs
                                                        September 2007
            IPv6 Socket API for Source Address Selection

Status of This Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Abstract

 The IPv6 default address selection document (RFC 3484) describes the
 rules for selecting source and destination IPv6 addresses, and
 indicates that 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 (RFC 3493) or
 advanced (RFC 3542) IPv6 socket API documents.  This document fills
 that gap partially by specifying new socket-level options for source
 address selection and flags for the getaddrinfo() API to specify
 address selection based on the source address preference in
 accordance with the socket-level options that modify the default
 source address selection algorithm.  The socket API 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
 communication.  It also specifies socket options and flags for
 selecting Cryptographically Generated Address (CGA) or non-CGA source
 addresses.

Nordmark, et al. Informational [Page 1] RFC 5014 Socket API for Source Address Selection September 2007

Table of Contents

 1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
 2.  Definition Of Terms  . . . . . . . . . . . . . . . . . . . . .  5
 3.  Usage Scenario . . . . . . . . . . . . . . . . . . . . . . . .  6
 4.  Design Alternatives  . . . . . . . . . . . . . . . . . . . . .  6
 5.  Address Preference Flags . . . . . . . . . . . . . . . . . . .  7
 6.  Additions to the Socket Interface  . . . . . . . . . . . . . .  9
 7.  Additions to the Protocol-Independent Nodename Translation . . 10
 8.  Application Requirements . . . . . . . . . . . . . . . . . . . 11
 9.  Usage Example  . . . . . . . . . . . . . . . . . . . . . . . . 13
 10. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 13
 11. Mapping to Default Address Selection Rules . . . . . . . . . . 14
 12. IPv4-Mapped IPv6 Addresses . . . . . . . . . . . . . . . . . . 16
 13. Validating Source Address Preferences  . . . . . . . . . . . . 16
 14. Summary of New Definitions . . . . . . . . . . . . . . . . . . 19
 15. Security Considerations  . . . . . . . . . . . . . . . . . . . 19
 16. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 19
 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
   17.1.  Normative References  . . . . . . . . . . . . . . . . . . 20
   17.2.  Informative References  . . . . . . . . . . . . . . . . . 20
 Appendix A.  Per-Packet Address Selection Preference . . . . . . . 21
 Appendix B.  Intellectual Property Statement . . . . . . . . . . . 22

1. Introduction

 [RFC3484] specifies the default address selection rules for IPv6
 [RFC2460].  This document defines socket API extensions that allow
 applications to override the default choice of source address
 selection.  It therefore indirectly affects the destination address
 selection through getaddrinfo().  Privacy considerations [RFC3041]
 have introduced "public" and "temporary" addresses.  IPv6 Mobility
 [RFC3775] introduces "home address" and "care-of address" definitions
 in the mobile systems.
 The default address selection rules in [RFC3484], 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 mechanisms to choose a
 specific source address through simple bind() operation or
 IPV6_PKTINFO socket option [RFC3542].  However, in order to use
 bind() or IPV6_PKTINFO socket option, the application itself must

Nordmark, et al. Informational [Page 2] RFC 5014 Socket API for Source Address Selection September 2007

 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 verify the
 appropriateness of the source address scope 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 preference with
 respect to one of the rules.
 The mechanism presented in this document allows the application to
 specify attributes of the source 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 specifying
 address selection preferences.  Since the API should not assume a
 particular implementation method of the address selection [RFC3484]
 in the network layer or in getaddrinfo(), the corresponding set of
 flags are also defined for getaddrinfo(), as it depends on the source
 address selection.
 As a result, this document introduces several flags for address
 selection preferences that alter the default address selection
 [RFC3484] 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 [RFC3972] and non-CGA source addresses when CGA
 addresses are available in the system.  In the future, more 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.  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 instead.
 Specifying hard requirements for address selection would be
 problematic for several reasons.  The major one is that, in the vast

Nordmark, et al. Informational [Page 3] RFC 5014 Socket API for Source Address Selection September 2007

 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 (e.g., DNS queries), might prefer
 to use a care-of address when running on a mobile host that is away
 from home since this provides a short roundtrip time in many cases.
 But if the application is running on a mobile host that is at home,
 or running on a host that 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() or sendmsg() primitives, 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() or sendmsg(), which
 would introduce new failure modes.
 For the few applications that have hard requirements on the
 attributes of the IP addresses they use, this document defines a
 verification function that allows such applications to properly fail
 to communicate when their address selection requirements are not met.
 Furthermore, the approach is to define two flags for each rule that
 can be modified so that an application can specify its preference for
 addresses selected as per the rule, the opposite preference (i.e., an
 address selected as per the rule reverted), or choose not to set
 either of the flags relating to that rule and leave it up to the
 system default (Section 4).  This approach allows different
 implementations to have 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 the
 same approach for getaddrinfo.)
 Note that this document does not directly modify the destination
 address selection rules described in [RFC3484].  An analysis has been
 done to see which destination address rules may be altered by the
 applications.  Rule number 4(prefer home address), 8(prefer smaller
 scope), 7(prefer native interfaces) of default address selection
 document [RFC3484] were taken into consideration for destination
 address alteration.  But as of this writing, there was not enough
 practical usage for applications to alter destination address
 selection rules directly by applying the setsockopt() with a
 preferred destination type of address flag.  However, this document
 does not rule out any possibility of adding flags for preferred
 destination address selection.  However, [RFC3484] destination
 address selection rules are dependent on source address selections,
 thus by altering the default source address selection by using the
 methods described in this document, one indirectly influences the
 choice of destination address selection.  Hence, this document

Nordmark, et al. Informational [Page 4] RFC 5014 Socket API for Source Address Selection September 2007

 explains how getaddrinfo() can be used to select the destination
 address while taking the preferred source addresses into
 consideration (Section 11).
 This document specifies extensions only to the Basic IPv6 socket API
 specified in [RFC3493].  The intent is that this document serves as a
 model for expressing preferences for attributes of IP addresses that
 also need to be expressible in other networking API, such as those
 found in middleware systems and the Java environment.  A similar
 model is also applicable for other socket families.

2. Definition Of Terms

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in [RFC2119].
 Address preference flag:
    A flag expressing a preference for a particular type of address
    (e.g., temporary, public).
 Opposite flags:
    Each flag expressing an address preference has an "opposite flag"
    expressing the opposite preference:
  • Home address preference flag is the opposite of the care-of

address preference flag.

  • Temporary address preference flag is the opposite of the public

address preference flag.

  • CGA address preference flag is the opposite of the non-CGA

address preference flag.

 Contradictory flags:
    Any combination of flags including both a flag expressing a given
    address preference and a flag expressing the opposite preference
    constitutes contradictory flags.  Such flags are contradictory by
    definition of their usefulness with respect to source address
    selection.  For example, consider a set of flags, including both
    the home address preference flag and the care-of address
    preference flag.  When considering source address selection, the
    selected address can be a home address, or a care-of address, but
    it cannot be both at the same time.  Hence, to prefer an address
    that is both a home address and a care-of address is
    contradictory.

Nordmark, et al. Informational [Page 5] RFC 5014 Socket API for Source Address Selection September 2007

3. Usage Scenario

 The examples discussed here are limited to applications supporting
 Mobile IPv6, IPv6 Privacy Extensions, and Cryptographically Generated
 Addresses.  Address selection document [RFC3484] recommends that home
 addresses should be preferred over care-of address when both are
 configured.  However, a mobile node may want to prefer a care-of
 address as the source address for a 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 a home
 address as the source address.  Another example is the IKE
 application, which requires a care-of address as its source address
 for the initial security association pair with a Home Agent [RFC3775]
 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 the 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
 the home address as the source address for one socket and a care-of
 address for the others.
 In a non-mobile environment, an application may similarly prefer to
 use a temporary address as the 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 a "temporary" address for the
 former and a "public" address for the mail-server, as a mail-server
 may require a reverse path for DNS records for anti-spam rules.
 Similarly, a node may be configured to use Cryptographically
 Generated Addresses [RFC3972] by default, as in Secure Neighbor
 Discovery [RFC3971], but an application may prefer not to use it; for
 instance, fping [FPING], a debugging tool that tests basic
 reachability of multiple destinations by sending packets in parallel.
 These packets may end up initiating neighbor discovery signaling that
 uses SEND if used with a CGA source address.  SEND performs some
 cryptographic operations to prove ownership of the said CGA address.
 If the application does not require this feature, it would like to
 use a non-CGA address to avoid potentially expensive computations
 performed by SEND.  On the other hand, when a node is not configured
 for CGA as default, an application may prefer using CGA by setting
 the corresponding preference.

4. Design Alternatives

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

Nordmark, et al. Informational [Page 6] RFC 5014 Socket API for Source Address Selection September 2007

 o  While some systems have per-environment/application flags (such as
    environment variables in Unix systems) this might not be available
    in all systems that implement the socket API.
 o  When an application links with some standard library, that library
    might use the socket API while the application is unaware of that
    fact.  Mechanisms that would provide per-application flags may
    affect not only the application itself but also the libraries,
    hence, creating risks of unintended consequences.
 Instead of the pair of 'flag' and 'opposite flag' for each rule that
 can be modified, the socket option could have been defined to use a
 single 'flag' 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 '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 expressible in the parameters
 that are passed with a single getaddrinfo() call.  Hence, for
 consistency, the 'flag' and 'opposite flag' approach is used for both
 getaddrinfo() and setsockopt().
 Thus, in this API document, an application has three choices on
 source address selection:
    a) The application wants to use an address with flag X: Set flag
    X; unset opposite/contradictory flags of X if they are set before.
    b) The application wants to use an address with 'opposite' or
    contradictory flag of X: Set opposite or contradictory flag of X;
    unset flag X, if already set.
    c) The application does not care about the presence of flag X and
    would like to use default: No need to set any address preference
    flags through setsockopt() or getaddrinfo(); unset any address
    preference flags if they are set before by the same socket.

5. Address Preference Flags

 The following flags are defined to alter or set the default rule of
 source address selection rules discussed in default address selection
 specification [RFC3484].
    IPV6_PREFER_SRC_HOME /* Prefer Home address as source */
    IPV6_PREFER_SRC_COA /* Prefer Care-of address as source */

Nordmark, et al. Informational [Page 7] RFC 5014 Socket API for Source Address Selection September 2007

    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 */
 These flags can be combined together in a flag-set to express more
 complex address preferences.  However, such combinations can result
 in a contradictory flag-set, for example:
    IPV6_PREFER_SRC_PUBLIC | IPV6_PREFER_SRC_TMP
    IPV6_PREFER_SRC_HOME | IPV6_PREFER_SRC_COA
    IPV6_PREFER_SRC_HOME | IPV6_PREFER_SRC_COA | IPV6_PREFER_SRC_TMP
    IPV6_PREFER_SRC_CGA | IPV6_PREFER_SRC_NONCGA
    Etc.
 Examples of valid combinations of address selection flags are given
 below:
    IPV6_PREFER_SRC_HOME | IPV6_PREFER_SRC_PUBLIC
    IPV6_PREFER_SRC_HOME | IPV6_PREFER_SRC_CGA
    IPV6_PREFER_SRC_COA | IPV6_PREFER_SRC_PUBLIC | IPV6_PREFER_SRC_CGA
    IPV6_PREFER_SRC_HOME | IPV6_PREFER_SRC_NONCGA
 If a flag-set includes a 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, on a system that has only public addresses, the valid
 combination of flags:
    IPV6_PREFER_SRC_TMP | IPV6_PREFER_SRC_HOME
 would result in the selected address being a public home address,
 since no temporary addresses are available.

Nordmark, et al. Informational [Page 8] RFC 5014 Socket API for Source Address Selection September 2007

6. Additions to the Socket Interface

 The IPv6 Basic Socket API [RFC3493] defines socket options for IPv6.
 To allow applications to influence address selection mechanisms, 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 to set and get the address
 selection preferences affecting all packets sent via a given socket.
 The socket option value (optval) is a 32-bit unsigned integer
 argument.  The argument consists of a number of flags where each flag
 indicates an address selection preference that modifies one of the
 rules in the default address selection specification.
 The following flags are defined to alter or set the default rule of
 source address selection rules discussed in default address selection
 specification [RFC3484].  They are defined as a result of including
 the <netinet/in.h> header:
    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 */
 NOTE: No source preference flag for the longest matching prefix is
 defined here because it is believed to be handled by the policy table
 defined in the default address selection specification.
 When the IPV6_ADDR_PREFERENCES is successfully set with setsockopt(),
 the option value given is used to specify the 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 contradictory flags at the same time results in the error
 EINVAL.

Nordmark, et al. Informational [Page 9] RFC 5014 Socket API for Source Address Selection September 2007

7. Additions to the Protocol-Independent Nodename Translation

 Section 8 of the Default Address Selection [RFC3484] document
 indicates possible implementation strategies for getaddrinfo()
 [RFC3493].  One of them suggests that getaddrinfo() collects
 available source/destination pairs 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 the network layer to
 retrieve source address information and then sort the list in the
 context of getaddrinfo().
 This implies that getaddrinfo() should 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 alters the default address selection rules by
 using setsockopt() with the IPV6_ADDR_PREFERENCES option, the
 application should also use the corresponding address selection
 preference flags with its getaddrinfo() call.
 For that purpose, the addrinfo data structure defined in Basic IPV6
 Socket API Extension [RFC3493] has been extended with an extended
 "ai_eflags" flag-set field to provide the designers freedom from
 adding more flags as necessary without crowding the valuable bit
 space in the "ai_flags" flag-set field.  The extended addrinfo data
 structure is defined as a result of including the <netdb.h> header:
  struct addrinfo {
      int ai_flags;             /* input flags */
      int ai_family;            /* protocol family for socket */
      int ai_socktype;          /* socket type */
      int ai_protocol;          /* protocol for socket */
      socklen_t ai_addrlen;     /* length of socket address */
      char *ai_canonname;       /* canonical name for hostname */
      struct sockaddr *ai_addr; /* socket address for socket */
      struct addrinfo *ai_next; /* pointer to next in list */
      int ai_eflags;            /* Extended flags for special usage */
  };
 Note that the additional field for extended flags are added at the
 bottom of the addrinfo structure to preserve binary compatibility of
 the new functionality with the old applications that use the existing
 addrinfo data structure.
 A new flag (AI_EXTFLAGS) is defined for the "ai_flags" flag-set field
 of the addrinfo data structure to tell the system to look for the
 "ai_eflags" extended flag-set field in the addrinfo structure.  It is
 defined in the <netdb.h> header:

Nordmark, et al. Informational [Page 10] RFC 5014 Socket API for Source Address Selection September 2007

    AI_EXTFLAGS /* extended flag-set present */
 If the AI_EXTFLAGS flag is set in "ai_flags" flag-set field of the
 addrinfo data structure, then the getaddrinfo() implementation MUST
 look for the "ai_eflags" values stored in the extended flag-set field
 "ai_eflags" of the addrinfo data structure.  The flags stored in the
 "ai_eflags" field are only meaningful if the AI_EXTFLAGS flag is set
 in the "ai_flags" flag-set field of the addrinfo data structure.  By
 default, AI_EXTFLAGS is not set in the "ai_flags" flag-set field.  If
 AI_EXTFLAGS is set in the "ai_flags" flag-set field, and the
 "ai_eflags" extended flag-set field is 0 (zero) or undefined, then
 AI_EXTFLAGS is ignored.
 The IPV6 source address preference values (IPV6_PREFER_SRC_*) defined
 for the IPV6_ADDR_PREFERENCES socket option are also defined as
 address selection preference flags for the "ai_eflags" extended flag-
 set field of the addrinfo data structure, so that getaddrinfo() can
 return matching destination addresses corresponding to the source
 address preferences expressed by the caller application.
 Thus, an application passes source address selection hints to
 getaddrinfo by setting AI_EXTFLAGS in the "ai_flags" field of the
 addrinfo structure, and the corresponding address selection
 preference flags (IPV6_PREFER_SRC_*) in the "ai_eflags" field.
 Currently, AI_EXTFLAGS is defined for the AF_INET6 socket protocol
 family only.  But its usage should be extendable to other socket
 protocol families -- such as AF_INET or as appropriate.
 If contradictory flags, such as IPV6_PREFER_SRC_HOME and
 IPV6_PREFER_SRC_COA, are set in ai_eflags, the getaddrinfo() fails
 and return the value EAI_BADEXTFLAGS, defined as a result of
 including the <netdb.h> header.  This error value MUST be interpreted
 into a descriptive text string when passed to the gai_strerror()
 function [RFC3493].

8. Application Requirements

 An application should call getsockopt() prior to calling setsockopt()
 if the application needs to be able to restore the socket back to the
 system default preferences.  Note that this is suggested for
 portability.  An application that does not have this requirement can
 just use getaddrinfo() while specifying its preferences, followed by:

Nordmark, et al. Informational [Page 11] RFC 5014 Socket API for Source Address Selection September 2007

    uint32_t flags = IPV6_PREFER_SRC_TMP;
    if (setsockopt(s, IPPROTO_IPV6, IPV6_ADDR_PREFERENCES,
                   (void *) &flags, sizeof (flags)) == -1) {
        perror("setsockopt IPV6_ADDR_REFERENCES");
        }
 An application that 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 flags now */
    if (getsockopt(s, IPPROTO_IPV6, IPV6_ADDR_PREFERENCES,
                   (void *) &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,
                (void *) &flags, sizeof (flags)) == -1) {
        perror("setsockopt IPV6_ADDR_REFERENCES");
        }
    /*
     *
     *  Do some work with the socket here.
     *
     */
    /* Restore the flags */
    if (setsockopt(s, IPPROTO_IPV6, IPV6_ADDR_PREFERENCES,
                (void *) &save_flags, sizeof (save_flags)) == -1) {
        perror("setsockopt IPV6_ADDR_REFERENCES");
        }
 Applications should not set contradictory flags at the same time.
 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 semantically
 equivalent flags when calling getaddrinfo() and setsockopt().  For
 example, if the application sets the IPV6_PREFER_SRC_COA flag, it
 MUST use the same for the "ai_eflag" field of the addrinfo data

Nordmark, et al. Informational [Page 12] RFC 5014 Socket API for Source Address Selection September 2007

 structure when calling getaddrinfo().  If applications are not
 setting the semantically equivalent flags, the behavior of the
 implementation is undefined.

9. Usage Example

 An example of usage of this API is given below:
  struct addrinfo hints, *ai, *ai0;
  uint32_t preferences;
  preferences = IPV6_PREFER_SRC_TMP;
  hints.ai_flags |= AI_EXTFLAGS;
  hints.ai_eflags = preferences;  /* Chosen address preference flag */
  /* Fill in other hints fields */
  getaddrinfo(....,&hints,. &ai0..);
  /* Loop over all returned addresses and do connect  */
  for (ai = ai0; ai; ai = ai->ai_next) {
      s = socket(ai->ai_family, ...);
      setsockopt(s, IPV6_ADDR_PREFERENCES, (void *) &preferences,
                 sizeof (preferences));
      if (connect(s, ai->ai_addr, ai->ai_addrlen) == -1){
          close (s);
          s = -1;
          continue;
          }
      break;
      }
  freeaddrinfo(ai0);

10. Implementation Notes

 o  Within the same application, if a specific source address is set
    by either bind() or IPV6_PKTINFO socket option, while at the same
    time an address selection preference is expressed with the
    IPV6_ADDR_PREFERENCES socket option, then the source address
    setting carried by bind() or IPV6_PKTINFO takes precedence over
    the address selection setting.

Nordmark, et al. Informational [Page 13] RFC 5014 Socket API for Source Address Selection September 2007

 o  setsockopt() and getaddrinfo() should silently ignore any address
    preference flags that are not supported in the system.  For
    example, a host that 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 (-1) and set errno to EINVAL when contradictory flags values
    are passed to them.
 o  If an implementation supports both stream and datagram sockets, it
    should implement the address preference mechanism API described in
    this document on both types of sockets.
 o  An implementation supporting this API MUST implement both
    getaddrinfo() extension flags and socket option flags processing
    for portability of applications.
 o  The following flags are set as default values on a system (which
    is consistent with [RFC3484] defaults):
    IPV6_PREFER_SRC_HOME
    IPV6_PREFER_SRC_PUBLIC
    IPV6_PREFER_SRC_CGA

11. 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 [RFC3484].
    Source address selection rule #4 (prefer home address):
    IPV6_PREFER_SRC_HOME (default)
    IPV6_PREFER_SRC_COA
    Source address selection rule #7 (prefer public address):
    IPV6_PREFER_SRC_PUBLIC (default)
    IPV6_PREFER_SRC_TMP
 At this time, this document does not define flags to alter source
 address selection rule #2 (prefer appropriate scope for destination)
 and destination address selection rule #8 (prefer smaller scope), as
 the implementers felt that there were no practical applications that

Nordmark, et al. Informational [Page 14] RFC 5014 Socket API for Source Address Selection September 2007

 can take advantage of reverting the scoping rules of IPv6 default
 address selection.  Flags altering other destination address
 selection rules (#4, prefer home address and #7, prefer native
 transport) could have applications, but the problem is that the local
 system cannot systematically determine whether a destination address
 is a tunnel address for destination rule #7 (although it can when the
 destination address is one of its own, or can be syntactically
 recognized as a tunnel address, e.g., a 6-to-4 address.)  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.
 Also, note that there is no corresponding destination address
 selection rule for source address selection rule #7 (prefer public
 addresses) of default address selection document [RFC3484].  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 source 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 the route to DB points to interface B. Thus, when
 AI_EXTFLAGS in ai_flags and IPV6_PREFER_SRC_TMP in ai_eflags are set,
 getaddrinfo() returns DA before DB in the list of destination
 addresses and thus, SA will be used to communicate with the
 destination DA.  Similarly, getaddrinfo() returns DB before DA when
 AI_EXTFLAGS and ai_eflags are set to IPV6_PREFER_SRC_PUBLIC.  Thus,
 the source address preference is taking effect into destination
 address selection 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:
    1234::9:3
    9876::9:4

Nordmark, et al. Informational [Page 15] RFC 5014 Socket API for Source Address Selection September 2007

 By default, getaddrinfo() will return the destination addresses in
 the following order:
    1234::9:3
    9876::9:4
 because the public source is preferred and 1234 matches more bits
 with the public source address.  On the other hand, if ai_flags is
 set to AI_EXTFLAGS and ai_eflags to IPV6_PREFER_SRC_TMP, getaddrinfo
 will return the addresses in the reverse order since the temporary
 source address will be preferred.
 Other source address rules (that are not mentioned here) were also
 deemed not applicable for changing its default on a per-application
 basis.

12. IPv4-Mapped IPv6 Addresses

 IPv4-mapped IPv6 addresses for AF_INET6 sockets are supported in this
 API.  In some cases, the application of IPv4-mapped addresses are
 limited because the API attributes are IPv6 specific.  For example,
 IPv6 temporary addresses and cryptographically generated addresses
 have no IPv4 counterparts.  Thus, the IPV6_PREFER_SRC_TMP or
 IPV6_PREFER_SRC_CGA are not directly applicable to an IPv4-mapped
 IPv6 address.  However, the IPv4-mapped address support may be useful
 for mobile-IPv4 applications shifting the source address between the
 home address and the care-of address.  Thus, the IPV6_PREFER_SRC_COA
 and IPV6_PREFER_SRC_HOME are applicable to an IPv4-mapped IPv6
 address.  At this point, it is not well understood whether this
 particular API has any value to IPv4 addresses or AF_INET family of
 sockets, but a similar model still applies to AF_INET socket family
 if corresponding address flags are defined.

13. Validating Source Address Preferences

 Sometimes an application may have a requirement to only use addresses
 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 requirements are
 met.  Instead, the application has to use a new call that binds a
 socket to the source address that would be selected to communicate
 with a given destination address, according to its preferences, and
 then explicitly verify that the chosen address satisfies its
 requirements using a validation function.  Such an application would
 go through the following steps:

Nordmark, et al. Informational [Page 16] RFC 5014 Socket API for Source Address Selection September 2007

 1.  The application specifies one or more IPV6_PREFER_SRC_* flags and
     AI_EXTFLAGS ai_flags with getaddrinfo().
 2.  The application specifies the same IPV6_PREFER_SRC_* flags with
     setsockopt().
 3.  The application calls the stack to select a source address to
     communicate with the specified destination address, according to
     the expressed address selection preferences.  This is achieved
     with a connect() call, or a bind2addrsel() call as specified
     below.  The connect() function must not be used when the
     application uses connection-oriented communication (e.g., TCP)
     and want to ensure that no single packet (e.g., TCP SYN) is sent
     before the application could verify that its requirements were
     fulfilled.  Instead, the application must use the newly
     introduced bind2addrsel() call, which binds a socket to the
     source address that would be selected to communicate with a given
     destination address, according to the application's preferences.
     For datagram-oriented communications (e.g., UDP), the connect()
     call can be used since it results in the stack selecting a source
     address without sending any packets.
 4.  Retrieve the selected source address using the getsockname() API
     call.
 5.  Verify with the validation function that the retrieved address is
     satisfactory as specified below.  If not, abort the
     communication, e.g., by closing the socket.
 The binding of the socket to the address that would be selected to
 communicate with a given destination address, according to the
 application preferences, is accomplished via a new binding function
 defined for this purpose:
    #include <netinet/in.h>
    int bind2addrsel(int s, const struct sockaddr *dstaddr,
                     socklen_t dstaddrlen);
 where s is the socket that source address selection preferences have
 been expressed by the application, the dstaddr is a non-NULL pointer
 to a sockaddr_in6 structure initialized as follows:
 o  sin6_addr is a 128-bit IPv6 destination address with which the
    local node wants to communicate;
 o  sin6_family MUST be set to AF_INET6;

Nordmark, et al. Informational [Page 17] RFC 5014 Socket API for Source Address Selection September 2007

 o  sin6_scope_id MUST be set if the address is link-local;
 and dstaddrlen is the size of the sockaddr structure passed as
 argument.
 The bind2addrsel() call is defined to return the same values as the
 bind() call, i.e., 0 if successful, -1 otherwise while the global
 variable errno is set to indicate the error.  The bind2addrsel() call
 fails for the same reasons that the bind() call.
 The verification of temporary vs. public, home vs. care-of, CGA vs.
 not, are performed by a new validation function defined for this
 purpose:
    #include <netinet/in.h>
    short inet6_is_srcaddr(struct sockaddr_in6 *srcaddr,
                           uint32_t flags);
 where the flags contain the specified IPV6_PREFER_SRC_* source
 preference flags, and the srcaddr is a non-NULL pointer to a
 sockaddr_in6 structure initialized as follows:
 o  sin6_addr is a 128-bit IPv6 address of the local node.
 o  sin6_family MUST be set to AF_INET6.
 o  sin6_scope_id MUST be set if the address is link-local.
 inet6_is_srcaddr() is defined to return three possible values (0, 1,
 -1): The function returns true (1) when the IPv6 address corresponds
 to a valid address in the node and satisfies the given preference
 flags.  If the IPv6 address input value does not correspond to any
 address in the node or if the flags are not one of the valid
 preference flags, it returns a failure (-1).  If the input address
 does not match an address that satisfies the preference flags
 indicated, the function returns false (0.)
 This function can handle multiple valid preference flag combinations
 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.  Contradictory flag values result in a false
 return value.
 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
 that is at home (i.e., does not have any care-of address).

Nordmark, et al. Informational [Page 18] RFC 5014 Socket API for Source Address Selection September 2007

14. Summary of New Definitions

 The following list summarizes the constants, structure, and extern
 definitions discussed in this memo, sorted by header.
 <netdb.h>        AI_EXTFLAGS
 <netdb.h>        IPV6_PREFER_SRC_HOME
 <netdb.h>        IPV6_PREFER_SRC_COA
 <netdb.h>        IPV6_PREFER_SRC_TMP
 <netdb.h>        IPV6_PREFER_SRC_PUBLIC
 <netdb.h>        IPV6_PREFER_SRC_CGA
 <netdb.h>        IPV6_PREFER_SRC_NONCGA
 <netdb.h>        EAI_BADEXTFLAGS
 <netdb.h>        struct addrinfo{};
 <netinet/in.h>   IPV6_PREFER_SRC_HOME
 <netinet/in.h>   IPV6_PREFER_SRC_COA
 <netinet/in.h>   IPV6_PREFER_SRC_TMP
 <netinet/in.h>   IPV6_PREFER_SRC_PUBLIC
 <netinet/in.h>   IPV6_PREFER_SRC_CGA
 <netinet/in.h>   IPV6_PREFER_SRC_NONCGA
 <netinet/in.h>   short inet6_is_srcaddr(struct sockaddr_in6 *,
                                               uint32_t);
 <netinet/in.h>   int bind2addrsel(int, const struct sockaddr *,
                                         socklen_t);

15. Security Considerations

 This document conforms to the same security implications as specified
 in the Basic IPv6 socket API [RFC3493] and address selection rules
 [RFC3484].  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.  The setting
 of certain address preferences (e.g., not using a CGA address, or not
 using a temporary address) may be restricted to privileged processes
 because of security implications.

16. 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, Keiichi Shima, Michael
 Hunter, Sebastien Roy, Robert Elz, Pekka Savola, Itojun, Jim Bound,
 Jeff Boote, Steve Cipolli, Vlad Yasevich, Mika Liljeberg, Ted Hardie,
 Vidya Narayanan, and Lars Eggert for useful discussions and

Nordmark, et al. Informational [Page 19] RFC 5014 Socket API for Source Address Selection September 2007

 suggestions.  Thanks to Remi Denis-Courmont, Brian Haberman, Brian
 Haley, Bob Gilligan, Jack McCann, Jim Bound, Jinmei Tatuya, Suresh
 Krishnan, Hilarie Orman, Geoff Houston, Marcelo Bungulo, and Jari
 Arkko for the review of this document and suggestions for
 improvement.

17. References

17.1. Normative References

 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC3484]  Draves, R., "Default Address Selection for Internet
            Protocol version 6 (IPv6)", RFC 3484, February 2003.
 [RFC3493]  Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
            Stevens, "Basic Socket Interface Extensions for IPv6",
            RFC 3493, February 2003.

17.2. Informative References

 [FPING]    "Fping - a program to ping hosts in parallel", Online web
            site http://www.fping.com.
 [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
            (IPv6) Specification", RFC 2460, December 1998.
 [RFC3041]  Narten, T. and R. Draves, "Privacy Extensions for
            Stateless Address Autoconfiguration in IPv6", RFC 3041,
            January 2001.
 [RFC3542]  Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei,
            "Advanced Sockets Application Program Interface (API) for
            IPv6", RFC 3542, May 2003.
 [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
            in IPv6", RFC 3775, June 2004.
 [RFC3971]  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
            Neighbor Discovery (SEND)", RFC 3971, March 2005.
 [RFC3972]  Aura, T., "Cryptographically Generated Addresses (CGA)",
            RFC 3972, March 2005.

Nordmark, et al. Informational [Page 20] RFC 5014 Socket API for Source Address Selection September 2007

Appendix A. Per-Packet Address Selection Preference

 This document discusses setting source address selection preferences
 on a per-socket basis with the new IPV6_ADDR_PREFERENCES socket
 option used in setsockopt().  The document does not encourage setting
 the source address selection preference on a per-packet basis through
 the use of ancillary data objects with sendmsg(), or setsockopt()
 with unconnected datagram sockets.
 Per-packet source address selection is expensive, as the system will
 have to determine the source address indicated by the application
 preference before sending each packet, while setsockopt() address
 preference on a connected socket makes the selection once and uses
 that source address for all packets transmitted through that socket
 endpoint, as long as the socket option is set.
 However, this document provides guidelines for those implementations
 that like to have an option on implementing transmit-side ancillary
 data object support for altering default source address selection.
 Therefore, if an application chooses to use the per-packet source
 address selection, then the implementation should process at the
 IPPROTO_IPV6 level (cmsg_level) ancillary data object of type
 (cmsg_type) IPV6_ADDR_PREFERENCES containing as data (cmsg_data[]) a
 32-bit unsigned integer encoding the source address selection
 preference flags (e.g., IPV6_PREFER_SRC_COA | IPV6_PREFER_SRC_PUBLIC)
 in a fashion similar to the advanced IPV6 Socket API [RFC3542].  This
 address selection preference ancillary data object may be present
 along with other ancillary data objects.
 The implementation processing the ancillary data object is
 responsible for the selection of the preferred source address as
 indicated in the ancillary data object.  Thus, an application can use
 sendmsg() to pass an address selection preference ancillary data
 object to the IPv6 layer.  The following example shows usage of the
 ancillary data API for setting address preferences:

Nordmark, et al. Informational [Page 21] RFC 5014 Socket API for Source Address Selection September 2007

 void *extptr;
 socklen_t extlen;
 struct msghdr msg;
 struct cmsghdr *cmsgptr;
 int cmsglen;
 struct sockaddr_in6 dest;
 uint32_t flags;
 extlen = sizeof(flags);
 cmsglen = CMSG_SPACE(extlen);
 cmsgptr = malloc(cmsglen);
 cmsgptr->cmsg_len = CMSG_LEN(extlen);
 cmsgptr->cmsg_level = IPPROTO_IPV6;
 cmsgptr->cmsg_type = IPV6_ADDR_PREFERENCES;
 extptr = CMSG_DATA(cmsgptr);
 flags = IPV6_PREFER_SRC_COA;
 memcpy(extptr, &flags, extlen);
 msg.msg_control = cmsgptr;
 msg.msg_controllen = cmsglen;
 /* finish filling in msg{} */
 msg.msg_name = dest;
 sendmsg(s, &msg, 0);
 Thus, when an IPV6_ADDR_PREFERENCES ancillary data object is passed
 to sendmsg(), the value included in the object is used to specify
 address preference for the packet being sent by sendmsg().

Appendix B. Intellectual Property Statement

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

Nordmark, et al. Informational [Page 22] RFC 5014 Socket API for Source Address Selection September 2007

Authors' Addresses

 Erik Nordmark
 Sun Microsystems, Inc.
 17 Network Circle
 Menlo Park, CA 94025
 USA
 EMail: Erik.Nordmark@Sun.com
 Samita Chakrabarti
 Azaire Networks
 3121 Jay Street, Suite 210
 Santa Clara, CA 95054
 USA
 EMail: samitac2@gmail.com
 Julien Laganier
 DoCoMo Euro-Labs
 Landsbergerstrasse 312
 D-80687 Muenchen
 Germany
 EMail: julien.IETF@laposte.net

Nordmark, et al. Informational [Page 23] RFC 5014 Socket API for Source Address Selection September 2007

Full Copyright Statement

 Copyright (C) The IETF Trust (2007).
 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.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

 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
 http://www.ietf.org/ipr.
 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
 ietf-ipr@ietf.org.

Nordmark, et al. Informational [Page 24]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5014.txt · Last modified: 2007/09/17 21:17 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki