doc: Add RFC documents

1 files changed, 1347 insertions, 0 deletions

diff --git a/doc/rfc/rfc5014.txt b/doc/rfc/rfc5014.txt
new file mode 100644
index 0000000..4d5347f
--- /dev/null
+++ b/doc/rfc/rfc5014.txt
@@ -0,0 +1,1347 @@
+
+
+
+
+
+
+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]
+