--- 1/draft-ietf-shim6-multihome-shim-api-10.txt 2009-12-07 12:12:34.000000000 +0100 +++ 2/draft-ietf-shim6-multihome-shim-api-11.txt 2009-12-07 12:12:34.000000000 +0100 @@ -1,22 +1,22 @@ SHIM6 Working Group M. Komu Internet-Draft HIIT Intended status: Informational M. Bagnulo -Expires: April 29, 2010 UC3M +Expires: June 10, 2010 UC3M K. Slavov S. Sugimoto, Ed. Ericsson - October 26, 2009 + December 7, 2009 Socket Application Program Interface (API) for Multihoming Shim - draft-ietf-shim6-multihome-shim-api-10 + draft-ietf-shim6-multihome-shim-api-11 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. @@ -25,21 +25,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on April 29, 2010. + This Internet-Draft will expire on June 10, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights @@ -78,56 +78,59 @@ 5.12. SHIM_LOCLIST_PEER . . . . . . . . . . . . . . . . . . . . 23 5.13. SHIM_APP_TIMEOUT . . . . . . . . . . . . . . . . . . . . 23 5.14. SHIM_DEFERRED_CONTEXT_SETUP . . . . . . . . . . . . . . . 24 5.15. Applicability . . . . . . . . . . . . . . . . . . . . . . 25 5.16. Error Handling . . . . . . . . . . . . . . . . . . . . . 25 6. Ancillary Data for Multihoming Shim Sub-layer . . . . . . . . 26 6.1. Get Locator from Incoming Packet . . . . . . . . . . . . 27 6.2. Set Locator for Outgoing Packet . . . . . . . . . . . . . 27 6.3. Notification from Application to Multihoming Shim Sub-layer . . . . . . . . . . . . . . . . . . . . . . . . 27 - 6.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 28 - 7. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 28 - 7.1. Placeholder for Locator Information . . . . . . . . . . . 28 - 7.1.1. Handling Locator behind NAT . . . . . . . . . . . . . 29 - 7.2. Path Exploration Parameter . . . . . . . . . . . . . . . 30 - 7.3. Feedback Information . . . . . . . . . . . . . . . . . . 31 - 8. System Requirements . . . . . . . . . . . . . . . . . . . . . 32 - 9. Implications for Existing Socket API Extensions . . . . . . . 32 - 10. Resolving Conflicts with Preference Values . . . . . . . . . . 33 - 10.1. Implicit Forking . . . . . . . . . . . . . . . . . . . . 33 - 11. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 34 - 11.1. Naming at Socket Layer . . . . . . . . . . . . . . . . . 34 - 11.2. Additional Requirements from Applications . . . . . . . . 34 + 6.4. Notification from Multihoming Shim Sub-layer to + Application . . . . . . . . . . . . . . . . . . . . . . . 28 + 6.5. Applicability . . . . . . . . . . . . . . . . . . . . . . 29 + 7. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 29 + 7.1. Placeholder for Locator Information . . . . . . . . . . . 29 + 7.1.1. Handling Locator behind NAT . . . . . . . . . . . . . 30 + 7.2. Path Exploration Parameter . . . . . . . . . . . . . . . 31 + 7.3. Feedback Information . . . . . . . . . . . . . . . . . . 32 + 8. System Requirements . . . . . . . . . . . . . . . . . . . . . 33 + 9. Implications for Existing Socket API Extensions . . . . . . . 33 + 10. Resolving Conflicts with Preference Values . . . . . . . . . . 34 + 10.1. Implicit Forking . . . . . . . . . . . . . . . . . . . . 34 + 11. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 35 + 11.1. Naming at Socket Layer . . . . . . . . . . . . . . . . . 35 + 11.2. Additional Requirements from Applications . . . . . . . . 35 11.3. Issues of Header Conversion among Different Address - Family . . . . . . . . . . . . . . . . . . . . . . . . . 34 - 11.4. Handling of Unknown Locator Provided by Application . . . 35 - 12. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 - 12.1. Changes from version 00 to version 01 . . . . . . . . . . 35 - 12.2. Changes from version 01 to version 02 . . . . . . . . . . 35 - 12.3. Changes from version 02 to version 03 . . . . . . . . . . 36 - 12.4. Changes from version 03 to version 04 . . . . . . . . . . 36 - 12.5. Changes from version 04 to version 05 . . . . . . . . . . 36 - 12.6. Changes from version 05 to version 06 . . . . . . . . . . 36 - 12.7. Changes from version 06 to version 07 . . . . . . . . . . 36 - 12.8. Changes from version 07 to version 08 . . . . . . . . . . 36 - 12.9. Changes from version 08 to version 09 . . . . . . . . . . 36 - 12.10. Changes from version 09 to version 10 . . . . . . . . . . 36 - 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 - 14. Security Considerations . . . . . . . . . . . . . . . . . . . 37 - 15. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 37 - 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 - 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 - 17.1. Normative References . . . . . . . . . . . . . . . . . . 38 - 17.2. Informative References . . . . . . . . . . . . . . . . . 38 - Appendix A. Context Forking . . . . . . . . . . . . . . . . . . . 39 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 + Family . . . . . . . . . . . . . . . . . . . . . . . . . 36 + 11.4. Handling of Unknown Locator Provided by Application . . . 36 + 12. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 + 12.1. Changes from version 00 to version 01 . . . . . . . . . . 36 + 12.2. Changes from version 01 to version 02 . . . . . . . . . . 37 + 12.3. Changes from version 02 to version 03 . . . . . . . . . . 37 + 12.4. Changes from version 03 to version 04 . . . . . . . . . . 37 + 12.5. Changes from version 04 to version 05 . . . . . . . . . . 37 + 12.6. Changes from version 05 to version 06 . . . . . . . . . . 37 + 12.7. Changes from version 06 to version 07 . . . . . . . . . . 37 + 12.8. Changes from version 07 to version 08 . . . . . . . . . . 37 + 12.9. Changes from version 08 to version 09 . . . . . . . . . . 38 + 12.10. Changes from version 09 to version 10 . . . . . . . . . . 38 + 12.11. Changes from version 10 to version 11 . . . . . . . . . . 38 + 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 + 14. Security Considerations . . . . . . . . . . . . . . . . . . . 38 + 15. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 38 + 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39 + 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 + 17.1. Normative References . . . . . . . . . . . . . . . . . . 39 + 17.2. Informative References . . . . . . . . . . . . . . . . . 40 + Appendix A. Context Forking . . . . . . . . . . . . . . . . . . . 40 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 1. Introduction HIP and SHIM6 have a commonality in their protocol design in the sense that the semantic roles of an IP address, i.e., an identifier and a locator, are distinguished. Separation of identifier and locator is done by introducing a "shim" inside the IP layer which maintains mapping of the identifier and associated locators. This design principle is called "identifier/locator separation" and the shim is referred to as a "shim sub-layer" in this document. @@ -160,20 +163,29 @@ As this document specifies sockets API extensions, it is written so that the syntax and semantics are in line with the Posix standard [POSIX] as much as possible. The API specified in this document defines how to use ancillary data (aka cmsg) to access the locator information with recvmsg() and/or sendmsg() I/O calls. The definition of API is presented in C language and data types follow the Posix format; intN_t means a singed integer of exactly N bits (e.g. int16_t) and uintN_t means an unsigned integer of exactly N bits (e.g. uint32_t). + The distinction between "connected" sockets and "unconnected" sockets + is important when discussing the applicability of the socket API + defined in this document. A connected socket is bound to a given + peer, whereas an unconnected socket is not bound to any specific + peers. That is, the destination of the user data is not known until + the application writes data to an unconnected socket. TCP sockets + are connected, by definition. UDP sockets are unconnected, unless + the application uses the connect() system call. + The target readers of this document are application programmers who develop application software which may benefit greatly from multihomed environments. In addition, this document aims to provide necessary information for developers of multihoming shim protocols to implement API for enabling advanced locator management. 2. Terminology This section provides terminology used in this document. Basically most of the terms used in this document are taken from the following @@ -539,28 +551,31 @@ The SHIM_ASSOCIATED option is used to check whether the socket is associated with any shim context or not. This option is meaningful when the locator information of the received IP packet does not tell whether the identifier/locator adaptation is performed or not. Note that the EID pair and the locator pair may be identical in some cases. This option can be specified by getsockopt(). Thus, the option is - read-only and the result (0 or 1) is set in the option value (the + read-only and the result (0/1/2) is set in the option value (the fourth argument of getsockopt()). The data type of the option value is an integer. The option value - indicates the presence of shim context. A returned value 1 means - that the socket is associated with a shim context at the shim sub- - layer. A return value 0 indicates that there is no shim context - associated with the socket. + indicates the presence of shim context. A return value 1 means that + the socket is associated with a shim context at the shim sub-layer. + A return value 0 indicates that there is no shim context associated + with the socket. A return value 2 means that it is not known whether + the socket is associated with a shim context or not, and this must be + returned only when the socket is unconnected. In other words, the + returned value must be 0 or 1 when the socket is connected. For example, the option can be used by the application as follows: int optval; int optlen = sizeof(optval); getsockopt(fd, SOL_SHIM, SHIM_ASSOCIATED, &optval, &optlen); 5.2. SHIM_DONTSHIM @@ -1062,20 +1076,28 @@ communication. Note that SHIM6 supports deferred context setup and HIP does not because EIDs in HIP (i.e., Host Identifiers) are non- routable. The data type for the option value is an integer. The option value should be binary (0 or 1). By default, the value is set to 1, meaning that the context setup is deferred. In order to disable the option, the application should call setsockopt() with option value set to 0. + Note that HIP does not support deferred context setup, by default. + When the application requests to enable deferred context setup in + case of HIP, it may mean that the application allows the system to + start TCP handshake even when there is no IPsec security association + with the peer. Such a usage of the SHIM_DEFERRED_CONTEXT_SETUP + option should be considered as experimental and left for further + study. + For example, an application can disable the deferred context setup by using the socket option as follows: int optval; optval = 0; setsockopt(fd, SOL_SHIM, SHIM_DEFERRED_CONTEXT_SETUP, &optval, sizeof(optval)); @@ -1084,31 +1106,29 @@ int optval; int len; len = sizeof(optval); getsockopt(fd, SOL_SHIM, SHIM_DEFERRED_CONTEXT_SETUP, &optval, &len); 5.15. Applicability - All the socket options for the multihoming shim sub-layer are - applicable only to connected sockets. The reason behind this - restriction is that it is necessary for the multihoming shim layer to - identify a target multihoming shim context when an application gives - preference value(s) by a socket option for the multihoming shim sub- - layer. Multihoming shim contexts are, by definition, identified by a - pair of EIDs. Therefore, it is possible for the multihoming shim - sub-layer to identify the target context only when the source and - destination IP addresses of the application session are known. When - any socket options for the multihoming shim sub-layer is set for an - unconnected socket, EINVAL error code MUST be returned. + All the socket options for the multihoming shim sub-layer except for + SHIM_HOT_STANDBY are applicable for both connected and unconnected + sockets. + + The reason SHIM_HOT_STANDBY socket option cannot be used for an + unconnected socket is that the multihoming shim sub-layer cannot + initiate context establishment to create a hot standby connection + because the peer's IP address is not known until the application + writes data to the unconnected socket. 5.16. Error Handling If successful, getsockopt() and setsockopt() return 0; otherwise, the functions return -1 and set errno to indicate an error. The following are new error values defined for some shim specific socket options indicating that the getsockopt() or setsockopt() finished incompletely: @@ -1214,33 +1234,63 @@ specifying SHIM_FEEDBACK option in cmsg_type. An error ENOENT will be returned when there is no context associated with the socket. See Section 7.3 for details of the data structure to be used. It is outside the scope of this document how the shim sub-layer would react when a feedback is provided by an application. -6.4. Applicability +6.4. Notification from Multihoming Shim Sub-layer to Application - It is important to note that the ancillary data specified in this - section are applicable only to datagram-oriented sockets (e.g., UDP - sockets or raw sockets) and that they are not applicable to stream- - oriented sockets (e.g., TCP sockets). The reason behind this - restriction is that there is no one-to-one mapping between a single - send or receive operation and a TCP segment being transmitted or - received. + The multihoming shim sub-layer MAY provide notification about a + locator change within a multihome shim context to applications that + have concern with the context. Such a notification is useful, for + example, for an application which is sensitive to path + characteristics. A locator change is caused when either of local or + peer's locator (or both) is changed. Note that locators discussed + here are the ones that appear in the IP packet header, and not the + ones that are included in the locator list. A locator change may + take place asynchronously. - Due to the above restriction and the restriction addressed in - Section 5.15, SHIM_LOC_LOCAL_RECV or SHIM_LOC_PEER_RECV socket - options are, in practice, applicable only to connected UDP sockets. + The notification is handled as an out-of-band data by the + application. + 1. Application calls the select() system call by setting non-NULL + value for the fourth argument. + 2. When there is a notification, the application reads out-of-band + data from the socket by calling the recvmsg() system call. + 3. The application checks the flag in the msghdr (msg_flags) to see + if there is any notification about locator change delivered. If + the MSG_SHIM_LOCATOR_CHANGE flag is set, application parse the + chain of control message to read a pair of ancillary data objects + which contains the source locator and the destination locator. + Note that the direction of locator change is distinguished by the + cmsg_type; SHIM_LOC_*_RECV is used for inbound locator change, + and SHIM_LOC_*_SEND is used for outbound locator change. + + There is no restriction in terms of applicability of the notification + about locator change. The notification can be delivered to sockets + regardless of if it is connected or unconnected, stream-oriented or + datagram-oriented. + +6.5. Applicability + + A care is needed when the SHIM_LOC_*_RECV socket option is used for + stream-oriented sockets (e.g., TCP sockets) because there is no one- + to-one mapping between a single send or receive operation and the + data (e.g., a TCP segment) being received. In other words, there is + no gurantee that the locator(s) set in the SHIM_LOC_*_RECV ancillary + data is identical to the locator(s) that appear in the IP packets + received. The multihoming shim sub-layer SHOULD provide the latest + locator information to the application in response to the + SHIM_LOC_*_RECV socket option. 7. Data Structures In this section, data structures specifically defined for the multihoming shim sub-layer are introduced. These data structures are either used as a parameter for setsockopt()/getsockopt() (as mentioned in Section 5) or as a parameter for ancillary data to be processed by sendmsg()/recvmsg() (as mentioned in Section 6). 7.1. Placeholder for Locator Information @@ -1389,46 +1440,62 @@ direction Indicates direction of reachability between a locator pair in question. A value 0 indicates outbound and a value 1 indicates inbound direction. indicator A value indicating the degree of satisfaction of a unidirectional reachability for a given locator pair. * 0: Default value. Whenever this value is specified the feedback information must not be processed by the shim sub- layer. - * 1: Unable to connect. There is no unidirectional reachability between the locator pair in question. * 2: Unsatisfactory. The application is not satisfied with the unidirectional reachability between the locator pair in question. + * 3: Satisfactory. There is satisfactory unidirectional reachability between the locator pair in question. reserved Reserved field. Must be ignored by the receiver. 8. System Requirements As discussed in Section 5, all the socket options for multihoming - shim sub-layer are applicable only to connected sockets. To break - this down into system requirements, the operating system (kernel) - should be able to establish and maintain an association between a - socket instance and one or more multihoming shim context. It is, - however, outside the scope of this document how the operating system - would establish and maintain associations between sockets and - multihoming shim contexts. An association can be established on - creation of a multihoming shim context, or at any stage. On creation - of a shim context, the multihoming shim sub-layer on the initiator - side should be aware of the triggering packet and it should be - possible to figure out the originating socket. It is more difficult - to establish an association on the responder side. + shim sub-layer except for the SHIM_HOT_STANDBY socket option are + applicable to both connected and unconnected sockets. The + implications of this design choice on system requirements should be + noted. + + There are less system requirements to enable support for applications + that use connected sockets. This is because the kernel can easily + maintain association between a connected socket and a multihoming + shim context. Note that the multihoming shim contexts are identified + by an EID pair. In contrast, there are more system requirements to + enable support for applications that use unconnected sockets. The + kernel needs to dynamically resolve association between an + unconnected socket and a multihoming shim context, if any, upon + packet processing. As to outbound packet processing, the kernel + needs to check if there is any multihoming shim context whose EID + pair matches with the source and destination IP addresses of the user + data originating from an unconnected socket. If a matching context + is found, the multihoming shim sub-layer performs packet processing + taking the application's preference into account. Note that the + multihoming shim sub-layer should be able to backtrack the socket + from which the user data was originated. As to inbound packet + processing, the multihoming shim sub-layer needs to check not only + the IP header but also the transport layer protocol header to resolve + the destination socket. If the destination socket is resolved and it + contains any values concerning the multihoming shim sub-layer socket + options, the multihoming shim sub-layer processes the IP packet as + requested (e.g., set locator information of received packet in the + ancillary data). 9. Implications for Existing Socket API Extensions Some of the socket options defined in this document are overlapping with existing sockets API and care should be taken for the usage not to confuse with the overlapping features. The socket options for requesting specific locators to be used for a given transaction (SHIM_LOC_LOCAL_PREF and SHIM_LOC_PEER_PREF) are semantically similar to the existing sockets API (IPV6_PKTINFO). The @@ -1621,27 +1690,35 @@ comments provided by Samu Varjonen. o Made it clear that downgrading the multihoming shim support (i.e., specifying value 1 with the SHIM_DONTSHIM socket option) is only allowed before the socket is connected. o Updated locator information (shim_locator{}) so that it can contain a locator behind NAT. 12.10. Changes from version 09 to version 10 The followings are changes from version 09 to version 10: - o Addressed applicability of socket options and ancillary data for the multihoming shim sub-layer. o Addressed system requirements. o Removed unnecessary description about deprecated socket option (SHIM_IF_RECV). +12.11. Changes from version 10 to version 11 + + The followings are changes from version 10 to version 11: + o Added short descriptions about connected sockets and unconnected + sockets. + o Relax applicability of the socket options. + o Relax applicability of the ancillary data. + o Added notification about locator change. + 13. IANA Considerations This document contains no IANA consideration. 14. Security Considerations This document does not specify any security mechanism for the shim sub-layer. Fundamentally, the shim sub-layer has a potential to impose security threats, as it changes the source and/or destination IP addresses of the IP packet being sent or received. Therefore, the @@ -1860,11 +1937,11 @@ Phone: +358 9 299 3286 Email: kristian.slavov@ericsson.com Shinta Sugimoto (editor) Nippon Ericsson K.K. Koraku Mori Building 1-4-14, Koraku, Bunkyo-ku Tokyo 112-0004 Japan Phone: +81 3 3830 2241 - Email: shinta@sfc.wide.ad.jp + Email: shinta.sugimoto@ericsson.com