idnits 2.17.1 draft-sugimoto-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 1323. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1300. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1307. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1313. ** 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 787 has weird spacing: '... u_int msg_...' == Line 788 has weird spacing: '... struct iovec...' == Line 789 has weird spacing: '... u_int msg_...' == Line 791 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) == Unused Reference: 'I-D.ietf-shim6-hba' is defined on line 1234, but no explicit reference was found in the text -- 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 3493 ** 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: 6 errors (**), 0 flaws (~~), 11 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network 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-sugimoto-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 also for 48 accessing to information about failure detection and path 49 exploration. 51 This document is based on an assumption that a multhomed host is 52 equipped with a 'shim' layer which essentially maintains mappings 53 between identifiers and locators at the IP layer. SHIM6 and HIP are 54 examples of this shim layer. Hence, the API can be commonly used by 55 SHIM6 and HIP. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Target . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. System Overview . . . . . . . . . . . . . . . . . . . . . . . 6 63 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 6. Socket Options for Multihomed Shim Layer . . . . . . . . . . . 9 65 6.1. SHIM_ASSOCIATED . . . . . . . . . . . . . . . . . . . . . 12 66 6.2. SHIM_DONTSHIM . . . . . . . . . . . . . . . . . . . . . . 12 67 6.3. SHIM_HOT_STANDBY . . . . . . . . . . . . . . . . . . . . . 13 68 6.4. SHIM_PATHEXPLORE . . . . . . . . . . . . . . . . . . . . . 13 69 6.5. SHIM_LOC_LOCAL_PREF . . . . . . . . . . . . . . . . . . . 13 70 6.6. SHIM_LOC_PEER_PREF . . . . . . . . . . . . . . . . . . . . 14 71 6.7. SHIM_LOC_LOCAL_RECV . . . . . . . . . . . . . . . . . . . 14 72 6.8. SHIM_LOC_PEER_RECV . . . . . . . . . . . . . . . . . . . . 15 73 6.9. SHIM_LOCLIST_LOCAL . . . . . . . . . . . . . . . . . . . . 15 74 6.10. SHIM_LOCLIST_PEER . . . . . . . . . . . . . . . . . . . . 15 75 6.11. SHIM_APP_TIMEOUT . . . . . . . . . . . . . . . . . . . . . 16 76 6.12. SHIM_FEEDBACK_POSITIVE . . . . . . . . . . . . . . . . . . 16 77 6.13. SHIM_FEEDBACK_NEGATIVE . . . . . . . . . . . . . . . . . . 16 78 6.14. SHIM_DEFERRED_CONTEXT_SETUP . . . . . . . . . . . . . . . 17 79 6.15. SHIM_IF_RECV . . . . . . . . . . . . . . . . . . . . . . . 17 80 6.16. SHIM_IF_SEND . . . . . . . . . . . . . . . . . . . . . . . 17 81 6.17. Error Handling . . . . . . . . . . . . . . . . . . . . . . 17 82 7. Access to Locator Information . . . . . . . . . . . . . . . . 18 83 7.1. Get Locator Information from Incoming Packet . . . . . . . 19 84 7.2. Specify Locator Information for Outgoing Packet . . . . . 20 85 8. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 20 86 8.1. Placeholder for Locator Information . . . . . . . . . . . 20 87 8.1.1. addrinfo structure . . . . . . . . . . . . . . . . . . 20 88 8.1.2. sockaddr_storage structure . . . . . . . . . . . . . . 21 89 9. Implications for Existing Socket API Extensions . . . . . . . 22 90 10. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 23 91 10.1. Issues with a Context Shared by Applications . . . . . . . 23 92 10.2. Issues with Shim Unaware Application . . . . . . . . . . . 24 93 10.2.1. Initial Contact with Multiple Locator Pairs . . . . . 24 94 10.2.2. Naming at Socket Layer . . . . . . . . . . . . . . . . 25 95 10.3. Additional Requirements from Application . . . . . . . . . 25 96 10.4. Issues of Header Conversion among Different Address 97 Family . . . . . . . . . . . . . . . . . . . . . . . . . . 26 98 10.5. Handling of Unknown Locator Provided by Application . . . 26 99 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 100 12. Security Considerations . . . . . . . . . . . . . . . . . . . 26 101 13. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 27 102 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 103 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 104 15.1. Normative References . . . . . . . . . . . . . . . . . . . 27 105 15.2. Informative References . . . . . . . . . . . . . . . . . . 28 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 107 Intellectual Property and Copyright Statements . . . . . . . . . . 30 109 1. Introduction 111 This document specifies a socket API for the multihoming shim layer. 112 The API aims to enable interactions between application and the 113 multihoming shim layer for advanced locator management and for 114 accessing to information about failure detection and path 115 exploration. 117 This document is based on an assumption that a multhomed host is 118 equipped with a 'shim' layer which essentially maintains mapping 119 between identifiers and locators at the IP layer. SHIM6 and HIP are 120 examples of the shim. Hence, the API can be commonly used by SHIM6 121 and HIP. 123 We suggest that the ID/Locator adaptation is done only once inside 124 the network stack. In other words, if there exist multiple shim 125 sublayers at the IP layer, any one of them should be exclusively 126 applied for a given flow. 128 We try to make this document be in line with Posix standard [POSIX] 129 as much as possible. And the API defines how to use ancillary data 130 (aka cmsg) to access locator information with recvmsg() and/or 131 sendmsg() I/O calls. Definition of API is presented in C language 132 and data types follow Posix format: intN_t means a singed integer of 133 exactly N bits (e.g. int16_t) and uintN_t means an unsigned integer 134 of exactly N bits (e.g. uint32_t). 136 2. Target 138 The primary target reader of this document is application programmers 139 who develop application software which may run on top of a multihomed 140 environment. In particular, the API should be beneficial for 141 application development of the software which takes advantage of 142 multihomed environment aiming to achieve better failover. 144 Secondly, this document should be of interest for the developers of a 145 given protocol stack for the shim layer (e.g. SHIM6 and HIP). This 146 is because this document specifies what kinds of information exchange 147 should be possible between the applications and the shim layer. 149 3. Terminology 151 This document does not intend to give new definitions for technical 152 terms that are relevant to multihomed environments but tries to 153 inherit definitions provided in the existing documents as listed 154 below: 156 o SHIM6 Protocol Specification[I-D.ietf-shim6-proto] 157 o HIP Architecture[I-D.ietf-hip-arch] 158 o Reachability Protocol (REAP)[I-D.ietf-shim6-failure-detection] 160 For clarification, we provide definition for the terms that are 161 frequently used in this document: 163 o Endpoint Identifier (EID) - An identifier used by the application 164 to specify an endpoint of the communication. As addressed in 165 [I-D.ietf-shim6-app-refer], application may handle and EID in 166 various ways in different types of communication models such as 167 long-lived connections, callbacks, and referrals. 168 * In case of SHIM6, the EID is called ULID. The ULID is chosen 169 from one of the locators available on the host. 170 * In case of HIP, the EID is essentially a public key of the 171 host. In order to preserve backward compatibility with legacy 172 applications, a hash of public key called Host Identity Tag 173 (HIT) is used by the applications as a handle for the EID. 174 o Locator - An IP address actually used to deliver IP packets. 175 Locators should be present in the source and destination fields of 176 the IP header of a packet that appears on wire. Normally, a 177 locator is assigned to the network interface of the host. And the 178 IP packet destined to a given locator is delivered to the 179 correspondent network interface by the routing system. 180 o Shim - A conceptual (sub-)layer inside the IP Layer which 181 maintains mappings of EIDs and locators. An EID can be associated 182 with more than one locator at a time when the host is multihomed. 183 It should be noted that the term 'shim' does not refer to a 184 specific protocol but refers to the generic concept of a layer 185 that enables the mapping between identifiers and locators. SHIM6 186 and HIP are examples of the shim. 187 o Context - A state information shared by the peers, which 188 essentially stores a binding between the EIDs and associated 189 locators. The context is maintained at the shim layer of the 190 host. 191 o List of Locators - A list of locators associated with an EID. 192 There are two lists of locators stored in a given context, one is 193 associated with the local EID and the other is associated with the 194 remote EID. As defined in [I-D.ietf-shim6-proto], the list of 195 locators associated with an EID 'A' can be denoted as Ls(A). 196 o Preferred Locator - The (source/destination) locator currently 197 used to send packets. As defined in [I-D.ietf-shim6-proto], the 198 preferred locator of a host which EID is 'A' can be denoted as 199 Lp(A). 200 o Reachability Detection - A procedure to detect reachability 201 between a given locator pair. 203 o Path - A sequence of routers that an IP packet goes through to 204 reach the destination. 205 o Path Exploration - A procedure to explore available paths for a 206 given set of locator pairs. 207 o Outage - An incident meaning that the reachability among a given 208 locator pair is lost. The outage could be caused by any kind of 209 problems inside the routing infrastructure and/or problems of the 210 network interfaces of the end hosts. 211 o Working Address Pair - An address pair is said to be working if 212 the packet containing the first address from the pair as source 213 address and the second address from the pair as destination 214 address can safely travel from the source to the destination. If 215 the reachability is confirmed in both directions, the address 216 pairs is said to be bi-directional. Otherwise, it's 217 unidirectional. 218 o REAP - A protocol for detecting failure and exploring reachability 219 in a multihomed environment. REAP is defined in[I-D.ietf-shim6- 220 failure-detection]. 221 o Endpoint Descriptor (ED) - The representation of endpoints is 222 hidden from the applications. ED is a "handle" or "pointer" to 223 the actual EID. 225 4. System Overview 227 +------------------------+ 228 | Application | 229 +------------------------+ 230 ^ ^ 231 ~~~~~~~~~~~~~|~Socket Interface|~~~~~~~~~~~~~~ 232 | v 233 +-----------|------------------------------+ 234 | | Transport Layer | 235 +-----------|------------------------------+ 236 ^ | 237 +-------------|-----|-------------------------------------+ 238 | v v | 239 | +-----------------------------+ +----------+ | IP 240 | | Shim |<----->| REAP | | Layer 241 | +-----------------------------+ +----------+ | 242 | ^ ^ | 243 +-----------------------|----------------------|----------+ 244 v v 245 +------------------------------------------+ 246 | Link Layer | 247 +------------------------------------------+ 249 Figure 1: System overview 251 Figure 1 illustrates the system overview. The application can use 252 the socket API to interact with the shim layer and the transport 253 layer for better control of locator management, failure detection and 254 path exploration. 256 Inside the IP layer, there is the shim which closely interacts with 257 REAP component. There could be interactions between the shim and the 258 transport layer, however they are outside of scope of this document. 259 The scope of this document is an interface from the application to 260 the shim layer, which is enabled via the socket interface. 262 5. Requirements 264 The list of requirements from the application perspective is the 265 following. These requirements are mainly identified during the 266 discussions on SHIM6 WG mailing list. Some requirements are derived 267 from Reachability Protocol document[I-D.ietf-shim6-failure- 268 detection]. 270 o Locator management. The shim layer selects a pair of locators for 271 sending IP packets within a given context. The selection is made 272 by taking miscellaneous conditions into account such as 273 reachability of the path, application's preference, and 274 characteristics of path. From the application's perspective: 275 * It should be possible to obtain the lists of locators of a 276 given context: Ls(local) and Ls(remote). 277 * It should be possible to obtain the preferred locators of a 278 given context: Lp(local) and Lp(remote). 279 o Notification from the application to the shim layer about the 280 status of the communication. Note that the notification is made 281 in an event based manner. There are mainly two aspects of the 282 feedback that application or upper layer protocol may provide for 283 the shim layer, positive and negative feedbacks [NOTE: These 284 feedbacks are addressed in section 4.3 and section 5.2 of REAP 285 specification]: 286 * Positive feedback could be given by the application or upper 287 layer protocol (e.g. TCP) to the shim layer informing that the 288 communication is going well. 289 * Negative feedback could be given by the application or upper 290 layer protocol (e.g. TCP) to the shim layer informing that the 291 communication status is not satisfactory. TCP could detect a 292 problem when it does not receives expected ACK from the peer. 293 ICMP error messages delivered to the upper layer protocol could 294 be a clue for application to detect potential problems. REAP 295 module may be triggered by these negative feedbacks and invoke 296 procedure of path exploration. 297 o Feedback from application to shim layer. The application should 298 be able to inform the shim layer about the timeout values for 299 detecting failures, for sending keepalives, for starting the 300 exploration procedure. In particular, the application should be 301 able to suppress the keepalives. 302 o Hot-standby. The application may request the shim layer for hot- 303 standby capabilities. In this case, alternative paths are known 304 to be working before a failure is detected. Hence it is possible 305 for the host to immediately replace the current locator pair with 306 the alternative locator pair. Hot-standby may allow applications 307 to achieve better failover. 308 o Eagerness of locator exploration. The application should be able 309 to inform the shim layer how aggressive it wants REAP mechanism to 310 perform path exploration (e.g. specifying the number of concurrent 311 attempts of discovering working locator pair) when an outage 312 occurs on the path between the currently selected locator pair. 313 o Providing locator information to application. The application 314 should be able to obtain information about the locator pair which 315 was actually used to send or receive the packet. 316 * For inbound traffic, the application may be interested in the 317 locator pair which was actually used to receive the packet. 318 * For outbound traffic, the application may be interested in the 319 locator pair which was actually used to transmit the packet. 320 In this way, the application may have additional control on the 321 locator management. For example, the application can verify if 322 its preference of locator is actually applied to the flow or not. 323 o The application should be able to specify if it wants to defer the 324 context setup or if it wants context establishment to be started 325 immediately in case there is no available context. With deferred 326 context setup, there should be no additional delay imposed by 327 context establishment in initiation of communication. 328 o Turn on/off shim. The application should be able to request to 329 turn on/off the multihoming support by the shim layer: 330 * Apply shim. The application should be able to explicitly 331 request the shim layer to apply multihoming support. 332 * Don't apply shim. The application should be able to request 333 the shim layer not to apply the multihoming support but to 334 apply normal IP processing at the IP layer. 335 o The application should be able to know if the communication is now 336 served by the shim layer or not. 337 o The application should be able to access locator information 338 regardless of its address family. In other words, no matter the 339 target locator is IPv4 or IPv6, the application should be able to 340 use common interface to access the locator information. 342 6. Socket Options for Multihomed Shim Layer 344 In this section, the socket options for the interface between the 345 application and the multihomed shim layer are defined. These options 346 can be used either by getsockopt() and/or setsockopt() system calls 347 for an opened socket. Table 1 provides a list of the socket options. 348 Note that all socket options are defined at level SOL_SHIM. 350 The first column of the table gives the name of the option. The 351 second and third columns indicates whether if the option is for 352 getsockopt() and/or setsockopt(), respectively. The fourth column 353 provides a brief description of the socket option. The fifth column 354 shows the data structure specified with the socket option, which can 355 store an argument for setsockopt() and result for getsockopt(). By 356 default, the data structure is an integer. 358 +-----------------------------+-----+-----+-----------------+-------+ 359 | optname | get | set | description | dtype | 360 +-----------------------------+-----+-----+-----------------+-------+ 361 | SHIM_ASSOCIATED | o | | Check if the | int | 362 | | | | socket is | | 363 | | | | associated with | | 364 | | | | any shim | | 365 | | | | context or not. | | 366 | SHIM_DONTSHIM | o | o | Request the | int | 367 | | | | shim layer not | | 368 | | | | to apply any | | 369 | | | | multihoming | | 370 | | | | support for the | | 371 | | | | communication. | | 372 | SHIM_HOT_STANDBY | | o | Request the | int | 373 | | | | shim layer to | | 374 | | | | prepare a | | 375 | | | | hot-standby | | 376 | | | | connection (in | | 377 | | | | addition to the | | 378 | | | | current path). | | 379 | SHIM_LOC_LOCAL_PREF | o | o | Get or set the | *1 | 380 | | | | preferred | | 381 | | | | locator on the | | 382 | | | | local side for | | 383 | | | | the context | | 384 | | | | associated with | | 385 | | | | the socket. | | 386 | SHIM_LOC_PEER_PREF | o | o | Get or set the | *1 | 387 | | | | preferred | | 388 | | | | locator on the | | 389 | | | | remote side for | | 390 | | | | the context | | 391 | | | | associated with | | 392 | | | | the socket. | | 393 | SHIM_LOC_LOCAL_RECV | | o | Request for the | int | 394 | | | | destination | | 395 | | | | locator of the | | 396 | | | | received IP | | 397 | | | | packet. | | 398 | SHIM_LOC_PEER_RECV | | o | Request for the | int | 399 | | | | source locator | | 400 | | | | of the received | | 401 | | | | IP packet. | | 402 | SHIM_LOCLIST_LOCAL | o | o | Get or set a | *1 | 403 | | | | list of | | 404 | | | | locators | | 405 | | | | associated with | | 406 | | | | the local EID. | | 407 | SHIM_LOCLIST_PEER | o | o | Get or set a | *1 | 408 | | | | list of | | 409 | | | | locators | | 410 | | | | associated with | | 411 | | | | the peer's EID. | | 412 | SHIM_APP_TIMEOUT | | o | Inform the shim | int | 413 | | | | layer about a | | 414 | | | | timeout value | | 415 | | | | for detecting | | 416 | | | | failure. | | 417 | SHIM_FEEDBACK_POSITIVE | | o | Provide a | int | 418 | | | | positive | | 419 | | | | feedback to the | | 420 | | | | shim layer. | | 421 | SHIM_FEEDBACK_NEGATIVE | | o | Provide a | *2 | 422 | | | | negative | | 423 | | | | feedback to the | | 424 | | | | shim layer. | | 425 | SHIM_PATHEXPLORE | | o | Specify how | *3 | 426 | | | | path | | 427 | | | | exploration | | 428 | | | | should be | | 429 | | | | performed in | | 430 | | | | case of | | 431 | | | | failure. | | 432 | SHIM_CONTEXT_DEFERRED_SETUP | | o | Specify if the | int | 433 | | | | context setup | | 434 | | | | can be deferred | | 435 | | | | or not. | | 436 | SHIM_IF_RECV | | o | Request for a | int | 437 | | | | receiving | | 438 | | | | interface. | | 439 | SHIM_IF_SEND | | o | Request for an | int | 440 | | | | outgoing | | 441 | | | | interface. | | 442 +-----------------------------+-----+-----+-----------------+-------+ 444 Table 1: Shim specific socket options for getsockopt() and 445 setsockopt() 447 *1: Pointer to the buffer which stores arrays of locator information. 448 The buffer is actually the chained list of addrinfo structure. 450 *2: TBD. 452 *3: TBD. 454 Figure 2 illustrates how the shim specific socket options fit into 455 the system model of socket API. In the figure, it can be seen that 456 the shim layer and the additional protocol components (IPv4 and IPv6) 457 below the shim layer are new to the system model. As previously 458 mentioned, all the shim specific socket options are defined at 459 SOL_SHIM level. This design choice brings the following advantages: 461 1. It is assured that the existing socket API continue to work at 462 the layer above the shim layer. That is, those legacy API deal 463 with 'identifier' aspect of the IP addresses. 464 2. With newly defined socket options for the shim layer, the 465 application obtains additional control on locator management. 466 3. The shim specific socket options are not specific to any address 467 family (IPPROTO_IP or IPPROTO_IPV6) nor any transport protocol 468 (SOCK_STREAM or SOCK_DGRAM or SOCK_RAW). 470 s1 s2 s3 s4 471 | | | | 472 +----------------|--|-------|--|----------------+ 473 | +-------+ +-------+ | 474 | IPPROTO_TCP | TCP | | UDP | | 475 | +-------+ +-------+ | 476 | | \ / | | 477 | | ----- | | 478 | | / \ | | 479 | +------+ +------+ | 480 | IPPROTO_IP | IPv4 | | IPv6 | IPPROTO_IPV6 | 481 | +------+ +------+ | 482 | \ / SOL_SOCKET 483 | +--------\-------/--------+ | 484 | SOL_SHIM | shim | | 485 | +--------/-------\--------+ | 486 | / \ | 487 | +------+ +------+ | 488 | | IPv4 | | IPv6 | | 489 | +------+ +------+ | 490 | | | | 491 +------------------|----------|-----------------+ 492 | | 493 IPv4 IPv6 494 Datagram Datagram 496 Figure 2: System model of socket API with shim layer 498 6.1. SHIM_ASSOCIATED 500 This option can be specified by getsockopt() to check if the socket 501 is associated with a shim context or not. Thus, the option is read- 502 only and the result (0 or 1) is set in optval. A returned value 1 503 means that the socket is associated with a given shim context at the 504 shim layer, while a return value 0 indicates that there is no context 505 associated with the socket. 507 This option is particularly meaningful in a case where locator 508 information of the received IP packet is not enough for identifying 509 if the ID/Locator adaptation is performed or not. Note that the EID 510 pair and locator pair maybe identical in some case. 512 ISSUE: Should we limit this option only for 'connected' socket ? 514 6.2. SHIM_DONTSHIM 516 This option can be specified either by getsockopt() or setsockopt(). 518 The application can specify the option by setsockopt() taking the 519 argument optval with value 1 to request the shim layer not to apply 520 any multihoming support for the communication. The application can 521 also obtain the current setting by specifying the the socket option 522 in getsockopt(). The result should be binary (0 or 1). 524 By default, the value is set to 0, meaning that the shim layer will 525 try to apply ID/Locator adaptation for the communication over a given 526 socket. 528 Once the socket option is specified by setsockopt(), it remains 529 effective until it is deactivated (sticky option). 531 6.3. SHIM_HOT_STANDBY 533 This option can be specified by setsockopt(). 535 By setting 1 in the optval for the setsockopt(), the application can 536 request the shim layer to use a hot-standby connection. The hot- 537 standby connection is another working locator pair than the current 538 locator pair. 540 By default, the value is set to 0, meaning that hot-standby 541 connection is disabled. 543 Once the socket option is specified by setsockopt(), it remains 544 effective until it is deactivated (sticky option). 546 6.4. SHIM_PATHEXPLORE 548 This option can be specified either by setsockopt() or getsockopt(). 549 The value specified by the option indicates how aggressive the 550 application wants path exploration to be performed in case of 551 failure. Therefore, this option is effective only when there is 552 associated shim context for the socket. 554 The information to be provided by this socket option should contain: 555 suggested number of attempts for path exploration, frequency of the 556 path exploration, and so on. Need further discussions. 558 The data type for the argument optval is TBD. 560 Once the socket option is specified by setsockopt(), it remains 561 effective until it is deactivated (sticky option). 563 6.5. SHIM_LOC_LOCAL_PREF 565 This option can be specified either by setsockopt() or getsockopt(). 567 When specified by setsockopt(), the preferred locator on local side 568 is explicitly given to the shim layer. The shim layer shall 569 accordingly update the preferred locator of the context associated 570 with the socket. 572 When specified by getsockopt(), the preferred locator on local side 573 is returned by the shim layer. 575 An error ENOSHIMCONTEXT will be returned when there is no context 576 associated with the socket. 578 Once the socket option is specified by setsockopt(), it remains 579 effective until it is deactivated (sticky option). 581 6.6. SHIM_LOC_PEER_PREF 583 This option can be specified either by setsockopt() or getsockopt(). 585 When specified by setsockopt(), the preferred locator on remote side 586 is explicitly given to the shim layer. The shim layer shall 587 accordingly update the preferred locator of the context associated 588 with the socket. 590 When specified by getsockopt(), the preferred locator on remote side 591 is returned by the shim layer. 593 An error ENOSHIMCONTEXT will be returned when there is no context 594 associated with the socket. 596 An error EINVALIDLOCATOR will be returned when the validation of the 597 specified locator failed. 599 Once the socket option is specified by setsockopt(), it remains 600 effective until it is deactivated (sticky option). 602 6.7. SHIM_LOC_LOCAL_RECV 604 This option can be specified by setsockopt(). 606 When specified by setsockopt(), the shim layer stores the destination 607 locator of the received IP packet in an ancillary data object which 608 can be accessed by recvmsg(). The argument optval value should be 609 set to 1. 611 An error ENOSHIMCONTEXT will be returned when there is no context 612 associated with the socket. 614 Once the socket option is specified by setsockopt(), it remains 615 effective until it is deactivated (sticky option). 617 6.8. SHIM_LOC_PEER_RECV 619 This option can be specified by setsockopt(). 621 When specified by setsockopt(), the shim layer stores the source 622 locator of the received IP packet in an ancillary data object which 623 can be accessed by recvmsg(). The argument optval value should be 624 set to 1. 626 An error ENOSHIMCONTEXT will be returned when there is no context 627 associated with the socket. 629 Once the socket option is specified by setsockopt(), it remains 630 effective until it is deactivated (sticky option). 632 6.9. SHIM_LOCLIST_LOCAL 634 This option can be specified either by getsockopt() or setsockopt(). 636 When specified by setsockopt(), the application provides a list of 637 locators which is associated with the local EID to the shim layer. 638 Accordingly, the shim layer shall update the list of locators 639 Ls(local). The argument optval should contain a pointer to the 640 buffer in which a list of locators are stored. See Section 8 for 641 detail. 643 When specified by getsockopt(), the application obtains a list of 644 locators which is associated with the local EID. 646 An error ENOSHIMCONTEXT will be returned when there is no context 647 associated with the socket. 649 Once the socket option is specified by setsockopt(), it remains 650 effective until it is deactivated (sticky option). 652 6.10. SHIM_LOCLIST_PEER 654 This option can be specified either by getsockopt() or setsockopt(). 656 When specified by setsockopt(), the application provides a list of 657 locators which is associated with the remote EID to the shim layer. 658 Accordingly, the shim layer shall update the list of locators 659 Ls(remote). The argument optval should contain a pointer to the 660 buffer in which a list of locators are stored. See Section 661 Section 8.1for detail. 663 When specified by getsockopt(), the application obtains a list of 664 locators which is associated with the remote EID. 666 An error ENOSHIMCONTEXT will be returned when there is no context 667 associated with the socket. 669 Once the socket option is specified by setsockopt(), it remains 670 effective until it is deactivated (sticky option). 672 6.11. SHIM_APP_TIMEOUT 674 This option can be specified by setsockopt(). 676 The application can inform the shim layer about the timeout value for 677 detecting failure. The argument optval should contain the timeout 678 value in seconds. Accordingly, the shim layer shall update the 679 strategy for reachability test. Especially, this is efficient in a 680 case where the informed timeout value is shorter than the interval of 681 keepalive. In such case, keepalives to be performed by REAP may be 682 suppressed. 684 An error ENOSHIMCONTEXT will be returned when there is no context 685 associated with the socket. 687 Once the socket option is specified by setsockopt(), it remains 688 effective until it is deactivated (sticky option). 690 6.12. SHIM_FEEDBACK_POSITIVE 692 This option can be specified by setsockopt(). 694 The application can simply inform the shim layer that its 695 communication is going well. The argument optval should be set to 1. 697 An error ENOSHIMCONTEXT will be returned when there is no context 698 associated with the socket. 700 6.13. SHIM_FEEDBACK_NEGATIVE 702 This option can be specified by setsockopt(). 704 The application can inform the shim layer that its communication is 705 not going well. The argument optval should be TBD. 707 An error ENOSHIMCONTEXT will be returned when there is no context 708 associated with the socket. 710 6.14. SHIM_DEFERRED_CONTEXT_SETUP 712 This option can be specified by setsockopt(). 714 When specified by the setsockopt(), optval should be set to 1 if the 715 context setup can be deferred. Otherwise, the context setup is 716 invoked immediately when there is no shim context setup for the flow. 717 By default, the value is set to 1. 719 It should be noted that in some case, deferred context setup is not 720 possible; given EID is non-routable address and there is no way to 721 transmit any IP packet unless there is a context providing the 722 locators. In such case, context establishment should be made prior 723 to communication. 725 6.15. SHIM_IF_RECV 727 This option can be specified by setsockopt(). 729 The application can request the shim layer to provide information 730 about interface from which the packet was received. Once the socket 731 option is successfully set, the interface information can be obtained 732 by recvmsg() from the ancillary data. The argument optval should be 733 set to 1. 735 An error ENOSHIMCONTEXT will be returned when there is no context 736 associated with the socket. 738 Once the socket option is specified by setsockopt(), it remains 739 effective until it is deactivated (sticky option). 741 6.16. SHIM_IF_SEND 743 This option can be specified by setsockopt(). 745 The application can specify outgoing interface of the outbound 746 traffic over the socket. Application should specify the requested 747 interface identifier in the argument optval. Alternatively, this 748 option can also be specified in ancillary data in along with 749 sendmsg() call. 751 Once the socket option is specified by setsockopt(), it remains 752 effective until it is deactivated (sticky option). 754 6.17. Error Handling 756 If successful, getsockopt() and setsockopt() return 0; otherwise, the 757 functions return -1 and set errno to indicate error. 759 Following are errno codes newly defined for some shim specific socket 760 options indicating that the getsockopt() or setsockopt() finished 761 incompletely: 763 ENOSHIIMCONTEXT 764 There is no shim context associated with the socket. 765 EINVALIDLOCATOR 766 This indicates that at least one of the necessary validations 767 inside the shim layer for the specified locator has failed. In 768 case of SHIM6, there are two kinds of verifications required prior 769 sending an IP packet to the peer's new address; one is return 770 routability (check if the peer is actually willing to receive data 771 with the specified locator) and the other is verifications based 772 on given crypto identifier mechanisms[RFC3972], [I-D.ietf-shim6- 773 hba]. 775 7. Access to Locator Information 777 In this section, the way how to access locator information with some 778 I/O calls is presented. As defined in Posix, sendmsg() and recvmsg() 779 take msghdr structure as its argument and they can additionally 780 handle control information in along with data. Figure 3 shows the 781 msghdr structure which is defined in . msg_control 782 member holds a pointer to the buffer where the shim specific 783 ancillary data objects are stored. 785 struct msghdr { 786 caddr_t msg_name; /* optional address */ 787 u_int msg_namelen; /* size of address */ 788 struct iovec *msg_iov; /* scatter/gather array */ 789 u_int msg_iovlen; /* # elements in msg_iov */ 790 caddr_t msg_control; /* ancillary data, see below */ 791 u_int msg_controllen; /* ancillary data buffer len */ 792 int msg_flags; /* flags on received message */ 793 }; 795 Figure 3: msghdr structure 797 ISSUE: Should we introduce a new flag for msg_flags (e.g. 798 MSG_SHIMMED) ? Following the practice, it seems reasonable to do so, 799 but not sure how much it is useful. 801 The buffer pointed from the msg_control member of the msghdr 802 structure should contain a single locator and it should be possible 803 to process them with the existing macros defined in Posix and 804 [RFC3542]. Each cmsghdr{} should be followed by a data which stores 805 a single locator. 807 In case of non-connected socket, msg_name member stores the socket 808 address of the peer which should be considered as an identifier 809 rather than a locator. The locator of the peer node should be 810 retrieved by SHIM_LOC_PEER_RECV as specified below. 812 Table 2 is a list of the shim specific ancillary data which can be 813 used for recvmsg() or sendmsg(). In any case, SOL_SHIM must be set 814 as cmsg_level. 816 +---------------------+-----------+-----------+-------------+ 817 | cmsg_type | sendmsg() | recvmsg() | cmsg_data[] | 818 +---------------------+-----------+-----------+-------------+ 819 | SHIM_LOC_LOCAL_RECV | | o | *1 | 820 | SHIM_LOC_PEER_RECV | | o | *1 | 821 | SHIM_LOC_LOCAL_SEND | o | | *1 | 822 | SHIM_LOC_PEER_SEND | o | | *1 | 823 | SHIM_IF_RECV | | o | int | 824 | SHIM_IF_SEND | o | | int | 825 +---------------------+-----------+-----------+-------------+ 827 Table 2: Shim specific ancillary data 829 *1: cmsg_data[] should include padding (if necessary) and a single 830 sockaddr_storage{} a protocol independent placeholder for socket 831 addresses. 833 ISSUE: Is the design choice (to use sockaddr_storage{}) reasonable ? 835 It should be noted that the above ancillary data can only be handled 836 in UDP and raw sockets, not in TCP sockets. As explained in 837 [RFC3542], there is no one-to-one mapping of send/receive operations 838 and the TCP segments being transmitted/received. In case of TCP, 839 application may use setsockopt() or getsockopt() to access or specify 840 some of locator information provided by the shim layer. 842 7.1. Get Locator Information from Incoming Packet 844 Application can get locator information from the received IP packet 845 by specifying the shim specific socket options for the socket. When 846 SHIM_LOC_LOCAL_RECV and/or SHIM_LOC_PEER_RECV socket options are set, 847 the application can retrieve local and/or remote locator from the 848 ancillary data. 850 In addition, the application can get the receiving interface from the 851 ancillary data marked with SHIM_IF_RECV. The ancillary data should 852 contain an interface identifier of the physical interface which was 853 actually used to receive the packet. 855 7.2. Specify Locator Information for Outgoing Packet 857 Application can specify the locators to be used for transmitting an 858 IP packet by sendmsg(). When ancillary data of cmsg_type 859 SHIM_LOC_LOCAL_SEND and/or SHIM_LOC_PEER_SEND are specified, the 860 application can explicitly specify source and/or destination locators 861 to be used for the communication over the socket. 863 In addition, the application can specify the outgoing interface by 864 SHIM_IF_SEND ancillary data. The ancillary data should contain an 865 interface identifier of the physical interface over which the 866 application expect the packet to be transmitted. 868 Note that the effect is limited to the datagram transmitted by the 869 sendmsg(). If the specified locator pair seem to be valid, the shim 870 layer overrides the locator of the IP packet as requested. 872 An error EINVALIDLOCATOR will be returned when validation of the 873 specified locator failed. 875 ISSUE: Is there any other type of error that we should specifically 876 handle ? 878 8. Data Structures 880 Some of the socket options defined in this document requires specific 881 data structures for exchanging information. Those data structures 882 are illustrated in this section. 884 8.1. Placeholder for Locator Information 886 Some of the socket options defined in this document handle locator 887 information. Locator information could be a single locator or an 888 array of locators. An important requirement is that the locator 889 information should be handled in a protocol independent manner. In 890 other words, an interface to the locator information should not be 891 dependent to any address family. 893 8.1.1. addrinfo structure 895 addrinfo structure in along with getaddrinfo() function are defined 896 in Posix, which is useful for programming applications in protocol 897 independent manner. As mentioned earlier, protocol independency is 898 required for the locator management at the shim layer, thus we 899 propose to use addrinfo structure as a placeholder for locators. 901 A chain of addrinfo structures can be used to represent a list of 902 locators. Note that addrinfo structure itself does not contain the 903 locator data but it holds a pointer to sockaddr structure where the 904 actual data of a given locator is stored. Figure 4 illustrates the 905 addrinfo structure defined in . 907 struct addrinfo { 908 int ai_flags; /* input flags */ 909 int ai_family; /* protocol family for socket */ 910 int ai_socktype; /* socket type */ 911 int ai_protocol; /* protocol for socket */ 912 socklen_t ai_addrlen; /* length of socket-address */ 913 struct sockaddr *ai_addr; /* socket-address for socket */ 914 char *ai_canonname; /* canonical name for 915 service location */ 916 struct addrinfo *ai_next; /* pointer to next in list */ 917 }; 919 Figure 4: addrinfo structure 921 8.1.2. sockaddr_storage structure 923 [RFC3493] specifies a protocol independent placeholder for socket 924 address, called sockaddr_storage structure as shown in Figure 5. By 925 definition, the structure can store socket address of any protocol 926 (IPv4 or IPv6) and is simply suitable for a placeholder for the 927 locator information. In this document, we suggest to use 928 sockaddr_storage structure to store the locator information to be 929 specified in the ancillary data. In those cases, the locator 930 information is a single locator. 932 /* 933 * Desired design of maximum size and alignment 934 */ 935 #define _SS_MAXSIZE 128 /* Implementation specific max size */ 936 #define _SS_ALIGNSIZE (sizeof (int64_t)) 937 /* Implementation specific desired alignment */ 938 /* 939 * Definitions used for sockaddr_storage structure paddings design. 940 */ 941 #define _SS_PAD1SIZE (_SS_ALIGNSIZE - sizeof (sa_family_t)) 942 #define _SS_PAD2SIZE (_SS_MAXSIZE - (sizeof (sa_family_t) + 943 _SS_PAD1SIZE + _SS_ALIGNSIZE)) 945 struct sockaddr_storage { 946 sa_family_t ss_family; /* address family */ 947 /* Following fields are implementation specific */ 948 char __ss_pad1[_SS_PAD1SIZE]; 949 int64_t __ss_align; 950 char __ss_pad2[_SS_PAD2SIZE]; 951 }; 953 Figure 5: sockaddr_storage structure 955 9. Implications for Existing Socket API Extensions 957 As the socket options proposed in this document allow the application 958 to specify the locators for transmitting IP packet, there may be 959 conflict with some of the existing socket API. As stated in 960 Section 6, a basic assumption is that the legacy API should continue 961 to work above the shim layer. 963 In IPv4, application can obtain the destination IP address of the 964 received IP packet (IP_RECVDSTADDR) as well as the receiving 965 interface (IP_RECVIF). If the shim layer performs ID/Locator 966 adaptation for the received packet, the destination EID should be 967 stored in the ancillary data (IP_RECVDSTADDR). Accordingly, the 968 receiving interface should be aligned with the destination EID of the 969 packet. That is, the shim layer should set appropriate interface to 970 which the destination EID is assigned in the ancillary data object. 971 However, from the application perspective, knowing the receiving 972 interface which is associated with the destination EID may not be 973 useful, especially in the case where application is particularly 974 interested in the characteristics of the receiving interface. Hence, 975 we suggest application programmer to use SHIM_IF_RECV instead of 976 IP_RECVIF in such case. 978 In IPv6, [RFC3542] defines that IPV6_PKTINFO can be used to specify 979 source IPv6 address and the outgoing interface for outgoing packets, 980 and retrieve destination IPv6 address and receiving interface for 981 incoming packets. This information is stored in ancillary data being 982 IPV6_PKTINFO specified as cmsg_type. Now, similar to the case of 983 IPv4, the shim layer may affect the behavior of socket API which 984 deals with IPV6_PKFINFO. We again would like note that existing 985 socket API should continue to work above the shim layer, that is, the 986 IP addresses handled in IPV6_PKTINFO should be EIDs, not the 987 locators. Hence we recommend application programmers to use shim 988 specific socket options (SHIM_IF_RECV or SHIM_IF_SEND) if the 989 interest in the communicating interface comes from lower level (e.g. 990 characteristics of physical interface). For the same reason, in 991 order to handle locator information, we suggest to use shim specific 992 socket options defined in Section 7. 994 In summary, a care should be taken in potential conflict with 995 existing socket API which treats the IP address as a locator rather 996 than identifier. Basic assumption is that the existing socket API 997 works above the shim layer. 999 10. Discussion 1001 In this section, open discussion issues are noted. 1003 10.1. Issues with a Context Shared by Applications 1005 A context is by definition, system-wide. This means that a context 1006 could be shared by applications whose communications are using the 1007 same EID pair. 1009 When a context is shared by applications, there may be some problems 1010 when the shim layer needs to handle feedbacks from the multiple 1011 applications. As mentioned in Section X, an application may provide 1012 the shim layer feedback about timeout values from its own settings. 1013 This implies that there is potentially a race condition at the shim 1014 layer. 1016 First of all, the socket options must be used with a proper 1017 privilege. Feedback from the application which is run under a root 1018 privilege must always override the feedback provided by application 1019 which is run under normal user privilege. 1021 For other cases, one could rely on a kind of heuristics of the 1022 configuration. For instance, prioritizing feedback with higher 1023 demand (e.g. timeout value 300 seconds are more demanding then 1024 timeout value 600 seconds) may make sense in some cases. However, it 1025 is still an open issue what kind of timer value could be handled in 1026 this way. 1028 Further discussions are needed how the shim layer can accommodate 1029 feedbacks from multiple applications within a same context. 1031 10.2. Issues with Shim Unaware Application 1033 In multihomed environment where either or both of the peers have 1034 multiple locators, there are some issues with shim unaware 1035 application which uses legacy socket API. 1037 10.2.1. Initial Contact with Multiple Locator Pairs 1039 In a connection oriented communication, the connect() system call is 1040 used to make the initial contact to the peer, which typically 1041 requires IP address and port number to specify the endpoint. Hence, 1042 name-to-address resolution should be performed prior to connect(). 1043 The application needs to resolve the FQDN of the peer to an IP 1044 address by any available name-to-address conversion method. 1046 In typical case, the application receives information from the 1047 resolver. If the application ends up with receiving multiple IP 1048 addresses to reach the peer, it should iterate through each 1049 destination address one-by-one. It should be noted that the host may 1050 also have multiple source addresses. 1052 The different resulting address pairs may have different reachability 1053 status so, in order to find a working address pair, it may be 1054 required to explore all the available address pairs (as opposed to 1055 explore all available destination addresses). 1057 In normal case, the application issues a connect() by specifying the 1058 resolved IP address of the peer. If the connect() fails, it iterates 1059 through the available IP addresses one by one sequentially until 1060 working pair is found. Another approach is to initiate concurrent 1061 connect() with every locator of the peer. connect() can also be 1062 called in a sequence which would probably require more time to find 1063 the working pair. 1065 There is a case where involvement of the shim layer is expected for 1066 handling initial contact. In such case, behavior of the shim layer 1067 will depend on presence of the required context. This case occurs 1068 when there exists a context for the EID specified in connect(), the 1069 initial contact can be made in accordance with the context 1070 information. Otherwise, the shim layer should invoke context 1071 establishment with the peer EID specified in the argument for 1072 connect(). 1074 Additional efforts would be required in a case where the peer cannot 1075 be reachable through the EID (for example, EID is non-routable or 1076 non-IP reachable) but it can be reached through alternative locator. 1077 In particular, the shim layer should somehow discover the alternate 1078 locator for the EID to establish context. [I-D.nordmark-shim6-esd] 1079 addresses the possible approach to perform reverse DNS lookup from 1080 EID to FQDN, then perform forward lookup again to find the full-set 1081 of locators and EID. 1083 In HIP, resolving HITs to IP addresses using DNS is not feasible 1084 because HITs do not contain any hierarchical information. To 1085 mitigate this problem, there are a few alternatives. Firstly, 1086 resolver library on end-host can be modified to provide HIT-to-IP 1087 mappings for HIP software module. Secondly, a distributed hash table 1088 (DHT) service can be used for storing and looking up the mappings 1089 because it supports non-hierarchical identifiers, such as HITs 1090 [I-D.ietf-hip-arch]. Thirdly, it is possible to use IP addresses in 1091 legacy applications as described in [I-D.henderson-hip-applications]. 1093 10.2.2. Naming at Socket Layer 1095 getsockname() and getpeername() system calls are used to obtain the 1096 'name' of endpoint which is actually a pair of IP address and port 1097 number assigned to a given socket. getsockname() is used when an 1098 application wants to obtain the local IP address and port number 1099 assigned for a given socket instance. getpeername() is used when an 1100 application wants to obtain the remote IP address and port number. 1102 The above is based on a traditional system model of the socket API 1103 where an IP address is expected to play both the role of identifier 1104 and the role of locator. 1106 In a system model where a shim layer exists inside the IP layer, both 1107 getsockname() and getpeername() deal with identifiers, namely EIDs. 1108 In this sense, the shim layer serves to (1) hide locators and (2) 1109 provide access to the identifier for the application over the legacy 1110 socket APIs. 1112 10.3. Additional Requirements from Application 1114 At the moment, it is not certain if following requirements are common 1115 in all the multihomed environments (SHIM6 and HIP). These are mainly 1116 identified during discussions made on SHIM6 WG mailing list. 1117 o The application should be able to set preferences for the 1118 locators, local and remote one and also to the preferences of the 1119 local locators that will be passed to the peer. 1121 10.4. Issues of Header Conversion among Different Address Family 1123 The shim layer performs ID/Locator adaptation. Therefore, in some 1124 case, the whole IP header can be replaced with new IP header of a 1125 different address family (e.g. conversion from IPv4 to IPv6 or vice 1126 versa). Hence, there is an issue how to make the conversion with 1127 minimum impact. Note that this issue is common in other protocol 1128 conversion such as SIIT[RFC2765]. 1130 As addressed in SIIT specification, some of the features (IPv6 1131 routing headers, hop-by-hop extension headers, or destination 1132 headers) from IPv6 are not convertible to IPv4. In addition, notion 1133 of source routing is not exactly the same in IPv4 and IPv6. Hence, 1134 there is certain limitation in protocol conversion between IPv4 and 1135 IPv6. 1137 The question is how should the shim layer behave when it is face with 1138 limitation problem of protocol conversion. Should we introduce new 1139 error something like ENOSUITABLELOCATOR ? 1141 10.5. Handling of Unknown Locator Provided by Application 1143 There might be a case where application provides the shim layer new 1144 locator with the SHIM_LOC_*_PREF socket options or SHIM_LOC_*_SEND 1145 ancillary data. Then there is a question how should the shim layer 1146 treat the new locator informed by the application. 1148 In principle, locator information are exchanged by the shim protocol. 1149 However, there might be a case where application acquires information 1150 about the locator and prefers to use it for its communication. 1152 11. IANA Considerations 1154 This document contains no IANA consideration. 1156 12. Security Considerations 1158 This document does not specify any security mechanism for the shim 1159 layer. Fundamentally, the shim layer has a potential to impose 1160 security threats, as it changes the source and/or destination IP 1161 addresses of the IP packet being sent or received. Therefore, the 1162 basic assumption is that the security mechanism defined in each 1163 protocol of the shim layer is strictly applied. 1165 13. Conclusion 1167 In this document, the Application Program Interface (API) for 1168 multihomed shim layer is specified. The socket API allows 1169 applications to have additional control on the locator management and 1170 interface to the REAP mechanism inside the shim layer. The socket 1171 API is expected to be useful for the application that takes full 1172 advantage of multihomed environment. From architectural perspective, 1173 the socket API aims to enhance software development environment in 1174 terms of support for separation of identifier and locator. That is, 1175 with new API, application can handle identifier and locator 1176 separately still being allowed to use legacy socket API. 1178 Shim specific socket options can be used by getsockopt() and/or 1179 setcokopt() system calls, which allows applications to get 1180 information about locator management. Additionally, applications can 1181 specify locator information for outgoing packet and get locator 1182 information from incoming packet by using ancillary data. 1184 14. Acknowledgments 1186 Jari Arkko participated in the discussion that lead to the first 1187 version of this document. 1189 15. References 1191 15.1. Normative References 1193 [I-D.henderson-hip-applications] 1194 Henderson, T. and P. Nikander, "Using HIP with Legacy 1195 Applications", draft-henderson-hip-applications-03 (work 1196 in progress), May 2006. 1198 [I-D.ietf-hip-arch] 1199 Moskowitz, R. and P. Nikander, "Host Identity Protocol 1200 Architecture", draft-ietf-hip-arch-03 (work in progress), 1201 August 2005. 1203 [I-D.ietf-shim6-failure-detection] 1204 Arkko, J. and I. Beijnum, "Failure Detection and Locator 1205 Pair Exploration Protocol for IPv6 Multihoming", 1206 draft-ietf-shim6-failure-detection-03 (work in progress), 1207 December 2005. 1209 [I-D.ietf-shim6-proto] 1210 Bagnulo, M. and E. Nordmark, "Level 3 multihoming shim 1211 protocol", draft-ietf-shim6-proto-03 (work in progress), 1212 December 2005. 1214 [POSIX] "IEEE Std. 1003.1-2001 Standard for Information Technology 1215 -- Portable Operating System Interface (POSIX). Open group 1216 Technical Standard: Base Specifications, Issue 6, 1217 http://www.opengroup.org/austin", December 2001. 1219 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 1220 Stevens, "Basic Socket Interface Extensions for IPv6", 1221 RFC 3493, February 2003. 1223 [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, 1224 "Advanced Sockets Application Program Interface (API) for 1225 IPv6", RFC 3542, May 2003. 1227 15.2. Informative References 1229 [I-D.ietf-shim6-app-refer] 1230 Nordmark, E., "Shim6 Application Referral Issues", 1231 draft-ietf-shim6-app-refer-00 (work in progress), 1232 July 2005. 1234 [I-D.ietf-shim6-hba] 1235 Bagnulo, M., "Hash Based Addresses (HBA)", 1236 draft-ietf-shim6-hba-01 (work in progress), October 2005. 1238 [I-D.nordmark-shim6-esd] 1239 Nordmark, E., "Extended Shim6 Design for ID/loc split and 1240 Traffic Engineering", draft-nordmark-shim6-esd-00 (work in 1241 progress), February 2006. 1243 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 1244 (SIIT)", RFC 2765, February 2000. 1246 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1247 RFC 3972, March 2005. 1249 Authors' Addresses 1251 Miika Komu 1252 Helsinki Institue for Information Technology 1253 Tammasaarenkatu 3 1254 Helsinki 1255 Finland 1257 Phone: +358503841531 1258 Fax: +35896949768 1259 Email: miika@iki.fi 1260 URI: http://www.hiit.fi/ 1262 Marcelo Bagnulo 1263 Universidad Carlos III de Madrid 1264 Av. Universidad 30 1265 Leganes 28911 1266 SPAIN 1268 Phone: +34 91 6248837 1269 Email: marcelo@it.uc3m.es 1270 URI: http://it.uc3m.es/marcelo 1272 Kristian Slavov 1273 Ericsson Research Nomadiclab 1274 Hirsalantie 11 1275 Jorvas FI-02420 1276 Finland 1278 Phone: +358 9 299 3286 1279 Email: kristian.slavov@ericsson.com 1281 Shinta Sugimoto (editor) 1282 Nippon Ericsson K.K. 1283 Koraku Mori Building 1284 1-4-14, Koraku, Bunkyo-ku 1285 Tokyo 112-0004 1286 Japan 1288 Phone: +81 3 3830 2241 1289 Email: shinta.sugimoto@ericsson.com 1291 Intellectual Property Statement 1293 The IETF takes no position regarding the validity or scope of any 1294 Intellectual Property Rights or other rights that might be claimed to 1295 pertain to the implementation or use of the technology described in 1296 this document or the extent to which any license under such rights 1297 might or might not be available; nor does it represent that it has 1298 made any independent effort to identify any such rights. Information 1299 on the procedures with respect to rights in RFC documents can be 1300 found in BCP 78 and BCP 79. 1302 Copies of IPR disclosures made to the IETF Secretariat and any 1303 assurances of licenses to be made available, or the result of an 1304 attempt made to obtain a general license or permission for the use of 1305 such proprietary rights by implementers or users of this 1306 specification can be obtained from the IETF on-line IPR repository at 1307 http://www.ietf.org/ipr. 1309 The IETF invites any interested party to bring to its attention any 1310 copyrights, patents or patent applications, or other proprietary 1311 rights that may cover technology that may be required to implement 1312 this standard. Please address the information to the IETF at 1313 ietf-ipr@ietf.org. 1315 Disclaimer of Validity 1317 This document and the information contained herein are provided on an 1318 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1319 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1320 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1321 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1322 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1323 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1325 Copyright Statement 1327 Copyright (C) The Internet Society (2006). This document is subject 1328 to the rights, licenses and restrictions contained in BCP 78, and 1329 except as set forth therein, the authors retain all their rights. 1331 Acknowledgment 1333 Funding for the RFC Editor function is currently provided by the 1334 Internet Society.