Network Working Group P. Sarolahti
Internet-Draft HIIT/ICSI
Intended status: Experimental March 4, 2010
Expires: September 5, 2010
Multi-address Interface in the Socket API
draft-sarolahti-mptcp-af-multipath-01.txt
Abstract
This document specifies a new address family to be used for sockets
that are bound to more than one IP address, as motivated by the
Multipath TCP work in the IETF. The goal is to use the same set of
function calls as traditionally, but by new address family make it
possible for them to express multiple addresses to connect or bind
to. The document gives a high-level definition of the behavior of
the traditional function calls, but a detailed specification of the
API syntax is not in the scope of this document.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 September 5, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
Sarolahti Expires September 5, 2010 [Page 1]
Internet-Draft AF-Multipath March 2010
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The Multipath Address Family . . . . . . . . . . . . . . . . . 4
4. Behaviour with Different Networking Functions . . . . . . . . 6
4.1. Bind . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Connect . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Name resolution . . . . . . . . . . . . . . . . . . . . . 7
4.4. Get Local Address / Get Remote Address . . . . . . . . . . 8
5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Address Family or Protocol Family? . . . . . . . . . . . . 8
5.2. Comparison to Alternative Design Options . . . . . . . . . 9
5.3. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
Sarolahti Expires September 5, 2010 [Page 2]
Internet-Draft AF-Multipath March 2010
1. Introduction
The socket API is designed as a generic protocol-independent
interface that includes a compact set of operations for network
applications to communicate to the network. Despite the small number
of basic operations, the socket API has proved to be enough powerful
to carry out various different kinds of tasks, arguably because of
the generic enough interface definitions. In addition to Internet
communication, the socket API is also used, for example, in the Unix
domain sockets that operate on Unix filenames as communication
identifiers, and various control tasks between the applications and
the communication stack, for example in IPsec key management sockets
[RFC2367], or so called netlink or routing sockets that interact with
the routing table in the network stack. The exact semantics of the
socket API methods are not defined by the API itself, but depend on
the parameters given when a new socket is created.
The socket API is designed to expose the addresses used for the
communication to the applications. Consistent with the generic
design of the API, the addresses are passed in a generic type-length
encoded structure, that is interpreted based on the address family
given in the beginning of the structure. In practice, primarily two
address families are currently used for Internet communication: IPv4
(also known as AF_INET) or IPv6 (AF_INET6). Perhaps confusingly,
traditionally the same constants used to indicate the address family
are often also used to indicate the protocol family for creating
socket. This dependency is discussed in more detail in Section 5.1.
This document proposes a new way to use the socket API to better
support protocols that use multiple IP addresses at either end of a
connection. The primary motivation for this specification is the
ongoing work on Multipath TCP (e.g., [I-D.ietf-mptcp-architecture],
[I-D.ford-mptcp-multiaddressed]), but the same API can be used with
any other protocol that runs multiple addresses on a single socket.
One of the design goals in this specification is to enable support
for multiple addresses in a socket without changing the binary
function call API at the operation system interface, or the set of
networking function calls available in the system. This design also
aims to maintain unchanged semantics with the previously familiar
operations to the extent it is possible, while avoiding backwards
compatibility issues by explicitly using a new address family.
Using Multipath TCP with a traditional single-homed socket API can be
problematic, as discussed in the API considerations document
[I-D.scharf-mptcp-api]. The socket API was designed with an
assumption that a socket is using just one address, with this address
being explicitly visible to the applications. When the API is used
with a protocol that uses multiple addresses for communication,
Sarolahti Expires September 5, 2010 [Page 3]
Internet-Draft AF-Multipath March 2010
defining the semantics of existing function calls that directly refer
to one IP address becomes problematic, possibly making the existing
applications behave defectively when using the legacy socket API with
Multipath TCP. While the motivation of Multipath TCP to operate on
unmodified legacy APIs is well understandable, eventually a more
expressive API is needed to better manage connections using multiple
addresses at either end.
This document specifies a new multipath-compatible address family to
be used with the familiar socket operations, called AF_MULTIPATH.
This address family is composed as a sequence of one or multiple
elements that are each structured in the same way as one of the
existing address families supported by the system, such as AF_INET or
AF_INET6. At the same time, this lets the application indicate if it
supports the use of multiple addresses for the socket, for example
using multipath TCP. One advantage of the Multipath Address Family
is that it supports using different address families, such as IPv4 or
IPv6, in the same address set, thereby enabling dual-stack
functionality between both IPv4 and IPv6 interfaces (although we note
that IPv4 addresses can be expressed as a AF_INET6 structure).
The AF_MULTIPATH address family could be used also with other
protocols capable of multihoming, for example SCTP [RFC4960]. It may
possibly be applicable also to shim-layer approaches to multihoming
such as SHIM6 [RFC5533] or HIP [RFC5206], although these are based on
a different philosophy of splitting locators (IP addresses) from the
host identity. Different API extensions for multihomed protocols
have been specified (or are being worked on), for example one using a
set of socket options [I-D.ietf-shim6-multihome-shim-api], and
another extending the set of socket operations in the socket API
[I-D.ietf-tsvwg-sctpsocket]. This document deliberately proposes a
new approach as an alternative to these, and discusses the benefits
and disadvantages of different approaches in Section 5.2
2. Terminology
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].
3. The Multipath Address Family
Multipath address family (AF_MULTIPATH) is composed of a sequence of
addresses, each expressed using one of the existing address family
formats supported in the system. A desirable behavior would be that
in a system that supports the multipath address family, opening a
Sarolahti Expires September 5, 2010 [Page 4]
Internet-Draft AF-Multipath March 2010
socket using one of the traditional single-address families should be
taken as an indication that multiple addresses should not be used for
that socket. However, to allow migration period for legacy
applications that are not converted to use the new address family,
but would benefit from multipath communication, an additional option
switch may be needed to control the behavior on traditional single-
address families.
The address family is structured according to the generic sockaddress
structure as follows. The fields are given in network byte order.
o Length (8 bits)
o Address family (=AF_MULTIPATH) (8 bits)
o Number of addresses (8 bits)
o Address 1
o Address 2
o ....
o Address N
Each of the address records above takes the generic sockaddress
format, i.e.:
o Length (8 bits)
o Address family (8 bits)
o Address (...i.e., the rest of sockaddr structure as defined by the
address family...)
In a dynamic multipath connection the set of address fields can
change over time: new addresses may be added and earlier addresses
can be removed. This characteristic, that the socket address content
can change during a connection, differs from traditional behavior.
However, this just reflects the changed behavior of multipath TCP
compared to traditional TCP, which uses the same pair of addresses
through the connection life cycle.
In today's systems the address family is commonly either AF_INET or
AF_INET6, although also other address families can exist. Depending
on the address family, the address would typically be structured as
sockaddr_in or sockaddr_in6 structure, with the length set
appropriately. Different address families can be combined in a
Sarolahti Expires September 5, 2010 [Page 5]
Internet-Draft AF-Multipath March 2010
single AF_MULTIPATH record.
4. Behaviour with Different Networking Functions
This section defines the intended behavior of commonly used network
operations when used with AF_MULTIPATH address family. The section
gives a high-level definition of the operations to be applied as
appropriate in different application environments.
4.1. Bind
An AF_MULTIPATH socket can bind to several addresses using a single
call. It is possible to use wildcard ("Any") address in some of
entries of the address set. Technically, multiple "Any" addresses
could allow binding several ports to the same socket, although it is
unclear if there is any viable reason for doing so. AF_MULTIPATH can
also contain just one address entry, in which case the behavior is
similar to traditional single-homed bind. On return, the function
call should indicate how many addresses were successfully bound, and
use failure response to indicate that binding failed to all
addresses. "Get Local Address" operation (getsockname in Posix) can
be used to investigate which addresses were successfully bound.
Differing from its past use, bind can be called multiple times for
the same socket, to allow the application dynamically change the set
of local addresses. When a subsequent bind call does not include an
address that is currently in use, it indicates to the protocol that
this address should not be used anymore in a connection. When a
subsequent bind call includes addresses that are not currently in
use, it indicates that these addresses should be added to the
connection. The protocol implementation may change the set of used
addresses dynamically without a trigger from application. Before the
bind call the set of currently used addresses can be obtained using
the "Get Local Address" (getsockname) call as described in
Section 4.4.
4.2. Connect
An AF_MULTIPATH socket can give multiple addresses to connect,
assuming the addresses belong to the same host. The underlying
protocol may need to activate these connections one at a time, if the
protocol logic does not permit connecting to multiple addresses
simultaneously. On return, the function call should indicate how
many of the addresses were successfully connected, or an error code.
It is expected that commonly this call is used together with name
resolution, as described below. "Get Remote Address" (getpeername)
operation can be used to investigate which addresses were
Sarolahti Expires September 5, 2010 [Page 6]
Internet-Draft AF-Multipath March 2010
successfully connected to.
Similarly to bind operation, connect can be called multiple times for
the same socket, to allow the application dynamically change the set
of remote addresses. When a subsequent connect call does not include
an address that is currently in use, it indicates to the protocol
that this address should not be used anymore in a connection. When a
subsequent bind call includes addresses that are not currently in
use, it indicates that these addresses should be added to the
connection (in practice triggering this from application can be
unusual for remote addresses). The protocol implementation may
change the set of used addresses dynamically without a trigger from
application. Before the connect call the set of currently used
addresses can be obtained using the "Get Remote Address"
(getpeername) call as described in Section 4.4.
An application may give multiple addresses that seem reachable, but
belong to different hosts. The underlying protocol that supports
AF_MULTIPATH API MUST be able to detect such situation, and prevent
connections to multiple hosts. Often there are sufficient protocol
mechanisms (such as connection tokens in multipath TCP) and other
protocol state that cause such connections to fail automatically.
4.3. Name resolution
In a typical usage of a name resolver, multiple addresses may be
returned from a name server, and a client cycles through the given
addresses until connection is successfully established. This is
useful, for example, in dual-stack IPv4/IPv6 hosts. A client may
need to try connecting separately to IPv6 addresses and IPv4
addresses, when it is not certain whether IPv6 is supported on the
path.
When an AF_MULTIPATH-enabled name resolver is called, it returns the
available address records as separate entries in a single
AF_MULTIPATH structure. This would mean that the call returns a
single AF_MULTIPATH host entry that may contain multiple addresses as
specified in the AF_MULTIPATH format. An application may directly
place the returned AF_MULTIPATH structure as a parameter of a connect
call, indicating that a multipath protocol should try these addresses
as subflows of the multipath connection. When a name resolver
receives an AF_MULTIPATH-enabled call in a host that supports both
IPv6 and IPv4, it is useful to invoke name server queries for both
IPv6 and IPv4 addresses. If available, records of both types are
returned to the application, that can pass them to connect call, in
attempt to invoke a multipath connection over both IPv4 and IPv6
paths. This may be useful feature supporting transition from IPv4 to
IPv6.
Sarolahti Expires September 5, 2010 [Page 7]
Internet-Draft AF-Multipath March 2010
It is not uncommon that a DNS name is associated to multiple hosts,
for example to perform DNS-based load balancing. As discussed above
with the connect call, the underlying protocol implementation should
be able to prevent connect attempts to separate hosts.
4.4. Get Local Address / Get Remote Address
The basic operation of these calls happens as before: they return a
sockaddress structure either at the local or the remote end.
AF_MULTIPATH address family is returned if it has been used earlier
with the same socket. The set of local or remote addresses SHOULD be
up-to-date with the currently active set in the protocol
implementation. When the underlying protocol is able to change the
active address set during the connection, this implies that
subsequent calls to these functions can return different sets of
addresses. Along with the current addresses, an application learns
also about the connection identifier with this call. The connection
identifier returned with "Get Remote Address" MUST be the same as the
identifier returned with "Get Local Address", since it only has local
meaning, and therefore the other end of the connection typically gets
entirely different connection identifier for the connection.
5. Discussion
5.1. Address Family or Protocol Family?
The socket API defines separately the protocol family, that is used
to define the semantics of the socket behavior when a socket is
created, and the address family that is used to distinguish different
socket address formats [RFC2553]. By convention, in many systems
AF_INET is defined to have an equal value to PF_INET, and AF_INET6 is
defined to have an equal value to PF_INET6, allowing the pairs of
definitions to be used interchangeably in implementations.
Defining separate protocol families for IPv6 and IPv4 has some
unfortunate consequences: in principle, it needs to be decided at
socket creation time whether to use IPv6 or IPv4. In practice, IPv6
defines a specific address range, IPv4-mapped addresses, to
"virtually" represent IPv4 addresses in IPv6 address space.
Implementations can use this feature to signal, that IPv4 should be
used on the wire. An alternative design choice could have been to
use same protocol family for both IPv4 and IPv6, and distinguish use
of IPv4 and IPv6 with the address family, that can be selected also
after the socket is created. After all, the transport protocol
implementation, and its semantics, are the same in both cases.
In case of AF_MULTIPATH, the format of the socket address structure
Sarolahti Expires September 5, 2010 [Page 8]
Internet-Draft AF-Multipath March 2010
changes, while for example in the case of multipath TCP, the
semantics of the socket calls are intended to remain unchanged. This
would suggest that when AF_MULTIPATH address family is used with
socket address structures, the protocol family definition should
remain at its typical value. Here an argument can be made that
AF_MULTIPATH changes the behavior of bind and connect calls, but on
the other hand, it is correct to say that from the applications point
of view the outcome of a successful completion -- choosing a local
access point, or successfully establishing connection with the peer
-- is exactly the same as with the traditional use of the API. It is
unclear at this point, whether the pairwise definitions of protocol
family and address family has lead to dependencies in implementations
that would hinder the implementation of the AF_MULTIPATH address
family, or whether such dependencies would be difficult to be fixed.
5.2. Comparison to Alternative Design Options
Replacing the current socket API with a "connect-by-name" API has
been proposed. Different proposals have slightly different
abstraction levels, but commonly in these APIs application passes a
DNS name with the connect call. The benefit of such API is that the
application does not need to handle the network addresses, that
arguably shouldn't be application's concern in most cases, and it
thus avoids a separate name resolution step. In a long term this
seems a promising direction to take in API design, but involves
inter-operation between the name resolver that is often implemented
in user space in current systems, and may need changes in operating
system kernel interface. This proposal intentionally has taken the
traditional, more short term approach, to expose the network
addresses to applications.
Additions to the set of calls in the socket API has been proposed,
for example, alternative operations for multi-address bind and
connect [I-D.ietf-tsvwg-sctpsocket]. In the beginning this document
lauded the elegance of simple, generic socket API with a small basic
set of operations, and addition of new purpose-specific operations
would be a deviation from this design principle. In addition adding
operations to socket API would cause changes to the operating system
kernel function interface, that could cause interoperability and
maintenance issues. One way to implement such extended operations
would be through an user-space library that maps the operations to
the existing socket calls in the kernel implementation. In mapping
the additional operations to existing kernel interface, such library
might leverage a mechanism similar to what presented in this
document, or use, for example socket options or ioctl calls.
Socket options can be used tune parameters affecting the protocol
behavior. The extensibility of the socket option format can make it
Sarolahti Expires September 5, 2010 [Page 9]
Internet-Draft AF-Multipath March 2010
appealing to use this interface for more significant run-time tasks,
such as adding or deleting addresses in a multi-address session, as
done in [I-D.ietf-shim6-multihome-shim-api]. In this approach the
semantics of the traditional single-homed operations still need to be
specified. It can also be questioned whether it is appropriate to
use socket options to trigger actions that can be seen to fall beyond
the scope of the original meaning of "socket option".
In summary, introducing a new address family as proposed in this
document allows keeping the existing set of socket operations in the
API, which the author believes to be a useful property, for example
concerning the maintenance of the interfaces between the operation
system and applications. If an operating system does not support
AF_MULTIPATH, it can gracefully return an appropriate error code to
an application, that can then revert to use the traditional single-
homed address family, if desired. There are no backwards
compatibility issues with old applications, because applications
explicitly signal their support of this address family with the
connect or bind calls.
Presenting the multiple addresses associated with the connection
using the socket addresses seems a natural and native way of
expressing this fairly new kind of property to applications. The
recent discussion on this idea showed, however, that the use of more
dynamic socket addresses can be perceived as unconventional and can
raise doubts, for example regarding the possible assumptions about
the persistence of the address structure in the implementations. It
is unclear how actual this concern is, given that the underlying
protocol that dynamically maintains the set of addresses is a fairly
new feature, compared to decades of past use of the end-to-end
transport.
5.3. Open Issues
Below are listed some potentially open issues that need to be taken
in to account in follow-up discussion on this document.
o Are there any constraints on the generic format of the socket
address structure, that would conflict with what proposed above?
It appears that for example BSD and Linux use different formats
for this structure, so that the Linux structure follows the "old
BSD" convention, without a common length field (sa_len). Are
there reasons to follow one of these conventions, or would it be
possible, for example, to specify a 16-bit length field that could
be useful for large sets of IPv6 addresses?
o Is there a need to expose pairwise source-destination subflow
associations, instead of just a group of source and destination
Sarolahti Expires September 5, 2010 [Page 10]
Internet-Draft AF-Multipath March 2010
addresses? Currently no such reason can be seen: the socket
should represent one logical connection between a source host and
a destination host, that in this case may have multiple IP
addresses in use for the connection.
o Is a separate connection identifier field needed, as in the
earlier version of this document? Currently the author cannot
identify such need.
6. Security Considerations
No additional security threats are known because of the multipath
address family. This document referred to the possibility that
dynamic end host multihoming may enable new ways to maliciously
transfer a connection to another host. A multi-address interface may
open this possibility to applications, but ultimately the multihomed
protocol should have mechanisms to protect from such behavior.
7. Acknowledgments
The author is thankful to Alan Ford for pointing out specific
technical issues to be addressed, and to the people who have
participated the discussion on the MPTCP mailing list.
The author is supported by Finland-ICSI Center for Novel Internet
Architectures (FICNIA) and the Finnish Funding Agency for Technology
and Innovation (TEKES).
8. References
8.1. Normative References
[I-D.ietf-mptcp-architecture]
Ford, A., Raiciu, C., Barre, S., and J. Iyengar,
"Architectural Guidelines for Multipath TCP Development",
draft-ietf-mptcp-architecture-00 (work in progress),
March 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[I-D.ford-mptcp-multiaddressed]
Ford, A., Raiciu, C., and M. Handley, "TCP Extensions for
Sarolahti Expires September 5, 2010 [Page 11]
Internet-Draft AF-Multipath March 2010
Multipath Operation with Multiple Addresses",
draft-ford-mptcp-multiaddressed-02 (work in progress),
October 2009.
[I-D.ietf-shim6-multihome-shim-api]
Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto,
"Socket Application Program Interface (API) for
Multihoming Shim", draft-ietf-shim6-multihome-shim-api-13
(work in progress), February 2010.
[I-D.ietf-tsvwg-sctpsocket]
Stewart, R., Poon, K., Tuexen, M., Yasevich, V., and P.
Lei, "Sockets API Extensions for Stream Control
Transmission Protocol (SCTP)",
draft-ietf-tsvwg-sctpsocket-21 (work in progress),
February 2010.
[I-D.scharf-mptcp-api]
Scharf, M. and A. Ford, "MPTCP Application Interface
Considerations", draft-scharf-mptcp-api-00 (work in
progress), October 2009.
[RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key
Management API, Version 2", RFC 2367, July 1998.
[RFC2553] Gilligan, R., Thomson, S., Bound, J., and W. Stevens,
"Basic Socket Interface Extensions for IPv6", RFC 2553,
March 1999.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007.
[RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End-
Host Mobility and Multihoming with the Host Identity
Protocol", RFC 5206, April 2008.
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", RFC 5533, June 2009.
Appendix A. Change log
Changes from version -00 to -01
o Added more background to the Introduction
o Added section to discuss protocol family/address family issues,
and comparison to related API designs
Sarolahti Expires September 5, 2010 [Page 12]
Internet-Draft AF-Multipath March 2010
o Removed the connection identifier from the address structure, and
changed related descriptions related to socket calls.
o Added discussion about open issues in Section 3
Author's Address
Pasi Sarolahti
HIIT/ICSI
1947 Center Street (Suite 600)
Berkeley, CA 94704
USA
Phone: +1 (510) 409 - 9972
Email: pasi.sarolahti@iki.fi
URI: http://www.iki.fi/pasi.sarolahti/
Sarolahti Expires September 5, 2010 [Page 13]