idnits 2.17.1 draft-ietf-shim6-multihome-shim-api-13.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 a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 589: '...ltihoming shim support MUST be made by...' RFC 2119 keyword, line 592: '... EOPNOTSUPP MUST be returned....' RFC 2119 keyword, line 1240: '... sub-layer MUST return zero-filled l...' RFC 2119 keyword, line 1291: '...e shim sub-layer SHOULD provide the la...' RFC 2119 keyword, line 1362: '...ator information MAY contain a locator...' (7 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1197 has weird spacing: '... u_int msg_...' == Line 1198 has weird spacing: '... struct iovec...' == Line 1199 has weird spacing: '... u_int msg_...' == Line 1201 has weird spacing: '... u_int msg_...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 22, 2010) is 5176 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 972 -- Looks like a reference, but probably isn't: '1' on line 983 ** Obsolete normative reference: RFC 4423 (Obsoleted by RFC 9063) == Outdated reference: A later version (-23) exists of draft-ietf-behave-v6v4-xlate-05 == Outdated reference: A later version (-08) exists of draft-ietf-shim6-applicability-04 -- Obsolete informational reference (is this intentional?): RFC 2765 (Obsoleted by RFC 6145) Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SHIM6 Working Group M. Komu 3 Internet-Draft HIIT 4 Intended status: Informational M. Bagnulo 5 Expires: August 26, 2010 UC3M 6 K. Slavov 7 S. Sugimoto, Ed. 8 Ericsson 9 February 22, 2010 11 Socket Application Program Interface (API) for Multihoming Shim 12 draft-ietf-shim6-multihome-shim-api-13 14 Abstract 16 This document specifies sockets API extensions for the multihoming 17 shim layer. The API aims to enable interactions between applications 18 and the multihoming shim layer for advanced locator management, and 19 access to information about failure detection and path exploration. 21 This document is based on an assumption that a multihomed host is 22 equipped with a conceptual sub-layer (hereafter "shim") inside the IP 23 layer that maintains mappings between identifiers and locators. 24 Examples of the shim are SHIM6 and HIP. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt. 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 This Internet-Draft will expire on August 26, 2010. 49 Copyright Notice 51 Copyright (c) 2010 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3. System Overview . . . . . . . . . . . . . . . . . . . . . . . 6 69 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 5. Socket Options for Multihoming Shim Sub-layer . . . . . . . . 9 71 5.1. SHIM_ASSOCIATED . . . . . . . . . . . . . . . . . . . . . 12 72 5.2. SHIM_DONTSHIM . . . . . . . . . . . . . . . . . . . . . . 13 73 5.3. SHIM_HOT_STANDBY . . . . . . . . . . . . . . . . . . . . 14 74 5.4. SHIM_LOC_LOCAL_PREF . . . . . . . . . . . . . . . . . . . 15 75 5.5. SHIM_LOC_PEER_PREF . . . . . . . . . . . . . . . . . . . 16 76 5.6. SHIM_LOC_LOCAL_RECV . . . . . . . . . . . . . . . . . . . 17 77 5.7. SHIM_LOC_PEER_RECV . . . . . . . . . . . . . . . . . . . 18 78 5.8. SHIM_LOC_LOCAL_SEND . . . . . . . . . . . . . . . . . . . 18 79 5.9. SHIM_LOC_PEER_SEND . . . . . . . . . . . . . . . . . . . 20 80 5.10. SHIM_LOCLIST_LOCAL . . . . . . . . . . . . . . . . . . . 20 81 5.11. SHIM_LOCLIST_PEER . . . . . . . . . . . . . . . . . . . . 23 82 5.12. SHIM_APP_TIMEOUT . . . . . . . . . . . . . . . . . . . . 23 83 5.13. SHIM_PATHEXPLORE . . . . . . . . . . . . . . . . . . . . 24 84 5.14. SHIM_DEFERRED_CONTEXT_SETUP . . . . . . . . . . . . . . . 25 85 5.15. Applicability . . . . . . . . . . . . . . . . . . . . . . 26 86 5.16. Error Handling . . . . . . . . . . . . . . . . . . . . . 26 87 6. Ancillary Data for Multihoming Shim Sub-layer . . . . . . . . 26 88 6.1. Get Locator from Incoming Packet . . . . . . . . . . . . 27 89 6.2. Set Locator for Outgoing Packet . . . . . . . . . . . . . 28 90 6.3. Notification from Application to Multihoming Shim 91 Sub-layer . . . . . . . . . . . . . . . . . . . . . . . . 28 92 6.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 28 93 7. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 29 94 7.1. Placeholder for Locator Information . . . . . . . . . . . 29 95 7.1.1. Handling Locator behind NAT . . . . . . . . . . . . . 30 97 7.2. Path Exploration Parameter . . . . . . . . . . . . . . . 31 98 7.3. Feedback Information . . . . . . . . . . . . . . . . . . 32 99 8. System Requirements . . . . . . . . . . . . . . . . . . . . . 33 100 9. Relation to Existing Sockets API Extensions . . . . . . . . . 33 101 10. Operational Considerations . . . . . . . . . . . . . . . . . . 33 102 10.1. Conflict Resolution . . . . . . . . . . . . . . . . . . . 34 103 10.2. Incompatiblility between IPv4 and IPv6 . . . . . . . . . 34 104 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 105 12. Protocol Constants and Variables . . . . . . . . . . . . . . . 35 106 13. Security Considerations . . . . . . . . . . . . . . . . . . . 35 107 13.1. Treatment of Unknown Locator . . . . . . . . . . . . . . 35 108 13.1.1. Treatment of Unknown Source Locator . . . . . . . . . 35 109 13.1.2. Treatment of Unknown Destination Locator . . . . . . . 36 110 14. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 111 14.1. Changes from version 00 to version 01 . . . . . . . . . . 36 112 14.2. Changes from version 01 to version 02 . . . . . . . . . . 36 113 14.3. Changes from version 02 to version 03 . . . . . . . . . . 36 114 14.4. Changes from version 03 to version 04 . . . . . . . . . . 36 115 14.5. Changes from version 04 to version 05 . . . . . . . . . . 37 116 14.6. Changes from version 05 to version 06 . . . . . . . . . . 37 117 14.7. Changes from version 06 to version 07 . . . . . . . . . . 37 118 14.8. Changes from version 07 to version 08 . . . . . . . . . . 37 119 14.9. Changes from version 08 to version 09 . . . . . . . . . . 37 120 14.10. Changes from version 09 to version 10 . . . . . . . . . . 37 121 14.11. Changes from version 10 to version 11 . . . . . . . . . . 37 122 14.12. Changes from version 11 to version 12 . . . . . . . . . . 37 123 14.13. Changes from version 12 to version 13 . . . . . . . . . . 38 124 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38 125 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 126 16.1. Normative References . . . . . . . . . . . . . . . . . . 38 127 16.2. Informative References . . . . . . . . . . . . . . . . . 39 128 Appendix A. Context Forking . . . . . . . . . . . . . . . . . . . 39 129 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 131 1. Introduction 133 This document defines socket API extensions by which upper layer 134 protocols may be informed about and control the way in which a 135 multihoming shim sub-layer in the IP layer manages the dynamic choice 136 of locators. Initially it applies to SHIM6 and HIP, but it is 137 defined generically. 139 The role of the multihoming shim sub-layer (hereafter called "shim 140 sub-layer" in this document) is to avoid impacts to upper layer 141 protocols which may be caused when the endhost changes its attachment 142 point to the Internet, for instance, in the case of rehoming event 143 under the multihomed environment. The key design of the shim sub- 144 layer is to treat identifier and locator separately. Identifiers are 145 presented to upper layer protocols and used as communication 146 endpoints. Locators represent toplogical location of endhosts and 147 are used to route packet from the source to the destiantion. The 148 shim sub-layer maintains mapping of identifiers and locators. 150 Note that the shim sub-layer may conflict with other multihoming 151 mechanisms such as SCTP and multipath 152 TCP[I-D.ietf-shim6-applicability]. To avoid any conflict, only one 153 of SHIM6 and HIP should be in use. 155 In this document, syntax and semantics of the API are given in the 156 same way as the Posix standard [POSIX]. The API specifies how to use 157 ancillary data (aka cmsg) to access the locator information with 158 recvmsg() and/or sendmsg() I/O calls. The API is described in C 159 language and data types are defined in the Posix format; intN_t means 160 a signed integer of exactly N bits (e.g. int16_t) and uintN_t means 161 an unsigned integer of exactly N bits (e.g. uint32_t). 163 The distinction between "connected" sockets and "unconnected" sockets 164 is important when discussing the applicability of the socket API 165 defined in this document. A connected socket is bound to a given 166 peer, whereas an unconnected socket is not bound to any specific 167 peers. A TCP socket becomes a connected socket when the TCP 168 connection establishment is completed. UDP sockets are unconnected, 169 unless the application uses the connect() system call. 171 The target readers of this document are application programmers who 172 develop application software which may benefit greatly from 173 multihomed environments. In addition, this document aims to provide 174 necessary information for developers of shim protocols to implement 175 API for enabling advanced locator management. 177 2. Terminology 179 This section provides terminology used in this document. Basically 180 most of the terms used in this document are taken from the following 181 documents: 183 o SHIM6 Protocol Specification[RFC5533] 184 o HIP Architecture[RFC4423] 185 o Reachability Protocol (REAP)[RFC5534] 187 In this document, the term "IP" refers to both IPv4 and IPv6, unless 188 the protocol version is specifically mentioned. The following are 189 definitions of terms frequently used in this document: 191 o Endpoint identifier (EID) - The identifier used by the application 192 to specify the endpoint of a given communication. Applications 193 may handle EIDs in various ways such as long-lived connections, 194 callbacks, and referrals[I-D.ietf-shim6-app-refer]. 195 * In the case of SHIM6, an identifier called a ULID serves as an 196 EID. A ULID is chosen from locators available on the host. 197 * In the case of HIP, an identifier called a Host Identifier 198 serves as an EID. A Host Identifier is derived from the public 199 key of a given host. For the sake of backward compatibility 200 with the sockets API, the Host Identifier is represented in a 201 form of hash of public key. 202 * Note that the EID appears in the standard socket API as an 203 address, and does not appear in the extensions defined in this 204 document, which only concern locators. 205 o Locator - The IP address actually used to deliver IP packets. 206 Locators are present in the source and destination fields of the 207 IP header of a packet on the wire. 208 * List of locators - A list of locators associated with an EID. 209 There are two lists of locators stored in a given context. One 210 is associated with the local EID and the other is associated 211 with the remote EID. As defined in [RFC5533], the list of 212 locators associated with an EID 'A' is denoted as Ls(A). 213 * Preferred locator - The (source/destination) locator currently 214 used to send packets within a given context. As defined in 215 [RFC5533], the preferred locator of a host 'A' is denoted as 216 Lp(A). 217 * Unknown locator - Any locator that does not appear in the 218 locator list of the shim context associated with the socket. 219 When there is no shim context associated with the socket, any 220 source and/or destination locator requested by the application 221 is considered to be unknown locator. 222 o Shim - The conceptual sub-layer inside the IP layer which 223 maintains mappings between EIDs and locators. An EID can be 224 associated with more than one locator at a time when the host is 225 multihomed. The term 'shim' does not refer to a specific protocol 226 but refers to the conceptual sub-layer inside the IP layer. 227 o Identifier/locator adaptation - The adaptation performed at the 228 shim sub-layer which may end up re-writing the source and/or 229 destination addresses of an IP packet. In the outbound packet 230 processing, the EID pair is converted to the associated locator 231 pair. In the inbound packet processing, the locator pair is 232 converted to the EID pair. 233 o Context - The state information shared by a given pair of peers, 234 which stores a binding between the EID and associated locators. 235 Contexts are maintained by the shim sub-layer. 236 o Reachability detection - The procedure to check reachability 237 between a given locator pair. 238 o Path - The sequence of routers that an IP packet goes through to 239 reach the destination. 240 o Path exploration - The procedure to explore available paths for a 241 given set of locator pairs. 242 o Outage - The incident that prevents IP packets to flow from the 243 source locator to the destination locator. When there is an 244 outage, it means that there is no reachability between a given 245 locator pair. The outage may be caused by various reasons, such 246 as shortage of network resources, congestion, and human error 247 (faulty operation). 248 o Working address pair - The address pair is considered to be 249 "working" if the packet can safely travel from the source to the 250 destination where the packet contains the first address from the 251 pair as the source address and the second address from the pair as 252 the destination address. If reachability is confirmed in both 253 directions, the address pair is considered to be working bi- 254 directionally. 255 o Reachability protocol (REAP) - The protocol for detecting failure 256 and exploring reachability in a multihomed environment. REAP is 257 defined in [RFC5534]. 259 3. System Overview 261 Figure 1 illustrates the system overview. The shim sub-layer and 262 REAP component exist inside the IP layer. Applications use the 263 sockets API defined in this document to interface with the shim sub- 264 layer and the transport layer for locator management, failure 265 detection, and path exploration. 267 It may also be possible that the shim sub-layer interacts with the 268 transport layer, however, such an interaction is outside the scope of 269 this document. 271 +------------------------+ 272 | Application | 273 +------------------------+ 274 ^ ^ 275 ~~~~~~~~~~~~~|~Socket Interface|~~~~~~~~~~~~~~ 276 | v 277 +-----------|------------------------------+ 278 | | Transport Layer | 279 +-----------|------------------------------+ 280 ^ | 281 +-------------|-----|-------------------------------------+ 282 | v v | 283 | +-----------------------------+ +----------+ | IP 284 | | Shim |<----->| REAP | | Layer 285 | +-----------------------------+ +----------+ | 286 | ^ ^ | 287 +-----------------------|----------------------|----------+ 288 v v 289 +------------------------------------------+ 290 | Link Layer | 291 +------------------------------------------+ 293 Figure 1: System overview 295 4. Requirements 297 The following is a list of requirements from applications: 298 o Turn on/off shim. An application should be able to request to 299 turn on or turn off the multihoming support by the shim layer: 300 * Apply shim. The application should be able to explicitly 301 request the shim sub-layer to apply multihoming support. 302 * Don't apply shim. The application should be able to request 303 the shim sub-layer not to apply the multihoming support but to 304 apply normal IP processing at the IP layer. 305 * Note that this function is also required by other types of 306 multihoming mechanisms such as SCTP and multipath TCP to avoid 307 potential conflict with the shim sub-layer. 308 o Locator management. 309 * It should be possible to set preferred source and/or 310 destination locator within a given context: Lp(local) and/or 311 Lp(remote). 312 * It should be possible to get preferred source and/or 313 destination locator within a given context: Lp(local) and/or 314 Lp(remote). 316 * It should be possible to set a list of source and/or 317 destination locators within a given context: Ls(local) and 318 Ls(remote). 319 * It should be possible to get a list of source and/or 320 destination locators within a given context: Ls(local) and 321 Ls(remote). 322 o Notification from applications to the shim sub-layer about the 323 status of the communication. The notification occurs in an event- 324 based manner. Applications and/or upper layer protocols may 325 provide positive feedbacks or negative feedbacks to the shim sub- 326 layer. Note that these feedbacks are mentioned in [RFC5534]: 327 * Applications and/or upper layer protocols (e.g., TCP) may 328 provide positive feedbacks to the shim sub-layer informing that 329 the communication is going well. 330 * Applications and/or upper layer protocols (e.g., TCP) may 331 provide negative feedbacks to the shim sub-layer informing that 332 the communication status is not satisfactory. TCP may detect a 333 problem when it does not receive any expected ACK message from 334 the peer. The REAP module may be triggered by these negative 335 feedbacks and invoke the path exploration procedure. 336 o Feedback from applications to the shim sub-layer. Applications 337 should be able to inform the shim sub-layer of the timeout values 338 for detecting failures, sending keepalives, and starting the 339 exploration procedure. In particular, applications should be able 340 to suppress keepalives. 341 o Hot-standby. Applications may request the shim sub-layer for the 342 hot-standby capability. This means that, alternative paths are 343 known to be working in advance of a failure detection. In such a 344 case, it is possible for the host to immediately replace the 345 current locator pair with an alternative locator pair. 346 o Eagerness for locator exploration. An application should be able 347 to inform the shim sub-layer of how aggressively it wants the REAP 348 mechanism to perform a path exploration (e.g., by specifying the 349 number of concurrent attempts of discovery of working locator 350 pairs) when an outage occurs on the path between the locator pair 351 in use. 352 o Providing locator information to applications. An application 353 should be able to obtain information about the locator pair which 354 was actually used to send or receive the packet. 355 * For inbound traffic, the application may be interested in the 356 locator pair which was actually used to receive the packet. 357 * For outbound traffic, the application may be interested in the 358 locator pair which was actually used to transmit the packet. 359 In this way, applications may have additional control on the 360 locator management. For example, an application becomes able to 361 verify if its preference for locator is actually applied to the 362 flow or not. 364 o Applications should be able to know if the shim-sublayer supports 365 deferred context setup or not. 366 o An application should be able to know if the communication is now 367 being served by the shim sub-layer or not. 368 o An application should be able to use a common interface to access 369 an IPv4 locator and an IPv6 locator. 371 5. Socket Options for Multihoming Shim Sub-layer 373 In this section, socket options that are specific to the shim sub- 374 layer are defined. 376 Table 1 shows a list of the socket options that are specific to the 377 shim sub-layer. An application may use these socket options for a 378 given socket either by the getsockopt() system call or by the 379 setsockopt() system call. All of these socket options are defined at 380 level SOL_SHIM. 382 The first column of Table 1 gives the name of the option. The second 383 and third columns indicate whether the option can be handled by the 384 getsockopt() system call and/or by the setsockopt() system call. The 385 fourth column provides a brief description of the socket option. The 386 fifth column shows the type of data structure specified along with 387 the socket option. By default, the data structure type is an 388 integer. 390 +-----------------------------+-----+-----+-----------------+-------+ 391 | optname | get | set | description | dtype | 392 +-----------------------------+-----+-----+-----------------+-------+ 393 | SHIM_ASSOCIATED | o | | Get the | int | 394 | | | | parameter which | | 395 | | | | indicates | | 396 | | | | whether the | | 397 | | | | socket is | | 398 | | | | associated with | | 399 | | | | any shim | | 400 | | | | context or not. | | 401 | SHIM_DONTSHIM | o | o | Get or set the | int | 402 | | | | parameter which | | 403 | | | | indicates | | 404 | | | | whether to | | 405 | | | | employ the | | 406 | | | | multihoming | | 407 | | | | support by the | | 408 | | | | shim sub-layer | | 409 | | | | or not. | | 410 | SHIM_HOT_STANDBY | o | o | Get or set the | int | 411 | | | | parameter to | | 412 | | | | request the | | 413 | | | | shim sub-layer | | 414 | | | | to prepare a | | 415 | | | | hot-standby | | 416 | | | | connection. | | 417 | SHIM_LOC_LOCAL_PREF | o | o | Get or set the | *1 | 418 | | | | preferred | | 419 | | | | locator on the | | 420 | | | | local side for | | 421 | | | | the context | | 422 | | | | associated with | | 423 | | | | the socket. | | 424 | SHIM_LOC_PEER_PREF | o | o | Get or set the | *1 | 425 | | | | preferred | | 426 | | | | locator on the | | 427 | | | | remote side for | | 428 | | | | the context | | 429 | | | | associated with | | 430 | | | | the socket. | | 431 | SHIM_LOC_LOCAL_RECV | o | o | Get or set the | int | 432 | | | | parameter which | | 433 | | | | is used to | | 434 | | | | request the | | 435 | | | | shim sub-layer | | 436 | | | | to store the | | 437 | | | | destination | | 438 | | | | locator of the | | 439 | | | | received IP | | 440 | | | | packet. | | 441 | SHIM_LOC_PEER_RECV | o | o | Get or set the | int | 442 | | | | parameter which | | 443 | | | | is used to | | 444 | | | | request the | | 445 | | | | shim sub-layer | | 446 | | | | to store the | | 447 | | | | source locator | | 448 | | | | of the received | | 449 | | | | IP packet. | | 450 | SHIM_LOC_LOCAL_SEND | o | o | Get or set the | *1 | 451 | | | | source locator | | 452 | | | | of outgoing IP | | 453 | | | | packets. | | 454 | SHIM_LOC_PEER_SEND | o | o | Get or set the | *1 | 455 | | | | destination | | 456 | | | | locator of | | 457 | | | | outgoing IP | | 458 | | | | packets. | | 459 | SHIM_LOCLIST_LOCAL | o | o | Get or set the | *2 | 460 | | | | list of | | 461 | | | | locators | | 462 | | | | associated with | | 463 | | | | the local EID. | | 464 | SHIM_LOCLIST_PEER | o | o | Get or set the | *2 | 465 | | | | list of | | 466 | | | | locators | | 467 | | | | associated with | | 468 | | | | the peer's EID. | | 469 | SHIM_APP_TIMEOUT | o | o | Get or set the | int | 470 | | | | timeout value | | 471 | | | | for detecting | | 472 | | | | failure. | | 473 | SHIM_PATHEXPLORE | o | o | Get or set | *3 | 474 | | | | parameters for | | 475 | | | | path | | 476 | | | | exploration and | | 477 | | | | failure | | 478 | | | | detection. | | 479 | SHIM_CONTEXT_DEFERRED_SETUP | o | | Get the | int | 480 | | | | parameter which | | 481 | | | | indicates | | 482 | | | | whether | | 483 | | | | deferred | | 484 | | | | context setup | | 485 | | | | is supported or | | 486 | | | | not. | | 487 +-----------------------------+-----+-----+-----------------+-------+ 489 Table 1: Socket options for multihoming shim sub-layer 491 *1: Pointer to a shim_locator which is defined in Section 7. 493 *2: Pointer to an array of shim_locator. 495 *3: Pointer to a shim_pathexplore which is defined in Section 7. 497 Figure 2 illustrates how the shim specific socket options fit into 498 the system model of socket API. The figure shows that the shim sub- 499 layer and the additional protocol components (IPv4 and IPv6) below 500 the shim sub-layer are new to the system model. As previously 501 mentioned, all the shim specific socket options are defined at the 502 SOL_SHIM level. This design choice brings the following advantages: 504 1. The existing sockets API continue to work at the layer above the 505 shim sub-layer. That is, those legacy API handle IP addresses as 506 identifiers. 507 2. With newly defined socket options for the shim sub-layer, the 508 application obtains additional control of locator management. 509 3. The shim specific socket options can be kept independent from 510 address family (IPPROTO_IP or IPPROTO_IPV6) and transport 511 protocol (IPPROTO_TCP or IPPROTO_UDP). 513 s1 s2 s3 s4 514 | | | | 515 +----------------|--|-------|--|----------------+ 516 | +-------+ +-------+ | 517 | IPPROTO_TCP | TCP | | UDP | | 518 | +-------+ +-------+ | 519 | | \ / | | 520 | | ----- | | 521 | | / \ | | 522 | +------+ +------+ | 523 | IPPROTO_IP | IPv4 | | IPv6 | IPPROTO_IPV6 | 524 | +------+ +------+ | 525 | \ / SOL_SOCKET 526 | +--------\-------/--------+ | 527 | SOL_SHIM | shim | | 528 | +--------/-------\--------+ | 529 | / \ | 530 | +------+ +------+ | 531 | | IPv4 | | IPv6 | | 532 | +------+ +------+ | 533 | | | | 534 +------------------|----------|-----------------+ 535 | | 536 IPv4 IPv6 537 Datagram Datagram 539 Figure 2: System model of sockets API with shim sub-layer 541 5.1. SHIM_ASSOCIATED 543 The SHIM_ASSOCIATED option is used to check whether the socket is 544 associated with any shim context or not. 546 This option is meaningful when the locator information of the 547 received IP packet does not tell whether the identifier/locator 548 adaptation is performed or not. Note that the EID pair and the 549 locator pair may be identical in some cases. 551 This option can be specified by getsockopt(). Thus, the option is 552 read-only and the result (0/1/2) is set in the option value (the 553 fourth argument of getsockopt()). 555 When the application specifies the socket option to an unconnected 556 socket, an error code EOPNOTSUPP is returned to the application. 558 The data type of the option value is an integer. The option value 559 indicates the presence of shim context. A return value 1 means that 560 the socket is associated with a shim context at the shim sub-layer. 561 A return value 0 indicates that there is no shim context associated 562 with the socket. A return value 2 means that it is not known whether 563 the socket is associated with a shim context or not, and this must be 564 returned only when the socket is unconnected. In other words, the 565 returned value must be 0 or 1 when the socket is connected. 567 For example, the option can be used by the application as follows: 569 int optval; 570 int optlen = sizeof(optval); 572 getsockopt(fd, SOL_SHIM, SHIM_ASSOCIATED, &optval, &optlen); 574 5.2. SHIM_DONTSHIM 576 The SHIM_DONTSHIM option is used to request the shim layer not to 577 provide the multihoming support for the communication established 578 over the socket. 580 The data type of the option value is an integer, and it takes 0 or 1. 581 An option value 0 means that the shim sub-layer is employed if 582 available. An option value 1 means that the application does not 583 want the shim sub-layer to provide the multihoming support for the 584 communication established over the socket. 586 Default value is set as 0, which means that the shim sub-layer 587 performs identifier/locator adaptation if available. 589 Any attempt to disable the multihoming shim support MUST be made by 590 the application before the socket is connected. If an application 591 makes such an attempt for a connected-socket, an error code 592 EOPNOTSUPP MUST be returned. 594 For example, an application can request the system not to apply the 595 multihoming support as follows: 597 int optval; 599 optval = 1; 601 setsockopt(fd, SOL_SHIM, SHIM_DONTSHIM, &optval, sizeof(optval)); 603 For example, the application can check the option value as follows: 605 int optval; 606 int len; 608 len = sizeof(optval); 610 getsockopt(fd, SOL_SHIM, SHIM_DONTSHIM, &optval, &len); 612 5.3. SHIM_HOT_STANDBY 614 The SHIM_HOT_STANDBY option is used to control the shim sub-layer 615 whether to employ a hot-standby connection for the socket or not. A 616 hot-standby connection is an alternative working locator pair to the 617 current locator pair. This option is effective only when there is a 618 shim context associated with the socket. 620 The data type of the option value is an integer. 622 The option value can be set by setsockopt(). 624 The option value can be read by getsockopt(). 626 By default, the value is set to 0, meaning that hot-standby 627 connection is disabled. 629 When the application specifies the socket option to an unconnected 630 socket, an error code EOPNOTSUPP is returned to the application. 632 When there is no shim context associated with the socket, an error 633 code ENOENT is returned to the application. 635 For example, an application can request establishment of a hot- 636 standby connection by using the socket option as follows: 638 int optval; 640 optval = 1; 642 setsockopt(fd, SOL_SHIM, SHIM_HOT_STANDBY, &optval, 643 sizeof(optval)); 645 For example, an application can get the option value by using the 646 socket option as follows: 648 int optval; 649 int len; 651 len = sizeof(optval); 653 getsockopt(fd, SOL_SHIM, SHIM_HOT_STANDBY, &optval, &len); 655 5.4. SHIM_LOC_LOCAL_PREF 657 The SHIM_LOC_LOCAL_PREF option is used to get or set preference for a 658 source locator for outbound traffic within a given context. This 659 option is effective only when there is a shim context associated with 660 the socket. 662 The preference of a locator is defined by a combination of priority 663 and weight as per DNS SRV[RFC2782]. Note that the SHIM6 base 664 protocol defines preference of locator in the same way. 666 The data type of the option value is a pointer to a locator 667 information data structure which is defined in Section 7. 669 By default, the option value is set to NULL, meaning that the option 670 is disabled. 672 The preferred locator can be set by setsockopt(). The shim sub-layer 673 shall verify requested locator before it updates the preferred 674 locator. 676 An application can get the preferred locator by getsockopt(). 678 When the application specifies the socket option to an unconnected 679 socket, an error code EOPNOTSUPP is returned to the application. 681 When there is no shim context associated with the socket, an error 682 code ENOENT is returned to the application. 684 An error EINVALIDLOCATOR is returned when the validation of the 685 specified locator fails. 687 For example, an application can set the preferred locator by using 688 the socket option as follows. Note that some members of the 689 shim_locator (lc_ifidx and lc_flags) are ignored in the set 690 operation. 692 struct shim_locator lc; 693 struct in6_addr ip6; 695 /* ...set the locator (ip6)... */ 697 memset(&lc, 0, sizeof(shim_locator)); 698 lc.lc_family = AF_INET6; /* IPv6 */ 699 lc.lc_ifidx = 0; 700 lc.lc_flags = 0; 701 lc.lc_prio = 1; 702 lc.lc_weight = 10; 703 memcpy(&lc.lc_addr, &ip6, sizeof(in6_addr)); 705 setsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_PREF, &lc, 706 sizeof(optval)); 708 For example, an application can get the preferred locator by using 709 the socket option as follows. 711 struct shim_locator lc; 712 int len; 714 len = sizeof(lc); 716 getsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_PREF, &lc, &len); 718 5.5. SHIM_LOC_PEER_PREF 720 The SHIM_LOC_PEER_PREF option is used to get or set preference of a 721 destination locator for outbound traffic within a given context. 722 This option is effective only when there is a shim context associated 723 with the socket. 725 As defined earlier, the preference of a locator is defined by a 726 combination of priority and weight as per DNS SRV[RFC2782]. When 727 there are more than one candidate destination locators, the shim sub- 728 layer makes selection based on the priority and weight specified for 729 each locator. 731 The data type of the option value is a pointer to the locator 732 information data structure which is defined in Section 7. 734 By default, the option value is set to NULL, meaning that the option 735 is disabled. 737 The preferred locator can be set by setsockopt(). The shim sub-layer 738 shall verify requested locator before it updating the preferred 739 locator. 741 An application can get the preferred locator by getsockopt(). 743 When the application specifies the socket option to an unconnected 744 socket, an error code EOPNOTSUPP is returned to the application. 746 When there is no shim context associated with the socket, an error 747 code ENOENT is returned to the application. 749 An error EINVALIDLOCATOR is returned when the validation of the 750 requested locator fails. 752 The usage of the option is same as that of SHIM_LOC_LOCAL_PREF. Note 753 that some members of the shim_locator (lc_ifidx and lc_flags) are 754 ignored in the set operation. 756 5.6. SHIM_LOC_LOCAL_RECV 758 The SHIM_LOC_LOCAL_RECV option can be used to request the shim sub- 759 layer to store the destination locator of the received IP packet in 760 an ancillary data object which can be accessed by recvmsg(). This 761 option is effective only when there is a shim context associated with 762 the socket. 764 The data type of the option value is integer. The option value 765 should be binary (0 or 1). By default, the option value is set to 0, 766 meaning that the option is disabled. 768 An application can set the option value by setsockopt(). 770 An application can get the option value by getsockopt(). 772 See Section 6 for the procedure to access locator information stored 773 in the ancillary data objects. 775 When the application specifies the socket option to an unconnected 776 socket, an error code EOPNOTSUPP is returned to the application. 778 When there is no shim context associated with the socket, an error 779 code ENOENT is returned to the application. 781 For example, an application can request the shim sub-layer to store 782 destination locator by using the socket option as follows. 784 int optval; 786 optval = 1; 788 setsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_RECV, &optval, 789 sizeof(optval)); 791 For example, an application can get the option value as follows. 793 int optval; 794 int len; 796 len = sizeof(optval); 798 getsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_RECV, &optval, &len); 800 5.7. SHIM_LOC_PEER_RECV 802 The SHIM_LOC_PEER_RECV option is used to request the shim sub-layer 803 to store the source locator of the received IP packet in an ancillary 804 data object which can be accessed by recvmsg(). This option is 805 effective only when there is a shim context associated with the 806 socket. 808 The data type of the option value is integer. The option value 809 should be binary (0 or 1). By default, the option value is set to 0, 810 meaning that the option is disabled. 812 The option value can be set by setsockopt(). 814 The option value can be read by getsockopt(). 816 See Section 6 for the procedure to access locator information stored 817 in the ancillary data objects. 819 When the application specifies the socket option to an unconnected 820 socket, an error code EOPNOTSUPP is returned to the application. 822 When there is no shim context associated with the socket, an error 823 code ENOENT is returned to the application. 825 The usage of the option is same as that of SHIM_LOC_LOCAL_RECV 826 option. 828 5.8. SHIM_LOC_LOCAL_SEND 830 The SHIM_LOC_LOCAL_SEND option is used to request the shim sub-layer 831 to use a specific locator as the source locator for the IP packets to 832 be sent from the socket. This option is effective only when there is 833 a shim context associated with the socket. 835 The data type of option value is pointer to shim_locator data 836 structure. 838 An application can set the local locator by setsockopt() providing a 839 valid locator which is stored in a shim_locator data structure. When 840 a zero-filled locator is specified, pre-existing setting of local 841 locator is inactivated. 843 An application can get the local locator by getsockopt(). 845 When the application specifies the socket option to an unconnected 846 socket, an error code EOPNOTSUPP is returned to the application. 848 When there is no shim context associated with the socket, an error 849 code ENOENT is returned to the application. 851 An error EINVALIDLOCATOR is returned when an invalid locator is 852 specified. 854 For example, an application can request the shim sub-layer to use a 855 specific local locator by using the socket option as follows. 857 struct shim_locator locator; 858 struct in6_addr ia6; 860 /* an IPv6 address preferred for the source locator is copied 861 to the parameter ia6 */ 863 memset(&locator, 0, sizeof(locator)); 865 /* fill shim_locator data structure */ 866 locator.lc_family = AF_INET6; 867 locator.lc_ifidx = 1; 868 locator.lc_flags = 0; 869 locator.lc_prio = 0; 870 locator.lc_weight = 0; 871 memcpy(&locator.lc_addr, &ia6, sizeof(ia6)); 873 setsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_SEND, &locator, 874 sizeof(locator)); 876 For example, an application can get the preferred local locator by 877 using the socket option as follows. 879 struct shim_locator locator; 881 memset(&locator, 0, sizeof(locator)); 883 getsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_SEND, &locator, 884 sizeof(locator)); 886 /* check locator */ 888 5.9. SHIM_LOC_PEER_SEND 890 The SHIM_LOC_PEER_SEND option is used to request the shim sub-layer 891 to use a specific locator for the destination locator of IP packets 892 to be sent from the socket. This option is effective only when there 893 is a shim context associated with the socket. 895 The data type of the option value is a pointer to shim_locator data 896 structure. 898 An application can set the remote locator by setsockopt() providing a 899 valid locator which is stored in a shim_locator data structure. When 900 a zero-filled locator is specified, pre-existing setting of remote 901 locator is inactivated. 903 An application can get the specified remote locator by getsockopt(). 905 When the application specifies the socket option to an unconnected 906 socket, an error code EOPNOTSUPP is returned to the application. 908 When there is no shim context associated with the socket, an error 909 code ENOENT is returned to the application. 911 An error EINVALIDLOCATOR when invalid an locator is specified. 913 The usage of the option is the same as that of SHIM_LOC_LOCAL_SEND 914 option. 916 5.10. SHIM_LOCLIST_LOCAL 918 The SHIM_LOCLIST_LOCAL option is used to get or set the locator list 919 associated with the local EID of the shim context associated with the 920 socket. This option is effective only when there is a shim context 921 associated with the socket. 923 The data type of the option value is a pointer to the buffer in which 924 a locator list is stored. See Section 7 for the data structure for 925 storing the locator information. By default, the option value is set 926 to NULL, meaning that the option is disabled. 928 An application can get the locator list by getsockopt(). Note that 929 the size of the buffer pointed to by the optval argument should be 930 large enough to store an array of locator information. The number of 931 the locator information is not known beforehand. 933 The local locator list can be set by setsockopt(). The buffer 934 pointed to by the optval argument should contain an array of locator 935 structures. 937 When the application specifies the socket option to an unconnected 938 socket, an error code EOPNOTSUPP is returned to the application. 940 When there is no shim context associated with the socket, an error 941 code ENOENT is returned to the application. 943 An error EINVALIDLOCATOR is returned when the validation of any of 944 the specified locators failed. 946 An error ETOOMANYLOCATORS is returned when the number of locators 947 specified exceeds the limit (SHIM_MAX_LOCATORS), or when the size of 948 the buffer provided by the application is not large enough to store 949 the locator list provided by the shim sub-layer. 951 For example, an application can set a list of locators to be 952 associated with the local EID by using the socket option as follows: 954 struct shim_locator locators[SHIM_MAX_LOCATORS]; 955 struct sockaddr_in *sin; 956 struct sockaddr_in6 *sin6; 958 memset(locators, 0, sizeof(locators)); 960 ... 962 /* obtain local IP addresses from local interfaces */ 964 ... 966 /* first locator (an IPv6 address) */ 967 locators[0].lc_family = AF_INET6; 968 locators[0].lc_ifidx = 0; 969 locators[0].lc_flags = 0; 970 locators[0].lc_prio = 1; 971 locators[0].lc_weight = 0; 972 memcpy(&locators[0].lc_addr, &sa6->sin6_addr, 973 sizeof(sa6->sin6_addr)); 975 ... 977 /* second locator (an IPv4 address) */ 978 locators[1].lc_family = AF_INET; 979 locators[1].lc_ifidx = 0; 980 locators[1].lc_flags = 0; 981 locators[1].lc_prio = 0; 982 locators[1].lc_weight = 0; 983 memcpy(&locators[1].lc_addr, &sa->sin_addr, 984 sizeof(sa->sin_addr)); 986 setsockopt(fd, SOL_SHIM, SHIM_LOCLIST_LOCAL, locators, 987 sizeof(locators)); 989 For example, an application can get a list of locators that are 990 associated with the local EID by using the socket option as follows. 992 struct shim_locator locators[SHIM_MAX_LOCATORS]; 994 memset(locators, 0, sizeof(locators)); 996 getsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_RECV, locators, 997 sizeof(locators)); 999 /* parse locators */ 1000 ... 1002 5.11. SHIM_LOCLIST_PEER 1004 The SHIM_LOCLIST_PEER option is used to get or set the locator list 1005 associated with the peer EID of the shim context associated with the 1006 socket. This option is effective only when there is a shim context 1007 associated with the socket. 1009 The data type of the option value is a pointer to the buffer where a 1010 locator list is stored. See Section 7 for the data structure for 1011 storing the locator information. By default, the option value is set 1012 to NULL, meaning that the option is disabled. 1014 An application can get the locator list by getsockopt(). Note that 1015 the size of the buffer pointed to by the optval argument should be 1016 large enough to store an array of locator information. The number of 1017 the locator information is not known beforehand. 1019 An application can set the locator list by setsockopt(). The buffer 1020 pointed to by the optval argument should contain an array of locator 1021 list. 1023 When the application specifies the socket option to an unconnected 1024 socket, an error code EOPNOTSUPP is returned to the application. 1026 When there is no shim context associated with the socket, an error 1027 code ENOENT is returned to the application. 1029 An error EINVALIDLOCATOR is returned when the validation of any of 1030 the specified locators failed. 1032 An error ETOOMANYLOCATORS is returned when the number of locators 1033 specified exceeds the limit (SHIM_MAX_LOCATORS), or when the size of 1034 the buffer provided by the application is not large enough to store 1035 the locator list provided by the shim sub-layer. 1037 The usage of the option is same as that of SHIM_LOCLIST_LOCAL. 1039 5.12. SHIM_APP_TIMEOUT 1041 The SHIM_APP_TIMEOUT option is used to get or set the Send Timeout 1042 value of the REAP protocol. This option is effective only when there 1043 is a shim context associated with the socket. 1045 The data type of the option value is an integer. The value indicates 1046 the period of timeout in seconds to send a REAP Keepalive message 1047 since the last outbound traffic. By default, the option value is set 1048 to 0, meaning that the option is disabled. When the option is 1049 disabled, the REAP mechanism follows its default value of Send 1050 Timeout value as specified in [RFC5534] 1052 When the application specifies the socket option to an unconnected 1053 socket, an error code EOPNOTSUPP is returned to the application. 1055 When there is no shim context associated with the socket, an error 1056 code ENOENT is returned to the application. 1058 For example, an application can set the timeout value by using the 1059 socket option as follows. 1061 int optval; 1063 optval = 15; /* 15 seconds */ 1065 setsockopt(fd, SOL_SHIM, SHIM_APP_TIMEOUT, &optval, 1066 sizeof(optval)); 1068 For example, an application can get the timeout value by using the 1069 socket option as follows. 1071 int optval; 1072 int len; 1074 len = sizeof(optval); 1076 getsockopt(fd, SOL_SHIM, SHIM_APP_TIMEOUT, &optval, &len); 1078 5.13. SHIM_PATHEXPLORE 1080 The application may use this socket option to get or set parameters 1081 concerning path exploration. Path exploration is a procedure to find 1082 an alternative locator pair to the current locator pair. As the REAP 1083 specification defines, a peer may send Probe messages to find an 1084 alternative locator pair. 1086 This option is effective only when there is a shim context associated 1087 with the socket. 1089 The data type of the option value is a pointer to the buffer where a 1090 set of information for path exploration is stored. The data 1091 structure is defined in Section 7. 1093 By default, the option value is set to NULL, meaning that the option 1094 is disabled. 1096 When the application specifies the socket option to an unconnected 1097 socket, an error code EOPNOTSUPP is returned to the application. 1099 When there is no shim context associated with the socket, an error 1100 code ENOENT is returned to the application. 1102 For example, an application can set parameters for path exploration 1103 by using the socket option as follows. 1105 struct shim6_pathexplore pe; 1107 pe.pe_probenum = 4; /* times */ 1108 pe.pe_keepaliveto = 10; /* seconds */ 1109 pe.pe_initprobeto = 500; /* milliseconds */ 1110 pe.pe_reserved = 0; 1112 setsockopt(fd, SOL_SHIM, SHIM_PATHEXPLORE, &pe, sizeof(pe)); 1114 For example, an application can get parameters for path exploration 1115 by using the socket option as follows. 1117 struct shim6_pathexplore pe; 1118 int len; 1120 len = sizeof(pe); 1122 getsockopt(fd, SOL_SHIM, SHIM_PATHEXPLORE, &pe, &len); 1124 5.14. SHIM_DEFERRED_CONTEXT_SETUP 1126 The SHIM_DEFERRED_CONTEXT_SETUP option is used to check whether 1127 deferred context setup is possible or not. Deferred context setup 1128 means that the context is established in parallel with the data 1129 communication. Note that SHIM6 supports deferred context setup and 1130 HIP does not because EIDs in HIP (i.e., Host Identifiers) are non- 1131 routable. 1133 The data type for the option value is an integer. The option value 1134 should be binary (0 or 1). The option value 1 means that the shim 1135 sub-layer supports deferred context setup. 1137 When the application specifies the socket option to an unconnected 1138 socket, an error code EOPNOTSUPP is returned to the application. 1140 For example, an application can check whether deferred context setup 1141 is possible or not as follows: 1143 int optval; 1144 int len; 1146 len = sizeof(optval); 1148 getsockopt(fd, SOL_SHIM, SHIM_DEFERRED_CONTEXT_SETUP, 1149 &optval, &len); 1151 5.15. Applicability 1153 All the socket options defined in this section except for the 1154 SHIM_DONTSHIM option are applicable to applications that use 1155 connected sockets. 1157 All the socket options defined in this section except for the 1158 SHIM_ASSOCIATED, SHIM_DONTSHIM and SHIM_CONTEXT_DEFERRED_SETUP 1159 options are effective only when there is a shim context associated 1160 with the socket. 1162 5.16. Error Handling 1164 If successful, getsockopt() and setsockopt() return 0; otherwise, the 1165 functions return -1 and set errno to indicate an error. 1167 The following are new error values defined for some shim specific 1168 socket options indicating that the getsockopt() or setsockopt() 1169 finished incompletely: 1171 EINVALIDLOCATOR 1172 This indicates that at least one of the necessary validations 1173 inside the shim sub-layer for the specified locator has failed. 1174 In case of SHIM6, there are two kinds of verifications required 1175 for security reasons prior to sending an IP packet to the peer's 1176 new locator; one is the return routability (check if the peer is 1177 actually willing to receive data with the specified locator) and 1178 the other one is the verification based on crypto identifier 1179 mechanisms [RFC3972], [RFC5535]. 1181 6. Ancillary Data for Multihoming Shim Sub-layer 1183 This section provides definitions of ancillary data to be used for 1184 locator management and notification from/to the shim sub-layer to/ 1185 from application. 1187 When the application performs locator management by sendmsg() or 1188 recvmsg(), a member of the msghdr structure (given in Figure 3) 1189 called msg_control holds a pointer to the buffer in which one ore 1190 more shim specific ancillary data objects may be stored. An 1191 ancillary data object can store a single locator. It should be 1192 possible to process the shim specific ancillary data object by the 1193 existing macros defined in the Posix standard and [RFC3542]. 1195 struct msghdr { 1196 caddr_t msg_name; /* optional address */ 1197 u_int msg_namelen; /* size of address */ 1198 struct iovec *msg_iov; /* scatter/gather array */ 1199 u_int msg_iovlen; /* # elements in msg_iov */ 1200 caddr_t msg_control; /* ancillary data, see below */ 1201 u_int msg_controllen; /* ancillary data buffer len */ 1202 int msg_flags; /* flags on received message */ 1203 }; 1205 Figure 3: msghdr structure 1207 In the case of unconnected socket, msg_name stores the socket address 1208 of the peer which should be considered to be an identifier rather 1209 than a locator. SHIM_LOC_PEER_RECV should be used to get the locator 1210 of the peer node. 1212 Table 2 is a list of the shim specific ancillary data which can be 1213 used for locator management by recvmsg() or sendmsg(). In any case, 1214 the value of cmsg_level must be set as SOL_SHIM. 1216 +---------------------+-----------+-----------+-----------------+ 1217 | cmsg_type | sendmsg() | recvmsg() | cmsg_data[] | 1218 +---------------------+-----------+-----------+-----------------+ 1219 | SHIM_LOC_LOCAL_RECV | | o | *1 | 1220 | SHIM_LOC_PEER_RECV | | o | *1 | 1221 | SHIM_LOC_LOCAL_SEND | o | | *1 | 1222 | SHIM_LOC_PEER_SEND | o | | *1 | 1223 | SHIM_FEEDBACK | o | | shim_feedback{} | 1224 +---------------------+-----------+-----------+-----------------+ 1226 Table 2: Shim specific ancillary data 1228 *1: cmsg_data[] includes a single sockaddr_in{} or sockaddr_in6{} and 1229 padding if necessary 1231 6.1. Get Locator from Incoming Packet 1233 An application can get locator information from the received IP 1234 packet by specifying the shim specific socket options for the socket. 1235 When SHIM_LOC_LOCAL_RECV and/or SHIM_LOC_PEER_RECV socket options are 1236 set, the application can retrieve local and/or remote locator from 1237 the ancillary data. 1239 When there is no shim context associated with the socket, the shim 1240 sub-layer MUST return zero-filled locator information to the 1241 application. 1243 6.2. Set Locator for Outgoing Packet 1245 An application can specify the locators to be used for transmitting 1246 an IP packet by sendmsg(). When the ancillary data of cmsg_type 1247 SHIM_LOC_LOCAL_SEND and/or SHIM_LOC_PEER_SEND are specified, the 1248 application can explicitly specify the source and/or the destination 1249 locators to be used for the communication over the socket. If the 1250 specified locator pair is verified, the shim sub-layer overrides the 1251 locator(s) of the outgoing IP packet. Note that the effect is 1252 limited to the datagram transmitted by the sendmsg(). 1254 When there is no shim context associated with the socket, an error 1255 code ENOENT is returned to the application. 1257 An error code EINVALIDLOCATOR is returned when validation of the 1258 specified locator fails. 1260 6.3. Notification from Application to Multihoming Shim Sub-layer 1262 An application may provide feedbacks to the shim sub-layer about the 1263 communication status. Such feedbacks are particularly useful for the 1264 shim sub-layer in the absence of REAP mechanism to monitor the 1265 reachability status of the currently used locator pair in a given 1266 shim context. 1268 The notification can be made by sendmsg() specifying a new ancillary 1269 data called SHIM_FEEDBACK. The ancillary data can be handled by 1270 specifying SHIM_FEEDBACK option in cmsg_type. 1272 When there is no shim context associated with the socket, an error 1273 code ENOENT is returned to the application. 1275 See Section 7.3 for details of the data structure to be used. 1277 It is outside the scope of this document how the shim sub-layer would 1278 react when a feedback is provided by an application. 1280 6.4. Applicability 1282 All the ancillary data for the shim sub-layer is applicable to 1283 connected sockets. 1285 Care is needed when the SHIM_LOC_*_RECV socket option is used for 1286 stream-oriented sockets (e.g., TCP sockets) because there is no one- 1287 to-one mapping between a single send or receive operation and the 1288 data (e.g., a TCP segment) being received. In other words, there is 1289 no gurantee that the locator(s) set in the SHIM_LOC_*_RECV ancillary 1290 data is identical to the locator(s) that appear in the IP packets 1291 received. The shim sub-layer SHOULD provide the latest locator 1292 information to the application in response to the SHIM_LOC_*_RECV 1293 socket option. 1295 7. Data Structures 1297 This section data structures for the shim sub-layer. These data 1298 structures are either used as a parameter for setsockopt() or 1299 getsockopt() (as mentioned in Section 5) or as a parameter for 1300 ancillary data to be processed by sendmsg() or recvmsg() (as 1301 mentioned in Section 6). 1303 7.1. Placeholder for Locator Information 1305 As defined in Section 5, the SHIM_LOC_*_PREF, SHIM_LOC_*_SEND, and 1306 SHIM_LOCLIST_* socket options need to handle one or more locator 1307 information. Locator information includes not only the locator 1308 itself but also additional information about the locator which is 1309 useful for locator management. A new data structure is defined to 1310 serve as a placeholder for the locator information. 1312 Figure 4 illustrates the data structure called shim_locator which 1313 stores a locator information. 1315 struct shim_locator { 1316 uint8_t lc_family; /* address family */ 1317 uint8_t lc_proto; /* protocol */ 1318 uint16_t lc_port; /* port number */ 1319 uint16_t lc_prio; /* preference value */ 1320 uint16_t lc_weight; /* weight */ 1321 uint32_t lc_ifidx; /* interface index */ 1322 struct in6_addr lc_addr; /* address */ 1323 uint16_t lc_flags; /* flags */ 1324 }; 1326 Figure 4: shim locator structure 1328 lc_family 1329 Address family of the locator (e.g. AF_INET, AF_INET6). It is 1330 required that the parameter contains non-zero value indicating the 1331 exact address family of the locator. 1333 lc_proto 1334 Internet Protocol number for the protocol which is used to handle 1335 locator behind NAT. Typically, this value is set as UDP (17) when 1336 the locator is a UDP encapsulation interface. 1337 lc_port 1338 Port number which is used for handling locator behind NAT. 1339 lc_prio 1340 The priority of the locator. The range is 0-65535. The lowest 1341 priority value means the highest priority. 1342 lc_weight 1343 The weight value indicates a relative weight for locators with the 1344 same priority value. The range is 0-65535. 1345 lc_ifidx 1346 Interface index of the network interface to which the locator is 1347 assigned. This field should be valid only in a read 1348 (getsockopt()) operation. 1349 lc_addr 1350 Contains the locator. In the case where a locator whose size is 1351 smaller than 16 bytes, an encoding rule should be provided for 1352 each locator of a given address family. For instance, in case of 1353 AF_INET (IPv4), the locator should be in the format of an IPv4- 1354 mapped IPv6 address as defined in [RFC4291]. 1355 lc_flags 1356 Each bit of the flags represents a specific characteristics of the 1357 locator. Hash Based Address (HBA) is defined as 0x01. 1358 Cryptographically Generated Address (CGA) is defined as 0x02. 1360 7.1.1. Handling Locator behind NAT 1362 Note that the locator information MAY contain a locator behind a 1363 Network Address Translator (NAT). Such a situation may arise when 1364 the host is behind the NAT and uses a local address as a source 1365 locator to communicate with the peer. Note that a NAT traversal 1366 mechanism for HIP is defined, which allows HIP host to tunnel control 1367 and data traffic over UDP[I-D.ietf-hip-nat-traversal]. Note also 1368 that the locator behind NAT is not necessarily an IPv4 address but it 1369 can be an IPv6 address. Below is an example where the application 1370 sets a UDP encapsulation interface as a source locator when sending 1371 IP packets. 1373 struct shim_locator locator; 1374 struct in6_addr ia6; 1376 /* copy the private IPv4 address to the ia6 as an IPv4-mapped 1377 IPv6 address */ 1379 memset(&locator, 0, sizeof(locator)); 1381 /* fill shim_locator data structure */ 1382 locator.lc_family = AF_INET; 1383 locator.lc_proto = IPPROTO_UDP; 1384 locator.lc_port = 50500; 1385 locator.lc_flags = 0; 1386 locator.lc_prio = 0; 1387 locator.lc_weight = 0; 1388 locator.lc_ifidx = 3; 1390 memcpy(&locator.lc_addr, &ia6, sizeof(ia6)); 1392 setsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_SEND, &locator, 1393 sizeof(locator)); 1395 Figure 5: Handling locator behind NAT 1397 7.2. Path Exploration Parameter 1399 As defined in Section 5, SHIM_PATHEXPLORE allows application to set 1400 or read the parameters for path exploration and failure detection. A 1401 new data structure called shim_pathexplore is defined to store the 1402 necessary parameters. Figure 6 illustrates the data structure. The 1403 data structure can be passed to getsockopt() or setsockopt() as an 1404 argument. 1406 struct shim_pathexplore { 1407 uint8_t pe_probenum; /* # of initial probe */ 1408 uint8_t pe_keepaliveto; /* Keepalive Timeout */ 1409 uint16_t pe_initprobeto; /* Initial Probe Timeout */ 1410 uint32_t pe_reserved; /* reserved */ 1411 }; 1413 Figure 6: path explore structure 1415 pe_probenum 1416 Indicates the number of initial probe messages to be sent. 1417 Default value of this parameter should follow what is specified in 1418 [RFC5534]. 1420 pe_keepaliveto 1421 Indicates timeout value for detecting a failure when the host does 1422 not receive any packets for a certain period of time while there 1423 is outbound traffic. When the timer expires, path exploration 1424 procedure will be carried out by sending a REAP Probe message. 1425 Default value of this parameter should follow what is specified in 1426 [RFC5534]. 1427 pe_initprobeto 1428 Indicates retransmission timer of REAP Probe message in 1429 milliseconds. Note that this timer is applied before exponential 1430 back-off is started. A REAP Probe message for the same locator 1431 pair may be retransmitted. Default value of this parameter should 1432 follow what is specified in [RFC5534]. 1433 pe_reserved 1434 A reserved field for future extension. By default, the field 1435 should be initialized to zero. 1437 7.3. Feedback Information 1439 As mentioned in Section 6.3, applications can inform the shim sub- 1440 layer about the status of unicast reachability of the locator pair 1441 currently in use. The feedback information can be handled by using 1442 ancillary data called SHIM_FEEDBACK. A new data structure named 1443 shim_feedback is illustrated in Figure 7. 1445 struct shim_feedback { 1446 uint8_t fb_direction; /* direction of traffic */ 1447 uint8_t fb_indicator; /* indicator (1-3) */ 1448 uint16_t fb_reserved; /* reserved */ 1449 }; 1451 Figure 7: feedback information structure 1453 direction 1454 Indicates direction of reachability between a locator pair in 1455 question. A value 0 indicates outbound and a value 1 indicates 1456 inbound direction. 1457 indicator 1458 A value indicating the degree of satisfaction of a unidirectional 1459 reachability for a given locator pair. 1460 * 0: Default value. Whenever this value is specified the 1461 feedback information must not be processed by the shim sub- 1462 layer. 1463 * 1: Unable to connect. There is no unidirectional reachability 1464 between the locator pair in question. 1465 * 2: Unsatisfactory. The application is not satisfied with the 1466 unidirectional reachability between the locator pair in 1467 question. 1469 * 3: Satisfactory. There is satisfactory unidirectional 1470 reachability between the locator pair in question. 1471 reserved 1472 Reserved field. Must be ignored by the receiver. 1474 8. System Requirements 1476 As addressed in Section 5, most of the socket options and ancillary 1477 data defined in this document are applicable to connected sockets. 1478 It is assumed that the kernel is capable of maintaining the 1479 association between a connected socket and a shim context. This 1480 requirement is considered to be reasonable because a pair of source 1481 and destination IP addresses is bound to a connected socket. 1483 9. Relation to Existing Sockets API Extensions 1485 This section explains relation between the sockets API defined in 1486 this document and the existing sockets API extensions. 1488 As mentioned in Section 5, the basic assumption is that the existing 1489 sockets API continues to work above the shim sub-layer. This means 1490 that, the existing sockets API deals with identifiers, and the 1491 sockets API defined in this document deals with locators. 1493 SHIM_LOC_LOCAL_SEND and SHIM_LOC_PEER_SEND socket options are 1494 semantically similar to the IPV6_PKTINFO socket API in the sense that 1495 both provide a means for application to set the source IP address of 1496 outbound IP packets. 1498 SHIM_LOC_LOCAL_RECV and SHIM_LOC_PEER_RECV socket options are 1499 semantically similar to the IP_RECVDSTADDR and IPV6_PKTINFO socket 1500 APIs in the sense that both provides a means for application to get 1501 the source and/or destination IP address of inbound IP packets. 1503 getsockname() and getpeername() enable application to get 'name' of 1504 the communication endpoints which is represented by a pair of IP 1505 address and port number assigned to the socket. getsockname() gives 1506 IP address and port number assigned to the socket on the local side, 1507 and getpeername() gives IP address and port number of the peer side. 1509 10. Operational Considerations 1511 This section gives operational considerations of the sockets API 1512 defined in this document. 1514 10.1. Conflict Resolution 1516 There may be a conflicting situation when different applications 1517 specify difference preference for the same shim context. For 1518 instance, application A and B may establish communication with the 1519 same EID pair while both applications have different preference in 1520 their choice of local locator. The notion of context forking in 1521 SHIM6 can resolve the conflicting situation. 1523 Socket options defined in Section 5 may cause conflicting situation 1524 when the target context is shared by multiple applications. In such 1525 a case, the socket handler should inform the shim sub-layer that 1526 context forking is required. In SHIM6, when a context is forked, an 1527 unique identifier called Forked Instance Identifier (FII) is assigned 1528 to the newly forked context. The forked context is then exclusively 1529 associated with the socket through which non-default preference value 1530 was specified. The forked context is maintained by the shim sub- 1531 layer during the lifetime of associated socket instance. When the 1532 socket is closed, the shim sub-layer SHOULD delete associated 1533 context. 1535 When the application specifies SHIM_LOC_*_SEND specifying a different 1536 source or destination locator which does not have the highest 1537 priority and weight specified by the SHIM_LOC_*_PREF, the shim sub- 1538 layer SHOULD supersede the request made by SHIM_LOC_*_SEND over the 1539 preference specified by SHIM_LOC_*_PREF. 1541 When the peer provides preferences of the locators (e.g., a SHIM6 1542 peer may send a locator with a Locator Preferences Option) which 1543 conflict with preference specified by the applications either by 1544 SHIM_LOC_PEER_SEND or SHIM_LOC_PEER_PREF, the shim sub-layer SHOULD 1545 supersede the preference made by the application over the preference 1546 specified by the peer. 1548 10.2. Incompatiblility between IPv4 and IPv6 1550 The shim sub-layer performs identifier/locator adaptation. 1551 Therefore, in some cases, the whole IP header can be replaced with 1552 new IP header of a different address family (e.g. conversion from 1553 IPv4 to IPv6 or vice versa). Hence, there is an issue how to make 1554 the conversion with minimum impact. Note that this issue is common 1555 in other protocol conversion techniques 1556 [RFC2765][I-D.ietf-behave-v6v4-xlate]. 1558 As studied in the previous works on protocol 1559 conversion[RFC2765][I-D.ietf-behave-v6v4-xlate], some of the features 1560 (IPv6 routing headers, hop-by-hop extension headers, and destination 1561 headers) from IPv6 are not convertible to IPv4. In addition, notion 1562 of source routing is not exactly the same in IPv4 and IPv6. This 1563 means that an error may occur during the conversion of identifier and 1564 locator. It is ffs exactly how the shim sub-layer should behave in 1565 such erroneous cases. 1567 11. IANA Considerations 1569 This document contains no IANA consideration. 1571 12. Protocol Constants and Variables 1573 This section defines protocol constants and variables. 1574 SHIM_MAX_LOCATORS The maximum number of the locators to be included 1575 in a locator list. 32. 1577 13. Security Considerations 1579 This section gives security considerations of the API defined in this 1580 document. 1582 13.1. Treatment of Unknown Locator 1584 When sending IP packets, application may request use of unknown 1585 locator for the source and/or destination locators. Note that 1586 treatment of unknown locator can be a subject of security 1587 considerations because use of invalid source and/or destination 1588 locator may cause redirection attack. 1590 13.1.1. Treatment of Unknown Source Locator 1592 The shim sub-layer checks if the requested locator is available on 1593 any of the local interface. If not, the shim sub-layer MUST reject 1594 the request and return an error message with the EINVALIDLOCATOR code 1595 to the application. If the locator is confirmed to be available, the 1596 shim sub-layer SHOULD initiate the procedure to update the locator 1597 list. 1599 Use of the following socket options and ancillary data may require 1600 treatment of unknown source locator: 1601 o SHIM_LOC_LOCAL_SEND 1602 o SHIM_LOC_LOCAL_PREF 1603 o SHIM_LOCLIST_LOCAL 1605 13.1.2. Treatment of Unknown Destination Locator 1607 If the shim sub-layer turns out to be SHIM6, the SHIM6 implementation 1608 MUST reject the request for using unknown destination locator. 1610 If the shim sub-layer turns out to be HIP, the HIP implementation MAY 1611 accept the request for using unknown destination locator. 1613 Use of the following socket options and ancillary data may require 1614 treatment of unknown destination locator: 1615 o SHIM_LOC_PEER_SEND 1616 o SHIM_LOC_PEER_PREF 1617 o SHIM_LOCLIST_PEER 1619 14. Changes 1621 14.1. Changes from version 00 to version 01 1623 o Define shim_locator{} data type which is a placeholder for 1624 locator. 1625 o Define shim_pathexplore{} data type in which a set of REAP 1626 parameters are stored. 1627 o Remove descriptions about "stickiness" of socket options. 1628 o Deprecate SHIM_IF_RECV and SHIM_IF_SEND socket options. 1629 o Give default value and how to disable given socket option. 1631 14.2. Changes from version 01 to version 02 1633 o Add section describing context forking. 1634 o Rephrase conclusion section. 1635 o Separate normative references from informative references. 1636 o Remove texts from discussion section that are not relevant to the 1637 contents of the document. 1638 o Add section describing change history (this section). 1640 14.3. Changes from version 02 to version 03 1642 o Add an Appendix section describing the issue of context forking. 1644 14.4. Changes from version 03 to version 04 1646 o Updated reference. 1647 o Correct typo and grammatical errors. 1649 14.5. Changes from version 04 to version 05 1651 o Added definition of SHIM_FEEDBACK ancillary data. 1652 o Added an example of code using the SHIM_LOCLIST_LOCAL 1653 o Added SHIM_LOC_LOCAL_SEND and SHIM_LOC_PEER_SEND socket options. 1655 14.6. Changes from version 05 to version 06 1657 o Updated references. 1659 14.7. Changes from version 06 to version 07 1661 o Resolved editorial issues. 1663 14.8. Changes from version 07 to version 08 1665 No changes are made except for updates of the references. 1667 14.9. Changes from version 08 to version 09 1669 o Updated texts for Section 1 and Section 5 according to the 1670 comments provided by Samu Varjonen. 1671 o Made it clear that downgrading the multihoming shim support (i.e., 1672 specifying value 1 with the SHIM_DONTSHIM socket option) is only 1673 allowed before the socket is connected. 1674 o Updated locator information (shim_locator{}) so that it can 1675 contain a locator behind NAT. 1677 14.10. Changes from version 09 to version 10 1679 o Addressed applicability of socket options and ancillary data for 1680 the shim sub-layer. 1681 o Addressed system requirements. 1682 o Removed unnecessary description about deprecated socket option 1683 (SHIM_IF_RECV). 1685 14.11. Changes from version 10 to version 11 1687 o Added short descriptions about connected sockets and unconnected 1688 sockets. 1689 o Relaxed applicability of the socket options. 1690 o Relaxed applicability of the ancillary data. 1691 o Added notification about locator change. 1693 14.12. Changes from version 11 to version 12 1694 o Reflected comments from Brian Karpenter. 1695 o Reflected comments from Michael Scharf. 1697 14.13. Changes from version 12 to version 13 1699 o Reflected comments from Sebastien Barre. 1700 o Removed the description about the notification from the shim sub- 1701 layer to applications. 1702 o Narrowed down the scope of the applicability of the socket options 1703 and the ancillary data. 1705 15. Acknowledgments 1707 Authors would like to thank Jari Arkko who participated in the 1708 discussion that lead to the first version of this document, and 1709 Tatuya Jinmei who thoroughly reviewed the early version of this draft 1710 and provided detailed comments on sockets API related issues. Thomas 1711 Henderson provided valuable comments especially from HIP 1712 perspectives. 1714 Authors sincerely thank to the following people for their helpful 1715 comments to the document: Samu Varjonen, Dmitriy Kuptsov, Brian 1716 Carpenter, Michael Scharf, and Sebastien Barre 1718 16. References 1720 16.1. Normative References 1722 [POSIX] "IEEE Std. 1003.1-2001 Standard for Information Technology 1723 -- Portable Operating System Interface (POSIX). Open group 1724 Technical Standard: Base Specifications, Issue 6, 1725 http://www.opengroup.org/austin", December 2001. 1727 [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, 1728 "Advanced Sockets Application Program Interface (API) for 1729 IPv6", RFC 3542, May 2003. 1731 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 1732 (HIP) Architecture", RFC 4423, May 2006. 1734 [RFC5533] Bagnulo, M. and E. Nordmark, "Level 3 multihoming shim 1735 protocol", RFC 5533, June 2009. 1737 [RFC5534] Arkko, J. and I. Beijnum, "Failure Detection and Locator 1738 Pair Exploration Protocol for IPv6 Multihoming", RFC 5534, 1739 June 2009. 1741 16.2. Informative References 1743 [I-D.ietf-behave-v6v4-xlate] 1744 Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 1745 Algorithm", draft-ietf-behave-v6v4-xlate-05 (work in 1746 progress), December 2009. 1748 [I-D.ietf-hip-nat-traversal] 1749 Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. 1750 Keranen, "Basic HIP Extensions for Traversal of Network 1751 Address Translators", Internet 1752 Draft draft-ietf-hip-nat-traversal-09, October 2009. 1754 [I-D.ietf-shim6-app-refer] 1755 Nordmark, E., "Shim6 Application Referral Issues", 1756 draft-ietf-shim6-app-refer-00 (work in progress), 1757 July 2005. 1759 [I-D.ietf-shim6-applicability] 1760 Abley, J., Bagnulo, M., and A. Garcia-Martinez, 1761 "Applicability Statement for the Level 3 Multihoming Shim 1762 Protocol (Shim6)", draft-ietf-shim6-applicability-04 (work 1763 in progress), November 2009. 1765 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 1766 (SIIT)", RFC 2765, February 2000. 1768 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1769 specifying the location of services (DNS SRV)", RFC 2782, 1770 February 2000. 1772 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1773 RFC 3972, March 2005. 1775 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1776 Architecture", RFC 4291, February 2006. 1778 [RFC5535] Bagnulo, M., "Hash Based Addresses (HBA)", RFC 5535, 1779 June 2009. 1781 Appendix A. Context Forking 1783 In this section, an issue concerning context forking and its relation 1784 to the multihoming shim API are discussed. 1786 SHIM6 supports a notion of context forking. A peer may decide to 1787 fork a context for certain reason (e.g. upper layer protocol prefers 1788 to use different locator pair than the one defined in available 1789 context). The procedure of forking context is done similar to the 1790 normal context establishment, performing the 4-way message exchange. 1791 A peer who has decided to fork a context initiates the context 1792 establishment. Hereafter, we call this peer the "initiator". The 1793 peer of the initiator is called the "responder". 1795 Once the forked context is established between the peers, on the 1796 initiator side, it is possible to apply forked context to the packet 1797 flow since the system maintains an association between the forked 1798 context and the socket owned by the application that has requested 1799 the context forking. How this association is maintained is an 1800 implementation specific issue. However, on the responder side, there 1801 is a question how the outbound packet can be multiplexed by the shim 1802 sub-layer because there are more than one SHIM6 contexts that match 1803 with the ULID pair of the packet flow. There is a need to 1804 differentiate packet flows not only by the ULID pairs but by some 1805 other information and associate a given packet flow with a specific 1806 context. 1808 Figure 8 gives an example of a scenario where two communicating peers 1809 fork a context. Initially, there has been a single transaction 1810 between the peers, by the application 1 (App1). Accordingly, another 1811 transaction is started, by application 2 (App2). Both of the 1812 transactions are made based on the same ULID pair. The first context 1813 pair (Ctx1) is established for the transaction of App1. Given the 1814 requests from App2, the shim sub-layer on Peer 1 decides to fork a 1815 context. Accordingly, a forked context (Ctx2) is established between 1816 the peers, which should be exclusively applied to the transaction of 1817 App2. Ideally, multiplexing and demultiplexing of packet flows that 1818 relate to App1 and App2 should be done as illustrated in Figure 8. 1819 However, as mentioned earlier, the responder needs to multiplex 1820 outbound flows of App1 and App2 somehow. Note that if a context 1821 forking occurs on the initiator side, a context forking needs to 1822 occur also on the responder side. 1824 Peer 1 Peer 2 1825 (initiator) (responder) 1827 +----+ +----+ +----+ +----+ 1828 |App1| |App2| |App1| |App2| 1829 +----+ +----+ +----+ +----+ 1830 |^ |^ ^| ^| 1831 v| v| |v |v 1832 -----S1-------------S2----- -----S1-------------S2----- 1833 || || || || 1834 || || || || 1836 Ctx1 Ctx2 Ctx1 Ctx2 1837 ULID: ULID: ULID: ULID: 1838 Loc: Loc: Loc: Loc: 1839 FII: 0 FII: 100 FII: 0 FII: 100 1841 |^ |^ ^| ^| 1842 || || || || 1843 || || || || 1844 \..............||....................../| || 1845 \.............||......................./ || 1846 || || 1847 \|...................................../| 1848 \....................................../ 1850 Figure 8: context forking 1852 Any solution is needed to overcome the problem mentioned above. 1854 Authors' Addresses 1856 Miika Komu 1857 Helsinki Institute for Information Technology 1858 Tammasaarenkatu 3 1859 Helsinki 1860 Finland 1862 Phone: +358503841531 1863 Fax: +35896949768 1864 Email: miika@iki.fi 1865 URI: http://www.hiit.fi/ 1866 Marcelo Bagnulo 1867 Universidad Carlos III de Madrid 1868 Av. Universidad 30 1869 Leganes 28911 1870 SPAIN 1872 Phone: +34 91 6248837 1873 Email: marcelo@it.uc3m.es 1874 URI: http://it.uc3m.es/marcelo 1876 Kristian Slavov 1877 Ericsson Research Nomadiclab 1878 Hirsalantie 11 1879 Jorvas FI-02420 1880 Finland 1882 Phone: +358 9 299 3286 1883 Email: kristian.slavov@ericsson.com 1885 Shinta Sugimoto (editor) 1886 Nippon Ericsson K.K. 1887 Koraku Mori Building 1888 1-4-14, Koraku, Bunkyo-ku 1889 Tokyo 112-0004 1890 Japan 1892 Phone: +81 3 3830 2241 1893 Email: shinta@sfc.wide.ad.jp