idnits 2.17.1 draft-ietf-shim6-multihome-shim-api-14.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 590: '...ltihoming shim support MUST be made by...' RFC 2119 keyword, line 593: '... EOPNOTSUPP MUST be returned....' RFC 2119 keyword, line 1241: '... sub-layer MUST return zero-filled l...' RFC 2119 keyword, line 1292: '...e shim sub-layer SHOULD provide the la...' RFC 2119 keyword, line 1363: '...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 1198 has weird spacing: '... u_int msg_...' == Line 1199 has weird spacing: '... struct iovec...' == Line 1200 has weird spacing: '... u_int msg_...' == Line 1202 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 (August 19, 2010) is 4999 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 973 -- Looks like a reference, but probably isn't: '1' on line 984 ** Obsolete normative reference: RFC 4423 (Obsoleted by RFC 9063) == Outdated reference: A later version (-23) exists of draft-ietf-behave-v6v4-xlate-21 == Outdated reference: A later version (-08) exists of draft-ietf-shim6-applicability-05 -- 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: February 20, 2011 UC3M 6 K. Slavov 7 S. Sugimoto, Ed. 8 Ericsson 9 August 19, 2010 11 Socket Application Program Interface (API) for Multihoming Shim 12 draft-ietf-shim6-multihome-shim-api-14 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 February 20, 2011. 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 14.14. Changes from version 13 to version 14 . . . . . . . . . . 38 125 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38 126 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 127 16.1. Normative References . . . . . . . . . . . . . . . . . . 38 128 16.2. Informative References . . . . . . . . . . . . . . . . . 39 129 Appendix A. Context Forking . . . . . . . . . . . . . . . . . . . 40 130 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 132 1. Introduction 134 This document defines socket API extensions by which upper layer 135 protocols may be informed about and control the way in which a 136 multihoming shim sub-layer in the IP layer manages the dynamic choice 137 of locators. Initially it applies to SHIM6 and HIP, but it is 138 defined generically. 140 The role of the multihoming shim sub-layer (hereafter called "shim 141 sub-layer" in this document) is to avoid impacts to upper layer 142 protocols which may be caused when the endhost changes its attachment 143 point to the Internet, for instance, in the case of rehoming event 144 under the multihomed environment. The key design of the shim sub- 145 layer is to treat identifier and locator separately. Identifiers are 146 presented to upper layer protocols and used as communication 147 endpoints. Locators represent toplogical location of endhosts and 148 are used to route packet from the source to the destiantion. The 149 shim sub-layer maintains mapping of identifiers and locators. 151 Note that the shim sub-layer may conflict with other multihoming 152 mechanisms such as SCTP and multipath 153 TCP[I-D.ietf-shim6-applicability]. To avoid any conflict, only one 154 of SHIM6 and HIP should be in use. 156 In this document, syntax and semantics of the API are given in the 157 same way as the Posix standard [POSIX]. The API specifies how to use 158 ancillary data (aka cmsg) to access the locator information with 159 recvmsg() and/or sendmsg() I/O calls. The API is described in C 160 language and data types are defined in the Posix format; intN_t means 161 a signed integer of exactly N bits (e.g. int16_t) and uintN_t means 162 an unsigned integer of exactly N bits (e.g. uint32_t). 164 The distinction between "connected" sockets and "unconnected" sockets 165 is important when discussing the applicability of the socket API 166 defined in this document. A connected socket is bound to a given 167 peer, whereas an unconnected socket is not bound to any specific 168 peers. A TCP socket becomes a connected socket when the TCP 169 connection establishment is completed. UDP sockets are unconnected, 170 unless the application uses the connect() system call. 172 The target readers of this document are application programmers who 173 develop application software which may benefit greatly from 174 multihomed environments. In addition, this document aims to provide 175 necessary information for developers of shim protocols to implement 176 API for enabling advanced locator management. 178 2. Terminology 180 This section provides terminology used in this document. Basically 181 most of the terms used in this document are taken from the following 182 documents: 184 o SHIM6 Protocol Specification[RFC5533] 185 o HIP Architecture[RFC4423] 186 o Reachability Protocol (REAP)[RFC5534] 188 In this document, the term "IP" refers to both IPv4 and IPv6, unless 189 the protocol version is specifically mentioned. The following are 190 definitions of terms frequently used in this document: 192 o Endpoint identifier (EID) - The identifier used by the application 193 to specify the endpoint of a given communication. Applications 194 may handle EIDs in various ways such as long-lived connections, 195 callbacks, and referrals[I-D.ietf-shim6-app-refer]. 196 * In the case of SHIM6, an identifier called a ULID serves as an 197 EID. A ULID is chosen from locators available on the host. 198 * In the case of HIP, an identifier called a Host Identifier 199 serves as an EID. A Host Identifier is derived from the public 200 key of a given host. For the sake of backward compatibility 201 with the sockets API, the Host Identifier is represented in a 202 form of hash of public key. 203 * Note that the EID appears in the standard socket API as an 204 address, and does not appear in the extensions defined in this 205 document, which only concern locators. 206 o Locator - The IP address actually used to deliver IP packets. 207 Locators are present in the source and destination fields of the 208 IP header of a packet on the wire. 209 * List of locators - A list of locators associated with an EID. 210 There are two lists of locators stored in a given context. One 211 is associated with the local EID and the other is associated 212 with the remote EID. As defined in [RFC5533], the list of 213 locators associated with an EID 'A' is denoted as Ls(A). 214 * Preferred locator - The (source/destination) locator currently 215 used to send packets within a given context. As defined in 216 [RFC5533], the preferred locator of a host 'A' is denoted as 217 Lp(A). 218 * Unknown locator - Any locator that does not appear in the 219 locator list of the shim context associated with the socket. 220 When there is no shim context associated with the socket, any 221 source and/or destination locator requested by the application 222 is considered to be unknown locator. 223 o Shim - The conceptual sub-layer inside the IP layer which 224 maintains mappings between EIDs and locators. An EID can be 225 associated with more than one locator at a time when the host is 226 multihomed. The term 'shim' does not refer to a specific protocol 227 but refers to the conceptual sub-layer inside the IP layer. 228 o Identifier/locator adaptation - The adaptation performed at the 229 shim sub-layer which may end up re-writing the source and/or 230 destination addresses of an IP packet. In the outbound packet 231 processing, the EID pair is converted to the associated locator 232 pair. In the inbound packet processing, the locator pair is 233 converted to the EID pair. 234 o Context - The state information shared by a given pair of peers, 235 which stores a binding between the EID and associated locators. 236 Contexts are maintained by the shim sub-layer. 237 o Reachability detection - The procedure to check reachability 238 between a given locator pair. 239 o Path - The sequence of routers that an IP packet goes through to 240 reach the destination. 241 o Path exploration - The procedure to explore available paths for a 242 given set of locator pairs. 243 o Outage - The incident that prevents IP packets to flow from the 244 source locator to the destination locator. When there is an 245 outage, it means that there is no reachability between a given 246 locator pair. The outage may be caused by various reasons, such 247 as shortage of network resources, congestion, and human error 248 (faulty operation). 249 o Working address pair - The address pair is considered to be 250 "working" if the packet can safely travel from the source to the 251 destination where the packet contains the first address from the 252 pair as the source address and the second address from the pair as 253 the destination address. If reachability is confirmed in both 254 directions, the address pair is considered to be working bi- 255 directionally. 256 o Reachability protocol (REAP) - The protocol for detecting failure 257 and exploring reachability in a multihomed environment. REAP is 258 defined in [RFC5534]. 260 3. System Overview 262 Figure 1 illustrates the system overview. The shim sub-layer and 263 REAP component exist inside the IP layer. Applications use the 264 sockets API defined in this document to interface with the shim sub- 265 layer and the transport layer for locator management, failure 266 detection, and path exploration. 268 It may also be possible that the shim sub-layer interacts with the 269 transport layer, however, such an interaction is outside the scope of 270 this document. 272 +------------------------+ 273 | Application | 274 +------------------------+ 275 ^ ^ 276 ~~~~~~~~~~~~~|~Socket Interface|~~~~~~~~~~~~~~ 277 | v 278 +-----------|------------------------------+ 279 | | Transport Layer | 280 +-----------|------------------------------+ 281 ^ | 282 +-------------|-----|-------------------------------------+ 283 | v v | 284 | +-----------------------------+ +----------+ | IP 285 | | Shim |<----->| REAP | | Layer 286 | +-----------------------------+ +----------+ | 287 | ^ ^ | 288 +-----------------------|----------------------|----------+ 289 v v 290 +------------------------------------------+ 291 | Link Layer | 292 +------------------------------------------+ 294 Figure 1: System overview 296 4. Requirements 298 The following is a list of requirements from applications: 299 o Turn on/off shim. An application should be able to request to 300 turn on or turn off the multihoming support by the shim layer: 301 * Apply shim. The application should be able to explicitly 302 request the shim sub-layer to apply multihoming support. 303 * Don't apply shim. The application should be able to request 304 the shim sub-layer not to apply the multihoming support but to 305 apply normal IP processing at the IP layer. 306 * Note that this function is also required by other types of 307 multihoming mechanisms such as SCTP and multipath TCP to avoid 308 potential conflict with the shim sub-layer. 309 o Locator management. 310 * It should be possible to set preferred source and/or 311 destination locator within a given context: Lp(local) and/or 312 Lp(remote). 313 * It should be possible to get preferred source and/or 314 destination locator within a given context: Lp(local) and/or 315 Lp(remote). 317 * It should be possible to set a list of source and/or 318 destination locators within a given context: Ls(local) and 319 Ls(remote). 320 * It should be possible to get a list of source and/or 321 destination locators within a given context: Ls(local) and 322 Ls(remote). 323 o Notification from applications to the shim sub-layer about the 324 status of the communication. The notification occurs in an event- 325 based manner. Applications and/or upper layer protocols may 326 provide positive feedbacks or negative feedbacks to the shim sub- 327 layer. Note that these feedbacks are mentioned in [RFC5534]: 328 * Applications and/or upper layer protocols (e.g., TCP) may 329 provide positive feedbacks to the shim sub-layer informing that 330 the communication is going well. 331 * Applications and/or upper layer protocols (e.g., TCP) may 332 provide negative feedbacks to the shim sub-layer informing that 333 the communication status is not satisfactory. TCP may detect a 334 problem when it does not receive any expected ACK message from 335 the peer. The REAP module may be triggered by these negative 336 feedbacks and invoke the path exploration procedure. 337 o Feedback from applications to the shim sub-layer. Applications 338 should be able to inform the shim sub-layer of the timeout values 339 for detecting failures, sending keepalives, and starting the 340 exploration procedure. In particular, applications should be able 341 to suppress keepalives. 342 o Hot-standby. Applications may request the shim sub-layer for the 343 hot-standby capability. This means that, alternative paths are 344 known to be working in advance of a failure detection. In such a 345 case, it is possible for the host to immediately replace the 346 current locator pair with an alternative locator pair. 347 o Eagerness for locator exploration. An application should be able 348 to inform the shim sub-layer of how aggressively it wants the REAP 349 mechanism to perform a path exploration (e.g., by specifying the 350 number of concurrent attempts of discovery of working locator 351 pairs) when an outage occurs on the path between the locator pair 352 in use. 353 o Providing locator information to applications. An application 354 should be able to obtain information about the locator pair which 355 was actually used to send or receive the packet. 356 * For inbound traffic, the application may be interested in the 357 locator pair which was actually used to receive the packet. 358 * For outbound traffic, the application may be interested in the 359 locator pair which was actually used to transmit the packet. 360 In this way, applications may have additional control on the 361 locator management. For example, an application becomes able to 362 verify if its preference for locator is actually applied to the 363 flow or not. 365 o Applications should be able to know if the shim-sublayer supports 366 deferred context setup or not. 367 o An application should be able to know if the communication is now 368 being served by the shim sub-layer or not. 369 o An application should be able to use a common interface to access 370 an IPv4 locator and an IPv6 locator. 372 5. Socket Options for Multihoming Shim Sub-layer 374 In this section, socket options that are specific to the shim sub- 375 layer are defined. 377 Table 1 shows a list of the socket options that are specific to the 378 shim sub-layer. An application may use these socket options for a 379 given socket either by the getsockopt() system call or by the 380 setsockopt() system call. All of these socket options are defined at 381 level SOL_SHIM. 383 The first column of Table 1 gives the name of the option. The second 384 and third columns indicate whether the option can be handled by the 385 getsockopt() system call and/or by the setsockopt() system call. The 386 fourth column provides a brief description of the socket option. The 387 fifth column shows the type of data structure specified along with 388 the socket option. By default, the data structure type is an 389 integer. 391 +-----------------------------+-----+-----+-----------------+-------+ 392 | optname | get | set | description | dtype | 393 +-----------------------------+-----+-----+-----------------+-------+ 394 | SHIM_ASSOCIATED | o | | Get the | int | 395 | | | | parameter which | | 396 | | | | indicates | | 397 | | | | whether the | | 398 | | | | socket is | | 399 | | | | associated with | | 400 | | | | any shim | | 401 | | | | context or not. | | 402 | SHIM_DONTSHIM | o | o | Get or set the | int | 403 | | | | parameter which | | 404 | | | | indicates | | 405 | | | | whether to | | 406 | | | | employ the | | 407 | | | | multihoming | | 408 | | | | support by the | | 409 | | | | shim sub-layer | | 410 | | | | or not. | | 411 | SHIM_HOT_STANDBY | o | o | Get or set the | int | 412 | | | | parameter to | | 413 | | | | request the | | 414 | | | | shim sub-layer | | 415 | | | | to prepare a | | 416 | | | | hot-standby | | 417 | | | | connection. | | 418 | SHIM_LOC_LOCAL_PREF | o | o | Get or set the | *1 | 419 | | | | preferred | | 420 | | | | locator on the | | 421 | | | | local side for | | 422 | | | | the context | | 423 | | | | associated with | | 424 | | | | the socket. | | 425 | SHIM_LOC_PEER_PREF | o | o | Get or set the | *1 | 426 | | | | preferred | | 427 | | | | locator on the | | 428 | | | | remote side for | | 429 | | | | the context | | 430 | | | | associated with | | 431 | | | | the socket. | | 432 | SHIM_LOC_LOCAL_RECV | o | o | Get or set the | int | 433 | | | | parameter which | | 434 | | | | is used to | | 435 | | | | request the | | 436 | | | | shim sub-layer | | 437 | | | | to store the | | 438 | | | | destination | | 439 | | | | locator of the | | 440 | | | | received IP | | 441 | | | | packet. | | 442 | SHIM_LOC_PEER_RECV | o | o | Get or set the | int | 443 | | | | parameter which | | 444 | | | | is used to | | 445 | | | | request the | | 446 | | | | shim sub-layer | | 447 | | | | to store the | | 448 | | | | source locator | | 449 | | | | of the received | | 450 | | | | IP packet. | | 451 | SHIM_LOC_LOCAL_SEND | o | o | Get or set the | *1 | 452 | | | | source locator | | 453 | | | | of outgoing IP | | 454 | | | | packets. | | 455 | SHIM_LOC_PEER_SEND | o | o | Get or set the | *1 | 456 | | | | destination | | 457 | | | | locator of | | 458 | | | | outgoing IP | | 459 | | | | packets. | | 460 | SHIM_LOCLIST_LOCAL | o | o | Get or set the | *2 | 461 | | | | list of | | 462 | | | | locators | | 463 | | | | associated with | | 464 | | | | the local EID. | | 465 | SHIM_LOCLIST_PEER | o | o | Get or set the | *2 | 466 | | | | list of | | 467 | | | | locators | | 468 | | | | associated with | | 469 | | | | the peer's EID. | | 470 | SHIM_APP_TIMEOUT | o | o | Get or set the | int | 471 | | | | timeout value | | 472 | | | | for detecting | | 473 | | | | failure. | | 474 | SHIM_PATHEXPLORE | o | o | Get or set | *3 | 475 | | | | parameters for | | 476 | | | | path | | 477 | | | | exploration and | | 478 | | | | failure | | 479 | | | | detection. | | 480 | SHIM_CONTEXT_DEFERRED_SETUP | o | | Get the | int | 481 | | | | parameter which | | 482 | | | | indicates | | 483 | | | | whether | | 484 | | | | deferred | | 485 | | | | context setup | | 486 | | | | is supported or | | 487 | | | | not. | | 488 +-----------------------------+-----+-----+-----------------+-------+ 490 Table 1: Socket options for multihoming shim sub-layer 492 *1: Pointer to a shim_locator which is defined in Section 7. 494 *2: Pointer to an array of shim_locator. 496 *3: Pointer to a shim_pathexplore which is defined in Section 7. 498 Figure 2 illustrates how the shim specific socket options fit into 499 the system model of socket API. The figure shows that the shim sub- 500 layer and the additional protocol components (IPv4 and IPv6) below 501 the shim sub-layer are new to the system model. As previously 502 mentioned, all the shim specific socket options are defined at the 503 SOL_SHIM level. This design choice brings the following advantages: 505 1. The existing sockets API continue to work at the layer above the 506 shim sub-layer. That is, those legacy API handle IP addresses as 507 identifiers. 508 2. With newly defined socket options for the shim sub-layer, the 509 application obtains additional control of locator management. 510 3. The shim specific socket options can be kept independent from 511 address family (IPPROTO_IP or IPPROTO_IPV6) and transport 512 protocol (IPPROTO_TCP or IPPROTO_UDP). 514 s1 s2 s3 s4 515 | | | | 516 +----------------|--|-------|--|----------------+ 517 | +-------+ +-------+ | 518 | IPPROTO_TCP | TCP | | UDP | | 519 | +-------+ +-------+ | 520 | | \ / | | 521 | | ----- | | 522 | | / \ | | 523 | +------+ +------+ | 524 | IPPROTO_IP | IPv4 | | IPv6 | IPPROTO_IPV6 | 525 | +------+ +------+ | 526 | \ / SOL_SOCKET 527 | +--------\-------/--------+ | 528 | SOL_SHIM | shim | | 529 | +--------/-------\--------+ | 530 | / \ | 531 | +------+ +------+ | 532 | | IPv4 | | IPv6 | | 533 | +------+ +------+ | 534 | | | | 535 +------------------|----------|-----------------+ 536 | | 537 IPv4 IPv6 538 Datagram Datagram 540 Figure 2: System model of sockets API with shim sub-layer 542 5.1. SHIM_ASSOCIATED 544 The SHIM_ASSOCIATED option is used to check whether the socket is 545 associated with any shim context or not. 547 This option is meaningful when the locator information of the 548 received IP packet does not tell whether the identifier/locator 549 adaptation is performed or not. Note that the EID pair and the 550 locator pair may be identical in some cases. 552 This option can be specified by getsockopt(). Thus, the option is 553 read-only and the result (0/1/2) is set in the option value (the 554 fourth argument of getsockopt()). 556 When the application specifies the socket option to an unconnected 557 socket, an error code EOPNOTSUPP is returned to the application. 559 The data type of the option value is an integer. The option value 560 indicates the presence of shim context. A return value 1 means that 561 the socket is associated with a shim context at the shim sub-layer. 562 A return value 0 indicates that there is no shim context associated 563 with the socket. A return value 2 means that it is not known whether 564 the socket is associated with a shim context or not, and this must be 565 returned only when the socket is unconnected. In other words, the 566 returned value must be 0 or 1 when the socket is connected. 568 For example, the option can be used by the application as follows: 570 int optval; 571 int optlen = sizeof(optval); 573 getsockopt(fd, SOL_SHIM, SHIM_ASSOCIATED, &optval, &optlen); 575 5.2. SHIM_DONTSHIM 577 The SHIM_DONTSHIM option is used to request the shim layer not to 578 provide the multihoming support for the communication established 579 over the socket. 581 The data type of the option value is an integer, and it takes 0 or 1. 582 An option value 0 means that the shim sub-layer is employed if 583 available. An option value 1 means that the application does not 584 want the shim sub-layer to provide the multihoming support for the 585 communication established over the socket. 587 Default value is set as 0, which means that the shim sub-layer 588 performs identifier/locator adaptation if available. 590 Any attempt to disable the multihoming shim support MUST be made by 591 the application before the socket is connected. If an application 592 makes such an attempt for a connected-socket, an error code 593 EOPNOTSUPP MUST be returned. 595 For example, an application can request the system not to apply the 596 multihoming support as follows: 598 int optval; 600 optval = 1; 602 setsockopt(fd, SOL_SHIM, SHIM_DONTSHIM, &optval, sizeof(optval)); 604 For example, the application can check the option value as follows: 606 int optval; 607 int len; 609 len = sizeof(optval); 611 getsockopt(fd, SOL_SHIM, SHIM_DONTSHIM, &optval, &len); 613 5.3. SHIM_HOT_STANDBY 615 The SHIM_HOT_STANDBY option is used to control the shim sub-layer 616 whether to employ a hot-standby connection for the socket or not. A 617 hot-standby connection is an alternative working locator pair to the 618 current locator pair. This option is effective only when there is a 619 shim context associated with the socket. 621 The data type of the option value is an integer. 623 The option value can be set by setsockopt(). 625 The option value can be read by getsockopt(). 627 By default, the value is set to 0, meaning that hot-standby 628 connection is disabled. 630 When the application specifies the socket option to an unconnected 631 socket, an error code EOPNOTSUPP is returned to the application. 633 When there is no shim context associated with the socket, an error 634 code ENOENT is returned to the application. 636 For example, an application can request establishment of a hot- 637 standby connection by using the socket option as follows: 639 int optval; 641 optval = 1; 643 setsockopt(fd, SOL_SHIM, SHIM_HOT_STANDBY, &optval, 644 sizeof(optval)); 646 For example, an application can get the option value by using the 647 socket option as follows: 649 int optval; 650 int len; 652 len = sizeof(optval); 654 getsockopt(fd, SOL_SHIM, SHIM_HOT_STANDBY, &optval, &len); 656 5.4. SHIM_LOC_LOCAL_PREF 658 The SHIM_LOC_LOCAL_PREF option is used to get or set preference for a 659 source locator for outbound traffic within a given context. This 660 option is effective only when there is a shim context associated with 661 the socket. 663 The preference of a locator is defined by a combination of priority 664 and weight as per DNS SRV[RFC2782]. Note that the SHIM6 base 665 protocol defines preference of locator in the same way. 667 The data type of the option value is a pointer to a locator 668 information data structure which is defined in Section 7. 670 By default, the option value is set to NULL, meaning that the option 671 is disabled. 673 The preferred locator can be set by setsockopt(). The shim sub-layer 674 shall verify requested locator before it updates the preferred 675 locator. 677 An application can get the preferred locator by getsockopt(). 679 When the application specifies the socket option to an unconnected 680 socket, an error code EOPNOTSUPP is returned to the application. 682 When there is no shim context associated with the socket, an error 683 code ENOENT is returned to the application. 685 An error EINVALIDLOCATOR is returned when the validation of the 686 specified locator fails. 688 For example, an application can set the preferred locator by using 689 the socket option as follows. Note that some members of the 690 shim_locator (lc_ifidx and lc_flags) are ignored in the set 691 operation. 693 struct shim_locator lc; 694 struct in6_addr ip6; 696 /* ...set the locator (ip6)... */ 698 memset(&lc, 0, sizeof(shim_locator)); 699 lc.lc_family = AF_INET6; /* IPv6 */ 700 lc.lc_ifidx = 0; 701 lc.lc_flags = 0; 702 lc.lc_prio = 1; 703 lc.lc_weight = 10; 704 memcpy(&lc.lc_addr, &ip6, sizeof(in6_addr)); 706 setsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_PREF, &lc, 707 sizeof(optval)); 709 For example, an application can get the preferred locator by using 710 the socket option as follows. 712 struct shim_locator lc; 713 int len; 715 len = sizeof(lc); 717 getsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_PREF, &lc, &len); 719 5.5. SHIM_LOC_PEER_PREF 721 The SHIM_LOC_PEER_PREF option is used to get or set preference of a 722 destination locator for outbound traffic within a given context. 723 This option is effective only when there is a shim context associated 724 with the socket. 726 As defined earlier, the preference of a locator is defined by a 727 combination of priority and weight as per DNS SRV[RFC2782]. When 728 there are more than one candidate destination locators, the shim sub- 729 layer makes selection based on the priority and weight specified for 730 each locator. 732 The data type of the option value is a pointer to the locator 733 information data structure which is defined in Section 7. 735 By default, the option value is set to NULL, meaning that the option 736 is disabled. 738 The preferred locator can be set by setsockopt(). The shim sub-layer 739 shall verify requested locator before it updating the preferred 740 locator. 742 An application can get the preferred locator by getsockopt(). 744 When the application specifies the socket option to an unconnected 745 socket, an error code EOPNOTSUPP is returned to the application. 747 When there is no shim context associated with the socket, an error 748 code ENOENT is returned to the application. 750 An error EINVALIDLOCATOR is returned when the validation of the 751 requested locator fails. 753 The usage of the option is same as that of SHIM_LOC_LOCAL_PREF. Note 754 that some members of the shim_locator (lc_ifidx and lc_flags) are 755 ignored in the set operation. 757 5.6. SHIM_LOC_LOCAL_RECV 759 The SHIM_LOC_LOCAL_RECV option can be used to request the shim sub- 760 layer to store the destination locator of the received IP packet in 761 an ancillary data object which can be accessed by recvmsg(). This 762 option is effective only when there is a shim context associated with 763 the socket. 765 The data type of the option value is integer. The option value 766 should be binary (0 or 1). By default, the option value is set to 0, 767 meaning that the option is disabled. 769 An application can set the option value by setsockopt(). 771 An application can get the option value by getsockopt(). 773 See Section 6 for the procedure to access locator information stored 774 in the ancillary data objects. 776 When the application specifies the socket option to an unconnected 777 socket, an error code EOPNOTSUPP is returned to the application. 779 When there is no shim context associated with the socket, an error 780 code ENOENT is returned to the application. 782 For example, an application can request the shim sub-layer to store 783 destination locator by using the socket option as follows. 785 int optval; 787 optval = 1; 789 setsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_RECV, &optval, 790 sizeof(optval)); 792 For example, an application can get the option value as follows. 794 int optval; 795 int len; 797 len = sizeof(optval); 799 getsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_RECV, &optval, &len); 801 5.7. SHIM_LOC_PEER_RECV 803 The SHIM_LOC_PEER_RECV option is used to request the shim sub-layer 804 to store the source locator of the received IP packet in an ancillary 805 data object which can be accessed by recvmsg(). This option is 806 effective only when there is a shim context associated with the 807 socket. 809 The data type of the option value is integer. The option value 810 should be binary (0 or 1). By default, the option value is set to 0, 811 meaning that the option is disabled. 813 The option value can be set by setsockopt(). 815 The option value can be read by getsockopt(). 817 See Section 6 for the procedure to access locator information stored 818 in the ancillary data objects. 820 When the application specifies the socket option to an unconnected 821 socket, an error code EOPNOTSUPP is returned to the application. 823 When there is no shim context associated with the socket, an error 824 code ENOENT is returned to the application. 826 The usage of the option is same as that of SHIM_LOC_LOCAL_RECV 827 option. 829 5.8. SHIM_LOC_LOCAL_SEND 831 The SHIM_LOC_LOCAL_SEND option is used to request the shim sub-layer 832 to use a specific locator as the source locator for the IP packets to 833 be sent from the socket. This option is effective only when there is 834 a shim context associated with the socket. 836 The data type of option value is pointer to shim_locator data 837 structure. 839 An application can set the local locator by setsockopt() providing a 840 valid locator which is stored in a shim_locator data structure. When 841 a zero-filled locator is specified, pre-existing setting of local 842 locator is inactivated. 844 An application can get the local locator by getsockopt(). 846 When the application specifies the socket option to an unconnected 847 socket, an error code EOPNOTSUPP is returned to the application. 849 When there is no shim context associated with the socket, an error 850 code ENOENT is returned to the application. 852 An error EINVALIDLOCATOR is returned when an invalid locator is 853 specified. 855 For example, an application can request the shim sub-layer to use a 856 specific local locator by using the socket option as follows. 858 struct shim_locator locator; 859 struct in6_addr ia6; 861 /* an IPv6 address preferred for the source locator is copied 862 to the parameter ia6 */ 864 memset(&locator, 0, sizeof(locator)); 866 /* fill shim_locator data structure */ 867 locator.lc_family = AF_INET6; 868 locator.lc_ifidx = 1; 869 locator.lc_flags = 0; 870 locator.lc_prio = 0; 871 locator.lc_weight = 0; 872 memcpy(&locator.lc_addr, &ia6, sizeof(ia6)); 874 setsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_SEND, &locator, 875 sizeof(locator)); 877 For example, an application can get the preferred local locator by 878 using the socket option as follows. 880 struct shim_locator locator; 882 memset(&locator, 0, sizeof(locator)); 884 getsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_SEND, &locator, 885 sizeof(locator)); 887 /* check locator */ 889 5.9. SHIM_LOC_PEER_SEND 891 The SHIM_LOC_PEER_SEND option is used to request the shim sub-layer 892 to use a specific locator for the destination locator of IP packets 893 to be sent from the socket. This option is effective only when there 894 is a shim context associated with the socket. 896 The data type of the option value is a pointer to shim_locator data 897 structure. 899 An application can set the remote locator by setsockopt() providing a 900 valid locator which is stored in a shim_locator data structure. When 901 a zero-filled locator is specified, pre-existing setting of remote 902 locator is inactivated. 904 An application can get the specified remote locator by getsockopt(). 906 When the application specifies the socket option to an unconnected 907 socket, an error code EOPNOTSUPP is returned to the application. 909 When there is no shim context associated with the socket, an error 910 code ENOENT is returned to the application. 912 An error EINVALIDLOCATOR when invalid an locator is specified. 914 The usage of the option is the same as that of SHIM_LOC_LOCAL_SEND 915 option. 917 5.10. SHIM_LOCLIST_LOCAL 919 The SHIM_LOCLIST_LOCAL option is used to get or set the locator list 920 associated with the local EID of the shim context associated with the 921 socket. This option is effective only when there is a shim context 922 associated with the socket. 924 The data type of the option value is a pointer to the buffer in which 925 a locator list is stored. See Section 7 for the data structure for 926 storing the locator information. By default, the option value is set 927 to NULL, meaning that the option is disabled. 929 An application can get the locator list by getsockopt(). Note that 930 the size of the buffer pointed to by the optval argument should be 931 large enough to store an array of locator information. The number of 932 the locator information is not known beforehand. 934 The local locator list can be set by setsockopt(). The buffer 935 pointed to by the optval argument should contain an array of locator 936 structures. 938 When the application specifies the socket option to an unconnected 939 socket, an error code EOPNOTSUPP is returned to the application. 941 When there is no shim context associated with the socket, an error 942 code ENOENT is returned to the application. 944 An error EINVALIDLOCATOR is returned when the validation of any of 945 the specified locators failed. 947 An error ETOOMANYLOCATORS is returned when the number of locators 948 specified exceeds the limit (SHIM_MAX_LOCATORS), or when the size of 949 the buffer provided by the application is not large enough to store 950 the locator list provided by the shim sub-layer. 952 For example, an application can set a list of locators to be 953 associated with the local EID by using the socket option as follows: 955 struct shim_locator locators[SHIM_MAX_LOCATORS]; 956 struct sockaddr_in *sin; 957 struct sockaddr_in6 *sin6; 959 memset(locators, 0, sizeof(locators)); 961 ... 963 /* obtain local IP addresses from local interfaces */ 965 ... 967 /* first locator (an IPv6 address) */ 968 locators[0].lc_family = AF_INET6; 969 locators[0].lc_ifidx = 0; 970 locators[0].lc_flags = 0; 971 locators[0].lc_prio = 1; 972 locators[0].lc_weight = 0; 973 memcpy(&locators[0].lc_addr, &sa6->sin6_addr, 974 sizeof(sa6->sin6_addr)); 976 ... 978 /* second locator (an IPv4 address) */ 979 locators[1].lc_family = AF_INET; 980 locators[1].lc_ifidx = 0; 981 locators[1].lc_flags = 0; 982 locators[1].lc_prio = 0; 983 locators[1].lc_weight = 0; 984 memcpy(&locators[1].lc_addr, &sa->sin_addr, 985 sizeof(sa->sin_addr)); 987 setsockopt(fd, SOL_SHIM, SHIM_LOCLIST_LOCAL, locators, 988 sizeof(locators)); 990 For example, an application can get a list of locators that are 991 associated with the local EID by using the socket option as follows. 993 struct shim_locator locators[SHIM_MAX_LOCATORS]; 995 memset(locators, 0, sizeof(locators)); 997 getsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_RECV, locators, 998 sizeof(locators)); 1000 /* parse locators */ 1001 ... 1003 5.11. SHIM_LOCLIST_PEER 1005 The SHIM_LOCLIST_PEER option is used to get or set the locator list 1006 associated with the peer EID of the shim context associated with the 1007 socket. This option is effective only when there is a shim context 1008 associated with the socket. 1010 The data type of the option value is a pointer to the buffer where a 1011 locator list is stored. See Section 7 for the data structure for 1012 storing the locator information. By default, the option value is set 1013 to NULL, meaning that the option is disabled. 1015 An application can get the locator list by getsockopt(). Note that 1016 the size of the buffer pointed to by the optval argument should be 1017 large enough to store an array of locator information. The number of 1018 the locator information is not known beforehand. 1020 An application can set the locator list by setsockopt(). The buffer 1021 pointed to by the optval argument should contain an array of locator 1022 list. 1024 When the application specifies the socket option to an unconnected 1025 socket, an error code EOPNOTSUPP is returned to the application. 1027 When there is no shim context associated with the socket, an error 1028 code ENOENT is returned to the application. 1030 An error EINVALIDLOCATOR is returned when the validation of any of 1031 the specified locators failed. 1033 An error ETOOMANYLOCATORS is returned when the number of locators 1034 specified exceeds the limit (SHIM_MAX_LOCATORS), or when the size of 1035 the buffer provided by the application is not large enough to store 1036 the locator list provided by the shim sub-layer. 1038 The usage of the option is same as that of SHIM_LOCLIST_LOCAL. 1040 5.12. SHIM_APP_TIMEOUT 1042 The SHIM_APP_TIMEOUT option is used to get or set the Send Timeout 1043 value of the REAP protocol. This option is effective only when there 1044 is a shim context associated with the socket. 1046 The data type of the option value is an integer. The value indicates 1047 the period of timeout in seconds to send a REAP Keepalive message 1048 since the last outbound traffic. By default, the option value is set 1049 to 0, meaning that the option is disabled. When the option is 1050 disabled, the REAP mechanism follows its default value of Send 1051 Timeout value as specified in [RFC5534] 1053 When the application specifies the socket option to an unconnected 1054 socket, an error code EOPNOTSUPP is returned to the application. 1056 When there is no shim context associated with the socket, an error 1057 code ENOENT is returned to the application. 1059 For example, an application can set the timeout value by using the 1060 socket option as follows. 1062 int optval; 1064 optval = 15; /* 15 seconds */ 1066 setsockopt(fd, SOL_SHIM, SHIM_APP_TIMEOUT, &optval, 1067 sizeof(optval)); 1069 For example, an application can get the timeout value by using the 1070 socket option as follows. 1072 int optval; 1073 int len; 1075 len = sizeof(optval); 1077 getsockopt(fd, SOL_SHIM, SHIM_APP_TIMEOUT, &optval, &len); 1079 5.13. SHIM_PATHEXPLORE 1081 The application may use this socket option to get or set parameters 1082 concerning path exploration. Path exploration is a procedure to find 1083 an alternative locator pair to the current locator pair. As the REAP 1084 specification defines, a peer may send Probe messages to find an 1085 alternative locator pair. 1087 This option is effective only when there is a shim context associated 1088 with the socket. 1090 The data type of the option value is a pointer to the buffer where a 1091 set of information for path exploration is stored. The data 1092 structure is defined in Section 7. 1094 By default, the option value is set to NULL, meaning that the option 1095 is disabled. 1097 When the application specifies the socket option to an unconnected 1098 socket, an error code EOPNOTSUPP is returned to the application. 1100 When there is no shim context associated with the socket, an error 1101 code ENOENT is returned to the application. 1103 For example, an application can set parameters for path exploration 1104 by using the socket option as follows. 1106 struct shim6_pathexplore pe; 1108 pe.pe_probenum = 4; /* times */ 1109 pe.pe_keepaliveto = 10; /* seconds */ 1110 pe.pe_initprobeto = 500; /* milliseconds */ 1111 pe.pe_reserved = 0; 1113 setsockopt(fd, SOL_SHIM, SHIM_PATHEXPLORE, &pe, sizeof(pe)); 1115 For example, an application can get parameters for path exploration 1116 by using the socket option as follows. 1118 struct shim6_pathexplore pe; 1119 int len; 1121 len = sizeof(pe); 1123 getsockopt(fd, SOL_SHIM, SHIM_PATHEXPLORE, &pe, &len); 1125 5.14. SHIM_DEFERRED_CONTEXT_SETUP 1127 The SHIM_DEFERRED_CONTEXT_SETUP option is used to check whether 1128 deferred context setup is possible or not. Deferred context setup 1129 means that the context is established in parallel with the data 1130 communication. Note that SHIM6 supports deferred context setup and 1131 HIP does not because EIDs in HIP (i.e., Host Identifiers) are non- 1132 routable. 1134 The data type for the option value is an integer. The option value 1135 should be binary (0 or 1). The option value 1 means that the shim 1136 sub-layer supports deferred context setup. 1138 When the application specifies the socket option to an unconnected 1139 socket, an error code EOPNOTSUPP is returned to the application. 1141 For example, an application can check whether deferred context setup 1142 is possible or not as follows: 1144 int optval; 1145 int len; 1147 len = sizeof(optval); 1149 getsockopt(fd, SOL_SHIM, SHIM_DEFERRED_CONTEXT_SETUP, 1150 &optval, &len); 1152 5.15. Applicability 1154 All the socket options defined in this section except for the 1155 SHIM_DONTSHIM option are applicable to applications that use 1156 connected sockets. 1158 All the socket options defined in this section except for the 1159 SHIM_ASSOCIATED, SHIM_DONTSHIM and SHIM_CONTEXT_DEFERRED_SETUP 1160 options are effective only when there is a shim context associated 1161 with the socket. 1163 5.16. Error Handling 1165 If successful, getsockopt() and setsockopt() return 0; otherwise, the 1166 functions return -1 and set errno to indicate an error. 1168 The following are new error values defined for some shim specific 1169 socket options indicating that the getsockopt() or setsockopt() 1170 finished incompletely: 1172 EINVALIDLOCATOR 1173 This indicates that at least one of the necessary validations 1174 inside the shim sub-layer for the specified locator has failed. 1175 In case of SHIM6, there are two kinds of verifications required 1176 for security reasons prior to sending an IP packet to the peer's 1177 new locator; one is the return routability (check if the peer is 1178 actually willing to receive data with the specified locator) and 1179 the other one is the verification based on crypto identifier 1180 mechanisms [RFC3972], [RFC5535]. 1182 6. Ancillary Data for Multihoming Shim Sub-layer 1184 This section provides definitions of ancillary data to be used for 1185 locator management and notification from/to the shim sub-layer to/ 1186 from application. 1188 When the application performs locator management by sendmsg() or 1189 recvmsg(), a member of the msghdr structure (given in Figure 3) 1190 called msg_control holds a pointer to the buffer in which one ore 1191 more shim specific ancillary data objects may be stored. An 1192 ancillary data object can store a single locator. It should be 1193 possible to process the shim specific ancillary data object by the 1194 existing macros defined in the Posix standard and [RFC3542]. 1196 struct msghdr { 1197 caddr_t msg_name; /* optional address */ 1198 u_int msg_namelen; /* size of address */ 1199 struct iovec *msg_iov; /* scatter/gather array */ 1200 u_int msg_iovlen; /* # elements in msg_iov */ 1201 caddr_t msg_control; /* ancillary data, see below */ 1202 u_int msg_controllen; /* ancillary data buffer len */ 1203 int msg_flags; /* flags on received message */ 1204 }; 1206 Figure 3: msghdr structure 1208 In the case of unconnected socket, msg_name stores the socket address 1209 of the peer which should be considered to be an identifier rather 1210 than a locator. SHIM_LOC_PEER_RECV should be used to get the locator 1211 of the peer node. 1213 Table 2 is a list of the shim specific ancillary data which can be 1214 used for locator management by recvmsg() or sendmsg(). In any case, 1215 the value of cmsg_level must be set as SOL_SHIM. 1217 +---------------------+-----------+-----------+-----------------+ 1218 | cmsg_type | sendmsg() | recvmsg() | cmsg_data[] | 1219 +---------------------+-----------+-----------+-----------------+ 1220 | SHIM_LOC_LOCAL_RECV | | o | *1 | 1221 | SHIM_LOC_PEER_RECV | | o | *1 | 1222 | SHIM_LOC_LOCAL_SEND | o | | *1 | 1223 | SHIM_LOC_PEER_SEND | o | | *1 | 1224 | SHIM_FEEDBACK | o | | shim_feedback{} | 1225 +---------------------+-----------+-----------+-----------------+ 1227 Table 2: Shim specific ancillary data 1229 *1: cmsg_data[] includes a single sockaddr_in{} or sockaddr_in6{} and 1230 padding if necessary 1232 6.1. Get Locator from Incoming Packet 1234 An application can get locator information from the received IP 1235 packet by specifying the shim specific socket options for the socket. 1236 When SHIM_LOC_LOCAL_RECV and/or SHIM_LOC_PEER_RECV socket options are 1237 set, the application can retrieve local and/or remote locator from 1238 the ancillary data. 1240 When there is no shim context associated with the socket, the shim 1241 sub-layer MUST return zero-filled locator information to the 1242 application. 1244 6.2. Set Locator for Outgoing Packet 1246 An application can specify the locators to be used for transmitting 1247 an IP packet by sendmsg(). When the ancillary data of cmsg_type 1248 SHIM_LOC_LOCAL_SEND and/or SHIM_LOC_PEER_SEND are specified, the 1249 application can explicitly specify the source and/or the destination 1250 locators to be used for the communication over the socket. If the 1251 specified locator pair is verified, the shim sub-layer overrides the 1252 locator(s) of the outgoing IP packet. Note that the effect is 1253 limited to the datagram transmitted by the sendmsg(). 1255 When there is no shim context associated with the socket, an error 1256 code ENOENT is returned to the application. 1258 An error code EINVALIDLOCATOR is returned when validation of the 1259 specified locator fails. 1261 6.3. Notification from Application to Multihoming Shim Sub-layer 1263 An application may provide feedbacks to the shim sub-layer about the 1264 communication status. Such feedbacks are particularly useful for the 1265 shim sub-layer in the absence of REAP mechanism to monitor the 1266 reachability status of the currently used locator pair in a given 1267 shim context. 1269 The notification can be made by sendmsg() specifying a new ancillary 1270 data called SHIM_FEEDBACK. The ancillary data can be handled by 1271 specifying SHIM_FEEDBACK option in cmsg_type. 1273 When there is no shim context associated with the socket, an error 1274 code ENOENT is returned to the application. 1276 See Section 7.3 for details of the data structure to be used. 1278 It is outside the scope of this document how the shim sub-layer would 1279 react when a feedback is provided by an application. 1281 6.4. Applicability 1283 All the ancillary data for the shim sub-layer is applicable to 1284 connected sockets. 1286 Care is needed when the SHIM_LOC_*_RECV socket option is used for 1287 stream-oriented sockets (e.g., TCP sockets) because there is no one- 1288 to-one mapping between a single send or receive operation and the 1289 data (e.g., a TCP segment) being received. In other words, there is 1290 no gurantee that the locator(s) set in the SHIM_LOC_*_RECV ancillary 1291 data is identical to the locator(s) that appear in the IP packets 1292 received. The shim sub-layer SHOULD provide the latest locator 1293 information to the application in response to the SHIM_LOC_*_RECV 1294 socket option. 1296 7. Data Structures 1298 This section data structures for the shim sub-layer. These data 1299 structures are either used as a parameter for setsockopt() or 1300 getsockopt() (as mentioned in Section 5) or as a parameter for 1301 ancillary data to be processed by sendmsg() or recvmsg() (as 1302 mentioned in Section 6). 1304 7.1. Placeholder for Locator Information 1306 As defined in Section 5, the SHIM_LOC_*_PREF, SHIM_LOC_*_SEND, and 1307 SHIM_LOCLIST_* socket options need to handle one or more locator 1308 information. Locator information includes not only the locator 1309 itself but also additional information about the locator which is 1310 useful for locator management. A new data structure is defined to 1311 serve as a placeholder for the locator information. 1313 Figure 4 illustrates the data structure called shim_locator which 1314 stores a locator information. 1316 struct shim_locator { 1317 uint8_t lc_family; /* address family */ 1318 uint8_t lc_proto; /* protocol */ 1319 uint16_t lc_port; /* port number */ 1320 uint16_t lc_prio; /* preference value */ 1321 uint16_t lc_weight; /* weight */ 1322 uint32_t lc_ifidx; /* interface index */ 1323 struct in6_addr lc_addr; /* address */ 1324 uint16_t lc_flags; /* flags */ 1325 }; 1327 Figure 4: shim locator structure 1329 lc_family 1330 Address family of the locator (e.g. AF_INET, AF_INET6). It is 1331 required that the parameter contains non-zero value indicating the 1332 exact address family of the locator. 1334 lc_proto 1335 Internet Protocol number for the protocol which is used to handle 1336 locator behind NAT. Typically, this value is set as UDP (17) when 1337 the locator is a UDP encapsulation interface. 1338 lc_port 1339 Port number which is used for handling locator behind NAT. 1340 lc_prio 1341 The priority of the locator. The range is 0-65535. The lowest 1342 priority value means the highest priority. 1343 lc_weight 1344 The weight value indicates a relative weight for locators with the 1345 same priority value. The range is 0-65535. 1346 lc_ifidx 1347 Interface index of the network interface to which the locator is 1348 assigned. This field should be valid only in a read 1349 (getsockopt()) operation. 1350 lc_addr 1351 Contains the locator. In the case where a locator whose size is 1352 smaller than 16 bytes, an encoding rule should be provided for 1353 each locator of a given address family. For instance, in case of 1354 AF_INET (IPv4), the locator should be in the format of an IPv4- 1355 mapped IPv6 address as defined in [RFC4291]. 1356 lc_flags 1357 Each bit of the flags represents a specific characteristics of the 1358 locator. Hash Based Address (HBA) is defined as 0x01. 1359 Cryptographically Generated Address (CGA) is defined as 0x02. 1361 7.1.1. Handling Locator behind NAT 1363 Note that the locator information MAY contain a locator behind a 1364 Network Address Translator (NAT). Such a situation may arise when 1365 the host is behind the NAT and uses a local address as a source 1366 locator to communicate with the peer. Note that a NAT traversal 1367 mechanism for HIP is defined, which allows HIP host to tunnel control 1368 and data traffic over UDP[I-D.ietf-hip-nat-traversal]. Note also 1369 that the locator behind NAT is not necessarily an IPv4 address but it 1370 can be an IPv6 address. Below is an example where the application 1371 sets a UDP encapsulation interface as a source locator when sending 1372 IP packets. 1374 struct shim_locator locator; 1375 struct in6_addr ia6; 1377 /* copy the private IPv4 address to the ia6 as an IPv4-mapped 1378 IPv6 address */ 1380 memset(&locator, 0, sizeof(locator)); 1382 /* fill shim_locator data structure */ 1383 locator.lc_family = AF_INET; 1384 locator.lc_proto = IPPROTO_UDP; 1385 locator.lc_port = 50500; 1386 locator.lc_flags = 0; 1387 locator.lc_prio = 0; 1388 locator.lc_weight = 0; 1389 locator.lc_ifidx = 3; 1391 memcpy(&locator.lc_addr, &ia6, sizeof(ia6)); 1393 setsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_SEND, &locator, 1394 sizeof(locator)); 1396 Figure 5: Handling locator behind NAT 1398 7.2. Path Exploration Parameter 1400 As defined in Section 5, SHIM_PATHEXPLORE allows application to set 1401 or read the parameters for path exploration and failure detection. A 1402 new data structure called shim_pathexplore is defined to store the 1403 necessary parameters. Figure 6 illustrates the data structure. The 1404 data structure can be passed to getsockopt() or setsockopt() as an 1405 argument. 1407 struct shim_pathexplore { 1408 uint8_t pe_probenum; /* # of initial probe */ 1409 uint8_t pe_keepaliveto; /* Keepalive Timeout */ 1410 uint16_t pe_initprobeto; /* Initial Probe Timeout */ 1411 uint32_t pe_reserved; /* reserved */ 1412 }; 1414 Figure 6: path explore structure 1416 pe_probenum 1417 Indicates the number of initial probe messages to be sent. 1418 Default value of this parameter should follow what is specified in 1419 [RFC5534]. 1421 pe_keepaliveto 1422 Indicates timeout value for detecting a failure when the host does 1423 not receive any packets for a certain period of time while there 1424 is outbound traffic. When the timer expires, path exploration 1425 procedure will be carried out by sending a REAP Probe message. 1426 Default value of this parameter should follow what is specified in 1427 [RFC5534]. 1428 pe_initprobeto 1429 Indicates retransmission timer of REAP Probe message in 1430 milliseconds. Note that this timer is applied before exponential 1431 back-off is started. A REAP Probe message for the same locator 1432 pair may be retransmitted. Default value of this parameter should 1433 follow what is specified in [RFC5534]. 1434 pe_reserved 1435 A reserved field for future extension. By default, the field 1436 should be initialized to zero. 1438 7.3. Feedback Information 1440 As mentioned in Section 6.3, applications can inform the shim sub- 1441 layer about the status of unicast reachability of the locator pair 1442 currently in use. The feedback information can be handled by using 1443 ancillary data called SHIM_FEEDBACK. A new data structure named 1444 shim_feedback is illustrated in Figure 7. 1446 struct shim_feedback { 1447 uint8_t fb_direction; /* direction of traffic */ 1448 uint8_t fb_indicator; /* indicator (1-3) */ 1449 uint16_t fb_reserved; /* reserved */ 1450 }; 1452 Figure 7: feedback information structure 1454 direction 1455 Indicates direction of reachability between a locator pair in 1456 question. A value 0 indicates outbound and a value 1 indicates 1457 inbound direction. 1458 indicator 1459 A value indicating the degree of satisfaction of a unidirectional 1460 reachability for a given locator pair. 1461 * 0: Default value. Whenever this value is specified the 1462 feedback information must not be processed by the shim sub- 1463 layer. 1464 * 1: Unable to connect. There is no unidirectional reachability 1465 between the locator pair in question. 1466 * 2: Unsatisfactory. The application is not satisfied with the 1467 unidirectional reachability between the locator pair in 1468 question. 1470 * 3: Satisfactory. There is satisfactory unidirectional 1471 reachability between the locator pair in question. 1472 reserved 1473 Reserved field. Must be ignored by the receiver. 1475 8. System Requirements 1477 As addressed in Section 5, most of the socket options and ancillary 1478 data defined in this document are applicable to connected sockets. 1479 It is assumed that the kernel is capable of maintaining the 1480 association between a connected socket and a shim context. This 1481 requirement is considered to be reasonable because a pair of source 1482 and destination IP addresses is bound to a connected socket. 1484 9. Relation to Existing Sockets API Extensions 1486 This section explains relation between the sockets API defined in 1487 this document and the existing sockets API extensions. 1489 As mentioned in Section 5, the basic assumption is that the existing 1490 sockets API continues to work above the shim sub-layer. This means 1491 that, the existing sockets API deals with identifiers, and the 1492 sockets API defined in this document deals with locators. 1494 SHIM_LOC_LOCAL_SEND and SHIM_LOC_PEER_SEND socket options are 1495 semantically similar to the IPV6_PKTINFO socket API in the sense that 1496 both provide a means for application to set the source IP address of 1497 outbound IP packets. 1499 SHIM_LOC_LOCAL_RECV and SHIM_LOC_PEER_RECV socket options are 1500 semantically similar to the IP_RECVDSTADDR and IPV6_PKTINFO socket 1501 APIs in the sense that both provides a means for application to get 1502 the source and/or destination IP address of inbound IP packets. 1504 getsockname() and getpeername() enable application to get 'name' of 1505 the communication endpoints which is represented by a pair of IP 1506 address and port number assigned to the socket. getsockname() gives 1507 IP address and port number assigned to the socket on the local side, 1508 and getpeername() gives IP address and port number of the peer side. 1510 10. Operational Considerations 1512 This section gives operational considerations of the sockets API 1513 defined in this document. 1515 10.1. Conflict Resolution 1517 There may be a conflicting situation when different applications 1518 specify difference preference for the same shim context. For 1519 instance, application A and B may establish communication with the 1520 same EID pair while both applications have different preference in 1521 their choice of local locator. The notion of context forking in 1522 SHIM6 can resolve the conflicting situation. 1524 Socket options defined in Section 5 may cause conflicting situation 1525 when the target context is shared by multiple applications. In such 1526 a case, the socket handler should inform the shim sub-layer that 1527 context forking is required. In SHIM6, when a context is forked, an 1528 unique identifier called Forked Instance Identifier (FII) is assigned 1529 to the newly forked context. The forked context is then exclusively 1530 associated with the socket through which non-default preference value 1531 was specified. The forked context is maintained by the shim sub- 1532 layer during the lifetime of associated socket instance. When the 1533 socket is closed, the shim sub-layer SHOULD delete associated 1534 context. 1536 When the application specifies SHIM_LOC_*_SEND specifying a different 1537 source or destination locator which does not have the highest 1538 priority and weight specified by the SHIM_LOC_*_PREF, the shim sub- 1539 layer SHOULD supersede the request made by SHIM_LOC_*_SEND over the 1540 preference specified by SHIM_LOC_*_PREF. 1542 When the peer provides preferences of the locators (e.g., a SHIM6 1543 peer may send a locator with a Locator Preferences Option) which 1544 conflict with preference specified by the applications either by 1545 SHIM_LOC_PEER_SEND or SHIM_LOC_PEER_PREF, the shim sub-layer SHOULD 1546 supersede the preference made by the application over the preference 1547 specified by the peer. 1549 10.2. Incompatiblility between IPv4 and IPv6 1551 The shim sub-layer performs identifier/locator adaptation. 1552 Therefore, in some cases, the whole IP header can be replaced with 1553 new IP header of a different address family (e.g. conversion from 1554 IPv4 to IPv6 or vice versa). Hence, there is an issue how to make 1555 the conversion with minimum impact. Note that this issue is common 1556 in other protocol conversion techniques 1557 [RFC2765][I-D.ietf-behave-v6v4-xlate]. 1559 As studied in the previous works on protocol 1560 conversion[RFC2765][I-D.ietf-behave-v6v4-xlate], some of the features 1561 (IPv6 routing headers, hop-by-hop extension headers, and destination 1562 headers) from IPv6 are not convertible to IPv4. In addition, notion 1563 of source routing is not exactly the same in IPv4 and IPv6. This 1564 means that an error may occur during the conversion of identifier and 1565 locator. It is ffs exactly how the shim sub-layer should behave in 1566 such erroneous cases. 1568 11. IANA Considerations 1570 This document contains no IANA consideration. 1572 12. Protocol Constants and Variables 1574 This section defines protocol constants and variables. 1575 SHIM_MAX_LOCATORS The maximum number of the locators to be included 1576 in a locator list. 32. 1578 13. Security Considerations 1580 This section gives security considerations of the API defined in this 1581 document. 1583 13.1. Treatment of Unknown Locator 1585 When sending IP packets, application may request use of unknown 1586 locator for the source and/or destination locators. Note that 1587 treatment of unknown locator can be a subject of security 1588 considerations because use of invalid source and/or destination 1589 locator may cause redirection attack. 1591 13.1.1. Treatment of Unknown Source Locator 1593 The shim sub-layer checks if the requested locator is available on 1594 any of the local interface. If not, the shim sub-layer MUST reject 1595 the request and return an error message with the EINVALIDLOCATOR code 1596 to the application. If the locator is confirmed to be available, the 1597 shim sub-layer SHOULD initiate the procedure to update the locator 1598 list. 1600 Use of the following socket options and ancillary data may require 1601 treatment of unknown source locator: 1602 o SHIM_LOC_LOCAL_SEND 1603 o SHIM_LOC_LOCAL_PREF 1604 o SHIM_LOCLIST_LOCAL 1606 13.1.2. Treatment of Unknown Destination Locator 1608 If the shim sub-layer turns out to be SHIM6, the SHIM6 implementation 1609 MUST reject the request for using unknown destination locator. 1611 If the shim sub-layer turns out to be HIP, the HIP implementation MAY 1612 accept the request for using unknown destination locator. 1614 Use of the following socket options and ancillary data may require 1615 treatment of unknown destination locator: 1616 o SHIM_LOC_PEER_SEND 1617 o SHIM_LOC_PEER_PREF 1618 o SHIM_LOCLIST_PEER 1620 14. Changes 1622 14.1. Changes from version 00 to version 01 1624 o Define shim_locator{} data type which is a placeholder for 1625 locator. 1626 o Define shim_pathexplore{} data type in which a set of REAP 1627 parameters are stored. 1628 o Remove descriptions about "stickiness" of socket options. 1629 o Deprecate SHIM_IF_RECV and SHIM_IF_SEND socket options. 1630 o Give default value and how to disable given socket option. 1632 14.2. Changes from version 01 to version 02 1634 o Add section describing context forking. 1635 o Rephrase conclusion section. 1636 o Separate normative references from informative references. 1637 o Remove texts from discussion section that are not relevant to the 1638 contents of the document. 1639 o Add section describing change history (this section). 1641 14.3. Changes from version 02 to version 03 1643 o Add an Appendix section describing the issue of context forking. 1645 14.4. Changes from version 03 to version 04 1647 o Updated reference. 1648 o Correct typo and grammatical errors. 1650 14.5. Changes from version 04 to version 05 1652 o Added definition of SHIM_FEEDBACK ancillary data. 1653 o Added an example of code using the SHIM_LOCLIST_LOCAL 1654 o Added SHIM_LOC_LOCAL_SEND and SHIM_LOC_PEER_SEND socket options. 1656 14.6. Changes from version 05 to version 06 1658 o Updated references. 1660 14.7. Changes from version 06 to version 07 1662 o Resolved editorial issues. 1664 14.8. Changes from version 07 to version 08 1666 No changes are made except for updates of the references. 1668 14.9. Changes from version 08 to version 09 1670 o Updated texts for Section 1 and Section 5 according to the 1671 comments provided by Samu Varjonen. 1672 o Made it clear that downgrading the multihoming shim support (i.e., 1673 specifying value 1 with the SHIM_DONTSHIM socket option) is only 1674 allowed before the socket is connected. 1675 o Updated locator information (shim_locator{}) so that it can 1676 contain a locator behind NAT. 1678 14.10. Changes from version 09 to version 10 1680 o Addressed applicability of socket options and ancillary data for 1681 the shim sub-layer. 1682 o Addressed system requirements. 1683 o Removed unnecessary description about deprecated socket option 1684 (SHIM_IF_RECV). 1686 14.11. Changes from version 10 to version 11 1688 o Added short descriptions about connected sockets and unconnected 1689 sockets. 1690 o Relaxed applicability of the socket options. 1691 o Relaxed applicability of the ancillary data. 1692 o Added notification about locator change. 1694 14.12. Changes from version 11 to version 12 1695 o Reflected comments from Brian Karpenter. 1696 o Reflected comments from Michael Scharf. 1698 14.13. Changes from version 12 to version 13 1700 o Reflected comments from Sebastien Barre. 1701 o Removed the description about the notification from the shim sub- 1702 layer to applications. 1703 o Narrowed down the scope of the applicability of the socket options 1704 and the ancillary data. 1706 14.14. Changes from version 13 to version 14 1708 o No change was made. The draft was re-submitted to avoid 1709 expiration. 1711 15. Acknowledgments 1713 Authors would like to thank Jari Arkko who participated in the 1714 discussion that lead to the first version of this document, and 1715 Tatuya Jinmei who thoroughly reviewed the early version of this draft 1716 and provided detailed comments on sockets API related issues. Thomas 1717 Henderson provided valuable comments especially from HIP 1718 perspectives. 1720 Authors sincerely thank to the following people for their helpful 1721 comments to the document: Samu Varjonen, Dmitriy Kuptsov, Brian 1722 Carpenter, Michael Scharf, and Sebastien Barre 1724 16. References 1726 16.1. Normative References 1728 [POSIX] "IEEE Std. 1003.1-2001 Standard for Information Technology 1729 -- Portable Operating System Interface (POSIX). Open group 1730 Technical Standard: Base Specifications, Issue 6, 1731 http://www.opengroup.org/austin", December 2001. 1733 [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, 1734 "Advanced Sockets Application Program Interface (API) for 1735 IPv6", RFC 3542, May 2003. 1737 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 1738 (HIP) Architecture", RFC 4423, May 2006. 1740 [RFC5533] Bagnulo, M. and E. Nordmark, "Level 3 multihoming shim 1741 protocol", RFC 5533, June 2009. 1743 [RFC5534] Arkko, J. and I. Beijnum, "Failure Detection and Locator 1744 Pair Exploration Protocol for IPv6 Multihoming", RFC 5534, 1745 June 2009. 1747 16.2. Informative References 1749 [I-D.ietf-behave-v6v4-xlate] 1750 Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 1751 Algorithm", draft-ietf-behave-v6v4-xlate-21 (work in 1752 progress), August 2010. 1754 [I-D.ietf-hip-nat-traversal] 1755 Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. 1756 Keranen, "Basic HIP Extensions for Traversal of Network 1757 Address Translators", Internet 1758 Draft draft-ietf-hip-nat-traversal-09, October 2009. 1760 [I-D.ietf-shim6-app-refer] 1761 Nordmark, E., "Shim6 Application Referral Issues", 1762 draft-ietf-shim6-app-refer-00 (work in progress), 1763 July 2005. 1765 [I-D.ietf-shim6-applicability] 1766 Abley, J., Bagnulo, M., and A. Garcia-Martinez, 1767 "Applicability Statement for the Level 3 Multihoming Shim 1768 Protocol (Shim6)", draft-ietf-shim6-applicability-05 (work 1769 in progress), February 2010. 1771 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 1772 (SIIT)", RFC 2765, February 2000. 1774 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1775 specifying the location of services (DNS SRV)", RFC 2782, 1776 February 2000. 1778 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1779 RFC 3972, March 2005. 1781 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1782 Architecture", RFC 4291, February 2006. 1784 [RFC5535] Bagnulo, M., "Hash Based Addresses (HBA)", RFC 5535, 1785 June 2009. 1787 Appendix A. Context Forking 1789 In this section, an issue concerning context forking and its relation 1790 to the multihoming shim API are discussed. 1792 SHIM6 supports a notion of context forking. A peer may decide to 1793 fork a context for certain reason (e.g. upper layer protocol prefers 1794 to use different locator pair than the one defined in available 1795 context). The procedure of forking context is done similar to the 1796 normal context establishment, performing the 4-way message exchange. 1797 A peer who has decided to fork a context initiates the context 1798 establishment. Hereafter, we call this peer the "initiator". The 1799 peer of the initiator is called the "responder". 1801 Once the forked context is established between the peers, on the 1802 initiator side, it is possible to apply forked context to the packet 1803 flow since the system maintains an association between the forked 1804 context and the socket owned by the application that has requested 1805 the context forking. How this association is maintained is an 1806 implementation specific issue. However, on the responder side, there 1807 is a question how the outbound packet can be multiplexed by the shim 1808 sub-layer because there are more than one SHIM6 contexts that match 1809 with the ULID pair of the packet flow. There is a need to 1810 differentiate packet flows not only by the ULID pairs but by some 1811 other information and associate a given packet flow with a specific 1812 context. 1814 Figure 8 gives an example of a scenario where two communicating peers 1815 fork a context. Initially, there has been a single transaction 1816 between the peers, by the application 1 (App1). Accordingly, another 1817 transaction is started, by application 2 (App2). Both of the 1818 transactions are made based on the same ULID pair. The first context 1819 pair (Ctx1) is established for the transaction of App1. Given the 1820 requests from App2, the shim sub-layer on Peer 1 decides to fork a 1821 context. Accordingly, a forked context (Ctx2) is established between 1822 the peers, which should be exclusively applied to the transaction of 1823 App2. Ideally, multiplexing and demultiplexing of packet flows that 1824 relate to App1 and App2 should be done as illustrated in Figure 8. 1825 However, as mentioned earlier, the responder needs to multiplex 1826 outbound flows of App1 and App2 somehow. Note that if a context 1827 forking occurs on the initiator side, a context forking needs to 1828 occur also on the responder side. 1830 Peer 1 Peer 2 1831 (initiator) (responder) 1833 +----+ +----+ +----+ +----+ 1834 |App1| |App2| |App1| |App2| 1835 +----+ +----+ +----+ +----+ 1836 |^ |^ ^| ^| 1837 v| v| |v |v 1838 -----S1-------------S2----- -----S1-------------S2----- 1839 || || || || 1840 || || || || 1842 Ctx1 Ctx2 Ctx1 Ctx2 1843 ULID: ULID: ULID: ULID: 1844 Loc: Loc: Loc: Loc: 1845 FII: 0 FII: 100 FII: 0 FII: 100 1847 |^ |^ ^| ^| 1848 || || || || 1849 || || || || 1850 \..............||....................../| || 1851 \.............||......................./ || 1852 || || 1853 \|...................................../| 1854 \....................................../ 1856 Figure 8: context forking 1858 Any solution is needed to overcome the problem mentioned above. 1860 Authors' Addresses 1862 Miika Komu 1863 Helsinki Institute for Information Technology 1864 Tammasaarenkatu 3 1865 Helsinki 1866 Finland 1868 Phone: +358503841531 1869 Fax: +35896949768 1870 Email: miika@iki.fi 1871 URI: http://www.hiit.fi/ 1872 Marcelo Bagnulo 1873 Universidad Carlos III de Madrid 1874 Av. Universidad 30 1875 Leganes 28911 1876 SPAIN 1878 Phone: +34 91 6248837 1879 Email: marcelo@it.uc3m.es 1880 URI: http://it.uc3m.es/marcelo 1882 Kristian Slavov 1883 Ericsson Research Nomadiclab 1884 Hirsalantie 11 1885 Jorvas FI-02420 1886 Finland 1888 Phone: +358 9 299 3286 1889 Email: kristian.slavov@ericsson.com 1891 Shinta Sugimoto (editor) 1892 Nippon Ericsson K.K. 1893 Koraku Mori Building 1894 1-4-14, Koraku, Bunkyo-ku 1895 Tokyo 112-0004 1896 Japan 1898 Phone: +81 3 3830 2241 1899 Email: shinta@sfc.wide.ad.jp