idnits 2.17.1 draft-ietf-shim6-multihome-shim-api-11.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 596: '...ltihoming shim support MUST be made by...' RFC 2119 keyword, line 599: '... EOPNOTSUPP MUST be returned....' RFC 2119 keyword, line 1246: '...g shim sub-layer MAY provide notificat...' RFC 2119 keyword, line 1284: '...g shim sub-layer SHOULD provide the la...' RFC 2119 keyword, line 1350: '...ator information MAY contain a locator...' (3 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 (December 7, 2009) is 5253 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 974 -- Looks like a reference, but probably isn't: '1' on line 984 ** Obsolete normative reference: RFC 4423 (Obsoleted by RFC 9063) -- Obsolete informational reference (is this intentional?): RFC 2765 (Obsoleted by RFC 6145) Summary: 3 errors (**), 0 flaws (~~), 5 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: June 10, 2010 UC3M 6 K. Slavov 7 S. Sugimoto, Ed. 8 Ericsson 9 December 7, 2009 11 Socket Application Program Interface (API) for Multihoming Shim 12 draft-ietf-shim6-multihome-shim-api-11 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 June 10, 2010. 37 Copyright Notice 39 Copyright (c) 2009 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 . . . . . . . . . . . . . . . . . . . . . . 29 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. Implications for Existing Socket API Extensions . . . . . . . 33 98 10. Resolving Conflicts with Preference Values . . . . . . . . . . 34 99 10.1. Implicit Forking . . . . . . . . . . . . . . . . . . . . 34 100 11. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 35 101 11.1. Naming at Socket Layer . . . . . . . . . . . . . . . . . 35 102 11.2. Additional Requirements from Applications . . . . . . . . 35 103 11.3. Issues of Header Conversion among Different Address 104 Family . . . . . . . . . . . . . . . . . . . . . . . . . 36 105 11.4. Handling of Unknown Locator Provided by Application . . . 36 106 12. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 107 12.1. Changes from version 00 to version 01 . . . . . . . . . . 36 108 12.2. Changes from version 01 to version 02 . . . . . . . . . . 37 109 12.3. Changes from version 02 to version 03 . . . . . . . . . . 37 110 12.4. Changes from version 03 to version 04 . . . . . . . . . . 37 111 12.5. Changes from version 04 to version 05 . . . . . . . . . . 37 112 12.6. Changes from version 05 to version 06 . . . . . . . . . . 37 113 12.7. Changes from version 06 to version 07 . . . . . . . . . . 37 114 12.8. Changes from version 07 to version 08 . . . . . . . . . . 37 115 12.9. Changes from version 08 to version 09 . . . . . . . . . . 38 116 12.10. Changes from version 09 to version 10 . . . . . . . . . . 38 117 12.11. Changes from version 10 to version 11 . . . . . . . . . . 38 118 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 119 14. Security Considerations . . . . . . . . . . . . . . . . . . . 38 120 15. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 38 121 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39 122 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 123 17.1. Normative References . . . . . . . . . . . . . . . . . . 39 124 17.2. Informative References . . . . . . . . . . . . . . . . . 40 125 Appendix A. Context Forking . . . . . . . . . . . . . . . . . . . 40 126 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 128 1. Introduction 130 HIP and SHIM6 have a commonality in their protocol design in the 131 sense that the semantic roles of an IP address, i.e., an identifier 132 and a locator, are distinguished. Separation of identifier and 133 locator is done by introducing a "shim" inside the IP layer which 134 maintains mapping of the identifier and associated locators. This 135 design principle is called "identifier/locator separation" and the 136 shim is referred to as a "shim sub-layer" in this document. 138 The shim sub-layer provides a nice property to present a stable 139 communication endpoints (i.e., identifiers) to the upper layer 140 protocols. An on-going session can be maintained even when the 141 locator associated with the identifier is changed, for instance, upon 142 a re-homing event under a multihomed environment. Therefore, upper 143 layer protocols, especially connection-oriented applications are no 144 more annoyed by the locator change thanks to the identifier/locator 145 separation mechanism. 147 While the identifier/locator separation removes negative impact of 148 locator change, it does not necessarily mean that applications are 149 always ignorant about locators. We rather think that applications 150 may want to have a control of locators in some cases. For instance, 151 an application may want to use a specific locator to send IP packets. 152 Such a control of locators is referred to as "locator management" in 153 this document. Besides, applications may want to turn on or off the 154 identifier/locator separation mechanism. This document defines API 155 that provides locator management and additional control of shim sub- 156 layer for applications. 158 This document recommends that the switching of identifier and locator 159 is done only once inside the TCP/IP stack of an endhost. That is, if 160 multiple shim sub-layers exist at the IP layer, any one of them 161 should be applied exclusively for a given flow. 163 As this document specifies sockets API extensions, it is written so 164 that the syntax and semantics are in line with the Posix standard 165 [POSIX] as much as possible. The API specified in this document 166 defines how to use ancillary data (aka cmsg) to access the locator 167 information with recvmsg() and/or sendmsg() I/O calls. The 168 definition of API is presented in C language and data types follow 169 the Posix format; intN_t means a singed integer of exactly N bits 170 (e.g. int16_t) and uintN_t means an unsigned integer of exactly N 171 bits (e.g. uint32_t). 173 The distinction between "connected" sockets and "unconnected" sockets 174 is important when discussing the applicability of the socket API 175 defined in this document. A connected socket is bound to a given 176 peer, whereas an unconnected socket is not bound to any specific 177 peers. That is, the destination of the user data is not known until 178 the application writes data to an unconnected socket. TCP sockets 179 are connected, by definition. UDP sockets are unconnected, unless 180 the application uses the connect() system call. 182 The target readers of this document are application programmers who 183 develop application software which may benefit greatly from 184 multihomed environments. In addition, this document aims to provide 185 necessary information for developers of multihoming shim protocols to 186 implement API for enabling advanced locator management. 188 2. Terminology 190 This section provides terminology used in this document. Basically 191 most of the terms used in this document are taken from the following 192 documents: 194 o SHIM6 Protocol Specification[RFC5533] 195 o HIP Architecture[RFC4423] 196 o Reachability Protocol (REAP)[RFC5534] 198 In this document, the term "IP" refers to both IPv4 and IPv6, unless 199 the protocol version is specifically mentioned. The following are 200 definitions of terms frequently used in this document: 202 o Endpoint identifier (EID) - The identifier used by the application 203 to specify the endpoint of a given communication. Applications 204 may handle EIDs in various ways such as long-lived connections, 205 callbacks, and referrals[I-D.ietf-shim6-app-refer]. 206 * In the case of SHIM6, an identifier called a ULID serves as an 207 EID. A ULID is chosen from locators available on the host. 208 * In the case of HIP, an identifier called a Host Identifier 209 serves as an EID. A Host Identifier is derived from the public 210 key of a given host. For the sake of backward compatibility 211 with the sockets API, the Host Identifier is represented in a 212 form of hash of public key. 213 o Locator - The IP address actually used to deliver IP packets. 214 Locators are present in the source and destination fields of the 215 IP header of a packet on the wire. 216 * List of locators - A list of locators associated with an EID. 217 There are two lists of locators stored in a given context. One 218 is associated with the local EID and the other is associated 219 with the remote EID. As defined in [RFC5533], the list of 220 locators associated with an EID 'A' is denoted as Ls(A). 222 * Preferred locator - The (source/destination) locator currently 223 used to send packets within a given context. As defined in 224 [RFC5533], the preferred locator of a host 'A' is denoted as 225 Lp(A). 226 o Shim - The conceptual sub-layer inside the IP layer which 227 maintains mappings between EIDs and locators. An EID can be 228 associated with more than one locator at a time when the host is 229 multihomed. The term 'shim' does not refer to a specific protocol 230 but refers to the conceptual sub-layer inside the IP layer. 231 o Identifier/locator adaptation - The adaptation performed at the 232 shim sub-layer which may end up re-writing the source and/or 233 destination addresses of an IP packet. In the outbound packet 234 processing, the EID pair is converted to the associated locator 235 pair. In the inbound packet processing, the locator pair is 236 converted to the EID pair. 237 o Context - The state information shared by a given pair of peers, 238 which stores a binding between the EID and associated locators. 239 Contexts are maintained by the shim sub-layer. 240 o Reachability detection - The procedure to check reachability 241 between a given locator pair. 242 o Path - The sequence of routers that an IP packet goes through to 243 reach the destination. 244 o Path exploration - The procedure to explore available paths for a 245 given set of locator pairs. 246 o Outage - The incident that prevents IP packets to flow from the 247 source locator to the destination locator. When there is an 248 outage, it means that there is no reachability between a given 249 locator pair. The outage may be caused by various reasons, such 250 as shortage of network resources, congestion, and human error 251 (faulty operation). 252 o Working address pair - The address pair is considered to be 253 "working" if the packet can safely travel from the source to the 254 destination where the packet contains the first address from the 255 pair as the source address and the second address from the pair as 256 the destination address. If reachability is confirmed in both 257 directions, the address pair is considered to be working bi- 258 directionally. 259 o Reachability protocol (REAP) - The protocol for detecting failure 260 and exploring reachability in a multihomed environment. REAP is 261 defined in [RFC5534]. 263 3. System Overview 265 Figure 1 illustrates the system overview. The shim sub-layer and 266 REAP component exist inside the IP layer. Applications use the 267 sockets API defined in this document to interface with the shim sub- 268 layer and the transport layer for locator management, failure 269 detection, and path exploration. 271 It may also be possible that the shim sub-layer interacts with the 272 transport layer, however, such an interaction is outside the scope of 273 this document. 275 +------------------------+ 276 | Application | 277 +------------------------+ 278 ^ ^ 279 ~~~~~~~~~~~~~|~Socket Interface|~~~~~~~~~~~~~~ 280 | v 281 +-----------|------------------------------+ 282 | | Transport Layer | 283 +-----------|------------------------------+ 284 ^ | 285 +-------------|-----|-------------------------------------+ 286 | v v | 287 | +-----------------------------+ +----------+ | IP 288 | | Shim |<----->| REAP | | Layer 289 | +-----------------------------+ +----------+ | 290 | ^ ^ | 291 +-----------------------|----------------------|----------+ 292 v v 293 +------------------------------------------+ 294 | Link Layer | 295 +------------------------------------------+ 297 Figure 1: System overview 299 4. Requirements 301 The following is a list of requirements from applications: 302 o Locator management. 303 * It should be possible to set preferred source and/or 304 destination locator within a given context: Lp(local) and/or 305 Lp(remote). 306 * It should be possible to get preferred source and/or 307 destination locator within a given context: Lp(local) and/or 308 Lp(remote). 309 * It should be possible to set a list of source and/or 310 destination locators within a given context: Ls(local) and 311 Ls(remote). 313 * It should be possible to get a list of source and/or 314 destination locators within a given context: Ls(local) and 315 Ls(remote). 316 o Notification from applications to the shim sub-layer about the 317 status of the communication. The notification occurs in an event- 318 based manner. Applications and/or upper layer protocols may 319 provide positive feedbacks or negative feedbacks to the shim sub- 320 layer. Note that these feedbacks are mentioned in [RFC5534]]: 321 * Applications and/or upper layer protocols (e.g., TCP) may 322 provide positive feedbacks to the shim sub-layer informing that 323 the communication is going well. 324 * Applications and/or upper layer protocols (e.g., TCP) may 325 provide negative feedbacks to the shim sub-layer informing that 326 the communication status is not satisfactory. TCP may detect a 327 problem when it does not receive any expected ACK message from 328 the peer. Besides, a receipt of an ICMP error message could be 329 a clue for the application to detect problems. The REAP module 330 may be triggered by these negative feedbacks and invoke the 331 path exploration procedure. 332 o Feedback from applications to the shim sub-layer. Applications 333 should be able to inform the shim sub-layer of the timeout values 334 for detecting failures, sending keepalives, and starting the 335 exploration procedure. In particular, applications should be able 336 to suppress keepalives. 337 o Hot-standby. Applications may request the shim sub-layer for the 338 hot-standby capability. This means that, alternative paths are 339 known to be working in advance of a failure detection. In such a 340 case, it is possible for the host to immediately replace the 341 current locator pair with an alternative locator pair. 342 o Eagerness for locator exploration. An application should be able 343 to inform the shim sub-layer of how aggressively it wants the REAP 344 mechanism to perform a path exploration (e.g., by specifying the 345 number of concurrent attempts of discovery of working locator 346 pairs) when an outage occurs on the path between the locator pair 347 in use. 348 o Providing locator information to applications. An application 349 should be able to obtain information about the locator pair which 350 was actually used to send or receive the packet. 351 * For inbound traffic, the application may be interested in the 352 locator pair which was actually used to receive the packet. 353 * For outbound traffic, the application may be interested in the 354 locator pair which was actually used to transmit the packet. 355 In this way, applications may have additional control on the 356 locator management. For example, an application becomes able to 357 verify if its preference for locator is actually applied to the 358 flow or not. 360 o Applications should be able to specify if they want to defer the 361 context setup, or if they want context establishment to be started 362 immediately in the case where there is no available context. A 363 deferred context setup means that the initiation of communication 364 should not be blocked to wait for completion of the context 365 establishment. 366 o Turn on/off shim. An application should be able to request to 367 turn on or turn off the multihoming support by the shim layer: 368 * Apply shim. The application should be able to explicitly 369 request the shim sub-layer to apply multihoming support. 370 * Don't apply shim. The application should be able to request 371 the shim sub-layer not to apply the multihoming support but to 372 apply normal IP processing at the IP layer. 373 o An application should be able to know if the communication is now 374 being served by the shim sub-layer or not. 375 o An application should be able to use a common interface to access 376 an IPv4 locator and an IPv6 locator. 378 5. Socket Options for Multihoming Shim Sub-layer 380 In this section, socket options that are specific to the shim sub- 381 layer are defined. 383 Table 1 shows a list of the socket options that are specific to the 384 multihoming shim sub-layer. An application may use these socket 385 options for a given socket either by the getsockopt() system call or 386 by the setsockopt() system call. All of these socket options are 387 defined at level SOL_SHIM. 389 The first column of Table 1 gives the name of the option. The second 390 and third columns indicate whether the option can be handled by the 391 getsockopt() system call and/or by the setsockopt() system call. The 392 fourth column provides a brief description of the socket option. The 393 fifth column shows the type of data structure specified along with 394 the socket option. By default, the data structure type is an 395 integer. 397 +-----------------------------+-----+-----+-----------------+-------+ 398 | optname | get | set | description | dtype | 399 +-----------------------------+-----+-----+-----------------+-------+ 400 | SHIM_ASSOCIATED | o | | Get the | int | 401 | | | | parameter which | | 402 | | | | indicates | | 403 | | | | whether if the | | 404 | | | | socket is | | 405 | | | | associated with | | 406 | | | | any shim | | 407 | | | | context or not. | | 408 | SHIM_DONTSHIM | o | o | Get or set the | int | 409 | | | | parameter which | | 410 | | | | indicates | | 411 | | | | whether to | | 412 | | | | employ the | | 413 | | | | multihoming | | 414 | | | | support by the | | 415 | | | | shim sub-layer | | 416 | | | | or not. | | 417 | SHIM_HOT_STANDBY | o | o | Get or set the | int | 418 | | | | parameter to | | 419 | | | | request the | | 420 | | | | shim sub-layer | | 421 | | | | to prepare a | | 422 | | | | hot-standby | | 423 | | | | connection. | | 424 | SHIM_LOC_LOCAL_PREF | o | o | Get or set the | *1 | 425 | | | | preferred | | 426 | | | | locator on the | | 427 | | | | local side for | | 428 | | | | the context | | 429 | | | | associated with | | 430 | | | | the socket. | | 431 | SHIM_LOC_PEER_PREF | o | o | Get or set the | *1 | 432 | | | | preferred | | 433 | | | | locator on the | | 434 | | | | remote side for | | 435 | | | | the context | | 436 | | | | associated with | | 437 | | | | the socket. | | 438 | SHIM_LOC_LOCAL_RECV | o | o | Get or set the | int | 439 | | | | parameter which | | 440 | | | | is used to | | 441 | | | | request the | | 442 | | | | shim sub-layer | | 443 | | | | to store the | | 444 | | | | destination | | 445 | | | | locator of the | | 446 | | | | received IP | | 447 | | | | packet. | | 448 | SHIM_LOC_PEER_RECV | o | o | Get or set the | int | 449 | | | | parameter which | | 450 | | | | is used to | | 451 | | | | request the | | 452 | | | | shim sub-layer | | 453 | | | | to store the | | 454 | | | | source locator | | 455 | | | | of the received | | 456 | | | | IP packet. | | 457 | SHIM_LOC_LOCAL_SEND | o | o | Get or set the | *2 | 458 | | | | source locator | | 459 | | | | of outgoing IP | | 460 | | | | packets. | | 461 | SHIM_LOC_PEER_SEND | o | o | Get or set the | *2 | 462 | | | | destination | | 463 | | | | locator of | | 464 | | | | outgoing IP | | 465 | | | | packets. | | 466 | SHIM_LOCLIST_LOCAL | o | o | Get or set the | *3 | 467 | | | | list of | | 468 | | | | locators | | 469 | | | | associated with | | 470 | | | | the local EID. | | 471 | SHIM_LOCLIST_PEER | o | o | Get or set the | *3 | 472 | | | | list of | | 473 | | | | locators | | 474 | | | | associated with | | 475 | | | | the peer's EID. | | 476 | SHIM_APP_TIMEOUT | o | o | Get or set the | int | 477 | | | | timeout value | | 478 | | | | for detecting | | 479 | | | | failure. | | 480 | SHIM_PATHEXPLORE | o | o | Get or set | *4 | 481 | | | | parameters for | | 482 | | | | path | | 483 | | | | exploration and | | 484 | | | | failure | | 485 | | | | detection. | | 486 | SHIM_CONTEXT_DEFERRED_SETUP | o | o | Get or set the | int | 487 | | | | parameter which | | 488 | | | | indicates | | 489 | | | | whether | | 490 | | | | deferred | | 491 | | | | context setup | | 492 | | | | is supported or | | 493 | | | | not. | | 494 +-----------------------------+-----+-----+-----------------+-------+ 496 Table 1: Socket options for multihoming shim sub-layer 498 *1: Pointer to a shim_locator which is defined in Section 7. 500 *2: Pointer to shim_locator data structure. 502 *3: Pointer to an array of shim_locator. 504 *4: Pointer to a shim_pathexplore which is defined in Section 7. 506 Figure 2 illustrates how the shim specific socket options fit into 507 the system model of socket API. The figure shows that the shim sub- 508 layer and the additional protocol components (IPv4 and IPv6) below 509 the shim sub-layer are new to the system model. As previously 510 mentioned, all the shim specific socket options are defined at the 511 SOL_SHIM level. This design choice brings the following advantages: 513 1. The existing sockets API continue to work at the layer above the 514 shim sub-layer. That is, those legacy API handle IP addresses as 515 identifiers. 516 2. With newly defined socket options for the shim sub-layer, the 517 application obtains additional control of locator management. 518 3. The shim specific socket options can be kept independent from 519 address family (IPPROTO_IP or IPPROTO_IPV6) and transport 520 protocol (IPPROTO_TCP or IPPROTO_UDP). 522 s1 s2 s3 s4 523 | | | | 524 +----------------|--|-------|--|----------------+ 525 | +-------+ +-------+ | 526 | IPPROTO_TCP | TCP | | UDP | | 527 | +-------+ +-------+ | 528 | | \ / | | 529 | | ----- | | 530 | | / \ | | 531 | +------+ +------+ | 532 | IPPROTO_IP | IPv4 | | IPv6 | IPPROTO_IPV6 | 533 | +------+ +------+ | 534 | \ / SOL_SOCKET 535 | +--------\-------/--------+ | 536 | SOL_SHIM | shim | | 537 | +--------/-------\--------+ | 538 | / \ | 539 | +------+ +------+ | 540 | | IPv4 | | IPv6 | | 541 | +------+ +------+ | 542 | | | | 543 +------------------|----------|-----------------+ 544 | | 545 IPv4 IPv6 546 Datagram Datagram 548 Figure 2: System model of sockets API with shim sub-layer 550 5.1. SHIM_ASSOCIATED 552 The SHIM_ASSOCIATED option is used to check whether the socket is 553 associated with any shim context or not. 555 This option is meaningful when the locator information of the 556 received IP packet does not tell whether the identifier/locator 557 adaptation is performed or not. Note that the EID pair and the 558 locator pair may be identical in some cases. 560 This option can be specified by getsockopt(). Thus, the option is 561 read-only and the result (0/1/2) is set in the option value (the 562 fourth argument of getsockopt()). 564 The data type of the option value is an integer. The option value 565 indicates the presence of shim context. A return value 1 means that 566 the socket is associated with a shim context at the shim sub-layer. 567 A return value 0 indicates that there is no shim context associated 568 with the socket. A return value 2 means that it is not known whether 569 the socket is associated with a shim context or not, and this must be 570 returned only when the socket is unconnected. In other words, the 571 returned value must be 0 or 1 when the socket is connected. 573 For example, the option can be used by the application as follows: 575 int optval; 576 int optlen = sizeof(optval); 578 getsockopt(fd, SOL_SHIM, SHIM_ASSOCIATED, &optval, &optlen); 580 5.2. SHIM_DONTSHIM 582 The SHIM_DONTSHIM option is used to request the shim layer not to 583 provide the multihoming support for the communication established 584 over the socket. 586 The data type of the option value is an integer, and it takes 0 or 1. 587 An option value 0 means that the multihoming shim sub-layer is 588 employed if available. An option value 1 means that the application 589 does not want the multihoming shim sub-layer to provide the 590 multihoming support for the communication established over the 591 socket. 593 Default value is set as 0, which means that the multihoming shim sub- 594 layer performs identifier/locator adaptation if available. 596 Any attempt to disable the multihoming shim support MUST be made by 597 the application before the socket is connected. If an application 598 makes such an attempt for a connected-socket, an error code 599 EOPNOTSUPP MUST be returned. 601 For example, an application can request the system not to apply the 602 multihoming support as follows: 604 int optval; 606 optval = 1; 608 setsockopt(fd, SOL_SHIM, SHIM_DONTSHIM, &optval, sizeof(optval)); 610 For example, the application can check the option value as follows: 612 int optval; 613 int len; 615 len = sizeof(optval); 616 getsockopt(fd, SOL_SHIM, SHIM_DONTSHIM, &optval, &len); 618 5.3. SHIM_HOT_STANDBY 620 The SHIM_HOT_STANDBY option is used to control the shim sub-layer 621 whether to employ a hot-standby connection for the socket or not. A 622 hot-standby connection is an alternative working locator pair to the 623 current locator pair. This option is effective only when there is a 624 shim context associated with the socket. 626 The data type of the option value is an integer. 628 The option value can be set by setsockopt(). 630 The option value can be read by getsockopt(). 632 By default, the value is set to 0, meaning that hot-standby 633 connection is disabled. 635 For example, an application can request establishment of a hot- 636 standby connection by using the socket option as follows: 638 int optval; 640 optval = 1; 642 setsockopt(fd, SOL_SHIM, SHIM_HOT_STANDBY, &optval, 643 sizeof(optval)); 645 For example, an application can get the option value by using the 646 socket option as follows: 648 int optval; 649 int len; 651 len = sizeof(optval); 653 getsockopt(fd, SOL_SHIM, SHIM_HOT_STANDBY, &optval, &len); 655 5.4. SHIM_PATHEXPLORE 657 The application may use this socket option to specify parameters 658 concerning path exploration. Path exploration is a procedure to find 659 an alternative locator pair to the current locator pair. As the REAP 660 specification defines, a peer may send Probe messages to find an 661 alternative locator pair. 663 The option is effective only when there is a shim context associated 664 with the socket. 666 The data type of the option value is a pointer to the buffer where a 667 set of information for path exploration is stored. The data 668 structure is defined in Section 7. 670 By default, the option value is set to NULL, meaning that the option 671 is disabled. 673 An error ENOENT will be returned when there is no context associated 674 with the socket. 676 For example, an application can set parameters for path exploration 677 by using the socket option as follows. 679 struct shim6_pathexplore pe; 681 pe.pe_probenum = 4; /* times */ 682 pe.pe_keepaliveto = 10; /* seconds */ 683 pe.pe_initprobeto = 500; /* milliseconds */ 684 pe.pe_reserved = 0; 686 setsockopt(fd, SOL_SHIM, SHIM_PATHEXPLORE, &pe, sizeof(pe)); 688 For example, an application can get parameters for path exploration 689 by using the socket option as follows. 691 struct shim6_pathexplore pe; 692 int len; 694 len = sizeof(pe); 696 getsockopt(fd, SOL_SHIM, SHIM_PATHEXPLORE, &pe, &len); 698 5.5. SHIM_LOC_LOCAL_PREF 700 The SHIM_LOC_LOCAL_PREF option is used to get or set preferred 701 locator on local side within a given context. Hence this option is 702 effective only when there is a shim context associated with the 703 socket. 705 The data type of the option value is a pointer to a locator 706 information data structure which is defined in Section 7. 708 By default, the option value is set to NULL, meaning that the option 709 is disabled. 711 The preferred locator can be set by setsockopt(). The shim sub-layer 712 shall verify requested locator before it updating the preferred 713 locator. 715 An application can get the preferred locator by getsockopt(). 717 An error ENOENT will be returned when there is no context associated 718 with the socket. 720 An error EINVALIDLOCATOR will be returned when the validation of the 721 specified locator failed. 723 For example, an application can set the preferred locator by using 724 the socket option as follows. Note that some members of the 725 shim_locator (lc_ifidx and lc_flags) are ignored in the set 726 operation. 728 struct shim_locator lc; 729 struct in6_addr ip6; 731 /* ...set the locator (ip6)... */ 733 memset(&lc, 0, sizeof(shim_locator)); 734 lc.lc_family = AF_INET6; /* IPv6 */ 735 lc.lc_ifidx = 0; 736 lc.lc_flags = 0; 737 lc.lc_preference = 255; 738 memcpy(lc.lc_addr, &ip6, sizeof(in6_addr)); 740 setsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_PREF, &lc, 741 sizeof(optval)); 743 For example, an application can get the preferred locator by using 744 the socket option as follows. 746 struct shim_locator lc; 747 int len; 749 len = sizeof(lc); 751 getsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_PREF, &lc, &len); 753 5.6. SHIM_LOC_PEER_PREF 755 The SHIM_LOC_PEER_PREF option is used to get or set preferred locator 756 on peer side within a given context. Hence this option is effective 757 only when there is a shim context associated with the socket. 759 The data type of the option value is a pointer to the locator 760 information data structure which is defined in Section 7. 762 By default, the option value is set to NULL, meaning that the option 763 is disabled. 765 The preferred locator can be set by setsockopt(). The shim sub-layer 766 shall verify requested locator before it updating the preferred 767 locator. 769 An application can get the preferred locator by getsockopt(). 771 An error ENOENT will be returned when there is no context associated 772 with the socket. 774 An error EINVALIDLOCATOR will be returned when the validation of the 775 requested locator fails. 777 The usage of the option is same as that of SHIM_LOC_LOCAL_PREF. Note 778 that some members of the shim_locator (lc_ifidx and lc_flags) are 779 ignored in the set operation. 781 5.7. SHIM_LOC_LOCAL_RECV 783 The SHIM_LOC_LOCAL_RECV option can be used to request the shim sub- 784 layer to store the destination locator of the received IP packet in 785 an ancillary data object which can be accessed by recvmsg(). Hence 786 this option is effective only when there is a shim context associated 787 with the socket. 789 The data type of the option value is integer. The option value 790 should be binary (0 or 1). By default, the option value is set to 0, 791 meaning that the option is disabled. 793 An application can set the option value by setsockopt(). 795 An application can get the option value by getsockopt(). 797 See Section 6 for the procedure to access locator information stored 798 in the ancillary data objects. 800 An error ENOENT will be returned when there is no context associated 801 with the socket. 803 For example, an application can request the shim sub-layer to store 804 destination locator by using the socket option as follows. 806 int optval; 808 optval = 1; 810 setsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_RECV, &optval, 811 sizeof(optval)); 813 For example, an application can get the option value as follows. 815 int optval; 816 int len; 818 len = sizeof(optval); 820 getsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_RECV, &optval, &len); 822 5.8. SHIM_LOC_PEER_RECV 824 The SHIM_LOC_PEER_RECV option is used to request the shim sub-layer 825 to store the source locator of the received IP packet in an ancillary 826 data object which can be accessed by recvmsg(). Hence this option is 827 effective only when there is a shim context associated with the 828 socket. 830 The data type of the option value is integer. The option value 831 should be binary (0 or 1). By default, the option value is set to 0, 832 meaning that the option is disabled. 834 The option value can be set by setsockopt(). 836 The option value can be read by getsockopt(). 838 See Section 6 for the procedure to access locator information stored 839 in the ancillary data objects. 841 An error ENOENT will be returned when there is no context associated 842 with the socket. 844 The usage of the option is same as that of SHIM_LOC_LOCAL_RECV 845 option. 847 5.9. SHIM_LOC_LOCAL_SEND 849 The SHIM_LOC_LOCAL_SEND option is used to request the shim sub-layer 850 to use a specific locator as the source locator for the IP packets to 851 be sent from the socket. Hence this option is effective only when 852 there is a shim context associated with the socket. 854 The data type of option value is pointer to shim_locator data 855 structure. 857 An application can set the local locator by setsockopt() providing a 858 valid locator which is stored in a shim_locator data structure. When 859 a zero-filled locator is specified, pre-existing setting of local 860 locator is inactivated. 862 An application can get the local locator by getsockopt(). 864 An error ENOENT will be returned when there is no context associated 865 with the socket. 867 An error EINVALIDLOCATOR will be returned when invalid locator is 868 specified. 870 For example, an application can request the shim sub-layer to use a 871 specific local locator by using the socket option as follows. 873 struct shim_locator locator; 874 struct in6_addr ia6; 876 /* an IPv6 address preferred for the source locator is copied 877 to the parameter ia6 */ 879 memset(&locator, 0, sizeof(locator)); 881 /* fill shim_locator data structure */ 882 locator.lc_family = AF_INET6; 883 locator.lc_ifidx = 1; 884 locator.lc_flags = 0; 885 locator.lc_preference = 0; 886 memcpy(&locator.lc_addr, &ia6, sizeof(ia6)); 888 setsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_SEND, &locator, 889 sizeof(locator)); 891 For example, an application can get the preferred local locator by 892 using the socket option as follows. 894 struct shim_locator locator; 896 memset(&locator, 0, sizeof(locator)); 898 getsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_SEND, &locator, 899 sizeof(locator)); 901 /* check locator */ 903 5.10. SHIM_LOC_PEER_SEND 905 The SHIM_LOC_PEER_SEND option is used to request the shim sub-layer 906 to use a specific locator for the destination locator of IP packets 907 to be sent from the socket. Hence this option is effective only when 908 there is a shim context associated with the socket. 910 The data type of the option value is a pointer to shim_locator data 911 structure. 913 An application can set the remote locator by setsockopt() providing a 914 valid locator which is stored in a shim_locator data structure. When 915 a zero-filled locator is specified, pre-existing setting of remote 916 locator is inactivated. 918 An application can get the specified remote locator by getsockopt(). 920 An error ENOENT will be returned when there is no context associated 921 with the socket. 923 An error EINVALIDLOCATOR when invalid locator is specified. 925 The usage of the option is as the same as that of SHIM_LOC_LOCAL_SEND 926 option. 928 5.11. SHIM_LOCLIST_LOCAL 930 The SHIM_LOCLIST_LOCAL option is used to get or set the locator list 931 associated with the local EID of the shim context associated with the 932 socket. Hence this option is effective only when there is a shim 933 context associated with the socket. 935 The data type of the option value is a pointer to the buffer in which 936 a locator list is stored. See Section 7 for the data structure for 937 storing the locator information. By default, the option value is set 938 to NULL, meaning that the option is disabled. 940 An application can get the locator list by getsockopt(). Note that 941 the size of the buffer pointed by optval argument should be large 942 enough to store an array of locator information. The number of the 943 locator information is not known beforehand. 945 The local locator list can be set by setsockopt(). The buffer 946 pointed by optval argument should contain an array of locator list. 948 An error ENOENT will be returned when there is no context associated 949 with the socket. 951 An error EINVALIDLOCATOR will be returned when the validation of the 952 specified locator failed. 954 For example, an application can set a list of locators to be 955 associated with the local EID by using the socket option as follows: 957 struct shim_locator locators[SHIM_MAX_LOCATORS]; 958 struct sockaddr_in *sin; 959 struct sockaddr_in6 *sin6; 961 memset(locators, 0, sizeof(locators)); 963 ... 965 /* obtain local IP addresses from local interfaces */ 967 ... 969 /* first locator (an IPv6 address) */ 970 locators[0].lc_family = AF_INET6; 971 locators[0].lc_ifidx = 0; 972 locators[0].lc_flags = 0; 973 locators[0].lc_preference = 1; 974 memcpy(&locators[0].lc_addr, &sa6->sin6_addr, 975 sizeof(sa6->sin6_addr)); 977 ... 979 /* second locator (an IPv4 address) */ 980 locators[1].lc_family = AF_INET; 981 locators[1].lc_ifidx = 0; 982 locators[1].lc_flags = 0; 983 locators[1].lc_preference = 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.12. 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. Hence this option is effective only when there is a shim 1008 context 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 by optval argument should be large 1017 enough to store an array of locator information. The number of the 1018 locator information is not known beforehand. 1020 An application can set the locator list by setsockopt(). The buffer 1021 pointed by optval argument should contain an array of locator list. 1023 An error ENOENT will be returned when there is no context associated 1024 with the socket. 1026 An error EINVALIDLOCATOR will be returned when the validation of the 1027 specified locator failed. 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 will be returned when there is no context associated 1049 with 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 multihoming shim sub-layer except for 1117 SHIM_HOT_STANDBY are applicable for both connected and unconnected 1118 sockets. 1120 The reason SHIM_HOT_STANDBY socket option cannot be used for an 1121 unconnected socket is that the multihoming shim sub-layer cannot 1122 initiate context establishment to create a hot standby connection 1123 because the peer's IP address is not known until the application 1124 writes data to the unconnected socket. 1126 5.16. Error Handling 1128 If successful, getsockopt() and setsockopt() return 0; otherwise, the 1129 functions return -1 and set errno to indicate an error. 1131 The following are new error values defined for some shim specific 1132 socket options indicating that the getsockopt() or setsockopt() 1133 finished incompletely: 1135 EINVALIDLOCATOR 1136 This indicates that at least one of the necessary validations 1137 inside the shim sub-layer for the specified locator has failed. 1138 In case of SHIM6, there are two kinds of verifications required 1139 for security reasons prior to sending an IP packet to the peer's 1140 new locator; one is the return routability (check if the peer is 1141 actually willing to receive data with the specified locator) and 1142 the other one is the verification based on crypto identifier 1143 mechanisms [RFC3972], [RFC5535]. 1145 6. Ancillary Data for Multihoming Shim Sub-layer 1147 In this section, the definition and the usage of the ancillary data 1148 specific to multihoming shim sub-layer are provided. 1150 As defined in the Posix standard, sendmsg() and recvmsg() input a 1151 msghdr structure as their arguments. These system calls can handle 1152 control information along with data. Figure 3 shows the msghdr 1153 structure which is defined in . The member msg_control 1154 holds a pointer to the buffer where the shim specific ancillary data 1155 objects can be stored in addition to other ancillary data objects. 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 The buffer pointed by the member msg_control of the msghdr structure 1170 may contain locator information which is a single locator and it 1171 should be possible to process them with the existing macros defined 1172 in Posix and [RFC3542]. Each cmsghdr{} should be followed by data 1173 which stores a single locator. 1175 In case of non-connected socket, msg_name member stores the socket 1176 address of the peer which should be considered as an identifier 1177 rather than a locator. The locator of the peer node should be 1178 retrieved by SHIM_LOC_PEER_RECV as specified below. 1180 Table 2 is a list of the shim specific ancillary data which can be 1181 used for recvmsg() or sendmsg(). In any case, SOL_SHIM must be set 1182 as cmsg_level. 1184 +---------------------+-----------+-----------+-----------------+ 1185 | cmsg_type | sendmsg() | recvmsg() | cmsg_data[] | 1186 +---------------------+-----------+-----------+-----------------+ 1187 | SHIM_LOC_LOCAL_RECV | | o | *1 | 1188 | SHIM_LOC_PEER_RECV | | o | *1 | 1189 | SHIM_LOC_LOCAL_SEND | o | | *1 | 1190 | SHIM_LOC_PEER_SEND | o | | *1 | 1191 | SHIM_FEEDBACK | o | | shim_feedback{} | 1192 +---------------------+-----------+-----------+-----------------+ 1194 Table 2: Shim specific ancillary data 1196 *1: cmsg_data[] should include padding (if necessary) and a single 1197 sockaddr_in{}/sockaddr_in6{}. 1199 6.1. Get Locator from Incoming Packet 1201 An application can get locator information from the received IP 1202 packet by specifying the shim specific socket options for the socket. 1203 When SHIM_LOC_LOCAL_RECV and/or SHIM_LOC_PEER_RECV socket options are 1204 set, the application can retrieve local and/or remote locator from 1205 the ancillary data. 1207 6.2. Set Locator for Outgoing Packet 1209 An application can specify the locators to be used for transmitting 1210 an IP packet by sendmsg(). When the ancillary data of cmsg_type 1211 SHIM_LOC_LOCAL_SEND and/or SHIM_LOC_PEER_SEND are specified, the 1212 application can explicitly specify the source and/or the destination 1213 locators to be used for the communication over the socket. 1215 Note that the effect is limited to the datagram transmitted by the 1216 sendmsg(). 1218 If the specified locator pair is verified, the shim sub-layer 1219 overrides the locators of the IP packet. 1221 An error EINVALIDLOCATOR will be returned when validation of the 1222 specified locator failed. 1224 6.3. Notification from Application to Multihoming Shim Sub-layer 1226 An application may provide feedbacks to the shim sub-layer about the 1227 communication status. Such feedbacks are particularly useful for the 1228 shim sub-layer in the absence of REAP mechanism to monitor the 1229 reachability status of the currently used locator pair in a given 1230 shim context. 1232 The notification can be made by sendmsg() specifying a new ancillary 1233 data called SHIM_FEEDBACK. The ancillary data can be handled by 1234 specifying SHIM_FEEDBACK option in cmsg_type. 1236 An error ENOENT will be returned when there is no context associated 1237 with the socket. 1239 See Section 7.3 for details of the data structure to be used. 1241 It is outside the scope of this document how the shim sub-layer would 1242 react when a feedback is provided by an application. 1244 6.4. Notification from Multihoming Shim Sub-layer to Application 1246 The multihoming shim sub-layer MAY provide notification about a 1247 locator change within a multihome shim context to applications that 1248 have concern with the context. Such a notification is useful, for 1249 example, for an application which is sensitive to path 1250 characteristics. A locator change is caused when either of local or 1251 peer's locator (or both) is changed. Note that locators discussed 1252 here are the ones that appear in the IP packet header, and not the 1253 ones that are included in the locator list. A locator change may 1254 take place asynchronously. 1256 The notification is handled as an out-of-band data by the 1257 application. 1258 1. Application calls the select() system call by setting non-NULL 1259 value for the fourth argument. 1260 2. When there is a notification, the application reads out-of-band 1261 data from the socket by calling the recvmsg() system call. 1262 3. The application checks the flag in the msghdr (msg_flags) to see 1263 if there is any notification about locator change delivered. If 1264 the MSG_SHIM_LOCATOR_CHANGE flag is set, application parse the 1265 chain of control message to read a pair of ancillary data objects 1266 which contains the source locator and the destination locator. 1267 Note that the direction of locator change is distinguished by the 1268 cmsg_type; SHIM_LOC_*_RECV is used for inbound locator change, 1269 and SHIM_LOC_*_SEND is used for outbound locator change. 1271 There is no restriction in terms of applicability of the notification 1272 about locator change. The notification can be delivered to sockets 1273 regardless of if it is connected or unconnected, stream-oriented or 1274 datagram-oriented. 1276 6.5. Applicability 1278 A care is needed when the SHIM_LOC_*_RECV socket option is used for 1279 stream-oriented sockets (e.g., TCP sockets) because there is no one- 1280 to-one mapping between a single send or receive operation and the 1281 data (e.g., a TCP segment) being received. In other words, there is 1282 no gurantee that the locator(s) set in the SHIM_LOC_*_RECV ancillary 1283 data is identical to the locator(s) that appear in the IP packets 1284 received. The multihoming shim sub-layer SHOULD provide the latest 1285 locator information to the application in response to the 1286 SHIM_LOC_*_RECV socket option. 1288 7. Data Structures 1290 In this section, data structures specifically defined for the 1291 multihoming shim sub-layer are introduced. These data structures are 1292 either used as a parameter for setsockopt()/getsockopt() (as 1293 mentioned in Section 5) or as a parameter for ancillary data to be 1294 processed by sendmsg()/recvmsg() (as mentioned in Section 6). 1296 7.1. Placeholder for Locator Information 1298 As defined in Section 5, the SHIM_LOC_LOCAL_PREF, SHIM_LOC_PEER_PREF, 1299 SHIM_LOCLIST_LOCAL, and SHIM_LOCLIST_PEER socket options need to 1300 handle one or more locator information. Locator information includes 1301 not only the locator itself but also additional information about the 1302 locator which is useful for locator management. A new data structure 1303 is defined to serve as a placeholder for the locator information. 1305 Figure 4 illustrates the data structure called shim_locator which 1306 stores a locator information. 1308 struct shim_locator { 1309 uint8_t lc_family; /* address family */ 1310 uint8_t lc_proto; /* protocol */ 1311 uint16_t lc_port; /* port number */ 1312 uint16_t lc_flags; /* flags */ 1313 uint16_t lc_pref; /* preference value */ 1314 uint32_t lc_ifidx; /* interface index */ 1315 struct in6_addr lc_addr; /* address */ 1316 }; 1318 Figure 4: shim locator structure 1320 lc_family 1321 Address family of the locator (e.g. AF_INET, AF_INET6). It is 1322 required that the parameter contains non-zero value indicating the 1323 exact address family of the locator. 1324 lc_proto 1325 Internet Protocol number for the protocol which is used to handle 1326 locator behind NAT. Typically, this value is set as UDP (17) when 1327 the locator is a UDP encapsulation interface. 1328 lc_port 1329 Port number which is used for handling locator behind NAT. 1330 lc_flags 1331 Each bit of the flags represents a specific characteristics of the 1332 locator. Hash Based Address (HBA) is defined as 0x01. 1333 Cryptographically Generated Address (CGA) is defined as 0x02. 1334 lc_pref 1335 Preference of the locator. The preference is represented by an 1336 integer. 1337 lc_ifidx 1338 Interface index of the network interface to which the locator is 1339 assigned. This field should be valid only in a read 1340 (getsockopt()) operation. 1341 lc_addr 1342 Contains the locator. In the case where a locator whose size is 1343 smaller than 16 bytes, an encoding rule should be provided for 1344 each locator of a given address family. For instance, in case of 1345 AF_INET (IPv4), the locator should be in the format of an IPv4- 1346 mapped IPv6 address as defined in [RFC4291]. 1348 7.1.1. Handling Locator behind NAT 1350 Note that the locator information MAY contain a locator behind a 1351 Network Address Translator (NAT). Such a situation may arise when 1352 the host is behind the NAT and uses a local address as a source 1353 locator to communicate with the peer. Note that a NAT traversal 1354 mechanism for HIP is defined, which allows HIP host to tunnel control 1355 and data traffic over UDP[I-D.ietf-hip-nat-traversal]. Note also 1356 that the locator behind NAT is not necessarily an IPv4 address but it 1357 can be an IPv6 address. Below is an example where the application 1358 sets a UDP encapsulation interface as a source locator when sending 1359 IP packets. 1361 struct shim_locator locator; 1362 struct in6_addr ia6; 1364 /* copy the private IPv4 address to the ia6 as an IPv4-mapped 1365 IPv6 address */ 1367 memset(&locator, 0, sizeof(locator)); 1369 /* fill shim_locator data structure */ 1370 locator.lc_family = AF_INET; 1371 locator.lc_proto = IPPROTO_UDP; 1372 locator.lc_port = 50500; 1373 locator.lc_flags = 0; 1374 locator.lc_pref = 0; 1375 locator.lc_ifidx = 3; 1377 memcpy(&locator.lc_addr, &ia6, sizeof(ia6)); 1379 setsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_SEND, &locator, 1380 sizeof(locator)); 1382 Figure 5: Handling locator behind NAT 1384 7.2. Path Exploration Parameter 1386 As defined in Section 5, SHIM_PATHEXPLORE allows application to set 1387 or read the parameters for path exploration and failure detection. A 1388 new data structure called shim_pathexplore is defined to store the 1389 necessary parameters. Figure 6 illustrates the data structure. The 1390 data structure can be passed to getsockopt() or setsockopt() as an 1391 argument. 1393 struct shim_pathexplore { 1394 uint8_t pe_probenum; /* # of initial probe */ 1395 uint8_t pe_keepaliveto; /* Keepalive Timeout */ 1396 uint16_t pe_initprobeto; /* Initial Probe Timeout */ 1397 uint32_t pe_reserved; /* reserved */ 1398 }; 1400 Figure 6: path explore structure 1402 pe_probenum 1403 Indicates the number of initial probe messages to be sent. 1404 Default value of this parameter should follow what is specified in 1405 [RFC5534]. 1407 pe_keepaliveto 1408 Indicates timeout value for detecting a failure when the host does 1409 not receive any packets for a certain period of time while there 1410 is outbound traffic. When the timer expires, path exploration 1411 procedure will be carried out by sending a REAP Probe message. 1412 Default value of this parameter should follow what is specified in 1413 [RFC5534]. 1414 pe_initprobeto 1415 Indicates retransmission timer of REAP Probe message in 1416 milliseconds. Note that this timer is applied before exponential 1417 back-off is started. A REAP Probe message for the same locator 1418 pair may be retransmitted. Default value of this parameter should 1419 follow what is specified in [RFC5534]. 1420 pe_reserved 1421 A reserved field for future extension. By default, the field 1422 should be initialized to zero. 1424 7.3. Feedback Information 1426 As mentioned in Section 6.3, applications can inform the shim sub- 1427 layer about the status of unicast reachability of the locator pair 1428 currently in use. The feedback information can be handled by using 1429 ancillary data called SHIM_FEEDBACK. A new data structure named 1430 shim_feedback is illustrated in Figure 7. 1432 struct shim_feedback { 1433 uint8_t fb_direction; /* direction of traffic */ 1434 uint8_t fb_indicator; /* indicator (1-3) */ 1435 uint16_t fb_reserved; /* reserved */ 1436 }; 1438 Figure 7: feedback information structure 1440 direction 1441 Indicates direction of reachability between a locator pair in 1442 question. A value 0 indicates outbound and a value 1 indicates 1443 inbound direction. 1444 indicator 1445 A value indicating the degree of satisfaction of a unidirectional 1446 reachability for a given locator pair. 1447 * 0: Default value. Whenever this value is specified the 1448 feedback information must not be processed by the shim sub- 1449 layer. 1450 * 1: Unable to connect. There is no unidirectional reachability 1451 between the locator pair in question. 1452 * 2: Unsatisfactory. The application is not satisfied with the 1453 unidirectional reachability between the locator pair in 1454 question. 1456 * 3: Satisfactory. There is satisfactory unidirectional 1457 reachability between the locator pair in question. 1458 reserved 1459 Reserved field. Must be ignored by the receiver. 1461 8. System Requirements 1463 As discussed in Section 5, all the socket options for multihoming 1464 shim sub-layer except for the SHIM_HOT_STANDBY socket option are 1465 applicable to both connected and unconnected sockets. The 1466 implications of this design choice on system requirements should be 1467 noted. 1469 There are less system requirements to enable support for applications 1470 that use connected sockets. This is because the kernel can easily 1471 maintain association between a connected socket and a multihoming 1472 shim context. Note that the multihoming shim contexts are identified 1473 by an EID pair. In contrast, there are more system requirements to 1474 enable support for applications that use unconnected sockets. The 1475 kernel needs to dynamically resolve association between an 1476 unconnected socket and a multihoming shim context, if any, upon 1477 packet processing. As to outbound packet processing, the kernel 1478 needs to check if there is any multihoming shim context whose EID 1479 pair matches with the source and destination IP addresses of the user 1480 data originating from an unconnected socket. If a matching context 1481 is found, the multihoming shim sub-layer performs packet processing 1482 taking the application's preference into account. Note that the 1483 multihoming shim sub-layer should be able to backtrack the socket 1484 from which the user data was originated. As to inbound packet 1485 processing, the multihoming shim sub-layer needs to check not only 1486 the IP header but also the transport layer protocol header to resolve 1487 the destination socket. If the destination socket is resolved and it 1488 contains any values concerning the multihoming shim sub-layer socket 1489 options, the multihoming shim sub-layer processes the IP packet as 1490 requested (e.g., set locator information of received packet in the 1491 ancillary data). 1493 9. Implications for Existing Socket API Extensions 1495 Some of the socket options defined in this document are overlapping 1496 with existing sockets API and care should be taken for the usage not 1497 to confuse with the overlapping features. 1499 The socket options for requesting specific locators to be used for a 1500 given transaction (SHIM_LOC_LOCAL_PREF and SHIM_LOC_PEER_PREF) are 1501 semantically similar to the existing sockets API (IPV6_PKTINFO). The 1502 socket options for obtaining the locator information from the 1503 received IP packet (SHIM_LOC_LOCAL_RECV and SHIM_LOC_PEER_RECV) are 1504 semantically similar to the existing sockets API (IP_RECVDSTADDR and 1505 IPV6_PKTINFO). 1507 In IPv4, application can obtain the destination IP address of the 1508 received IP packet (IP_RECVDSTADDR). If the shim sub-layer performs 1509 identifier/locator adaptation for the received packet, the 1510 destination EID should be stored in the ancillary data 1511 (IP_RECVDSTADDR). 1513 In IPv6, [RFC3542] defines that IPV6_PKTINFO can be used to specify 1514 source IPv6 address and the outgoing interface for outgoing packets, 1515 and retrieve destination IPv6 address and receiving interface for 1516 incoming packets. This information is stored in ancillary data being 1517 IPV6_PKTINFO specified as cmsg_type. Existing sockets API should 1518 continue to work above the shim sub-layer, that is, the IP addresses 1519 handled in IPV6_PKTINFO should be EIDs, not the locators. 1521 Baseline is that the above existing sockets API (IP_RECVDSTADDR and 1522 IPV6_PKTINFO) is assumed to work above the multihoming shim sub- 1523 layer. In other words, the IP addresses those socket options deal 1524 with are EIDs rather than locators. 1526 10. Resolving Conflicts with Preference Values 1528 Since the multihoming shim API allows application to specify 1529 preference value for the context which is associated with the socket 1530 instance, there may be a conflict with preference values specified by 1531 different applications. For instance, application A and B may 1532 establish communication with the same EID pair while both 1533 applications have different preference in their choice of local 1534 locator. 1536 SHIM6 supports a notion of context forking in which a context is 1537 split when there is a conflict with preference values specified by 1538 multiple applications. Thus, context forking can simply resolve the 1539 conflicting situation which may be caused by the use of socket 1540 options for multihoming shim sub-layer. 1542 10.1. Implicit Forking 1544 Socket options defined in Section 5 may cause conflicting situation 1545 when the target context is shared by multiple applications. In such 1546 case, socket handler should inform the shim sub-layer that context 1547 forking is required. In SHIM6, when a context is forked, an unique 1548 identifier called Forked Instance Identifier (FII) is assigned to the 1549 newly forked context. The forked context is then exclusively 1550 associated with the socket through which non-default preference value 1551 was specified. The forked context is maintained by the multihoming 1552 shim sub-layer during the lifetime of associated socket instance. 1553 When the socket is closed, the multihoming shim sub-layer SHOULD 1554 delete associated context. In this way, garbage collection can be 1555 carried out to cleanup unused forked contexts. Upon garbage 1556 collection, every forked context SHOULD be checked if there is no 1557 socket (process) associated with the context. If there is none, the 1558 forked context should be deleted. When a forked context is torn 1559 down, SHIM6 should notify the peer about the deletion of forked 1560 context. 1562 As opposed to socket options, context forking MUST NOT be triggered 1563 by any use of ancillary data that is specific to multihoming shim 1564 sub-layer as defined in Section 6. 1566 11. Discussion 1568 In this section, open issues are introduced. 1570 11.1. Naming at Socket Layer 1572 The getsockname() and getpeername() system calls are used to obtain 1573 the 'name' of an endpoint which is actually a pair of IP address and 1574 port number assigned to a given socket. getsockname() is used when an 1575 application wants to obtain the local IP address and port number 1576 assigned for a given socket instance. getpeername() is used when an 1577 application obtains the remote IP address and port number. 1579 The above is based on a traditional system model of the sockets API 1580 where an IP address is expected to play both the role of identifier 1581 and the role of locator. 1583 In a system model where a shim sub-layer exists inside the IP layer, 1584 both getsockname() and getpeername() deal with identifiers, namely 1585 EIDs. In this sense, the shim sub-layer serves to (1) hide locators 1586 and (2) provide access to the identifier for the application over the 1587 legacy socket APIs. 1589 11.2. Additional Requirements from Applications 1591 At the moment, it is not certain if following requirements are common 1592 in all the multihomed environments (SHIM6 and HIP). These are mainly 1593 identified during discussions made on SHIM6 WG mailing list. 1595 o The application should be able to set preferences for the 1596 locators, local and remote ones, and also to the preferences of 1597 the local locators that will be passed to the peer. 1599 11.3. Issues of Header Conversion among Different Address Family 1601 The shim sub-layer performs identifier/locator adaptation. 1602 Therefore, in some cases, the whole IP header can be replaced with 1603 new IP header of a different address family (e.g. conversion from 1604 IPv4 to IPv6 or vice versa). Hence, there is an issue how to make 1605 the conversion with minimum impact. Note that this issue is common 1606 in other protocol conversion such as SIIT[RFC2765]. 1608 As addressed in SIIT specification, some of the features (IPv6 1609 routing headers, hop-by-hop extension headers, or destination 1610 headers) from IPv6 are not convertible to IPv4. In addition, notion 1611 of source routing is not exactly the same in IPv4 and IPv6. Hence, 1612 there is a certain limitation in protocol conversion between IPv4 and 1613 IPv6. 1615 The question is how should the shim sub-layer behave when it faces 1616 with limitation problem of protocol conversion. Should we introduce 1617 new error something like ENOSUITABLELOCATOR ? 1619 11.4. Handling of Unknown Locator Provided by Application 1621 There might be a case where application provides the shim layer new 1622 locator with the SHIM_LOC_*_PREF socket options or SHIM_LOC_*_SEND 1623 ancillary data. Then there is a question how should the shim sub- 1624 layer treat the new locator informed by the application. 1626 In principle, locator information are exchanged by the shim protocol. 1627 However, there might be a case where application acquires information 1628 about the locator and prefers to use it for its communication. 1630 12. Changes 1632 12.1. Changes from version 00 to version 01 1634 The followings are changes from version 00 to version 01: 1635 o Define shim_locator{} data type which is a placeholder for 1636 locator. 1637 o Define shim_pathexplore{} data type in which a set of REAP 1638 parameters are stored. 1639 o Remove descriptions about "stickiness" of socket options. 1641 o Deprecate SHIM_IF_RECV and SHIM_IF_SEND socket options. 1642 o Give default value and how to disable given socket option. 1644 12.2. Changes from version 01 to version 02 1646 The followings are changes from version 01 to version 02: 1647 o Add section describing context forking. 1648 o Rephrase conclusion section. 1649 o Separate normative references from informative references. 1650 o Remove texts from discussion section that are not relevant to the 1651 contents of the document. 1652 o Add section describing change history (this section). 1654 12.3. Changes from version 02 to version 03 1656 The followings are changes from version 02 to version 03: 1657 o Add an Appendix section describing the issue of context forking. 1659 12.4. Changes from version 03 to version 04 1661 The followings are changes from version 03 to version 04: 1662 o Updated reference. 1663 o Correct typo and grammatical errors. 1665 12.5. Changes from version 04 to version 05 1667 The followings are changes from version 04 to version 05: 1668 o Added definition of SHIM_FEEDBACK ancillary data. 1669 o Added an example of code using the SHIM_LOCLIST_LOCAL 1670 o Added SHIM_LOC_LOCAL_SEND and SHIM_LOC_PEER_SEND socket options. 1672 12.6. Changes from version 05 to version 06 1674 The followings are changes from version 04 to version 05: 1675 o Updated references. 1677 12.7. Changes from version 06 to version 07 1679 The followings are changes from version 06 to version 07: 1680 o Resolved editorial issues. 1682 12.8. Changes from version 07 to version 08 1684 No changes are made except for updates of the references. 1686 12.9. Changes from version 08 to version 09 1688 The followings are changes from version 08 to version 09: 1689 o Updated texts for Section 1 and Section 5 according to the 1690 comments provided by Samu Varjonen. 1691 o Made it clear that downgrading the multihoming shim support (i.e., 1692 specifying value 1 with the SHIM_DONTSHIM socket option) is only 1693 allowed before the socket is connected. 1694 o Updated locator information (shim_locator{}) so that it can 1695 contain a locator behind NAT. 1697 12.10. Changes from version 09 to version 10 1699 The followings are changes from version 09 to version 10: 1700 o Addressed applicability of socket options and ancillary data for 1701 the multihoming shim sub-layer. 1702 o Addressed system requirements. 1703 o Removed unnecessary description about deprecated socket option 1704 (SHIM_IF_RECV). 1706 12.11. Changes from version 10 to version 11 1708 The followings are changes from version 10 to version 11: 1709 o Added short descriptions about connected sockets and unconnected 1710 sockets. 1711 o Relax applicability of the socket options. 1712 o Relax applicability of the ancillary data. 1713 o Added notification about locator change. 1715 13. IANA Considerations 1717 This document contains no IANA consideration. 1719 14. Security Considerations 1721 This document does not specify any security mechanism for the shim 1722 sub-layer. Fundamentally, the shim sub-layer has a potential to 1723 impose security threats, as it changes the source and/or destination 1724 IP addresses of the IP packet being sent or received. Therefore, the 1725 basic assumption is that the security mechanism defined in each 1726 protocol of the shim sub-layer is strictly applied. 1728 15. Conclusion 1730 In this document, the Application Program Interface (API) for 1731 multihoming shim sub-layer is specified. The sockets API allows 1732 applications to have additional control of the locator management and 1733 interface to the REAP mechanism inside the multihoming shim sub- 1734 layer. 1736 Socket options for multihoming shim sub-layer can be used by 1737 getsockopt() and/or setsockopt() system calls. Besides, applications 1738 can use some ancillary data that are specific to multihoming shim 1739 sub-layer to get locator from received packet or to set locator for 1740 outgoing packet. 1742 From an architectural point of view, the sockets API provides extends 1743 the existing sockets API framework in the face of ID/Locator 1744 separation. With regard to API that relate to IP address management, 1745 it is assured that existing sockets API continue to work above the 1746 shim sub-layer dealing with identifiers, while multihoming shim API 1747 deals with locators. 1749 16. Acknowledgments 1751 Authors would like to thank Jari Arkko who participated in the 1752 discussion that lead to the first version of this document, and 1753 Tatuya Jinmei who thoroughly reviewed the early version of this draft 1754 and provided detailed comments on sockets API related issues. Thomas 1755 Henderson provided valuable comments especially from HIP 1756 perspectives. 1758 Authors sincerely thank to the following people for their help to 1759 improve this document: Samu Varjonen and Dmitriy Kuptsov. 1761 17. References 1763 17.1. Normative References 1765 [POSIX] "IEEE Std. 1003.1-2001 Standard for Information Technology 1766 -- Portable Operating System Interface (POSIX). Open group 1767 Technical Standard: Base Specifications, Issue 6, 1768 http://www.opengroup.org/austin", December 2001. 1770 [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, 1771 "Advanced Sockets Application Program Interface (API) for 1772 IPv6", RFC 3542, May 2003. 1774 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 1775 (HIP) Architecture", RFC 4423, May 2006. 1777 [RFC5533] Bagnulo, M. and E. Nordmark, "Level 3 multihoming shim 1778 protocol", RFC 5533, June 2009. 1780 [RFC5534] Arkko, J. and I. Beijnum, "Failure Detection and Locator 1781 Pair Exploration Protocol for IPv6 Multihoming", RFC 5534, 1782 June 2009. 1784 17.2. Informative References 1786 [I-D.ietf-hip-nat-traversal] 1787 Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. 1788 Keranen, "Basic HIP Extensions for Traversal of Network 1789 Address Translators", Internet 1790 Draft draft-ietf-hip-nat-traversal-09, October 2009. 1792 [I-D.ietf-shim6-app-refer] 1793 Nordmark, E., "Shim6 Application Referral Issues", 1794 draft-ietf-shim6-app-refer-00 (work in progress), 1795 July 2005. 1797 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 1798 (SIIT)", RFC 2765, February 2000. 1800 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1801 RFC 3972, March 2005. 1803 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1804 Architecture", RFC 4291, February 2006. 1806 [RFC5535] Bagnulo, M., "Hash Based Addresses (HBA)", RFC 5535, 1807 June 2009. 1809 Appendix A. Context Forking 1811 In this section, an issue concerning context forking and its relation 1812 to the multihoming shim API are discussed. 1814 SHIM6 supports a notion of context forking. A peer may decide to 1815 fork a context for certain reason (e.g. upper layer protocol prefers 1816 to use different locator pair than the one defined in available 1817 context). The procedure of forking context is done similar to the 1818 normal context establishment, performing the 4-way message exchange. 1819 A peer who has decided to fork a context initiates the context 1820 establishment. Hereafter, we call this peer initiator. 1822 Once the forked context is established between the peers, on the 1823 initiator side, it is possible to apply forked context to the packet 1824 flow since the system maintains an association between the forked 1825 context and the socket owned by the application that has requested 1826 the context forking. How this association is maintained is 1827 implementation specific issue. However, on the responder side, there 1828 is a question on how the outbound packet can be multiplexed by the 1829 shim sub-layer. Since there are more than one SHIM6 contexts that 1830 match with the ULID pair of the packet flow. There is a need to 1831 differentiate packet flows not only by the ULID pairs but some other 1832 information and associate a given packet flow with specific context. 1834 Figure 8 gives an example of a scenario where two communicating peers 1835 fork a context. Initially, there has been a single transaction 1836 between the peers, by the application 1 (App1). Accordingly, another 1837 transaction is started, by application 2 (App2). Both of the 1838 transactions are made based the same ULID pair. The first context 1839 pair (Ctx1) is established for the transaction of App1. Given the 1840 requests from App2, the shim sub-layer on Peer 1 decides to fork a 1841 context. Accordingly, a forked context (Ctx2) is established between 1842 the peers, which should be exclusively applied to the transaction of 1843 App2. Ideally, multiplexing and demultiplexing of packet flows that 1844 relate to App1 and App2 should be done as illustrated in Figure 8. 1845 However, as mentioned earlier, the responder needs to multiplex 1846 outbound flows of App1 and App2 somehow. Note that if a context 1847 forking occurs on the initiator side, a context forking needs to 1848 occur also on the responder side. 1850 Peer 1 Peer 2 1851 (initiator) (responder) 1853 +----+ +----+ +----+ +----+ 1854 |App1| |App2| |App1| |App2| 1855 +----+ +----+ +----+ +----+ 1856 |^ |^ ^| ^| 1857 v| v| |v |v 1858 -----S1-------------S2----- -----S1-------------S2----- 1859 || || || || 1860 || || || || 1862 Ctx1 Ctx2 Ctx1 Ctx2 1863 ULID: ULID: ULID: ULID: 1864 Loc: Loc: Loc: Loc: 1865 FII: 0 FII: 100 FII: 0 FII: 100 1867 |^ |^ ^| ^| 1868 || || || || 1869 || || || || 1870 \..............||....................../| || 1871 \.............||......................./ || 1872 || || 1873 \|...................................../| 1874 \....................................../ 1876 Figure 8: context forking 1878 To overcome the problem mentioned above, there are some solutions. 1880 One viable approach is to let the system implicitly maintain an 1881 association between the socket and the associated context by keeping 1882 the record of inbound packet processing. That is, the system stores 1883 the information about the context on which the inbound packet flow 1884 was demultiplexed. The information comprises the ULID pair and FII 1885 of the context and is stored in the socket instance. Later, the 1886 system can use the information to identify the associated context in 1887 outbound packet processing. This approach should be feasible as far 1888 as there is bi-directional user traffic. 1890 Another viable approach is to extend SHIM6 protocol by adding 1891 capability of exchanging additional information to identify the 1892 packet flow from others which needs to be handled by a newly forked 1893 context. The information exchange can be done during the context 1894 establishment. The initiator appends 5 tuple of the packet flow to 1895 be handled by the newly forked context. Note that the additional 1896 information provided by the 5 tuple are source and destination port 1897 numbers and upper layer protocol. The information is later used by 1898 the shim sub-layer to multiplex the outbound packet flow on the 1899 responder side. 1901 The socket options for multihoming shim can be used by the 1902 application to trigger the context forking in implicit manner. The 1903 peer becomes an initiator in the establishment of the forked context. 1904 Once the forked context is established between the peers, application 1905 on each end can influence the preference on context by utilizing the 1906 multihoming shim API. 1908 Authors' Addresses 1910 Miika Komu 1911 Helsinki Institute for Information Technology 1912 Tammasaarenkatu 3 1913 Helsinki 1914 Finland 1916 Phone: +358503841531 1917 Fax: +35896949768 1918 Email: miika@iki.fi 1919 URI: http://www.hiit.fi/ 1921 Marcelo Bagnulo 1922 Universidad Carlos III de Madrid 1923 Av. Universidad 30 1924 Leganes 28911 1925 SPAIN 1927 Phone: +34 91 6248837 1928 Email: marcelo@it.uc3m.es 1929 URI: http://it.uc3m.es/marcelo 1931 Kristian Slavov 1932 Ericsson Research Nomadiclab 1933 Hirsalantie 11 1934 Jorvas FI-02420 1935 Finland 1937 Phone: +358 9 299 3286 1938 Email: kristian.slavov@ericsson.com 1939 Shinta Sugimoto (editor) 1940 Nippon Ericsson K.K. 1941 Koraku Mori Building 1942 1-4-14, Koraku, Bunkyo-ku 1943 Tokyo 112-0004 1944 Japan 1946 Phone: +81 3 3830 2241 1947 Email: shinta.sugimoto@ericsson.com