I've read your draft. My first comment is that an API in that space is badly needed, so I fully support an effort to standardize such an API.
My second comment is on the suggested API itself. Some of the rules in the address selection RFC are common sense, some are really 'suggested practices' that make sense in common cases, but not in all. So, I would like to see an API that enable to change ALL the rules in the second category. for example: prefer larger scope, prefer v4 over v6,....
From your list of open question, I would like to see a 'request foo' option too. An application may say: 'request non IPv4-mapped', or reqest 'global'. If such an address in not available at the time, the syscall could return an error.
Another thing I would like to see would be some tie-breakers,
when a application could say: 'all things beeing equal, I rather like to use x'
- Alain.
Samita Chakrabarti wrote:
We have had discussion about requirement of having a socket-API on source address selection, in this alias.
A draft has been submitted to address source address selection at the per-socket (and per apps) basis. Currently it discusses preferences of source address selection by the application for privacy addresses, mobileipv6 addresses and Cryptographically generated addresses. Thus the application can reverse the sense of default source address selection by using the proposed APIs.
Please provide your comments/feedback on the alias and to the authors.
We have listed some open issues in the draft as well to seek suggestions from the working group for further enhancement of the draft.
The draft will be available in the draft directory shortly, however, I am including the text file here.
Thanks,
-Samita
------------------------------------------------------------------------
INTERNET-DRAFT Erik Nordmark Expires: August, 2003 Samita Chakrabarti Sun Microsystems, Inc.
Julien Laganier
Sun Microsystems, Inc.
LIP / ENS-Lyon
February, 2003
IPv6 Socket API for source address selection
Status of this Memo
This document is an Internet-Draft and is subject to 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 expires August, 2003.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
draft-chakrabarti-ipv6-addrselect-api-00.txt [Page 1] INTERNET-DRAFT IPv6 Socket API for source address selection Feb., 2003
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 APIs exist in the
basic or advanced IPv6 socket API documents. Hence this document specifies socket level options to prefer a particular source address as per the choice of the applications. It also discusses implications on the name-to-address translation API that performs
part of the default 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 Usage .......................................... 4
3. Changes to the Socket Interface ........................ 5
4. Changes to the protocol-independent nodename translation ............................ 6
5. IPv4-Mapped IPv6 Addresses .............................. 7
6. Security Considerations ................................. 7
7. Open Issues ............................................. 7
8. References .............................................. 8
9. Acknowledgements ........................................ 8
10. Authors' Addresses ...................................... 9
draft-chakrabarti-ipv6-addrselect-api-00.txt [Page 2] INTERNET-DRAFT IPv6 Socket API for source address selection Feb., 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 does not provide a
mechanism to choose a particular source address other than simple
bind() operation. The bind() operation allows an application to
specify a particular source address. Thus in order to use bind() 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.
A socket option has been deemed useful for this purpose, as it enables an application ability to make a choice of source address at per-socket basis as well as it can 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 different flags for source address selection that can be used by the applications for Mobility [3], Privacy Extension [6] and CGA [7] scenarios. 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 specify that it
prefers temporary addresses but if no temporary addresses are available to the default address selection algorithm, a public
address would be chosen instead.
draft-chakrabarti-ipv6-addrselect-api-00.txt [Page 3] INTERNET-DRAFT IPv6 Socket API for source address selection Feb., 2003
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 specifing its preferences for some other attribute of the source
addresses.
2. Example Usages
The examples of usages 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
genenerated 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.
draft-chakrabarti-ipv6-addrselect-api-00.txt [Page 4]
INTERNET-DRAFT IPv6 Socket API for source address selection Feb., 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 flags defined in this document are:
IPV6_PREFER_SRC_HOME IPV6_PREFER_SRC_COA IPV6_PREFER_SRC_TMP IPV6_PREFER_SRC_PUBLIC IPV6_PREFER_SRC_CGA IPV6_PREFER_SRC_NONCGA
The following example illustrates how it is used:
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"); }
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 the option is not set, the system selects
a default value. Setting conflicting flags at the same time results
in the error EINVAL.
It is recommended that the application does a getsockopt() prior
calling to setsockopt() call so that it can save the existing
source address preference value, in the cases when the application
might need to restore the preferences.
The constants mentioned in this section are defined in <netinet/in.h>.
draft-chakrabarti-ipv6-addrselect-api-00.txt [Page 5]
INTERNET-DRAFT IPv6 Socket API for source address selection Feb., 2003
4. Changes to the protocol-independent nodename translation
Section 8 of Default Address Selction [1] document indicates about
possible implementation strategy for getaddrinfo() [2]. getaddrinfo() collects available source addresses from the network
layer and then it sorts the list of source addresses as per source
address selection rules. Thus if an application sets setsockopt()
IPV6_SRC_PREFERENCES option to alter the default address selection
rules , it must make sure that it calls getaddrinfo() with the
corresponding flags specified in this section. This will ensure
correct behavior of getaddrinfo() destination address selection
based on the sorted list of source addresses as per the socket
source address selection preferences.
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
AI_PREFER_SRC_COA
AI_PREFER_SRC_TMP
AI_PREFER_SRC_PUBLIC
AI_PREFER_SRC_CGA
AI_PREFER_SRC_NONCGA
The above flags are ignored for the AF_INET address family. If a
returned address is an IPv4 address (either as AF_INET6 when
AI_V4MAPPED, or as AF_INET) then the source preference flags have
no effect.
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].
Some valid sequences of flags would be:
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>.
draft-chakrabarti-ipv6-addrselect-api-00.txt [Page 6] INTERNET DRAFT IPv6 Socket API for source address selection Feb., 2003
5. IPv4-Mapped IPv6 Addresses
IPv4-Mapped IPv6 addresses are not supported for setting preference
on home, care-of-address, CGA, non-CGA, public or privacy auto-
configured addresses as source addresses. Because they are all pure
IPv6 addresses.
6. Security Considerations
This document conforms to the same security implications as specified in IPv6 Basic Socket API [2] document. It is also recommended that the applications set IPV6_V6ONLY IP level socket option to permit the nodes to not process IPv4 packets as IPv4 Mapped addresses. 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.
7. Open Issues
- Are there more flags we should define at this point in time? For instance, PREFER_LARGEST_SCOPE?
- Is there a need for REQUIRE flags in addition to or instead of the
PREFER flags? Note that in general it isn't possible to verify that a requirement can be satisfied until sendto() or connect()
(when the destination address is known) thus this would result
in late errors being reported to the application.
- Is there a need for "validation" functions to go with these preferences such as functions that check whether an address is a temporary address?
draft-chakrabarti-ipv6-addrselect-api-00.txt [Page 7] INTERNET-DRAFT IPv6 Socket API for source address selection Feb., 2003
8. References
Normative references:
[1] Richard Draves, "Default Address Selection for IPv6", draft-ietf-ipv6-default-addr-select-09.txt, August 6, 2002.
[2] R.E. Gilligan, S. Thomson, J. Bound, J. McCann, W. R. Stevens,
"Basic Socket Interface Extensions for IPv6", draft-ietf-ipngwg-rfc2553bis-10.txt, December, 2002.
Informative references:
[3] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in IPv6" draft-ietf-mobileip-ipv6-20.txt, January, 2003.
[4] Deering, S., Hinden, R., "Internet Protocol, Version 6 (IPv6), Specification", RFC 2460, Dec. 1998.
[5] Stevens, W. R, Thomas, M., Nordmark, E., Jinmei, T., "Advanced
Sockets API for IPv6", draft-ietf-ipngwg-rfc2292bis-07.txt April 19, 2002.
[6] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[7] Montenegro, G. and C. Castelluccia, "Statistically Unique and
Cryptographically Verifiable (SUCV) Identifiers and Addresses.", NDSS 2002, February 2002.
[8] Castelluccia, C. and G. Montenegro, "Securing Group Management in IPv6 with Cryptographically Generated Addresses", draft-irtf-gsec-sgmv6-01 (work in progress), July 2002.
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.
draft-chakrabarti-ipv6-addrselect-api-00.txt [Page 8] INTERNET-DRAFT IPv6 Socket API for source address selection Feb., 2003
10. Authors' Addresses
Erik Nordmark Sun Microsystems Laboratories, Europe 180 Avenue de l'Europe 38334 Saint Ismier, France Email: [EMAIL PROTECTED]
Samita Chakrabarti
Sun Microsystems, Inc. 4150 Network Circle Santa Clara, CA 95054, USA
Email: [EMAIL PROTECTED]
Julien Laganier Sun Microsystems Laboratories, Europe
180 Avenue de l'Europe
38334 Saint Ismier, France
Email: [EMAIL PROTECTED]
draft-chakrabarti-ipv6-addrselect-api-00.txt [Page 9]
-------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
