idnits 2.17.1 draft-ietf-shim6-multihome-shim-api-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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: '...e shim sub-layer MAY provide notificat...' RFC 2119 keyword, line 1281: '...e shim sub-layer SHOULD provide the la...' RFC 2119 keyword, line 1348: '...ator information MAY contain a locator...' (5 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1159 has weird spacing: '... u_int msg_...' == Line 1160 has weird spacing: '... struct iovec...' == Line 1161 has weird spacing: '... u_int msg_...' == Line 1163 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 (January 9, 2010) is 5192 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 971 -- Looks like a reference, but probably isn't: '1' on line 981 ** Obsolete normative reference: RFC 4423 (Obsoleted by RFC 9063) == 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 (~~), 6 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: July 13, 2010 UC3M 6 K. Slavov 7 S. Sugimoto, Ed. 8 Ericsson 9 January 9, 2010 11 Socket Application Program Interface (API) for Multihoming Shim 12 draft-ietf-shim6-multihome-shim-api-12 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on July 13, 2010. 37 Copyright Notice 39 Copyright (c) 2010 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents in effect on the date of 44 publication of this document (http://trustee.ietf.org/license-info). 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. 48 Abstract 50 This document specifies sockets API extensions for the multihoming 51 shim layer. The API aims to enable interactions between applications 52 and the multihoming shim layer for advanced locator management, and 53 access to information about failure detection and path exploration. 55 This document is based on an assumption that a multihomed host is 56 equipped with a conceptual sub-layer (hereafter "shim") inside the IP 57 layer that maintains mappings between identifiers and locators. 58 Examples of the shim are SHIM6 and HIP. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3. System Overview . . . . . . . . . . . . . . . . . . . . . . . 6 65 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 5. Socket Options for Multihoming Shim Sub-layer . . . . . . . . 9 67 5.1. SHIM_ASSOCIATED . . . . . . . . . . . . . . . . . . . . . 13 68 5.2. SHIM_DONTSHIM . . . . . . . . . . . . . . . . . . . . . . 14 69 5.3. SHIM_HOT_STANDBY . . . . . . . . . . . . . . . . . . . . 15 70 5.4. SHIM_PATHEXPLORE . . . . . . . . . . . . . . . . . . . . 15 71 5.5. SHIM_LOC_LOCAL_PREF . . . . . . . . . . . . . . . . . . . 16 72 5.6. SHIM_LOC_PEER_PREF . . . . . . . . . . . . . . . . . . . 17 73 5.7. SHIM_LOC_LOCAL_RECV . . . . . . . . . . . . . . . . . . . 18 74 5.8. SHIM_LOC_PEER_RECV . . . . . . . . . . . . . . . . . . . 19 75 5.9. SHIM_LOC_LOCAL_SEND . . . . . . . . . . . . . . . . . . . 19 76 5.10. SHIM_LOC_PEER_SEND . . . . . . . . . . . . . . . . . . . 21 77 5.11. SHIM_LOCLIST_LOCAL . . . . . . . . . . . . . . . . . . . 21 78 5.12. SHIM_LOCLIST_PEER . . . . . . . . . . . . . . . . . . . . 23 79 5.13. SHIM_APP_TIMEOUT . . . . . . . . . . . . . . . . . . . . 23 80 5.14. SHIM_DEFERRED_CONTEXT_SETUP . . . . . . . . . . . . . . . 24 81 5.15. Applicability . . . . . . . . . . . . . . . . . . . . . . 25 82 5.16. Error Handling . . . . . . . . . . . . . . . . . . . . . 25 83 6. Ancillary Data for Multihoming Shim Sub-layer . . . . . . . . 26 84 6.1. Get Locator from Incoming Packet . . . . . . . . . . . . 27 85 6.2. Set Locator for Outgoing Packet . . . . . . . . . . . . . 27 86 6.3. Notification from Application to Multihoming Shim 87 Sub-layer . . . . . . . . . . . . . . . . . . . . . . . . 27 88 6.4. Notification from Multihoming Shim Sub-layer to 89 Application . . . . . . . . . . . . . . . . . . . . . . . 28 90 6.5. Applicability . . . . . . . . . . . . . . . . . . . . . . 28 91 7. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 29 92 7.1. Placeholder for Locator Information . . . . . . . . . . . 29 93 7.1.1. Handling Locator behind NAT . . . . . . . . . . . . . 30 94 7.2. Path Exploration Parameter . . . . . . . . . . . . . . . 31 95 7.3. Feedback Information . . . . . . . . . . . . . . . . . . 32 96 8. System Requirements . . . . . . . . . . . . . . . . . . . . . 33 97 9. Relation to Existing Sockets API Extensions . . . . . . . . . 33 98 10. Operational Considerations . . . . . . . . . . . . . . . . . . 34 99 10.1. Conflict Resolution . . . . . . . . . . . . . . . . . . . 34 100 10.2. Incompatiblility between IPv4 and IPv6 . . . . . . . . . 35 101 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 102 12. Protocol Constants and Variables . . . . . . . . . . . . . . . 35 103 13. Security Considerations . . . . . . . . . . . . . . . . . . . 35 104 13.1. Treatment of Unknown Locator . . . . . . . . . . . . . . 35 105 13.1.1. Treatment of Unknown Source Locator . . . . . . . . . 35 106 13.1.2. Treatment of Unknown Destination Locator . . . . . . . 36 107 14. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 108 14.1. Changes from version 00 to version 01 . . . . . . . . . . 36 109 14.2. Changes from version 01 to version 02 . . . . . . . . . . 36 110 14.3. Changes from version 02 to version 03 . . . . . . . . . . 37 111 14.4. Changes from version 03 to version 04 . . . . . . . . . . 37 112 14.5. Changes from version 04 to version 05 . . . . . . . . . . 37 113 14.6. Changes from version 05 to version 06 . . . . . . . . . . 37 114 14.7. Changes from version 06 to version 07 . . . . . . . . . . 37 115 14.8. Changes from version 07 to version 08 . . . . . . . . . . 37 116 14.9. Changes from version 08 to version 09 . . . . . . . . . . 37 117 14.10. Changes from version 09 to version 10 . . . . . . . . . . 37 118 14.11. Changes from version 10 to version 11 . . . . . . . . . . 38 119 14.12. Changes from version 11 to version 12 . . . . . . . . . . 38 120 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38 121 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 122 16.1. Normative References . . . . . . . . . . . . . . . . . . 38 123 16.2. Informative References . . . . . . . . . . . . . . . . . 39 124 Appendix A. Context Forking . . . . . . . . . . . . . . . . . . . 39 125 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 127 1. Introduction 129 This document defines socket API extensions by which upper layer 130 protocols may be informed about and control the way in which a 131 multihoming shim sub-layer in the IP layer manages the dynamic choice 132 of locators. Initially it applies to SHIM6 and HIP, but it is 133 defined generically. 135 The role of the multihoming shim sub-layer (hereafter called "shim 136 sub-layer" in this document) is to avoid impacts to upper layer 137 protocols which may be caused when the endhost changes its attachment 138 point to the Internet, for instance, in the case of rehoming event 139 under the multihomed environment. The key design of the shim sub- 140 layer is to treat identifier and locator separately. Identifiers are 141 presented to upper layer protocols and used as communication 142 endpoints. Locators represent toplogical location of endhosts and 143 are used to route packet from the source to the destiantion. The 144 shim sub-layer maintains mapping of identifiers and locators. 146 Note that the shim sub-layer may conflict with other multihoming 147 mechanisms such as SCTP and multipath 148 TCP[I-D.ietf-shim6-applicability]. To avoid any conflict, only one 149 of SHIM6 and HIP should be in use. 151 In this document, syntax and semantics of the API are given in the 152 same way as the Posix standard [POSIX]. The API specifies how to use 153 ancillary data (aka cmsg) to access the locator information with 154 recvmsg() and/or sendmsg() I/O calls. The API is described in C 155 language and data types are defined in the Posix format; intN_t means 156 a singed integer of exactly N bits (e.g. int16_t) and uintN_t means 157 an unsigned integer of exactly N bits (e.g. uint32_t). 159 The distinction between "connected" sockets and "unconnected" sockets 160 is important when discussing the applicability of the socket API 161 defined in this document. A connected socket is bound to a given 162 peer, whereas an unconnected socket is not bound to any specific 163 peers. A TCP socket becomes a connected socket when the TCP 164 connection establishment is completed. UDP sockets are unconnected, 165 unless the application uses the connect() system call. 167 The target readers of this document are application programmers who 168 develop application software which may benefit greatly from 169 multihomed environments. In addition, this document aims to provide 170 necessary information for developers of shim protocols to implement 171 API for enabling advanced locator management. 173 2. Terminology 175 This section provides terminology used in this document. Basically 176 most of the terms used in this document are taken from the following 177 documents: 179 o SHIM6 Protocol Specification[RFC5533] 180 o HIP Architecture[RFC4423] 181 o Reachability Protocol (REAP)[RFC5534] 183 In this document, the term "IP" refers to both IPv4 and IPv6, unless 184 the protocol version is specifically mentioned. The following are 185 definitions of terms frequently used in this document: 187 o Endpoint identifier (EID) - The identifier used by the application 188 to specify the endpoint of a given communication. Applications 189 may handle EIDs in various ways such as long-lived connections, 190 callbacks, and referrals[I-D.ietf-shim6-app-refer]. 191 * In the case of SHIM6, an identifier called a ULID serves as an 192 EID. A ULID is chosen from locators available on the host. 193 * In the case of HIP, an identifier called a Host Identifier 194 serves as an EID. A Host Identifier is derived from the public 195 key of a given host. For the sake of backward compatibility 196 with the sockets API, the Host Identifier is represented in a 197 form of hash of public key. 198 * Note that the EID appears in the standard socket API as an 199 address, and does not appear in the extensions defined in this 200 document, which only concern locators. 201 o Locator - The IP address actually used to deliver IP packets. 202 Locators are present in the source and destination fields of the 203 IP header of a packet on the wire. 204 * List of locators - A list of locators associated with an EID. 205 There are two lists of locators stored in a given context. One 206 is associated with the local EID and the other is associated 207 with the remote EID. As defined in [RFC5533], the list of 208 locators associated with an EID 'A' is denoted as Ls(A). 209 * Preferred locator - The (source/destination) locator currently 210 used to send packets within a given context. As defined in 211 [RFC5533], the preferred locator of a host 'A' is denoted as 212 Lp(A). 213 * Unknown locator - Any locator that does not appear in the 214 locator list of the shim context associated with the socket. 215 When there is no shim context associated with the socket, any 216 source and/or destination locator requested by the application 217 is considered to be unknown locator. 218 o Shim - The conceptual sub-layer inside the IP layer which 219 maintains mappings between EIDs and locators. An EID can be 220 associated with more than one locator at a time when the host is 221 multihomed. The term 'shim' does not refer to a specific protocol 222 but refers to the conceptual sub-layer inside the IP layer. 223 o Identifier/locator adaptation - The adaptation performed at the 224 shim sub-layer which may end up re-writing the source and/or 225 destination addresses of an IP packet. In the outbound packet 226 processing, the EID pair is converted to the associated locator 227 pair. In the inbound packet processing, the locator pair is 228 converted to the EID pair. 229 o Context - The state information shared by a given pair of peers, 230 which stores a binding between the EID and associated locators. 231 Contexts are maintained by the shim sub-layer. 232 o Reachability detection - The procedure to check reachability 233 between a given locator pair. 234 o Path - The sequence of routers that an IP packet goes through to 235 reach the destination. 236 o Path exploration - The procedure to explore available paths for a 237 given set of locator pairs. 238 o Outage - The incident that prevents IP packets to flow from the 239 source locator to the destination locator. When there is an 240 outage, it means that there is no reachability between a given 241 locator pair. The outage may be caused by various reasons, such 242 as shortage of network resources, congestion, and human error 243 (faulty operation). 244 o Working address pair - The address pair is considered to be 245 "working" if the packet can safely travel from the source to the 246 destination where the packet contains the first address from the 247 pair as the source address and the second address from the pair as 248 the destination address. If reachability is confirmed in both 249 directions, the address pair is considered to be working bi- 250 directionally. 251 o Reachability protocol (REAP) - The protocol for detecting failure 252 and exploring reachability in a multihomed environment. REAP is 253 defined in [RFC5534]. 255 3. System Overview 257 Figure 1 illustrates the system overview. The shim sub-layer and 258 REAP component exist inside the IP layer. Applications use the 259 sockets API defined in this document to interface with the shim sub- 260 layer and the transport layer for locator management, failure 261 detection, and path exploration. 263 It may also be possible that the shim sub-layer interacts with the 264 transport layer, however, such an interaction is outside the scope of 265 this document. 267 +------------------------+ 268 | Application | 269 +------------------------+ 270 ^ ^ 271 ~~~~~~~~~~~~~|~Socket Interface|~~~~~~~~~~~~~~ 272 | v 273 +-----------|------------------------------+ 274 | | Transport Layer | 275 +-----------|------------------------------+ 276 ^ | 277 +-------------|-----|-------------------------------------+ 278 | v v | 279 | +-----------------------------+ +----------+ | IP 280 | | Shim |<----->| REAP | | Layer 281 | +-----------------------------+ +----------+ | 282 | ^ ^ | 283 +-----------------------|----------------------|----------+ 284 v v 285 +------------------------------------------+ 286 | Link Layer | 287 +------------------------------------------+ 289 Figure 1: System overview 291 4. Requirements 293 The following is a list of requirements from applications: 294 o Turn on/off shim. An application should be able to request to 295 turn on or turn off the multihoming support by the shim layer: 296 * Apply shim. The application should be able to explicitly 297 request the shim sub-layer to apply multihoming support. 298 * Don't apply shim. The application should be able to request 299 the shim sub-layer not to apply the multihoming support but to 300 apply normal IP processing at the IP layer. 301 * Note that this function is also required by other types of 302 multihoming mechanisms such as SCTP and multipath TCP to avoid 303 potential conflict with the shim sub-layer. 304 o Locator management. 305 * It should be possible to set preferred source and/or 306 destination locator within a given context: Lp(local) and/or 307 Lp(remote). 308 * It should be possible to get preferred source and/or 309 destination locator within a given context: Lp(local) and/or 310 Lp(remote). 312 * It should be possible to set a list of source and/or 313 destination locators within a given context: Ls(local) and 314 Ls(remote). 315 * It should be possible to get a list of source and/or 316 destination locators within a given context: Ls(local) and 317 Ls(remote). 318 o Notification from applications to the shim sub-layer about the 319 status of the communication. The notification occurs in an event- 320 based manner. Applications and/or upper layer protocols may 321 provide positive feedbacks or negative feedbacks to the shim sub- 322 layer. Note that these feedbacks are mentioned in [RFC5534]: 323 * Applications and/or upper layer protocols (e.g., TCP) may 324 provide positive feedbacks to the shim sub-layer informing that 325 the communication is going well. 326 * Applications and/or upper layer protocols (e.g., TCP) may 327 provide negative feedbacks to the shim sub-layer informing that 328 the communication status is not satisfactory. TCP may detect a 329 problem when it does not receive any expected ACK message from 330 the peer. Besides, a receipt of an ICMP error message could be 331 a clue for the application to detect problems. The REAP module 332 may be triggered by these negative feedbacks and invoke the 333 path exploration procedure. 334 o Feedback from applications to the shim sub-layer. Applications 335 should be able to inform the shim sub-layer of the timeout values 336 for detecting failures, sending keepalives, and starting the 337 exploration procedure. In particular, applications should be able 338 to suppress keepalives. 339 o Hot-standby. Applications may request the shim sub-layer for the 340 hot-standby capability. This means that, alternative paths are 341 known to be working in advance of a failure detection. In such a 342 case, it is possible for the host to immediately replace the 343 current locator pair with an alternative locator pair. 344 o Eagerness for locator exploration. An application should be able 345 to inform the shim sub-layer of how aggressively it wants the REAP 346 mechanism to perform a path exploration (e.g., by specifying the 347 number of concurrent attempts of discovery of working locator 348 pairs) when an outage occurs on the path between the locator pair 349 in use. 350 o Providing locator information to applications. An application 351 should be able to obtain information about the locator pair which 352 was actually used to send or receive the packet. 353 * For inbound traffic, the application may be interested in the 354 locator pair which was actually used to receive the packet. 355 * For outbound traffic, the application may be interested in the 356 locator pair which was actually used to transmit the packet. 357 In this way, applications may have additional control on the 358 locator management. For example, an application becomes able to 359 verify if its preference for locator is actually applied to the 360 flow or not. 361 o Applications should be able to specify if they want to defer the 362 context setup, or if they want context establishment to be started 363 immediately in the case where there is no available context. A 364 deferred context setup means that the initiation of communication 365 should not be blocked to wait for completion of the context 366 establishment. 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 if 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 | *2 | 452 | | | | source locator | | 453 | | | | of outgoing IP | | 454 | | | | packets. | | 455 | SHIM_LOC_PEER_SEND | o | o | Get or set the | *2 | 456 | | | | destination | | 457 | | | | locator of | | 458 | | | | outgoing IP | | 459 | | | | packets. | | 460 | SHIM_LOCLIST_LOCAL | o | o | Get or set the | *3 | 461 | | | | list of | | 462 | | | | locators | | 463 | | | | associated with | | 464 | | | | the local EID. | | 465 | SHIM_LOCLIST_PEER | o | o | Get or set the | *3 | 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 | *4 | 475 | | | | parameters for | | 476 | | | | path | | 477 | | | | exploration and | | 478 | | | | failure | | 479 | | | | detection. | | 480 | SHIM_CONTEXT_DEFERRED_SETUP | o | o | Get or set 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 shim_locator data structure. 496 *3: Pointer to an array of shim_locator. 498 *4: Pointer to a shim_pathexplore which is defined in Section 7. 500 Figure 2 illustrates how the shim specific socket options fit into 501 the system model of socket API. The figure shows that the shim sub- 502 layer and the additional protocol components (IPv4 and IPv6) below 503 the shim sub-layer are new to the system model. As previously 504 mentioned, all the shim specific socket options are defined at the 505 SOL_SHIM level. This design choice brings the following advantages: 507 1. The existing sockets API continue to work at the layer above the 508 shim sub-layer. That is, those legacy API handle IP addresses as 509 identifiers. 510 2. With newly defined socket options for the shim sub-layer, the 511 application obtains additional control of locator management. 512 3. The shim specific socket options can be kept independent from 513 address family (IPPROTO_IP or IPPROTO_IPV6) and transport 514 protocol (IPPROTO_TCP or IPPROTO_UDP). 516 s1 s2 s3 s4 517 | | | | 518 +----------------|--|-------|--|----------------+ 519 | +-------+ +-------+ | 520 | IPPROTO_TCP | TCP | | UDP | | 521 | +-------+ +-------+ | 522 | | \ / | | 523 | | ----- | | 524 | | / \ | | 525 | +------+ +------+ | 526 | IPPROTO_IP | IPv4 | | IPv6 | IPPROTO_IPV6 | 527 | +------+ +------+ | 528 | \ / SOL_SOCKET 529 | +--------\-------/--------+ | 530 | SOL_SHIM | shim | | 531 | +--------/-------\--------+ | 532 | / \ | 533 | +------+ +------+ | 534 | | IPv4 | | IPv6 | | 535 | +------+ +------+ | 536 | | | | 537 +------------------|----------|-----------------+ 538 | | 539 IPv4 IPv6 540 Datagram Datagram 542 Figure 2: System model of sockets API with shim sub-layer 544 5.1. SHIM_ASSOCIATED 546 The SHIM_ASSOCIATED option is used to check whether the socket is 547 associated with any shim context or not. 549 This option is meaningful when the locator information of the 550 received IP packet does not tell whether the identifier/locator 551 adaptation is performed or not. Note that the EID pair and the 552 locator pair may be identical in some cases. 554 This option can be specified by getsockopt(). Thus, the option is 555 read-only and the result (0/1/2) is set in the option value (the 556 fourth argument of getsockopt()). 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 For example, an application can request establishment of a hot- 630 standby connection by using the socket option as follows: 632 int optval; 634 optval = 1; 636 setsockopt(fd, SOL_SHIM, SHIM_HOT_STANDBY, &optval, 637 sizeof(optval)); 639 For example, an application can get the option value by using the 640 socket option as follows: 642 int optval; 643 int len; 645 len = sizeof(optval); 647 getsockopt(fd, SOL_SHIM, SHIM_HOT_STANDBY, &optval, &len); 649 5.4. SHIM_PATHEXPLORE 651 The application may use this socket option to specify parameters 652 concerning path exploration. Path exploration is a procedure to find 653 an alternative locator pair to the current locator pair. As the REAP 654 specification defines, a peer may send Probe messages to find an 655 alternative locator pair. 657 The option is effective only when there is a shim context associated 658 with the socket. 660 The data type of the option value is a pointer to the buffer where a 661 set of information for path exploration is stored. The data 662 structure is defined in Section 7. 664 By default, the option value is set to NULL, meaning that the option 665 is disabled. 667 An error ENOENT is returned when there is no context associated with 668 the socket. 670 For example, an application can set parameters for path exploration 671 by using the socket option as follows. 673 struct shim6_pathexplore pe; 675 pe.pe_probenum = 4; /* times */ 676 pe.pe_keepaliveto = 10; /* seconds */ 677 pe.pe_initprobeto = 500; /* milliseconds */ 678 pe.pe_reserved = 0; 680 setsockopt(fd, SOL_SHIM, SHIM_PATHEXPLORE, &pe, sizeof(pe)); 682 For example, an application can get parameters for path exploration 683 by using the socket option as follows. 685 struct shim6_pathexplore pe; 686 int len; 688 len = sizeof(pe); 690 getsockopt(fd, SOL_SHIM, SHIM_PATHEXPLORE, &pe, &len); 692 5.5. SHIM_LOC_LOCAL_PREF 694 The SHIM_LOC_LOCAL_PREF option is used to get or set preferred 695 locator on local side within a given context. Hence this option is 696 effective only when there is a shim context associated with the 697 socket. 699 The data type of the option value is a pointer to a locator 700 information data structure which is defined in Section 7. 702 By default, the option value is set to NULL, meaning that the option 703 is disabled. 705 The preferred locator can be set by setsockopt(). The shim sub-layer 706 shall verify requested locator before it updating the preferred 707 locator. 709 An application can get the preferred locator by getsockopt(). 711 An error ENOENT is returned when there is no context associated with 712 the socket. 714 An error EINVALIDLOCATOR is returned when the validation of the 715 specified locator failed. 717 For example, an application can set the preferred locator by using 718 the socket option as follows. Note that some members of the 719 shim_locator (lc_ifidx and lc_flags) are ignored in the set 720 operation. 722 struct shim_locator lc; 723 struct in6_addr ip6; 725 /* ...set the locator (ip6)... */ 727 memset(&lc, 0, sizeof(shim_locator)); 728 lc.lc_family = AF_INET6; /* IPv6 */ 729 lc.lc_ifidx = 0; 730 lc.lc_flags = 0; 731 lc.lc_preference = 255; 732 memcpy(lc.lc_addr, &ip6, sizeof(in6_addr)); 734 setsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_PREF, &lc, 735 sizeof(optval)); 737 For example, an application can get the preferred locator by using 738 the socket option as follows. 740 struct shim_locator lc; 741 int len; 743 len = sizeof(lc); 745 getsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_PREF, &lc, &len); 747 5.6. SHIM_LOC_PEER_PREF 749 The SHIM_LOC_PEER_PREF option is used to get or set preferred locator 750 on peer side within a given context. Hence this option is effective 751 only when there is a shim context associated with the socket. 753 The data type of the option value is a pointer to the locator 754 information data structure which is defined in Section 7. 756 By default, the option value is set to NULL, meaning that the option 757 is disabled. 759 The preferred locator can be set by setsockopt(). The shim sub-layer 760 shall verify requested locator before it updating the preferred 761 locator. 763 An application can get the preferred locator by getsockopt(). 765 An error ENOENT is returned when there is no context associated with 766 the socket. 768 An error EINVALIDLOCATOR is returned when the validation of the 769 requested locator fails. 771 The usage of the option is same as that of SHIM_LOC_LOCAL_PREF. Note 772 that some members of the shim_locator (lc_ifidx and lc_flags) are 773 ignored in the set operation. 775 5.7. SHIM_LOC_LOCAL_RECV 777 The SHIM_LOC_LOCAL_RECV option can be used to request the shim sub- 778 layer to store the destination locator of the received IP packet in 779 an ancillary data object which can be accessed by recvmsg(). Hence 780 this option is effective only when there is a shim context associated 781 with the socket. 783 The data type of the option value is integer. The option value 784 should be binary (0 or 1). By default, the option value is set to 0, 785 meaning that the option is disabled. 787 An application can set the option value by setsockopt(). 789 An application can get the option value by getsockopt(). 791 See Section 6 for the procedure to access locator information stored 792 in the ancillary data objects. 794 An error ENOENT is returned when there is no context associated with 795 the socket. 797 For example, an application can request the shim sub-layer to store 798 destination locator by using the socket option as follows. 800 int optval; 802 optval = 1; 804 setsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_RECV, &optval, 805 sizeof(optval)); 807 For example, an application can get the option value as follows. 809 int optval; 810 int len; 812 len = sizeof(optval); 814 getsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_RECV, &optval, &len); 816 5.8. SHIM_LOC_PEER_RECV 818 The SHIM_LOC_PEER_RECV option is used to request the shim sub-layer 819 to store the source locator of the received IP packet in an ancillary 820 data object which can be accessed by recvmsg(). Hence this option is 821 effective only when there is a shim context associated with the 822 socket. 824 The data type of the option value is integer. The option value 825 should be binary (0 or 1). By default, the option value is set to 0, 826 meaning that the option is disabled. 828 The option value can be set by setsockopt(). 830 The option value can be read by getsockopt(). 832 See Section 6 for the procedure to access locator information stored 833 in the ancillary data objects. 835 An error ENOENT is returned when there is no context associated with 836 the socket. 838 The usage of the option is same as that of SHIM_LOC_LOCAL_RECV 839 option. 841 5.9. SHIM_LOC_LOCAL_SEND 843 The SHIM_LOC_LOCAL_SEND option is used to request the shim sub-layer 844 to use a specific locator as the source locator for the IP packets to 845 be sent from the socket. Hence this option is effective only when 846 there is a shim context associated with the socket. 848 The data type of option value is pointer to shim_locator data 849 structure. 851 An application can set the local locator by setsockopt() providing a 852 valid locator which is stored in a shim_locator data structure. When 853 a zero-filled locator is specified, pre-existing setting of local 854 locator is inactivated. 856 An application can get the local locator by getsockopt(). 858 An error ENOENT is returned when there is no context associated with 859 the socket. 861 An error EINVALIDLOCATOR is returned when invalid locator is 862 specified. 864 For example, an application can request the shim sub-layer to use a 865 specific local locator by using the socket option as follows. 867 struct shim_locator locator; 868 struct in6_addr ia6; 870 /* an IPv6 address preferred for the source locator is copied 871 to the parameter ia6 */ 873 memset(&locator, 0, sizeof(locator)); 875 /* fill shim_locator data structure */ 876 locator.lc_family = AF_INET6; 877 locator.lc_ifidx = 1; 878 locator.lc_flags = 0; 879 locator.lc_preference = 0; 880 memcpy(&locator.lc_addr, &ia6, sizeof(ia6)); 882 setsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_SEND, &locator, 883 sizeof(locator)); 885 For example, an application can get the preferred local locator by 886 using the socket option as follows. 888 struct shim_locator locator; 890 memset(&locator, 0, sizeof(locator)); 892 getsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_SEND, &locator, 893 sizeof(locator)); 895 /* check locator */ 897 5.10. SHIM_LOC_PEER_SEND 899 The SHIM_LOC_PEER_SEND option is used to request the shim sub-layer 900 to use a specific locator for the destination locator of IP packets 901 to be sent from the socket. Hence this option is effective only when 902 there is a shim context associated with the socket. 904 The data type of the option value is a pointer to shim_locator data 905 structure. 907 An application can set the remote locator by setsockopt() providing a 908 valid locator which is stored in a shim_locator data structure. When 909 a zero-filled locator is specified, pre-existing setting of remote 910 locator is inactivated. 912 An application can get the specified remote locator by getsockopt(). 914 An error ENOENT is returned when there is no context associated with 915 the socket. 917 An error EINVALIDLOCATOR when invalid locator is specified. 919 The usage of the option is as the same as that of SHIM_LOC_LOCAL_SEND 920 option. 922 5.11. SHIM_LOCLIST_LOCAL 924 The SHIM_LOCLIST_LOCAL option is used to get or set the locator list 925 associated with the local EID of the shim context associated with the 926 socket. Hence this option is effective only when there is a shim 927 context associated with the socket. 929 The data type of the option value is a pointer to the buffer in which 930 a locator list is stored. See Section 7 for the data structure for 931 storing the locator information. By default, the option value is set 932 to NULL, meaning that the option is disabled. 934 An application can get the locator list by getsockopt(). Note that 935 the size of the buffer pointed by optval argument should be large 936 enough to store an array of locator information. The number of the 937 locator information is not known beforehand. 939 The local locator list can be set by setsockopt(). The buffer 940 pointed by optval argument should contain an array of locator list. 942 An error ENOENT is returned when there is no context associated with 943 the socket. 945 An error EINVALIDLOCATOR is returned when the validation of the 946 specified locator failed. 948 An error ETOOMANYLOCATORS is returned when the number of locators 949 specified exceeds the limit (SHIM_MAX_LOCATORS). 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_preference = 1; 971 memcpy(&locators[0].lc_addr, &sa6->sin6_addr, 972 sizeof(sa6->sin6_addr)); 974 ... 976 /* second locator (an IPv4 address) */ 977 locators[1].lc_family = AF_INET; 978 locators[1].lc_ifidx = 0; 979 locators[1].lc_flags = 0; 980 locators[1].lc_preference = 0; 981 memcpy(&locators[1].lc_addr, &sa->sin_addr, 982 sizeof(sa->sin_addr)); 984 setsockopt(fd, SOL_SHIM, SHIM_LOCLIST_LOCAL, locators, 985 sizeof(locators)); 987 For example, an application can get a list of locators that are 988 associated with the local EID by using the socket option as follows. 990 struct shim_locator locators[SHIM_MAX_LOCATORS]; 992 memset(locators, 0, sizeof(locators)); 994 getsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_RECV, locators, 995 sizeof(locators)); 997 /* parse locators */ 998 ... 1000 5.12. SHIM_LOCLIST_PEER 1002 The SHIM_LOCLIST_PEER option is used to get or set the locator list 1003 associated with the peer EID of the shim context associated with the 1004 socket. Hence this option is effective only when there is a shim 1005 context associated with the socket. 1007 The data type of the option value is a pointer to the buffer where a 1008 locator list is stored. See Section 7 for the data structure for 1009 storing the locator information. By default, the option value is set 1010 to NULL, meaning that the option is disabled. 1012 An application can get the locator list by getsockopt(). Note that 1013 the size of the buffer pointed by optval argument should be large 1014 enough to store an array of locator information. The number of the 1015 locator information is not known beforehand. 1017 An application can set the locator list by setsockopt(). The buffer 1018 pointed by optval argument should contain an array of locator list. 1020 An error ENOENT is returned when there is no context associated with 1021 the socket. 1023 An error EINVALIDLOCATOR is returned when the validation of the 1024 specified locator failed. 1026 An error ETOOMANYLOCATORS is returned when the number of locators 1027 specified exceeds the limit (SHIM_MAX_LOCATORS). 1029 The usage of the option is same as that of SHIM_LOCLIST_LOCAL. 1031 5.13. SHIM_APP_TIMEOUT 1033 The SHIM_APP_TIMEOUT option is used to get or set the timeout value 1034 for application to detect failure. Hence this option is effective 1035 only when there is a shim context associated with the socket. 1037 The data type of the option value is an integer. The value indicates 1038 the period of timeout in seconds to send a REAP Keepalive message 1039 since the last outbound traffic. By default, the option value is set 1040 to 0, meaning that the option is disabled. When the option is 1041 disabled, the REAP mechanism follows its default value of Send 1042 Timeout value as specified in [RFC5534] 1044 If the timeout value specified is longer than the Send Timeout 1045 configured in the REAP component, the REAP Keepalive message should 1046 be suppressed. 1048 An error ENOENT is returned when there is no context associated with 1049 the socket. 1051 For example, an application can set the timeout value by using the 1052 socket option as follows. 1054 int optval; 1056 optval = 15; /* 15 seconds */ 1058 setsockopt(fd, SOL_SHIM, SHIM_APP_TIMEOUT, &optval, 1059 sizeof(optval)); 1061 For example, an application can get the timeout value by using the 1062 socket option as follows. 1064 int optval; 1065 int len; 1067 len = sizeof(optval); 1069 getsockopt(fd, SOL_SHIM, SHIM_APP_TIMEOUT, &optval, &len); 1071 5.14. SHIM_DEFERRED_CONTEXT_SETUP 1073 The SHIM_DEFERRED_CONTEXT_SETUP option is used to specify whether to 1074 enable deferred context setup or not. Deferred context setup means 1075 that the context is established in parallel with the data 1076 communication. Note that SHIM6 supports deferred context setup and 1077 HIP does not because EIDs in HIP (i.e., Host Identifiers) are non- 1078 routable. 1080 The data type for the option value is an integer. The option value 1081 should be binary (0 or 1). By default, the value is set to 1, 1082 meaning that the context setup is deferred. In order to disable the 1083 option, the application should call setsockopt() with option value 1084 set to 0. 1086 Note that HIP does not support deferred context setup, by default. 1087 When the application requests to enable deferred context setup in 1088 case of HIP, it may mean that the application allows the system to 1089 start TCP handshake even when there is no IPsec security association 1090 with the peer. Such a usage of the SHIM_DEFERRED_CONTEXT_SETUP 1091 option should be considered as experimental and left for further 1092 study. 1094 For example, an application can disable the deferred context setup by 1095 using the socket option as follows: 1097 int optval; 1099 optval = 0; 1101 setsockopt(fd, SOL_SHIM, SHIM_DEFERRED_CONTEXT_SETUP, 1102 &optval, sizeof(optval)); 1104 For example, an application can get the option value as follows. 1106 int optval; 1107 int len; 1109 len = sizeof(optval); 1111 getsockopt(fd, SOL_SHIM, SHIM_DEFERRED_CONTEXT_SETUP, 1112 &optval, &len); 1114 5.15. Applicability 1116 All the socket options for the shim sub-layer except for 1117 SHIM_HOT_STANDBY are applicable to both connected and unconnected 1118 sockets. SHIM_HOT_STANDBY socket option is applicable only to 1119 connected sockets. This is because the shim sub-layer cannot 1120 initiate context establishment to create a hot standby connection 1121 when the peer's IP address is not known until the application writes 1122 data to the unconnected socket. 1124 5.16. Error Handling 1126 If successful, getsockopt() and setsockopt() return 0; otherwise, the 1127 functions return -1 and set errno to indicate an error. 1129 The following are new error values defined for some shim specific 1130 socket options indicating that the getsockopt() or setsockopt() 1131 finished incompletely: 1133 EINVALIDLOCATOR 1134 This indicates that at least one of the necessary validations 1135 inside the shim sub-layer for the specified locator has failed. 1136 In case of SHIM6, there are two kinds of verifications required 1137 for security reasons prior to sending an IP packet to the peer's 1138 new locator; one is the return routability (check if the peer is 1139 actually willing to receive data with the specified locator) and 1140 the other one is the verification based on crypto identifier 1141 mechanisms [RFC3972], [RFC5535]. 1143 6. Ancillary Data for Multihoming Shim Sub-layer 1145 This section provides definitions of ancillary data to be used for 1146 locator management and notification from/to the shim sub-layer to/ 1147 from application. 1149 When the application performs locator management by sendmsg() or 1150 recvmsg(), a member of the msghdr structure (given in Figure 3) 1151 called msg_control holds a pointer to the buffer in which one ore 1152 more shim specific ancillary data objects may be stored. An 1153 ancillary data object can store a single locator. It should be 1154 possible to process the shim specific ancillary data object by the 1155 existing macros defined in the Posix standard and [RFC3542]. 1157 struct msghdr { 1158 caddr_t msg_name; /* optional address */ 1159 u_int msg_namelen; /* size of address */ 1160 struct iovec *msg_iov; /* scatter/gather array */ 1161 u_int msg_iovlen; /* # elements in msg_iov */ 1162 caddr_t msg_control; /* ancillary data, see below */ 1163 u_int msg_controllen; /* ancillary data buffer len */ 1164 int msg_flags; /* flags on received message */ 1165 }; 1167 Figure 3: msghdr structure 1169 In the case of unconnected socket, msg_name stores the socket address 1170 of the peer which should be considered to be an identifier rather 1171 than a locator. SHIM_LOC_PEER_RECV should be used to get the locator 1172 of the peer node. 1174 Table 2 is a list of the shim specific ancillary data which can be 1175 used for locator management by recvmsg() or sendmsg(). In any case, 1176 the value of cmsg_level must be set as SOL_SHIM. 1178 +---------------------+-----------+-----------+-----------------+ 1179 | cmsg_type | sendmsg() | recvmsg() | cmsg_data[] | 1180 +---------------------+-----------+-----------+-----------------+ 1181 | SHIM_LOC_LOCAL_RECV | | o | *1 | 1182 | SHIM_LOC_PEER_RECV | | o | *1 | 1183 | SHIM_LOC_LOCAL_SEND | o | | *1 | 1184 | SHIM_LOC_PEER_SEND | o | | *1 | 1185 | SHIM_FEEDBACK | o | | shim_feedback{} | 1186 +---------------------+-----------+-----------+-----------------+ 1188 Table 2: Shim specific ancillary data 1190 *1: cmsg_data[] includes a single sockaddr_in{} or sockaddr_in6{} and 1191 padding if necessary 1193 6.1. Get Locator from Incoming Packet 1195 An application can get locator information from the received IP 1196 packet by specifying the shim specific socket options for the socket. 1197 When SHIM_LOC_LOCAL_RECV and/or SHIM_LOC_PEER_RECV socket options are 1198 set, the application can retrieve local and/or remote locator from 1199 the ancillary data. 1201 6.2. Set Locator for Outgoing Packet 1203 An application can specify the locators to be used for transmitting 1204 an IP packet by sendmsg(). When the ancillary data of cmsg_type 1205 SHIM_LOC_LOCAL_SEND and/or SHIM_LOC_PEER_SEND are specified, the 1206 application can explicitly specify the source and/or the destination 1207 locators to be used for the communication over the socket. 1209 Note that the effect is limited to the datagram transmitted by the 1210 sendmsg(). 1212 If the specified locator pair is verified, the shim sub-layer 1213 overrides the locators of the IP packet. 1215 An error EINVALIDLOCATOR is returned when validation of the specified 1216 locator failed. 1218 6.3. Notification from Application to Multihoming Shim Sub-layer 1220 An application may provide feedbacks to the shim sub-layer about the 1221 communication status. Such feedbacks are particularly useful for the 1222 shim sub-layer in the absence of REAP mechanism to monitor the 1223 reachability status of the currently used locator pair in a given 1224 shim context. 1226 The notification can be made by sendmsg() specifying a new ancillary 1227 data called SHIM_FEEDBACK. The ancillary data can be handled by 1228 specifying SHIM_FEEDBACK option in cmsg_type. 1230 An error ENOENT is returned when there is no context associated with 1231 the socket. 1233 See Section 7.3 for details of the data structure to be used. 1235 It is outside the scope of this document how the shim sub-layer would 1236 react when a feedback is provided by an application. 1238 6.4. Notification from Multihoming Shim Sub-layer to Application 1240 The shim sub-layer MAY provide notification about a locator change 1241 within a multihome shim context to applications that have concern 1242 with the context. Such a notification may be useful, for example, 1243 for an application which is sensitive to the characteristics of the 1244 current path. A locator change is caused when either of local or 1245 peer's locator (or both) is changed. Note that locators discussed 1246 here are the ones that appear in the IP packet header, and not the 1247 ones that are included in the locator list. A locator change may 1248 take place asynchronously. 1250 The notification is handled as an out-of-band data by the 1251 application. 1252 1. Application calls the select() system call by setting non-NULL 1253 value for the fourth argument. 1254 2. When there is a notification, the application reads out-of-band 1255 data from the socket by calling recvmsg(). 1256 3. The application checks the flag in the msghdr (msg_flags) to see 1257 if there is any notification about locator change delivered. If 1258 the MSG_SHIM_LOCATOR_CHANGE flag is set, application parses the 1259 chain of control message to read a pair of ancillary data objects 1260 which contains the source locator and the destination locator. 1261 Note that the direction of locator change is distinguished by the 1262 value of cmsg_type; SHIM_LOC_*_RECV is used for inbound locator 1263 change, and SHIM_LOC_*_SEND is used for outbound locator change. 1265 There is no restriction in terms of applicability of the notification 1266 about locator change. The notification can be delivered to any type 1267 of socket (connected or unconnected, stream-oriented or datagram- 1268 oriented). 1270 6.5. Applicability 1272 All the ancillary data for the shim sub-layer is applicable to both 1273 connected and unconnected sockets. 1275 A care is needed when the SHIM_LOC_*_RECV socket option is used for 1276 stream-oriented sockets (e.g., TCP sockets) because there is no one- 1277 to-one mapping between a single send or receive operation and the 1278 data (e.g., a TCP segment) being received. In other words, there is 1279 no gurantee that the locator(s) set in the SHIM_LOC_*_RECV ancillary 1280 data is identical to the locator(s) that appear in the IP packets 1281 received. The shim sub-layer SHOULD provide the latest locator 1282 information to the application in response to the SHIM_LOC_*_RECV 1283 socket option. 1285 7. Data Structures 1287 This section data structures for the shim sub-layer. These data 1288 structures are either used as a parameter for setsockopt() or 1289 getsockopt() (as mentioned in Section 5) or as a parameter for 1290 ancillary data to be processed by sendmsg() or recvmsg() (as 1291 mentioned in Section 6). 1293 7.1. Placeholder for Locator Information 1295 As defined in Section 5, the SHIM_LOC_LOCAL_PREF, SHIM_LOC_PEER_PREF, 1296 SHIM_LOCLIST_LOCAL, and SHIM_LOCLIST_PEER socket options need to 1297 handle one or more locator information. Locator information includes 1298 not only the locator itself but also additional information about the 1299 locator which is useful for locator management. A new data structure 1300 is defined to serve as a placeholder for the locator information. 1302 Figure 4 illustrates the data structure called shim_locator which 1303 stores a locator information. 1305 struct shim_locator { 1306 uint8_t lc_family; /* address family */ 1307 uint8_t lc_proto; /* protocol */ 1308 uint16_t lc_port; /* port number */ 1309 uint16_t lc_flags; /* flags */ 1310 uint16_t lc_pref; /* preference value */ 1311 uint32_t lc_ifidx; /* interface index */ 1312 struct in6_addr lc_addr; /* address */ 1313 }; 1315 Figure 4: shim locator structure 1317 lc_family 1318 Address family of the locator (e.g. AF_INET, AF_INET6). It is 1319 required that the parameter contains non-zero value indicating the 1320 exact address family of the locator. 1322 lc_proto 1323 Internet Protocol number for the protocol which is used to handle 1324 locator behind NAT. Typically, this value is set as UDP (17) when 1325 the locator is a UDP encapsulation interface. 1326 lc_port 1327 Port number which is used for handling locator behind NAT. 1328 lc_flags 1329 Each bit of the flags represents a specific characteristics of the 1330 locator. Hash Based Address (HBA) is defined as 0x01. 1331 Cryptographically Generated Address (CGA) is defined as 0x02. 1332 lc_pref 1333 Preference of the locator. The preference is represented by an 1334 integer. 1335 lc_ifidx 1336 Interface index of the network interface to which the locator is 1337 assigned. This field should be valid only in a read 1338 (getsockopt()) operation. 1339 lc_addr 1340 Contains the locator. In the case where a locator whose size is 1341 smaller than 16 bytes, an encoding rule should be provided for 1342 each locator of a given address family. For instance, in case of 1343 AF_INET (IPv4), the locator should be in the format of an IPv4- 1344 mapped IPv6 address as defined in [RFC4291]. 1346 7.1.1. Handling Locator behind NAT 1348 Note that the locator information MAY contain a locator behind a 1349 Network Address Translator (NAT). Such a situation may arise when 1350 the host is behind the NAT and uses a local address as a source 1351 locator to communicate with the peer. Note that a NAT traversal 1352 mechanism for HIP is defined, which allows HIP host to tunnel control 1353 and data traffic over UDP[I-D.ietf-hip-nat-traversal]. Note also 1354 that the locator behind NAT is not necessarily an IPv4 address but it 1355 can be an IPv6 address. Below is an example where the application 1356 sets a UDP encapsulation interface as a source locator when sending 1357 IP packets. 1359 struct shim_locator locator; 1360 struct in6_addr ia6; 1362 /* copy the private IPv4 address to the ia6 as an IPv4-mapped 1363 IPv6 address */ 1365 memset(&locator, 0, sizeof(locator)); 1367 /* fill shim_locator data structure */ 1368 locator.lc_family = AF_INET; 1369 locator.lc_proto = IPPROTO_UDP; 1370 locator.lc_port = 50500; 1371 locator.lc_flags = 0; 1372 locator.lc_pref = 0; 1373 locator.lc_ifidx = 3; 1375 memcpy(&locator.lc_addr, &ia6, sizeof(ia6)); 1377 setsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_SEND, &locator, 1378 sizeof(locator)); 1380 Figure 5: Handling locator behind NAT 1382 7.2. Path Exploration Parameter 1384 As defined in Section 5, SHIM_PATHEXPLORE allows application to set 1385 or read the parameters for path exploration and failure detection. A 1386 new data structure called shim_pathexplore is defined to store the 1387 necessary parameters. Figure 6 illustrates the data structure. The 1388 data structure can be passed to getsockopt() or setsockopt() as an 1389 argument. 1391 struct shim_pathexplore { 1392 uint8_t pe_probenum; /* # of initial probe */ 1393 uint8_t pe_keepaliveto; /* Keepalive Timeout */ 1394 uint16_t pe_initprobeto; /* Initial Probe Timeout */ 1395 uint32_t pe_reserved; /* reserved */ 1396 }; 1398 Figure 6: path explore structure 1400 pe_probenum 1401 Indicates the number of initial probe messages to be sent. 1402 Default value of this parameter should follow what is specified in 1403 [RFC5534]. 1405 pe_keepaliveto 1406 Indicates timeout value for detecting a failure when the host does 1407 not receive any packets for a certain period of time while there 1408 is outbound traffic. When the timer expires, path exploration 1409 procedure will be carried out by sending a REAP Probe message. 1410 Default value of this parameter should follow what is specified in 1411 [RFC5534]. 1412 pe_initprobeto 1413 Indicates retransmission timer of REAP Probe message in 1414 milliseconds. Note that this timer is applied before exponential 1415 back-off is started. A REAP Probe message for the same locator 1416 pair may be retransmitted. Default value of this parameter should 1417 follow what is specified in [RFC5534]. 1418 pe_reserved 1419 A reserved field for future extension. By default, the field 1420 should be initialized to zero. 1422 7.3. Feedback Information 1424 As mentioned in Section 6.3, applications can inform the shim sub- 1425 layer about the status of unicast reachability of the locator pair 1426 currently in use. The feedback information can be handled by using 1427 ancillary data called SHIM_FEEDBACK. A new data structure named 1428 shim_feedback is illustrated in Figure 7. 1430 struct shim_feedback { 1431 uint8_t fb_direction; /* direction of traffic */ 1432 uint8_t fb_indicator; /* indicator (1-3) */ 1433 uint16_t fb_reserved; /* reserved */ 1434 }; 1436 Figure 7: feedback information structure 1438 direction 1439 Indicates direction of reachability between a locator pair in 1440 question. A value 0 indicates outbound and a value 1 indicates 1441 inbound direction. 1442 indicator 1443 A value indicating the degree of satisfaction of a unidirectional 1444 reachability for a given locator pair. 1445 * 0: Default value. Whenever this value is specified the 1446 feedback information must not be processed by the shim sub- 1447 layer. 1448 * 1: Unable to connect. There is no unidirectional reachability 1449 between the locator pair in question. 1450 * 2: Unsatisfactory. The application is not satisfied with the 1451 unidirectional reachability between the locator pair in 1452 question. 1454 * 3: Satisfactory. There is satisfactory unidirectional 1455 reachability between the locator pair in question. 1456 reserved 1457 Reserved field. Must be ignored by the receiver. 1459 8. System Requirements 1461 This section gives system requirements posed by the sockets API 1462 defined in this document. There exist requirements for the system 1463 (kernel) to maintain the association between sockets and shim 1464 contexts. 1466 As addressed in Section 5, all the socket options and ancillary data 1467 defined in this document except for the SHIM_HOT_STANDBY socket 1468 option are applicable to both connected and unconnected sockets. 1470 There are less system requirements to enable support for applications 1471 that use connected sockets. This is because the kernel can maintain 1472 the association between a connected socket and a shim context in a 1473 static manner because a connected socket is bound to a source and 1474 destination IP addresses (identifiers). The kernel should be able to 1475 identify shim context associated with a connected socket by searching 1476 shim context keyed by the pair of source and destination identifiers. 1477 However, this is not the case for unnconnected sockets. The kernel 1478 needs to dynamically resolve association between an unconnected 1479 socket and a shim context, if any, upon packet processing. As to 1480 outbound packet processing, the kernel needs to check if there is any 1481 shim context whose EID pair matches with the source and destination 1482 IP addresses of the user data originating from an unconnected socket. 1483 If a matching context is found, the shim sub-layer performs packet 1484 processing taking the application's preference into account. Note 1485 that the shim sub-layer should be able to backtrack the socket from 1486 which the user data was originated. As to inbound packet processing, 1487 the shim sub-layer needs to check not only the IP header but also the 1488 transport layer protocol header to resolve the destination socket. 1489 If the destination socket is resolved and it contains any values 1490 concerning the shim sub-layer socket options, the shim sub-layer 1491 processes the IP packet as requested (e.g., set locator information 1492 of received packet in the ancillary data). 1494 9. Relation to Existing Sockets API Extensions 1496 This section explains relation between the sockets API defined in 1497 this document and the existing sockets API extensions. 1499 As mentioned in Section 5, the basic assumption is that the existing 1500 sockets API continues to work above the shim sub-layer. This means 1501 that, the existing sockets API deals with identifiers, and the 1502 sockets API defined in this document deals with locators. 1504 SHIM_LOC_LOCAL_PREF and SHIM_LOC_PEER_PREF socket options are 1505 semantically similar to the IPV6_PKTINFO socket API in the sense that 1506 both provide a means for application to set the source IP address of 1507 outbound IP packets. 1509 SHIM_LOC_LOCAL_RECV and SHIM_LOC_PEER_RECV socket options are 1510 semantically similar to the IP_RECVDSTADDR and IPV6_PKTINFO socket 1511 APIs in the sense that both provides a means for application to get 1512 the source and/or destination IP address of inbound IP packets. 1514 getsockname() and getpeername() enable application to get 'name' of 1515 the communication endpoints which is represented by a pair of IP 1516 address and port number assigned to the socket. getsockname() gives 1517 IP address and port number assigned to the socket on the local side, 1518 and getpeername() gives IP address and port number of the peer side. 1520 10. Operational Considerations 1522 This section gives operational considerations of the sockets API 1523 defined in this document. 1525 10.1. Conflict Resolution 1527 There may be a conflicting situation when different applications 1528 specify difference preference for the same shim context. For 1529 instance, application A and B may establish communication with the 1530 same EID pair while both applications have different preference in 1531 their choice of local locator. The notion of context forking in 1532 SHIM6 can resolve the conflicting situation. 1534 Socket options defined in Section 5 may cause conflicting situation 1535 when the target context is shared by multiple applications. In such 1536 a case, the socket handler should inform the shim sub-layer that 1537 context forking is required. In SHIM6, when a context is forked, an 1538 unique identifier called Forked Instance Identifier (FII) is assigned 1539 to the newly forked context. The forked context is then exclusively 1540 associated with the socket through which non-default preference value 1541 was specified. The forked context is maintained by the shim sub- 1542 layer during the lifetime of associated socket instance. When the 1543 socket is closed, the shim sub-layer SHOULD delete associated 1544 context. When a forked context is torn down, the SHIM6 1545 implementation should notify the peer about the deletion of forked 1546 context. 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 such as SIIT[RFC2765]. 1557 As addressed in the SIIT specification, some of the features (IPv6 1558 routing headers, hop-by-hop extension headers, or destination 1559 headers) from IPv6 are not convertible to IPv4. In addition, notion 1560 of source routing is not exactly the same in IPv4 and IPv6. This 1561 means that an error may occur during the conversion of identifier and 1562 locator. It is ffs exactly how the shim sub-layer should behave in 1563 such erroneous cases. 1565 11. IANA Considerations 1567 This document contains no IANA consideration. 1569 12. Protocol Constants and Variables 1571 This section defines protocol constants and variables. 1572 SHIM_MAX_LOCATORS The maximum number of the locators to be included 1573 in a locator list. 32. 1575 13. Security Considerations 1577 This section gives security considerations of the API defined in this 1578 document. 1580 13.1. Treatment of Unknown Locator 1582 When sending IP packets, application may request use of unknown 1583 locator for the source and/or destination locators. Note that 1584 treatment of unknown locator can be a subject of security 1585 considerations because use of invalid source and/or destination 1586 locator may cause redirection attack. 1588 13.1.1. Treatment of Unknown Source Locator 1590 The shim sub-layer checks if the requested locator is available on 1591 any of the local interface. If not, the shim sub-layer MUST reject 1592 the request and return an error message with the EINVALIDLOCATOR code 1593 to the application. If the locator is confirmed to be available, the 1594 shim sub-layer SHOULD initiate the procedure to update the locator 1595 list. 1597 Use of the following socket options and ancillary data may require 1598 treatment of unknown source locator: 1599 o SHIM_LOC_LOCAL_SEND 1600 o SHIM_LOC_LOCAL_PREF 1601 o SHIM_LOC_LIST_LOCAL 1603 13.1.2. Treatment of Unknown Destination Locator 1605 If the shim sub-layer turns out to be SHIM6, the SHIM6 implementation 1606 MUST reject the request for using unknown destination locator. 1608 If the shim sub-layer turns out to be HIP, the HIP implementation MAY 1609 accept the request for using unknown destination locator. 1611 Use of the following socket options and ancillary data may require 1612 treatment of unknown destination locator: 1613 o SHIM_LOC_PEER_SEND 1614 o SHIM_LOC_PEER_PREF 1615 o SHIM_LOC_LIST_PEER 1617 14. Changes 1619 14.1. Changes from version 00 to version 01 1621 o Define shim_locator{} data type which is a placeholder for 1622 locator. 1623 o Define shim_pathexplore{} data type in which a set of REAP 1624 parameters are stored. 1625 o Remove descriptions about "stickiness" of socket options. 1626 o Deprecate SHIM_IF_RECV and SHIM_IF_SEND socket options. 1627 o Give default value and how to disable given socket option. 1629 14.2. Changes from version 01 to version 02 1631 o Add section describing context forking. 1632 o Rephrase conclusion section. 1633 o Separate normative references from informative references. 1634 o Remove texts from discussion section that are not relevant to the 1635 contents of the document. 1636 o Add section describing change history (this section). 1638 14.3. Changes from version 02 to version 03 1640 o Add an Appendix section describing the issue of context forking. 1642 14.4. Changes from version 03 to version 04 1644 o Updated reference. 1645 o Correct typo and grammatical errors. 1647 14.5. Changes from version 04 to version 05 1649 o Added definition of SHIM_FEEDBACK ancillary data. 1650 o Added an example of code using the SHIM_LOCLIST_LOCAL 1651 o Added SHIM_LOC_LOCAL_SEND and SHIM_LOC_PEER_SEND socket options. 1653 14.6. Changes from version 05 to version 06 1655 o Updated references. 1657 14.7. Changes from version 06 to version 07 1659 o Resolved editorial issues. 1661 14.8. Changes from version 07 to version 08 1663 No changes are made except for updates of the references. 1665 14.9. Changes from version 08 to version 09 1667 o Updated texts for Section 1 and Section 5 according to the 1668 comments provided by Samu Varjonen. 1669 o Made it clear that downgrading the multihoming shim support (i.e., 1670 specifying value 1 with the SHIM_DONTSHIM socket option) is only 1671 allowed before the socket is connected. 1672 o Updated locator information (shim_locator{}) so that it can 1673 contain a locator behind NAT. 1675 14.10. Changes from version 09 to version 10 1677 o Addressed applicability of socket options and ancillary data for 1678 the shim sub-layer. 1679 o Addressed system requirements. 1680 o Removed unnecessary description about deprecated socket option 1681 (SHIM_IF_RECV). 1683 14.11. Changes from version 10 to version 11 1685 o Added short descriptions about connected sockets and unconnected 1686 sockets. 1687 o Relaxed applicability of the socket options. 1688 o Relaxed applicability of the ancillary data. 1689 o Added notification about locator change. 1691 14.12. Changes from version 11 to version 12 1693 o Reflected comments from Brian Karpenter 1694 o Reflected comments from Michael Scharf 1696 15. Acknowledgments 1698 Authors would like to thank Jari Arkko who participated in the 1699 discussion that lead to the first version of this document, and 1700 Tatuya Jinmei who thoroughly reviewed the early version of this draft 1701 and provided detailed comments on sockets API related issues. Thomas 1702 Henderson provided valuable comments especially from HIP 1703 perspectives. 1705 Authors sincerely thank to the following people for their help to 1706 improve this document: Samu Varjonen and Dmitriy Kuptsov. 1708 16. References 1710 16.1. Normative References 1712 [POSIX] "IEEE Std. 1003.1-2001 Standard for Information Technology 1713 -- Portable Operating System Interface (POSIX). Open group 1714 Technical Standard: Base Specifications, Issue 6, 1715 http://www.opengroup.org/austin", December 2001. 1717 [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, 1718 "Advanced Sockets Application Program Interface (API) for 1719 IPv6", RFC 3542, May 2003. 1721 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 1722 (HIP) Architecture", RFC 4423, May 2006. 1724 [RFC5533] Bagnulo, M. and E. Nordmark, "Level 3 multihoming shim 1725 protocol", RFC 5533, June 2009. 1727 [RFC5534] Arkko, J. and I. Beijnum, "Failure Detection and Locator 1728 Pair Exploration Protocol for IPv6 Multihoming", RFC 5534, 1729 June 2009. 1731 16.2. Informative References 1733 [I-D.ietf-hip-nat-traversal] 1734 Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. 1735 Keranen, "Basic HIP Extensions for Traversal of Network 1736 Address Translators", Internet 1737 Draft draft-ietf-hip-nat-traversal-09, October 2009. 1739 [I-D.ietf-shim6-app-refer] 1740 Nordmark, E., "Shim6 Application Referral Issues", 1741 draft-ietf-shim6-app-refer-00 (work in progress), 1742 July 2005. 1744 [I-D.ietf-shim6-applicability] 1745 Abley, J., Bagnulo, M., and A. Garcia-Martinez, 1746 "Applicability Statement for the Level 3 Multihoming Shim 1747 Protocol (Shim6)", draft-ietf-shim6-applicability-04 (work 1748 in progress), November 2009. 1750 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 1751 (SIIT)", RFC 2765, February 2000. 1753 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1754 RFC 3972, March 2005. 1756 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1757 Architecture", RFC 4291, February 2006. 1759 [RFC5535] Bagnulo, M., "Hash Based Addresses (HBA)", RFC 5535, 1760 June 2009. 1762 Appendix A. Context Forking 1764 In this section, an issue concerning context forking and its relation 1765 to the multihoming shim API are discussed. 1767 SHIM6 supports a notion of context forking. A peer may decide to 1768 fork a context for certain reason (e.g. upper layer protocol prefers 1769 to use different locator pair than the one defined in available 1770 context). The procedure of forking context is done similar to the 1771 normal context establishment, performing the 4-way message exchange. 1772 A peer who has decided to fork a context initiates the context 1773 establishment. Hereafter, we call this peer the "initiator". The 1774 peer of the initiator is called the "responder". 1776 Once the forked context is established between the peers, on the 1777 initiator side, it is possible to apply forked context to the packet 1778 flow since the system maintains an association between the forked 1779 context and the socket owned by the application that has requested 1780 the context forking. How this association is maintained is an 1781 implementation specific issue. However, on the responder side, there 1782 is a question how the outbound packet can be multiplexed by the shim 1783 sub-layer because there are more than one SHIM6 contexts that match 1784 with the ULID pair of the packet flow. There is a need to 1785 differentiate packet flows not only by the ULID pairs but by some 1786 other information and associate a given packet flow with a specific 1787 context. 1789 Figure 8 gives an example of a scenario where two communicating peers 1790 fork a context. Initially, there has been a single transaction 1791 between the peers, by the application 1 (App1). Accordingly, another 1792 transaction is started, by application 2 (App2). Both of the 1793 transactions are made based on the same ULID pair. The first context 1794 pair (Ctx1) is established for the transaction of App1. Given the 1795 requests from App2, the shim sub-layer on Peer 1 decides to fork a 1796 context. Accordingly, a forked context (Ctx2) is established between 1797 the peers, which should be exclusively applied to the transaction of 1798 App2. Ideally, multiplexing and demultiplexing of packet flows that 1799 relate to App1 and App2 should be done as illustrated in Figure 8. 1800 However, as mentioned earlier, the responder needs to multiplex 1801 outbound flows of App1 and App2 somehow. Note that if a context 1802 forking occurs on the initiator side, a context forking needs to 1803 occur also on the responder side. 1805 Peer 1 Peer 2 1806 (initiator) (responder) 1808 +----+ +----+ +----+ +----+ 1809 |App1| |App2| |App1| |App2| 1810 +----+ +----+ +----+ +----+ 1811 |^ |^ ^| ^| 1812 v| v| |v |v 1813 -----S1-------------S2----- -----S1-------------S2----- 1814 || || || || 1815 || || || || 1817 Ctx1 Ctx2 Ctx1 Ctx2 1818 ULID: ULID: ULID: ULID: 1819 Loc: Loc: Loc: Loc: 1820 FII: 0 FII: 100 FII: 0 FII: 100 1822 |^ |^ ^| ^| 1823 || || || || 1824 || || || || 1825 \..............||....................../| || 1826 \.............||......................./ || 1827 || || 1828 \|...................................../| 1829 \....................................../ 1831 Figure 8: context forking 1833 Any solution is needed to overcome the problem mentioned above. 1835 Authors' Addresses 1837 Miika Komu 1838 Helsinki Institute for Information Technology 1839 Tammasaarenkatu 3 1840 Helsinki 1841 Finland 1843 Phone: +358503841531 1844 Fax: +35896949768 1845 Email: miika@iki.fi 1846 URI: http://www.hiit.fi/ 1847 Marcelo Bagnulo 1848 Universidad Carlos III de Madrid 1849 Av. Universidad 30 1850 Leganes 28911 1851 SPAIN 1853 Phone: +34 91 6248837 1854 Email: marcelo@it.uc3m.es 1855 URI: http://it.uc3m.es/marcelo 1857 Kristian Slavov 1858 Ericsson Research Nomadiclab 1859 Hirsalantie 11 1860 Jorvas FI-02420 1861 Finland 1863 Phone: +358 9 299 3286 1864 Email: kristian.slavov@ericsson.com 1866 Shinta Sugimoto (editor) 1867 Nippon Ericsson K.K. 1868 Koraku Mori Building 1869 1-4-14, Koraku, Bunkyo-ku 1870 Tokyo 112-0004 1871 Japan 1873 Phone: +81 3 3830 2241 1874 Email: shinta@sfc.wide.ad.jp