idnits 2.17.1 draft-sarolahti-mptcp-af-multipath-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 20, 2009) is 5264 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-01) exists of draft-ford-mptcp-architecture-00 == Outdated reference: A later version (-03) exists of draft-ford-mptcp-multiaddressed-02 == Outdated reference: A later version (-17) exists of draft-ietf-shim6-multihome-shim-api-10 == Outdated reference: A later version (-32) exists of draft-ietf-tsvwg-sctpsocket-19 == Outdated reference: A later version (-04) exists of draft-scharf-mptcp-api-00 -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5206 (Obsoleted by RFC 8046) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Sarolahti 3 Internet-Draft HIIT/ICSI 4 Intended status: Experimental November 20, 2009 5 Expires: May 24, 2010 7 Multipath Interface in the Socket API 8 draft-sarolahti-mptcp-af-multipath-00.txt 10 Abstract 12 This document specifies a new address family to be used for sockets 13 that are bound to more than one IP address, as motivated by the 14 Multipath TCP work in the IETF. The goal is to use the same set of 15 function calls as traditionally, but by new address family make it 16 possible for them to express multiple addresses to connect or bind 17 to. The document gives a high-level definition of the behavior of 18 the traditional function calls, but a detailed specification of the 19 API syntax is not in the scope of this document. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on May 24, 2010. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. The Multipath Address Family . . . . . . . . . . . . . . . . . 4 64 4. Behaviour with Different Networking Functions . . . . . . . . . 6 65 4.1. Bind . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 4.2. Connect . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 4.3. Name resolution . . . . . . . . . . . . . . . . . . . . . . 7 68 4.4. Get Local Address / Get Remote Address . . . . . . . . . . 7 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 70 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 6.1. Normative References . . . . . . . . . . . . . . . . . . . 8 72 6.2. Informative References . . . . . . . . . . . . . . . . . . 8 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 This document proposes a new way to use the socket API to better 78 support protocols that use multiple IP addresses at either end of a 79 connection. The primary motivation for this specification is the 80 ongoing work on Multipath TCP (e.g., [I-D.ford-mptcp-architecture], 81 [I-D.ford-mptcp-multiaddressed]), but the same API can be used with 82 any other protocol that runs multiple addresses on a single socket. 83 One of the design goals in this specification is to enable support 84 for multiple addresses in a socket without changing the set of 85 networking function calls available in the system. This design also 86 aims to maintain unchanged semantics with the previously familiar 87 operations to the extent it is possible. 89 Using Multipath TCP with a traditional socket API with IPv4 address 90 family (also known as AF_INET) or IPv6 (AF_INET6) address family can 91 be problematic, as discussed in the API considerations document 92 [I-D.scharf-mptcp-api]. The socket API was designed with an 93 assumption that a socket is using just one address, with this address 94 being explicitly visible to the applications. When the API is used 95 with a protocol that uses multiple addresses for communication, 96 defining the semantics of existing function calls that directly refer 97 to one IP address becomes problematic, potentially making the 98 existing applications behave defectively when using the legacy socket 99 API with Multipath TCP. While the motivation of Multipath TCP to 100 operate on unmodified legacy APIs is well understandable, eventually 101 a more expressive API is needed to better manage connections using 102 multiple addresses at either end. 104 This document specifies a new multipath-compatible address family to 105 be used with the familiar socket operations, called AF_MULTIPATH. 106 This address family is composed as a sequence of one or multiple 107 elements that are each structured in the same way as one of the 108 existing address families supported by the system, such as AF_INET or 109 AF_INET6. At the same time, this lets the application indicate if it 110 supports the use of multiple addresses for the socket, for example 111 using multipath TCP. One advantage of the Multipath Address Family 112 is that it supports using different address families, such as IPv4 or 113 IPv6, in the same address set, thereby enabling dual-stack 114 functionality between both IPv4 and IPv6 interfaces (although we note 115 that IPv4 addresses can be expressed as a AF_INET6 structure). 117 The AF_MULTIPATH address family could be used also with other 118 protocols capable of multihoming, for example SCTP [RFC4960]. It may 119 possibly be applicable also to shim-layer approaches to multihoming 120 such as SHIM6 [RFC5533] or HIP [RFC5206], although these are based on 121 a different philosophy of splitting locators (IP addresses) from the 122 host identity. Different API extensions for multihomed protocols 123 have been specified (or are being worked on), for example one using a 124 set of socket options [I-D.ietf-shim6-multihome-shim-api], and 125 another extending the set of socket operations in the socket API 126 [I-D.ietf-tsvwg-sctpsocket]. This document deliberately avoids both 127 approaches, choosing a method that does not require adding several 128 new socket options or socket operations. The goal has been to 129 develop a mechanism that fits with the existing operations in the 130 socket API. 132 2. Terminology 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC2119]. 138 3. The Multipath Address Family 140 Multipath address family (AF_MULTIPATH) is composed of a sequence of 141 addresses, each expressed using one of the existing address family 142 formats supported in the system. A desirable behavior would be that 143 in a system that supports the multipath address family, opening a 144 socket using one of the traditional single-address families should be 145 taken as an indication that multiple addresses should not be used for 146 that socket. However, to allow migration period for legacy 147 applications that are not converted to use the new address family, 148 but would benefit from multipath communication, an additional option 149 switch may be needed to control the behavior on traditional single- 150 address families. 152 The address family is structured according to the generic sockaddress 153 structure as follows. The fields are given in network byte order. 155 o Length (8 bits) 157 o Address family (=AF_MULTIPATH) (8 bits) 159 o Connection identifier (32 bits) (TODO: discuss if this is needed, 160 or is the socket descriptor sufficient) 162 o Number of addresses (8 bits) 164 o Address 1 166 o Address 2 167 o .... 169 o Address N 171 Each of the address records above takes the generic sockaddress 172 format, i.e.: 174 o Length (8 bits) 176 o Address family (8 bits) 178 o Address (...i.e., the rest of sockaddr structure as defined by the 179 address family...) 181 When the API is used with Multipath TCP, the Connection identifier 182 can be equal to the sender token used by Multipath TCP 183 [I-D.ford-mptcp-multiaddressed]. Connection identifier is only used 184 locally, and it is not intended that this identifier is communicated 185 over the network. Connection identifier MUST be unique among all 186 active connections in the host, and connection identifier MUST NOT be 187 changed during the lifetime of the Multipath TCP connection. The 188 same connection identifier SHOULD NOT be reused immediately after a 189 socket is closed. Similar semantics are applied also to other 190 multipath protocols, if AF_MULTIPATH is used with them. 192 While the connection identifier is stable throughout the connection 193 lifetime, in a dynamic multipath connection the other fields can 194 change over time: new addresses may be added and earlier addresses 195 can be removed. 197 In today's system with Posix API the address family is commonly 198 either AF_INET or AF_INET6, but the design is not limited to these 199 address families. Depending on the address family, the address would 200 typically in a Posix system be structured as sockaddr_in or 201 sockaddr_in6 structure, with the length set appropriately. Different 202 address families can be combined in a single AF_MULTIPATH record. 204 There is a tradition that the IPv4/IPv6 address family is also used 205 to indicate the protocol family in the socket call, originally 206 intended to separate UNIX internal protocols from Internet protocols 207 or ISO protocols. It is unclear (to the author) why the evolution 208 has lead to use two separate values to indicate IPv4 and IPv6 209 protocols in the protocol family parameter of the socket call. It 210 would seem appropriate that as dual-stack IPv4/IPv6 implementations 211 are commonplace, a single protocol family would be used for opening a 212 socket for any Internet protocol. 214 4. Behaviour with Different Networking Functions 216 This section defines the intended behavior of commonly used network 217 operations when used with AF_MULTIPATH address family. The section 218 gives a high-level definition of the operations to be applied as 219 appropriate in different application environments. 221 4.1. Bind 223 An AF_MULTIPATH socket can bind to several addresses using a single 224 call. It is possible to use wildcard ("Any") address in some of 225 entries of the address set. Multiple "Any" addresses could allow 226 binding several ports to the same socket, although this does not seem 227 a sensible action to take. AF_MULTIPATH can also contain just one 228 address entry, in which case the behavior is similar to traditional 229 single-homed bind. On return, the function call should indicate how 230 many addresses were successfully bound, using error codes to indicate 231 that binding failed to all addresses. "Get Local Address" operation 232 (getsockname in Posix) can be used to investigate which addresses 233 were successfully bound. 235 When binding a new socket with no prior AF_MULTIPATH entry, 236 connection identifier MUST be set to 0. This call can also be used 237 by an application to indicate that new local addresses should be 238 added to the connection. In this case connection identifier refers 239 to an existing connection. If connection identifier is non-zero and 240 such connection does not exist in the system, the call returns with 241 failure. 243 4.2. Connect 245 An AF_MULTIPATH socket can give multiple addresses to connect to, 246 assuming the addresses belong to the same host. The protocol may 247 need to activate these connections one at a time, if the protocol 248 logic does not permit connecting to multiple addresses 249 simultaneously. On return, the function call should indicate how 250 many of the addresses were successfully connected, or an error code. 251 It is expected that commonly this call is used together with name 252 resolution, as described below. "Get Remote Address" (getpeername) 253 operation can be used to investigate which addresses were 254 successfully connected to. 256 When connecting a new, earlier unconnected socket, connection 257 identifier MUST be set to 0. Application can also indicate by this 258 call, that the protocol stack should try to add new remote addresses 259 to the connection. In this case connection identifier refers to an 260 existing connection. If connection identifier is non-zero and such 261 connection does not exist in the system, the call returns with 262 failure. 264 A consideration: one failure mode is that new address is reachable, 265 but points to a different host. MPTCP MUST be able to detect this 266 before any data gets exchanged. This might be something for the main 267 MPTCP specification to think about, because this seems like a generic 268 MPTCP security issue on connection hijacking. 270 4.3. Name resolution 272 In a typical usage of a name resolver, multiple addresses may be 273 returned from a name server, and a client cycles through the given 274 addresses until connection is successfully established. Sometimes a 275 client may need to try separately IPv6 addresses and IPv4 addresses, 276 when it is not certain whether IPv6 is supported on the path. 278 When name resolver is called with AF_MULTIPATH enabled, the name 279 server returns the available address records as separate entries in a 280 single AF_MULTIPATH structure. This would mean that the call returns 281 a single AF_MULTIPATH host entry that may contain multiple addresses 282 as specified in the AF_MULTIPATH format. An application may directly 283 place the returned AF_MULTIPATH structure as a parameter of a connect 284 call, indicating that a multipath protocol should try these addresses 285 as subflows of the multipath connection. It is recommended that when 286 resolver receives an AF_MULTIPATH-enabled call, it invokes name 287 server queries for both IPv6 and IPv4 addresses, if both are 288 supported in the system, and records of both types are returned to 289 the application, if available. 291 4.4. Get Local Address / Get Remote Address 293 These calls operate similarly than originally: they return a 294 sockaddress structure at local or remote end. AF_MULTIPATH address 295 family is returned if it has been used earlier with the same socket. 296 The set of local or remote addresses SHOULD be up-to-date with the 297 currently active set in the protocol implementation. Along with the 298 current addresses, an application learns also about the connection 299 identifier with this call. The connection identifier returned with 300 "Get Remote Address" MUST be the same as the identifier returned with 301 "Get Local Address", since it only has local meaning, and therefore 302 the other end of the connection typically gets entirely different 303 connection identifier for the connection. 305 5. Security Considerations 307 No additional security threats known because of the multipath address 308 family. 310 6. References 312 6.1. Normative References 314 [I-D.ford-mptcp-architecture] 315 Ford, A., Raiciu, C., Barre, S., Iyengar, J., and B. Ford, 316 "Architectural Guidelines for Multipath TCP Development", 317 draft-ford-mptcp-architecture-00 (work in progress), 318 October 2009. 320 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 321 Requirement Levels", BCP 14, RFC 2119, March 1997. 323 6.2. Informative References 325 [I-D.ford-mptcp-multiaddressed] 326 Ford, A., Raiciu, C., and M. Handley, "TCP Extensions for 327 Multipath Operation with Multiple Addresses", 328 draft-ford-mptcp-multiaddressed-02 (work in progress), 329 October 2009. 331 [I-D.ietf-shim6-multihome-shim-api] 332 Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto, 333 "Socket Application Program Interface (API) for 334 Multihoming Shim", draft-ietf-shim6-multihome-shim-api-10 335 (work in progress), October 2009. 337 [I-D.ietf-tsvwg-sctpsocket] 338 Stewart, R., Poon, K., Tuexen, M., Yasevich, V., and P. 339 Lei, "Sockets API Extensions for Stream Control 340 Transmission Protocol (SCTP)", 341 draft-ietf-tsvwg-sctpsocket-19 (work in progress), 342 February 2009. 344 [I-D.scharf-mptcp-api] 345 Scharf, M. and A. Ford, "MPTCP Application Interface 346 Considerations", draft-scharf-mptcp-api-00 (work in 347 progress), October 2009. 349 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 350 RFC 4960, September 2007. 352 [RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End- 353 Host Mobility and Multihoming with the Host Identity 354 Protocol", RFC 5206, April 2008. 356 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 357 Shim Protocol for IPv6", RFC 5533, June 2009. 359 Author's Address 361 Pasi Sarolahti 362 HIIT/ICSI 363 1947 Center Street (Suite 600) 364 Berkeley, CA 94704 365 USA 367 Phone: +1 (510) 409 - 9972 368 Email: pasi.sarolahti@iki.fi 369 URI: http://www.iki.fi/pasi.sarolahti/