Network Working Group E. Nordmark
Internet-Draft S. Chakrabarti
Expires: January 13, 2006 Sun Microsystems, Inc.
J. Laganier
DoCoMo Euro-Labs
July 12, 2005
IPv6 Socket API for Address Selection
draft-chakrabarti-ipv6-addrselect-api-03
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 January 13, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
The IPv6 default address selection document, RFC 3484, describes the
rules for selecting source and destination IP addresses, and
indicates that the 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 or advanced IPv6
socket API documents. This document fills that gap by specifying
Nordmark, et al. Expires January 13, 2006 [Page 1]
Internet-Draft IPv6 Socket API for Address Selection July 2005
socket level options add new flags for the getaddrinfo() API to
specify preferences for address selection that modify the default
address selection algorithm. The socket APIs described in this
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Design Alternatives . . . . . . . . . . . . . . . . . . . . 6
3. Example Usages . . . . . . . . . . . . . . . . . . . . . . . 7
4. Additions to the Socket Interface . . . . . . . . . . . . . 9
5. Additions to the protocol-independent nodename translation . 11
6. Application Requirements . . . . . . . . . . . . . . . . . . 14
7. Implementation Notes . . . . . . . . . . . . . . . . . . . . 16
8. Mapping to Default Address Selection Rules . . . . . . . . . 17
9. IPv4-mapped IPv6 Addresses . . . . . . . . . . . . . . . . . 19
10. Validation function for source address . . . . . . . . . . . 20
11. Security Considerations . . . . . . . . . . . . . . . . . . 22
12. Changes from previous version of draft . . . . . . . . . . . 23
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 24
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
14.1 Normative References . . . . . . . . . . . . . . . . . . 25
14.2 Informative References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 26
A. Intellectual Property Statement . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . 28
Nordmark, et al. Expires January 13, 2006 [Page 2]
Internet-Draft IPv6 Socket API for Address Selection July 2005
1. Introduction
RFC 3484 [1] specifies the default address selection rules. This
document defines socket API extensions that allow the applications to
override the default choice of address selection. Privacy
considerations [7] have introduced "public" and "temporary"
addresses. IPv6 Mobility [4] introduces "home address" and "care-of-
address" definitions in the mobile systems. Some applications might
want to control whether large scope [2] or small scope IPv6 addresses
are preferred.
The default rules in [1] 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 mechanism to choose a
specific source address through simple bind() operation or
IPV6_PKTINFO socket option [6]. 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. 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 preferences with respect to
one of the rules.
The mechanism presented in this document allows the application to
specify attributes of the source (and destination) addresses it
prefers while still having the system perform the rest of 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 address
preferences. Since source address selection and destination address
Nordmark, et al. Expires January 13, 2006 [Page 3]
Internet-Draft IPv6 Socket API for Address Selection July 2005
ordering need to be partially implemented in getaddrinfo() [3] the
corresponding set of flags are also defined for that routine.
As a result, this document introduces several flags for address
selection preferences that alter the default address selection [1]
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
[8][9] and non-CGA source addresses when CGA addresses are available
in the system. In the future, more destination or source flags may
be added to expand the API as the needs may arise.
The approach in this document is to allow the application to specify
preferences for address selection and not to be able to specify hard
requirements. Thus for instance, an application can set a flag to
prefer a temporary source address, but if no temporary source
addresses are available at the node, a public address would be chosen
instead.
Specifying hard requirements for address selection would be
problematic for several reasons. The major one is that in the vast
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, might prefer to use a care-of-
address when running on a mobile host which is away from home since
this provides a short round-trip time in many cases. But if the
application is running on a mobile host that is at home, or running
on a host which 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() primitive, 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(), which would introduce new failure modes.
For the few applications that have hard requirements on the
attributes of the IP addresses it uses, this document defines a
verification function which such applications can use so that they
can properly fail to communicate if their address selection
requirements are not satisfied.
Furthermore, the approach is to define two flags for each rule that
can be modified, so that an application can specify either that it
prefers 'X' or prefers 'not X', or it can choose not to set either of
the flags relating to 'X' and leave it up to the system default (see
section 3.1). This approach allows different implementations to have
Nordmark, et al. Expires January 13, 2006 [Page 4]
Internet-Draft IPv6 Socket API for Address Selection July 2005
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 this approach for getaddrinfo.)
This document only specifies the extensions for the socket API since
the socket API is already specified in RFCs [3]. The intent is that
this document serve as a model for expressing preferences for
attributes of IP addresses, that also need to be expressable in other
networking API such as those found in middleware systems and the Java
environment.
Nordmark, et al. Expires January 13, 2006 [Page 5]
Internet-Draft IPv6 Socket API for Address Selection July 2005
2. Design Alternatives
Some suggested to have per-application flags instead of per-socket
flags. However, this design stays with per-socket flags for the
following reasons:
o While some system have per environment/application flags (such as
environment variables in Unix systems) this might not be available
in all systems which implement the socket API
o When an application links with some standard library that library,
unknown to the application, might be using the socket API.
Mechanisms that would provide per application flags may affect not
only the application itself but also the libraries creating risks
of unintended consequences.
Instead of the pair of 'X' and 'not X' flags for each rule that can
be modified, the socket option could have been defined to use a
single 'X' 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 'X' 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 expressable in the parameters
that are passed with a single getaddrinfo() call. Hence, for
consistency, the 'X'/'not X' approach is used for both getaddrinfo()
and setsockopt().
Nordmark, et al. Expires January 13, 2006 [Page 6]
Internet-Draft IPv6 Socket API for Address Selection July 2005
3. Example Usages
The examples discussed here are limited to applications supporting
Mobile IPv6, IPv6 Privacy Extensions and Cryptographically Generated
Addresses. Address selection document [1] recommends that home
addresses should be preferred over care-of-address when both are
configured. However, a mobile node may want to prefer care-of-
address as source address for DNS query in the foreign network as it
normally means a shorter and local return path compared to the route
via the mobile node's home-agent when the query contains home-address
as source address. Another example is IKE application which requires
care-of-address as its source address for the initial security
association pair with Home Agent [4] while the mobile node boots up
at the foreign network and wants to do the key exchange before a
successful home-registration. Also a Mobile IPv6 aware application
may want to toggle between home-address and care-of-address depending
on its location and state of the application. It may also want to
open different sockets and use home-address as source address for one
socket and care-of-address for the others.
In a non-mobile environment, similarly an application may prefer to
use temporary address as source address for certain cases. By
default, the source address selection rule selects "public" address
when both are available. For example, an application supporting web
browser and mail-server may want to use "temporary" address for the
former and "public" address for the mail-server as a mail-server may
require reverse path for DNS records for anti-spam rules.
Similarly, a node may be configured to use the cryptographically
generated addresses by default, as in Secure Neighbor Discovery, but
an application may prefer not to use it. For instance, fping, a
debugging tool which tests basic reachability of multiple
destinations by sending packets in parallel, may find that the cost
and time incurred in proof-of-ownership by CGA verification is not
justified. On the other hand, when a node is not configured for CGA
as default, an application may prefer using CGA by setting the socket
option. It may subsequently verify that it is truly bound to a CGA
by first calling getsockname() and then recomputing the CGA using the
public key of the node.
In addition to the above examples, the defined address preference
flags can be used to specify or alter the system default values for
largest scope of addresses as well. An application may want to use
only link-local source address to contact a node with global
destination address on the same link, it can do so by setting the
appropriate source address preference flag in the application. By
default the system would have chosen global source address. This
example assumes that only link-local and global addresses are
Nordmark, et al. Expires January 13, 2006 [Page 7]
Internet-Draft IPv6 Socket API for Address Selection July 2005
available on the nodes.
Nordmark, et al. Expires January 13, 2006 [Page 8]
Internet-Draft IPv6 Socket API for Address Selection July 2005
4. Additions to the Socket Interface
IPv6 Basic API [3] defines socket options for IPv6. This document
adds a new socket option at the IPPROTO_IPV6 level. This socket
option is called IPV6_ADDR_PREFERENCES. It can be used with
setsockopt() and getsockopt() calls. This socket option takes a
32bit unsigned integer argument. The argument consists of a number
of flags where each flag indicates an address selection preference
which modifies one of the rules in the default address selection
specification.
The following flags are defined to alter or set the default rule of
source and destination address selection rules discussed in default
address selection specification [1].
<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_LARGESCOPE /* Prefer larger scope source */
IPV6_PREFER_SRC_SMALLSCOPE /* Prefer smaller scope source */
NOTE: No source preference flag for longest matching prefix is
defined here because it is believed to be handled by the policy table
defined in the default address selection specification.
Flags corresponding to scoped destination address rules are defined
here as they make sense in the context of a sender. See section 8
for more analysis and mapping of rules and different flags.
IPV6_PREFER_DST_LARGESCOPE /* Prefer larger scope for dest */
IPV6_PREFER_DST_SMALLSCOPE /* Prefer smaller scope for dest */
The following example illustrates how it is used on a AF_INET6
socket:
Nordmark, et al. Expires January 13, 2006 [Page 9]
Internet-Draft IPv6 Socket API for Address Selection July 2005
uint32_t flags = IPV6_PREFER_SRC_COA;
if (setsockopt(s, IPPROTO_IPV6, IPV6_ADDR_PREFERENCES,
(char *) &flags, sizeof (flags)) == -1) {
perror("setsockopt IPV6_ADDR_REFERENCES");
}
When the IPV6_ADDR_PREFERENCES is successfully set with setsockopt(),
the option value given is used to specify address preference for any
connection initiation through the socket and all subsequent packets
sent via that socket. If no option is set, the system selects a
default value as per default address selection algorithm or by some
other equivalent means.
Setting conflicting flags at the same time results in the error
EINVAL. For example, setting 'X' and 'not X' is not allowed at the
same time. If flag is set as combination of 'X' and 'Y', and if 'Y'
is not applicable or available in the system, then the selected
address has attribute 'X' and system default for the attribute 'Y'.
For example, a possible valid combination of flags can be:
IPV6_PREFER_SRC_PUBLIC | IPV6_PREFER_SRC_LARGESCOPE
Nordmark, et al. Expires January 13, 2006 [Page 10]
Internet-Draft IPv6 Socket API for Address Selection July 2005
5. Additions to the protocol-independent nodename translation
Section 8 of Default Address Selection [1] document indicates
possible implementation strategies for getaddrinfo() [3]. 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().
This implies that getaddrinfo() needs to 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 uses setsockopt() with the
IPV6_ADDR_PREFERENCES option to alter the default address selection
rules, the application must also use the corresponding flags with its
getaddrinfo() call. The AI_PREFER_* flags that correspond to the
IPV6_PREFER_* flags are defined below.
There is no corresponding destination address selection rule for
source address selection rule 7, in default address selection
document. However, this API provides a way for an application to
make sure that the source address preference set in setsockopt() is
taken into account by the getaddrinfo() function. Let's consider an
example to understand this scenario. DA and DB are two global
destination addresses and the node has two global addresses SA and SB
through interface A and B respectively. SA is a temporary address
while SB is a public address. The application has set
IPV6_PREFER_SRC_TMP in the setsockopt() flag. The route to DA points
to interface A and route to DB points to interface B. Thus when
AI_PREFER_SRC_TMP is set , getaddrinfo() returns DA before DB and SA
before SB likewise. Similarly, getaddrinfo() returns DB before DA
when AI_PREFER_SRC_PUBLIC is set in this example. Thus the source
address preference is taking effect into destination address
selection and as well as source address selection by the
getaddrinfo() function.
The following numerical example clarifies the above further.
Imagine a host with two addresses:
1234::1:1 public
9876::1:2 temporary
The destination has the following two addresses:
Nordmark, et al. Expires January 13, 2006 [Page 11]
Internet-Draft IPv6 Socket API for Address Selection July 2005
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 [3].
AI_PREFER_SRC_HOME /* Prefer Home Address */
AI_PREFER_SRC_COA /* Prefer COA */
AI_PREFER_SRC_TMP /* Prefer Temporary Address */
AI_PREFER_SRC_PUBLIC /* Prefer Public Address */
AI_PREFER_SRC_CGA /* Prefer CGA Address */
AI_PREFER_SRC_NONCGA /* Prefer address other than CGA */
AI_PREFER_SRC_LARGESCOPE /* Prefer larger scope src */
AI_PREFER_SRC_SMALLSCOPE /* Prefer smaller scope src */
AI_PREFER_DST_LARGESCOPE /* Prefer larger scope dest. */
AI_PREFER_DST_SMALLSCOPE /* Prefer smaller scope dest.*/
The above flags are ignored for the AF_INET address family as the
address selection algorithm defined in section 5 of [1] only applies
to the IPv6 addresses.
If conflicting flags such as AI_PREFER_SRC_HOME and AI_PREFER_SRC_
COA are set, the getaddrinfo() fails with an error EAI_BADFLAGS [3].
Some valid combinations of flags are:
Nordmark, et al. Expires January 13, 2006 [Page 12]
Internet-Draft IPv6 Socket API for Address Selection July 2005
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
AI_PREFER_SRC_LARGESCOPE | AI_PREFER_DST_LARGESCOPE
AI_PREFER_SRC_SMALLSCOPE | AI_PREFER_DST_SMALLSCOPE
AI_PREFER_SRC_LARGESCOPE | AI_PREFER_DST_LARGESCOPE |
AI_PREFER_SRC_PUBLIC
All the constants mentioned in this section for ai_flags are defined
in <netdb.h>.
Nordmark, et al. Expires January 13, 2006 [Page 13]
Internet-Draft IPv6 Socket API for Address Selection July 2005
6. Application Requirements
An application only needs to call getsockopt() prior calling
setsockopt() if the application needs to be able to restore the
socket back to the system default preferences. An application which
does not have this requirement can just use getaddrinfo() to specify
the preferences, followed by:
uint32_t flags;
flags = IPV6_PREFER_SRC_TMP;
if (setsockopt(s, IPPROTO_IPV6, IPV6_ADDR_PREFERENCES,
(char *) &flags, sizeof (flags)) == -1) {
perror("setsockopt IPV6_ADDR_REFERENCES");
}
An application which 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 FLAG now */
if (getsockopt(s, IPPROTO_IPV6, IPV6_ADDR_PREFERENCES,
&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,
(char *) &flags, sizeof (flags)) == -1) {
perror("setsockopt IPV6_ADDR_REFERENCES");
}
/* Do some work with the socket */
;
/ Restore the flags */
flags = IPV6_PREFER_SRC_TMP;
if (setsockopt(s, IPPROTO_IPV6, IPV6_ADDR_PREFERENCES,
(char *) &save_flags, sizeof (save_flags)) == -1) {
perror("setsockopt IPV6_ADDR_REFERENCES");
}
Application must not set conflicting flags; the only conflicts that
are checked for are flag X and flag not-X being set at the same time.
Nordmark, et al. Expires January 13, 2006 [Page 14]
Internet-Draft IPv6 Socket API for Address Selection July 2005
Example of conflicting flags: IPV6_PREFER_SRC_TMP |
IPV6_PREFER_SRC_PUBLIC.
In order to allow different implementations to do different parts of
address selection in getaddrinfo() and in the protocol stack, this
specification requires that applications set the same flags when
calling getaddrinfo() and when calling setsockopt(). For example, if
the application sets IPV6_PREFER_SRC_COA flag, it must use
AI_PREFER_SRC_COA flag when calling getaddrinfo(). If applications
are not setting the same flags the behavior of the implementation is
undefined.
It is envisioned that Mobile IPv6 applications may want to choose
Care-of-Address as source for short transaction (for efficiency)
while roaming, but still keep Home address as source address for long
lived communication for address stability. Thus it is recommended
that applications take this idea into consideration and use the
source address selection API for home-address and care-of -address
selection appropriately. Similarly, an application may choose to set
IPV6_PREFER_SRC_COA flag for datagram services; it uses home-address
as source when at home and uses care-of-address outside home-network
for short datagram transactions. This is an advantage of having
flexibility of "preference" vs. "requirement".
Nordmark, et al. Expires January 13, 2006 [Page 15]
Internet-Draft IPv6 Socket API for Address Selection July 2005
7. Implementation Notes
o If either bind() or IPV6_PKTINFO socket option is set with a
specific source address in the same application along with the
address preference socket option, then bind() or IPV6_PKTINFO
option takes precedence.
o setsockopt() should silently ignore any address preference flags
that are not supported in the system. For example, a host which
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 when
invalid flag values are passed to them. The invalid flag values
are: flag X and flag not-X (set at the same time).
o If an implementation supports both stream and datagram sockets, it
should implement the address preference mechanism API described in
this document on types of sockets.
o Implementation supporting this API must implement both AI flags
and socket option flags processing for portability of
applications.
o An implementation may choose to set the following flags by default
on the system (which is consistent with [1] defaults):
IPV6_PREFER_SRC_HOME
IPV6_PREFER_SRC_PUBLIC
IPV6_PREFER_SRC_LARGESCOPE
IPV6_PREFER_SRC_CGA
IPV6_PREFER_DST_SMALLSCOPE
Nordmark, et al. Expires January 13, 2006 [Page 16]
Internet-Draft IPv6 Socket API for Address Selection July 2005
8. Mapping to Default Address Selection Rules
This API defines only those flags that are deemed to be useful by the
applications to alter default address selection rules. Thus we
discuss the mapping of each set of flags to the corresponding rule
number in the address selection document[1].
Source address selection rule #4 (prefer home address):
IPV6_PREFER_SRC_HOME (default)
IPV6_PREFER_SRC_COA
AI_PREFER_SRC_HOME (default)
AI_PREFER_SRC_COA
Source address selection rule #7 (prefer public address) :
IPV6_PREFER_SRC_PUBLIC (default)
IPV6_PREFER_SRC_TMP
AI_PREFER_SRC_PUBLIC (default)
AI_PREFER_SRC_TMP
Source address selection rule #2 (prefer appropriate scope):
IPV6_PREFER_SRC_LARGESCOPE (default)
IPV6_PREFER_SRC_SMALLSCOPE
AI_PREFER_SRC_LARGESCOPE (default)
AI_PREFER_SRC_SMALLSCOPE
The LARGESCOPE default above is to prefer source addresses that
have a scope equal or larger than the scope of the destination
address. The inverse is to prefer source address that have a
scope smaller than the scope of the destination address.
Destination address selection rule #8 ( prefer smaller scope):
IPV6_PREFER_DST_SMALLSCOPE (default)
IPV6_PREFER_DST_LARGESCOPE
Nordmark, et al. Expires January 13, 2006 [Page 17]
Internet-Draft IPv6 Socket API for Address Selection July 2005
AI_PREFER_DST_SMALLSCOPE (default)
AI_PREFER_DST_LARGESCOPE
Other destination rules (#4-prefer home address; #7-prefer native
interfaces) could have been applicable. But the problem is that the
local system does not know whether a destination address is a tunnel-
address for destination rule #7. It can only know for sure if the
destination address is one of its own. The flags defined for source
address selection rule #4 ( prefer home address) should also take
care of destination address selection rule #4. Thus at this point,
it was decided not to define flags for these destination rules.
Other source address rules (that are not mentioned here) were also
deemed not applicable for changing its default notion per-application
basis.
Nordmark, et al. Expires January 13, 2006 [Page 18]
Internet-Draft IPv6 Socket API for Address Selection July 2005
9. IPv4-mapped IPv6 Addresses
IPv4-mapped IPv6 addresses, which are IPv4 addresses in a form that
can be used on an AF_INET6 socket, are supported in this API. In
some cases the IPv4-mapped addresses may not make much sense because
the attributes are IPv6 specific. For example, IPv6 temporary
addresses are not the same as private IPv4 addresses. However, the
IPv4 mapped-address support may be useful for mobile home address and
care-of-address. At this point it is not understood whether this API
has any value to IPv4 addresses or AF_INET family of sockets.
Nordmark, et al. Expires January 13, 2006 [Page 19]
Internet-Draft IPv6 Socket API for Address Selection July 2005
10. Validation function for source address
Sometimes an application may have a requirement to only use address
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's requirements are
met, but instead the application has to explicitly verify that the
chosen address satisfies its requirements. Such an application would
go through the following steps:
1. The application specifies one or more AI_PREFER_* flags with
getaddrinfo().
2. The application specifies the corresponding IPV6_PREFER_* flags
with setsockopt()
3. The application calls connect(). This applies even for datagram
(UDP) sockets, as the connect call results in the stack selecting
a source address, for TCP as well as UDP.
4. Retrieve the selected source address using the getsockname() API
call.
5. Verifying that the retrieved address is satisfactory as specified
below. If not, abort the communication e.g., by closing the
socket.
If the application has hard requirements on the scope of the source
address, then it can perform the verification using the APIs
specified in [3] such as IN6_IS_ADDR_LINKLOCAL.
The verification of temporary vs. public, home vs. care-of, CGA vs.
not, are performed by a new function defined for this purpose:
#include <netinet/in.h>
boolean_t inet6_is_srcaddr(struct sockaddr_in6 *srcaddr,
uint32_t flags);
Where the flags contain the specified source preference flags. The
function expects a non-NULL input for srcaddr. sockaddr_in6 structure
must contain AF_INET6 as sin6_family. It also must contain the
scope_id information if the source address is a link-local address.
The function returns true when srcaddr corresponds to a valid address
in the node and that address type satisfies the preference flag(s).
If srcaddr input value does not correspond to any address in the node
Nordmark, et al. Expires January 13, 2006 [Page 20]
Internet-Draft IPv6 Socket API for Address Selection July 2005
or it does not match an address which satisfy the preferences
indicated, the function returns false.
This function can handle multiple valid flags combination 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. Invalid flag values result in 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
which is at home (i.e., does not have any care-of-address).
Nordmark, et al. Expires January 13, 2006 [Page 21]
Internet-Draft IPv6 Socket API for Address Selection July 2005
11. Security Considerations
This document conforms to the same security implications as specified
in IPv6 Basic Socket API [3] 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 January 13, 2006 [Page 22]
Internet-Draft IPv6 Socket API for Address Selection July 2005
12. Changes from previous version of draft
o Changed IPV6_SRC_PREFERENCES option to IPV6_ADDR_PREFERENCES to
include destination address preference for scope and for further
future enhancement which may include both source and destination
addresses.
o Added implementation and application requirements.
o Removed IPV6_PREFER_SRC_NATIVE and IPV6_PREFER_SRC_TUNNEL flags as
there is no corresponding source address rule in RFC3484.
Moreover it doesn't seem to make sense to add preference flags for
this destination addresses since:
* The local system doesn't in general know whether there is a
tunnel at the destination end and
* In the case (6to4) where the local system can tell there will
be a tunnel for a destination address the default policy table
already has a rule (for the 6to4 prefix).
Perhaps there should have been a source rule for tunnel vs. native
interface in default address selection specification in which case
it might have made sense to add a preference flag for that.
o Added section on default address selection rule mapping.
o Added comments on using JAVA API.
o Added four new flags for destination scoped addresses as some
working group members felt the requirement of altering default
destination address scope.
o Clarified when getsockopt needs to be used. Removed text that
said a setsockopt with flags=0 would restore the preferences to
the system defaults.
o Added text showing the different ways the validation can be
performed. The validation of scope is quite different than the
validation function for other address selection preferences.
Nordmark, et al. Expires January 13, 2006 [Page 23]
Internet-Draft IPv6 Socket API for Address Selection July 2005
13. Acknowledgments
The authors like to thank members of mobile-ip and ipv6 working
groups for useful discussion on this topic. Richard Draves and Dave
Thaler suggested that getaddrinfo also needs to be considered along
with the new socket option. Gabriel Montenegro suggested that CGAs
may also be considered in this document. Thanks to Alain Durand,
Renee Danson, Alper Yegin, Francis Dupont, Michael Hunter, Sebastien
Roy, Robert Elz, Jinmei Tatuya, Pekka Savola, Itojun, Jim Bound, Jeff
Boote and Mika Liljeberg for useful discussions and suggestions.
Nordmark, et al. Expires January 13, 2006 [Page 24]
Internet-Draft IPv6 Socket API for Address Selection July 2005
14. References
14.1 Normative References
[1] Draves, R., "Default Address Selection for IPv6", RFC 3484,
August 2002.
[2] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
Addressing Architecture", RFC 3513, April 2003.
[3] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493,
March 2003.
14.2 Informative References
[4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[5] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6), Specification", RFC 2460, December 1998.
[6] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, "Advanced
Sockets API for IPv6", RFC 3542, May 2003.
[7] Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[8] Aura, T., "Cryptographically Generated Addresses (CGA)",
draft-ietf-send-cga-01.txt (work in progress), August 2003.
[9] Montenegro, G. and C. Castelluccia, "Statistically Unique and
Cryptographically Verifiable (SUCV) Identifiers and
Addresses.", NDSS 2002, February 2002.
[10] Chakrabarti, S. and E. Nordmark, "Extension to Sockets API for
Mobile IPv6", draft-ietf-mip6-mipext-advapi-03.txt (work in
progress), September 2004.
Nordmark, et al. Expires January 13, 2006 [Page 25]
Internet-Draft IPv6 Socket API for Address Selection July 2005
Authors' Addresses
Erik Nordmark
Sun Microsystems, Inc.
4150 Network Circle, UMPK17-308
Santa Clara, CA 95054
USA
Email: Erik.Nordmark@Sun.COM
Samita Chakrabarti
Sun Microsystems, Inc.
4150 Network Circle, UMPK16-157
Santa Clara, CA 95054
USA
Email: Samita.Chakrabarti@Sun.COM
Julien Laganier
DoCoMo Communications Laboratories Europe GmbH
Landsberger Strasse 312
Munich 80687
Germany
Phone: +49 89 56824 231
Email: julien.ietf@laposte.net
URI: http://www.docomolab-euro.com/
Nordmark, et al. Expires January 13, 2006 [Page 26]
Internet-Draft IPv6 Socket API for Address Selection July 2005
Appendix A. Intellectual Property Statement
This document only defines a source preference flag to choose
Cryptographically Generated Address (CGA) as source address when
applicable. CGA are obtained using public keys and hashes to prove
address ownership. Several IPR claims have been made about such
methods.
Nordmark, et al. Expires January 13, 2006 [Page 27]
Internet-Draft IPv6 Socket API for Address Selection July 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Nordmark, et al. Expires January 13, 2006 [Page 28]
