draft-ietf-shim6-multihome-shim-api-11.txt   draft-ietf-shim6-multihome-shim-api-12.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: June 10, 2010 UC3M Expires: July 13, 2010 UC3M
K. Slavov K. Slavov
S. Sugimoto, Ed. S. Sugimoto, Ed.
Ericsson Ericsson
December 7, 2009 January 9, 2010
Socket Application Program Interface (API) for Multihoming Shim Socket Application Program Interface (API) for Multihoming Shim
draft-ietf-shim6-multihome-shim-api-11 draft-ietf-shim6-multihome-shim-api-12
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 June 10, 2010. This Internet-Draft will expire on July 13, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract Abstract
skipping to change at page 2, line 47 skipping to change at page 2, line 47
5.14. SHIM_DEFERRED_CONTEXT_SETUP . . . . . . . . . . . . . . . 24 5.14. SHIM_DEFERRED_CONTEXT_SETUP . . . . . . . . . . . . . . . 24
5.15. Applicability . . . . . . . . . . . . . . . . . . . . . . 25 5.15. Applicability . . . . . . . . . . . . . . . . . . . . . . 25
5.16. Error Handling . . . . . . . . . . . . . . . . . . . . . 25 5.16. Error Handling . . . . . . . . . . . . . . . . . . . . . 25
6. Ancillary Data for Multihoming Shim Sub-layer . . . . . . . . 26 6. Ancillary Data for Multihoming Shim Sub-layer . . . . . . . . 26
6.1. Get Locator from Incoming Packet . . . . . . . . . . . . 27 6.1. Get Locator from Incoming Packet . . . . . . . . . . . . 27
6.2. Set Locator for Outgoing Packet . . . . . . . . . . . . . 27 6.2. Set Locator for Outgoing Packet . . . . . . . . . . . . . 27
6.3. Notification from Application to Multihoming Shim 6.3. Notification from Application to Multihoming Shim
Sub-layer . . . . . . . . . . . . . . . . . . . . . . . . 27 Sub-layer . . . . . . . . . . . . . . . . . . . . . . . . 27
6.4. Notification from Multihoming Shim Sub-layer to 6.4. Notification from Multihoming Shim Sub-layer to
Application . . . . . . . . . . . . . . . . . . . . . . . 28 Application . . . . . . . . . . . . . . . . . . . . . . . 28
6.5. Applicability . . . . . . . . . . . . . . . . . . . . . . 29 6.5. Applicability . . . . . . . . . . . . . . . . . . . . . . 28
7. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 29 7. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 29
7.1. Placeholder for Locator Information . . . . . . . . . . . 29 7.1. Placeholder for Locator Information . . . . . . . . . . . 29
7.1.1. Handling Locator behind NAT . . . . . . . . . . . . . 30 7.1.1. Handling Locator behind NAT . . . . . . . . . . . . . 30
7.2. Path Exploration Parameter . . . . . . . . . . . . . . . 31 7.2. Path Exploration Parameter . . . . . . . . . . . . . . . 31
7.3. Feedback Information . . . . . . . . . . . . . . . . . . 32 7.3. Feedback Information . . . . . . . . . . . . . . . . . . 32
8. System Requirements . . . . . . . . . . . . . . . . . . . . . 33 8. System Requirements . . . . . . . . . . . . . . . . . . . . . 33
9. Implications for Existing Socket API Extensions . . . . . . . 33 9. Relation to Existing Sockets API Extensions . . . . . . . . . 33
10. Resolving Conflicts with Preference Values . . . . . . . . . . 34 10. Operational Considerations . . . . . . . . . . . . . . . . . . 34
10.1. Implicit Forking . . . . . . . . . . . . . . . . . . . . 34 10.1. Conflict Resolution . . . . . . . . . . . . . . . . . . . 34
11. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 35 10.2. Incompatiblility between IPv4 and IPv6 . . . . . . . . . 35
11.1. Naming at Socket Layer . . . . . . . . . . . . . . . . . 35 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
11.2. Additional Requirements from Applications . . . . . . . . 35 12. Protocol Constants and Variables . . . . . . . . . . . . . . . 35
11.3. Issues of Header Conversion among Different Address 13. Security Considerations . . . . . . . . . . . . . . . . . . . 35
Family . . . . . . . . . . . . . . . . . . . . . . . . . 36 13.1. Treatment of Unknown Locator . . . . . . . . . . . . . . 35
11.4. Handling of Unknown Locator Provided by Application . . . 36 13.1.1. Treatment of Unknown Source Locator . . . . . . . . . 35
12. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 13.1.2. Treatment of Unknown Destination Locator . . . . . . . 36
12.1. Changes from version 00 to version 01 . . . . . . . . . . 36 14. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
12.2. Changes from version 01 to version 02 . . . . . . . . . . 37 14.1. Changes from version 00 to version 01 . . . . . . . . . . 36
12.3. Changes from version 02 to version 03 . . . . . . . . . . 37 14.2. Changes from version 01 to version 02 . . . . . . . . . . 36
12.4. Changes from version 03 to version 04 . . . . . . . . . . 37 14.3. Changes from version 02 to version 03 . . . . . . . . . . 37
12.5. Changes from version 04 to version 05 . . . . . . . . . . 37 14.4. Changes from version 03 to version 04 . . . . . . . . . . 37
12.6. Changes from version 05 to version 06 . . . . . . . . . . 37 14.5. Changes from version 04 to version 05 . . . . . . . . . . 37
12.7. Changes from version 06 to version 07 . . . . . . . . . . 37 14.6. Changes from version 05 to version 06 . . . . . . . . . . 37
12.8. Changes from version 07 to version 08 . . . . . . . . . . 37 14.7. Changes from version 06 to version 07 . . . . . . . . . . 37
12.9. Changes from version 08 to version 09 . . . . . . . . . . 38 14.8. Changes from version 07 to version 08 . . . . . . . . . . 37
12.10. Changes from version 09 to version 10 . . . . . . . . . . 38 14.9. Changes from version 08 to version 09 . . . . . . . . . . 37
12.11. Changes from version 10 to version 11 . . . . . . . . . . 38 14.10. Changes from version 09 to version 10 . . . . . . . . . . 37
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 14.11. Changes from version 10 to version 11 . . . . . . . . . . 38
14. Security Considerations . . . . . . . . . . . . . . . . . . . 38 14.12. Changes from version 11 to version 12 . . . . . . . . . . 38
15. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 38 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 16.1. Normative References . . . . . . . . . . . . . . . . . . 38
17.1. Normative References . . . . . . . . . . . . . . . . . . 39 16.2. Informative References . . . . . . . . . . . . . . . . . 39
17.2. Informative References . . . . . . . . . . . . . . . . . 40 Appendix A. Context Forking . . . . . . . . . . . . . . . . . . . 39
Appendix A. Context Forking . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43
1. Introduction 1. Introduction
HIP and SHIM6 have a commonality in their protocol design in the This document defines socket API extensions by which upper layer
sense that the semantic roles of an IP address, i.e., an identifier protocols may be informed about and control the way in which a
and a locator, are distinguished. Separation of identifier and multihoming shim sub-layer in the IP layer manages the dynamic choice
locator is done by introducing a "shim" inside the IP layer which of locators. Initially it applies to SHIM6 and HIP, but it is
maintains mapping of the identifier and associated locators. This defined generically.
design principle is called "identifier/locator separation" and the
shim is referred to as a "shim sub-layer" in this document.
The shim sub-layer provides a nice property to present a stable
communication endpoints (i.e., identifiers) to the upper layer
protocols. An on-going session can be maintained even when the
locator associated with the identifier is changed, for instance, upon
a re-homing event under a multihomed environment. Therefore, upper
layer protocols, especially connection-oriented applications are no
more annoyed by the locator change thanks to the identifier/locator
separation mechanism.
While the identifier/locator separation removes negative impact of The role of the multihoming shim sub-layer (hereafter called "shim
locator change, it does not necessarily mean that applications are sub-layer" in this document) is to avoid impacts to upper layer
always ignorant about locators. We rather think that applications protocols which may be caused when the endhost changes its attachment
may want to have a control of locators in some cases. For instance, point to the Internet, for instance, in the case of rehoming event
an application may want to use a specific locator to send IP packets. under the multihomed environment. The key design of the shim sub-
Such a control of locators is referred to as "locator management" in layer is to treat identifier and locator separately. Identifiers are
this document. Besides, applications may want to turn on or off the presented to upper layer protocols and used as communication
identifier/locator separation mechanism. This document defines API endpoints. Locators represent toplogical location of endhosts and
that provides locator management and additional control of shim sub- are used to route packet from the source to the destiantion. The
layer for applications. shim sub-layer maintains mapping of identifiers and locators.
This document recommends that the switching of identifier and locator Note that the shim sub-layer may conflict with other multihoming
is done only once inside the TCP/IP stack of an endhost. That is, if mechanisms such as SCTP and multipath
multiple shim sub-layers exist at the IP layer, any one of them TCP[I-D.ietf-shim6-applicability]. To avoid any conflict, only one
should be applied exclusively for a given flow. of SHIM6 and HIP should be in use.
As this document specifies sockets API extensions, it is written so In this document, syntax and semantics of the API are given in the
that the syntax and semantics are in line with the Posix standard same way as the Posix standard [POSIX]. The API specifies how to use
[POSIX] as much as possible. The API specified in this document ancillary data (aka cmsg) to access the locator information with
defines how to use ancillary data (aka cmsg) to access the locator recvmsg() and/or sendmsg() I/O calls. The API is described in C
information with recvmsg() and/or sendmsg() I/O calls. The language and data types are defined in the Posix format; intN_t means
definition of API is presented in C language and data types follow a singed integer of exactly N bits (e.g. int16_t) and uintN_t means
the Posix format; intN_t means a singed integer of exactly N bits an unsigned integer of exactly N bits (e.g. uint32_t).
(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 The distinction between "connected" sockets and "unconnected" sockets
is important when discussing the applicability of the socket API is important when discussing the applicability of the socket API
defined in this document. A connected socket is bound to a given defined in this document. A connected socket is bound to a given
peer, whereas an unconnected socket is not bound to any specific peer, whereas an unconnected socket is not bound to any specific
peers. That is, the destination of the user data is not known until peers. A TCP socket becomes a connected socket when the TCP
the application writes data to an unconnected socket. TCP sockets connection establishment is completed. UDP sockets are unconnected,
are connected, by definition. UDP sockets are unconnected, unless unless the application uses the connect() system call.
the application uses the connect() system call.
The target readers of this document are application programmers who The target readers of this document are application programmers who
develop application software which may benefit greatly from develop application software which may benefit greatly from
multihomed environments. In addition, this document aims to provide multihomed environments. In addition, this document aims to provide
necessary information for developers of multihoming shim protocols to necessary information for developers of shim protocols to implement
implement API for enabling advanced locator management. API for enabling advanced locator management.
2. Terminology 2. Terminology
This section provides terminology used in this document. Basically This section provides terminology used in this document. Basically
most of the terms used in this document are taken from the following most of the terms used in this document are taken from the following
documents: documents:
o SHIM6 Protocol Specification[RFC5533] o SHIM6 Protocol Specification[RFC5533]
o HIP Architecture[RFC4423] o HIP Architecture[RFC4423]
o Reachability Protocol (REAP)[RFC5534] o Reachability Protocol (REAP)[RFC5534]
skipping to change at page 5, line 41 skipping to change at page 5, line 30
to specify the endpoint of a given communication. Applications to specify the endpoint of a given communication. Applications
may handle EIDs in various ways such as long-lived connections, may handle EIDs in various ways such as long-lived connections,
callbacks, and referrals[I-D.ietf-shim6-app-refer]. callbacks, and referrals[I-D.ietf-shim6-app-refer].
* In the case of SHIM6, an identifier called a ULID serves as an * In the case of SHIM6, an identifier called a ULID serves as an
EID. A ULID is chosen from locators available on the host. EID. A ULID is chosen from locators available on the host.
* In the case of HIP, an identifier called a Host Identifier * In the case of HIP, an identifier called a Host Identifier
serves as an EID. A Host Identifier is derived from the public serves as an EID. A Host Identifier is derived from the public
key of a given host. For the sake of backward compatibility key of a given host. For the sake of backward compatibility
with the sockets API, the Host Identifier is represented in a with the sockets API, the Host Identifier is represented in a
form of hash of public key. form of hash of public key.
* Note that the EID appears in the standard socket API as an
address, and does not appear in the extensions defined in this
document, which only concern locators.
o Locator - The IP address actually used to deliver IP packets. o Locator - The IP address actually used to deliver IP packets.
Locators are present in the source and destination fields of the Locators are present in the source and destination fields of the
IP header of a packet on the wire. IP header of a packet on the wire.
* List of locators - A list of locators associated with an EID. * List of locators - A list of locators associated with an EID.
There are two lists of locators stored in a given context. One There are two lists of locators stored in a given context. One
is associated with the local EID and the other is associated is associated with the local EID and the other is associated
with the remote EID. As defined in [RFC5533], the list of with the remote EID. As defined in [RFC5533], the list of
locators associated with an EID 'A' is denoted as Ls(A). locators associated with an EID 'A' is denoted as Ls(A).
* Preferred locator - The (source/destination) locator currently * Preferred locator - The (source/destination) locator currently
used to send packets within a given context. As defined in used to send packets within a given context. As defined in
[RFC5533], the preferred locator of a host 'A' is denoted as [RFC5533], the preferred locator of a host 'A' is denoted as
Lp(A). Lp(A).
* Unknown locator - Any locator that does not appear in the
locator list of the shim context associated with the socket.
When there is no shim context associated with the socket, any
source and/or destination locator requested by the application
is considered to be unknown locator.
o Shim - The conceptual sub-layer inside the IP layer which o Shim - The conceptual sub-layer inside the IP layer which
maintains mappings between EIDs and locators. An EID can be maintains mappings between EIDs and locators. An EID can be
associated with more than one locator at a time when the host is associated with more than one locator at a time when the host is
multihomed. The term 'shim' does not refer to a specific protocol multihomed. The term 'shim' does not refer to a specific protocol
but refers to the conceptual sub-layer inside the IP layer. but refers to the conceptual sub-layer inside the IP layer.
o Identifier/locator adaptation - The adaptation performed at the o Identifier/locator adaptation - The adaptation performed at the
shim sub-layer which may end up re-writing the source and/or shim sub-layer which may end up re-writing the source and/or
destination addresses of an IP packet. In the outbound packet destination addresses of an IP packet. In the outbound packet
processing, the EID pair is converted to the associated locator processing, the EID pair is converted to the associated locator
pair. In the inbound packet processing, the locator pair is pair. In the inbound packet processing, the locator pair is
skipping to change at page 7, line 37 skipping to change at page 7, line 32
v v v v
+------------------------------------------+ +------------------------------------------+
| Link Layer | | Link Layer |
+------------------------------------------+ +------------------------------------------+
Figure 1: System overview Figure 1: System overview
4. Requirements 4. Requirements
The following is a list of requirements from applications: The following is a list of requirements from applications:
o Turn on/off shim. An application should be able to request to
turn on or turn off the multihoming support by the shim layer:
* Apply shim. The application should be able to explicitly
request the shim sub-layer to apply multihoming support.
* Don't apply shim. The application should be able to request
the shim sub-layer not to apply the multihoming support but to
apply normal IP processing at the IP layer.
* Note that this function is also required by other types of
multihoming mechanisms such as SCTP and multipath TCP to avoid
potential conflict with the shim sub-layer.
o Locator management. o Locator management.
* It should be possible to set preferred source and/or * It should be possible to set preferred source and/or
destination locator within a given context: Lp(local) and/or destination locator within a given context: Lp(local) and/or
Lp(remote). Lp(remote).
* It should be possible to get preferred source and/or * It should be possible to get preferred source and/or
destination locator within a given context: Lp(local) and/or destination locator within a given context: Lp(local) and/or
Lp(remote). Lp(remote).
* It should be possible to set a list of source and/or * It should be possible to set a list of source and/or
destination locators within a given context: Ls(local) and destination locators within a given context: Ls(local) and
Ls(remote). Ls(remote).
* It should be possible to get a list of source and/or * It should be possible to get a list of source and/or
destination locators within a given context: Ls(local) and destination locators within a given context: Ls(local) and
Ls(remote). Ls(remote).
o Notification from applications to the shim sub-layer about the o Notification from applications to the shim sub-layer about the
status of the communication. The notification occurs in an event- status of the communication. The notification occurs in an event-
based manner. Applications and/or upper layer protocols may based manner. Applications and/or upper layer protocols may
provide positive feedbacks or negative feedbacks to the shim sub- provide positive feedbacks or negative feedbacks to the shim sub-
layer. Note that these feedbacks are mentioned in [RFC5534]]: layer. Note that these feedbacks are mentioned in [RFC5534]:
* Applications and/or upper layer protocols (e.g., TCP) may * Applications and/or upper layer protocols (e.g., TCP) may
provide positive feedbacks to the shim sub-layer informing that provide positive feedbacks to the shim sub-layer informing that
the communication is going well. the communication is going well.
* Applications and/or upper layer protocols (e.g., TCP) may * Applications and/or upper layer protocols (e.g., TCP) may
provide negative feedbacks to the shim sub-layer informing that provide negative feedbacks to the shim sub-layer informing that
the communication status is not satisfactory. TCP may detect a the communication status is not satisfactory. TCP may detect a
problem when it does not receive any expected ACK message from problem when it does not receive any expected ACK message from
the peer. Besides, a receipt of an ICMP error message could be the peer. Besides, a receipt of an ICMP error message could be
a clue for the application to detect problems. The REAP module a clue for the application to detect problems. The REAP module
may be triggered by these negative feedbacks and invoke the may be triggered by these negative feedbacks and invoke the
skipping to change at page 9, line 4 skipping to change at page 9, line 5
should be able to obtain information about the locator pair which should be able to obtain information about the locator pair which
was actually used to send or receive the packet. was actually used to send or receive the packet.
* For inbound traffic, the application may be interested in the * For inbound traffic, the application may be interested in the
locator pair which was actually used to receive the packet. locator pair which was actually used to receive the packet.
* For outbound traffic, the application may be interested in the * For outbound traffic, the application may be interested in the
locator pair which was actually used to transmit the packet. locator pair which was actually used to transmit the packet.
In this way, applications may have additional control on the In this way, applications may have additional control on the
locator management. For example, an application becomes able to locator management. For example, an application becomes able to
verify if its preference for locator is actually applied to the verify if its preference for locator is actually applied to the
flow or not. flow or not.
o Applications should be able to specify if they want to defer the o Applications should be able to specify if they want to defer the
context setup, or if they want context establishment to be started context setup, or if they want context establishment to be started
immediately in the case where there is no available context. A immediately in the case where there is no available context. A
deferred context setup means that the initiation of communication deferred context setup means that the initiation of communication
should not be blocked to wait for completion of the context should not be blocked to wait for completion of the context
establishment. establishment.
o Turn on/off shim. An application should be able to request to
turn on or turn off the multihoming support by the shim layer:
* Apply shim. The application should be able to explicitly
request the shim sub-layer to apply multihoming support.
* Don't apply shim. The application should be able to request
the shim sub-layer not to apply the multihoming support but to
apply normal IP processing at the IP layer.
o An application should be able to know if the communication is now o An application should be able to know if the communication is now
being served by the shim sub-layer or not. being served by the shim sub-layer or not.
o An application should be able to use a common interface to access o An application should be able to use a common interface to access
an IPv4 locator and an IPv6 locator. an IPv4 locator and an IPv6 locator.
5. Socket Options for Multihoming Shim Sub-layer 5. Socket Options for Multihoming Shim Sub-layer
In this section, socket options that are specific to the shim sub- In this section, socket options that are specific to the shim sub-
layer are defined. layer are defined.
Table 1 shows a list of the socket options that are specific to the Table 1 shows a list of the socket options that are specific to the
multihoming shim sub-layer. An application may use these socket shim sub-layer. An application may use these socket options for a
options for a given socket either by the getsockopt() system call or given socket either by the getsockopt() system call or by the
by the setsockopt() system call. All of these socket options are setsockopt() system call. All of these socket options are defined at
defined at level SOL_SHIM. 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 the and third columns indicate whether the option can be handled by the
getsockopt() system call and/or by the setsockopt() system call. The getsockopt() system call and/or by the setsockopt() system call. The
fourth column provides a brief description of the socket option. The fourth column provides a brief description of the socket option. The
fifth column shows the type of data structure specified along with fifth column shows the type of data structure specified along with
the socket option. By default, the data structure type is an the socket option. By default, the data structure type is an
integer. integer.
+-----------------------------+-----+-----+-----------------+-------+ +-----------------------------+-----+-----+-----------------+-------+
skipping to change at page 14, line 22 skipping to change at page 14, line 22
getsockopt(fd, SOL_SHIM, SHIM_ASSOCIATED, &optval, &optlen); getsockopt(fd, SOL_SHIM, SHIM_ASSOCIATED, &optval, &optlen);
5.2. SHIM_DONTSHIM 5.2. SHIM_DONTSHIM
The SHIM_DONTSHIM option is used to request the shim layer not to The SHIM_DONTSHIM option is used to request the shim layer not to
provide the multihoming support for the communication established provide the multihoming support for the communication established
over the socket. over the socket.
The data type of the option value is an integer, and it takes 0 or 1. The data type of the option value is an integer, and it takes 0 or 1.
An option value 0 means that the multihoming shim sub-layer is An option value 0 means that the shim sub-layer is employed if
employed if available. An option value 1 means that the application available. An option value 1 means that the application does not
does not want the multihoming shim sub-layer to provide the want the shim sub-layer to provide the multihoming support for the
multihoming support for the communication established over the communication established over the socket.
socket.
Default value is set as 0, which means that the multihoming shim sub- Default value is set as 0, which means that the shim sub-layer
layer performs identifier/locator adaptation if available. performs identifier/locator adaptation if available.
Any attempt to disable the multihoming shim support MUST be made by Any attempt to disable the multihoming shim support MUST be made by
the application before the socket is connected. If an application the application before the socket is connected. If an application
makes such an attempt for a connected-socket, an error code makes such an attempt for a connected-socket, an error code
EOPNOTSUPP MUST be returned. EOPNOTSUPP MUST be returned.
For example, an application can request the system not to apply the For example, an application can request the system not to apply the
multihoming support as follows: multihoming support as follows:
int optval; int optval;
skipping to change at page 16, line 13 skipping to change at page 16, line 12
The option is effective only when there is a shim context associated The option is effective only when there is a shim context associated
with the socket. with the socket.
The data type of the option value is a pointer to the buffer where a The data type of the option value is a pointer to the buffer where a
set of information for path exploration is stored. The data set of information for path exploration is stored. The data
structure is defined in Section 7. structure is defined in Section 7.
By default, the option value is set to NULL, meaning that the option By default, the option value is set to NULL, meaning that the option
is disabled. is disabled.
An error ENOENT will be returned when there is no context associated An error ENOENT is returned when there is no context associated with
with the socket. the socket.
For example, an application can set parameters for path exploration For example, an application can set parameters for path exploration
by using the socket option as follows. by using the socket option as follows.
struct shim6_pathexplore pe; struct shim6_pathexplore pe;
pe.pe_probenum = 4; /* times */ pe.pe_probenum = 4; /* times */
pe.pe_keepaliveto = 10; /* seconds */ pe.pe_keepaliveto = 10; /* seconds */
pe.pe_initprobeto = 500; /* milliseconds */ pe.pe_initprobeto = 500; /* milliseconds */
pe.pe_reserved = 0; pe.pe_reserved = 0;
skipping to change at page 17, line 9 skipping to change at page 17, line 7
By default, the option value is set to NULL, meaning that the option By default, the option value is set to NULL, meaning that the option
is disabled. is disabled.
The preferred locator can be set by setsockopt(). The shim sub-layer The preferred locator can be set by setsockopt(). The shim sub-layer
shall verify requested locator before it updating the preferred shall verify requested locator before it updating the preferred
locator. locator.
An application can get the preferred locator by getsockopt(). An application can get the preferred locator by getsockopt().
An error ENOENT will be returned when there is no context associated An error ENOENT is returned when there is no context associated with
with the socket. the socket.
An error EINVALIDLOCATOR will be returned when the validation of the An error EINVALIDLOCATOR is returned when the validation of the
specified locator failed. specified locator failed.
For example, an application can set the preferred locator by using For example, an application can set the preferred locator by using
the socket option as follows. Note that some members of the the socket option as follows. Note that some members of the
shim_locator (lc_ifidx and lc_flags) are ignored in the set shim_locator (lc_ifidx and lc_flags) are ignored in the set
operation. operation.
struct shim_locator lc; struct shim_locator lc;
struct in6_addr ip6; struct in6_addr ip6;
skipping to change at page 18, line 15 skipping to change at page 18, line 12
By default, the option value is set to NULL, meaning that the option By default, the option value is set to NULL, meaning that the option
is disabled. is disabled.
The preferred locator can be set by setsockopt(). The shim sub-layer The preferred locator can be set by setsockopt(). The shim sub-layer
shall verify requested locator before it updating the preferred shall verify requested locator before it updating the preferred
locator. locator.
An application can get the preferred locator by getsockopt(). An application can get the preferred locator by getsockopt().
An error ENOENT will be returned when there is no context associated An error ENOENT is returned when there is no context associated with
with the socket. the socket.
An error EINVALIDLOCATOR will be returned when the validation of the An error EINVALIDLOCATOR is returned when the validation of the
requested locator fails. requested locator fails.
The usage of the option is same as that of SHIM_LOC_LOCAL_PREF. Note The usage of the option is same as that of SHIM_LOC_LOCAL_PREF. Note
that some members of the shim_locator (lc_ifidx and lc_flags) are that some members of the shim_locator (lc_ifidx and lc_flags) are
ignored in the set operation. ignored in the set operation.
5.7. SHIM_LOC_LOCAL_RECV 5.7. SHIM_LOC_LOCAL_RECV
The SHIM_LOC_LOCAL_RECV option can be used to request the shim sub- The SHIM_LOC_LOCAL_RECV option can be used to request the shim sub-
layer to store the destination locator of the received IP packet in layer to store the destination locator of the received IP packet in
skipping to change at page 18, line 44 skipping to change at page 18, line 41
should be binary (0 or 1). By default, the option value is set to 0, should be binary (0 or 1). By default, the option value is set to 0,
meaning that the option is disabled. meaning that the option is disabled.
An application can set the option value by setsockopt(). An application can set the option value by setsockopt().
An application can get the option value by getsockopt(). An application can get the option value by getsockopt().
See Section 6 for the procedure to access locator information stored See Section 6 for the procedure to access locator information stored
in the ancillary data objects. in the ancillary data objects.
An error ENOENT will be returned when there is no context associated An error ENOENT is returned when there is no context associated with
with the socket. the socket.
For example, an application can request the shim sub-layer to store For example, an application can request the shim sub-layer to store
destination locator by using the socket option as follows. destination locator by using the socket option as follows.
int optval; int optval;
optval = 1; optval = 1;
setsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_RECV, &optval, setsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_RECV, &optval,
sizeof(optval)); sizeof(optval));
skipping to change at page 19, line 40 skipping to change at page 19, line 34
should be binary (0 or 1). By default, the option value is set to 0, should be binary (0 or 1). By default, the option value is set to 0,
meaning that the option is disabled. meaning that the option is disabled.
The option value can be set by setsockopt(). The option value can be set by setsockopt().
The option value can be read by getsockopt(). The option value can be read by getsockopt().
See Section 6 for the procedure to access locator information stored See Section 6 for the procedure to access locator information stored
in the ancillary data objects. in the ancillary data objects.
An error ENOENT will be returned when there is no context associated An error ENOENT is returned when there is no context associated with
with the socket. the socket.
The usage of the option is same as that of SHIM_LOC_LOCAL_RECV The usage of the option is same as that of SHIM_LOC_LOCAL_RECV
option. option.
5.9. SHIM_LOC_LOCAL_SEND 5.9. SHIM_LOC_LOCAL_SEND
The SHIM_LOC_LOCAL_SEND option is used to request the shim sub-layer The SHIM_LOC_LOCAL_SEND option is used to request the shim sub-layer
to use a specific locator as the source locator for the IP packets to to use a specific locator as the source locator for the IP packets to
be sent from the socket. Hence this option is effective only when be sent from the socket. Hence this option is effective only when
there is a shim context associated with the socket. there is a shim context associated with the socket.
skipping to change at page 20, line 15 skipping to change at page 20, line 9
The data type of option value is pointer to shim_locator data The data type of option value is pointer to shim_locator data
structure. structure.
An application can set the local locator by setsockopt() providing a An application can set the local locator by setsockopt() providing a
valid locator which is stored in a shim_locator data structure. When valid locator which is stored in a shim_locator data structure. When
a zero-filled locator is specified, pre-existing setting of local a zero-filled locator is specified, pre-existing setting of local
locator is inactivated. locator is inactivated.
An application can get the local locator by getsockopt(). An application can get the local locator by getsockopt().
An error ENOENT will be returned when there is no context associated An error ENOENT is returned when there is no context associated with
with the socket. the socket.
An error EINVALIDLOCATOR will be returned when invalid locator is An error EINVALIDLOCATOR is returned when invalid locator is
specified. specified.
For example, an application can request the shim sub-layer to use a For example, an application can request the shim sub-layer to use a
specific local locator by using the socket option as follows. specific local locator by using the socket option as follows.
struct shim_locator locator; struct shim_locator locator;
struct in6_addr ia6; struct in6_addr ia6;
/* an IPv6 address preferred for the source locator is copied /* an IPv6 address preferred for the source locator is copied
to the parameter ia6 */ to the parameter ia6 */
skipping to change at page 21, line 22 skipping to change at page 21, line 22
The data type of the option value is a pointer to shim_locator data The data type of the option value is a pointer to shim_locator data
structure. structure.
An application can set the remote locator by setsockopt() providing a An application can set the remote locator by setsockopt() providing a
valid locator which is stored in a shim_locator data structure. When valid locator which is stored in a shim_locator data structure. When
a zero-filled locator is specified, pre-existing setting of remote a zero-filled locator is specified, pre-existing setting of remote
locator is inactivated. locator is inactivated.
An application can get the specified remote locator by getsockopt(). An application can get the specified remote locator by getsockopt().
An error ENOENT will be returned when there is no context associated An error ENOENT is returned when there is no context associated with
with the socket. the socket.
An error EINVALIDLOCATOR when invalid locator is specified. An error EINVALIDLOCATOR when invalid locator is specified.
The usage of the option is as the same as that of SHIM_LOC_LOCAL_SEND The usage of the option is as the same as that of SHIM_LOC_LOCAL_SEND
option. option.
5.11. SHIM_LOCLIST_LOCAL 5.11. SHIM_LOCLIST_LOCAL
The SHIM_LOCLIST_LOCAL option is used to get or set the locator list The SHIM_LOCLIST_LOCAL option is used to get or set the locator list
associated with the local EID of the shim context associated with the associated with the local EID of the shim context associated with the
skipping to change at page 21, line 50 skipping to change at page 21, line 50
to NULL, meaning that the option is disabled. to NULL, meaning that the option is disabled.
An application can get the locator list by getsockopt(). Note that An application can get the locator list by getsockopt(). Note that
the size of the buffer pointed by optval argument should be large the size of the buffer pointed by optval argument should be large
enough to store an array of locator information. The number of the enough to store an array of locator information. The number of the
locator information is not known beforehand. locator information is not known beforehand.
The local locator list can be set by setsockopt(). The buffer The local locator list can be set by setsockopt(). The buffer
pointed by optval argument should contain an array of locator list. pointed by optval argument should contain an array of locator list.
An error ENOENT will be returned when there is no context associated An error ENOENT is returned when there is no context associated with
with the socket. the socket.
An error EINVALIDLOCATOR will be returned when the validation of the An error EINVALIDLOCATOR is returned when the validation of the
specified locator failed. specified locator failed.
An error ETOOMANYLOCATORS is returned when the number of locators
specified exceeds the limit (SHIM_MAX_LOCATORS).
For example, an application can set a list of locators to be For example, an application can set a list of locators to be
associated with the local EID by using the socket option as follows: associated with the local EID by using the socket option as follows:
struct shim_locator locators[SHIM_MAX_LOCATORS]; struct shim_locator locators[SHIM_MAX_LOCATORS];
struct sockaddr_in *sin; struct sockaddr_in *sin;
struct sockaddr_in6 *sin6; struct sockaddr_in6 *sin6;
memset(locators, 0, sizeof(locators)); memset(locators, 0, sizeof(locators));
... ...
skipping to change at page 23, line 35 skipping to change at page 23, line 35
to NULL, meaning that the option is disabled. to NULL, meaning that the option is disabled.
An application can get the locator list by getsockopt(). Note that An application can get the locator list by getsockopt(). Note that
the size of the buffer pointed by optval argument should be large the size of the buffer pointed by optval argument should be large
enough to store an array of locator information. The number of the enough to store an array of locator information. The number of the
locator information is not known beforehand. locator information is not known beforehand.
An application can set the locator list by setsockopt(). The buffer An application can set the locator list by setsockopt(). The buffer
pointed by optval argument should contain an array of locator list. pointed by optval argument should contain an array of locator list.
An error ENOENT will be returned when there is no context associated An error ENOENT is returned when there is no context associated with
with the socket. the socket.
An error EINVALIDLOCATOR will be returned when the validation of the An error EINVALIDLOCATOR is returned when the validation of the
specified locator failed. specified locator failed.
An error ETOOMANYLOCATORS is returned when the number of locators
specified exceeds the limit (SHIM_MAX_LOCATORS).
The usage of the option is same as that of SHIM_LOCLIST_LOCAL. The usage of the option is same as that of SHIM_LOCLIST_LOCAL.
5.13. SHIM_APP_TIMEOUT 5.13. SHIM_APP_TIMEOUT
The SHIM_APP_TIMEOUT option is used to get or set the timeout value The SHIM_APP_TIMEOUT option is used to get or set the timeout value
for application to detect failure. Hence this option is effective for application to detect failure. Hence this option is effective
only when there is a shim context associated with the socket. only when there is a shim context associated with the socket.
The data type of the option value is an integer. The value indicates The data type of the option value is an integer. The value indicates
the period of timeout in seconds to send a REAP Keepalive message the period of timeout in seconds to send a REAP Keepalive message
since the last outbound traffic. By default, the option value is set since the last outbound traffic. By default, the option value is set
to 0, meaning that the option is disabled. When the option is to 0, meaning that the option is disabled. When the option is
disabled, the REAP mechanism follows its default value of Send disabled, the REAP mechanism follows its default value of Send
Timeout value as specified in [RFC5534] Timeout value as specified in [RFC5534]
If the timeout value specified is longer than the Send Timeout If the timeout value specified is longer than the Send Timeout
configured in the REAP component, the REAP Keepalive message should configured in the REAP component, the REAP Keepalive message should
be suppressed. be suppressed.
An error ENOENT will be returned when there is no context associated An error ENOENT is returned when there is no context associated with
with the socket. the socket.
For example, an application can set the timeout value by using the For example, an application can set the timeout value by using the
socket option as follows. socket option as follows.
int optval; int optval;
optval = 15; /* 15 seconds */ optval = 15; /* 15 seconds */
setsockopt(fd, SOL_SHIM, SHIM_APP_TIMEOUT, &optval, setsockopt(fd, SOL_SHIM, SHIM_APP_TIMEOUT, &optval,
sizeof(optval)); sizeof(optval));
skipping to change at page 25, line 32 skipping to change at page 25, line 35
int optval; int optval;
int len; int len;
len = sizeof(optval); len = sizeof(optval);
getsockopt(fd, SOL_SHIM, SHIM_DEFERRED_CONTEXT_SETUP, getsockopt(fd, SOL_SHIM, SHIM_DEFERRED_CONTEXT_SETUP,
&optval, &len); &optval, &len);
5.15. Applicability 5.15. Applicability
All the socket options for the multihoming shim sub-layer except for All the socket options for the shim sub-layer except for
SHIM_HOT_STANDBY are applicable for both connected and unconnected SHIM_HOT_STANDBY are applicable to both connected and unconnected
sockets. sockets. SHIM_HOT_STANDBY socket option is applicable only to
connected sockets. This is because the shim sub-layer cannot
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 initiate context establishment to create a hot standby connection
because the peer's IP address is not known until the application when the peer's IP address is not known until the application writes
writes data to the unconnected socket. data to the unconnected socket.
5.16. Error Handling 5.16. Error Handling
If successful, getsockopt() and setsockopt() return 0; otherwise, the If successful, getsockopt() and setsockopt() return 0; otherwise, the
functions return -1 and set errno to indicate an error. functions return -1 and set errno to indicate an error.
The following are new error values defined for some shim specific The following are new error values defined for some shim specific
socket options indicating that the getsockopt() or setsockopt() socket options indicating that the getsockopt() or setsockopt()
finished incompletely: finished incompletely:
skipping to change at page 26, line 17 skipping to change at page 26, line 17
inside the shim sub-layer for the specified locator has failed. inside the shim sub-layer for the specified locator has failed.
In case of SHIM6, there are two kinds of verifications required In case of SHIM6, there are two kinds of verifications required
for security reasons prior to sending an IP packet to the peer's for security reasons prior to sending an IP packet to the peer's
new locator; one is the return routability (check if the peer is new locator; one is the return routability (check if the peer is
actually willing to receive data with the specified locator) and actually willing to receive data with the specified locator) and
the other one is the verification based on crypto identifier the other one is the verification based on crypto identifier
mechanisms [RFC3972], [RFC5535]. mechanisms [RFC3972], [RFC5535].
6. Ancillary Data for Multihoming Shim Sub-layer 6. Ancillary Data for Multihoming Shim Sub-layer
In this section, the definition and the usage of the ancillary data This section provides definitions of ancillary data to be used for
specific to multihoming shim sub-layer are provided. locator management and notification from/to the shim sub-layer to/
from application.
As defined in the Posix standard, sendmsg() and recvmsg() input a When the application performs locator management by sendmsg() or
msghdr structure as their arguments. These system calls can handle recvmsg(), a member of the msghdr structure (given in Figure 3)
control information along with data. Figure 3 shows the msghdr called msg_control holds a pointer to the buffer in which one ore
structure which is defined in <sys/socket.h>. The member msg_control more shim specific ancillary data objects may be stored. An
holds a pointer to the buffer where the shim specific ancillary data ancillary data object can store a single locator. It should be
objects can be stored in addition to other ancillary data objects. possible to process the shim specific ancillary data object by the
existing macros defined in the Posix standard and [RFC3542].
struct msghdr { struct msghdr {
caddr_t msg_name; /* optional address */ caddr_t msg_name; /* optional address */
u_int msg_namelen; /* size of address */ u_int msg_namelen; /* size of address */
struct iovec *msg_iov; /* scatter/gather array */ struct iovec *msg_iov; /* scatter/gather array */
u_int msg_iovlen; /* # elements in msg_iov */ u_int msg_iovlen; /* # elements in msg_iov */
caddr_t msg_control; /* ancillary data, see below */ caddr_t msg_control; /* ancillary data, see below */
u_int msg_controllen; /* ancillary data buffer len */ u_int msg_controllen; /* ancillary data buffer len */
int msg_flags; /* flags on received message */ int msg_flags; /* flags on received message */
}; };
Figure 3: msghdr structure Figure 3: msghdr structure
The buffer pointed by the member msg_control of the msghdr structure In the case of unconnected socket, msg_name stores the socket address
may contain locator information which is a single locator and it of the peer which should be considered to be an identifier rather
should be possible to process them with the existing macros defined than a locator. SHIM_LOC_PEER_RECV should be used to get the locator
in Posix and [RFC3542]. Each cmsghdr{} should be followed by data of the peer node.
which stores a single locator.
In case of non-connected socket, msg_name member stores the socket
address of the peer which should be considered as an identifier
rather than a locator. The locator of the peer node should be
retrieved by SHIM_LOC_PEER_RECV as specified below.
Table 2 is a list of the shim specific ancillary data which can be Table 2 is a list of the shim specific ancillary data which can be
used for recvmsg() or sendmsg(). In any case, SOL_SHIM must be set used for locator management by recvmsg() or sendmsg(). In any case,
as cmsg_level. the value of cmsg_level must be set as SOL_SHIM.
+---------------------+-----------+-----------+-----------------+ +---------------------+-----------+-----------+-----------------+
| 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 | o | | shim_feedback{} | | SHIM_FEEDBACK | o | | shim_feedback{} |
+---------------------+-----------+-----------+-----------------+ +---------------------+-----------+-----------+-----------------+
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[] includes a single sockaddr_in{} or sockaddr_in6{} and
sockaddr_in{}/sockaddr_in6{}. padding if necessary
6.1. Get Locator from Incoming Packet 6.1. Get Locator from Incoming Packet
An application can get locator information from the received IP An application can get locator information from the received IP
packet by specifying the shim specific socket options for the socket. packet by specifying the shim specific socket options for the socket.
When SHIM_LOC_LOCAL_RECV and/or SHIM_LOC_PEER_RECV socket options are When SHIM_LOC_LOCAL_RECV and/or SHIM_LOC_PEER_RECV socket options are
set, the application can retrieve local and/or remote locator from set, the application can retrieve local and/or remote locator from
the ancillary data. the ancillary data.
6.2. Set Locator for Outgoing Packet 6.2. Set Locator for Outgoing Packet
skipping to change at page 27, line 43 skipping to change at page 27, line 42
SHIM_LOC_LOCAL_SEND and/or SHIM_LOC_PEER_SEND are specified, the SHIM_LOC_LOCAL_SEND and/or SHIM_LOC_PEER_SEND are specified, the
application can explicitly specify the source and/or the destination application can explicitly specify the source and/or the destination
locators to be used for the communication over the socket. locators to be used for the communication over the socket.
Note that the effect is limited to the datagram transmitted by the Note that the effect is limited to the datagram transmitted by the
sendmsg(). sendmsg().
If the specified locator pair is verified, the shim sub-layer If the specified locator pair is verified, the shim sub-layer
overrides the locators of the IP packet. overrides the locators of the IP packet.
An error EINVALIDLOCATOR will be returned when validation of the An error EINVALIDLOCATOR is returned when validation of the specified
specified locator failed. locator failed.
6.3. Notification from Application to Multihoming Shim Sub-layer 6.3. Notification from Application to Multihoming Shim Sub-layer
An application may provide feedbacks to the shim sub-layer about the An application may provide feedbacks to the shim sub-layer about the
communication status. Such feedbacks are particularly useful for the communication status. Such feedbacks are particularly useful for the
shim sub-layer in the absence of REAP mechanism to monitor the shim sub-layer in the absence of REAP mechanism to monitor the
reachability status of the currently used locator pair in a given reachability status of the currently used locator pair in a given
shim context. shim context.
The notification can be made by sendmsg() specifying a new ancillary The notification can be made by sendmsg() specifying a new ancillary
data called SHIM_FEEDBACK. The ancillary data can be handled by data called SHIM_FEEDBACK. The ancillary data can be handled by
specifying SHIM_FEEDBACK option in cmsg_type. specifying SHIM_FEEDBACK option in cmsg_type.
An error ENOENT will be returned when there is no context associated An error ENOENT is returned when there is no context associated with
with the socket. the socket.
See Section 7.3 for details of the data structure to be used. 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 It is outside the scope of this document how the shim sub-layer would
react when a feedback is provided by an application. react when a feedback is provided by an application.
6.4. Notification from Multihoming Shim Sub-layer to Application 6.4. Notification from Multihoming Shim Sub-layer to Application
The multihoming shim sub-layer MAY provide notification about a The shim sub-layer MAY provide notification about a locator change
locator change within a multihome shim context to applications that within a multihome shim context to applications that have concern
have concern with the context. Such a notification is useful, for with the context. Such a notification may be useful, for example,
example, for an application which is sensitive to path for an application which is sensitive to the characteristics of the
characteristics. A locator change is caused when either of local or current path. A locator change is caused when either of local or
peer's locator (or both) is changed. Note that locators discussed 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 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 ones that are included in the locator list. A locator change may
take place asynchronously. take place asynchronously.
The notification is handled as an out-of-band data by the The notification is handled as an out-of-band data by the
application. application.
1. Application calls the select() system call by setting non-NULL 1. Application calls the select() system call by setting non-NULL
value for the fourth argument. value for the fourth argument.
2. When there is a notification, the application reads out-of-band 2. When there is a notification, the application reads out-of-band
data from the socket by calling the recvmsg() system call. data from the socket by calling recvmsg().
3. The application checks the flag in the msghdr (msg_flags) to see 3. The application checks the flag in the msghdr (msg_flags) to see
if there is any notification about locator change delivered. If if there is any notification about locator change delivered. If
the MSG_SHIM_LOCATOR_CHANGE flag is set, application parse the the MSG_SHIM_LOCATOR_CHANGE flag is set, application parses the
chain of control message to read a pair of ancillary data objects chain of control message to read a pair of ancillary data objects
which contains the source locator and the destination locator. which contains the source locator and the destination locator.
Note that the direction of locator change is distinguished by the Note that the direction of locator change is distinguished by the
cmsg_type; SHIM_LOC_*_RECV is used for inbound locator change, value of cmsg_type; SHIM_LOC_*_RECV is used for inbound locator
and SHIM_LOC_*_SEND is used for outbound locator change. change, and SHIM_LOC_*_SEND is used for outbound locator change.
There is no restriction in terms of applicability of the notification There is no restriction in terms of applicability of the notification
about locator change. The notification can be delivered to sockets about locator change. The notification can be delivered to any type
regardless of if it is connected or unconnected, stream-oriented or of socket (connected or unconnected, stream-oriented or datagram-
datagram-oriented. oriented).
6.5. Applicability 6.5. Applicability
All the ancillary data for the shim sub-layer is applicable to both
connected and unconnected sockets.
A care is needed when the SHIM_LOC_*_RECV socket option is used for 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- stream-oriented sockets (e.g., TCP sockets) because there is no one-
to-one mapping between a single send or receive operation and the 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 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 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 data is identical to the locator(s) that appear in the IP packets
received. The multihoming shim sub-layer SHOULD provide the latest received. The shim sub-layer SHOULD provide the latest locator
locator information to the application in response to the information to the application in response to the SHIM_LOC_*_RECV
SHIM_LOC_*_RECV socket option. socket option.
7. Data Structures 7. Data Structures
In this section, data structures specifically defined for the This section data structures for the shim sub-layer. These data
multihoming shim sub-layer are introduced. These data structures are structures are either used as a parameter for setsockopt() or
either used as a parameter for setsockopt()/getsockopt() (as getsockopt() (as mentioned in Section 5) or as a parameter for
mentioned in Section 5) or as a parameter for ancillary data to be ancillary data to be processed by sendmsg() or recvmsg() (as
processed by sendmsg()/recvmsg() (as mentioned in Section 6). mentioned in Section 6).
7.1. Placeholder for Locator Information 7.1. Placeholder for Locator Information
As defined in Section 5, the SHIM_LOC_LOCAL_PREF, SHIM_LOC_PEER_PREF, As defined in Section 5, the SHIM_LOC_LOCAL_PREF, SHIM_LOC_PEER_PREF,
SHIM_LOCLIST_LOCAL, and SHIM_LOCLIST_PEER socket options need to SHIM_LOCLIST_LOCAL, and SHIM_LOCLIST_PEER socket options need to
handle one or more locator information. Locator information includes handle one or more locator information. Locator information includes
not only the locator itself but also additional information about the not only the locator itself but also additional information about the
locator which is useful for locator management. A new data structure locator which is useful for locator management. A new data structure
is defined to serve as a placeholder for the locator information. is defined to serve as a placeholder for the locator information.
skipping to change at page 33, line 12 skipping to change at page 33, line 12
unidirectional reachability between the locator pair in unidirectional reachability between the locator pair in
question. question.
* 3: Satisfactory. There is satisfactory unidirectional * 3: Satisfactory. There is satisfactory unidirectional
reachability between the locator pair in question. reachability between the locator pair in question.
reserved reserved
Reserved field. Must be ignored by the receiver. Reserved field. Must be ignored by the receiver.
8. System Requirements 8. System Requirements
As discussed in Section 5, all the socket options for multihoming This section gives system requirements posed by the sockets API
shim sub-layer except for the SHIM_HOT_STANDBY socket option are defined in this document. There exist requirements for the system
applicable to both connected and unconnected sockets. The (kernel) to maintain the association between sockets and shim
implications of this design choice on system requirements should be contexts.
noted.
As addressed in Section 5, all the socket options and ancillary data
defined in this document except for the SHIM_HOT_STANDBY socket
option are applicable to both connected and unconnected sockets.
There are less system requirements to enable support for applications There are less system requirements to enable support for applications
that use connected sockets. This is because the kernel can easily that use connected sockets. This is because the kernel can maintain
maintain association between a connected socket and a multihoming the association between a connected socket and a shim context in a
shim context. Note that the multihoming shim contexts are identified static manner because a connected socket is bound to a source and
by an EID pair. In contrast, there are more system requirements to destination IP addresses (identifiers). The kernel should be able to
enable support for applications that use unconnected sockets. The identify shim context associated with a connected socket by searching
kernel needs to dynamically resolve association between an shim context keyed by the pair of source and destination identifiers.
unconnected socket and a multihoming shim context, if any, upon However, this is not the case for unnconnected sockets. The kernel
packet processing. As to outbound packet processing, the kernel needs to dynamically resolve association between an unconnected
needs to check if there is any multihoming shim context whose EID socket and a shim context, if any, upon packet processing. As to
pair matches with the source and destination IP addresses of the user outbound packet processing, the kernel needs to check if there is any
data originating from an unconnected socket. If a matching context shim context whose EID pair matches with the source and destination
is found, the multihoming shim sub-layer performs packet processing IP addresses of the user data originating from an unconnected socket.
taking the application's preference into account. Note that the If a matching context is found, the shim sub-layer performs packet
multihoming shim sub-layer should be able to backtrack the socket processing taking the application's preference into account. Note
from which the user data was originated. As to inbound packet that the shim sub-layer should be able to backtrack the socket from
processing, the multihoming shim sub-layer needs to check not only which the user data was originated. As to inbound packet processing,
the IP header but also the transport layer protocol header to resolve the shim sub-layer needs to check not only the IP header but also the
the destination socket. If the destination socket is resolved and it transport layer protocol header to resolve the destination socket.
contains any values concerning the multihoming shim sub-layer socket If the destination socket is resolved and it contains any values
options, the multihoming shim sub-layer processes the IP packet as concerning the shim sub-layer socket options, the shim sub-layer
requested (e.g., set locator information of received packet in the processes the IP packet as requested (e.g., set locator information
ancillary data). of received packet in the ancillary data).
9. Implications for Existing Socket API Extensions 9. Relation to Existing Sockets API Extensions
Some of the socket options defined in this document are overlapping This section explains relation between the sockets API defined in
with existing sockets API and care should be taken for the usage not this document and the existing sockets API extensions.
to confuse with the overlapping features.
The socket options for requesting specific locators to be used for a As mentioned in Section 5, the basic assumption is that the existing
given transaction (SHIM_LOC_LOCAL_PREF and SHIM_LOC_PEER_PREF) are sockets API continues to work above the shim sub-layer. This means
semantically similar to the existing sockets API (IPV6_PKTINFO). The that, the existing sockets API deals with identifiers, and the
socket options for obtaining the locator information from the sockets API defined in this document deals with locators.
received IP packet (SHIM_LOC_LOCAL_RECV and SHIM_LOC_PEER_RECV) are
semantically similar to the existing sockets API (IP_RECVDSTADDR and
IPV6_PKTINFO).
In IPv4, application can obtain the destination IP address of the SHIM_LOC_LOCAL_PREF and SHIM_LOC_PEER_PREF socket options are
received IP packet (IP_RECVDSTADDR). If the shim sub-layer performs semantically similar to the IPV6_PKTINFO socket API in the sense that
identifier/locator adaptation for the received packet, the both provide a means for application to set the source IP address of
destination EID should be stored in the ancillary data outbound IP packets.
(IP_RECVDSTADDR).
In IPv6, [RFC3542] defines that IPV6_PKTINFO can be used to specify SHIM_LOC_LOCAL_RECV and SHIM_LOC_PEER_RECV socket options are
source IPv6 address and the outgoing interface for outgoing packets, semantically similar to the IP_RECVDSTADDR and IPV6_PKTINFO socket
and retrieve destination IPv6 address and receiving interface for APIs in the sense that both provides a means for application to get
incoming packets. This information is stored in ancillary data being the source and/or destination IP address of inbound IP packets.
IPV6_PKTINFO specified as cmsg_type. Existing sockets API should
continue to work above the shim sub-layer, that is, the IP addresses
handled in IPV6_PKTINFO should be EIDs, not the locators.
Baseline is that the above existing sockets API (IP_RECVDSTADDR and getsockname() and getpeername() enable application to get 'name' of
IPV6_PKTINFO) is assumed to work above the multihoming shim sub- the communication endpoints which is represented by a pair of IP
layer. In other words, the IP addresses those socket options deal address and port number assigned to the socket. getsockname() gives
with are EIDs rather than locators. IP address and port number assigned to the socket on the local side,
and getpeername() gives IP address and port number of the peer side.
10. Resolving Conflicts with Preference Values 10. Operational Considerations
Since the multihoming shim API allows application to specify This section gives operational considerations of the sockets API
preference value for the context which is associated with the socket defined in this document.
instance, there may be a conflict with preference values specified by
different applications. For instance, application A and B may
establish communication with the same EID pair while both
applications have different preference in their choice of local
locator.
SHIM6 supports a notion of context forking in which a context is 10.1. Conflict Resolution
split when there is a conflict with preference values specified by
multiple applications. Thus, context forking can simply resolve the
conflicting situation which may be caused by the use of socket
options for multihoming shim sub-layer.
10.1. Implicit Forking There may be a conflicting situation when different applications
specify difference preference for the same shim context. For
instance, application A and B may establish communication with the
same EID pair while both applications have different preference in
their choice of local locator. The notion of context forking in
SHIM6 can resolve the conflicting situation.
Socket options defined in Section 5 may cause conflicting situation Socket options defined in Section 5 may cause conflicting situation
when the target context is shared by multiple applications. In such when the target context is shared by multiple applications. In such
case, socket handler should inform the shim sub-layer that context a case, the socket handler should inform the shim sub-layer that
forking is required. In SHIM6, when a context is forked, an unique context forking is required. In SHIM6, when a context is forked, an
identifier called Forked Instance Identifier (FII) is assigned to the unique identifier called Forked Instance Identifier (FII) is assigned
newly forked context. The forked context is then exclusively to the newly forked context. The forked context is then exclusively
associated with the socket through which non-default preference value associated with the socket through which non-default preference value
was specified. The forked context is maintained by the multihoming was specified. The forked context is maintained by the shim sub-
shim sub-layer during the lifetime of associated socket instance. layer during the lifetime of associated socket instance. When the
When the socket is closed, the multihoming shim sub-layer SHOULD socket is closed, the shim sub-layer SHOULD delete associated
delete associated context. In this way, garbage collection can be context. When a forked context is torn down, the SHIM6
carried out to cleanup unused forked contexts. Upon garbage implementation should notify the peer about the deletion of forked
collection, every forked context SHOULD be checked if there is no
socket (process) associated with the context. If there is none, the
forked context should be deleted. When a forked context is torn
down, SHIM6 should notify the peer about the deletion of forked
context. context.
As opposed to socket options, context forking MUST NOT be triggered 10.2. Incompatiblility between IPv4 and IPv6
by any use of ancillary data that is specific to multihoming shim
sub-layer as defined in Section 6.
11. Discussion The shim sub-layer performs identifier/locator adaptation.
Therefore, in some cases, the whole IP header can be replaced with
new IP header of a different address family (e.g. conversion from
IPv4 to IPv6 or vice versa). Hence, there is an issue how to make
the conversion with minimum impact. Note that this issue is common
in other protocol conversion such as SIIT[RFC2765].
In this section, open issues are introduced. As addressed in the SIIT specification, some of the features (IPv6
routing headers, hop-by-hop extension headers, or destination
headers) from IPv6 are not convertible to IPv4. In addition, notion
of source routing is not exactly the same in IPv4 and IPv6. This
means that an error may occur during the conversion of identifier and
locator. It is ffs exactly how the shim sub-layer should behave in
such erroneous cases.
11.1. Naming at Socket Layer 11. IANA Considerations
The getsockname() and getpeername() system calls are used to obtain This document contains no IANA consideration.
the 'name' of an endpoint which is actually a pair of IP address and
port number assigned to a given socket. getsockname() is used when an
application wants to obtain the local IP address and port number
assigned for a given socket instance. getpeername() is used when an
application obtains the remote IP address and port number.
The above is based on a traditional system model of the sockets API 12. Protocol Constants and Variables
where an IP address is expected to play both the role of identifier
and the role of locator.
In a system model where a shim sub-layer exists inside the IP layer, This section defines protocol constants and variables.
both getsockname() and getpeername() deal with identifiers, namely SHIM_MAX_LOCATORS The maximum number of the locators to be included
EIDs. In this sense, the shim sub-layer serves to (1) hide locators in a locator list. 32.
and (2) provide access to the identifier for the application over the
legacy socket APIs.
11.2. Additional Requirements from Applications 13. Security Considerations
At the moment, it is not certain if following requirements are common This section gives security considerations of the API defined in this
in all the multihomed environments (SHIM6 and HIP). These are mainly document.
identified during discussions made on SHIM6 WG mailing list.
o The application should be able to set preferences for the 13.1. Treatment of Unknown Locator
locators, local and remote ones, and also to the preferences of
the local locators that will be passed to the peer.
11.3. Issues of Header Conversion among Different Address Family When sending IP packets, application may request use of unknown
locator for the source and/or destination locators. Note that
treatment of unknown locator can be a subject of security
considerations because use of invalid source and/or destination
locator may cause redirection attack.
The shim sub-layer performs identifier/locator adaptation. 13.1.1. Treatment of Unknown Source Locator
Therefore, in some cases, the whole IP header can be replaced with
new IP header of a different address family (e.g. conversion from
IPv4 to IPv6 or vice versa). Hence, there is an issue how to make
the conversion with minimum impact. Note that this issue is common
in other protocol conversion such as SIIT[RFC2765].
As addressed in SIIT specification, some of the features (IPv6 The shim sub-layer checks if the requested locator is available on
routing headers, hop-by-hop extension headers, or destination any of the local interface. If not, the shim sub-layer MUST reject
headers) from IPv6 are not convertible to IPv4. In addition, notion the request and return an error message with the EINVALIDLOCATOR code
of source routing is not exactly the same in IPv4 and IPv6. Hence, to the application. If the locator is confirmed to be available, the
there is a certain limitation in protocol conversion between IPv4 and shim sub-layer SHOULD initiate the procedure to update the locator
IPv6. list.
The question is how should the shim sub-layer behave when it faces Use of the following socket options and ancillary data may require
with limitation problem of protocol conversion. Should we introduce treatment of unknown source locator:
new error something like ENOSUITABLELOCATOR ? o SHIM_LOC_LOCAL_SEND
o SHIM_LOC_LOCAL_PREF
o SHIM_LOC_LIST_LOCAL
11.4. Handling of Unknown Locator Provided by Application 13.1.2. Treatment of Unknown Destination Locator
There might be a case where application provides the shim layer new If the shim sub-layer turns out to be SHIM6, the SHIM6 implementation
locator with the SHIM_LOC_*_PREF socket options or SHIM_LOC_*_SEND MUST reject the request for using unknown destination locator.
ancillary data. Then there is a question how should the shim sub-
layer treat the new locator informed by the application.
In principle, locator information are exchanged by the shim protocol. If the shim sub-layer turns out to be HIP, the HIP implementation MAY
However, there might be a case where application acquires information accept the request for using unknown destination locator.
about the locator and prefers to use it for its communication.
12. Changes Use of the following socket options and ancillary data may require
treatment of unknown destination locator:
o SHIM_LOC_PEER_SEND
o SHIM_LOC_PEER_PREF
o SHIM_LOC_LIST_PEER
12.1. Changes from version 00 to version 01 14. Changes
14.1. Changes from version 00 to version 01
The followings are changes from version 00 to version 01:
o Define shim_locator{} data type which is a placeholder for o Define shim_locator{} data type which is a placeholder for
locator. locator.
o Define shim_pathexplore{} data type in which a set of REAP o Define shim_pathexplore{} data type in which a set of REAP
parameters are stored. parameters are stored.
o Remove descriptions about "stickiness" of socket options. o Remove descriptions about "stickiness" of socket options.
o Deprecate SHIM_IF_RECV and SHIM_IF_SEND socket options. o Deprecate SHIM_IF_RECV and SHIM_IF_SEND socket options.
o Give default value and how to disable given socket option. o Give default value and how to disable given socket option.
12.2. Changes from version 01 to version 02 14.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 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).
12.3. Changes from version 02 to version 03 14.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. o Add an Appendix section describing the issue of context forking.
12.4. Changes from version 03 to version 04 14.4. Changes from version 03 to version 04
The followings are changes from version 03 to version 04:
o Updated reference. o Updated reference.
o Correct typo and grammatical errors. o Correct typo and grammatical errors.
12.5. Changes from version 04 to version 05 14.5. Changes from version 04 to version 05
The followings are changes from version 04 to version 05:
o Added definition of SHIM_FEEDBACK ancillary data. o Added definition of SHIM_FEEDBACK ancillary data.
o Added an example of code using the SHIM_LOCLIST_LOCAL o Added an example of code using the SHIM_LOCLIST_LOCAL
o Added SHIM_LOC_LOCAL_SEND and SHIM_LOC_PEER_SEND socket options. o Added SHIM_LOC_LOCAL_SEND and SHIM_LOC_PEER_SEND socket options.
12.6. Changes from version 05 to version 06 14.6. Changes from version 05 to version 06
The followings are changes from version 04 to version 05:
o Updated references. o Updated references.
12.7. Changes from version 06 to version 07 14.7. Changes from version 06 to version 07
The followings are changes from version 06 to version 07:
o Resolved editorial issues. o Resolved editorial issues.
12.8. Changes from version 07 to version 08 14.8. Changes from version 07 to version 08
No changes are made except for updates of the references. No changes are made except for updates of the references.
12.9. Changes from version 08 to version 09 14.9. Changes from version 08 to version 09
The followings are changes from version 08 to version 09:
o Updated texts for Section 1 and Section 5 according to the o Updated texts for Section 1 and Section 5 according to the
comments provided by Samu Varjonen. comments provided by Samu Varjonen.
o Made it clear that downgrading the multihoming shim support (i.e., o Made it clear that downgrading the multihoming shim support (i.e.,
specifying value 1 with the SHIM_DONTSHIM socket option) is only specifying value 1 with the SHIM_DONTSHIM socket option) is only
allowed before the socket is connected. allowed before the socket is connected.
o Updated locator information (shim_locator{}) so that it can o Updated locator information (shim_locator{}) so that it can
contain a locator behind NAT. contain a locator behind NAT.
12.10. Changes from version 09 to version 10 14.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 o Addressed applicability of socket options and ancillary data for
the multihoming shim sub-layer. the shim sub-layer.
o Addressed system requirements. o Addressed system requirements.
o Removed unnecessary description about deprecated socket option o Removed unnecessary description about deprecated socket option
(SHIM_IF_RECV). (SHIM_IF_RECV).
12.11. Changes from version 10 to version 11 14.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 o Added short descriptions about connected sockets and unconnected
sockets. sockets.
o Relax applicability of the socket options. o Relaxed applicability of the socket options.
o Relax applicability of the ancillary data. o Relaxed applicability of the ancillary data.
o Added notification about locator change. o Added notification about locator change.
13. IANA Considerations 14.12. Changes from version 11 to version 12
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
basic assumption is that the security mechanism defined in each
protocol of the shim sub-layer is strictly applied.
15. Conclusion
In this document, the Application Program Interface (API) for
multihoming shim sub-layer is specified. The sockets API allows
applications to have additional control of the locator management and
interface to the REAP mechanism inside the multihoming shim sub-
layer.
Socket options for multihoming shim sub-layer can be used by
getsockopt() and/or setsockopt() system calls. Besides, applications
can use some ancillary data that are specific to multihoming shim
sub-layer to get locator from received packet or to set locator for
outgoing packet.
From an architectural point of view, the sockets API provides extends o Reflected comments from Brian Karpenter
the existing sockets API framework in the face of ID/Locator o Reflected comments from Michael Scharf
separation. With regard to API that relate to IP address management,
it is assured that existing sockets API continue to work above the
shim sub-layer dealing with identifiers, while multihoming shim API
deals with locators.
16. Acknowledgments 15. Acknowledgments
Authors would like to thank Jari Arkko who participated in the Authors would like to thank Jari Arkko who participated in the
discussion that lead to the first version of this document, and discussion that lead to the first version of this document, and
Tatuya Jinmei who thoroughly reviewed the early version of this draft Tatuya Jinmei who thoroughly reviewed the early version of this draft
and provided detailed comments on sockets API related issues. Thomas and provided detailed comments on sockets API related issues. Thomas
Henderson provided valuable comments especially from HIP Henderson provided valuable comments especially from HIP
perspectives. perspectives.
Authors sincerely thank to the following people for their help to Authors sincerely thank to the following people for their help to
improve this document: Samu Varjonen and Dmitriy Kuptsov. improve this document: Samu Varjonen and Dmitriy Kuptsov.
17. References 16. References
17.1. Normative References 16.1. Normative References
[POSIX] "IEEE Std. 1003.1-2001 Standard for Information Technology [POSIX] "IEEE Std. 1003.1-2001 Standard for Information Technology
-- Portable Operating System Interface (POSIX). Open group -- Portable Operating System Interface (POSIX). Open group
Technical Standard: Base Specifications, Issue 6, Technical Standard: Base Specifications, Issue 6,
http://www.opengroup.org/austin", December 2001. http://www.opengroup.org/austin", December 2001.
[RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei,
"Advanced Sockets Application Program Interface (API) for "Advanced Sockets Application Program Interface (API) for
IPv6", RFC 3542, May 2003. IPv6", RFC 3542, May 2003.
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, May 2006. (HIP) Architecture", RFC 4423, May 2006.
[RFC5533] Bagnulo, M. and E. Nordmark, "Level 3 multihoming shim [RFC5533] Bagnulo, M. and E. Nordmark, "Level 3 multihoming shim
protocol", RFC 5533, June 2009. protocol", RFC 5533, June 2009.
[RFC5534] Arkko, J. and I. Beijnum, "Failure Detection and Locator [RFC5534] Arkko, J. and I. Beijnum, "Failure Detection and Locator
Pair Exploration Protocol for IPv6 Multihoming", RFC 5534, Pair Exploration Protocol for IPv6 Multihoming", RFC 5534,
June 2009. June 2009.
17.2. Informative References 16.2. Informative References
[I-D.ietf-hip-nat-traversal] [I-D.ietf-hip-nat-traversal]
Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A.
Keranen, "Basic HIP Extensions for Traversal of Network Keranen, "Basic HIP Extensions for Traversal of Network
Address Translators", Internet Address Translators", Internet
Draft draft-ietf-hip-nat-traversal-09, October 2009. Draft draft-ietf-hip-nat-traversal-09, October 2009.
[I-D.ietf-shim6-app-refer] [I-D.ietf-shim6-app-refer]
Nordmark, E., "Shim6 Application Referral Issues", Nordmark, E., "Shim6 Application Referral Issues",
draft-ietf-shim6-app-refer-00 (work in progress), draft-ietf-shim6-app-refer-00 (work in progress),
July 2005. July 2005.
[I-D.ietf-shim6-applicability]
Abley, J., Bagnulo, M., and A. Garcia-Martinez,
"Applicability Statement for the Level 3 Multihoming Shim
Protocol (Shim6)", draft-ietf-shim6-applicability-04 (work
in progress), November 2009.
[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.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[RFC5535] Bagnulo, M., "Hash Based Addresses (HBA)", RFC 5535, [RFC5535] Bagnulo, M., "Hash Based Addresses (HBA)", RFC 5535,
skipping to change at page 40, line 48 skipping to change at page 39, line 48
In this section, an issue concerning context forking and its relation In this section, an issue concerning context forking and its relation
to the multihoming shim API are discussed. to the multihoming shim API are discussed.
SHIM6 supports a notion of context forking. A peer may decide to SHIM6 supports a notion of context forking. A peer may decide to
fork a context for certain reason (e.g. upper layer protocol prefers fork a context for certain reason (e.g. upper layer protocol prefers
to use different locator pair than the one defined in available to use different locator pair than the one defined in available
context). The procedure of forking context is done similar to the context). The procedure of forking context is done similar to the
normal context establishment, performing the 4-way message exchange. normal context establishment, performing the 4-way message exchange.
A peer who has decided to fork a context initiates the context A peer who has decided to fork a context initiates the context
establishment. Hereafter, we call this peer initiator. establishment. Hereafter, we call this peer the "initiator". The
peer of the initiator is called the "responder".
Once the forked context is established between the peers, on the Once the forked context is established between the peers, on the
initiator side, it is possible to apply forked context to the packet initiator side, it is possible to apply forked context to the packet
flow since the system maintains an association between the forked flow since the system maintains an association between the forked
context and the socket owned by the application that has requested context and the socket owned by the application that has requested
the context forking. How this association is maintained is the context forking. How this association is maintained is an
implementation specific issue. However, on the responder side, there implementation specific issue. However, on the responder side, there
is a question on how the outbound packet can be multiplexed by the is a question how the outbound packet can be multiplexed by the shim
shim sub-layer. Since there are more than one SHIM6 contexts that sub-layer because there are more than one SHIM6 contexts that match
match with the ULID pair of the packet flow. There is a need to 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 differentiate packet flows not only by the ULID pairs but by some
information and associate a given packet flow with specific context. other information and associate a given packet flow with a specific
context.
Figure 8 gives an example of a scenario where two communicating peers Figure 8 gives an example of a scenario where two communicating peers
fork a context. Initially, there has been a single transaction fork a context. Initially, there has been a single transaction
between the peers, by the application 1 (App1). Accordingly, another between the peers, by the application 1 (App1). Accordingly, another
transaction is started, by application 2 (App2). Both of the transaction is started, by application 2 (App2). Both of the
transactions are made based the same ULID pair. The first context transactions are made based on the same ULID pair. The first context
pair (Ctx1) is established for the transaction of App1. Given the pair (Ctx1) is established for the transaction of App1. Given the
requests from App2, the shim sub-layer on Peer 1 decides to fork a requests from App2, the shim sub-layer on Peer 1 decides to fork a
context. Accordingly, a forked context (Ctx2) is established between context. Accordingly, a forked context (Ctx2) is established between
the peers, which should be exclusively applied to the transaction of the peers, which should be exclusively applied to the transaction of
App2. Ideally, multiplexing and demultiplexing of packet flows that App2. Ideally, multiplexing and demultiplexing of packet flows that
relate to App1 and App2 should be done as illustrated in Figure 8. relate to App1 and App2 should be done as illustrated in Figure 8.
However, as mentioned earlier, the responder needs to multiplex However, as mentioned earlier, the responder needs to multiplex
outbound flows of App1 and App2 somehow. Note that if a context outbound flows of App1 and App2 somehow. Note that if a context
forking occurs on the initiator side, a context forking needs to forking occurs on the initiator side, a context forking needs to
occur also on the responder side. occur also on the responder side.
skipping to change at page 42, line 33 skipping to change at page 41, line 33
|| || || || || || || ||
|| || || || || || || ||
\..............||....................../| || \..............||....................../| ||
\.............||......................./ || \.............||......................./ ||
|| || || ||
\|...................................../| \|...................................../|
\....................................../ \....................................../
Figure 8: context forking Figure 8: context forking
To overcome the problem mentioned above, there are some solutions. Any solution is needed to overcome the problem mentioned above.
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 sub-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 Institute for Information Technology Helsinki Institute for Information Technology
Tammasaarenkatu 3 Tammasaarenkatu 3
Helsinki Helsinki
Finland Finland
Phone: +358503841531 Phone: +358503841531
skipping to change at page 44, line 4 skipping to change at page 42, line 22
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)
Nippon Ericsson K.K. Nippon Ericsson K.K.
Koraku Mori Building Koraku Mori Building
1-4-14, Koraku, Bunkyo-ku 1-4-14, Koraku, Bunkyo-ku
Tokyo 112-0004 Tokyo 112-0004
Japan Japan
Phone: +81 3 3830 2241 Phone: +81 3 3830 2241
Email: shinta.sugimoto@ericsson.com Email: shinta@sfc.wide.ad.jp
 End of changes. 131 change blocks. 
419 lines changed or deleted 345 lines changed or added

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