draft-ietf-shim6-multihome-shim-api-10.txt   draft-ietf-shim6-multihome-shim-api-11.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: April 29, 2010 UC3M Expires: June 10, 2010 UC3M
K. Slavov K. Slavov
S. Sugimoto, Ed. S. Sugimoto, Ed.
Ericsson Ericsson
October 26, 2009 December 7, 2009
Socket Application Program Interface (API) for Multihoming Shim Socket Application Program Interface (API) for Multihoming Shim
draft-ietf-shim6-multihome-shim-api-10 draft-ietf-shim6-multihome-shim-api-11
Status of this Memo 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 April 29, 2010. This Internet-Draft will expire on June 10, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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
skipping to change at page 2, line 45 skipping to change at page 2, line 45
5.12. SHIM_LOCLIST_PEER . . . . . . . . . . . . . . . . . . . . 23 5.12. SHIM_LOCLIST_PEER . . . . . . . . . . . . . . . . . . . . 23
5.13. SHIM_APP_TIMEOUT . . . . . . . . . . . . . . . . . . . . 23 5.13. SHIM_APP_TIMEOUT . . . . . . . . . . . . . . . . . . . . 23
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. Applicability . . . . . . . . . . . . . . . . . . . . . . 28 6.4. Notification from Multihoming Shim Sub-layer to
7. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 28 Application . . . . . . . . . . . . . . . . . . . . . . . 28
7.1. Placeholder for Locator Information . . . . . . . . . . . 28 6.5. Applicability . . . . . . . . . . . . . . . . . . . . . . 29
7.1.1. Handling Locator behind NAT . . . . . . . . . . . . . 29 7. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 29
7.2. Path Exploration Parameter . . . . . . . . . . . . . . . 30 7.1. Placeholder for Locator Information . . . . . . . . . . . 29
7.3. Feedback Information . . . . . . . . . . . . . . . . . . 31 7.1.1. Handling Locator behind NAT . . . . . . . . . . . . . 30
8. System Requirements . . . . . . . . . . . . . . . . . . . . . 32 7.2. Path Exploration Parameter . . . . . . . . . . . . . . . 31
9. Implications for Existing Socket API Extensions . . . . . . . 32 7.3. Feedback Information . . . . . . . . . . . . . . . . . . 32
10. Resolving Conflicts with Preference Values . . . . . . . . . . 33 8. System Requirements . . . . . . . . . . . . . . . . . . . . . 33
10.1. Implicit Forking . . . . . . . . . . . . . . . . . . . . 33 9. Implications for Existing Socket API Extensions . . . . . . . 33
11. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 34 10. Resolving Conflicts with Preference Values . . . . . . . . . . 34
11.1. Naming at Socket Layer . . . . . . . . . . . . . . . . . 34 10.1. Implicit Forking . . . . . . . . . . . . . . . . . . . . 34
11.2. Additional Requirements from Applications . . . . . . . . 34 11. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 35
11.1. Naming at Socket Layer . . . . . . . . . . . . . . . . . 35
11.2. Additional Requirements from Applications . . . . . . . . 35
11.3. Issues of Header Conversion among Different Address 11.3. Issues of Header Conversion among Different Address
Family . . . . . . . . . . . . . . . . . . . . . . . . . 34 Family . . . . . . . . . . . . . . . . . . . . . . . . . 36
11.4. Handling of Unknown Locator Provided by Application . . . 35 11.4. Handling of Unknown Locator Provided by Application . . . 36
12. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 12. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
12.1. Changes from version 00 to version 01 . . . . . . . . . . 35 12.1. Changes from version 00 to version 01 . . . . . . . . . . 36
12.2. Changes from version 01 to version 02 . . . . . . . . . . 35 12.2. Changes from version 01 to version 02 . . . . . . . . . . 37
12.3. Changes from version 02 to version 03 . . . . . . . . . . 36 12.3. Changes from version 02 to version 03 . . . . . . . . . . 37
12.4. Changes from version 03 to version 04 . . . . . . . . . . 36 12.4. Changes from version 03 to version 04 . . . . . . . . . . 37
12.5. Changes from version 04 to version 05 . . . . . . . . . . 36 12.5. Changes from version 04 to version 05 . . . . . . . . . . 37
12.6. Changes from version 05 to version 06 . . . . . . . . . . 36 12.6. Changes from version 05 to version 06 . . . . . . . . . . 37
12.7. Changes from version 06 to version 07 . . . . . . . . . . 36 12.7. Changes from version 06 to version 07 . . . . . . . . . . 37
12.8. Changes from version 07 to version 08 . . . . . . . . . . 36 12.8. Changes from version 07 to version 08 . . . . . . . . . . 37
12.9. Changes from version 08 to version 09 . . . . . . . . . . 36 12.9. Changes from version 08 to version 09 . . . . . . . . . . 38
12.10. Changes from version 09 to version 10 . . . . . . . . . . 36 12.10. Changes from version 09 to version 10 . . . . . . . . . . 38
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 12.11. Changes from version 10 to version 11 . . . . . . . . . . 38
14. Security Considerations . . . . . . . . . . . . . . . . . . . 37 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
15. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 37 14. Security Considerations . . . . . . . . . . . . . . . . . . . 38
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 15. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 38
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39
17.1. Normative References . . . . . . . . . . . . . . . . . . 38 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
17.2. Informative References . . . . . . . . . . . . . . . . . 38 17.1. Normative References . . . . . . . . . . . . . . . . . . 39
Appendix A. Context Forking . . . . . . . . . . . . . . . . . . . 39 17.2. Informative References . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 Appendix A. Context Forking . . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43
1. Introduction 1. Introduction
HIP and SHIM6 have a commonality in their protocol design in the HIP and SHIM6 have a commonality in their protocol design in the
sense that the semantic roles of an IP address, i.e., an identifier sense that the semantic roles of an IP address, i.e., an identifier
and a locator, are distinguished. Separation of identifier and and a locator, are distinguished. Separation of identifier and
locator is done by introducing a "shim" inside the IP layer which locator is done by introducing a "shim" inside the IP layer which
maintains mapping of the identifier and associated locators. This maintains mapping of the identifier and associated locators. This
design principle is called "identifier/locator separation" and the design principle is called "identifier/locator separation" and the
shim is referred to as a "shim sub-layer" in this document. shim is referred to as a "shim sub-layer" in this document.
skipping to change at page 4, line 50 skipping to change at page 4, line 50
As this document specifies sockets API extensions, it is written so As this document specifies sockets API extensions, it is written so
that the syntax and semantics are in line with the Posix standard that the syntax and semantics are in line with the Posix standard
[POSIX] as much as possible. The API specified in this document [POSIX] as much as possible. The API specified in this document
defines how to use ancillary data (aka cmsg) to access the locator defines how to use ancillary data (aka cmsg) to access the locator
information with recvmsg() and/or sendmsg() I/O calls. The information with recvmsg() and/or sendmsg() I/O calls. The
definition of API is presented in C language and data types follow definition of API is presented in C language and data types follow
the Posix format; intN_t means a singed integer of exactly N bits the Posix format; intN_t means a singed integer of exactly N bits
(e.g. int16_t) and uintN_t means an unsigned integer of exactly N (e.g. int16_t) and uintN_t means an unsigned integer of exactly N
bits (e.g. uint32_t). bits (e.g. uint32_t).
The distinction between "connected" sockets and "unconnected" sockets
is important when discussing the applicability of the socket API
defined in this document. A connected socket is bound to a given
peer, whereas an unconnected socket is not bound to any specific
peers. That is, the destination of the user data is not known until
the application writes data to an unconnected socket. TCP sockets
are connected, by definition. UDP sockets are unconnected, unless
the application uses the connect() system call.
The target readers of this document are application programmers who 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 multihoming shim protocols to
implement API for enabling advanced locator management. implement 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
skipping to change at page 13, line 44 skipping to change at page 13, line 44
The SHIM_ASSOCIATED option is used to check whether the socket is The SHIM_ASSOCIATED option is used to check whether the socket is
associated with any shim context or not. associated with any shim context or not.
This option is meaningful when the locator information of the This option is meaningful when the locator information of the
received IP packet does not tell whether the identifier/locator received IP packet does not tell whether the identifier/locator
adaptation is performed or not. Note that the EID pair and the adaptation is performed or not. Note that the EID pair and the
locator pair may be identical in some cases. locator pair may be identical in some cases.
This option can be specified by getsockopt(). Thus, the option is This option can be specified by getsockopt(). Thus, the option is
read-only and the result (0 or 1) is set in the option value (the read-only and the result (0/1/2) is set in the option value (the
fourth argument of getsockopt()). fourth argument of getsockopt()).
The data type of the option value is an integer. The option value The data type of the option value is an integer. The option value
indicates the presence of shim context. A returned value 1 means indicates the presence of shim context. A return value 1 means that
that the socket is associated with a shim context at the shim sub- the socket is associated with a shim context at the shim sub-layer.
layer. A return value 0 indicates that there is no shim context A return value 0 indicates that there is no shim context associated
associated with the socket. with the socket. A return value 2 means that it is not known whether
the socket is associated with a shim context or not, and this must be
returned only when the socket is unconnected. In other words, the
returned value must be 0 or 1 when the socket is connected.
For example, the option can be used by the application as follows: For example, the option can be used by the application as follows:
int optval; int optval;
int optlen = sizeof(optval); int optlen = sizeof(optval);
getsockopt(fd, SOL_SHIM, SHIM_ASSOCIATED, &optval, &optlen); getsockopt(fd, SOL_SHIM, SHIM_ASSOCIATED, &optval, &optlen);
5.2. SHIM_DONTSHIM 5.2. SHIM_DONTSHIM
skipping to change at page 24, line 50 skipping to change at page 24, line 50
communication. Note that SHIM6 supports deferred context setup and communication. Note that SHIM6 supports deferred context setup and
HIP does not because EIDs in HIP (i.e., Host Identifiers) are non- HIP does not because EIDs in HIP (i.e., Host Identifiers) are non-
routable. routable.
The data type for the option value is an integer. The option value The data type for the option value is an integer. The option value
should be binary (0 or 1). By default, the value is set to 1, should be binary (0 or 1). By default, the value is set to 1,
meaning that the context setup is deferred. In order to disable the meaning that the context setup is deferred. In order to disable the
option, the application should call setsockopt() with option value option, the application should call setsockopt() with option value
set to 0. set to 0.
Note that HIP does not support deferred context setup, by default.
When the application requests to enable deferred context setup in
case of HIP, it may mean that the application allows the system to
start TCP handshake even when there is no IPsec security association
with the peer. Such a usage of the SHIM_DEFERRED_CONTEXT_SETUP
option should be considered as experimental and left for further
study.
For example, an application can disable the deferred context setup by For example, an application can disable the deferred context setup by
using the socket option as follows: using the socket option as follows:
int optval; int optval;
optval = 0; optval = 0;
setsockopt(fd, SOL_SHIM, SHIM_DEFERRED_CONTEXT_SETUP, setsockopt(fd, SOL_SHIM, SHIM_DEFERRED_CONTEXT_SETUP,
&optval, sizeof(optval)); &optval, sizeof(optval));
skipping to change at page 25, line 24 skipping to change at page 25, line 32
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 are All the socket options for the multihoming shim sub-layer except for
applicable only to connected sockets. The reason behind this SHIM_HOT_STANDBY are applicable for both connected and unconnected
restriction is that it is necessary for the multihoming shim layer to sockets.
identify a target multihoming shim context when an application gives
preference value(s) by a socket option for the multihoming shim sub- The reason SHIM_HOT_STANDBY socket option cannot be used for an
layer. Multihoming shim contexts are, by definition, identified by a unconnected socket is that the multihoming shim sub-layer cannot
pair of EIDs. Therefore, it is possible for the multihoming shim initiate context establishment to create a hot standby connection
sub-layer to identify the target context only when the source and because the peer's IP address is not known until the application
destination IP addresses of the application session are known. When writes data to the unconnected socket.
any socket options for the multihoming shim sub-layer is set for an
unconnected socket, EINVAL error code MUST be returned.
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 28, line 17 skipping to change at page 28, line 18
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 will be returned when there is no context associated
with the socket. with 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. Applicability 6.4. Notification from Multihoming Shim Sub-layer to Application
It is important to note that the ancillary data specified in this The multihoming shim sub-layer MAY provide notification about a
section are applicable only to datagram-oriented sockets (e.g., UDP locator change within a multihome shim context to applications that
sockets or raw sockets) and that they are not applicable to stream- have concern with the context. Such a notification is useful, for
oriented sockets (e.g., TCP sockets). The reason behind this example, for an application which is sensitive to path
restriction is that there is no one-to-one mapping between a single characteristics. A locator change is caused when either of local or
send or receive operation and a TCP segment being transmitted or peer's locator (or both) is changed. Note that locators discussed
received. here are the ones that appear in the IP packet header, and not the
ones that are included in the locator list. A locator change may
take place asynchronously.
Due to the above restriction and the restriction addressed in The notification is handled as an out-of-band data by the
Section 5.15, SHIM_LOC_LOCAL_RECV or SHIM_LOC_PEER_RECV socket application.
options are, in practice, applicable only to connected UDP sockets. 1. Application calls the select() system call by setting non-NULL
value for the fourth argument.
2. When there is a notification, the application reads out-of-band
data from the socket by calling the recvmsg() system call.
3. The application checks the flag in the msghdr (msg_flags) to see
if there is any notification about locator change delivered. If
the MSG_SHIM_LOCATOR_CHANGE flag is set, application parse the
chain of control message to read a pair of ancillary data objects
which contains the source locator and the destination locator.
Note that the direction of locator change is distinguished by the
cmsg_type; SHIM_LOC_*_RECV is used for inbound locator change,
and SHIM_LOC_*_SEND is used for outbound locator change.
There is no restriction in terms of applicability of the notification
about locator change. The notification can be delivered to sockets
regardless of if it is connected or unconnected, stream-oriented or
datagram-oriented.
6.5. Applicability
A care is needed when the SHIM_LOC_*_RECV socket option is used for
stream-oriented sockets (e.g., TCP sockets) because there is no one-
to-one mapping between a single send or receive operation and the
data (e.g., a TCP segment) being received. In other words, there is
no gurantee that the locator(s) set in the SHIM_LOC_*_RECV ancillary
data is identical to the locator(s) that appear in the IP packets
received. The multihoming shim sub-layer SHOULD provide the latest
locator information to the application in response to the
SHIM_LOC_*_RECV socket option.
7. Data Structures 7. Data Structures
In this section, data structures specifically defined for the In this section, data structures specifically defined for the
multihoming shim sub-layer are introduced. These data structures are multihoming shim sub-layer are introduced. These data structures are
either used as a parameter for setsockopt()/getsockopt() (as either used as a parameter for setsockopt()/getsockopt() (as
mentioned in Section 5) or as a parameter for ancillary data to be mentioned in Section 5) or as a parameter for ancillary data to be
processed by sendmsg()/recvmsg() (as mentioned in Section 6). processed by sendmsg()/recvmsg() (as mentioned in Section 6).
7.1. Placeholder for Locator Information 7.1. Placeholder for Locator Information
skipping to change at page 32, line 4 skipping to change at page 32, line 48
direction direction
Indicates direction of reachability between a locator pair in Indicates direction of reachability between a locator pair in
question. A value 0 indicates outbound and a value 1 indicates question. A value 0 indicates outbound and a value 1 indicates
inbound direction. inbound direction.
indicator indicator
A value indicating the degree of satisfaction of a unidirectional A value indicating the degree of satisfaction of a unidirectional
reachability for a given locator pair. reachability for a given locator pair.
* 0: Default value. Whenever this value is specified the * 0: Default value. Whenever this value is specified the
feedback information must not be processed by the shim sub- feedback information must not be processed by the shim sub-
layer. layer.
* 1: Unable to connect. There is no unidirectional reachability * 1: Unable to connect. There is no unidirectional reachability
between the locator pair in question. between the locator pair in question.
* 2: Unsatisfactory. The application is not satisfied with the * 2: Unsatisfactory. The application is not satisfied with the
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 As discussed in Section 5, all the socket options for multihoming
shim sub-layer are applicable only to connected sockets. To break shim sub-layer except for the SHIM_HOT_STANDBY socket option are
this down into system requirements, the operating system (kernel) applicable to both connected and unconnected sockets. The
should be able to establish and maintain an association between a implications of this design choice on system requirements should be
socket instance and one or more multihoming shim context. It is, noted.
however, outside the scope of this document how the operating system
would establish and maintain associations between sockets and There are less system requirements to enable support for applications
multihoming shim contexts. An association can be established on that use connected sockets. This is because the kernel can easily
creation of a multihoming shim context, or at any stage. On creation maintain association between a connected socket and a multihoming
of a shim context, the multihoming shim sub-layer on the initiator shim context. Note that the multihoming shim contexts are identified
side should be aware of the triggering packet and it should be by an EID pair. In contrast, there are more system requirements to
possible to figure out the originating socket. It is more difficult enable support for applications that use unconnected sockets. The
to establish an association on the responder side. kernel needs to dynamically resolve association between an
unconnected socket and a multihoming shim context, if any, upon
packet processing. As to outbound packet processing, the kernel
needs to check if there is any multihoming shim context whose EID
pair matches with the source and destination IP addresses of the user
data originating from an unconnected socket. If a matching context
is found, the multihoming shim sub-layer performs packet processing
taking the application's preference into account. Note that the
multihoming shim sub-layer should be able to backtrack the socket
from which the user data was originated. As to inbound packet
processing, the multihoming shim sub-layer needs to check not only
the IP header but also the transport layer protocol header to resolve
the destination socket. If the destination socket is resolved and it
contains any values concerning the multihoming shim sub-layer socket
options, the multihoming shim sub-layer processes the IP packet as
requested (e.g., set locator information of received packet in the
ancillary data).
9. Implications for Existing Socket API Extensions 9. Implications for Existing Socket API Extensions
Some of the socket options defined in this document are overlapping Some of the socket options defined in this document are overlapping
with existing sockets API and care should be taken for the usage not with existing sockets API and care should be taken for the usage not
to confuse with the overlapping features. to confuse with the overlapping features.
The socket options for requesting specific locators to be used for a The socket options for requesting specific locators to be used for a
given transaction (SHIM_LOC_LOCAL_PREF and SHIM_LOC_PEER_PREF) are given transaction (SHIM_LOC_LOCAL_PREF and SHIM_LOC_PEER_PREF) are
semantically similar to the existing sockets API (IPV6_PKTINFO). The semantically similar to the existing sockets API (IPV6_PKTINFO). The
skipping to change at page 37, line 4 skipping to change at page 38, line 19
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 12.10. Changes from version 09 to version 10
The followings are 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 multihoming 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
The followings are changes from version 10 to version 11:
o Added short descriptions about connected sockets and unconnected
sockets.
o Relax applicability of the socket options.
o Relax applicability of the ancillary data.
o Added notification about locator change.
13. IANA Considerations 13. IANA Considerations
This document contains no IANA consideration. This document contains no IANA consideration.
14. Security Considerations 14. Security Considerations
This document does not specify any security mechanism for the shim This document does not specify any security mechanism for the shim
sub-layer. Fundamentally, the shim sub-layer has a potential to sub-layer. Fundamentally, the shim sub-layer has a potential to
impose security threats, as it changes the source and/or destination impose security threats, as it changes the source and/or destination
IP addresses of the IP packet being sent or received. Therefore, the IP addresses of the IP packet being sent or received. Therefore, the
skipping to change at page 42, line 12 skipping to change at page 44, line 12
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@sfc.wide.ad.jp Email: shinta.sugimoto@ericsson.com
 End of changes. 20 change blocks. 
80 lines changed or deleted 155 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/