idnits 2.17.1 draft-sarolahti-mptcp-af-multipath-01.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 (March 4, 2010) is 5167 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-ietf-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-13 == Outdated reference: A later version (-32) exists of draft-ietf-tsvwg-sctpsocket-21 == Outdated reference: A later version (-04) exists of draft-scharf-mptcp-api-00 -- Obsolete informational reference (is this intentional?): RFC 2553 (Obsoleted by RFC 3493) -- 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 (==), 4 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 March 4, 2010 5 Expires: September 5, 2010 7 Multi-address Interface in the Socket API 8 draft-sarolahti-mptcp-af-multipath-01.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 September 5, 2010. 44 Copyright Notice 46 Copyright (c) 2010 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 . . . . . . . . . . 8 69 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 5.1. Address Family or Protocol Family? . . . . . . . . . . . . 8 71 5.2. Comparison to Alternative Design Options . . . . . . . . . 9 72 5.3. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 10 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 74 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 77 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 78 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 12 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 1. Introduction 83 The socket API is designed as a generic protocol-independent 84 interface that includes a compact set of operations for network 85 applications to communicate to the network. Despite the small number 86 of basic operations, the socket API has proved to be enough powerful 87 to carry out various different kinds of tasks, arguably because of 88 the generic enough interface definitions. In addition to Internet 89 communication, the socket API is also used, for example, in the Unix 90 domain sockets that operate on Unix filenames as communication 91 identifiers, and various control tasks between the applications and 92 the communication stack, for example in IPsec key management sockets 93 [RFC2367], or so called netlink or routing sockets that interact with 94 the routing table in the network stack. The exact semantics of the 95 socket API methods are not defined by the API itself, but depend on 96 the parameters given when a new socket is created. 98 The socket API is designed to expose the addresses used for the 99 communication to the applications. Consistent with the generic 100 design of the API, the addresses are passed in a generic type-length 101 encoded structure, that is interpreted based on the address family 102 given in the beginning of the structure. In practice, primarily two 103 address families are currently used for Internet communication: IPv4 104 (also known as AF_INET) or IPv6 (AF_INET6). Perhaps confusingly, 105 traditionally the same constants used to indicate the address family 106 are often also used to indicate the protocol family for creating 107 socket. This dependency is discussed in more detail in Section 5.1. 109 This document proposes a new way to use the socket API to better 110 support protocols that use multiple IP addresses at either end of a 111 connection. The primary motivation for this specification is the 112 ongoing work on Multipath TCP (e.g., [I-D.ietf-mptcp-architecture], 113 [I-D.ford-mptcp-multiaddressed]), but the same API can be used with 114 any other protocol that runs multiple addresses on a single socket. 115 One of the design goals in this specification is to enable support 116 for multiple addresses in a socket without changing the binary 117 function call API at the operation system interface, or the set of 118 networking function calls available in the system. This design also 119 aims to maintain unchanged semantics with the previously familiar 120 operations to the extent it is possible, while avoiding backwards 121 compatibility issues by explicitly using a new address family. 123 Using Multipath TCP with a traditional single-homed socket API can be 124 problematic, as discussed in the API considerations document 125 [I-D.scharf-mptcp-api]. The socket API was designed with an 126 assumption that a socket is using just one address, with this address 127 being explicitly visible to the applications. When the API is used 128 with a protocol that uses multiple addresses for communication, 129 defining the semantics of existing function calls that directly refer 130 to one IP address becomes problematic, possibly making the existing 131 applications behave defectively when using the legacy socket API with 132 Multipath TCP. While the motivation of Multipath TCP to operate on 133 unmodified legacy APIs is well understandable, eventually a more 134 expressive API is needed to better manage connections using multiple 135 addresses at either end. 137 This document specifies a new multipath-compatible address family to 138 be used with the familiar socket operations, called AF_MULTIPATH. 139 This address family is composed as a sequence of one or multiple 140 elements that are each structured in the same way as one of the 141 existing address families supported by the system, such as AF_INET or 142 AF_INET6. At the same time, this lets the application indicate if it 143 supports the use of multiple addresses for the socket, for example 144 using multipath TCP. One advantage of the Multipath Address Family 145 is that it supports using different address families, such as IPv4 or 146 IPv6, in the same address set, thereby enabling dual-stack 147 functionality between both IPv4 and IPv6 interfaces (although we note 148 that IPv4 addresses can be expressed as a AF_INET6 structure). 150 The AF_MULTIPATH address family could be used also with other 151 protocols capable of multihoming, for example SCTP [RFC4960]. It may 152 possibly be applicable also to shim-layer approaches to multihoming 153 such as SHIM6 [RFC5533] or HIP [RFC5206], although these are based on 154 a different philosophy of splitting locators (IP addresses) from the 155 host identity. Different API extensions for multihomed protocols 156 have been specified (or are being worked on), for example one using a 157 set of socket options [I-D.ietf-shim6-multihome-shim-api], and 158 another extending the set of socket operations in the socket API 159 [I-D.ietf-tsvwg-sctpsocket]. This document deliberately proposes a 160 new approach as an alternative to these, and discusses the benefits 161 and disadvantages of different approaches in Section 5.2 163 2. Terminology 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 167 document are to be interpreted as described in [RFC2119]. 169 3. The Multipath Address Family 171 Multipath address family (AF_MULTIPATH) is composed of a sequence of 172 addresses, each expressed using one of the existing address family 173 formats supported in the system. A desirable behavior would be that 174 in a system that supports the multipath address family, opening a 175 socket using one of the traditional single-address families should be 176 taken as an indication that multiple addresses should not be used for 177 that socket. However, to allow migration period for legacy 178 applications that are not converted to use the new address family, 179 but would benefit from multipath communication, an additional option 180 switch may be needed to control the behavior on traditional single- 181 address families. 183 The address family is structured according to the generic sockaddress 184 structure as follows. The fields are given in network byte order. 186 o Length (8 bits) 188 o Address family (=AF_MULTIPATH) (8 bits) 190 o Number of addresses (8 bits) 192 o Address 1 194 o Address 2 196 o .... 198 o Address N 200 Each of the address records above takes the generic sockaddress 201 format, i.e.: 203 o Length (8 bits) 205 o Address family (8 bits) 207 o Address (...i.e., the rest of sockaddr structure as defined by the 208 address family...) 210 In a dynamic multipath connection the set of address fields can 211 change over time: new addresses may be added and earlier addresses 212 can be removed. This characteristic, that the socket address content 213 can change during a connection, differs from traditional behavior. 214 However, this just reflects the changed behavior of multipath TCP 215 compared to traditional TCP, which uses the same pair of addresses 216 through the connection life cycle. 218 In today's systems the address family is commonly either AF_INET or 219 AF_INET6, although also other address families can exist. Depending 220 on the address family, the address would typically be structured as 221 sockaddr_in or sockaddr_in6 structure, with the length set 222 appropriately. Different address families can be combined in a 223 single AF_MULTIPATH record. 225 4. Behaviour with Different Networking Functions 227 This section defines the intended behavior of commonly used network 228 operations when used with AF_MULTIPATH address family. The section 229 gives a high-level definition of the operations to be applied as 230 appropriate in different application environments. 232 4.1. Bind 234 An AF_MULTIPATH socket can bind to several addresses using a single 235 call. It is possible to use wildcard ("Any") address in some of 236 entries of the address set. Technically, multiple "Any" addresses 237 could allow binding several ports to the same socket, although it is 238 unclear if there is any viable reason for doing so. AF_MULTIPATH can 239 also contain just one address entry, in which case the behavior is 240 similar to traditional single-homed bind. On return, the function 241 call should indicate how many addresses were successfully bound, and 242 use failure response to indicate that binding failed to all 243 addresses. "Get Local Address" operation (getsockname in Posix) can 244 be used to investigate which addresses were successfully bound. 246 Differing from its past use, bind can be called multiple times for 247 the same socket, to allow the application dynamically change the set 248 of local addresses. When a subsequent bind call does not include an 249 address that is currently in use, it indicates to the protocol that 250 this address should not be used anymore in a connection. When a 251 subsequent bind call includes addresses that are not currently in 252 use, it indicates that these addresses should be added to the 253 connection. The protocol implementation may change the set of used 254 addresses dynamically without a trigger from application. Before the 255 bind call the set of currently used addresses can be obtained using 256 the "Get Local Address" (getsockname) call as described in 257 Section 4.4. 259 4.2. Connect 261 An AF_MULTIPATH socket can give multiple addresses to connect, 262 assuming the addresses belong to the same host. The underlying 263 protocol may need to activate these connections one at a time, if the 264 protocol logic does not permit connecting to multiple addresses 265 simultaneously. On return, the function call should indicate how 266 many of the addresses were successfully connected, or an error code. 267 It is expected that commonly this call is used together with name 268 resolution, as described below. "Get Remote Address" (getpeername) 269 operation can be used to investigate which addresses were 270 successfully connected to. 272 Similarly to bind operation, connect can be called multiple times for 273 the same socket, to allow the application dynamically change the set 274 of remote addresses. When a subsequent connect call does not include 275 an address that is currently in use, it indicates to the protocol 276 that this address should not be used anymore in a connection. When a 277 subsequent bind call includes addresses that are not currently in 278 use, it indicates that these addresses should be added to the 279 connection (in practice triggering this from application can be 280 unusual for remote addresses). The protocol implementation may 281 change the set of used addresses dynamically without a trigger from 282 application. Before the connect call the set of currently used 283 addresses can be obtained using the "Get Remote Address" 284 (getpeername) call as described in Section 4.4. 286 An application may give multiple addresses that seem reachable, but 287 belong to different hosts. The underlying protocol that supports 288 AF_MULTIPATH API MUST be able to detect such situation, and prevent 289 connections to multiple hosts. Often there are sufficient protocol 290 mechanisms (such as connection tokens in multipath TCP) and other 291 protocol state that cause such connections to fail automatically. 293 4.3. Name resolution 295 In a typical usage of a name resolver, multiple addresses may be 296 returned from a name server, and a client cycles through the given 297 addresses until connection is successfully established. This is 298 useful, for example, in dual-stack IPv4/IPv6 hosts. A client may 299 need to try connecting separately to IPv6 addresses and IPv4 300 addresses, when it is not certain whether IPv6 is supported on the 301 path. 303 When an AF_MULTIPATH-enabled name resolver is called, it returns the 304 available address records as separate entries in a single 305 AF_MULTIPATH structure. This would mean that the call returns a 306 single AF_MULTIPATH host entry that may contain multiple addresses as 307 specified in the AF_MULTIPATH format. An application may directly 308 place the returned AF_MULTIPATH structure as a parameter of a connect 309 call, indicating that a multipath protocol should try these addresses 310 as subflows of the multipath connection. When a name resolver 311 receives an AF_MULTIPATH-enabled call in a host that supports both 312 IPv6 and IPv4, it is useful to invoke name server queries for both 313 IPv6 and IPv4 addresses. If available, records of both types are 314 returned to the application, that can pass them to connect call, in 315 attempt to invoke a multipath connection over both IPv4 and IPv6 316 paths. This may be useful feature supporting transition from IPv4 to 317 IPv6. 319 It is not uncommon that a DNS name is associated to multiple hosts, 320 for example to perform DNS-based load balancing. As discussed above 321 with the connect call, the underlying protocol implementation should 322 be able to prevent connect attempts to separate hosts. 324 4.4. Get Local Address / Get Remote Address 326 The basic operation of these calls happens as before: they return a 327 sockaddress structure either at the local or the remote end. 328 AF_MULTIPATH address family is returned if it has been used earlier 329 with the same socket. The set of local or remote addresses SHOULD be 330 up-to-date with the currently active set in the protocol 331 implementation. When the underlying protocol is able to change the 332 active address set during the connection, this implies that 333 subsequent calls to these functions can return different sets of 334 addresses. Along with the current addresses, an application learns 335 also about the connection identifier with this call. The connection 336 identifier returned with "Get Remote Address" MUST be the same as the 337 identifier returned with "Get Local Address", since it only has local 338 meaning, and therefore the other end of the connection typically gets 339 entirely different connection identifier for the connection. 341 5. Discussion 343 5.1. Address Family or Protocol Family? 345 The socket API defines separately the protocol family, that is used 346 to define the semantics of the socket behavior when a socket is 347 created, and the address family that is used to distinguish different 348 socket address formats [RFC2553]. By convention, in many systems 349 AF_INET is defined to have an equal value to PF_INET, and AF_INET6 is 350 defined to have an equal value to PF_INET6, allowing the pairs of 351 definitions to be used interchangeably in implementations. 353 Defining separate protocol families for IPv6 and IPv4 has some 354 unfortunate consequences: in principle, it needs to be decided at 355 socket creation time whether to use IPv6 or IPv4. In practice, IPv6 356 defines a specific address range, IPv4-mapped addresses, to 357 "virtually" represent IPv4 addresses in IPv6 address space. 358 Implementations can use this feature to signal, that IPv4 should be 359 used on the wire. An alternative design choice could have been to 360 use same protocol family for both IPv4 and IPv6, and distinguish use 361 of IPv4 and IPv6 with the address family, that can be selected also 362 after the socket is created. After all, the transport protocol 363 implementation, and its semantics, are the same in both cases. 365 In case of AF_MULTIPATH, the format of the socket address structure 366 changes, while for example in the case of multipath TCP, the 367 semantics of the socket calls are intended to remain unchanged. This 368 would suggest that when AF_MULTIPATH address family is used with 369 socket address structures, the protocol family definition should 370 remain at its typical value. Here an argument can be made that 371 AF_MULTIPATH changes the behavior of bind and connect calls, but on 372 the other hand, it is correct to say that from the applications point 373 of view the outcome of a successful completion -- choosing a local 374 access point, or successfully establishing connection with the peer 375 -- is exactly the same as with the traditional use of the API. It is 376 unclear at this point, whether the pairwise definitions of protocol 377 family and address family has lead to dependencies in implementations 378 that would hinder the implementation of the AF_MULTIPATH address 379 family, or whether such dependencies would be difficult to be fixed. 381 5.2. Comparison to Alternative Design Options 383 Replacing the current socket API with a "connect-by-name" API has 384 been proposed. Different proposals have slightly different 385 abstraction levels, but commonly in these APIs application passes a 386 DNS name with the connect call. The benefit of such API is that the 387 application does not need to handle the network addresses, that 388 arguably shouldn't be application's concern in most cases, and it 389 thus avoids a separate name resolution step. In a long term this 390 seems a promising direction to take in API design, but involves 391 inter-operation between the name resolver that is often implemented 392 in user space in current systems, and may need changes in operating 393 system kernel interface. This proposal intentionally has taken the 394 traditional, more short term approach, to expose the network 395 addresses to applications. 397 Additions to the set of calls in the socket API has been proposed, 398 for example, alternative operations for multi-address bind and 399 connect [I-D.ietf-tsvwg-sctpsocket]. In the beginning this document 400 lauded the elegance of simple, generic socket API with a small basic 401 set of operations, and addition of new purpose-specific operations 402 would be a deviation from this design principle. In addition adding 403 operations to socket API would cause changes to the operating system 404 kernel function interface, that could cause interoperability and 405 maintenance issues. One way to implement such extended operations 406 would be through an user-space library that maps the operations to 407 the existing socket calls in the kernel implementation. In mapping 408 the additional operations to existing kernel interface, such library 409 might leverage a mechanism similar to what presented in this 410 document, or use, for example socket options or ioctl calls. 412 Socket options can be used tune parameters affecting the protocol 413 behavior. The extensibility of the socket option format can make it 414 appealing to use this interface for more significant run-time tasks, 415 such as adding or deleting addresses in a multi-address session, as 416 done in [I-D.ietf-shim6-multihome-shim-api]. In this approach the 417 semantics of the traditional single-homed operations still need to be 418 specified. It can also be questioned whether it is appropriate to 419 use socket options to trigger actions that can be seen to fall beyond 420 the scope of the original meaning of "socket option". 422 In summary, introducing a new address family as proposed in this 423 document allows keeping the existing set of socket operations in the 424 API, which the author believes to be a useful property, for example 425 concerning the maintenance of the interfaces between the operation 426 system and applications. If an operating system does not support 427 AF_MULTIPATH, it can gracefully return an appropriate error code to 428 an application, that can then revert to use the traditional single- 429 homed address family, if desired. There are no backwards 430 compatibility issues with old applications, because applications 431 explicitly signal their support of this address family with the 432 connect or bind calls. 434 Presenting the multiple addresses associated with the connection 435 using the socket addresses seems a natural and native way of 436 expressing this fairly new kind of property to applications. The 437 recent discussion on this idea showed, however, that the use of more 438 dynamic socket addresses can be perceived as unconventional and can 439 raise doubts, for example regarding the possible assumptions about 440 the persistence of the address structure in the implementations. It 441 is unclear how actual this concern is, given that the underlying 442 protocol that dynamically maintains the set of addresses is a fairly 443 new feature, compared to decades of past use of the end-to-end 444 transport. 446 5.3. Open Issues 448 Below are listed some potentially open issues that need to be taken 449 in to account in follow-up discussion on this document. 451 o Are there any constraints on the generic format of the socket 452 address structure, that would conflict with what proposed above? 453 It appears that for example BSD and Linux use different formats 454 for this structure, so that the Linux structure follows the "old 455 BSD" convention, without a common length field (sa_len). Are 456 there reasons to follow one of these conventions, or would it be 457 possible, for example, to specify a 16-bit length field that could 458 be useful for large sets of IPv6 addresses? 460 o Is there a need to expose pairwise source-destination subflow 461 associations, instead of just a group of source and destination 462 addresses? Currently no such reason can be seen: the socket 463 should represent one logical connection between a source host and 464 a destination host, that in this case may have multiple IP 465 addresses in use for the connection. 467 o Is a separate connection identifier field needed, as in the 468 earlier version of this document? Currently the author cannot 469 identify such need. 471 6. Security Considerations 473 No additional security threats are known because of the multipath 474 address family. This document referred to the possibility that 475 dynamic end host multihoming may enable new ways to maliciously 476 transfer a connection to another host. A multi-address interface may 477 open this possibility to applications, but ultimately the multihomed 478 protocol should have mechanisms to protect from such behavior. 480 7. Acknowledgments 482 The author is thankful to Alan Ford for pointing out specific 483 technical issues to be addressed, and to the people who have 484 participated the discussion on the MPTCP mailing list. 486 The author is supported by Finland-ICSI Center for Novel Internet 487 Architectures (FICNIA) and the Finnish Funding Agency for Technology 488 and Innovation (TEKES). 490 8. References 492 8.1. Normative References 494 [I-D.ietf-mptcp-architecture] 495 Ford, A., Raiciu, C., Barre, S., and J. Iyengar, 496 "Architectural Guidelines for Multipath TCP Development", 497 draft-ietf-mptcp-architecture-00 (work in progress), 498 March 2010. 500 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 501 Requirement Levels", BCP 14, RFC 2119, March 1997. 503 8.2. Informative References 505 [I-D.ford-mptcp-multiaddressed] 506 Ford, A., Raiciu, C., and M. Handley, "TCP Extensions for 507 Multipath Operation with Multiple Addresses", 508 draft-ford-mptcp-multiaddressed-02 (work in progress), 509 October 2009. 511 [I-D.ietf-shim6-multihome-shim-api] 512 Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto, 513 "Socket Application Program Interface (API) for 514 Multihoming Shim", draft-ietf-shim6-multihome-shim-api-13 515 (work in progress), February 2010. 517 [I-D.ietf-tsvwg-sctpsocket] 518 Stewart, R., Poon, K., Tuexen, M., Yasevich, V., and P. 519 Lei, "Sockets API Extensions for Stream Control 520 Transmission Protocol (SCTP)", 521 draft-ietf-tsvwg-sctpsocket-21 (work in progress), 522 February 2010. 524 [I-D.scharf-mptcp-api] 525 Scharf, M. and A. Ford, "MPTCP Application Interface 526 Considerations", draft-scharf-mptcp-api-00 (work in 527 progress), October 2009. 529 [RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key 530 Management API, Version 2", RFC 2367, July 1998. 532 [RFC2553] Gilligan, R., Thomson, S., Bound, J., and W. Stevens, 533 "Basic Socket Interface Extensions for IPv6", RFC 2553, 534 March 1999. 536 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 537 RFC 4960, September 2007. 539 [RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End- 540 Host Mobility and Multihoming with the Host Identity 541 Protocol", RFC 5206, April 2008. 543 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 544 Shim Protocol for IPv6", RFC 5533, June 2009. 546 Appendix A. Change log 548 Changes from version -00 to -01 550 o Added more background to the Introduction 552 o Added section to discuss protocol family/address family issues, 553 and comparison to related API designs 555 o Removed the connection identifier from the address structure, and 556 changed related descriptions related to socket calls. 558 o Added discussion about open issues in Section 3 560 Author's Address 562 Pasi Sarolahti 563 HIIT/ICSI 564 1947 Center Street (Suite 600) 565 Berkeley, CA 94704 566 USA 568 Phone: +1 (510) 409 - 9972 569 Email: pasi.sarolahti@iki.fi 570 URI: http://www.iki.fi/pasi.sarolahti/