idnits 2.17.1 draft-ietf-shim6-multihome-shim-api-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1336. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1313. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1320. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1326. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 831 has weird spacing: '... u_int msg_...' == Line 832 has weird spacing: '... struct iovec...' == Line 833 has weird spacing: '... u_int msg_...' == Line 835 has weird spacing: '... u_int msg_...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2006) is 6644 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Normative reference to a draft: ref. 'I-D.henderson-hip-applications' ** Downref: Normative reference to an Informational draft: draft-ietf-hip-arch (ref. 'I-D.ietf-hip-arch') == Outdated reference: A later version (-13) exists of draft-ietf-shim6-failure-detection-03 == Outdated reference: A later version (-12) exists of draft-ietf-shim6-proto-03 -- Possible downref: Non-RFC (?) normative reference: ref. 'POSIX' ** Downref: Normative reference to an Informational RFC: RFC 3542 == Outdated reference: A later version (-05) exists of draft-ietf-shim6-hba-01 == Outdated reference: A later version (-01) exists of draft-nordmark-shim6-esd-00 -- Obsolete informational reference (is this intentional?): RFC 2765 (Obsoleted by RFC 6145) Summary: 5 errors (**), 0 flaws (~~), 10 warnings (==), 11 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 Expires: August 5, 2006 M. Bagnulo 5 UC3M 6 K. Slavov 7 S. Sugimoto, Ed. 8 Ericsson 9 February 2006 11 Socket Application Program Interface (API) for Multihoming Shim 12 draft-ietf-shim6-multihome-shim-api-00 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on August 5, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2006). 43 Abstract 45 This document specifies a socket API for the multihoming shim layer. 46 The API aims to enable interactions between the applications and the 47 multihoming shim layer for advanced locator management and access to 48 information about failure detection and path exploration. 50 This document is based on an assumption that a multhomed host is 51 equipped with a conceptual sublayer (here after "shim") inside the IP 52 layer that maintains mappings between identifiers and locators. 53 Examples of the shim are SHIM6 and HIP. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. System Overview . . . . . . . . . . . . . . . . . . . . . . . 6 60 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 5. Socket Options for Multihoming Shim Layer . . . . . . . . . . 9 62 5.1. SHIM_ASSOCIATED . . . . . . . . . . . . . . . . . . . . . 12 63 5.2. SHIM_DONTSHIM . . . . . . . . . . . . . . . . . . . . . . 13 64 5.3. SHIM_HOT_STANDBY . . . . . . . . . . . . . . . . . . . . . 13 65 5.4. SHIM_PATHEXPLORE . . . . . . . . . . . . . . . . . . . . . 14 66 5.5. SHIM_LOC_LOCAL_PREF . . . . . . . . . . . . . . . . . . . 14 67 5.6. SHIM_LOC_PEER_PREF . . . . . . . . . . . . . . . . . . . . 15 68 5.7. SHIM_LOC_LOCAL_RECV . . . . . . . . . . . . . . . . . . . 15 69 5.8. SHIM_LOC_PEER_RECV . . . . . . . . . . . . . . . . . . . . 16 70 5.9. SHIM_LOCLIST_LOCAL . . . . . . . . . . . . . . . . . . . . 16 71 5.10. SHIM_LOCLIST_PEER . . . . . . . . . . . . . . . . . . . . 17 72 5.11. SHIM_APP_TIMEOUT . . . . . . . . . . . . . . . . . . . . . 17 73 5.12. SHIM_DEFERRED_CONTEXT_SETUP . . . . . . . . . . . . . . . 18 74 5.13. Error Handling . . . . . . . . . . . . . . . . . . . . . . 19 75 6. Ancillary Data for Multihoming Shim . . . . . . . . . . . . . 19 76 6.1. Get Locator Information from Incoming Packet . . . . . . . 21 77 6.2. Specify Locator Information for Outgoing Packet . . . . . 21 78 6.3. Notification from Application to Multihomign Shim . . . . 21 79 6.3.1. SHIM_FEEDBACK_POSITIVE . . . . . . . . . . . . . . . . 21 80 6.3.2. SHIM_FEEDBACK_NEGATIVE . . . . . . . . . . . . . . . . 22 81 7. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 22 82 7.1. Placeholder for Locator Information . . . . . . . . . . . 22 83 7.1.1. Locator Information Stored in Control Message . . . . 22 84 7.1.2. Locator Information Handled by getsockopt() and 85 setsockopt() . . . . . . . . . . . . . . . . . . . . . 22 86 7.2. Parameters of Path Exploration . . . . . . . . . . . . . . 23 87 8. Implications for Existing Socket API Extensions . . . . . . . 23 88 9. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 23 89 9.1. Issues with a Context Shared by Applications . . . . . . . 23 90 9.2. Issues with Shim Unaware Application . . . . . . . . . . . 24 91 9.2.1. Initial Contact with Multiple Locator Pairs . . . . . 24 92 9.2.2. Naming at Socket Layer . . . . . . . . . . . . . . . . 25 93 9.3. Additional Requirements from Application . . . . . . . . . 26 94 9.4. Issues of Header Conversion among Different Address 95 Family . . . . . . . . . . . . . . . . . . . . . . . . . . 26 96 9.5. Handling of Unknown Locator Provided by Application . . . 26 98 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 99 11. Security Considerations . . . . . . . . . . . . . . . . . . . 27 100 12. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 27 101 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 102 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 103 14.1. Normative References . . . . . . . . . . . . . . . . . . . 28 104 14.2. Informative References . . . . . . . . . . . . . . . . . . 28 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 106 Intellectual Property and Copyright Statements . . . . . . . . . . 31 108 1. Introduction 110 HIP and SHIM6 have a commonality in their protocol design; separation 111 of identifier and locator (hereafter identifier/locator separation). 112 Both protocols aim to solve problems that are specific to multihoming 113 environment in a host centric approach. In these protocols, a sub- 114 layer within the IP layer maintains mappings of identifiers and 115 locators. 117 The shim layer is useful in a sense that the IP layer can maintain 118 the mapping of an identifier to corresponding locators. Under a 119 multihomed environment, typically, a host has more than one IP 120 address at a time. During a given transaction, a host may be 121 required to switch the IP address used for the communication to 122 another IP address to preserve the communication. A care is needed 123 to not disrupt the upper layer protocols by the address update. The 124 shim layer can make this locator update transparent to the upper 125 layer protocols. 127 In a system which is based on identifier/locator separation, upper 128 layer protocols are expected to deal with identifiers for 129 establishing and handling the communications. If an application 130 wants to have a multihoming support by the shim layer, the IP 131 addresses specified as source and destination addresses must be 132 identifiers. However, this does not necessarily mean that 133 applications are prohibited to choose specific locators in its 134 communication. It may be useful for applications, in some situation, 135 to specify a preferred locator for the flow. 137 This document recommends that the identifier/locator adaptation is 138 done only once inside the network stack of a host. That is, if 139 multiple shim sublayers exist at the IP layer, any one of them should 140 be applied exclusively for a given flow. 142 As this document specifies socket API, it is written so that the 143 contents are in line with Posix standard [POSIX] as much as possible. 144 The API specified in this document defines how to use ancillary data 145 (aka cmsg) to access locator information with recvmsg() and/or 146 sendmsg() I/O calls. Definition of API is presented in C language 147 and data types follow Posix format; intN_t means a singed integer of 148 exactly N bits (e.g. int16_t) and uintN_t means an unsigned integer 149 of exactly N bits (e.g. uint32_t). 151 The target readers of this document are application programmers who 152 develop application software which may benefit greatly from 153 multihomed environment. In addition, this document should be of 154 interest for the developers of a given shim protocol, as the shim 155 layer should provide the interface to the application. 157 2. Terminology 159 This section provides terminology used in this document. Basically 160 most of the terms used in this document are taken from the following 161 documents: 163 o SHIM6 Protocol Specification[I-D.ietf-shim6-proto] 164 o HIP Architecture[I-D.ietf-hip-arch] 165 o Reachability Protocol (REAP)[I-D.ietf-shim6-failure-detection] 167 In this document, the term "IP" refers to both IPv4 and IPv6, unless 168 the protocol version is specifically mentioned. The followings are 169 definitions of the terms that are frequently used in this document: 171 o Endpoint Identifier (EID) - An identifier used by the application 172 to specify the endpoint of a given communication. Applications 173 may handle EID in various ways such as long-lived connections, 174 callbacks, and referrals[I-D.ietf-shim6-app-refer]. 175 * In the case of SHIM6, an identifier called an ULID serves as an 176 EID. An ULID is chosen from locators available on the host. 177 * In the case of HIP, an identifier which specifies communication 178 endpoints is derived from the public key of the host, which is 179 called a Host Identifier. For the sake of backward 180 compatibility of the socket API, the Host Identifier is 181 represented in a form of hash of public key. 182 o Locator - An IP address actually used to deliver IP packets. 183 Locators should be present in the source and destination fields of 184 the IP header of a packet on the wire. 185 * List of Locators - A list of locators associated with an EID. 186 There are two lists of locators stored in a given context, one 187 is associated with the local EID and the other is associated 188 with the remote EID. As defined in [I-D.ietf-shim6-proto], the 189 list of locators associated with an EID 'A' can be denoted as 190 Ls(A). 191 * Preferred Locator - The (source/destination) locator currently 192 used to send packets within a given context. As defined in 193 [I-D.ietf-shim6-proto], the preferred locator of a host 'A' is 194 denoted as Lp(A). 195 o Shim - A conceptual (sub-)layer inside the IP Layer which 196 maintains mappings of EIDs and locators. An EID can be associated 197 with more than one locators at a time when the host is multihomed. 198 The term 'shim' does not refer to a specific protocol but refers 199 to the conceptual sublayer inside the IP layer. 200 o identifier/locator adaptation - An adaptation performed at the 201 shim layer between EIDs and locators within a given context. The 202 adaptation may end up re-writing the source and destination 203 addresses of the IP packet. In the outbound packet processing, 204 the EID pair is converted to the associated locator pair, while 205 the locator pair is converted to the EID pair in the inbound 206 packet processing. 207 o Context - State information shared by a given pair of peers, which 208 stores a binding between the EIDs and associated locators. The 209 context is maintained at the shim layer. 210 o Reachability Detection - A procedure to check reachability between 211 a given locator pair. 212 o Path - A sequence of routers that an IP packet goes through to 213 reach the destination. 214 o Path Exploration - A procedure to explore available paths for a 215 given set of locator pairs. 216 o Outage - An incident that prevents IP packets to flow from the 217 source locator to the destination locator. When there is an 218 outage, it means that there is no reachability between a given 219 locator pair. The outage can be caused by various reasons, such 220 as shortage of network resources, congestions, and human error 221 (faulty operation). 222 o Working Address Pair - An address pair is said to be working if 223 the packet containing the first address from the pair as source 224 address and the second address from the pair as destination 225 address can safely travel from the source to the destination. If 226 the reachability is confirmed in both directions, the address 227 pairs is said to be bi-directional. Otherwise, it's 228 unidirectional. 229 o Reachability Protocol (REAP) - A protocol for detecting failure 230 and exploring reachability in a multihomed environment. REAP is 231 defined in [I-D.ietf-shim6-failure-detection]. 233 3. System Overview 235 Figure 1 illustrates the system overview. The shim layer and REAP 236 component exist inside the IP layer. Applications can use the socket 237 API defined in this document to interface the shim layer and 238 transport layer for locator management and failure detection and path 239 exploration. 241 It is also possible that the shim layer interacts with transport 242 layers, but the interactions are outside the scope of this document. 244 +------------------------+ 245 | Application | 246 +------------------------+ 247 ^ ^ 248 ~~~~~~~~~~~~~|~Socket Interface|~~~~~~~~~~~~~~ 249 | v 250 +-----------|------------------------------+ 251 | | Transport Layer | 252 +-----------|------------------------------+ 253 ^ | 254 +-------------|-----|-------------------------------------+ 255 | v v | 256 | +-----------------------------+ +----------+ | IP 257 | | Shim |<----->| REAP | | Layer 258 | +-----------------------------+ +----------+ | 259 | ^ ^ | 260 +-----------------------|----------------------|----------+ 261 v v 262 +------------------------------------------+ 263 | Link Layer | 264 +------------------------------------------+ 266 Figure 1: System overview 268 4. Requirements 270 The following is the list of requirements from the application 271 perspective: 272 o Locator management. The shim layer selects a pair of locators for 273 sending IP packets within a given context. The selection is made 274 by taking miscellaneous conditions into account such as 275 reachability of the path, application's preference, and 276 characteristics of path. From the application's perspective: 277 * It should be possible to obtain the lists of locators of a 278 given context: Ls(local) and Ls(remote). 279 * It should be possible to obtain the preferred locators of a 280 given context: Lp(local) and Lp(remote). 281 o Notification from the application to the shim layer about the 282 status of the communication. Note that the notification is made 283 in an event based manner. There are mainly two aspects of the 284 feedback that application or upper layer protocol may provide for 285 the shim layer, positive and negative feedbacks [NOTE: These 286 feedbacks are addressed in section 4.3 and section 5.2 of REAP 287 specification]: 289 * Positive feedback could be given by the application or upper 290 layer protocol (e.g. TCP) to the shim layer informing that the 291 communication is going well. 292 * Negative feedback could be given by the application or upper 293 layer protocol (e.g. TCP) to the shim layer informing that the 294 communication status is not satisfactory. TCP could detect a 295 problem when it does not receive expected ACK from the peer. 296 ICMP error messages delivered to the upper layer protocol could 297 be a clue for application to detect potential problems. REAP 298 module may be triggered by these negative feedbacks and invoke 299 procedure of path exploration. 300 o Feedback from application to shim layer. The application should 301 be able to inform the shim layer of the timeout values for 302 detecting failures, for sending keepalives, for starting the 303 exploration procedure. In particular, the application should be 304 able to suppress the keepalives. 305 o Hot-standby. The application may request the shim layer for hot- 306 standby capabilities. In this case, alternative paths are known 307 to be working before a failure is detected. Hence it is possible 308 for the host to immediately replace the current locator pair with 309 an alternative locator pair. Hot-standby may allow applications 310 to achieve better failover. 311 o Eagerness of locator exploration. The application should be able 312 to inform the shim layer how aggressive it wants REAP mechanism to 313 perform path exploration (e.g. specifying the number of concurrent 314 attempts of discovering working locator pair) when an outage 315 occurs on the path between the currently selected locator pair. 316 o Providing locator information to application. The application 317 should be able to obtain information about the locator pair which 318 was actually used to send or receive the packet. 319 * For inbound traffic, the application may be interested in the 320 locator pair which was actually used to receive the packet. 321 * For outbound traffic, the application may be interested in the 322 locator pair which was actually used to transmit the packet. 323 In this way, the application may have additional control on the 324 locator management. For example, the application can verify if 325 its preference of locator is actually applied to the flow or not. 326 o The application should be able to specify if it wants to defer the 327 context setup or if it wants context establishment to be started 328 immediately in case there is no available context. With deferred 329 context setup, there should be no additional delay imposed by 330 context establishment in initiation of communication. 331 o Turn on/off shim. The application should be able to request to 332 turn on/off the multihoming support by the shim layer: 333 * Apply shim. The application should be able to explicitly 334 request the shim layer to apply multihoming support. 336 * Don't apply shim. The application should be able to request 337 the shim layer not to apply the multihoming support but to 338 apply normal IP processing at the IP layer. 339 o The application should be able to know if the communication is now 340 served by the shim layer or not. 341 o The application should be able to access locator information 342 regardless of its address family. In other words, no matter 343 whether the target locator is IPv4 or IPv6, the application should 344 be able to use common interface to access the locator information. 346 5. Socket Options for Multihoming Shim Layer 348 In this section, the socket options for the interface between the 349 application and the multihomed shim layer are defined. These options 350 can be used either by getsockopt() or setsockopt() system call for an 351 open socket. Table 1 provides a list of the socket options. Note 352 that all socket options are defined at level SOL_SHIM. 354 The first column of the table gives the name of the option. The 355 second and third columns indicate whether the option is for 356 getsockopt() and/or setsockopt(), respectively. The fourth column 357 provides a brief description of the socket option. The fifth column 358 shows the type of data structure specified with the socket option, 359 which can store an argument for setsockopt() and result for 360 getsockopt(). By default, the data structure type is an integer. 362 +-----------------------------+-----+-----+-----------------+-------+ 363 | optname | get | set | description | dtype | 364 +-----------------------------+-----+-----+-----------------+-------+ 365 | SHIM_ASSOCIATED | o | | Check if the | int | 366 | | | | socket is | | 367 | | | | associated with | | 368 | | | | any shim | | 369 | | | | context or not. | | 370 | SHIM_DONTSHIM | o | o | Request the | int | 371 | | | | shim layer not | | 372 | | | | to apply any | | 373 | | | | multihoming | | 374 | | | | support for the | | 375 | | | | communication. | | 376 | SHIM_HOT_STANDBY | o | o | Request the | int | 377 | | | | shim layer to | | 378 | | | | prepare a | | 379 | | | | hot-standby | | 380 | | | | connection (in | | 381 | | | | addition to the | | 382 | | | | current path). | | 383 | SHIM_LOC_LOCAL_PREF | o | o | Get or set the | *1 | 384 | | | | preferred | | 385 | | | | locator on the | | 386 | | | | local side for | | 387 | | | | the context | | 388 | | | | associated with | | 389 | | | | the socket. | | 390 | SHIM_LOC_PEER_PREF | o | o | Get or set the | *1 | 391 | | | | preferred | | 392 | | | | locator on the | | 393 | | | | remote side for | | 394 | | | | the context | | 395 | | | | associated with | | 396 | | | | the socket. | | 397 | SHIM_LOC_LOCAL_RECV | o | o | Request for the | int | 398 | | | | destination | | 399 | | | | locator of the | | 400 | | | | received IP | | 401 | | | | packet. | | 402 | SHIM_LOC_PEER_RECV | o | o | Request for the | int | 403 | | | | source locator | | 404 | | | | of the received | | 405 | | | | IP packet. | | 406 | SHIM_LOCLIST_LOCAL | o | o | Get or set a | *2 | 407 | | | | list of | | 408 | | | | locators | | 409 | | | | associated with | | 410 | | | | the local EID. | | 411 | SHIM_LOCLIST_PEER | o | o | Get or set a | *2 | 412 | | | | list of | | 413 | | | | locators | | 414 | | | | associated with | | 415 | | | | the peer's EID. | | 416 | SHIM_APP_TIMEOUT | o | o | Inform the shim | int | 417 | | | | layer of a | | 418 | | | | timeout value | | 419 | | | | for detecting | | 420 | | | | failure. | | 421 | SHIM_PATHEXPLORE | o | o | Specify how | *3 | 422 | | | | path | | 423 | | | | exploration | | 424 | | | | should be | | 425 | | | | performed in | | 426 | | | | case of | | 427 | | | | failure. | | 428 | SHIM_CONTEXT_DEFERRED_SETUP | o | o | Specify if the | int | 429 | | | | context setup | | 430 | | | | can be deferred | | 431 | | | | or not. | | 432 +-----------------------------+-----+-----+-----------------+-------+ 434 Table 1: Shim specific socket options for getsockopt() and 435 setsockopt() 437 *1: Pointer to the buffer (TBD) in which a single locator information 438 is stored. 440 *2: Pointer to the buffer (TBD) in which a list of locator 441 information is stored. 443 *3: Pointer to the buffer (TBD) in which a set of parameters of path 444 exploration is stored. 446 Figure 2 illustrates how the shim specific socket options fit into 447 the system model of socket API. In the figure, it can be seen that 448 the shim layer and the additional protocol components (IPv4 and IPv6) 449 below the shim layer are new to the system model. As previously 450 mentioned, all the shim specific socket options are defined at 451 SOL_SHIM level. This design choice brings the following advantages: 453 1. It is assured that the existing socket API continue to work at 454 the layer above the shim layer. That is, those legacy API deal 455 with 'identifier' aspect of the IP addresses. 456 2. With newly defined socket options for the shim layer, the 457 application obtains additional control on locator management. 458 3. The shim specific socket options are not specific to any address 459 family (IPPROTO_IP or IPPROTO_IPV6) or any transport protocol 460 (IPPROTO_TCP or IPPROTO_UDP). 462 s1 s2 s3 s4 463 | | | | 464 +----------------|--|-------|--|----------------+ 465 | +-------+ +-------+ | 466 | IPPROTO_TCP | TCP | | UDP | | 467 | +-------+ +-------+ | 468 | | \ / | | 469 | | ----- | | 470 | | / \ | | 471 | +------+ +------+ | 472 | IPPROTO_IP | IPv4 | | IPv6 | IPPROTO_IPV6 | 473 | +------+ +------+ | 474 | \ / SOL_SOCKET 475 | +--------\-------/--------+ | 476 | SOL_SHIM | shim | | 477 | +--------/-------\--------+ | 478 | / \ | 479 | +------+ +------+ | 480 | | IPv4 | | IPv6 | | 481 | +------+ +------+ | 482 | | | | 483 +------------------|----------|-----------------+ 484 | | 485 IPv4 IPv6 486 Datagram Datagram 488 Figure 2: System model of socket API with shim layer 490 5.1. SHIM_ASSOCIATED 492 This option can be specified by getsockopt() to check if the socket 493 is associated with a shim context or not. Thus, the option is read- 494 only and the result (0 or 1) is set in the option value (the fourth 495 argument of getsockopt()). A returned value 1 means that the socket 496 is associated with a certain shim context at the shim layer, while a 497 return value 0 indicates that there is no context associated with the 498 socket. 500 This option is particularly meaningful in a case where the locator 501 information of the received IP packet does not tell whether the 502 identifier/locator adaptation is performed or not. Note that the EID 503 pair and locator pair may be identical in some case. 505 For example, the option can be used by the application as follows: 507 int optval; 508 int optlen = sizeof(optval); 510 getsockopt(fd, SOL_SHIM, SHIM_ASSOCIATED, &optval, &optlen); 512 5.2. SHIM_DONTSHIM 514 This option indicates whether the shim layer applies the multihoming 515 support for the communication established over the socket or not. 516 The option value can be overwritten by setsockopt() and can be 517 checked by getsockopt(). The optval should be binary (0 or 1). By 518 default, the value is set to 0, meaning that the shim layer applies 519 identifier/locator adaptation for the communication. In order to 520 disable the socket option, the application should call setsockopt() 521 with optval set as 0. 523 For example, the option can be disabled by the application as 524 follows: 526 int optval; 528 optval = 0; 530 setsockopt(fd, SOL_SHIM, SHIM_DONTSHIM, &optval, sizeof(optval)); 532 For example, the option value can be checked by the application as 533 follows: 535 int optval; 536 int len; 538 len = sizeof(optval); 540 getsockopt(fd, SOL_SHIM, SHIM_DONTSHIM, &optval, &len); 542 5.3. SHIM_HOT_STANDBY 544 The option indicates whether the shim layer uses hot-standby 545 connection or not for the communication established over the socket. 546 Hence this option is effective only when there is a shim context 547 associated with the socket. another working locator pair than the 548 current locator pair. The option value can be overwritten by 549 setsockopt() and can be checked by getsockopt(). By default, the 550 value is set to 0, meaning that hot-standby connection is disabled. 552 For example, the option can be activated by the application as 553 follows: 555 int optval; 557 optval = 1; 559 setsockopt(fd, SOL_SHIM, SHIM_HOT_STANDBY, &optval, 560 sizeof(optval)); 562 For example, the option value can be checked by the application as 563 follows: 565 int optval; 566 int len; 568 len = sizeof(optval); 570 getsockopt(fd, SOL_SHIM, SHIM_HOT_STANDBY, &optval, &len); 572 5.4. SHIM_PATHEXPLORE 574 The option indicates how aggressive the application wants path 575 exploration to be performed in case of failure. Hence this option is 576 effective only when there is a shim context associated with the 577 socket. The option value can be overwritten by setsockopt() and can 578 be checked by getsockopt(). The option value contains a pointer to 579 the buffer where information of path exploration (the number of 580 attempts for path exploration, frequency of the path exploration, and 581 so on) is stored. By default, the option value is set as NULL, 582 meaning that the option is disabled. 584 An error ENOENT will be returned when there is no context associated 585 with the socket. 587 Example is TBD. 589 5.5. SHIM_LOC_LOCAL_PREF 591 The option value contains the preferred locator on local side within 592 a context associated with the socket. Hence this option is effective 593 only when there is a shim context associated with the socket. The 594 option value holds a single locator information. The option value 595 can be overwritten by setsockopt() and can be checked by 596 getsockopt(). When the option value is changed by the application by 597 setsockopt(), the shim layer shall accordingly update the preferred 598 locator within the context associated with the socket. By default, 599 the option value is set as NULL, meaning that the option is disabled. 601 An error ENOENT will be returned when there is no context associated 602 with the socket. 604 An error EINVALIDLOCATOR will be returned when the validation of the 605 specified locator failed. 607 Example is TBD. 609 5.6. SHIM_LOC_PEER_PREF 611 The option value contains the preferred locator on remote side within 612 a context associated with the socket. Hence this option is effective 613 only when there is a shim context associated with the socket. The 614 option value holds a single locator information. The option value 615 can be overwritten by setsockopt() and can be checked by 616 getsockopt(). When the option value is changed by the application by 617 setsockopt(), the shim layer shall accordingly update the preferred 618 locator within the context associated with the socket. By default, 619 the option value is set as NULL, meaning that the option is disabled. 621 An error ENOENT will be returned when there is no context associated 622 with the socket. 624 An error EINVALIDLOCATOR will be returned when the validation of the 625 specified locator failed. 627 Example is TBD. 629 5.7. SHIM_LOC_LOCAL_RECV 631 With this option, the application can request the shim layer to store 632 the destination locator of the received IP packet in an ancillary 633 data object which can be accessed by recvmsg(). Hence this option is 634 effective only when there is a shim context associated with the 635 socket. The option value should be binary (0 or 1). By default, the 636 option value is set to 0, meaning that the option is disabled. The 637 option value can be overwritten by setsockopt() and can be checked by 638 getsockopt(). See section Section 7 for the data structure for 639 storing the locator information. 641 An error ENOENT will be returned when there is no context associated 642 with the socket. 644 For example, the option can be activated by the application as 645 follows: 647 int optval; 649 optval = 1; 651 setsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_RECV, &optval, 652 sizeof(optval)); 654 For example, the option value can be checked by the application as 655 follows: 657 int optval; 658 int len; 660 len = sizeof(optval); 662 getsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_RECV, &optval, &len); 664 5.8. SHIM_LOC_PEER_RECV 666 With this option, the application can request the shim layer to store 667 the source locator of the received IP packet in an ancillary data 668 object which can be accessed by recvmsg(). Hence this option is 669 effective only when there is a shim context associated with the 670 socket. The option value should be binary (0 or 1). By default, the 671 option value is set to 0, meaning that the option is disabled. The 672 option value can be overwritten by setsockopt() and can be checked by 673 getsockopt(). See section Section 7 for the data structure for 674 storing the locator information. 676 An error ENOENT will be returned when there is no context associated 677 with the socket. 679 The usage of the option is almost identical to that of 680 SHIM_LOC_LOCAL_RECV option. 682 5.9. SHIM_LOCLIST_LOCAL 684 With this option, the application can request the shim layer for a 685 list of locators which is currently associated with the local EID 686 within a shim context. Hence this option is effective only when 687 there is a shim context associated with the socket. The option value 688 contains a pointer to the buffer where the locator list is stored. 689 By default, the option value is set as NULL, meaning that the option 690 is disabled. By getsockopt(), the application can get the locator 691 list. By setsockopt(), the application can request the shim layer to 692 update its locator list that is associated with a local EID. See 693 section Section 7 for the data structure for storing the locator 694 information. 696 An error ENOENT will be returned when there is no context associated 697 with the socket. 699 An error EINVALIDLOCATOR will be returned when the validation of the 700 specified locator failed. 702 Example is TBD. 704 5.10. SHIM_LOCLIST_PEER 706 With this option, the application can request the shim layer for a 707 list of locators which is currently associated with the remote EID 708 within a shim context. Hence this option is effective only when 709 there is a shim context associated with the socket. The option value 710 contains a pointer to the buffer where the locator list is stored. 711 By default, the option value is set as NULL, meaning that the option 712 is disabled. By getsockopt(), the application can get the locator 713 list. By setsockopt(), the application can request the shim layer to 714 update its locator list that is associated with a remote EID. See 715 section Section 7 for the data structure for storing the locator 716 information. 718 An error ENOENT will be returned when there is no context associated 719 with the socket. 721 An error EINVALIDLOCATOR will be returned when the validation of the 722 specified locator failed. 724 Example is TBD. 726 5.11. SHIM_APP_TIMEOUT 728 The option indicates period of timeout for application to detect 729 failure. Hence this option is effective only when there is a shim 730 context associated with the socket. The option value contains the 731 period of timeout in seconds. Accordingly, the shim layer shall 732 update the strategy for reachability test. In particular, this is 733 efficient in a case where the informed timeout value is shorter than 734 the period of the keepalive timer. In such case, keepalives to be 735 performed by REAP may be suppressed. By default, the option value is 736 set to 0, meaning that the option is disabled. 738 An error ENOENT will be returned when there is no context associated 739 with the socket. 741 For example, a specific timeout value can be configured by the 742 application as follows: 744 int optval; 746 optval = 4; /* 4 seconds */ 748 setsockopt(fd, SOL_SHIM, SHIM_APP_TIMEOUT, &optval, 749 sizeof(optval)); 751 For example, the option value namely the period of timeout can be 752 checked by the application as follows: 754 int optval; 755 int len; 757 len = sizeof(optval); 759 getsockopt(fd, SOL_SHIM, SHIM_APP_TIMEOUT, &optval, &len); 761 5.12. SHIM_DEFERRED_CONTEXT_SETUP 763 The option indicates how initiation of context setup is made in terms 764 of timing (before or after) the initial communication flow. Deferred 765 context means that the establishment of context does not put 766 additional delay for an initial transaction. The option value should 767 bi binary (0 or 1). By default, the value is set to 1, meaning that 768 the context setup is deferred. In order to disable the option, the 769 application should call setsockopt() with option value set to 0. 771 However, it should be noted that in some case, deferred context setup 772 is not possible; given EID is non-routable address and there is no 773 way to transmit any IP packet unless there is a context providing the 774 locators. In such case, context establishment should be made prior 775 to the communication. 777 For example, the option can be disabled by the application as 778 follows: 780 int optval; 782 optval = 0; 784 setsockopt(fd, SOL_SHIM, SHIM_DEFERRED_CONTEXT_SETUP, 785 &optval, sizeof(optval)); 787 For example, the option value can be checked by the application as 788 follows: 790 int optval; 791 int len; 793 len = sizeof(optval); 795 getsockopt(fd, SOL_SHIM, SHIM_DEFERRED_CONTEXT_SETUP, 796 &optval, &len); 798 5.13. Error Handling 800 If successful, getsockopt() and setsockopt() return 0; otherwise, the 801 functions return -1 and set errno to indicate error. 803 The followings are errno codes newly defined for some shim specific 804 socket options indicating that the getsockopt() or setsockopt() 805 finished incompletely: 807 EINVALIDLOCATOR 808 This indicates that at least one of the necessary validations 809 inside the shim layer for the specified locator has failed. In 810 case of SHIM6, there are two kinds of verifications required for 811 security reasons prior to sending an IP packet to the peer's new 812 locator; one is return routability (check if the peer is actually 813 willing to receive data with the specified locator) and the other 814 is verifications based on given crypto identifier mechanisms 815 [RFC3972], [I-D.ietf-shim6-hba]. 817 6. Ancillary Data for Multihoming Shim 819 In this section, definition and usage of the ancillary data which is 820 specific to multihiming shim are provided. 822 As defined in Posix standard, sendmsg() and recvmsg() take msghdr 823 structure as its argument and they can additionally handle control 824 information along with data. Figure 14 shows the msghdr structure 825 which is defined in . msg_control member holds a 826 pointer to the buffer where the shim specific ancillary data objects 827 can be stored in addition to other ancillary data objects. 829 struct msghdr { 830 caddr_t msg_name; /* optional address */ 831 u_int msg_namelen; /* size of address */ 832 struct iovec *msg_iov; /* scatter/gather array */ 833 u_int msg_iovlen; /* # elements in msg_iov */ 834 caddr_t msg_control; /* ancillary data, see below */ 835 u_int msg_controllen; /* ancillary data buffer len */ 836 int msg_flags; /* flags on received message */ 837 }; 839 Figure 14: msghdr structure 841 The buffer pointed from the msg_control member of the msghdr 842 structure may contain a locator information which is a single locator 843 and it should be possible to process them with the existing macros 844 defined in Posix and [RFC3542]. Each cmsghdr{} should be followed by 845 data which stores a single locator. 847 In case of non-connected socket, msg_name member stores the socket 848 address of the peer which should be considered as an identifier 849 rather than a locator. The locator of the peer node should be 850 retrieved by SHIM_LOC_PEER_RECV as specified below. 852 Table 2 is a list of the shim specific ancillary data which can be 853 used for recvmsg() or sendmsg(). In any case, SOL_SHIM must be set 854 as cmsg_level. 856 +------------------------+-----------+-----------+-------------+ 857 | cmsg_type | sendmsg() | recvmsg() | cmsg_data[] | 858 +------------------------+-----------+-----------+-------------+ 859 | SHIM_LOC_LOCAL_RECV | | o | *1 | 860 | SHIM_LOC_PEER_RECV | | o | *1 | 861 | SHIM_LOC_LOCAL_SEND | o | | *1 | 862 | SHIM_LOC_PEER_SEND | o | | *1 | 863 | SHIM_FEEDBACK_POSITIVE | o | | TBD | 864 | SHIM_FEEDBACK_NEGATICE | o | | TBD | 865 +------------------------+-----------+-----------+-------------+ 867 Table 2: Shim specific ancillary data 869 *1: cmsg_data[] should include padding (if necessary) and a single 870 sockaddr_in{}/sockaddr_in6{}. 872 It should be noted that the above ancillary data can only be handled 873 in UDP and raw sockets, not in TCP sockets. As explained in 874 [RFC3542], there is no one-to-one mapping of send/receive operations 875 and the TCP segments being transmitted/received. In case of TCP, 876 application may use setsockopt() or getsockopt() to access or specify 877 some of locator information provided by the shim layer. 879 6.1. Get Locator Information from Incoming Packet 881 Application can get locator information from the received IP packet 882 by specifying the shim specific socket options for the socket. When 883 SHIM_LOC_LOCAL_RECV and/or SHIM_LOC_PEER_RECV socket options are set, 884 the application can retrieve local and/or remote locator from the 885 ancillary data. 887 6.2. Specify Locator Information for Outgoing Packet 889 Application can specify the locators to be used for transmitting an 890 IP packet by sendmsg(). When ancillary data of cmsg_type 891 SHIM_LOC_LOCAL_SEND and/or SHIM_LOC_PEER_SEND are specified, the 892 application can explicitly specify source and/or destination locators 893 to be used for the communication over the socket. 895 In addition, the application can specify the outgoing interface by 896 SHIM_IF_SEND ancillary data. The ancillary data should contain the 897 interface identifier of the physical interface over which the 898 application expects the packet to be transmitted. 900 Note that the effect is limited to the datagram transmitted by the 901 sendmsg(). 903 If the specified locator pair seems to be valid, the shim layer 904 overrides the locator of the IP packet as requested. 906 An error EINVALIDLOCATOR will be returned when validation of the 907 specified locator failed. 909 6.3. Notification from Application to Multihomign Shim 911 Application may provide feedback to the shim layer in accordance with 912 its communication status. The notification can be made by specifying 913 shim specific ancillary data in sendmsg() call. Note that this 914 notification is dynamic rather than static. 916 6.3.1. SHIM_FEEDBACK_POSITIVE 918 The application can simply inform the shim layer that its 919 communication is going well. 921 Ancillary data object is TBD. 923 An error ENOENT will be returned when there is no context associated 924 with the socket. 926 6.3.2. SHIM_FEEDBACK_NEGATIVE 928 The application can inform the shim layer that its communication is 929 not going well. 931 Ancillary data object is TBD. 933 An error ENOENT will be returned when there is no context associated 934 with the socket. 936 7. Data Structures 938 In this section, data structures newly defined for socket options for 939 multihoming shim layer are introduced. 941 7.1. Placeholder for Locator Information 943 Some of the socket options defined in this document handle locator 944 information. Locator information could be a single locator or an 945 array of locators. An important requirement is that the locator 946 information should be handled in a protocol independent manner. In 947 other words, an interface to the locator information should not be 948 dependent on any address family. 950 7.1.1. Locator Information Stored in Control Message 952 When either SHIM_LOC_LOCAL_* or SHIM_LOC_PEER_* socket option is 953 specified, sendmsg() or recvmsg() should handle locator information 954 as a control message. The locator information is stored in an 955 ancillary data object which consists of a common header (cmsghdr{}), 956 the data, and the padding if necessary. In the case when the locator 957 is IPv4, the cmsg_data[] should contain sockaddr_in{}. In the case 958 when the locator is IPv6, the cmsg_data[] should contain 959 sockaddr_in6{}. 961 7.1.2. Locator Information Handled by getsockopt() and setsockopt() 963 SHIM_LOC_LOCAL_PREF and SHIM_LOC_PEER_PREF socket options defined in 964 Section Section 5 () require getsockopt() or setsockopt() to handle a 965 single locator information. The data structure for storing the 966 locator information is TBD. 968 SHIM_LOCLIST_LOCAL and SHIM_LOCLIST_PEER defined in Section Section 5 969 () require getsockopt() or setsockopt() to handle a set of locator 970 information (aka locator list). The data structure for storing the 971 locator information is TBD. 973 7.2. Parameters of Path Exploration 975 SHIM_PATHEXPLORE requires getsockopt() or setsockopt() to handle a 976 set of parameters for the path exploration. The data structure is 977 TBD. 979 8. Implications for Existing Socket API Extensions 981 Some of the socket options defined in this document have some 982 overlapping with existing socket API and care should be made for the 983 usage not to confuse the features. 985 The socket options for requesting specific locators to be used for a 986 given transaction (SHIM_LOC_LOCAL_PREF and SHIM_LOC_PEER_PREF) are 987 semantically similar to the existing socket API (IPV6_PKTINFO). The 988 socket options for obtaining the locator information from the 989 received IP packet (SHIM_LOC_LOCAL_RECV and SHIM_LOC_PEER_RECV) are 990 semantically similar to the existing socket API (IP_RECVDSTADDR and 991 IPV6_PKTINFO). 993 In IPv4, application can obtain the destination IP address of the 994 received IP packet (IP_RECVDSTADDR). If the shim layer performs 995 identifier/locator adaptation for the received packet, the 996 destination EID should be stored in the ancillary data 997 (IP_RECVDSTADDR). 999 In IPv6, [RFC3542] defines that IPV6_PKTINFO can be used to specify 1000 source IPv6 address and the outgoing interface for outgoing packets, 1001 and retrieve destination IPv6 address and receiving interface for 1002 incoming packets. This information is stored in ancillary data being 1003 IPV6_PKTINFO specified as cmsg_type. Existing socket API should 1004 continue to work above the shim layer, that is, the IP addresses 1005 handled in IPV6_PKTINFO should be EIDs, not the locators. 1007 Baseline is that the above existing socket API (IP_RECVDSTADDR and 1008 IPV6_PKTINFO) is assumed to work above the multihoming shim layer. 1009 In other words, the IP addresses those socket options deal with are 1010 EIDs rather than locators. 1012 9. Discussion 1014 In this section, open discussion issues are noted. 1016 9.1. Issues with a Context Shared by Applications 1018 A context is by definition, system-wide. This means that a context 1019 could be shared by applications whose communications are using the 1020 same EID pair. 1022 When a context is shared by applications, there may be some problems 1023 when the shim layer needs to handle feedbacks from the multiple 1024 applications. As mentioned in Section Section 6, an application may 1025 provide the shim layer feedback about timeout values from its own 1026 settings. This implies that there is potentially a race condition at 1027 the shim layer. 1029 First of all, the socket options must be used with a proper 1030 privilege. Feedback from the application which is run under a root 1031 privilege must always override the feedback provided by application 1032 which is run under normal user privilege. 1034 For other cases, one could rely on a kind of heuristics of the 1035 configuration. For instance, prioritizing feedback with higher 1036 demand (e.g. timeout value 300 seconds are more demanding then 1037 timeout value 600 seconds) may make sense in some cases. However, it 1038 is still an open issue what kind of timer value could be handled in 1039 this way. 1041 Further discussions are needed how the shim layer can accommodate 1042 feedbacks from multiple applications within a same context. 1044 9.2. Issues with Shim Unaware Application 1046 In multihomed environment where either of the peers or both of the 1047 peers have multiple locators, there are some issues with shim unaware 1048 application which uses legacy socket API. 1050 9.2.1. Initial Contact with Multiple Locator Pairs 1052 In a connection oriented communication, the connect() system call is 1053 used to make the initial contact to the peer, which typically 1054 requires IP address and port number to specify the endpoint. Hence, 1055 name-to-address resolution should be performed prior to connect(). 1056 The application needs to resolve the FQDN of the peer to an IP 1057 address by any available name-to-address conversion method. 1059 In typical case, the application receives information from the 1060 resolver. If the application ends up with receiving multiple IP 1061 addresses to reach the peer, it should iterate through each 1062 destination address one-by-one. It should be noted that the host may 1063 also have multiple source addresses. 1065 The different resulting address pairs may have different reachability 1066 status so, in order to find a working address pair, it may be 1067 required to explore all the available address pairs (as opposed to 1068 explore all available destination addresses). 1070 In normal case, the application issues a connect() by specifying the 1071 resolved IP address of the peer. If the connect() fails, it iterates 1072 through the available IP addresses one by one sequentially until 1073 working pair is found. Another approach is to initiate concurrent 1074 connect() with every locator of the peer. connect() can also be 1075 called in a sequence which would probably require more time to find 1076 the working pair. 1078 There is a case where involvement of the shim layer is expected for 1079 handling initial contact. In such case, behavior of the shim layer 1080 will depend on presence of the required context. This case occurs 1081 when there exists a context for the EID specified in connect(), the 1082 initial contact can be made in accordance with the context 1083 information. Otherwise, the shim layer should invoke context 1084 establishment with the peer EID specified in the argument for 1085 connect(). 1087 Additional efforts would be required in a case where the peer cannot 1088 be reachable through the EID (for example, EID is non-routable or 1089 non-IP reachable) but it can be reached through alternative locator. 1090 In particular, the shim layer should somehow discover the alternate 1091 locator for the EID to establish context. [I-D.nordmark-shim6-esd] 1092 addresses the possible approach to perform reverse DNS lookup from 1093 EID to FQDN, then perform forward lookup again to find the full-set 1094 of locators and EID. 1096 In HIP, resolving HITs to IP addresses using DNS is not feasible 1097 because HITs do not contain any hierarchical information. To 1098 mitigate this problem, there are a few alternatives. Firstly, 1099 resolver library on end-host can be modified to provide HIT-to-IP 1100 mappings for HIP software module. Secondly, a distributed hash table 1101 (DHT) service can be used for storing and looking up the mappings 1102 because it supports non-hierarchical identifiers, such as HITs 1103 [I-D.ietf-hip-arch]. Thirdly, it is possible to use IP addresses in 1104 legacy applications as described in [I-D.henderson-hip-applications]. 1106 9.2.2. Naming at Socket Layer 1108 getsockname() and getpeername() system calls are used to obtain the 1109 'name' of endpoint which is actually a pair of IP address and port 1110 number assigned to a given socket. getsockname() is used when an 1111 application wants to obtain the local IP address and port number 1112 assigned for a given socket instance. getpeername() is used when an 1113 application wants to obtain the remote IP address and port number. 1115 The above is based on a traditional system model of the socket API 1116 where an IP address is expected to play both the role of identifier 1117 and the role of locator. 1119 In a system model where a shim layer exists inside the IP layer, both 1120 getsockname() and getpeername() deal with identifiers, namely EIDs. 1121 In this sense, the shim layer serves to (1) hide locators and (2) 1122 provide access to the identifier for the application over the legacy 1123 socket APIs. 1125 9.3. Additional Requirements from Application 1127 At the moment, it is not certain if following requirements are common 1128 in all the multihomed environments (SHIM6 and HIP). These are mainly 1129 identified during discussions made on SHIM6 WG mailing list. 1130 o The application should be able to set preferences for the 1131 locators, local and remote one and also to the preferences of the 1132 local locators that will be passed to the peer. 1134 9.4. Issues of Header Conversion among Different Address Family 1136 The shim layer performs identifier/locator adaptation. Therefore, in 1137 some case, the whole IP header can be replaced with new IP header of 1138 a different address family (e.g. conversion from IPv4 to IPv6 or vice 1139 versa). Hence, there is an issue how to make the conversion with 1140 minimum impact. Note that this issue is common in other protocol 1141 conversion such as SIIT[RFC2765]. 1143 As addressed in SIIT specification, some of the features (IPv6 1144 routing headers, hop-by-hop extension headers, or destination 1145 headers) from IPv6 are not convertible to IPv4. In addition, notion 1146 of source routing is not exactly the same in IPv4 and IPv6. Hence, 1147 there is certain limitation in protocol conversion between IPv4 and 1148 IPv6. 1150 The question is how should the shim layer behave when it is face with 1151 limitation problem of protocol conversion. Should we introduce new 1152 error something like ENOSUITABLELOCATOR ? 1154 9.5. Handling of Unknown Locator Provided by Application 1156 There might be a case where application provides the shim layer new 1157 locator with the SHIM_LOC_*_PREF socket options or SHIM_LOC_*_SEND 1158 ancillary data. Then there is a question how should the shim layer 1159 treat the new locator informed by the application. 1161 In principle, locator information are exchanged by the shim protocol. 1162 However, there might be a case where application acquires information 1163 about the locator and prefers to use it for its communication. 1165 10. IANA Considerations 1167 This document contains no IANA consideration. 1169 11. Security Considerations 1171 This document does not specify any security mechanism for the shim 1172 layer. Fundamentally, the shim layer has a potential to impose 1173 security threats, as it changes the source and/or destination IP 1174 addresses of the IP packet being sent or received. Therefore, the 1175 basic assumption is that the security mechanism defined in each 1176 protocol of the shim layer is strictly applied. 1178 12. Conclusion 1180 In this document, the Application Program Interface (API) for 1181 multihomed shim layer is specified. The socket API allows 1182 applications to have additional control on the locator management and 1183 interface to the REAP mechanism inside the shim layer. The socket 1184 API is expected to be useful for applications that may greatly 1185 benefit from multihomed environment. From the architectural 1186 perspective, the socket API enhances software development environment 1187 in a sense that it allows separate treatment of identifier and 1188 locator at the IP layer. The API is designed with a care not to 1189 break the semantics of existing socket API and minimize the impact to 1190 the legacy applications. 1192 Multihoming shim socket options defined in this document can be used 1193 by getsockopt() and/or setcokopt() system calls, which allow 1194 applications to have control of locator management. Additionally, 1195 applications can specify locator information for outgoing packet and 1196 get locator information from incoming packet by using ancillary data 1197 objects that are specific to the multihoming shim layer. 1199 13. Acknowledgments 1201 Authors would like to thank Jari Arkko who participated in the 1202 discussion that lead to the first version of this document, and 1203 Tatuya Jinmei who thoroughly reviewed the early version of this draft 1204 and provided detailed comments on socket API related issues. 1206 14. References 1208 14.1. Normative References 1210 [I-D.henderson-hip-applications] 1211 Henderson, T. and P. Nikander, "Using HIP with Legacy 1212 Applications", draft-henderson-hip-applications-03 (work 1213 in progress), May 2006. 1215 [I-D.ietf-hip-arch] 1216 Moskowitz, R. and P. Nikander, "Host Identity Protocol 1217 Architecture", draft-ietf-hip-arch-03 (work in progress), 1218 August 2005. 1220 [I-D.ietf-shim6-failure-detection] 1221 Arkko, J. and I. Beijnum, "Failure Detection and Locator 1222 Pair Exploration Protocol for IPv6 Multihoming", 1223 draft-ietf-shim6-failure-detection-03 (work in progress), 1224 December 2005. 1226 [I-D.ietf-shim6-proto] 1227 Bagnulo, M. and E. Nordmark, "Level 3 multihoming shim 1228 protocol", draft-ietf-shim6-proto-03 (work in progress), 1229 December 2005. 1231 [POSIX] "IEEE Std. 1003.1-2001 Standard for Information Technology 1232 -- Portable Operating System Interface (POSIX). Open group 1233 Technical Standard: Base Specifications, Issue 6, 1234 http://www.opengroup.org/austin", December 2001. 1236 [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, 1237 "Advanced Sockets Application Program Interface (API) for 1238 IPv6", RFC 3542, May 2003. 1240 14.2. Informative References 1242 [I-D.ietf-shim6-app-refer] 1243 Nordmark, E., "Shim6 Application Referral Issues", 1244 draft-ietf-shim6-app-refer-00 (work in progress), 1245 July 2005. 1247 [I-D.ietf-shim6-hba] 1248 Bagnulo, M., "Hash Based Addresses (HBA)", 1249 draft-ietf-shim6-hba-01 (work in progress), October 2005. 1251 [I-D.nordmark-shim6-esd] 1252 Nordmark, E., "Extended Shim6 Design for ID/loc split and 1253 Traffic Engineering", draft-nordmark-shim6-esd-00 (work in 1254 progress), February 2006. 1256 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 1257 (SIIT)", RFC 2765, February 2000. 1259 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1260 RFC 3972, March 2005. 1262 Authors' Addresses 1264 Miika Komu 1265 Helsinki Institue for Information Technology 1266 Tammasaarenkatu 3 1267 Helsinki 1268 Finland 1270 Phone: +358503841531 1271 Fax: +35896949768 1272 Email: miika@iki.fi 1273 URI: http://www.hiit.fi/ 1275 Marcelo Bagnulo 1276 Universidad Carlos III de Madrid 1277 Av. Universidad 30 1278 Leganes 28911 1279 SPAIN 1281 Phone: +34 91 6248837 1282 Email: marcelo@it.uc3m.es 1283 URI: http://it.uc3m.es/marcelo 1285 Kristian Slavov 1286 Ericsson Research Nomadiclab 1287 Hirsalantie 11 1288 Jorvas FI-02420 1289 Finland 1291 Phone: +358 9 299 3286 1292 Email: kristian.slavov@ericsson.com 1294 Shinta Sugimoto (editor) 1295 Nippon Ericsson K.K. 1296 Koraku Mori Building 1297 1-4-14, Koraku, Bunkyo-ku 1298 Tokyo 112-0004 1299 Japan 1301 Phone: +81 3 3830 2241 1302 Email: shinta.sugimoto@ericsson.com 1304 Intellectual Property Statement 1306 The IETF takes no position regarding the validity or scope of any 1307 Intellectual Property Rights or other rights that might be claimed to 1308 pertain to the implementation or use of the technology described in 1309 this document or the extent to which any license under such rights 1310 might or might not be available; nor does it represent that it has 1311 made any independent effort to identify any such rights. Information 1312 on the procedures with respect to rights in RFC documents can be 1313 found in BCP 78 and BCP 79. 1315 Copies of IPR disclosures made to the IETF Secretariat and any 1316 assurances of licenses to be made available, or the result of an 1317 attempt made to obtain a general license or permission for the use of 1318 such proprietary rights by implementers or users of this 1319 specification can be obtained from the IETF on-line IPR repository at 1320 http://www.ietf.org/ipr. 1322 The IETF invites any interested party to bring to its attention any 1323 copyrights, patents or patent applications, or other proprietary 1324 rights that may cover technology that may be required to implement 1325 this standard. Please address the information to the IETF at 1326 ietf-ipr@ietf.org. 1328 Disclaimer of Validity 1330 This document and the information contained herein are provided on an 1331 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1332 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1333 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1334 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1335 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1336 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1338 Copyright Statement 1340 Copyright (C) The Internet Society (2006). This document is subject 1341 to the rights, licenses and restrictions contained in BCP 78, and 1342 except as set forth therein, the authors retain all their rights. 1344 Acknowledgment 1346 Funding for the RFC Editor function is currently provided by the 1347 Internet Society.