draft-ietf-shim6-multihome-shim-api-02.txt   draft-ietf-shim6-multihome-shim-api-03.txt 
SHIM6 Working Group M. Komu SHIM6 Working Group M. Komu
Internet-Draft HIIT Internet-Draft HIIT
Intended status: Informational M. Bagnulo Intended status: Informational M. Bagnulo
Expires: September 6, 2007 UC3M Expires: January 10, 2008 UC3M
K. Slavov K. Slavov
S. Sugimoto, Ed. S. Sugimoto, Ed.
Ericsson Ericsson
March 5, 2007 July 9, 2007
Socket Application Program Interface (API) for Multihoming Shim 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 Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 38 skipping to change at page 1, line 38
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. 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 Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document specifies a socket API for the multihoming shim layer. This document specifies a socket API for the multihoming shim layer.
The API aims to enable interactions between the applications and the The API aims to enable interactions between the applications and the
multihoming shim layer for advanced locator management and access to multihoming shim layer for advanced locator management and access to
information about failure detection and path exploration. 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 equipped with a conceptual sublayer (here after "shim") inside the IP
layer that maintains mappings between identifiers and locators. layer that maintains mappings between identifiers and locators.
Examples of the shim are SHIM6 and HIP. Examples of the shim are SHIM6 and HIP.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. System Overview . . . . . . . . . . . . . . . . . . . . . . . 6 3. System Overview . . . . . . . . . . . . . . . . . . . . . . . 6
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7
skipping to change at page 2, line 51 skipping to change at page 2, line 51
9.1. Implicit Forking . . . . . . . . . . . . . . . . . . . . . 27 9.1. Implicit Forking . . . . . . . . . . . . . . . . . . . . . 27
10. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 27 10. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 27
10.1. Naming at Socket Layer . . . . . . . . . . . . . . . . . . 27 10.1. Naming at Socket Layer . . . . . . . . . . . . . . . . . . 27
10.2. Additional Requirements from Application . . . . . . . . . 28 10.2. Additional Requirements from Application . . . . . . . . . 28
10.3. Issues of Header Conversion among Different Address 10.3. Issues of Header Conversion among Different Address
Family . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Family . . . . . . . . . . . . . . . . . . . . . . . . . . 28
10.4. Handling of Unknown Locator Provided by Application . . . 28 10.4. Handling of Unknown Locator Provided by Application . . . 28
11. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 11. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
11.1. Changes from version 00 to version 01 . . . . . . . . . . 29 11.1. Changes from version 00 to version 01 . . . . . . . . . . 29
11.2. Changes from version 01 to version 02 . . . . . . . . . . 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 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
13. Security Considerations . . . . . . . . . . . . . . . . . . . 29 13. Security Considerations . . . . . . . . . . . . . . . . . . . 29
14. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 29 14. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 30
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
16.1. Normative References . . . . . . . . . . . . . . . . . . . 30 16.1. Normative References . . . . . . . . . . . . . . . . . . . 30
16.2. Informative References . . . . . . . . . . . . . . . . . . 31 16.2. Informative References . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 Appendix A. Context Forking . . . . . . . . . . . . . . . . . . . 31
Intellectual Property and Copyright Statements . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
Intellectual Property and Copyright Statements . . . . . . . . . . 35
1. Introduction 1. Introduction
HIP and SHIM6 have a commonality in their protocol design separation HIP and SHIM6 have a commonality in their protocol design separation
of identifier and locator (hereafter identifier/locator separation). of identifier and locator (hereafter identifier/locator separation).
Both protocols aim to solve problems that are specific to multihoming Both protocols aim to solve problems that are specific to multihoming
environment in a host centric approach. In these protocols, a sub- environment in a host centric approach. In these protocols, a sub-
layer within the IP layer maintains mappings of identifiers and layer within the IP layer maintains mappings of identifiers and
locators. locators.
The shim layer is useful in a sense that the IP layer can maintain The shim layer is useful in a sense that the IP layer can maintain
the mapping of an identifier to corresponding locators. Under a the mapping of an identifier to corresponding locators. Under a
multihomed environment, typically, a host has more than one IP multihomed environment, typically, a host has more than one IP
address at a time. During a given transaction, a host may be address at a time. During a given transaction, a host may be
required to switch the IP address used for the communication to required to switch the IP address used for the communication to
another IP address to preserve the communication. A care is needed another IP address to preserve the communication. The protocol stack
to not disrupt the upper layer protocols by the address update. The should take care of isolating the upper layer from distruption by the
shim layer can make this locator update transparent to the upper address update. The shim layer can make this locator update
layer protocols. transparent to the upper layer protocols.
In a system which is based on identifier/locator separation, upper In a system which is based on identifier/locator separation, upper
layer protocols are expected to deal with identifiers for layer protocols are expected to deal with identifiers for
establishing and handling the communications. If an application establishing and handling the communications. If an application
wants to have a multihoming support by the shim layer, the IP wants to have a multihoming support by the shim layer, the IP
addresses specified as source and destination addresses must be addresses specified as source and destination addresses must be
identifiers. However, this does not necessarily mean that identifiers. However, this does not necessarily mean that
applications are prohibited to choose specific locators in its applications are prohibited to choose specific locators in its
communication. It may be useful for applications, in some situation, communication. It may be useful for applications, in some situation,
to specify a preferred locator for the flow. to specify a preferred locator for the flow.
skipping to change at page 6, line 19 skipping to change at page 6, line 19
o Reachability Detection - A procedure to check reachability between o Reachability Detection - A procedure to check reachability between
a given locator pair. a given locator pair.
o Path - A sequence of routers that an IP packet goes through to o Path - A sequence of routers that an IP packet goes through to
reach the destination. reach the destination.
o Path Exploration - A procedure to explore available paths for a o Path Exploration - A procedure to explore available paths for a
given set of locator pairs. given set of locator pairs.
o Outage - An incident that prevents IP packets to flow from the o Outage - An incident that prevents IP packets to flow from the
source locator to the destination locator. When there is an source locator to the destination locator. When there is an
outage, it means that there is no reachability between a given outage, it means that there is no reachability between a given
locator pair. The outage can be caused by various reasons, such 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). (faulty operation).
o Working Address Pair - An address pair is said to be working if o Working Address Pair - An address pair is said to be working if
the packet containing the first address from the pair as source the packet containing the first address from the pair as source
address and the second address from the pair as destination address and the second address from the pair as destination
address can safely travel from the source to the destination. If address can safely travel from the source to the destination. If
the reachability is confirmed in both directions, the address the reachability is confirmed in both directions, the address
pairs is said to be bi-directional. Otherwise, it's pairs is said to be bi-directional. Otherwise, it's
unidirectional. unidirectional.
o Reachability Protocol (REAP) - A protocol for detecting failure o Reachability Protocol (REAP) - A protocol for detecting failure
and exploring reachability in a multihomed environment. REAP is and exploring reachability in a multihomed environment. REAP is
skipping to change at page 9, line 14 skipping to change at page 9, line 14
o The application should be able to know if the communication is now o The application should be able to know if the communication is now
served by the shim layer or not. served by the shim layer or not.
o The application should be able to access locator information o The application should be able to access locator information
regardless of its address family. In other words, no matter regardless of its address family. In other words, no matter
whether the target locator is IPv4 or IPv6, the application should whether the target locator is IPv4 or IPv6, the application should
be able to use common interface to access the locator information. be able to use common interface to access the locator information.
5. Socket Options for Multihoming Shim Layer 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. are defined.
Table 1 provides a list of the socket options that are specific to Table 1 provides a list of the socket options that are specific to
multihoming shim layer. These socket options can be used by either multihoming shim layer. These socket options can be used by either
getsockopt() or setsockopt() system call for a given socket. All of getsockopt() or setsockopt() system call for a given socket. All of
these socket options are defined at level SOL_SHIM. these socket options are defined at level SOL_SHIM.
The first column of Table 1 gives the name of the option. The second 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 and third columns indicate whether the option can be handled by
getsockopt() and/or setsockopt(), respectively. The fourth column getsockopt() and/or setsockopt(), respectively. The fourth column
skipping to change at page 22, line 47 skipping to change at page 22, line 47
as cmsg_level. as cmsg_level.
+------------------------+-----------+-----------+-------------+ +------------------------+-----------+-----------+-------------+
| cmsg_type | sendmsg() | recvmsg() | cmsg_data[] | | cmsg_type | sendmsg() | recvmsg() | cmsg_data[] |
+------------------------+-----------+-----------+-------------+ +------------------------+-----------+-----------+-------------+
| SHIM_LOC_LOCAL_RECV | | o | *1 | | SHIM_LOC_LOCAL_RECV | | o | *1 |
| SHIM_LOC_PEER_RECV | | o | *1 | | SHIM_LOC_PEER_RECV | | o | *1 |
| SHIM_LOC_LOCAL_SEND | o | | *1 | | SHIM_LOC_LOCAL_SEND | o | | *1 |
| SHIM_LOC_PEER_SEND | o | | *1 | | SHIM_LOC_PEER_SEND | o | | *1 |
| SHIM_FEEDBACK_POSITIVE | o | | TBD | | SHIM_FEEDBACK_POSITIVE | o | | TBD |
| SHIM_FEEDBACK_NEGATICE | o | | TBD | | SHIM_FEEDBACK_NEGATIVE | o | | TBD |
+------------------------+-----------+-----------+-------------+ +------------------------+-----------+-----------+-------------+
Table 2: Shim specific ancillary data Table 2: Shim specific ancillary data
*1: cmsg_data[] should include padding (if necessary) and a single *1: cmsg_data[] should include padding (if necessary) and a single
sockaddr_in{}/sockaddr_in6{}. sockaddr_in{}/sockaddr_in6{}.
It should be noted that the above ancillary data can only be handled 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- 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 to-one mapping of send/receive operations and the TCP segments being
skipping to change at page 29, line 32 skipping to change at page 29, line 32
11.2. Changes from version 01 to version 02 11.2. Changes from version 01 to version 02
The followings are changes from version 01 to version 02: The followings are changes from version 01 to version 02:
o Add section describing context forking. o Add section describing context forking.
o Rephrase conclusion section. o Rephrase conclusion section.
o Separate normative references from informative references. o Separate normative references from informative references.
o Remove texts from discussion section that are not relevant to the o Remove texts from discussion section that are not relevant to the
contents of the document. contents of the document.
o Add section describing change history (this section). 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 12. IANA Considerations
This document contains no IANA consideration. This document contains no IANA consideration.
13. Security Considerations 13. Security Considerations
This document does not specify any security mechanism for the shim This document does not specify any security mechanism for the shim
layer. Fundamentally, the shim layer has a potential to impose layer. Fundamentally, the shim layer has a potential to impose
security threats, as it changes the source and/or destination IP security threats, as it changes the source and/or destination IP
addresses of the IP packet being sent or received. Therefore, the addresses of the IP packet being sent or received. Therefore, the
skipping to change at page 30, line 8 skipping to change at page 30, line 13
protocol of the shim layer is strictly applied. protocol of the shim layer is strictly applied.
14. Conclusion 14. Conclusion
In this document, the Application Program Interface (API) for In this document, the Application Program Interface (API) for
multihoming shim layer is specified. The socket API allows multihoming shim layer is specified. The socket API allows
applications to have additional control of the locator management and applications to have additional control of the locator management and
interface to the REAP mechanism inside the multihoming shim layer. interface to the REAP mechanism inside the multihoming shim layer.
Socket options for multihoming shim layer can be used by getsockopt() 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 ancillary data that are specific to multihoming shim layer to get
locator from received packet or to set locator for outgoing packet. locator from received packet or to set locator for outgoing packet.
From an architectural point of view, the socket API provides extends From an architectural point of view, the socket API provides extends
the existing socket API framework in the face of ID/Locator the existing socket API framework in the face of ID/Locator
separation. With regard to API that relate to IP address management, separation. With regard to API that relate to IP address management,
it is assured that existing socket API continue to work above the it is assured that existing socket API continue to work above the
shim layer dealing with identifiers, while multihoming shim API deals shim layer dealing with identifiers, while multihoming shim API deals
with locators. with locators.
skipping to change at page 31, line 25 skipping to change at page 31, line 29
[I-D.ietf-shim6-hba] [I-D.ietf-shim6-hba]
Bagnulo, M., "Hash Based Addresses (HBA)", Bagnulo, M., "Hash Based Addresses (HBA)",
draft-ietf-shim6-hba-02 (work in progress), October 2006. draft-ietf-shim6-hba-02 (work in progress), October 2006.
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm
(SIIT)", RFC 2765, February 2000. (SIIT)", RFC 2765, February 2000.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005. 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:<A1,B1> ULID:<A1,B1> ULID:<B1,A1> ULID:<B1,A1>
Loc: <A1,B2> Loc: <A1,B3> Loc: <B2,A1> Loc: <B3,A1>
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 Authors' Addresses
Miika Komu Miika Komu
Helsinki Institue for Information Technology Helsinki Institute for Information Technology
Tammasaarenkatu 3 Tammasaarenkatu 3
Helsinki Helsinki
Finland Finland
Phone: +358503841531 Phone: +358503841531
Fax: +35896949768 Fax: +35896949768
Email: miika@iki.fi Email: miika@iki.fi
URI: http://www.hiit.fi/ URI: http://www.hiit.fi/
Marcelo Bagnulo Marcelo Bagnulo
Universidad Carlos III de Madrid Universidad Carlos III de Madrid
Av. Universidad 30 Av. Universidad 30
Leganes 28911 Leganes 28911
SPAIN SPAIN
Phone: +34 91 6248837 Phone: +34 91 6248837
Email: marcelo@it.uc3m.es Email: marcelo@it.uc3m.es
URI: http://it.uc3m.es/marcelo URI: http://it.uc3m.es/marcelo
Kristian Slavov Kristian Slavov
Ericsson Research Nomadiclab Ericsson Research Nomadiclab
Hirsalantie 11 Hirsalantie 11
Jorvas FI-02420 Jorvas FI-02420
Finland Finland
Phone: +358 9 299 3286 Phone: +358 9 299 3286
Email: kristian.slavov@ericsson.com Email: kristian.slavov@ericsson.com
Shinta Sugimoto (editor) Shinta Sugimoto (editor)
 End of changes. 18 change blocks. 
18 lines changed or deleted 122 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/