draft-ietf-shim6-multihome-shim-api-12.txt | draft-ietf-shim6-multihome-shim-api-13.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: July 13, 2010 UC3M | Expires: August 26, 2010 UC3M | |||
K. Slavov | K. Slavov | |||
S. Sugimoto, Ed. | S. Sugimoto, Ed. | |||
Ericsson | Ericsson | |||
January 9, 2010 | February 22, 2010 | |||
Socket Application Program Interface (API) for Multihoming Shim | Socket Application Program Interface (API) for Multihoming Shim | |||
draft-ietf-shim6-multihome-shim-api-12 | draft-ietf-shim6-multihome-shim-api-13 | |||
Abstract | ||||
This document specifies sockets API extensions for the multihoming | ||||
shim layer. The API aims to enable interactions between applications | ||||
and the multihoming shim layer for advanced locator management, and | ||||
access to information about failure detection and path exploration. | ||||
This document is based on an assumption that a multihomed host is | ||||
equipped with a conceptual sub-layer (hereafter "shim") inside the IP | ||||
layer that maintains mappings between identifiers and locators. | ||||
Examples of the shim are SHIM6 and HIP. | ||||
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 48 | |||
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 July 13, 2010. | This Internet-Draft will expire on August 26, 2010. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2010 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 | |||
publication of this document (http://trustee.ietf.org/license-info). | (http://trustee.ietf.org/license-info) in effect on the date of | |||
Please review these documents carefully, as they describe your rights | publication of this document. Please review these documents | |||
and restrictions with respect to this document. | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | ||||
Abstract | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | ||||
This document specifies sockets API extensions for the multihoming | described in the BSD License. | |||
shim layer. The API aims to enable interactions between applications | ||||
and the multihoming shim layer for advanced locator management, and | ||||
access to information about failure detection and path exploration. | ||||
This document is based on an assumption that a multihomed host is | ||||
equipped with a conceptual sub-layer (hereafter "shim") inside the IP | ||||
layer that maintains mappings between identifiers and locators. | ||||
Examples of the shim are SHIM6 and HIP. | ||||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
3. System Overview . . . . . . . . . . . . . . . . . . . . . . . 6 | 3. System Overview . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
5. Socket Options for Multihoming Shim Sub-layer . . . . . . . . 9 | 5. Socket Options for Multihoming Shim Sub-layer . . . . . . . . 9 | |||
5.1. SHIM_ASSOCIATED . . . . . . . . . . . . . . . . . . . . . 13 | 5.1. SHIM_ASSOCIATED . . . . . . . . . . . . . . . . . . . . . 12 | |||
5.2. SHIM_DONTSHIM . . . . . . . . . . . . . . . . . . . . . . 14 | 5.2. SHIM_DONTSHIM . . . . . . . . . . . . . . . . . . . . . . 13 | |||
5.3. SHIM_HOT_STANDBY . . . . . . . . . . . . . . . . . . . . 15 | 5.3. SHIM_HOT_STANDBY . . . . . . . . . . . . . . . . . . . . 14 | |||
5.4. SHIM_PATHEXPLORE . . . . . . . . . . . . . . . . . . . . 15 | 5.4. SHIM_LOC_LOCAL_PREF . . . . . . . . . . . . . . . . . . . 15 | |||
5.5. SHIM_LOC_LOCAL_PREF . . . . . . . . . . . . . . . . . . . 16 | 5.5. SHIM_LOC_PEER_PREF . . . . . . . . . . . . . . . . . . . 16 | |||
5.6. SHIM_LOC_PEER_PREF . . . . . . . . . . . . . . . . . . . 17 | 5.6. SHIM_LOC_LOCAL_RECV . . . . . . . . . . . . . . . . . . . 17 | |||
5.7. SHIM_LOC_LOCAL_RECV . . . . . . . . . . . . . . . . . . . 18 | 5.7. SHIM_LOC_PEER_RECV . . . . . . . . . . . . . . . . . . . 18 | |||
5.8. SHIM_LOC_PEER_RECV . . . . . . . . . . . . . . . . . . . 19 | 5.8. SHIM_LOC_LOCAL_SEND . . . . . . . . . . . . . . . . . . . 18 | |||
5.9. SHIM_LOC_LOCAL_SEND . . . . . . . . . . . . . . . . . . . 19 | 5.9. SHIM_LOC_PEER_SEND . . . . . . . . . . . . . . . . . . . 20 | |||
5.10. SHIM_LOC_PEER_SEND . . . . . . . . . . . . . . . . . . . 21 | 5.10. SHIM_LOCLIST_LOCAL . . . . . . . . . . . . . . . . . . . 20 | |||
5.11. SHIM_LOCLIST_LOCAL . . . . . . . . . . . . . . . . . . . 21 | 5.11. SHIM_LOCLIST_PEER . . . . . . . . . . . . . . . . . . . . 23 | |||
5.12. SHIM_LOCLIST_PEER . . . . . . . . . . . . . . . . . . . . 23 | 5.12. SHIM_APP_TIMEOUT . . . . . . . . . . . . . . . . . . . . 23 | |||
5.13. SHIM_APP_TIMEOUT . . . . . . . . . . . . . . . . . . . . 23 | 5.13. SHIM_PATHEXPLORE . . . . . . . . . . . . . . . . . . . . 24 | |||
5.14. SHIM_DEFERRED_CONTEXT_SETUP . . . . . . . . . . . . . . . 24 | 5.14. SHIM_DEFERRED_CONTEXT_SETUP . . . . . . . . . . . . . . . 25 | |||
5.15. Applicability . . . . . . . . . . . . . . . . . . . . . . 25 | 5.15. Applicability . . . . . . . . . . . . . . . . . . . . . . 26 | |||
5.16. Error Handling . . . . . . . . . . . . . . . . . . . . . 25 | 5.16. Error Handling . . . . . . . . . . . . . . . . . . . . . 26 | |||
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 . . . . . . . . . . . . . 28 | |||
6.3. Notification from Application to Multihoming Shim | 6.3. Notification from Application to Multihoming Shim | |||
Sub-layer . . . . . . . . . . . . . . . . . . . . . . . . 27 | Sub-layer . . . . . . . . . . . . . . . . . . . . . . . . 28 | |||
6.4. Notification from Multihoming Shim Sub-layer to | 6.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 28 | |||
Application . . . . . . . . . . . . . . . . . . . . . . . 28 | ||||
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. Relation to Existing Sockets API Extensions . . . . . . . . . 33 | 9. Relation to Existing Sockets API Extensions . . . . . . . . . 33 | |||
10. Operational Considerations . . . . . . . . . . . . . . . . . . 34 | 10. Operational Considerations . . . . . . . . . . . . . . . . . . 33 | |||
10.1. Conflict Resolution . . . . . . . . . . . . . . . . . . . 34 | 10.1. Conflict Resolution . . . . . . . . . . . . . . . . . . . 34 | |||
10.2. Incompatiblility between IPv4 and IPv6 . . . . . . . . . 35 | 10.2. Incompatiblility between IPv4 and IPv6 . . . . . . . . . 34 | |||
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 | 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 | |||
12. Protocol Constants and Variables . . . . . . . . . . . . . . . 35 | 12. Protocol Constants and Variables . . . . . . . . . . . . . . . 35 | |||
13. Security Considerations . . . . . . . . . . . . . . . . . . . 35 | 13. Security Considerations . . . . . . . . . . . . . . . . . . . 35 | |||
13.1. Treatment of Unknown Locator . . . . . . . . . . . . . . 35 | 13.1. Treatment of Unknown Locator . . . . . . . . . . . . . . 35 | |||
13.1.1. Treatment of Unknown Source Locator . . . . . . . . . 35 | 13.1.1. Treatment of Unknown Source Locator . . . . . . . . . 35 | |||
13.1.2. Treatment of Unknown Destination Locator . . . . . . . 36 | 13.1.2. Treatment of Unknown Destination Locator . . . . . . . 36 | |||
14. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 | 14. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 | |||
14.1. Changes from version 00 to version 01 . . . . . . . . . . 36 | 14.1. Changes from version 00 to version 01 . . . . . . . . . . 36 | |||
14.2. Changes from version 01 to version 02 . . . . . . . . . . 36 | 14.2. Changes from version 01 to version 02 . . . . . . . . . . 36 | |||
14.3. Changes from version 02 to version 03 . . . . . . . . . . 37 | 14.3. Changes from version 02 to version 03 . . . . . . . . . . 36 | |||
14.4. Changes from version 03 to version 04 . . . . . . . . . . 37 | 14.4. Changes from version 03 to version 04 . . . . . . . . . . 36 | |||
14.5. Changes from version 04 to version 05 . . . . . . . . . . 37 | 14.5. Changes from version 04 to version 05 . . . . . . . . . . 37 | |||
14.6. Changes from version 05 to version 06 . . . . . . . . . . 37 | 14.6. Changes from version 05 to version 06 . . . . . . . . . . 37 | |||
14.7. Changes from version 06 to version 07 . . . . . . . . . . 37 | 14.7. Changes from version 06 to version 07 . . . . . . . . . . 37 | |||
14.8. Changes from version 07 to version 08 . . . . . . . . . . 37 | 14.8. Changes from version 07 to version 08 . . . . . . . . . . 37 | |||
14.9. Changes from version 08 to version 09 . . . . . . . . . . 37 | 14.9. Changes from version 08 to version 09 . . . . . . . . . . 37 | |||
14.10. Changes from version 09 to version 10 . . . . . . . . . . 37 | 14.10. Changes from version 09 to version 10 . . . . . . . . . . 37 | |||
14.11. Changes from version 10 to version 11 . . . . . . . . . . 38 | 14.11. Changes from version 10 to version 11 . . . . . . . . . . 37 | |||
14.12. Changes from version 11 to version 12 . . . . . . . . . . 38 | 14.12. Changes from version 11 to version 12 . . . . . . . . . . 37 | |||
14.13. Changes from version 12 to version 13 . . . . . . . . . . 38 | ||||
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38 | 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38 | |||
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 | 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 | |||
16.1. Normative References . . . . . . . . . . . . . . . . . . 38 | 16.1. Normative References . . . . . . . . . . . . . . . . . . 38 | |||
16.2. Informative References . . . . . . . . . . . . . . . . . 39 | 16.2. Informative References . . . . . . . . . . . . . . . . . 39 | |||
Appendix A. Context Forking . . . . . . . . . . . . . . . . . . . 39 | Appendix A. Context Forking . . . . . . . . . . . . . . . . . . . 39 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 | |||
1. Introduction | 1. Introduction | |||
This document defines socket API extensions by which upper layer | This document defines socket API extensions by which upper layer | |||
skipping to change at page 4, line 34 | skipping to change at page 4, line 34 | |||
Note that the shim sub-layer may conflict with other multihoming | Note that the shim sub-layer may conflict with other multihoming | |||
mechanisms such as SCTP and multipath | mechanisms such as SCTP and multipath | |||
TCP[I-D.ietf-shim6-applicability]. To avoid any conflict, only one | TCP[I-D.ietf-shim6-applicability]. To avoid any conflict, only one | |||
of SHIM6 and HIP should be in use. | of SHIM6 and HIP should be in use. | |||
In this document, syntax and semantics of the API are given in the | In this document, syntax and semantics of the API are given in the | |||
same way as the Posix standard [POSIX]. The API specifies how to use | same way as the Posix standard [POSIX]. The API specifies how to use | |||
ancillary data (aka cmsg) to access the locator information with | ancillary data (aka cmsg) to access the locator information with | |||
recvmsg() and/or sendmsg() I/O calls. The API is described in C | recvmsg() and/or sendmsg() I/O calls. The API is described in C | |||
language and data types are defined in the Posix format; intN_t means | language and data types are defined in the Posix format; intN_t means | |||
a singed integer of exactly N bits (e.g. int16_t) and uintN_t means | a signed integer of exactly N bits (e.g. int16_t) and uintN_t means | |||
an unsigned integer of exactly N bits (e.g. uint32_t). | 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. A TCP socket becomes a connected socket when the TCP | peers. A TCP socket becomes a connected socket when the TCP | |||
connection establishment is completed. UDP sockets are unconnected, | connection establishment is completed. UDP sockets are unconnected, | |||
unless the application uses the connect() system call. | unless the application uses the connect() system call. | |||
skipping to change at page 8, line 23 | skipping to change at page 8, line 23 | |||
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. The REAP module may be triggered by these negative | |||
a clue for the application to detect problems. The REAP module | feedbacks and invoke the path exploration procedure. | |||
may be triggered by these negative feedbacks and invoke the | ||||
path exploration procedure. | ||||
o Feedback from applications to the shim sub-layer. Applications | o Feedback from applications to the shim sub-layer. Applications | |||
should be able to inform the shim sub-layer of the timeout values | should be able to inform the shim sub-layer of the timeout values | |||
for detecting failures, sending keepalives, and starting the | for detecting failures, sending keepalives, and starting the | |||
exploration procedure. In particular, applications should be able | exploration procedure. In particular, applications should be able | |||
to suppress keepalives. | to suppress keepalives. | |||
o Hot-standby. Applications may request the shim sub-layer for the | o Hot-standby. Applications may request the shim sub-layer for the | |||
hot-standby capability. This means that, alternative paths are | hot-standby capability. This means that, alternative paths are | |||
known to be working in advance of a failure detection. In such a | known to be working in advance of a failure detection. In such a | |||
case, it is possible for the host to immediately replace the | case, it is possible for the host to immediately replace the | |||
current locator pair with an alternative locator pair. | current locator pair with an alternative locator pair. | |||
skipping to change at page 9, line 5 | skipping to change at page 9, line 4 | |||
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 | ||||
context setup, or if they want context establishment to be started | o Applications should be able to know if the shim-sublayer supports | |||
immediately in the case where there is no available context. A | deferred context setup or not. | |||
deferred context setup means that the initiation of communication | ||||
should not be blocked to wait for completion of the context | ||||
establishment. | ||||
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. | |||
skipping to change at page 10, line 11 | skipping to change at page 9, line 37 | |||
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. | |||
+-----------------------------+-----+-----+-----------------+-------+ | +-----------------------------+-----+-----+-----------------+-------+ | |||
| optname | get | set | description | dtype | | | optname | get | set | description | dtype | | |||
+-----------------------------+-----+-----+-----------------+-------+ | +-----------------------------+-----+-----+-----------------+-------+ | |||
| SHIM_ASSOCIATED | o | | Get the | int | | | SHIM_ASSOCIATED | o | | Get the | int | | |||
| | | | parameter which | | | | | | | parameter which | | | |||
| | | | indicates | | | | | | | indicates | | | |||
| | | | whether if the | | | | | | | whether the | | | |||
| | | | socket is | | | | | | | socket is | | | |||
| | | | associated with | | | | | | | associated with | | | |||
| | | | any shim | | | | | | | any shim | | | |||
| | | | context or not. | | | | | | | context or not. | | | |||
| SHIM_DONTSHIM | o | o | Get or set the | int | | | SHIM_DONTSHIM | o | o | Get or set the | int | | |||
| | | | parameter which | | | | | | | parameter which | | | |||
| | | | indicates | | | | | | | indicates | | | |||
| | | | whether to | | | | | | | whether to | | | |||
| | | | employ the | | | | | | | employ the | | | |||
| | | | multihoming | | | | | | | multihoming | | | |||
skipping to change at page 11, line 23 | skipping to change at page 10, line 44 | |||
| | | | packet. | | | | | | | packet. | | | |||
| SHIM_LOC_PEER_RECV | o | o | Get or set the | int | | | SHIM_LOC_PEER_RECV | o | o | Get or set the | int | | |||
| | | | parameter which | | | | | | | parameter which | | | |||
| | | | is used to | | | | | | | is used to | | | |||
| | | | request the | | | | | | | request the | | | |||
| | | | shim sub-layer | | | | | | | shim sub-layer | | | |||
| | | | to store the | | | | | | | to store the | | | |||
| | | | source locator | | | | | | | source locator | | | |||
| | | | of the received | | | | | | | of the received | | | |||
| | | | IP packet. | | | | | | | IP packet. | | | |||
| SHIM_LOC_LOCAL_SEND | o | o | Get or set the | *2 | | | SHIM_LOC_LOCAL_SEND | o | o | Get or set the | *1 | | |||
| | | | source locator | | | | | | | source locator | | | |||
| | | | of outgoing IP | | | | | | | of outgoing IP | | | |||
| | | | packets. | | | | | | | packets. | | | |||
| SHIM_LOC_PEER_SEND | o | o | Get or set the | *2 | | | SHIM_LOC_PEER_SEND | o | o | Get or set the | *1 | | |||
| | | | destination | | | | | | | destination | | | |||
| | | | locator of | | | | | | | locator of | | | |||
| | | | outgoing IP | | | | | | | outgoing IP | | | |||
| | | | packets. | | | | | | | packets. | | | |||
| SHIM_LOCLIST_LOCAL | o | o | Get or set the | *3 | | | SHIM_LOCLIST_LOCAL | o | o | Get or set the | *2 | | |||
| | | | list of | | | | | | | list of | | | |||
| | | | locators | | | | | | | locators | | | |||
| | | | associated with | | | | | | | associated with | | | |||
| | | | the local EID. | | | | | | | the local EID. | | | |||
| SHIM_LOCLIST_PEER | o | o | Get or set the | *3 | | | SHIM_LOCLIST_PEER | o | o | Get or set the | *2 | | |||
| | | | list of | | | | | | | list of | | | |||
| | | | locators | | | | | | | locators | | | |||
| | | | associated with | | | | | | | associated with | | | |||
| | | | the peer's EID. | | | | | | | the peer's EID. | | | |||
| SHIM_APP_TIMEOUT | o | o | Get or set the | int | | | SHIM_APP_TIMEOUT | o | o | Get or set the | int | | |||
| | | | timeout value | | | | | | | timeout value | | | |||
| | | | for detecting | | | | | | | for detecting | | | |||
| | | | failure. | | | | | | | failure. | | | |||
| SHIM_PATHEXPLORE | o | o | Get or set | *4 | | | SHIM_PATHEXPLORE | o | o | Get or set | *3 | | |||
| | | | parameters for | | | | | | | parameters for | | | |||
| | | | path | | | | | | | path | | | |||
| | | | exploration and | | | | | | | exploration and | | | |||
| | | | failure | | | | | | | failure | | | |||
| | | | detection. | | | | | | | detection. | | | |||
| SHIM_CONTEXT_DEFERRED_SETUP | o | o | Get or set the | int | | | SHIM_CONTEXT_DEFERRED_SETUP | o | | Get the | int | | |||
| | | | parameter which | | | | | | | parameter which | | | |||
| | | | indicates | | | | | | | indicates | | | |||
| | | | whether | | | | | | | whether | | | |||
| | | | deferred | | | | | | | deferred | | | |||
| | | | context setup | | | | | | | context setup | | | |||
| | | | is supported or | | | | | | | is supported or | | | |||
| | | | not. | | | | | | | not. | | | |||
+-----------------------------+-----+-----+-----------------+-------+ | +-----------------------------+-----+-----+-----------------+-------+ | |||
Table 1: Socket options for multihoming shim sub-layer | Table 1: Socket options for multihoming shim sub-layer | |||
*1: Pointer to a shim_locator which is defined in Section 7. | *1: Pointer to a shim_locator which is defined in Section 7. | |||
*2: Pointer to shim_locator data structure. | *2: Pointer to an array of shim_locator. | |||
*3: Pointer to an array of shim_locator. | ||||
*4: Pointer to a shim_pathexplore which is defined in Section 7. | *3: Pointer to a shim_pathexplore which is defined in Section 7. | |||
Figure 2 illustrates how the shim specific socket options fit into | Figure 2 illustrates how the shim specific socket options fit into | |||
the system model of socket API. The figure shows that the shim sub- | the system model of socket API. The figure shows that the shim sub- | |||
layer and the additional protocol components (IPv4 and IPv6) below | layer and the additional protocol components (IPv4 and IPv6) below | |||
the shim sub-layer are new to the system model. As previously | the shim sub-layer are new to the system model. As previously | |||
mentioned, all the shim specific socket options are defined at the | mentioned, all the shim specific socket options are defined at the | |||
SOL_SHIM level. This design choice brings the following advantages: | SOL_SHIM level. This design choice brings the following advantages: | |||
1. The existing sockets API continue to work at the layer above the | 1. The existing sockets API continue to work at the layer above the | |||
shim sub-layer. That is, those legacy API handle IP addresses as | shim sub-layer. That is, those legacy API handle IP addresses as | |||
skipping to change at page 13, line 47 | skipping to change at page 13, line 11 | |||
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/1/2) 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()). | |||
When the application specifies the socket option to an unconnected | ||||
socket, an error code EOPNOTSUPP is returned to the application. | ||||
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 return value 1 means that | indicates the presence of shim context. A return value 1 means that | |||
the socket is associated with a shim context at the shim sub-layer. | the socket is associated with a shim context at the shim sub-layer. | |||
A return value 0 indicates that there is no shim context associated | A return value 0 indicates that there is no shim context associated | |||
with the socket. A return value 2 means that it is not known whether | 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 | 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 only when the socket is unconnected. In other words, the | |||
returned value must be 0 or 1 when the socket is connected. | 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: | |||
skipping to change at page 15, line 22 | skipping to change at page 14, line 37 | |||
The data type of the option value is an integer. | The data type of the option value is an integer. | |||
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(). | |||
By default, the value is set to 0, meaning that hot-standby | By default, the value is set to 0, meaning that hot-standby | |||
connection is disabled. | connection is disabled. | |||
When the application specifies the socket option to an unconnected | ||||
socket, an error code EOPNOTSUPP is returned to the application. | ||||
When there is no shim context associated with the socket, an error | ||||
code ENOENT is returned to the application. | ||||
For example, an application can request establishment of a hot- | For example, an application can request establishment of a hot- | |||
standby connection by using the socket option as follows: | standby connection by using the socket option as follows: | |||
int optval; | int optval; | |||
optval = 1; | optval = 1; | |||
setsockopt(fd, SOL_SHIM, SHIM_HOT_STANDBY, &optval, | setsockopt(fd, SOL_SHIM, SHIM_HOT_STANDBY, &optval, | |||
sizeof(optval)); | sizeof(optval)); | |||
For example, an application can get the option value by using the | For example, an application can get the option value by using the | |||
socket option as follows: | socket option as follows: | |||
int optval; | int optval; | |||
int len; | int len; | |||
len = sizeof(optval); | len = sizeof(optval); | |||
getsockopt(fd, SOL_SHIM, SHIM_HOT_STANDBY, &optval, &len); | getsockopt(fd, SOL_SHIM, SHIM_HOT_STANDBY, &optval, &len); | |||
5.4. SHIM_PATHEXPLORE | 5.4. SHIM_LOC_LOCAL_PREF | |||
The application may use this socket option to specify parameters | ||||
concerning path exploration. Path exploration is a procedure to find | ||||
an alternative locator pair to the current locator pair. As the REAP | ||||
specification defines, a peer may send Probe messages to find an | ||||
alternative locator pair. | ||||
The option is effective only when there is a shim context associated | ||||
with the socket. | ||||
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 | ||||
structure is defined in Section 7. | ||||
By default, the option value is set to NULL, meaning that the option | ||||
is disabled. | ||||
An error ENOENT is returned when there is no context associated with | The SHIM_LOC_LOCAL_PREF option is used to get or set preference for a | |||
source locator for outbound traffic within a given context. This | ||||
option is effective only when there is a shim context associated with | ||||
the socket. | the socket. | |||
For example, an application can set parameters for path exploration | The preference of a locator is defined by a combination of priority | |||
by using the socket option as follows. | and weight as per DNS SRV[RFC2782]. Note that the SHIM6 base | |||
protocol defines preference of locator in the same way. | ||||
struct shim6_pathexplore pe; | ||||
pe.pe_probenum = 4; /* times */ | ||||
pe.pe_keepaliveto = 10; /* seconds */ | ||||
pe.pe_initprobeto = 500; /* milliseconds */ | ||||
pe.pe_reserved = 0; | ||||
setsockopt(fd, SOL_SHIM, SHIM_PATHEXPLORE, &pe, sizeof(pe)); | ||||
For example, an application can get parameters for path exploration | ||||
by using the socket option as follows. | ||||
struct shim6_pathexplore pe; | ||||
int len; | ||||
len = sizeof(pe); | ||||
getsockopt(fd, SOL_SHIM, SHIM_PATHEXPLORE, &pe, &len); | ||||
5.5. SHIM_LOC_LOCAL_PREF | ||||
The SHIM_LOC_LOCAL_PREF option is used to get or set preferred | ||||
locator on local side within a given context. Hence this option is | ||||
effective only when there is a shim context associated with the | ||||
socket. | ||||
The data type of the option value is a pointer to a locator | The data type of the option value is a pointer to a locator | |||
information data structure which is defined in Section 7. | information data structure which 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. | |||
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 updates 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 is returned when there is no context associated with | When the application specifies the socket option to an unconnected | |||
the socket. | socket, an error code EOPNOTSUPP is returned to the application. | |||
When there is no shim context associated with the socket, an error | ||||
code ENOENT is returned to the application. | ||||
An error EINVALIDLOCATOR is returned when the validation of the | An error EINVALIDLOCATOR is returned when the validation of the | |||
specified locator failed. | specified locator fails. | |||
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; | |||
/* ...set the locator (ip6)... */ | /* ...set the locator (ip6)... */ | |||
memset(&lc, 0, sizeof(shim_locator)); | memset(&lc, 0, sizeof(shim_locator)); | |||
lc.lc_family = AF_INET6; /* IPv6 */ | lc.lc_family = AF_INET6; /* IPv6 */ | |||
lc.lc_ifidx = 0; | lc.lc_ifidx = 0; | |||
lc.lc_flags = 0; | lc.lc_flags = 0; | |||
lc.lc_preference = 255; | lc.lc_prio = 1; | |||
memcpy(lc.lc_addr, &ip6, sizeof(in6_addr)); | lc.lc_weight = 10; | |||
memcpy(&lc.lc_addr, &ip6, sizeof(in6_addr)); | ||||
setsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_PREF, &lc, | setsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_PREF, &lc, | |||
sizeof(optval)); | sizeof(optval)); | |||
For example, an application can get the preferred locator by using | For example, an application can get the preferred locator by using | |||
the socket option as follows. | the socket option as follows. | |||
struct shim_locator lc; | struct shim_locator lc; | |||
int len; | int len; | |||
len = sizeof(lc); | len = sizeof(lc); | |||
getsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_PREF, &lc, &len); | getsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_PREF, &lc, &len); | |||
5.6. SHIM_LOC_PEER_PREF | 5.5. SHIM_LOC_PEER_PREF | |||
The SHIM_LOC_PEER_PREF option is used to get or set preferred locator | The SHIM_LOC_PEER_PREF option is used to get or set preference of a | |||
on peer side within a given context. Hence this option is effective | destination locator for outbound traffic within a given context. | |||
only when there is a shim context associated with the socket. | This option is effective only when there is a shim context associated | |||
with the socket. | ||||
As defined earlier, the preference of a locator is defined by a | ||||
combination of priority and weight as per DNS SRV[RFC2782]. When | ||||
there are more than one candidate destination locators, the shim sub- | ||||
layer makes selection based on the priority and weight specified for | ||||
each locator. | ||||
The data type of the option value is a pointer to the locator | The data type of the option value is a pointer to the locator | |||
information data structure which is defined in Section 7. | information data structure which 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. | |||
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 is returned when there is no context associated with | When the application specifies the socket option to an unconnected | |||
the socket. | socket, an error code EOPNOTSUPP is returned to the application. | |||
When there is no shim context associated with the socket, an error | ||||
code ENOENT is returned to the application. | ||||
An error EINVALIDLOCATOR is 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.6. 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 | |||
an ancillary data object which can be accessed by recvmsg(). Hence | an ancillary data object which can be accessed by recvmsg(). This | |||
this option is effective only when there is a shim context associated | option is effective only when there is a shim context associated with | |||
with the socket. | the socket. | |||
The data type of the option value is integer. The option value | The data type of the option value is integer. The option value | |||
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 is returned when there is no context associated with | When the application specifies the socket option to an unconnected | |||
the socket. | socket, an error code EOPNOTSUPP is returned to the application. | |||
When there is no shim context associated with the socket, an error | ||||
code ENOENT is returned to the application. | ||||
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)); | |||
For example, an application can get the option value as follows. | For example, an application can get the option value as follows. | |||
int optval; | int optval; | |||
int len; | int len; | |||
len = sizeof(optval); | len = sizeof(optval); | |||
getsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_RECV, &optval, &len); | getsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_RECV, &optval, &len); | |||
5.8. SHIM_LOC_PEER_RECV | 5.7. SHIM_LOC_PEER_RECV | |||
The SHIM_LOC_PEER_RECV option is used to request the shim sub-layer | The SHIM_LOC_PEER_RECV option is used to request the shim sub-layer | |||
to store the source locator of the received IP packet in an ancillary | to store the source locator of the received IP packet in an ancillary | |||
data object which can be accessed by recvmsg(). Hence this option is | data object which can be accessed by recvmsg(). This option is | |||
effective only when there is a shim context associated with the | effective only when there is a shim context associated with the | |||
socket. | socket. | |||
The data type of the option value is integer. The option value | The data type of the option value is integer. The option value | |||
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 is returned when there is no context associated with | When the application specifies the socket option to an unconnected | |||
the socket. | socket, an error code EOPNOTSUPP is returned to the application. | |||
When there is no shim context associated with the socket, an error | ||||
code ENOENT is returned to the application. | ||||
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.8. 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. This option is effective only when there is | |||
there is a shim context associated with the socket. | a shim context associated with the socket. | |||
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 is returned when there is no context associated with | When the application specifies the socket option to an unconnected | |||
the socket. | socket, an error code EOPNOTSUPP is returned to the application. | |||
An error EINVALIDLOCATOR is returned when invalid locator is | When there is no shim context associated with the socket, an error | |||
code ENOENT is returned to the application. | ||||
An error EINVALIDLOCATOR is returned when an 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 */ | |||
memset(&locator, 0, sizeof(locator)); | memset(&locator, 0, sizeof(locator)); | |||
/* fill shim_locator data structure */ | /* fill shim_locator data structure */ | |||
locator.lc_family = AF_INET6; | locator.lc_family = AF_INET6; | |||
locator.lc_ifidx = 1; | locator.lc_ifidx = 1; | |||
locator.lc_flags = 0; | locator.lc_flags = 0; | |||
locator.lc_preference = 0; | locator.lc_prio = 0; | |||
locator.lc_weight = 0; | ||||
memcpy(&locator.lc_addr, &ia6, sizeof(ia6)); | memcpy(&locator.lc_addr, &ia6, sizeof(ia6)); | |||
setsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_SEND, &locator, | setsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_SEND, &locator, | |||
sizeof(locator)); | sizeof(locator)); | |||
For example, an application can get the preferred local locator by | For example, an application can get the preferred local locator by | |||
using the socket option as follows. | using the socket option as follows. | |||
struct shim_locator locator; | struct shim_locator locator; | |||
memset(&locator, 0, sizeof(locator)); | memset(&locator, 0, sizeof(locator)); | |||
getsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_SEND, &locator, | getsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_SEND, &locator, | |||
sizeof(locator)); | sizeof(locator)); | |||
/* check locator */ | /* check locator */ | |||
5.10. SHIM_LOC_PEER_SEND | 5.9. SHIM_LOC_PEER_SEND | |||
The SHIM_LOC_PEER_SEND option is used to request the shim sub-layer | The SHIM_LOC_PEER_SEND option is used to request the shim sub-layer | |||
to use a specific locator for the destination locator of IP packets | to use a specific locator for the destination locator of IP packets | |||
to be sent from the socket. Hence this option is effective only when | to be sent from the socket. This option is effective only when there | |||
there is a shim context associated with the socket. | is a shim context associated with the socket. | |||
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 is returned when there is no context associated with | When the application specifies the socket option to an unconnected | |||
the socket. | socket, an error code EOPNOTSUPP is returned to the application. | |||
An error EINVALIDLOCATOR when invalid locator is specified. | When there is no shim context associated with the socket, an error | |||
code ENOENT is returned to the application. | ||||
The usage of the option is as the same as that of SHIM_LOC_LOCAL_SEND | An error EINVALIDLOCATOR when invalid an locator is specified. | |||
The usage of the option is the same as that of SHIM_LOC_LOCAL_SEND | ||||
option. | option. | |||
5.11. SHIM_LOCLIST_LOCAL | 5.10. 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 | |||
socket. Hence this option is effective only when there is a shim | socket. This option is effective only when there is a shim context | |||
context associated with the socket. | associated with the socket. | |||
The data type of the option value is a pointer to the buffer in which | The data type of the option value is a pointer to the buffer in which | |||
a locator list is stored. See Section 7 for the data structure for | a locator list is stored. See Section 7 for the data structure for | |||
storing the locator information. By default, the option value is set | storing the locator information. By default, the option value is set | |||
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 to by the optval argument should be | |||
enough to store an array of locator information. The number of the | large enough to store an array of locator information. The number of | |||
locator information is not known beforehand. | the 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 to by the optval argument should contain an array of locator | |||
structures. | ||||
An error ENOENT is returned when there is no context associated with | When the application specifies the socket option to an unconnected | |||
the socket. | socket, an error code EOPNOTSUPP is returned to the application. | |||
An error EINVALIDLOCATOR is returned when the validation of the | When there is no shim context associated with the socket, an error | |||
specified locator failed. | code ENOENT is returned to the application. | |||
An error EINVALIDLOCATOR is returned when the validation of any of | ||||
the specified locators failed. | ||||
An error ETOOMANYLOCATORS is returned when the number of locators | An error ETOOMANYLOCATORS is returned when the number of locators | |||
specified exceeds the limit (SHIM_MAX_LOCATORS). | specified exceeds the limit (SHIM_MAX_LOCATORS), or when the size of | |||
the buffer provided by the application is not large enough to store | ||||
the locator list provided by the shim sub-layer. | ||||
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)); | |||
... | ... | |||
/* obtain local IP addresses from local interfaces */ | /* obtain local IP addresses from local interfaces */ | |||
... | ... | |||
/* first locator (an IPv6 address) */ | /* first locator (an IPv6 address) */ | |||
locators[0].lc_family = AF_INET6; | locators[0].lc_family = AF_INET6; | |||
locators[0].lc_ifidx = 0; | locators[0].lc_ifidx = 0; | |||
locators[0].lc_flags = 0; | locators[0].lc_flags = 0; | |||
locators[0].lc_preference = 1; | locators[0].lc_prio = 1; | |||
locators[0].lc_weight = 0; | ||||
memcpy(&locators[0].lc_addr, &sa6->sin6_addr, | memcpy(&locators[0].lc_addr, &sa6->sin6_addr, | |||
sizeof(sa6->sin6_addr)); | sizeof(sa6->sin6_addr)); | |||
... | ... | |||
/* second locator (an IPv4 address) */ | /* second locator (an IPv4 address) */ | |||
locators[1].lc_family = AF_INET; | locators[1].lc_family = AF_INET; | |||
locators[1].lc_ifidx = 0; | locators[1].lc_ifidx = 0; | |||
locators[1].lc_flags = 0; | locators[1].lc_flags = 0; | |||
locators[1].lc_preference = 0; | locators[1].lc_prio = 0; | |||
locators[1].lc_weight = 0; | ||||
memcpy(&locators[1].lc_addr, &sa->sin_addr, | memcpy(&locators[1].lc_addr, &sa->sin_addr, | |||
sizeof(sa->sin_addr)); | sizeof(sa->sin_addr)); | |||
setsockopt(fd, SOL_SHIM, SHIM_LOCLIST_LOCAL, locators, | setsockopt(fd, SOL_SHIM, SHIM_LOCLIST_LOCAL, locators, | |||
sizeof(locators)); | sizeof(locators)); | |||
For example, an application can get a list of locators that are | For example, an application can get a list of locators that are | |||
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]; | |||
memset(locators, 0, sizeof(locators)); | memset(locators, 0, sizeof(locators)); | |||
getsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_RECV, locators, | getsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_RECV, locators, | |||
sizeof(locators)); | sizeof(locators)); | |||
/* parse locators */ | /* parse locators */ | |||
... | ... | |||
5.12. SHIM_LOCLIST_PEER | 5.11. SHIM_LOCLIST_PEER | |||
The SHIM_LOCLIST_PEER option is used to get or set the locator list | The SHIM_LOCLIST_PEER option is used to get or set the locator list | |||
associated with the peer EID of the shim context associated with the | associated with the peer EID of the shim context associated with the | |||
socket. Hence this option is effective only when there is a shim | socket. This option is effective only when there is a shim context | |||
context associated with the socket. | associated 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 | |||
locator list is stored. See Section 7 for the data structure for | locator list is stored. See Section 7 for the data structure for | |||
storing the locator information. By default, the option value is set | storing the locator information. By default, the option value is set | |||
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 to by the optval argument should be | |||
enough to store an array of locator information. The number of the | large enough to store an array of locator information. The number of | |||
locator information is not known beforehand. | the 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 to by the optval argument should contain an array of locator | |||
list. | ||||
An error ENOENT is returned when there is no context associated with | When the application specifies the socket option to an unconnected | |||
the socket. | socket, an error code EOPNOTSUPP is returned to the application. | |||
An error EINVALIDLOCATOR is returned when the validation of the | When there is no shim context associated with the socket, an error | |||
specified locator failed. | code ENOENT is returned to the application. | |||
An error EINVALIDLOCATOR is returned when the validation of any of | ||||
the specified locators failed. | ||||
An error ETOOMANYLOCATORS is returned when the number of locators | An error ETOOMANYLOCATORS is returned when the number of locators | |||
specified exceeds the limit (SHIM_MAX_LOCATORS). | specified exceeds the limit (SHIM_MAX_LOCATORS), or when the size of | |||
the buffer provided by the application is not large enough to store | ||||
the locator list provided by the shim sub-layer. | ||||
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.12. 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 Send Timeout | |||
for application to detect failure. Hence this option is effective | value of the REAP protocol. This option is effective only when there | |||
only when there is a shim context associated with the socket. | 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 | When the application specifies the socket option to an unconnected | |||
configured in the REAP component, the REAP Keepalive message should | socket, an error code EOPNOTSUPP is returned to the application. | |||
be suppressed. | ||||
An error ENOENT is returned when there is no context associated with | When there is no shim context associated with the socket, an error | |||
the socket. | code ENOENT is returned to the application. | |||
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 24, line 39 | skipping to change at page 24, line 32 | |||
For example, an application can get the timeout value by using the | For example, an application can get the timeout value by using the | |||
socket option as follows. | socket option as follows. | |||
int optval; | int optval; | |||
int len; | int len; | |||
len = sizeof(optval); | len = sizeof(optval); | |||
getsockopt(fd, SOL_SHIM, SHIM_APP_TIMEOUT, &optval, &len); | getsockopt(fd, SOL_SHIM, SHIM_APP_TIMEOUT, &optval, &len); | |||
5.13. SHIM_PATHEXPLORE | ||||
The application may use this socket option to get or set parameters | ||||
concerning path exploration. Path exploration is a procedure to find | ||||
an alternative locator pair to the current locator pair. As the REAP | ||||
specification defines, a peer may send Probe messages to find an | ||||
alternative locator pair. | ||||
This option is effective only when there is a shim context associated | ||||
with the socket. | ||||
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 | ||||
structure is defined in Section 7. | ||||
By default, the option value is set to NULL, meaning that the option | ||||
is disabled. | ||||
When the application specifies the socket option to an unconnected | ||||
socket, an error code EOPNOTSUPP is returned to the application. | ||||
When there is no shim context associated with the socket, an error | ||||
code ENOENT is returned to the application. | ||||
For example, an application can set parameters for path exploration | ||||
by using the socket option as follows. | ||||
struct shim6_pathexplore pe; | ||||
pe.pe_probenum = 4; /* times */ | ||||
pe.pe_keepaliveto = 10; /* seconds */ | ||||
pe.pe_initprobeto = 500; /* milliseconds */ | ||||
pe.pe_reserved = 0; | ||||
setsockopt(fd, SOL_SHIM, SHIM_PATHEXPLORE, &pe, sizeof(pe)); | ||||
For example, an application can get parameters for path exploration | ||||
by using the socket option as follows. | ||||
struct shim6_pathexplore pe; | ||||
int len; | ||||
len = sizeof(pe); | ||||
getsockopt(fd, SOL_SHIM, SHIM_PATHEXPLORE, &pe, &len); | ||||
5.14. SHIM_DEFERRED_CONTEXT_SETUP | 5.14. SHIM_DEFERRED_CONTEXT_SETUP | |||
The SHIM_DEFERRED_CONTEXT_SETUP option is used to specify whether to | The SHIM_DEFERRED_CONTEXT_SETUP option is used to check whether | |||
enable deferred context setup or not. Deferred context setup means | deferred context setup is possible or not. Deferred context setup | |||
that the context is established in parallel with the data | means that the context is established in parallel with the data | |||
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). The option value 1 means that the shim | |||
meaning that the context setup is deferred. In order to disable the | sub-layer supports deferred context setup. | |||
option, the application should call setsockopt() with option value | ||||
set to 0. | ||||
Note that HIP does not support deferred context setup, by default. | ||||
When the application requests to enable deferred context setup in | ||||
case of HIP, it may mean that the application allows the system to | ||||
start TCP handshake even when there is no IPsec security association | ||||
with the peer. Such a usage of the SHIM_DEFERRED_CONTEXT_SETUP | ||||
option should be considered as experimental and left for further | ||||
study. | ||||
For example, an application can disable the deferred context setup by | ||||
using the socket option as follows: | ||||
int optval; | ||||
optval = 0; | ||||
setsockopt(fd, SOL_SHIM, SHIM_DEFERRED_CONTEXT_SETUP, | When the application specifies the socket option to an unconnected | |||
&optval, sizeof(optval)); | socket, an error code EOPNOTSUPP is returned to the application. | |||
For example, an application can get the option value as follows. | For example, an application can check whether deferred context setup | |||
is possible or not as follows: | ||||
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 shim sub-layer except for | All the socket options defined in this section except for the | |||
SHIM_HOT_STANDBY are applicable to both connected and unconnected | SHIM_DONTSHIM option are applicable to applications that use | |||
sockets. SHIM_HOT_STANDBY socket option is applicable only to | connected sockets. | |||
connected sockets. This is because the shim sub-layer cannot | ||||
initiate context establishment to create a hot standby connection | All the socket options defined in this section except for the | |||
when the peer's IP address is not known until the application writes | SHIM_ASSOCIATED, SHIM_DONTSHIM and SHIM_CONTEXT_DEFERRED_SETUP | |||
data to the unconnected socket. | options are effective only when there is a shim context associated | |||
with the 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 27, line 28 | skipping to change at page 28, line 5 | |||
padding if necessary | 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. | |||
When there is no shim context associated with the socket, the shim | ||||
sub-layer MUST return zero-filled locator information to the | ||||
application. | ||||
6.2. Set Locator for Outgoing Packet | 6.2. Set Locator for Outgoing Packet | |||
An application can specify the locators to be used for transmitting | An application can specify the locators to be used for transmitting | |||
an IP packet by sendmsg(). When the ancillary data of cmsg_type | an IP packet by sendmsg(). When the ancillary data of cmsg_type | |||
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. If the | |||
specified locator pair is verified, the shim sub-layer overrides the | ||||
Note that the effect is limited to the datagram transmitted by the | locator(s) of the outgoing IP packet. Note that the effect is | |||
sendmsg(). | limited to the datagram transmitted by the sendmsg(). | |||
If the specified locator pair is verified, the shim sub-layer | When there is no shim context associated with the socket, an error | |||
overrides the locators of the IP packet. | code ENOENT is returned to the application. | |||
An error EINVALIDLOCATOR is returned when validation of the specified | An error code EINVALIDLOCATOR is returned when validation of the | |||
locator failed. | specified locator fails. | |||
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 is returned when there is no context associated with | When there is no shim context associated with the socket, an error | |||
the socket. | code ENOENT is returned to the application. | |||
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. Applicability | |||
The shim sub-layer MAY provide notification about a locator change | ||||
within a multihome shim context to applications that have concern | ||||
with the context. Such a notification may be useful, for example, | ||||
for an application which is sensitive to the characteristics of the | ||||
current path. A locator change is caused when either of local or | ||||
peer's locator (or both) is changed. Note that locators discussed | ||||
here are the ones that appear in the IP packet header, and not the | ||||
ones that are included in the locator list. A locator change may | ||||
take place asynchronously. | ||||
The notification is handled as an out-of-band data by the | ||||
application. | ||||
1. Application calls the select() system call by setting non-NULL | ||||
value for the fourth argument. | ||||
2. When there is a notification, the application reads out-of-band | ||||
data from the socket by calling recvmsg(). | ||||
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 parses 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 | ||||
value of 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 any type | ||||
of socket (connected or unconnected, stream-oriented or datagram- | ||||
oriented). | ||||
6.5. Applicability | ||||
All the ancillary data for the shim sub-layer is applicable to both | All the ancillary data for the shim sub-layer is applicable to | |||
connected and unconnected sockets. | connected sockets. | |||
A care is needed when the SHIM_LOC_*_RECV socket option is used for | 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 shim sub-layer SHOULD provide the latest locator | received. The shim sub-layer SHOULD provide the latest locator | |||
information to the application in response to the SHIM_LOC_*_RECV | information to the application in response to the SHIM_LOC_*_RECV | |||
socket option. | socket option. | |||
7. Data Structures | 7. Data Structures | |||
This section data structures for the shim sub-layer. These data | This section data structures for the shim sub-layer. These data | |||
structures are either used as a parameter for setsockopt() or | structures are either used as a parameter for setsockopt() or | |||
getsockopt() (as mentioned in Section 5) or as a parameter for | getsockopt() (as mentioned in Section 5) or as a parameter for | |||
ancillary data to be processed by sendmsg() or recvmsg() (as | ancillary data to be processed by sendmsg() or 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_*_PREF, SHIM_LOC_*_SEND, and | |||
SHIM_LOCLIST_LOCAL, and SHIM_LOCLIST_PEER socket options need to | SHIM_LOCLIST_* socket options need to handle one or more locator | |||
handle one or more locator information. Locator information includes | information. Locator information includes not only the locator | |||
not only the locator itself but also additional information about the | itself but also additional information about the locator which is | |||
locator which is useful for locator management. A new data structure | useful for locator management. A new data structure is defined to | |||
is defined to serve as a placeholder for the locator information. | serve as a placeholder for the locator information. | |||
Figure 4 illustrates the data structure called shim_locator which | Figure 4 illustrates the data structure called shim_locator which | |||
stores a locator information. | stores a locator information. | |||
struct shim_locator { | struct shim_locator { | |||
uint8_t lc_family; /* address family */ | uint8_t lc_family; /* address family */ | |||
uint8_t lc_proto; /* protocol */ | uint8_t lc_proto; /* protocol */ | |||
uint16_t lc_port; /* port number */ | uint16_t lc_port; /* port number */ | |||
uint16_t lc_flags; /* flags */ | uint16_t lc_prio; /* preference value */ | |||
uint16_t lc_pref; /* preference value */ | uint16_t lc_weight; /* weight */ | |||
uint32_t lc_ifidx; /* interface index */ | uint32_t lc_ifidx; /* interface index */ | |||
struct in6_addr lc_addr; /* address */ | struct in6_addr lc_addr; /* address */ | |||
uint16_t lc_flags; /* flags */ | ||||
}; | }; | |||
Figure 4: shim locator structure | Figure 4: shim locator structure | |||
lc_family | lc_family | |||
Address family of the locator (e.g. AF_INET, AF_INET6). It is | Address family of the locator (e.g. AF_INET, AF_INET6). It is | |||
required that the parameter contains non-zero value indicating the | required that the parameter contains non-zero value indicating the | |||
exact address family of the locator. | exact address family of the locator. | |||
lc_proto | lc_proto | |||
Internet Protocol number for the protocol which is used to handle | Internet Protocol number for the protocol which is used to handle | |||
locator behind NAT. Typically, this value is set as UDP (17) when | locator behind NAT. Typically, this value is set as UDP (17) when | |||
the locator is a UDP encapsulation interface. | the locator is a UDP encapsulation interface. | |||
lc_port | lc_port | |||
Port number which is used for handling locator behind NAT. | Port number which is used for handling locator behind NAT. | |||
lc_flags | lc_prio | |||
Each bit of the flags represents a specific characteristics of the | The priority of the locator. The range is 0-65535. The lowest | |||
locator. Hash Based Address (HBA) is defined as 0x01. | priority value means the highest priority. | |||
Cryptographically Generated Address (CGA) is defined as 0x02. | lc_weight | |||
lc_pref | The weight value indicates a relative weight for locators with the | |||
Preference of the locator. The preference is represented by an | same priority value. The range is 0-65535. | |||
integer. | ||||
lc_ifidx | lc_ifidx | |||
Interface index of the network interface to which the locator is | Interface index of the network interface to which the locator is | |||
assigned. This field should be valid only in a read | assigned. This field should be valid only in a read | |||
(getsockopt()) operation. | (getsockopt()) operation. | |||
lc_addr | lc_addr | |||
Contains the locator. In the case where a locator whose size is | Contains the locator. In the case where a locator whose size is | |||
smaller than 16 bytes, an encoding rule should be provided for | smaller than 16 bytes, an encoding rule should be provided for | |||
each locator of a given address family. For instance, in case of | each locator of a given address family. For instance, in case of | |||
AF_INET (IPv4), the locator should be in the format of an IPv4- | AF_INET (IPv4), the locator should be in the format of an IPv4- | |||
mapped IPv6 address as defined in [RFC4291]. | mapped IPv6 address as defined in [RFC4291]. | |||
lc_flags | ||||
Each bit of the flags represents a specific characteristics of the | ||||
locator. Hash Based Address (HBA) is defined as 0x01. | ||||
Cryptographically Generated Address (CGA) is defined as 0x02. | ||||
7.1.1. Handling Locator behind NAT | 7.1.1. Handling Locator behind NAT | |||
Note that the locator information MAY contain a locator behind a | Note that the locator information MAY contain a locator behind a | |||
Network Address Translator (NAT). Such a situation may arise when | Network Address Translator (NAT). Such a situation may arise when | |||
the host is behind the NAT and uses a local address as a source | the host is behind the NAT and uses a local address as a source | |||
locator to communicate with the peer. Note that a NAT traversal | locator to communicate with the peer. Note that a NAT traversal | |||
mechanism for HIP is defined, which allows HIP host to tunnel control | mechanism for HIP is defined, which allows HIP host to tunnel control | |||
and data traffic over UDP[I-D.ietf-hip-nat-traversal]. Note also | and data traffic over UDP[I-D.ietf-hip-nat-traversal]. Note also | |||
that the locator behind NAT is not necessarily an IPv4 address but it | that the locator behind NAT is not necessarily an IPv4 address but it | |||
skipping to change at page 31, line 18 | skipping to change at page 31, line 18 | |||
/* copy the private IPv4 address to the ia6 as an IPv4-mapped | /* copy the private IPv4 address to the ia6 as an IPv4-mapped | |||
IPv6 address */ | IPv6 address */ | |||
memset(&locator, 0, sizeof(locator)); | memset(&locator, 0, sizeof(locator)); | |||
/* fill shim_locator data structure */ | /* fill shim_locator data structure */ | |||
locator.lc_family = AF_INET; | locator.lc_family = AF_INET; | |||
locator.lc_proto = IPPROTO_UDP; | locator.lc_proto = IPPROTO_UDP; | |||
locator.lc_port = 50500; | locator.lc_port = 50500; | |||
locator.lc_flags = 0; | locator.lc_flags = 0; | |||
locator.lc_pref = 0; | locator.lc_prio = 0; | |||
locator.lc_weight = 0; | ||||
locator.lc_ifidx = 3; | locator.lc_ifidx = 3; | |||
memcpy(&locator.lc_addr, &ia6, sizeof(ia6)); | memcpy(&locator.lc_addr, &ia6, sizeof(ia6)); | |||
setsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_SEND, &locator, | setsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_SEND, &locator, | |||
sizeof(locator)); | sizeof(locator)); | |||
Figure 5: Handling locator behind NAT | Figure 5: Handling locator behind NAT | |||
7.2. Path Exploration Parameter | 7.2. Path Exploration Parameter | |||
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 | |||
This section gives system requirements posed by the sockets API | As addressed in Section 5, most of the socket options and ancillary | |||
defined in this document. There exist requirements for the system | data defined in this document are applicable to connected sockets. | |||
(kernel) to maintain the association between sockets and shim | It is assumed that the kernel is capable of maintaining the | |||
contexts. | association between a connected socket and a shim context. This | |||
requirement is considered to be reasonable because a pair of source | ||||
As addressed in Section 5, all the socket options and ancillary data | and destination IP addresses is bound to a connected socket. | |||
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 | ||||
that use connected sockets. This is because the kernel can maintain | ||||
the association between a connected socket and a shim context in a | ||||
static manner because a connected socket is bound to a source and | ||||
destination IP addresses (identifiers). The kernel should be able to | ||||
identify shim context associated with a connected socket by searching | ||||
shim context keyed by the pair of source and destination identifiers. | ||||
However, this is not the case for unnconnected sockets. The kernel | ||||
needs to dynamically resolve association between an unconnected | ||||
socket and a shim context, if any, upon packet processing. As to | ||||
outbound packet processing, the kernel needs to check if there is any | ||||
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 shim sub-layer performs packet | ||||
processing taking the application's preference into account. Note | ||||
that the shim sub-layer should be able to backtrack the socket from | ||||
which the user data was originated. As to inbound packet processing, | ||||
the 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 shim sub-layer socket options, the shim sub-layer | ||||
processes the IP packet as requested (e.g., set locator information | ||||
of received packet in the ancillary data). | ||||
9. Relation to Existing Sockets API Extensions | 9. Relation to Existing Sockets API Extensions | |||
This section explains relation between the sockets API defined in | This section explains relation between the sockets API defined in | |||
this document and the existing sockets API extensions. | this document and the existing sockets API extensions. | |||
As mentioned in Section 5, the basic assumption is that the existing | As mentioned in Section 5, the basic assumption is that the existing | |||
sockets API continues to work above the shim sub-layer. This means | sockets API continues to work above the shim sub-layer. This means | |||
that, the existing sockets API deals with identifiers, and the | that, the existing sockets API deals with identifiers, and the | |||
sockets API defined in this document deals with locators. | sockets API defined in this document deals with locators. | |||
SHIM_LOC_LOCAL_PREF and SHIM_LOC_PEER_PREF socket options are | SHIM_LOC_LOCAL_SEND and SHIM_LOC_PEER_SEND socket options are | |||
semantically similar to the IPV6_PKTINFO socket API in the sense that | semantically similar to the IPV6_PKTINFO socket API in the sense that | |||
both provide a means for application to set the source IP address of | both provide a means for application to set the source IP address of | |||
outbound IP packets. | outbound IP packets. | |||
SHIM_LOC_LOCAL_RECV and SHIM_LOC_PEER_RECV socket options are | SHIM_LOC_LOCAL_RECV and SHIM_LOC_PEER_RECV socket options are | |||
semantically similar to the IP_RECVDSTADDR and IPV6_PKTINFO socket | semantically similar to the IP_RECVDSTADDR and IPV6_PKTINFO socket | |||
APIs in the sense that both provides a means for application to get | APIs in the sense that both provides a means for application to get | |||
the source and/or destination IP address of inbound IP packets. | the source and/or destination IP address of inbound IP packets. | |||
getsockname() and getpeername() enable application to get 'name' of | getsockname() and getpeername() enable application to get 'name' of | |||
skipping to change at page 34, line 48 | skipping to change at page 34, line 24 | |||
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 | |||
a case, the socket handler should inform the shim sub-layer that | a case, the socket handler should inform the shim sub-layer that | |||
context forking is required. In SHIM6, when a context is forked, an | context forking is required. In SHIM6, when a context is forked, an | |||
unique identifier called Forked Instance Identifier (FII) is assigned | unique identifier called Forked Instance Identifier (FII) is assigned | |||
to the 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 shim sub- | was specified. The forked context is maintained by the shim sub- | |||
layer during the lifetime of associated socket instance. When the | layer during the lifetime of associated socket instance. When the | |||
socket is closed, the shim sub-layer SHOULD delete associated | socket is closed, the shim sub-layer SHOULD delete associated | |||
context. When a forked context is torn down, the SHIM6 | ||||
implementation should notify the peer about the deletion of forked | ||||
context. | context. | |||
When the application specifies SHIM_LOC_*_SEND specifying a different | ||||
source or destination locator which does not have the highest | ||||
priority and weight specified by the SHIM_LOC_*_PREF, the shim sub- | ||||
layer SHOULD supersede the request made by SHIM_LOC_*_SEND over the | ||||
preference specified by SHIM_LOC_*_PREF. | ||||
When the peer provides preferences of the locators (e.g., a SHIM6 | ||||
peer may send a locator with a Locator Preferences Option) which | ||||
conflict with preference specified by the applications either by | ||||
SHIM_LOC_PEER_SEND or SHIM_LOC_PEER_PREF, the shim sub-layer SHOULD | ||||
supersede the preference made by the application over the preference | ||||
specified by the peer. | ||||
10.2. Incompatiblility between IPv4 and IPv6 | 10.2. Incompatiblility between IPv4 and IPv6 | |||
The shim sub-layer performs identifier/locator adaptation. | The shim sub-layer performs identifier/locator adaptation. | |||
Therefore, in some cases, the whole IP header can be replaced with | Therefore, in some cases, the whole IP header can be replaced with | |||
new IP header of a different address family (e.g. conversion from | 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 | 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 | the conversion with minimum impact. Note that this issue is common | |||
in other protocol conversion such as SIIT[RFC2765]. | in other protocol conversion techniques | |||
[RFC2765][I-D.ietf-behave-v6v4-xlate]. | ||||
As addressed in the SIIT specification, some of the features (IPv6 | As studied in the previous works on protocol | |||
routing headers, hop-by-hop extension headers, or destination | conversion[RFC2765][I-D.ietf-behave-v6v4-xlate], some of the features | |||
(IPv6 routing headers, hop-by-hop extension headers, and destination | ||||
headers) from IPv6 are not convertible to IPv4. In addition, notion | headers) from IPv6 are not convertible to IPv4. In addition, notion | |||
of source routing is not exactly the same in IPv4 and IPv6. This | 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 | 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 | locator. It is ffs exactly how the shim sub-layer should behave in | |||
such erroneous cases. | such erroneous cases. | |||
11. IANA Considerations | 11. IANA Considerations | |||
This document contains no IANA consideration. | This document contains no IANA consideration. | |||
skipping to change at page 36, line 12 | skipping to change at page 35, line 45 | |||
any of the local interface. If not, the shim sub-layer MUST reject | any of the local interface. If not, the shim sub-layer MUST reject | |||
the request and return an error message with the EINVALIDLOCATOR code | the request and return an error message with the EINVALIDLOCATOR code | |||
to the application. If the locator is confirmed to be available, the | to the application. If the locator is confirmed to be available, the | |||
shim sub-layer SHOULD initiate the procedure to update the locator | shim sub-layer SHOULD initiate the procedure to update the locator | |||
list. | list. | |||
Use of the following socket options and ancillary data may require | Use of the following socket options and ancillary data may require | |||
treatment of unknown source locator: | treatment of unknown source locator: | |||
o SHIM_LOC_LOCAL_SEND | o SHIM_LOC_LOCAL_SEND | |||
o SHIM_LOC_LOCAL_PREF | o SHIM_LOC_LOCAL_PREF | |||
o SHIM_LOC_LIST_LOCAL | o SHIM_LOCLIST_LOCAL | |||
13.1.2. Treatment of Unknown Destination Locator | 13.1.2. Treatment of Unknown Destination Locator | |||
If the shim sub-layer turns out to be SHIM6, the SHIM6 implementation | If the shim sub-layer turns out to be SHIM6, the SHIM6 implementation | |||
MUST reject the request for using unknown destination locator. | MUST reject the request for using unknown destination locator. | |||
If the shim sub-layer turns out to be HIP, the HIP implementation MAY | If the shim sub-layer turns out to be HIP, the HIP implementation MAY | |||
accept the request for using unknown destination locator. | accept the request for using unknown destination locator. | |||
Use of the following socket options and ancillary data may require | Use of the following socket options and ancillary data may require | |||
treatment of unknown destination locator: | treatment of unknown destination locator: | |||
o SHIM_LOC_PEER_SEND | o SHIM_LOC_PEER_SEND | |||
o SHIM_LOC_PEER_PREF | o SHIM_LOC_PEER_PREF | |||
o SHIM_LOC_LIST_PEER | o SHIM_LOCLIST_PEER | |||
14. Changes | 14. Changes | |||
14.1. Changes from version 00 to version 01 | 14.1. 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. | |||
skipping to change at page 38, line 14 | skipping to change at page 38, line 4 | |||
14.11. Changes from version 10 to version 11 | 14.11. 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 Relaxed applicability of the socket options. | o Relaxed applicability of the socket options. | |||
o Relaxed applicability of the ancillary data. | o Relaxed applicability of the ancillary data. | |||
o Added notification about locator change. | o Added notification about locator change. | |||
14.12. Changes from version 11 to version 12 | 14.12. Changes from version 11 to version 12 | |||
o Reflected comments from Brian Karpenter. | ||||
o Reflected comments from Michael Scharf. | ||||
o Reflected comments from Brian Karpenter | 14.13. Changes from version 12 to version 13 | |||
o Reflected comments from Michael Scharf | ||||
o Reflected comments from Sebastien Barre. | ||||
o Removed the description about the notification from the shim sub- | ||||
layer to applications. | ||||
o Narrowed down the scope of the applicability of the socket options | ||||
and the ancillary data. | ||||
15. 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 helpful | |||
improve this document: Samu Varjonen and Dmitriy Kuptsov. | comments to the document: Samu Varjonen, Dmitriy Kuptsov, Brian | |||
Carpenter, Michael Scharf, and Sebastien Barre | ||||
16. References | 16. References | |||
16.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. | |||
skipping to change at page 39, line 8 | skipping to change at page 39, line 7 | |||
[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. | |||
16.2. Informative References | 16.2. Informative References | |||
[I-D.ietf-behave-v6v4-xlate] | ||||
Li, X., Bao, C., and F. Baker, "IP/ICMP Translation | ||||
Algorithm", draft-ietf-behave-v6v4-xlate-05 (work in | ||||
progress), December 2009. | ||||
[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] | [I-D.ietf-shim6-applicability] | |||
Abley, J., Bagnulo, M., and A. Garcia-Martinez, | Abley, J., Bagnulo, M., and A. Garcia-Martinez, | |||
"Applicability Statement for the Level 3 Multihoming Shim | "Applicability Statement for the Level 3 Multihoming Shim | |||
Protocol (Shim6)", draft-ietf-shim6-applicability-04 (work | Protocol (Shim6)", draft-ietf-shim6-applicability-04 (work | |||
in progress), November 2009. | 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. | |||
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for | ||||
specifying the location of services (DNS SRV)", RFC 2782, | ||||
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, | |||
June 2009. | June 2009. | |||
Appendix A. Context Forking | Appendix A. Context Forking | |||
End of changes. 106 change blocks. | ||||
324 lines changed or deleted | 343 lines changed or added | |||
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |