--- 1/draft-ietf-shim6-multihome-shim-api-02.txt 2007-07-11 21:12:15.000000000 +0200 +++ 2/draft-ietf-shim6-multihome-shim-api-03.txt 2007-07-11 21:12:15.000000000 +0200 @@ -1,22 +1,22 @@ SHIM6 Working Group M. Komu Internet-Draft HIIT Intended status: Informational M. Bagnulo -Expires: September 6, 2007 UC3M +Expires: January 10, 2008 UC3M K. Slavov S. Sugimoto, Ed. Ericsson - March 5, 2007 + July 9, 2007 Socket Application Program Interface (API) for Multihoming Shim - draft-ietf-shim6-multihome-shim-api-02 + draft-ietf-shim6-multihome-shim-api-03 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -27,34 +27,34 @@ 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 September 6, 2007. + This Internet-Draft will expire on January 10, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document specifies a socket API for the multihoming shim layer. The API aims to enable interactions between the applications and the multihoming shim layer for advanced locator management and access to information about failure detection and path exploration. - This document is based on an assumption that a multhomed host is + This document is based on an assumption that a multihomed host is equipped with a conceptual sublayer (here after "shim") inside the IP layer that maintains mappings between identifiers and locators. Examples of the shim are SHIM6 and HIP. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. System Overview . . . . . . . . . . . . . . . . . . . . . . . 6 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 @@ -86,48 +86,50 @@ 9.1. Implicit Forking . . . . . . . . . . . . . . . . . . . . . 27 10. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 27 10.1. Naming at Socket Layer . . . . . . . . . . . . . . . . . . 27 10.2. Additional Requirements from Application . . . . . . . . . 28 10.3. Issues of Header Conversion among Different Address Family . . . . . . . . . . . . . . . . . . . . . . . . . . 28 10.4. Handling of Unknown Locator Provided by Application . . . 28 11. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 11.1. Changes from version 00 to version 01 . . . . . . . . . . 29 11.2. Changes from version 01 to version 02 . . . . . . . . . . 29 + 11.3. Changes from version 02 to version 03 . . . . . . . . . . 29 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 13. Security Considerations . . . . . . . . . . . . . . . . . . . 29 - 14. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 29 + 14. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 30 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 16.1. Normative References . . . . . . . . . . . . . . . . . . . 30 16.2. Informative References . . . . . . . . . . . . . . . . . . 31 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 - Intellectual Property and Copyright Statements . . . . . . . . . . 33 + Appendix A. Context Forking . . . . . . . . . . . . . . . . . . . 31 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 + Intellectual Property and Copyright Statements . . . . . . . . . . 35 1. Introduction HIP and SHIM6 have a commonality in their protocol design separation of identifier and locator (hereafter identifier/locator separation). Both protocols aim to solve problems that are specific to multihoming environment in a host centric approach. In these protocols, a sub- layer within the IP layer maintains mappings of identifiers and locators. The shim layer is useful in a sense that the IP layer can maintain the mapping of an identifier to corresponding locators. Under a multihomed environment, typically, a host has more than one IP address at a time. During a given transaction, a host may be required to switch the IP address used for the communication to - another IP address to preserve the communication. A care is needed - to not disrupt the upper layer protocols by the address update. The - shim layer can make this locator update transparent to the upper - layer protocols. + another IP address to preserve the communication. The protocol stack + should take care of isolating the upper layer from distruption by the + address update. The shim layer can make this locator update + transparent to the upper layer protocols. In a system which is based on identifier/locator separation, upper layer protocols are expected to deal with identifiers for establishing and handling the communications. If an application wants to have a multihoming support by the shim layer, the IP addresses specified as source and destination addresses must be identifiers. However, this does not necessarily mean that applications are prohibited to choose specific locators in its communication. It may be useful for applications, in some situation, to specify a preferred locator for the flow. @@ -208,21 +210,21 @@ o Reachability Detection - A procedure to check reachability between a given locator pair. o Path - A sequence of routers that an IP packet goes through to reach the destination. o Path Exploration - A procedure to explore available paths for a given set of locator pairs. o Outage - An incident that prevents IP packets to flow from the source locator to the destination locator. When there is an outage, it means that there is no reachability between a given locator pair. The outage can be caused by various reasons, such - as shortage of network resources, congestions, and human error + as shortage of network resources, congestion, and human error (faulty operation). o Working Address Pair - An address pair is said to be working if the packet containing the first address from the pair as source address and the second address from the pair as destination address can safely travel from the source to the destination. If the reachability is confirmed in both directions, the address pairs is said to be bi-directional. Otherwise, it's unidirectional. o Reachability Protocol (REAP) - A protocol for detecting failure and exploring reachability in a multihomed environment. REAP is @@ -335,21 +337,21 @@ o The application should be able to know if the communication is now served by the shim layer or not. o The application should be able to access locator information regardless of its address family. In other words, no matter whether the target locator is IPv4 or IPv6, the application should be able to use common interface to access the locator information. 5. Socket Options for Multihoming Shim Layer - In this section, socket options that are specifc to multihome shim + In this section, socket options that are specific to multihomed shim are defined. Table 1 provides a list of the socket options that are specific to multihoming shim layer. These socket options can be used by either getsockopt() or setsockopt() system call for a given socket. All of these socket options are defined at level SOL_SHIM. The first column of Table 1 gives the name of the option. The second and third columns indicate whether the option can be handled by getsockopt() and/or setsockopt(), respectively. The fourth column @@ -970,21 +972,21 @@ as cmsg_level. +------------------------+-----------+-----------+-------------+ | cmsg_type | sendmsg() | recvmsg() | cmsg_data[] | +------------------------+-----------+-----------+-------------+ | SHIM_LOC_LOCAL_RECV | | o | *1 | | SHIM_LOC_PEER_RECV | | o | *1 | | SHIM_LOC_LOCAL_SEND | o | | *1 | | SHIM_LOC_PEER_SEND | o | | *1 | | SHIM_FEEDBACK_POSITIVE | o | | TBD | - | SHIM_FEEDBACK_NEGATICE | o | | TBD | + | SHIM_FEEDBACK_NEGATIVE | o | | TBD | +------------------------+-----------+-----------+-------------+ Table 2: Shim specific ancillary data *1: cmsg_data[] should include padding (if necessary) and a single sockaddr_in{}/sockaddr_in6{}. It should be noted that the above ancillary data can only be handled in UDP and raw sockets, not in TCP sockets because there is no one- to-one mapping of send/receive operations and the TCP segments being @@ -1288,20 +1290,25 @@ 11.2. Changes from version 01 to version 02 The followings are changes from version 01 to version 02: o Add section describing context forking. o Rephrase conclusion section. o Separate normative references from informative references. o Remove texts from discussion section that are not relevant to the contents of the document. o Add section describing change history (this section). +11.3. Changes from version 02 to version 03 + + The followings are changes from version 02 to version 03: + o Add an Appendix section describing the issue of context forking. + 12. IANA Considerations This document contains no IANA consideration. 13. Security Considerations This document does not specify any security mechanism for the shim layer. Fundamentally, the shim 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 @@ -1309,21 +1316,21 @@ protocol of the shim layer is strictly applied. 14. Conclusion In this document, the Application Program Interface (API) for multihoming shim layer is specified. The socket API allows applications to have additional control of the locator management and interface to the REAP mechanism inside the multihoming shim layer. Socket options for multihoming shim layer can be used by getsockopt() - and/or setcokopt() system calls. Besides, applications can use some + and/or setsockopt() system calls. Besides, applications can use some ancillary data that are specific to multihoming shim layer to get locator from received packet or to set locator for outgoing packet. From an architectural point of view, the socket API provides extends the existing socket API framework in the face of ID/Locator separation. With regard to API that relate to IP address management, it is assured that existing socket API continue to work above the shim layer dealing with identifiers, while multihoming shim API deals with locators. @@ -1371,42 +1378,139 @@ [I-D.ietf-shim6-hba] Bagnulo, M., "Hash Based Addresses (HBA)", draft-ietf-shim6-hba-02 (work in progress), October 2006. [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000. [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005. +Appendix A. Context Forking + + In this section, an issue concerning context forking and its relation + to the multihoming shim API are discussed. + + SHIM6 supports a notion of context forking. A peer may decide to + fork a context for certain reason (e.g. upper layer protocol prefers + to use different locator pair than the one defined in available + context). The procedure of forking context is done similar to the + normal context establishment, performing the 4-way message exchange. + A peer who has decided to fork a context initiates the context + establishment. Hereafter, we call this peer initiator. + + Once the forked context is established between the peers, on the + initiator side, it is possible to apply forked context to the packet + flow since the system maintains an association between the forked + context and the socket owned by the application that has requested + the context forking. How this association is maintained is + implementation specific issue. However, on the responder side, there + is a question on how the outbound packet can be multiplexed by the + shim layer. Since there are more than one SHIM6 contexts that match + with the ULID pair of the packet flow. There is a need to + differentiate packet flows not only by the ULID pairs but some other + information and associate a given packet flow with specific context. + + Figure 21 gives an example of a scenario where two communicating + peers fork a context. Initially, there has been a single transaction + between the peers, by the application 1 (App1). Accordingly, another + transaction is started, by application 2 (App2). Both of the + transactions are made based the same ULID pair. The first context + pair (Ctx1) is established for the transaction of App1. Given the + requests from App2, the shim layer on Peer 1 decides to fork a + context. Accordingly, a forked context (Ctx2) is established between + the peers, which should be exclusively applied to the transaction of + App2. Ideally, multiplexing and demultiplexing of packet flows that + relate to App1 and App2 should be done as illustrated in Figure 21. + However, as mentioned earlier, on the responder side, there is a + problem with multiplexing the outbound packet flows of App1 and App2. + + Peer 1 Peer 2 + (initiator) (responder) + + +----+ +----+ +----+ +----+ + |App1| |App2| |App1| |App2| + +----+ +----+ +----+ +----+ + |^ |^ ^| ^| + v| v| |v |v + -----S1-------------S2----- -----S1-------------S2----- + || || || || + || || || || + + Ctx1 Ctx2 Ctx1 Ctx2 + ULID: ULID: ULID: ULID: + Loc: Loc: Loc: Loc: + FII: 0 FII: 100 FII: 0 FII: 100 + + |^ |^ ^| ^| + || || || || + || || || || + \..............||........................../| || + \.............||.........................../ || + || || + \|........................................./| + \........................................../ + + Figure 21: context forking + + To overcome the problem mentioned above, there are some solutions. + + One viable approach is to let the system implicitly maintain an + association between the socket and the associated context by keeping + the record of inbound packet processing. That is, the system stores + the information about the context on which the inbound packet flow + was demultiplexed. The information comprises the ULID pair and FII + of the context and is stored in the socket instance. Later, the + system can use the information to identify the associated context in + outbound packet processing. This approach should be feasible as far + as there is bi-directional user traffic. + + Another viable approach is to extend SHIM6 protocol by adding + capability of exchanging additional information to identify the + packet flow from others which needs to be handled by a newly forked + context. The information exchange can be done during the context + establishment. The initiator appends 5 tuple of the packet flow to + be handled by the newly forked context. Note that the additional + information provided by the 5 tuple are source and destination port + numbers and upper layer protocol. The information is later used by + the shim layer to multiplex the outbound packet flow on the responder + side. + + The socket options for multihoming shim can be used by the + application to trigger the context forking in implicit manner. The + peer becomes an initiator in the establishment of the forked context. + Once the forked context is established between the peers, application + on each end can influence the preference on context by utilizing the + multihoming shim API. + Authors' Addresses Miika Komu - Helsinki Institue for Information Technology + Helsinki Institute for Information Technology Tammasaarenkatu 3 Helsinki Finland Phone: +358503841531 Fax: +35896949768 Email: miika@iki.fi URI: http://www.hiit.fi/ - Marcelo Bagnulo Universidad Carlos III de Madrid Av. Universidad 30 Leganes 28911 SPAIN Phone: +34 91 6248837 Email: marcelo@it.uc3m.es URI: http://it.uc3m.es/marcelo + Kristian Slavov Ericsson Research Nomadiclab Hirsalantie 11 Jorvas FI-02420 Finland Phone: +358 9 299 3286 Email: kristian.slavov@ericsson.com Shinta Sugimoto (editor)