[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 RFC 5014

Network Working Group                                        E. Nordmark
Internet-Draft                                            S. Chakrabarti
Expires: December 28, 2003                        Sun Microsystems, Inc.
                                                             J. Laganier
                                       ENS Lyon / Sun Microsystems, Inc.
                                                           June 29, 2003


              IPv6 Socket API for source address selection
               <draft-chakrabarti-ipv6-addrselect-api-01.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 28, 2003.

Copyright Notice

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

Abstract

   The IPv6 default address selection document describes the rules for
   selecting default source address by the system and indicates that the
   applications should be able to reverse the sense of system preference
   of source address selection for that application through possible API
   extensions.  However, no such socket API exists in the basic or
   advanced IPv6 socket API documents.  Hence this document specifies
   socket level options to prefer a particular source address as per
   choice of the applications.  It also discusses implications on the
   name-to-address translation API that performs part of the default



Nordmark, et al.        Expires December 28, 2003               [Page 1]


Internet-Draft    IPv6 Socket API for source address selection June 2003


   address selection.  The socket APIs described in this document will
   be particularly useful for Mobile IPv6 enabled applications and other
   IPv6 applications which want to choose between temporary and public
   addresses, CGA (cryptographically generated addresses) and non-CGA
   addresses etc..

Table of Contents

   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .   3
   2. Example Usages . . . . . . . . . . . . . . . . . . . . . . . .   5
   3. Changes to the Socket Interface  . . . . . . . . . . . . . . .   6
   4. Changes to the protocol-independent nodename translation . . .   9
   5. IPv4-mapped IPv6 Addresses . . . . . . . . . . . . . . . . . .  12
   6. Validation function for source address . . . . . . . . . . . .  13
   7. Security Considerations  . . . . . . . . . . . . . . . . . . .  14
   8. Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . .  15
   9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  16
      Normative References . . . . . . . . . . . . . . . . . . . . .  17
      Informative References . . . . . . . . . . . . . . . . . . . .  18
      Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .  18
   A. Intellectual Property Statement  . . . . . . . . . . . . . . .  19
      Full Copyright Statement . . . . . . . . . . . . . . . . . . .  20






























Nordmark, et al.        Expires December 28, 2003               [Page 2]


Internet-Draft    IPv6 Socket API for source address selection June 2003


1. Introduction

   This document defines socket extensions to support the non-default
   choice of source address by the applications.  The IPv6 default
   address selection [1] document has specified the rules for system
   default source address selection for an outbound IPv6 packet.
   Privacy considerations [6] have introduced "public" and "temporary"
   addresses.  IPv6 Mobility [3] introduces "home address" and "care-
   of-address" definitions in the mobile systems.  Although it is
   desirable to have default algorithms for the system to choose the
   source address of the outgoing IPv6 packet, an application may want
   to reverse that rule for efficiency and other application specific
   reasons.  Currently IPv6 socket API extensions provide mechanism to
   choose a specific source address through simple bind() operation or
   IPV6_PKTINFO socket option [5].  Thus in order to use bind() or
   IPV6_PKTINFO socket option, the application itself must make sure
   that the source address is appropriate for the destination address
   (e.g., with respect to the interface used to send packets to the
   destination).  The application also needs to make sure about the
   appropriate scope of source address with respect to the destination
   address and so on.  The mechanism presented in this document allows
   the application to specify attributes of the source addresses it
   prefers while still having the system do the rest of the default
   address selection.  For instance, if an application prefers to use
   care-of-address of a mobile node as the source address and if the
   mobile node has two care-of-addresses (one public and one temporary),
   then the node would select the public care-of-address by following
   the default address selection rule for public and temporary address.

   A socket option has been deemed useful for this purpose, as it
   enables an application to make a choice of source address at per-
   socket basis.  It can also provide flexibility of enabling and
   disabling choice of source addresses in non-connected sockets.  The
   socket option uses a set of flags for source address preferences.
   Since source address selection and destination address ordering need
   to be partially implemented in getaddrinfo() [2] the corresponding
   set of flags are also defined for that routine.

   Thus this document introduces several flags for source address
   selection to alter the default source address selection [1] for a
   number of cases.  It also provides flags for choosing CGA [7]  and
   non-CGA source addresses when CGA addresses are available in the
   system.  In future, more flags can be added to designate a choice for
   a certain type of source address as the needs may arise.

   The approach in this document is to allow the application to specify
   preferences on source addresses and not to be able to specify hard
   requirements.  Thus for instance, an application can set a flag in



Nordmark, et al.        Expires December 28, 2003               [Page 3]


Internet-Draft    IPv6 Socket API for source address selection June 2003


   order to prefer a temporary addresses, but if no temporary addresses
   are available at the node, a public address would be chosen instead.

   Specifying a 'requirement' for source address selection is not
   adopted through the socket option flags due to the nature of
   unreliable transport protocols where the failure of connect()
   operation may appear late in the event of unavailability of the
   required attribute of source address in the system.  For example, if
   an application 'requires' CGA addresses as the source address of its
   outgoing packets and it fails without that, then the application may
   verify the availability of the CGA address in the system after
   setting the source address preference flags.  This document defines a
   verification function which applications may choose to use before
   sending data on a connected socket.  By "connected" socket we mean
   that a connect() call is done after setting setsockopt() with the
   preference attributes.  Note that connect() can be used in UDP
   datagram sockets as well.  The purpose of checking the validation of
   address after connect() call ensures the availability of the desired
   address type; an application using only sendto() or sendmsg() cannot
   guarantee that the validated address at the time of setsockopt() is
   still being valid at the time of sending data .  The configuration of
   node may change or the address may expire between setsockopt()
   setting and sendto() or sendmsg() call.

   Furthermore, the approach is to define two flags for each purpose, so
   that an application can specify either that it prefers 'X' or prefers
   'not X', or it can choose not to set either of the flags relating to
   'X' and leave it up to the system default, perhaps while specifying
   its preferences for some other attribute of the source addresses.
   For example, if setsockopt() with a preference to care-of-address is
   set, but no flag is set to indicate a choice of temporary or public
   address, then temporary vs.  public source address selection will be
   determined from the  default source address selection [1] rules.
   Thus not specifying either of "X" and "not X" leaves the "X" property
   of the address selection at the system default.
















Nordmark, et al.        Expires December 28, 2003               [Page 4]


Internet-Draft    IPv6 Socket API for source address selection June 2003


2. Example Usages

   The examples discussed here are limited to applications supporting
   Mobile IPv6, IPv6 Privacy Extensions and Cryptographically Generated
   Addresses.  Address selection document [1] recommends that home
   addresses should be preferred over care-of-address when both are
   configured.  However, a mobile node may want to prefer care-of-
   address as source address for DNS query in the foreign network as it
   normally means a shorter and local return path compared to the route
   via the mobile node's home-agent when the query contains home-address
   as source address.  Another example is IKE application which requires
   care-of-address as its source address for the initial security
   association pair with Home Agent [3] while the mobile node boots up
   at the foreign network and wants to do the key exchange before a
   successful  home-registration.  Also a Mobile IPv6 aware application
   may want to toggle between home-address and care-of-address depending
   on its location and state of the application.  It may also want to
   open different sockets and use home-address as source address for one
   socket and care-of-address for the others.

   In a non-mobile environment, similarly an application may prefer to
   use temporary address as source address for certain cases.  By
   default, the source address selction rule selects "public" address
   when both are available.  For example, an application supporting web
   browser and mail-server may want to use "temporary" address for the
   former and "public" address for the mail-server as a mail-server may
   require reverse path for DNS records for anti-spam rules.

   Similarly, a node  may be configured to use the cryptographically
   generated addresses by default, but an application may prefer not to
   use it.  For instance, fping, a debugging tool which tests basic
   reachability of multiple destinations by sending packets in parallel,
   may find that the cost and time incurred in proof-of- ownership by
   CGA verification is not justified.  On the other hand, when a node is
   not configured for CGA as default, an application may prefer using
   CGA by setting the socket option.  It may subsequently verify that it
   is truly bound to a CGA by first calling getsockname() and then
   recomputing the CGA using the public key of the node.

   Besides the above examples, the defined source address preference
   flags can be used to specify or alter the system default values for
   largest scope of addresses and native IPv6 vs.  tunnel interface
   addresses.








Nordmark, et al.        Expires December 28, 2003               [Page 5]


Internet-Draft    IPv6 Socket API for source address selection June 2003


3. Changes to the Socket Interface

   IPv6 Basic API [2] defines socket options for IPv6.  This document
   adds a new socket option at the IPPROTO_IPV6 level.  This socket
   option is called IPV6_SRC_PREFERENCES.  It can be used with
   setsockopt() and getsockopt() calls.  This socket option takes a
   32bit unsigned integer argument.  The argument consists of a number
   of flags which indicate the choice of source address selection.

   The following flags are defined to alter or set the default rule of
   source address selction algorithm discussed in the section 5 of
   default address selection specification [1].

   <netinet/in.h>.

      IPV6_PREFER_SRC_HOME    /* Prefer Home Address as source */
      IPV6_PREFER_SRC_COA     /* Prefer Care-Of_address as source */
      IPV6_PREFER_SRC_TMP     /* Prefer Temporary address as source */
      IPV6_PREFER_SRC_PUBLIC  /* Prefer Public address as source */
      IPV6_PREFER_SRC_CGA     /* Prefer CGA address as source */
      IPV6_PREFER_SRC_NONCGA  /* Prefer a non-CGA address as source */
      IPV6_PREFER_SRC_TUNNEL  /* Prefer tunnel interface  as source  */
      IPV6_PREFER_SRC_NATIVE   /* Prefer native IPv6 source  addr */
      IPV6_PREFER_SRC_LARGESTSCOPE /* Prefer largest scope source */
      IPV6_PREFER_SRC_LOWERSCOPE  /* Prefer less than largest scope */

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







   The following example illustrates how it is used on a AF_INET6
   socket:

   uint32_t flags = IPV6_PREFER_SRC_COA;

   if (setsockopt(s, IPPROTO_IPV6, IPV6_SRC_PREFERENCES,

                 (char *) &flags, sizeof (flags)) == -1) {

                   perror("setsockopt IPV6_SRC_REFERENCES");

   }





Nordmark, et al.        Expires December 28, 2003               [Page 6]


Internet-Draft    IPv6 Socket API for source address selection June 2003



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

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

   IPV6_PREFER_SRC_COA | IPV6_PREFER_SRC_NATIVE

   Sometimes an application being unaware of a previously set source
   address preference may need to restore it after a while.  In order to
   achieve this, it needs to preserve the value of the previous source
   address preference by doing a getsockopt() prior calling the
   setsockopt() for IPV6_SRC_PREFERENCES.  The returned preference flag
   values should be saved by the application for restoring the
   preference values in a later step.  However, setsockopt() with a flag
   value 0 resets the source address selection to the system default
   policy.

   Example:

   uint32_t save_flag;
   int optlen = sizeof (save_flag);

   uint32_t flags = IPV6_PREFER_SRC_TMP;

   /* Save the existing IPv6_SRC_PREFERENCE FLAG now */

   if (getsockopt(s, IPPROTO_IPV6, IPV6_SRC_PREFERENCES,

                                 &save_flag, &optlen) == -1 {

                 perror("getsockopt IPV6_SRC_REFERENCES");

   }




Nordmark, et al.        Expires December 28, 2003               [Page 7]


Internet-Draft    IPv6 Socket API for source address selection June 2003



   if (!(save_flag & IPV6_PREFER_SRC_TMP)) {
         if (setsockopt(s, IPPROTO_IPV6, IPV6_SRC_PREFERENCES,

                     (char *) &flags, sizeof (flags)) == -1) {

                       perror("setsockopt IPV6_SRC_REFERENCES");

          }

   }

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





































Nordmark, et al.        Expires December 28, 2003               [Page 8]


Internet-Draft    IPv6 Socket API for source address selection June 2003


4. Changes to the protocol-independent nodename translation

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

   Thus if an application sets setsockopt() IPV6_SRC_PREFERENCES option
   to alter the default address selection rules , it is recommended that
   the apllication calls getaddrinfo() with the corresponding
   AI_PREFER_SRC_* flags specified in this section.  This ensures that
   the first entry in the returned addrinfo structure has the matching
   source address as chosen by the kernel due to the setsockopt()
   IPV6_SRC_PREFERENCES operation, given all other rules being equal for
   a specific destination.

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

   The following numerical example clarifies the abover further.

   Imagine a host with two addresses:

   1234::1:1    public

   9876::1:2    temporary






Nordmark, et al.        Expires December 28, 2003               [Page 9]


Internet-Draft    IPv6 Socket API for source address selection June 2003


   The destination has the following two addresses:

   1234::9:3

   9876::9:4

   By default getaddrinfo() will return the destination addresses in the
   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_PREFER_SRC_TMP is set, getaddrinfo will return the addresses in
   the reverse order since the temporary source address will be
   preferred.



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

      AI_PREFER_SRC_HOME        /* Prefer Home Address */
      AI_PREFER_SRC_COA         /* Prefer COA  */
      AI_PREFER_SRC_TMP         /* Prefer Temporary Address */
      AI_PREFER_SRC_PUBLIC      /* Prefer Public Address */
      AI_PREFER_SRC_CGA         /* Prefer CGA Address */
      AI_PREFER_SRC_NONCGA      /* Prefer address other than CGA */
      AI_PREFER_SRC_LARGESTSCOPE  /* Prefer largest scope */
      AI_PREFER_SRC_LOWERSCOPE    /* Prefer lower than largest scope */
      AI_PREFER_SRC_TUNNEL        /* Prefer address of tunnel interface */
      AI_PREFER_SRC_NATIVE        /* Prefer native IPv6 address */

   The above flags are ignored for the AF_INET address family as the
   source address selection algorithm defined in section 5 of [1] only
   applies to the IPv6 addresses.  However, the  flags may be applied to
   IPv4-mapped addresses on a AF_INET6 socket.

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



Nordmark, et al.        Expires December 28, 2003              [Page 10]


Internet-Draft    IPv6 Socket API for source address selection June 2003


   Some valid sequences of flags are:

      AI_PREFER_SRC_HOME | AI_PREFER_SRC_PUBLIC

      AI_PREFER_SRC_COA  | AI_PREFER_SRC_PUBLIC

      AI_PREFER_SRC_HOME | AI_PREFER_SRC_CGA

      AI_PREFER_SRC_HOME | AI_PREFER_SRC_NONCGA

      AI_PREFER_SRC_COA  | AI_PREFER_SRC_CGA

      AI_PREFER_SRC_COA  | AI_PREFER_SRC_NONCGA

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



































Nordmark, et al.        Expires December 28, 2003              [Page 11]


Internet-Draft    IPv6 Socket API for source address selection June 2003


5. IPv4-mapped IPv6 Addresses

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

   Discussion:

   Would it be simpler to define a seperate function for source address
   selection purpose?

   int get_srcaddrinfo(uint32_t srcflags, const struct addrinfo * hints,

   struct addrinfo ** res);  or some variant ? which operates only on
   AF_INET6 sockets - it then does not overload the getaddrinfo AI flags
   and also does not conflict with using original getaddrinfo() function
   which deals with AF_INET and UNSPEC families.






























Nordmark, et al.        Expires December 28, 2003              [Page 12]


Internet-Draft    IPv6 Socket API for source address selection June 2003


6. Validation function for source address

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

   <netinet/in.h>.

   boolean_t  inet6_is_addr(struct in6_addr * srcaddr, uint32_t flags)

   Where the flags contain the IPV6_PREFER_SRC_* flags.  The function
   expects a non-NULL input for srcaddr.  It returns true when srcaddr
   corresponds to a valid address in the node and that address type
   satisfies the preference flag.  If srcaddr input value does not
   correspond to any  address in the node or it does not match an
   address which satisfy the preferences indicated, the function returns
   false.

   The above function is useful for an application in two ways:

   1.  verify the source address type with the preference choice after
       calling setsockopt() and connect()  followed by getsockname().

   2.  verify that the source address returned in the addrinfo structure
       in the getaddrinfo() function matches the choice of preference.

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

   Discussion

   Does it make sense to make inet6_is_addr() function more flexible ?
   i,e.  one can pass NULL srcaddr and preference flag in order to find
   out if such address type at all exists in the system.  This is useful
   feature for some applications which has hard requirement for the
   address type.  Although the validity result is not guaranteed to be
   true all the time between the check and subsequent socket operation,
   this feature may be useful for those address types which has higher
   lifetime or validity expectancy such as scoped or tunnel interface
   addresses.






Nordmark, et al.        Expires December 28, 2003              [Page 13]


Internet-Draft    IPv6 Socket API for source address selection June 2003


7. Security Considerations

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












































Nordmark, et al.        Expires December 28, 2003              [Page 14]


Internet-Draft    IPv6 Socket API for source address selection June 2003


8. Open Issues

   o  Are there more flags we should define at this point in time?

   o  How about a separate func for get_srcadrinfo or something like
      that? Should we ban IPv4 sockets to use this API ? Is 32bit flags
      enough ? Would this API be used for other policy decisions such as
      Security or Qos policy decision to choose an address ? It may be
      easier to have separate API for IPSec and Qos, but then order of
      preference of those API compared to the ones defined here, needs to
      be defined.

   o  Should we make the validation function more generic and flexible ?
      [See section 6 discussion ]

   o  Should we define a order of preference and combination of
      attributes provided by IPV6_PREFER_SRC* flags ?


































Nordmark, et al.        Expires December 28, 2003              [Page 15]


Internet-Draft    IPv6 Socket API for source address selection June 2003


9. Acknowledgements

   The authors like to thank members of mobile-ip and ipv6 working
   groups for useful discussion on this topic.  Richard Draves and Dave
   Thaler suggested that getaddrinfo also needs to be considered along
   with the new socket option.  Gabriel Montenegro suggested that CGAs
   may also be considered in this document.  Thanks to Alain Durand,
   Renee Danson, Alper Yegin and Francis Dupont for useful discussions.











































Nordmark, et al.        Expires December 28, 2003              [Page 16]


Internet-Draft    IPv6 Socket API for source address selection June 2003


Normative References

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

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











































Nordmark, et al.        Expires December 28, 2003              [Page 17]


Internet-Draft    IPv6 Socket API for source address selection June 2003


Informative References

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

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

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

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

   [7]  Castelluccia, C. and G. Montenegro, "Securing Group Management
        in IPv6 with Cryptographically Generated  Addresses", draft-
        irtf-gsec-sgmv6-01.txt (work in progress), July 2002.

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


Authors' Addresses

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

   EMail: Erik.Nordmark@Sun.COM


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

   EMail: Samita.Chakrabarti@Sun.COM









Nordmark, et al.        Expires December 28, 2003              [Page 18]


Internet-Draft    IPv6 Socket API for source address selection June 2003


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

   EMail: Julien.Laganier@Sun.COM











Appendix A. Intellectual Property Statement

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


























Nordmark, et al.        Expires December 28, 2003              [Page 19]


Internet-Draft    IPv6 Socket API for source address selection June 2003


Full Copyright Statement

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

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

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

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

Acknowledgement

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



















Nordmark, et al.        Expires December 28, 2003              [Page 20]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/