[要約] RFC 6316は、マルチホーミングシムのためのソケットアプリケーションプログラムインターフェース（API）に関する仕様です。このRFCの目的は、マルチホーミング環境でのアプリケーション開発をサポートするために、統一されたAPIを提供することです。
Internet Engineering Task Force (IETF) M. Komu
Request for Comments: 6316 Aalto University
Category: Informational M. Bagnulo
ISSN: 2070-1721 UC3M
K. Slavov
S. Sugimoto, Ed.
Ericsson
July 2011
Sockets Application Program Interface (API) for Multihoming Shim
マルチホミングシム用のソケットアプリケーションプログラムインターフェイス（API）
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.
このドキュメントは、マルチホームシム層のSockets API拡張機能を指定します。APIは、高度なロケーター管理のために、アプリケーションとマルチホームシム層との相互作用を可能にすること、および障害検出とパス探索に関する情報へのアクセスを目指しています。
This document is based on an assumption that a multihomed host is equipped with a conceptual sub-layer (hereafter called "shim sub-layer") inside the IP layer that maintains mappings between identifiers and locators. Examples of the shim are Shim6 and the Host Identity Protocol (HIP).
このドキュメントは、マルチホームホストには、識別子とロケーター間のマッピングを維持するIPレイヤー内の概念サブレイヤー（以下「シムサブレイヤー」と呼ばれる）を装備しているという仮定に基づいています。SHIMの例は、SHIM6とホストIDプロトコル（HIP）です。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6316.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6316で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction ....................................................3
2. Requirements Language ...........................................4
3. Terminology and Background ......................................4
4. System Overview .................................................7
5. Requirements ....................................................8
6. Socket Options for Multihoming Shim Sub-Layer ..................10
6.1. SHIM_ASSOCIATED ...........................................14
6.2. SHIM_DONTSHIM .............................................15
6.3. SHIM_HOT_STANDBY ..........................................16
6.4. SHIM_LOC_LOCAL_PREF .......................................17
6.5. SHIM_LOC_PEER_PREF ........................................18
6.6. SHIM_LOC_LOCAL_RECV .......................................19
6.7. SHIM_LOC_PEER_RECV ........................................20
6.8. SHIM_LOC_LOCAL_SEND .......................................20
6.9. SHIM_LOC_PEER_SEND ........................................22
6.10. SHIM_LOCLIST_LOCAL .......................................23
6.11. SHIM_LOCLIST_PEER ........................................25
6.12. SHIM_APP_TIMEOUT .........................................26
6.13. SHIM_PATHEXPLORE .........................................27
6.14. SHIM_DEFERRED_CONTEXT_SETUP ..............................28
6.15. Applicability ............................................28
6.16. Error Handling ...........................................29
7. Ancillary Data for Multihoming Shim Sub-Layer ..................29
7.1. Get Locator from Incoming Packet ..........................30
7.2. Set Locator for Outgoing Packet ...........................30
7.3. Notification from Application to Multihoming Shim
Sub-Layer .................................................31
7.4. Applicability .............................................31
8. Data Structures ................................................32
8.1. Data Structure for Locator Information ....................32
8.1.1. Handling Locator behind NAT ........................33
8.2. Path Exploration Parameter ................................34
8.3. Feedback Information ......................................35
9. System Requirements ............................................36
10. Relation to Existing Sockets API Extensions ...................36
11. Operational Considerations ....................................37
11.1. Conflict Resolution ......................................37
11.2. Incompatibility between IPv4 and IPv6 ....................38
12. IANA Considerations ...........................................38
13. Protocol Constant .............................................38
14. Security Considerations .......................................38
14.1. Treatment of Unknown Locator .............................39
14.1.1. Treatment of Unknown Source Locator ...............39
14.1.2. Treatment of Unknown Destination Locator ..........39
15. Acknowledgments ...............................................40
16. References ....................................................40
16.1. Normative References .....................................40
16.2. Informative References ...................................41
Appendix A. Context Forking .......................................42
This document defines sockets API extensions by which upper-layer protocols may be informed about and control the way in which a multihoming shim sub-layer in the IP layer manages the dynamic choice of locators. Initially, the multihoming shim sub-layer refers to Shim6 and/or HIP, but it is defined generically.
このドキュメントでは、上層層プロトコルにIPレイヤーのマルチホームシムサブレイヤーがロケーターの動的な選択を管理する方法を通知し、制御できるソケットAPI拡張機能を定義します。当初、マルチホームシムサブレイヤーはShim6および/または股関節を指しますが、一般的に定義されています。
The role of the multihoming shim sub-layer (hereafter called "shim sub-layer" in this document) is to avoid impacts to upper-layer protocols that may be caused when the endhost changes its attachment point to the Internet -- for instance, in the case of a rehoming event under the multihomed environment. There is, however, a need for an API in the cases where 1) the upper-layer protocol is particularly sensitive to impacts, or 2) the upper-layer protocol wants to benefit from better knowledge of what is going on underneath.
マルチホミングシムサブレイヤー（このドキュメントの「シムサブレイヤー」と呼ばれる以下）の役割は、エンドホストがインターネットに添付ファイルポイントを変更したときに引き起こされる可能性のある上層層プロトコルへの影響を避けることです。マルチホーム環境の下での再ホームイベントの場合。ただし、1）上層層プロトコルが影響に特に敏感である場合、または2）上層層プロトコルは、下で何が起こっているかについてのより良い知識から利益を得たい場合、APIが必要です。
There are various kinds of technologies that aim to solve the same issue (the multihoming issue). Note that there will be conflict when more than one shim sub-layer is active at the same time. The assumption made in this document is that there is only a single shim sub-layer (HIP or Shim6) activated on the system.
同じ問題を解決することを目的としたさまざまな種類のテクノロジーがあります（マルチホームの問題）。複数のシムサブレイヤーが同時にアクティブである場合、競合が発生することに注意してください。このドキュメントで行われた仮定は、システム上でアクティブ化された単一のシムサブレイヤー（股関節またはSHIM6）のみがあることです。
The target readers of this document are application programmers who develop application software that may benefit greatly from multihomed environments. In addition, this document aims to provide necessary information for developers of shim protocols to implement APIs for enabling advanced locator management.
このドキュメントのターゲットリーダーは、マルチホーム環境から大きな利益を得る可能性のあるアプリケーションソフトウェアを開発するアプリケーションプログラマーです。さらに、このドキュメントは、高度なロケーター管理を可能にするためにAPIを実装するために、SHIMプロトコルの開発者に必要な情報を提供することを目的としています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
This section provides terminology used in this document. Basically, most of the terms used in this document are taken from the following documents:
このセクションでは、このドキュメントで使用される用語を提供します。基本的に、このドキュメントで使用されている用語のほとんどは、次のドキュメントから取得されます。
o Shim6 Protocol Specification [RFC5533]
o SHIM6プロトコル仕様[RFC5533]
o HIP Architecture [RFC4423]
o ヒップアーキテクチャ[RFC4423]
o Reachability Protocol (REAP) [RFC5534]
o リーチ可能性プロトコル（REAP）[RFC5534]
In this document, the term "IP" refers to both IPv4 and IPv6, unless the protocol version is specifically mentioned. The following are definitions of terms frequently used in this document:
このドキュメントでは、「IP」という用語は、プロトコルバージョンが具体的に言及されていない限り、IPv4とIPv6の両方を指します。以下は、このドキュメントで頻繁に使用される用語の定義です。
o Endpoint Identifier (EID) -- The identifier used by the application to specify the endpoint of a given communication. Applications may handle EIDs in various ways, such as long-lived connections, callbacks, and referrals [SHIM6-APP-REFER].
o エンドポイント識別子（EID） - 特定の通信のエンドポイントを指定するためにアプリケーションで使用される識別子。アプリケーションは、長命の接続、コールバック、紹介[SHIM6-APP-REFER]など、さまざまな方法でEIDを処理する場合があります。
* In the case of Shim6, an identifier called a ULID (Upper-Layer Identifier) serves as an EID. A ULID is chosen from locators available on the host.
* SHIM6の場合、尿素（上層識別子）と呼ばれる識別子がEIDとして機能します。ホストで利用可能なロケーターからulidが選択されます。
* In the case of HIP, an identifier called a Host Identifier serves as an EID. A Host Identifier is derived from the public key of a given host. For the sake of backward compatibility with the sockets API, the Host Identifier is represented in the form of a hash of a public key.
* 股関節の場合、ホスト識別子と呼ばれる識別子がEIDとして機能します。ホスト識別子は、特定のホストの公開鍵から派生しています。Sockets APIとの後方互換性のために、ホスト識別子は公開キーのハッシュの形で表されます。
* Note that the EID appears in the standard sockets API as an address, and does not appear in the extensions defined in this document, which only concern locators.
* EIDは標準ソケットAPIにアドレスとして表示され、このドキュメントで定義されている拡張機能には表示されないことに注意してください。
o Locator - The IP address actually used to deliver IP packets. Locators are present in the source and destination fields of the IP header of a packet on the wire. A locator as discussed in this document could be either an IPv4 address or an IPv6 address. Note that HIP can handle both IPv4 and IPv6 locators, whereas Shim6 can handle only IPv6 locators. For the HIP case, a locator can be a private IPv4 address when the host is behind a NAT. Section 8.1.1 gives a detailed description about the handling of a locator behind a NAT.
o ロケーター - 実際にはIPパケットを配信するために使用されていました。ロケーターは、ワイヤー上のパケットのIPヘッダーのソースおよび宛先フィールドに存在します。このドキュメントで説明されているロケーターは、IPv4アドレスまたはIPv6アドレスのいずれかです。HIPはIPv4とIPv6ロケーターの両方を処理できるのに対し、SHIM6はIPv6ロケーターのみを処理できることに注意してください。HIPケースの場合、ホストがNATの背後にある場合、ロケーターはプライベートIPv4アドレスになります。セクション8.1.1は、NATの背後にあるロケーターの取り扱いに関する詳細な説明を示しています。
* List of locators - A list of locators associated with an EID. There are two lists of locators stored in a given context. One is associated with the local EID, and the other is associated with the remote EID. As defined in [RFC5533], the list of locators associated with an EID 'A' is denoted as Ls(A).
* ロケーターのリスト - EIDに関連するロケーターのリスト。特定のコンテキストに保存されているロケーターの2つのリストがあります。1つは地元のEIDに関連付けられており、もう1つはリモートEIDに関連付けられています。[RFC5533]で定義されているように、EID 'A'に関連付けられたロケーターのリストはLS（a）として示されます。
* Preferred locator - The (source/destination) locator currently used to send packets within a given context.
* 優先ロケーター - 特定のコンテキスト内でパケットを送信するために現在使用されている（ソース/宛先）ロケーター。
* Unknown locator - Any locator that does not appear in the locator list of the shim context associated with the socket. When there is no shim context associated with the socket, any source and/or destination locator requested by the application is considered to be an unknown locator.
* 不明なロケーター - ソケットに関連付けられたシムコンテキストのロケーターリストに表示されないロケーター。ソケットに関連付けられたシムコンテキストがない場合、アプリケーションによって要求されたソースおよび/または宛先ロケーターは不明なロケーターと見なされます。
* Valid locator - A valid locator means that the locator is considered to be valid in the security sense. More specifically, the validity indicates whether the locator is part of a Hash-Based Address (HBA) set [RFC5535].
* 有効なロケーター - 有効なロケーターとは、ロケーターがセキュリティの意味で有効であると見なされることを意味します。より具体的には、有効性は、ロケーターがハッシュベースのアドレス（HBA）セット[RFC5535]の一部であるかどうかを示します。
* Verified locator - A verified locator means that the locator is considered to be reachable according to the result of a REAP return routability check. Note that the verification applies only to the peer's locator.
* 検証済みのロケーター - 検証済みのロケーターとは、REAPリターンルー上のチェックの結果に応じて、ロケーターが到達可能であると見なされることを意味します。検証はピアのロケーターにのみ適用されることに注意してください。
o Shim - The conceptual sub-layer inside the IP layer. This sub-layer maintains mappings between EIDs and locators. An EID can be associated with more than one locator at a time when the host is multihomed. The term "shim" does not refer to a specific protocol but refers to the conceptual sub-layer inside the IP layer.
o シム - IPレイヤー内の概念サブレイヤー。このサブ層は、EIDとロケーター間のマッピングを維持します。EIDは、ホストがマルチホームされているときに、複数のロケーターに関連付けることができます。「シム」という用語は、特定のプロトコルを指すのではなく、IPレイヤー内の概念サブレイヤーを指します。
o Identifier/locator adaptation - The adaptation performed at the shim sub-layer. This adaptation may end up re-writing the source and/or destination addresses of an IP packet. In the outbound packet processing, the EID pair is converted to the associated locator pair. In the inbound packet processing, the locator pair is converted to the EID pair.
o 識別子/ロケーターの適応 - シムサブレイヤーで実行される適応。この適応は、IPパケットのソースおよび/または宛先アドレスを書き直すことになります。アウトバウンドパケット処理では、EIDペアは関連するロケーターペアに変換されます。インバウンドパケット処理では、ロケーターペアがEIDペアに変換されます。
o Context - The state information shared by a given pair of peers. Context stores a binding between the EID and associated locators. Contexts are maintained by the shim sub-layer. Deferred context setup is a scenario where a context is established after the communication starts. Deferred context setup is possible if the ULID is routable, such as in the case of Shim6.
o コンテキスト - 特定のピアが共有する状態情報。コンテキストは、EIDと関連するロケーターの間にバインディングを保存します。コンテキストは、シムサブレイヤーによって維持されます。延期されたコンテキストのセットアップは、通信が開始された後にコンテキストが確立されるシナリオです。SHIM6の場合のように、ulidがルーティング可能である場合、延期されたコンテキストのセットアップが可能です。
o Reachability detection - The procedure to check reachability between a given locator pair.
o 到達可能性検出 - 特定のロケーターペア間の到達可能性を確認する手順。
o Path - The sequence of routers that an IP packet goes through to reach the destination.
o パス - IPパケットが宛先に到達するために通過するルーターのシーケンス。
o Path exploration - The procedure to explore available paths for a given set of locator pairs.
o パス探索 - 特定のロケーターペアセットで利用可能なパスを探索する手順。
o Outage - The incident that prevents IP packets flowing from the source locator to the destination locator. When there is an outage, it means that there is no reachability between a given locator pair. The outage may be caused by various reasons, such as a shortage of network resources, congestion, and human error (faulty operation).
o 停止 - ソースロケーターから宛先ロケーターに流れるIPパケットを防ぐインシデント。停止がある場合、特定のロケーターペアの間に到達可能性がないことを意味します。停止は、ネットワークリソースの不足、混雑、人為的エラー（操作の故障）など、さまざまな理由によって引き起こされる場合があります。
o Working address pair - Considered to be "working" if the packet can safely travel from the source to the destination, where the packet contains the first address from the pair as the source address and the second address from the pair as the destination address. If reachability is confirmed in both directions, the address pair is considered to be working bi-directionally.
o ワーキングアドレスペア - パケットがソースから宛先まで安全に移動できる場合は「動作」と見なされます。パケットには、ペアの最初のアドレスがソースアドレスとして、ペアの2番目のアドレスが宛先アドレスとして含まれています。到達可能性が両方向に確認された場合、アドレスペアは双方向で動作していると見なされます。
o Reachability Protocol (REAP) - The protocol for detecting failure and exploring reachability in a multihomed environment. REAP is defined in [RFC5534].
o Reachability Protocol（REAP） - マルチホーム環境での障害を検出し、到達可能性を調査するためのプロトコル。REAPは[RFC5534]で定義されています。
In this document, syntax and semantics of the API are given in the same way as in the Portable Operating System Interface (POSIX) standard [POSIX]. The API specifies how to use ancillary data (aka cmsg) to access the locator information with 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 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).
このドキュメントでは、APIの構文とセマンティクスは、ポータブルオペレーティングシステムインターフェイス（POSIX）標準[POSIX]と同じ方法で与えられます。APIは、補助データ（別名CMSG）を使用して、recvmsg（）および/またはsendmsg（）i/o呼び出しでロケーター情報にアクセスする方法を指定します。APIはC言語で説明されており、データ型はPOSIX形式で定義されています。intn_tは、正確にnビット（int16_tなど）の署名された整数を意味し、uintn_tは正確なnビット（uint32_tなど）の符号なし整数を意味します。
The distinction between "connected" sockets and "unconnected" sockets is important when discussing the applicability of the sockets API defined in this document. A connected socket is bound to a given peer, whereas an unconnected socket is not bound to any specific peers. A TCP socket becomes a connected socket when the TCP connection establishment is completed. UDP sockets are unconnected, unless the application uses the connect() system call.
「接続された」ソケットと「接続されていない」ソケットの区別は、このドキュメントで定義されているソケットAPIの適用性を議論する際に重要です。接続されたソケットは特定のピアにバインドされますが、接続されていないソケットは特定のピアにバインドされていません。TCP接続の確立が完了すると、TCPソケットが接続されたソケットになります。アプリケーションがConnect（）システムコールを使用しない限り、UDPソケットは接続されていません。
Figure 1 illustrates the system overview. The shim sub-layer and REAP component exist inside the IP layer. Applications use the sockets API defined in this document to interface with the shim sub-layer and the transport layer for locator management, failure detection, and path exploration.
図1は、システムの概要を示しています。ShimサブレイヤーとREAPコンポーネントは、IPレイヤー内に存在します。アプリケーションは、このドキュメントで定義されているソケットAPIを使用して、ロケーター管理、故障検出、およびパス探索のために、シムサブレイヤーと輸送層とのインターフェースを使用します。
It is also possible that the shim sub-layer interacts with the transport layer; however, such an interaction is outside the scope of this document.
シムサブレイヤーが輸送層と相互作用する可能性もあります。ただし、このような相互作用は、このドキュメントの範囲外です。
+------------------------+
| Application |
+------------------------+
^ ^
~~~~~~~~~~~~~|~Socket Interface|~~~~~~~~~~~~~~
| v
+-----------|------------------------------+
| | Transport Layer |
+-----------|------------------------------+
^ |
+-------------|-----|-------------------------------------+
| v v |
| +-----------------------------+ +----------+ | IP
| | Shim |<----->| REAP | | Layer
| +-----------------------------+ +----------+ |
| ^ ^ |
+-----------------------|----------------------|----------+
v v
+------------------------------------------+
| Link Layer |
+------------------------------------------+
Figure 1: System Overview
図1：システムの概要
The following is a list of requirements from applications:
以下は、アプリケーションからの要件のリストです。
o Turn on/off shim. An application should be able to request to turn on or turn off the multihoming support by the shim layer:
o オン/オフシムをオン/オフします。アプリケーションは、シムレイヤーによるマルチホームサポートをオンまたはオフにすることを要求できる必要があります。
* Apply shim. The application should be able to explicitly request that the shim sub-layer apply multihoming support.
* シムを適用します。アプリケーションは、シムサブレイヤーがマルチホームサポートを適用することを明示的に要求できるはずです。
* Don't apply shim. The application should be able to request that the shim sub-layer not apply the multihoming support but apply normal IP processing at the IP layer.
* シムを適用しないでください。アプリケーションは、Shimサブレイヤーがマルチホームサポートを適用せず、IPレイヤーで通常のIP処理を適用することを要求できる必要があります。
* Note that this function is also required by other types of multihoming mechanisms, such as the Stream Control Transmission Protocol (SCTP) and multipath TCP, to avoid potential conflict with the shim sub-layer.
* この関数は、SHIMサブレイヤーとの潜在的な競合を回避するために、ストリーム制御伝送プロトコル（SCTP）やマルチパスTCPなどの他のタイプのマルチホームメカニズムによっても必要であることに注意してください。
o Locator management.
o ロケーター管理。
* It should be possible to set a preferred source and/or destination locator within a given context.
* 指定されたコンテキスト内で優先ソースおよび/または宛先ロケーターを設定することができるはずです。
* It should be possible to get a preferred source and/or destination locator within a given context.
* 特定のコンテキスト内で優先ソースおよび/または宛先ロケーターを取得することができるはずです。
* It should be possible to set a list of source and/or destination locators within a given context: Ls(local) and Ls(remote).
* 特定のコンテキスト内でソースおよび/または宛先ロケーターのリストを設定することが可能である必要があります：LS（ローカル）およびLS（リモート）。
* It should be possible to get a list of source and/or destination locators within a given context: Ls(local) and Ls(remote).
* 特定のコンテキスト内でソースおよび/または宛先ロケーターのリストを取得することが可能である必要があります：LS（ローカル）およびLS（リモート）。
o Notification from applications and upper-layer protocols to the shim sub-layer about the status of the communication. The notification occurs in an event-based manner. Applications and/or upper-layer protocols may provide positive feedback or negative feedback to the shim sub-layer. Note that these types of feedback are mentioned in [RFC5534]:
o アプリケーションおよび上層層プロトコルから、通信のステータスに関するShimサブレイヤーへの通知。通知は、イベントベースの方法で発生します。アプリケーションおよび/または上層層プロトコルは、Shimサブレイヤーに肯定的なフィードバックまたは否定的なフィードバックを提供する場合があります。これらのタイプのフィードバックは[RFC5534]に記載されていることに注意してください。
* Applications and/or upper-layer protocols (e.g., TCP) may provide positive feedback to the shim sub-layer informing that the communication is going well.
* アプリケーションおよび/または上層層プロトコル（TCPなど）は、通信が順調に進んでいることを知らせるShimサブ層に肯定的なフィードバックを提供する場合があります。
* Applications and/or upper-layer protocols (e.g., TCP) may provide negative feedback to the shim sub-layer informing that the communication status is not satisfactory. TCP may detect a problem when it does not receive any expected ACK message from the peer. The REAP module may be triggered by the negative feedback and invoke the path exploration procedure.
* アプリケーションおよび/または上層層プロトコル（TCPなど）は、通信ステータスが満足のいくものではないことを通知するシムサブレイヤーに否定的なフィードバックを提供する場合があります。TCPは、ピアから予想されるACKメッセージを受信しない場合、問題を検出する場合があります。REAPモジュールは、負のフィードバックによってトリガーされ、パス探索手順を呼び出す場合があります。
o Feedback from applications to the shim sub-layer. Applications should be able to inform the shim sub-layer of the timeout values for detecting failures, sending keepalives, and starting the exploration procedure. In particular, applications should be able to suppress keepalives.
o アプリケーションからシムサブレイヤーへのフィードバック。アプリケーションは、障害を検出し、キープライブを送信し、探索手順を開始するためのタイムアウト値をシムサブレイヤーに通知できる必要があります。特に、アプリケーションはKeepaliveを抑制できるはずです。
o Hot-standby. Applications may request the shim sub-layer for a hot-standby capability. This means that alternative paths are known to be working in advance of a failure detection. In such a case, it is possible for the shim sub-layer to immediately replace the current locator pair with an alternative locator pair.
o ホットスタンドビー。アプリケーションは、Hot-Standby機能のためにShimサブレイヤーを要求する場合があります。これは、代替パスが障害検出の前に動作していることが知られていることを意味します。そのような場合、Shimサブレイヤーが現在のロケーターペアを代替ロケーターペアにすぐに置き換えることができます。
o Eagerness for locator exploration. An application should be able to inform the shim sub-layer of how aggressively it wants the REAP mechanism to perform a path exploration (e.g., by specifying the number of concurrent attempts of discovery of working locator pairs) when an outage occurs on the path between the locator pair in use.
o ロケーター探査への熱意。アプリケーションは、Shimサブレイヤーに、Path ExplorationをREAPメカニズムに実行することがどれほど積極的であるかを通知できる必要があります（たとえば、作業ロケーターペアの発見の同時試みの数を指定することにより）。使用中のロケーターペア。
o Providing locator information to applications. An application should be able to obtain information about the locator pair that was actually used to send or receive packets.
o ロケーター情報をアプリケーションに提供します。アプリケーションは、実際にパケットを送信または受信するために使用されたロケーターペアに関する情報を取得できる必要があります。
* For inbound traffic, the application may be interested in the locator pair that was actually used to receive the packet.
* インバウンドトラフィックの場合、アプリケーションは、実際にパケットを受信するために使用されたロケーターペアに関心がある場合があります。
* For outbound traffic, the application may be interested in the locator pair that was actually used to transmit the packet.
* アウトバウンドトラフィックの場合、アプリケーションは、実際にパケットの送信に使用されたロケーターペアに関心がある場合があります。
In this way, applications may have additional control of the locator management. For example, an application becomes capable of verifying if its preference for a locator is actually applied to the flow or not.
このようにして、アプリケーションはロケーター管理をさらに制御できる場合があります。たとえば、アプリケーションは、ロケーターの好みが実際にフローに適用されるかどうかを確認できるようになります。
o Applications should be able to know if the shim sub-layer supports deferred context setup or not.
o アプリケーションは、シムサブレイヤーが繰延コンテキストのセットアップをサポートするかどうかを知ることができるはずです。
o An application should be able to know if the communication is now being served by the shim sub-layer or not.
o アプリケーションは、コミュニケーションがShimサブレイヤーによって提供されているかどうかを知ることができるはずです。
o An application should be able to use a common interface to access an IPv4 locator and an IPv6 locator.
o アプリケーションは、共通インターフェイスを使用してIPv4ロケーターとIPv6ロケーターにアクセスできる必要があります。
In this section, socket options that are specific to the shim sub-layer are defined.
このセクションでは、シムサブレイヤーに固有のソケットオプションが定義されています。
Table 1 shows a list of the socket options that are specific to the shim sub-layer. All of these socket options are defined at the level SOL_SHIM. When an application uses one of the socket options by getsockopt() or setsockopt(), the second argument MUST be set to SOL_SHIM.
表1は、シムサブレイヤーに固有のソケットオプションのリストを示しています。これらのソケットオプションはすべて、レベルSOL_SHIMで定義されています。アプリケーションがgetSockopt（）またはsetSockopt（）によってソケットオプションの1つを使用する場合、2番目の引数をsol_shimに設定する必要があります。
The first column of Table 1 gives the name of the option. The second column indicates whether the value for the socket option can be read by getsockopt(), and the third column indicates whether the value for the socket option can be written by setsockopt(). The fourth column provides a brief description of the socket option. The fifth column shows the type of data structure specified along with the socket option. By default, the data structure type is an integer.
表1の最初の列は、オプションの名前を示しています。2番目の列は、Socketオプションの値をGetSockopt（）で読み取ることができるかどうかを示し、3番目の列はSetSockopt（）でStockeオプションの値を記述できるかどうかを示します。4番目の列は、ソケットオプションの簡単な説明を提供します。5番目の列は、ソケットオプションとともに指定されたデータ構造のタイプを示しています。デフォルトでは、データ構造タイプは整数です。
+-----------------------------+-----+-----+-----------------+-------+
| optname | get | set | description | dtype |
+-----------------------------+-----+-----+-----------------+-------+
| SHIM_ASSOCIATED | o | | Get the | int |
| | | | parameter that | |
| | | | indicates | |
| | | | whether the | |
| | | | socket is | |
| | | | associated (1) | |
| | | | with any shim | |
| | | | context or not | |
| | | | (0). | |
| SHIM_DONTSHIM | o | o | Get or set the | int |
| | | | parameter that | |
| | | | indicates | |
| | | | whether or not | |
| | | | to employ | |
| | | | multihoming | |
| | | | support by the | |
| | | | shim sub-layer. | |
| SHIM_HOT_STANDBY | o | o | Get or set the | int |
| | | | parameter to | |
| | | | request the | |
| | | | shim sub-layer | |
| | | | to prepare a | |
| | | | hot-standby | |
| | | | connection. | |
| SHIM_LOC_LOCAL_PREF | o | o | Set the | Note |
| | | | preference | 1 |
| | | | value for a | |
| | | | source locator | |
| | | | for outbound | |
| | | | traffic. Get | |
| | | | the preferred | |
| | | | locator for the | |
| | | | source locator | |
| | | | for outbound | |
| | | | traffic. | |
| SHIM_LOC_PEER_PREF | o | o | Set the | Note |
| | | | preference | 1 |
| | | | value for a | |
| | | | destination | |
| | | | locator for | |
| | | | outbound | |
| | | | traffic. Get | |
| | | | the preferred | |
| | | | locator for the | |
| | | | destination | |
| | | | locator for | |
| | | | outbound | |
| | | | traffic. | |
| SHIM_LOC_LOCAL_RECV | o | o | Request the | int |
| | | | shim sub-layer | |
| | | | to store the | |
| | | | destination | |
| | | | locator of the | |
| | | | received IP | |
| | | | packet in an | |
| | | | ancillary data | |
| | | | object. | |
| SHIM_LOC_PEER_RECV | o | o | Request the | int |
| | | | shim sub-layer | |
| | | | to store the | |
| | | | source locator | |
| | | | of the received | |
| | | | IP packet in an | |
| | | | ancillary data | |
| | | | object. | |
| SHIM_LOC_LOCAL_SEND | o | o | Get or set the | Note |
| | | | source locator | 1 |
| | | | of outgoing IP | |
| | | | packets. | |
| SHIM_LOC_PEER_SEND | o | o | Get or set the | Note |
| | | | destination | 1 |
| | | | locator of | |
| | | | outgoing IP | |
| | | | packets. | |
| SHIM_LOCLIST_LOCAL | o | o | Get or set the | Note |
| | | | list of | 2 |
| | | | locators | |
| | | | associated with | |
| | | | the local EID. | |
| SHIM_LOCLIST_PEER | o | o | Get or set the | Note |
| | | | list of | 2 |
| | | | locators | |
| | | | associated with | |
| | | | the peer's EID. | |
| SHIM_APP_TIMEOUT | o | o | Get or set the | int |
| | | | Send Timeout | |
| | | | value of REAP. | |
| SHIM_PATHEXPLORE | o | o | Get or set | Note |
| | | | parameters for | 3 |
| | | | path | |
| | | | exploration and | |
| | | | failure | |
| | | | detection. | |
| SHIM_CONTEXT_DEFERRED_SETUP | o | | Get the | int |
| | | | parameter that | |
| | | | indicates | |
| | | | whether | |
| | | | deferred | |
| | | | context setup | |
| | | | is supported or | |
| | | | not. | |
+-----------------------------+-----+-----+-----------------+-------+
Table 1: Socket Options for Multihoming Shim Sub-Layer
表1：マルチホミングシムサブレイヤーのソケットオプション
Note 1: Pointer to a shim_locator as defined in Section 8.
注1：セクション8で定義されているshim_locatorへのポインター。
Note 2: Pointer to an array of shim_locator data.
注2：shim_locatorデータの配列へのポインタ。
Note 3: Pointer to a shim_pathexplore as defined in Section 8.
注3：セクション8で定義されているshim_pathexploreへのポインター。
Figure 2 illustrates how the shim-specific socket options fit into the system model of sockets API. The figure shows that the shim sub-layer and the additional protocol components (IPv4 and IPv6) below the shim sub-layer are new to the system model. As previously mentioned, all the shim-specific socket options are defined at the SOL_SHIM level. This design choice brings the following advantages:
図2は、シム固有のソケットオプションがソケットAPIのシステムモデルにどのように適合するかを示しています。この図は、ShimサブレイヤーとShimサブレイヤーの下の追加のプロトコルコンポーネント（IPv4およびIPv6）がシステムモデルに新しくなっていることを示しています。前述のように、すべてのシム固有のソケットオプションは、sol_shimレベルで定義されています。この設計の選択により、次の利点があります。
1. The existing sockets APIs continue to work at the layer above the shim sub-layer. That is, those legacy APIs handle IP addresses as identifiers.
1. 既存のソケットAPIは、シムサブレイヤーの上のレイヤーで動作し続けます。つまり、これらのレガシーAPIは識別子としてIPアドレスを処理します。
2. With newly defined socket options for the shim sub-layer, the application obtains additional control of locator management.
2. Shimサブレイヤーの新たに定義されたソケットオプションを使用すると、アプリケーションはロケーター管理の追加制御を取得します。
3. The shim-specific socket options can be kept independent from address family (IPPROTO_IP or IPPROTO_IPV6) and transport protocol (IPPROTO_TCP or IPPROTO_UDP) settings.
3. SHIM固有のソケットオプションは、アドレスファミリ（IPPROTO_IPまたはIPPROTO_IPV6）および輸送プロトコル（IPPROTO_TCPまたはIPPROTO_UDP）の設定から独立して保つことができます。
s1 s2 s3 s4
| | | |
+----------------|--|-------|--|----------------+
| +-------+ +-------+ |
| IPPROTO_TCP | TCP | | UDP | |
| +-------+ +-------+ |
| | \ / | |
| | ----- | |
| | / \ | |
| +------+ +------+ |
| IPPROTO_IP | IPv4 | | IPv6 | IPPROTO_IPV6 |
| +------+ +------+ |
| \ / SOL_SOCKET
| +--------\-------/--------+ |
| SOL_SHIM | shim | |
| +--------/-------\--------+ |
| / \ |
| +------+ +------+ |
| | IPv4 | | IPv6 | |
| +------+ +------+ |
| | | |
+------------------|----------|-----------------+
| |
IPv4 IPv6
Datagram Datagram
Figure 2: System Model of Sockets API with Shim Sub-Layer
図2：Shimサブレイヤーを使用したソケットAPIのシステムモデル
The SHIM_ASSOCIATED option is used to check whether or not the socket is associated with any shim context.
shim_associatedオプションは、ソケットがShimコンテキストに関連付けられているかどうかを確認するために使用されます。
This option is meaningful when the locator information of the received IP packet does not tell whether or not the identifier/ locator adaptation is performed. Note that the EID pair and the locator pair may be identical in some cases.
このオプションは、受信したIPパケットのロケーター情報が識別子/ロケーターの適応が実行されているかどうかを知らない場合に意味があります。EIDペアとロケーターペアは、場合によっては同一であることに注意してください。
Note that the socket option is read-only, and the option value can be read by getsockopt(). The result (0/1/2) is set in the option value (the fourth argument of getsockopt()).
ソケットオプションは読み取り専用であり、Option値はgetSockopt（）によって読み取ることができることに注意してください。結果（0/1/2）は、オプション値（getSockopt（）の4番目の引数）で設定されます。
When the application specifies the socket option to an unconnected socket, error code EOPNOTSUPP is returned to the application.
アプリケーションが接続されていないソケットにソケットオプションを指定すると、エラーコードEOPNOTSUPPがアプリケーションに返されます。
The data type of the option value is an integer. The option value indicates the presence of shim context. A return value of 1 means that the socket is associated with a shim context at the shim sub-layer. A return value of 0 indicates that there is no shim context associated with the socket. A return value of 2 means that it is not known whether or not the socket is associated with a shim context, and this MUST be returned only when the socket is unconnected. In other words, the returned value MUST be 0 or 1 when the socket is connected.
オプション値のデータ型は整数です。オプション値は、シムコンテキストの存在を示します。1の戻り値は、ソケットがシムサブレイヤーのシムコンテキストに関連付けられていることを意味します。0の戻り値は、ソケットに関連付けられたシムコンテキストがないことを示します。2の戻り値は、ソケットがシムコンテキストに関連付けられているかどうかがわからないことを意味し、これはソケットが接続されていない場合にのみ返さなければなりません。つまり、ソケットを接続するときは、返された値は0または1でなければなりません。
For example, the option can be used by the application as follows:
たとえば、オプションは次のようにアプリケーションで使用できます。
int optval;
int optlen = sizeof(optval);
getsockopt(fd, SOL_SHIM, SHIM_ASSOCIATED, &optval, &optlen);
getSockopt（fd、sol_shim、shim_associated、＆optval、＆optlen）;
The SHIM_DONTSHIM option is used to request that the shim layer not provide the multihoming support for the communication established over the socket.
shim_dontshimオプションは、Shimレイヤーがソケットに確立された通信のマルチホームサポートを提供しないことを要求するために使用されます。
The data type of the option value is an integer, and it takes 0 or 1. An option value of 0 means that the shim sub-layer is employed if available. An option value of 1 means that the application does not want the shim sub-layer to provide the multihoming support for the communication established over the socket.
オプション値のデータ型は整数であり、0または1が必要です。オプション値は、可能な場合はシムサブレイヤーが使用されることを意味します。1のオプション値は、アプリケーションがShimサブレイヤーにソケットを介して確立された通信のマルチホームサポートを提供することを望まないことを意味します。
The default value is set to 0, which means that the shim sub-layer performs identifier/locator adaptation if available.
デフォルト値は0に設定されています。つまり、Shimサブレイヤーは、利用可能な場合は識別子/ロケーターの適応を実行します。
Any attempt to disable the multihoming shim support MUST be made by the application before the socket is connected. If an application makes such an attempt for a connected socket, error code EOPNOTSUPP MUST be returned.
ソケットが接続される前に、マルチホームシムサポートを無効にする試みは、アプリケーションによって行う必要があります。アプリケーションが接続されたソケットをこのような試みにした場合、エラーコードEOPNOTSUPPを返す必要があります。
For example, an application can request that the system not apply the multihoming support as follows:
たとえば、アプリケーションは、システムが次のようにマルチホームサポートを適用しないことを要求できます。
int optval;
int optval;
optval = 1;
optval = 1;
setsockopt(fd, SOL_SHIM, SHIM_DONTSHIM, &optval, sizeof(optval));
For example, the application can check the option value as follows:
たとえば、アプリケーションは次のようにオプション値を確認できます。
int optval; int len;
int optval;int len;
len = sizeof(optval);
getsockopt(fd, SOL_SHIM, SHIM_DONTSHIM, &optval, &len);
getSockopt（fd、sol_shim、shim_dontshim、＆optval、＆len）;
The SHIM_HOT_STANDBY option is used to control whether or not the shim sub-layer employs a hot-standby connection for the socket. A hot-standby connection is an alternative working locator pair to the current locator pair. This option is effective only when there is a shim context associated with the socket.
SHIM_HOT_STANDBYオプションは、SHIMサブレイヤーがソケットのホットスタンドバイ接続を使用しているかどうかを制御するために使用されます。Hot-Standby接続は、現在のロケーターペアの代替作業ロケーターペアです。このオプションは、ソケットに関連付けられたシムコンテキストがある場合にのみ有効です。
The data type of the option value is an integer.
オプション値のデータ型は整数です。
The option value can be set by setsockopt().
オプション値は、setSockopt（）によって設定できます。
The option value can be read by getsockopt().
オプション値は、getSockopt（）によって読み取ることができます。
By default, the value is set to 0, meaning that hot-standby connection is disabled.
デフォルトでは、値は0に設定されています。つまり、Hot-Standby接続が無効になっています。
When the application specifies the socket option to an unconnected socket, error code EOPNOTSUPP is returned to the application.
アプリケーションが接続されていないソケットにソケットオプションを指定すると、エラーコードEOPNOTSUPPがアプリケーションに返されます。
When there is no shim context associated with the socket, error code ENOENT is returned to the application.
ソケットに関連付けられたシムコンテキストがない場合、エラーコードenoentがアプリケーションに返されます。
For example, an application can request establishment of a hot-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, sizeof(optval));
SetSockopt（FD、SOL_SHIM、SHIM_HOT_STANDBY、＆OPTVAL、SIZEOF（OptVal））;
For example, an application can get the option value by using the socket option as follows:
たとえば、アプリケーションは、次のようにソケットオプションを使用してオプション値を取得できます。
int optval; int len;
int optval;int len;
len = sizeof(optval);
getsockopt(fd, SOL_SHIM, SHIM_HOT_STANDBY, &optval, &len);
getSockopt（fd、sol_shim、shim_hot_standby、＆optval、＆len）;
The SHIM_LOC_LOCAL_PREF option is used to set the preference value for a source locator for outbound traffic, or to get the preference value of the source locator for outbound traffic that has the highest preference value.
SHIM_LOC_LOCAL_PREFオプションは、アウトバウンドトラフィックのソースロケーターの優先値を設定するか、最高の優先値を持つアウトバウンドトラフィックのソースロケーターの優先値を取得するために使用されます。
This option is effective only when there is a shim context associated with the socket.
このオプションは、ソケットに関連付けられたシムコンテキストがある場合にのみ有効です。
By default, the option value is set to NULL, meaning that the option is disabled.
デフォルトでは、オプション値はnullに設定されています。つまり、オプションは無効になっています。
The preference of a locator is defined by a combination of priority and weight as per DNS SRV [RFC2782]. Note that the Shim6 base protocol defines the preference of a locator in the same way.
ロケーターの選好は、DNS SRV [RFC2782]に従って優先度と重量の組み合わせによって定義されます。SHIM6ベースプロトコルは、同じ方法でロケーターの選好を定義することに注意してください。
The data type of the option value is a pointer to the shim_locator information data structure as defined in Section 8.1.
オプション値のデータ型は、セクション8.1で定義されているshim_locator情報データ構造へのポインターです。
When an application specifies the socket option to an unconnected socket, error code EOPNOTSUPP is returned to the application.
アプリケーションが接続されていないソケットのソケットオプションを指定すると、エラーコードEOPNOTSUPPがアプリケーションに返されます。
When there is no shim context associated with the socket, error code ENOENT is returned to the application.
ソケットに関連付けられたシムコンテキストがない場合、エラーコードenoentがアプリケーションに返されます。
Error code EINVALIDLOCATOR is returned when the validation of the specified locator fails.
エラーコードEINVALIDLOCATORは、指定されたロケーターの検証が失敗したときに返されます。
An application can set the preference value for a source locator for outbound traffic by setsockopt() with the socket option. Note that lc_ifidx and lc_flags (as defined in Section 8.1) have no effect in a set operation. Below is an example of such a set operation.
アプリケーションは、ソケットオプションを使用して、SetSockopt（）によってアウトバウンドトラフィックのソースロケーターの優先値を設定できます。LC_IFIDXおよびLC_FLAGS（セクション8.1で定義されている）は、設定操作に効果がないことに注意してください。以下は、このようなセット操作の例です。
struct shim_locator lc; struct in6_addr ip6;
struct shim_locator lc;struct in6_addr ip6;
/* ...set the locator (ip6)... */
memset(&lc, 0, sizeof(shim_locator));
lc.lc_family = AF_INET6; /* IPv6 */
lc.lc_ifidx = 0;
lc.lc_flags = 0;
lc.lc_prio = 1;
lc.lc_weight = 10;
memcpy(&lc.lc_addr, &ip6, sizeof(in6_addr));
setsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_PREF, &lc, sizeof(optval));
SetSockopt（FD、SOL_SHIM、SHIM_LOC_LOCAL_PREF、＆LC、SIZEOF（OptVal））;
An application can get the source locator for outbound traffic that has the highest preference value by using the socket option. Below is an example of such a get operation.
アプリケーションは、ソケットオプションを使用して、優先順位が最も高いアウトバウンドトラフィック用のソースロケーターを取得できます。以下は、このようなGET操作の例です。
struct shim_locator lc; int len;
struct shim_locator lc;int len;
len = sizeof(lc);
getsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_PREF, &lc, &len);
getSockopt（fd、sol_shim、shim_loc_local_pref、＆lc、＆len）;
The SHIM_LOC_PEER_PREF option is used to set the preference value for a destination locator for outbound traffic, or to get the preference value of the destination locator for outbound traffic that has the highest preference value.
SHIM_LOC_PEER_PREFオプションは、アウトバウンドトラフィック用の宛先ロケーターの優先値を設定するか、最高の優先値を持つアウトバウンドトラフィックの宛先ロケーターの優先値を取得するために使用されます。
This option is effective only when there is a shim context associated with the socket.
このオプションは、ソケットに関連付けられたシムコンテキストがある場合にのみ有効です。
By default, the option value is set to NULL, meaning that the option is disabled.
デフォルトでは、オプション値はnullに設定されています。つまり、オプションは無効になっています。
As defined earlier, the preference of a locator is defined by a combination of priority and weight as per DNS SRV [RFC2782]. When there is more than one candidate destination locator, the shim sub-layer makes a selection based on the priority and weight specified for each locator.
前に定義されたように、ロケーターの好みは、DNS SRV [RFC2782]に従って優先度と重量の組み合わせによって定義されます。複数の候補の宛先ロケーターがある場合、Shimサブレイヤーは、各ロケーターに指定された優先度と重量に基づいて選択を行います。
The data type of the option value is a pointer to the shim_locator information data structure as defined in Section 8.1.
オプション値のデータ型は、セクション8.1で定義されているshim_locator情報データ構造へのポインターです。
When the application specifies the socket option to an unconnected socket, error code EOPNOTSUPP is returned to the application.
アプリケーションが接続されていないソケットにソケットオプションを指定すると、エラーコードEOPNOTSUPPがアプリケーションに返されます。
When there is no shim context associated with the socket, error code ENOENT is returned to the application.
ソケットに関連付けられたシムコンテキストがない場合、エラーコードenoentがアプリケーションに返されます。
Error code EINVALIDLOCATOR is returned when the validation of the requested locator fails.
エラーコードeinvalidLocatorは、要求されたロケーターの検証が失敗したときに返されます。
Error code EUNREACHABLELOCATOR is returned when the requested locator is determined to be unreachable according to a reachability check.
エラーコードeunReachableLocatorは、要求されたロケーターが到達可能性チェックに従って到達不可能であると判断されたときに返されます。
The usage of the option is the same as that of SHIM_LOC_LOCAL_PREF.
オプションの使用法は、shim_loc_local_prefの使用と同じです。
The SHIM_LOC_LOCAL_RECV option can be used to request that the shim sub-layer store the destination locator of the received IP packet in an ancillary data object that can be accessed by recvmsg(). This option is effective only when there is a shim context associated with the socket.
shim_loc_local_recvオプションを使用して、shimサブレイヤーに、recvmsg（）でアクセスできる補助データオブジェクトに受信したIPパケットの宛先ロケーターを保存するように要求できます。このオプションは、ソケットに関連付けられたシムコンテキストがある場合にのみ有効です。
The data type of the option value is an integer. The option value MUST be binary (0 or 1). By default, the option value is set to 0, meaning that the option is disabled.
オプション値のデータ型は整数です。オプション値はバイナリ（0または1）でなければなりません。デフォルトでは、オプション値は0に設定されています。つまり、オプションは無効になっています。
An application can set the option value by setsockopt().
アプリケーションは、SetSockopt（）によってオプション値を設定できます。
An application can get the option value by getsockopt().
アプリケーションは、getSockopt（）によってオプション値を取得できます。
See Section 7 for the procedure to access locator information stored in the ancillary data objects.
補助データオブジェクトに保存されているロケーター情報にアクセスする手順については、セクション7を参照してください。
When the application specifies the socket option to an unconnected socket, error code EOPNOTSUPP is returned to the application.
アプリケーションが接続されていないソケットにソケットオプションを指定すると、エラーコードEOPNOTSUPPがアプリケーションに返されます。
When there is no shim context associated with the socket, error code ENOENT is returned to the application.
ソケットに関連付けられたシムコンテキストがない場合、エラーコードenoentがアプリケーションに返されます。
For example, an application can request the shim sub-layer to store a destination locator by using the socket option as follows:
たとえば、アプリケーションは、ソケットオプションを次のように使用して、Shimサブレイヤーに宛先ロケーターを保存するように要求できます。
int optval;
int optval;
optval = 1;
optval = 1;
setsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_RECV, &optval, sizeof(optval));
SetSockopt（FD、SOL_SHIM、SHIM_LOC_LOCAL_RECV、＆OPTVAL、SIZEOF（OptVal））;
For example, an application can get the option value as follows:
たとえば、アプリケーションは次のようにオプション値を取得できます。
int optval; int len;
int optval;int len;
len = sizeof(optval);
getsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_RECV, &optval, &len);
getSockopt（fd、sol_shim、shim_loc_local_recv、＆optval、＆len）;
The SHIM_LOC_PEER_RECV option is used to request that the shim sub-layer store the source locator of the received IP packet in an ancillary data object that can be accessed by recvmsg(). This option is effective only when there is a shim context associated with the socket.
SHIM_LOC_PEER_RECVオプションは、shimサブレイヤーが、Recvmsg（）でアクセスできる補助データオブジェクトに受信したIPパケットのソースロケーターを保存するように要求するために使用されます。このオプションは、ソケットに関連付けられたシムコンテキストがある場合にのみ有効です。
The data type of the option value is an integer. The option value MUST be binary (0 or 1). By default, the option value is set to 0, meaning that the option is disabled.
オプション値のデータ型は整数です。オプション値はバイナリ（0または1）でなければなりません。デフォルトでは、オプション値は0に設定されています。つまり、オプションは無効になっています。
The option value can be set by setsockopt().
オプション値は、setSockopt（）によって設定できます。
The option value can be read by getsockopt().
オプション値は、getSockopt（）によって読み取ることができます。
See Section 7 for the procedure to access locator information stored in the ancillary data objects.
補助データオブジェクトに保存されているロケーター情報にアクセスする手順については、セクション7を参照してください。
When the application specifies the socket option to an unconnected socket, error code EOPNOTSUPP is returned to the application.
アプリケーションが接続されていないソケットにソケットオプションを指定すると、エラーコードEOPNOTSUPPがアプリケーションに返されます。
When there is no shim context associated with the socket, error code ENOENT is returned to the application.
ソケットに関連付けられたシムコンテキストがない場合、エラーコードenoentがアプリケーションに返されます。
The usage of the option is the same as that of the SHIM_LOC_LOCAL_RECV option.
オプションの使用法は、shim_loc_local_recvオプションの使用と同じです。
The SHIM_LOC_LOCAL_SEND option is used to request that the shim sub-layer use a specific locator as the source locator for the IP packets to be sent from the socket. This option is effective only when there is a shim context associated with the socket.
SHIM_LOC_LOCAL_SENDオプションは、SHIMサブレイヤーがソケットから送信されるIPパケットのソースロケーターとして特定のロケーターを使用することを要求するために使用されます。このオプションは、ソケットに関連付けられたシムコンテキストがある場合にのみ有効です。
The data type of the option value is a pointer to the shim_locator data structure.
オプション値のデータ型は、shim_locatorデータ構造へのポインターです。
An application can set the local locator by setsockopt(), providing a locator that is stored in a shim_locator data structure. When a zero-filled locator is specified, the pre-existing setting of the local locator is inactivated.
アプリケーションは、setsockopt（）によってローカルロケーターを設定し、shim_locatorデータ構造に保存されているロケーターを提供できます。ゼロで充填されたロケーターが指定されている場合、ローカルロケーターの既存の設定が不活性化されます。
An application can get the local locator by getsockopt().
アプリケーションは、GetSockopt（）によってローカルロケーターを取得できます。
When the application specifies the socket option to an unconnected socket, error code EOPNOTSUPP is returned to the application.
アプリケーションが接続されていないソケットにソケットオプションを指定すると、エラーコードEOPNOTSUPPがアプリケーションに返されます。
When there is no shim context associated with the socket, error code ENOENT is returned to the application.
ソケットに関連付けられたシムコンテキストがない場合、エラーコードenoentがアプリケーションに返されます。
Error code EINVALIDLOCATOR is returned when an invalid locator is specified.
エラーコードEINVALIDLOCATORは、無効なロケーターが指定されているときに返されます。
For example, an application can request the shim sub-layer to use a specific local locator by using the socket option as follows:
たとえば、アプリケーションは、次のようにソケットオプションを使用して、特定のローカルロケーターを使用するようにシムサブレイヤーに要求できます。
struct shim_locator locator; struct in6_addr ia6;
struct shim_locatorロケーター;struct in6_addr ia6;
/* an IPv6 address preferred for the source locator is copied
to the parameter ia6 */
memset(&locator, 0, sizeof(locator));
/* fill shim_locator data structure */
locator.lc_family = AF_INET6;
locator.lc_ifidx = 0;
locator.lc_flags = 0;
locator.lc_prio = 0;
locator.lc_weight = 0;
memcpy(&locator.lc_addr, &ia6, sizeof(ia6));
setsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_SEND, &locator, sizeof(locator));
setSockopt（FD、sol_shim、shim_loc_local_send、＆locator、sizeof（locator））;
For example, an application can get the designated local locator by using the socket option as follows:
たとえば、アプリケーションは、次のようにソケットオプションを使用して、指定されたローカルロケーターを取得できます。
struct shim_locator locator;
struct shim_locatorロケーター;
memset(&locator, 0, sizeof(locator));
getsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_SEND, &locator, sizeof(locator));
getSockopt（fd、sol_shim、shim_loc_local_send、＆locator、sizeof（locator））;
/* check locator */
The SHIM_LOC_PEER_SEND option is used to request that the shim sub-layer use a specific locator for the destination locator of IP packets to be sent from the socket. This option is effective only when there is a shim context associated with the socket.
SHIM_LOC_PEER_SENDオプションは、SHIMサブレイヤーがソケットから送信されるIPパケットの宛先ロケーターに特定のロケーターを使用することを要求するために使用されます。このオプションは、ソケットに関連付けられたシムコンテキストがある場合にのみ有効です。
The data type of the option value is a pointer to the shim_locator data structure.
オプション値のデータ型は、shim_locatorデータ構造へのポインターです。
An application can set the remote locator by setsockopt(), providing a locator that is stored in a shim_locator data structure. When a zero-filled locator is specified, the pre-existing setting of the remote locator is inactivated.
アプリケーションは、SetSockopt（）によってリモートロケーターを設定し、shim_locatorデータ構造に保存されているロケーターを提供できます。ゼロで充填されたロケーターが指定されている場合、リモートロケーターの既存の設定が不活性化されます。
An application can get the specified remote locator by getsockopt().
アプリケーションは、GetSockopt（）によって指定されたリモートロケーターを取得できます。
The difference between the SHIM_LOC_PEER_SEND option and the SHIM_LOC_PEER_PREF option is that the former guarantees the use of a requested locator when applicable, whereas the latter does not.
SHIM_LOC_PEER_SENDオプションとSHIM_LOC_PEER_PREFオプションの違いは、前者が該当する場合に要求されたロケーターの使用を保証することですが、後者はそうではありません。
When the application specifies the socket option to an unconnected socket, error code EOPNOTSUPP is returned to the application.
アプリケーションが接続されていないソケットにソケットオプションを指定すると、エラーコードEOPNOTSUPPがアプリケーションに返されます。
When there is no shim context associated with the socket, error code ENOENT is returned to the application.
ソケットに関連付けられたシムコンテキストがない場合、エラーコードenoentがアプリケーションに返されます。
Error code EINVALIDLOCATOR is returned when the validation of the requested locator fails.
エラーコードeinvalidLocatorは、要求されたロケーターの検証が失敗したときに返されます。
Error code EUNVERIFIEDLOCATOR is returned when reachability for the requested locator has not been verified yet.
エラーコードeunverifedlocatorは、要求されたロケーターの到達可能性がまだ検証されていない場合に返されます。
Error code EUNREACHABLELOCATOR is returned when the requested locator is determined to be unreachable according to a reachability check.
エラーコードeunReachableLocatorは、要求されたロケーターが到達可能性チェックに従って到達不可能であると判断されたときに返されます。
The usage of the option is the same as that of the SHIM_LOC_LOCAL_SEND option.
オプションの使用法は、shim_loc_local_sendオプションの使用と同じです。
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 socket. This option is effective only when there is a shim context associated with the socket.
shim_loclist_localオプションは、ソケットに関連付けられたシムコンテキストのローカルEidに関連付けられたロケーターリストを取得または設定するために使用されます。このオプションは、ソケットに関連付けられたシムコンテキストがある場合にのみ有効です。
The data type of the option value is a pointer to the buffer in which a locator list is stored. See Section 8 for the data structure for storing the locator information. By default, the option value is set to NULL, meaning that the option is disabled.
オプション値のデータ型は、ロケーターリストが保存されるバッファーへのポインターです。ロケーター情報を保存するためのデータ構造については、セクション8を参照してください。デフォルトでは、オプション値はnullに設定されています。つまり、オプションは無効になっています。
An application can get the locator list by getsockopt(). Note that the size of the buffer pointed to by the optval argument SHOULD be large enough to store an array of locator information. The number of the locator information is not known beforehand.
アプリケーションは、GetSockopt（）によってロケーターリストを取得できます。オプター引数によって指されたバッファーのサイズは、ロケーター情報の配列を保存するのに十分な大きさでなければならないことに注意してください。ロケーター情報の数は事前に知られていません。
The local locator list can be set by setsockopt(). The buffer pointed to by the optval argument MUST contain an array of locator structures.
ローカルロケーターリストは、setSockopt（）によって設定できます。オプトル引数によって指されたバッファーには、ロケーター構造の配列が含まれている必要があります。
When the application specifies the socket option to an unconnected socket, error code EOPNOTSUPP is returned to the application.
アプリケーションが接続されていないソケットにソケットオプションを指定すると、エラーコードEOPNOTSUPPがアプリケーションに返されます。
When there is no shim context associated with the socket, error code ENOENT is returned to the application.
ソケットに関連付けられたシムコンテキストがない場合、エラーコードenoentがアプリケーションに返されます。
Error code EINVALIDLOCATOR is returned when the validation of any of the specified locators failed.
エラーコードeinvalidLocatorは、指定されたロケーターの検証が失敗したときに返されます。
Error code ETOOMANYLOCATORS is returned when the number of 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.
エラーコードEtoomanylocatorsは、指定されたロケーターの数が制限（shim_max_locators）を超えた場合、またはアプリケーションによって提供されるバッファーのサイズがShimサブレイヤーによって提供されるロケーターリストを保存するのに十分な大きさでない場合に返されます。
For example, an application can set a list of locators to be associated with the local EID by using the socket option as follows. Note that an IPv4 locator can be handled by HIP and not by Shim6.
たとえば、アプリケーションは、ソケットオプションを次のように使用して、ローカルEIDに関連付けられるロケーターのリストを設定できます。IPv4ロケーターは、SHIM6ではなく股関節で処理できることに注意してください。
struct shim_locator locators[SHIM_MAX_LOCATORS];
struct sockaddr_in *sin;
struct sockaddr_in6 *sin6;
memset(locators, 0, sizeof(locators));
...
...
/* obtain local IP addresses from local interfaces */
...
...
/* first locator (an IPv6 address) */
locators[0].lc_family = AF_INET6;
locators[0].lc_ifidx = 0;
locators[0].lc_flags = 0;
locators[0].lc_prio = 1;
locators[0].lc_weight = 0;
memcpy(&locators[0].lc_addr, &sa6->sin6_addr,
sizeof(sa6->sin6_addr));
...
...
/* second locator (an IPv4 address) */
locators[1].lc_family = AF_INET;
locators[1].lc_ifidx = 0;
locators[1].lc_flags = 0;
locators[1].lc_prio = 0;
locators[1].lc_weight = 0;
memcpy(&locators[1].lc_addr, &sa->sin_addr,
sizeof(sa->sin_addr));
setsockopt(fd, SOL_SHIM, SHIM_LOCLIST_LOCAL, locators, sizeof(locators));
SetSockopt（FD、SOL_SHIM、SHIM_LOCLIST_LOCOL、LOCATORS、SIZEOF（Locators））;
For example, an application can get a list of locators that are associated with the local EID by using the socket option as follows:
たとえば、アプリケーションは、ソケットオプションを次のように使用して、ローカルEIDに関連付けられているロケーターのリストを取得できます。
struct shim_locator locators[SHIM_MAX_LOCATORS];
struct shim_locatorロケーター[shim_max_locators];
memset(locators, 0, sizeof(locators));
getsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_RECV, locators, sizeof(locators));
getSockopt（fd、sol_shim、shim_loc_local_recv、locators、sizeof（locators））;
/* parse locators */
...
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 socket. This option is effective only when there is a shim context associated with the socket.
SHIM_LOCLIST_PEERオプションは、ソケットに関連付けられたシムコンテキストのピアEIDに関連付けられたロケーターリストを取得または設定するために使用されます。このオプションは、ソケットに関連付けられたシムコンテキストがある場合にのみ有効です。
The data type of the option value is a pointer to the buffer where a locator list is stored. See Section 8 for the data structure for storing the locator information. By default, the option value is set to NULL, meaning that the option is disabled.
オプション値のデータ型は、ロケーターリストが保存されるバッファーへのポインターです。ロケーター情報を保存するためのデータ構造については、セクション8を参照してください。デフォルトでは、オプション値はnullに設定されています。つまり、オプションは無効になっています。
An application can get the locator list by getsockopt(). Note that the size of the buffer pointed to by the optval argument SHOULD be large enough to store an array of locator information. The number of the locator information is not known beforehand.
アプリケーションは、GetSockopt（）によってロケーターリストを取得できます。オプター引数によって指されたバッファーのサイズは、ロケーター情報の配列を保存するのに十分な大きさでなければならないことに注意してください。ロケーター情報の数は事前に知られていません。
An application can set the locator list by setsockopt(). The buffer pointed to by the optval argument MUST contain an array of locator list items.
アプリケーションは、setSockopt（）によってロケーターリストを設定できます。オプトル引数によって指されたバッファーには、ロケーターリスト項目の配列が含まれている必要があります。
When the application specifies the socket option to an unconnected socket, error code EOPNOTSUPP is returned to the application.
アプリケーションが接続されていないソケットにソケットオプションを指定すると、エラーコードEOPNOTSUPPがアプリケーションに返されます。
When there is no shim context associated with the socket, error code ENOENT is returned to the application.
ソケットに関連付けられたシムコンテキストがない場合、エラーコードenoentがアプリケーションに返されます。
Error code EINVALIDLOCATOR is returned when the validation of any of the specified locators failed.
エラーコードeinvalidLocatorは、指定されたロケーターの検証が失敗したときに返されます。
Error code EUNVERIFIEDLOCATOR is returned when reachability for the requested locator has not been verified yet.
エラーコードeunverifedlocatorは、要求されたロケーターの到達可能性がまだ検証されていない場合に返されます。
Error code EUNREACHABLELOCATOR is returned when the requested locator is determined to be unreachable according to a reachability check.
エラーコードeunReachableLocatorは、要求されたロケーターが到達可能性チェックに従って到達不可能であると判断されたときに返されます。
Error code ETOOMANYLOCATORS is returned when the number of 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.
エラーコードEtoomanylocatorsは、指定されたロケーターの数が制限（shim_max_locators）を超えた場合、またはアプリケーションによって提供されるバッファーのサイズがShimサブレイヤーによって提供されるロケーターリストを保存するのに十分な大きさでない場合に返されます。
The usage of the option is the same as that of SHIM_LOCLIST_LOCAL.
オプションの使用法は、shim_loclist_localの使用と同じです。
The SHIM_APP_TIMEOUT option is used to get or set the Send Timeout value of REAP [RFC5534]. This option is effective only when there is a shim context associated with the socket.
shim_app_timeoutオプションは、REAP [RFC5534]の送信タイムアウト値を取得または設定するために使用されます。このオプションは、ソケットに関連付けられたシムコンテキストがある場合にのみ有効です。
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 since the last outbound traffic. By default, the option value is set to 0, meaning that the option is disabled. When the option is disabled, the REAP mechanism follows its default Send Timeout value as specified in [RFC5534].
オプション値のデータ型は整数です。値は、最後のアウトバウンドトラフィック以来、刈り取りのキープライブメッセージを送信するための数秒でのタイムアウトの期間を示しています。デフォルトでは、オプション値は0に設定されています。つまり、オプションは無効になっています。オプションが無効になっている場合、REAPメカニズムは[RFC5534]で指定されているように、デフォルトの送信タイムアウト値に従います。
When the application specifies the socket option to an unconnected socket, error code EOPNOTSUPP is returned to the application.
アプリケーションが接続されていないソケットにソケットオプションを指定すると、エラーコードEOPNOTSUPPがアプリケーションに返されます。
When there is no shim context associated with the socket, error code ENOENT is returned to the application.
ソケットに関連付けられたシムコンテキストがない場合、エラーコードenoentがアプリケーションに返されます。
When there is no REAP instance on the system, error code EOPNOTSUPP is returned to the application.
システムにreapインスタンスがない場合、エラーコードeopnotsuppがアプリケーションに返されます。
For example, an application can set the timeout value by using the socket option as follows:
たとえば、ソケットオプションを次のように使用して、アプリケーションをタイムアウト値を設定できます。
int optval;
int optval;
optval = 15; /* 15 seconds */
setsockopt(fd, SOL_SHIM, SHIM_APP_TIMEOUT, &optval, sizeof(optval));
SetSockopt（FD、SOL_SHIM、SHIM_APP_TIMEOUT、＆OPTVAL、SIZEOF（OptVal））;
For example, an application can get the timeout value by using the socket option as follows:
たとえば、アプリケーションは、次のようにソケットオプションを使用してタイムアウト値を取得できます。
int optval; int len;
int optval;int len;
len = sizeof(optval);
getsockopt(fd, SOL_SHIM, SHIM_APP_TIMEOUT, &optval, &len);
getSockopt（fd、sol_shim、shim_app_timeout、＆optval、＆len）;
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.
アプリケーションは、このソケットオプションを使用して、パス探索に関するパラメーターを取得または設定する場合があります。Path Explorationは、現在のロケーターペアの代替ロケーターペアを見つける手順です。REAP仕様が定義するように、ピアはプローブメッセージを送信して、代替ロケーターペアを見つけることができます。
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 8.
オプション値のデータ型は、パス探索の情報セットが保存されるバッファーへのポインターです。データ構造は、セクション8で定義されています。
By default, the option value is set to NULL, meaning that the option is disabled.
デフォルトでは、オプション値はnullに設定されています。つまり、オプションは無効になっています。
When the application specifies the socket option to an unconnected socket, error code EOPNOTSUPP is returned to the application.
アプリケーションが接続されていないソケットにソケットオプションを指定すると、エラーコードEOPNOTSUPPがアプリケーションに返されます。
When there is no shim context associated with the socket, error code ENOENT is returned to the application.
ソケットに関連付けられたシムコンテキストがない場合、エラーコードenoentがアプリケーションに返されます。
For example, an application can set parameters for path exploration by using the socket option as follows:
たとえば、アプリケーションは、次のようにソケットオプションを使用して、パス探索のパラメーターを設定できます。
struct shim6_pathexplore pe;
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;
struct shim6_pathexplore pe;int len;
len = sizeof(pe);
getsockopt(fd, SOL_SHIM, SHIM_PATHEXPLORE, &pe, &len);
getSockopt（fd、sol_shim、shim_pathexplore、＆pe、＆len）;
The SHIM_DEFERRED_CONTEXT_SETUP option is used to check whether or not deferred context setup is possible. Deferred context setup means that the context is established in parallel with the data communication. Note that Shim6 supports deferred context setup and HIP does not, because EIDs in HIP (i.e., Host Identifiers) are non-routable.
shim_deferred_context_setupオプションは、繰延コンテキストのセットアップが可能かどうかを確認するために使用されます。延期されたコンテキストのセットアップとは、コンテキストがデータ通信と並行して確立されることを意味します。SHIM6は延期されたコンテキストのセットアップをサポートし、HIP（つまり、ホスト識別子）のEidsはルート不可能であるため、HIPはそうではありません。
Note that the socket option is read-only, and the option value can be read by getsockopt().
ソケットオプションは読み取り専用であり、Option値はgetSockopt（）によって読み取ることができることに注意してください。
The data type for the option value is an integer. The option value MUST be binary (0 or 1). The option value of 1 means that the shim sub-layer supports deferred context setup.
オプション値のデータ型は整数です。オプション値はバイナリ（0または1）でなければなりません。1のオプション値は、シムサブレイヤーが繰延コンテキストセットアップをサポートすることを意味します。
When the application specifies the socket option to an unconnected socket, error code EOPNOTSUPP is returned to the application.
アプリケーションが接続されていないソケットにソケットオプションを指定すると、エラーコードEOPNOTSUPPがアプリケーションに返されます。
For example, an application can check whether deferred context setup is possible or not as follows:
たとえば、アプリケーションは、延期されたコンテキストのセットアップが次のようかどうかを確認できます。
int optval; int len;
int optval;int len;
len = sizeof(optval);
getsockopt(fd, SOL_SHIM, SHIM_DEFERRED_CONTEXT_SETUP, &optval, &len);
getSockopt（fd、sol_shim、shim_deferred_context_setup、＆optval、＆len）;
All the socket options defined in this section except for the SHIM_DONTSHIM option are applicable to applications that use connected sockets.
shim_dontshimオプションを除くこのセクションで定義されているすべてのソケットオプションは、接続されたソケットを使用するアプリケーションに適用できます。
All the socket options defined in this section except for the SHIM_ASSOCIATED, SHIM_DONTSHIM, and SHIM_CONTEXT_DEFERRED_SETUP options are effective only when there is a shim context associated with the socket.
このセクションで定義されているすべてのソケットオプションは、shim_associated、shim_dontshim、およびshim_context_deferred_setupオプションを除き、ソケットに関連付けられたSHIMコンテキストがある場合にのみ有効です。
If successful, getsockopt() and setsockopt() return 0; otherwise, the functions return -1 and set errno to indicate an error.
成功した場合、getsockopt（）およびsetSockopt（）を返します。それ以外の場合、関数は-1を返し、errnoを設定してエラーを示します。
The following are new error values defined for some shim-specific socket options indicating that the getsockopt() or setsockopt() finished incompletely:
以下は、getsockopt（）またはsetsockopt（）が不完全に終了したことを示すいくつかのシム固有のソケットオプションで定義された新しいエラー値です。
EINVALIDLOCATOR This indicates that the locator is not part of the HBA set [RFC5535] within the shim context associated with the socket.
einvalidlocatorこれは、ロケーターがソケットに関連付けられたシムコンテキスト内のHBAセット[RFC5535]の一部ではないことを示しています。
EUNVERIFIEDLOCATOR This indicates that the reachability of the locator has not been confirmed. This error is applicable to only the peer's locator.
eunveriedLocatorこれは、ロケーターの到達可能性が確認されていないことを示しています。このエラーは、ピアのロケーターのみに適用できます。
EUNREACHABLELOCATOR This indicates that the locator is not reachable according to the result of the reachability check. This error is applicable to only the peer's locator.
EunReachableLocatorこれは、到達可能性チェックの結果に応じてロケーターが到達できないことを示しています。このエラーは、ピアのロケーターのみに適用できます。
This section provides definitions of ancillary data to be used for locator management and notification from/to the shim sub-layer to/ from the application.
このセクションでは、ロケーター管理に使用される補助データの定義と、アプリケーションからのShimサブレイヤーへの通知と通知をアプリケーションに提供します。
When the application performs locator management by sendmsg() or recvmsg(), a member of the msghdr structure (given in Figure 3) called msg_control holds a pointer to the buffer in which one or more shim-specific ancillary data objects may be stored. An ancillary data object can store a single locator. It should be possible to process the shim-specific ancillary data object by the existing macros defined in the POSIX standard and [RFC3542].
アプリケーションがsendmsg（）またはrecvmsg（）によってロケーター管理を実行すると、MSG_CONTROLと呼ばれるMSGHDR構造のメンバー（図3に示す）は、1つまたは複数のシム固有の補助データオブジェクトを保存できるバッファーへのポインターを保持します。補助的なデータオブジェクトは、単一のロケーターを保存できます。POSIX標準と[RFC3542]で定義されている既存のマクロによって、シム固有の補助データオブジェクトを処理することが可能です。
struct msghdr {
caddr_t msg_name; /* optional address */
u_int msg_namelen; /* size of address */
struct iovec *msg_iov; /* scatter/gather array */
u_int msg_iovlen; /* # elements in msg_iov */
caddr_t msg_control; /* ancillary data, see below */
u_int msg_controllen; /* ancillary data buffer len */
int msg_flags; /* flags on received message */
};
Figure 3: msghdr Structure
図3：MSGHDR構造
In the case of an unconnected socket, msg_name stores the socket address of the peer. Note that the address is not a locator of the peer but the identifier of the peer. SHIM_LOC_PEER_RECV can be used to get the locator of the peer node.
接続されていないソケットの場合、MSG_NAMEはピアのソケットアドレスを保存します。アドレスはピアのロケーターではなく、ピアの識別子であることに注意してください。SHIM_LOC_PEER_RECVを使用して、ピアノードのロケーターを取得できます。
Table 2 is a list of the shim-specific ancillary data that can be used for locator management by recvmsg() or sendmsg(). In any case, the value of cmsg_level MUST be set to SOL_SHIM.
表2は、recvmsg（）またはsendmsg（）でロケーター管理に使用できるシム固有の補助データのリストです。いずれにせよ、CMSG_LEVELの値はSOL_SHIMに設定する必要があります。
+---------------------+-----------+-----------+-----------------+
| cmsg_type | sendmsg() | recvmsg() | cmsg_data[] |
+---------------------+-----------+-----------+-----------------+
| SHIM_LOC_LOCAL_RECV | | o | Note 1 |
| SHIM_LOC_PEER_RECV | | o | Note 1 |
| SHIM_LOC_LOCAL_SEND | o | | Note 1 |
| SHIM_LOC_PEER_SEND | o | | Note 1 |
| SHIM_FEEDBACK | o | | shim_feedback{} |
+---------------------+-----------+-----------+-----------------+
Table 2: Shim-Specific Ancillary Data
表2：シム固有の補助データ
Note 1: cmsg_data[] within msg_control includes a single
sockaddr_in{} or sockaddr_in6{} and padding if necessary
An application can get locator information from the received IP 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 set, the application can retrieve a local and/or remote locator from the ancillary data.
アプリケーションは、ソケットのシム固有のソケットオプションを指定することにより、受信したIPパケットからロケーター情報を取得できます。shim_loc_local_recvおよび/またはshim_loc_peer_recvソケットオプションが設定されている場合、アプリケーションは補助データからローカルおよび/またはリモートロケーターを取得できます。
When there is no shim context associated with the socket, the shim sub-layer MUST return zero-filled locator information to the application.
ソケットに関連付けられたシムコンテキストがない場合、シムサブレイヤーはゼロで充填されたロケーター情報をアプリケーションに返す必要があります。
An application can specify the locators to be used for transmitting 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 application can explicitly specify the source and/or the destination locators to be used for the communication over the socket. If the specified locator pair is verified, the shim sub-layer overrides the locator(s) of the outgoing IP packet. Note that the effect is limited to the datagram transmitted by the sendmsg().
アプリケーションは、sendmsg（）によってIPパケットを送信するために使用されるロケーターを指定できます。CMSG_TYPE SHIM_LOC_LOCAL_SENDおよび/またはSHIM_LOC_PEER_SENDの補助データが指定されている場合、アプリケーションはソケットを介した通信に使用する宛先ロケーターを明示的に指定できます。指定されたロケーターペアが検証されている場合、Shimサブレイヤーは発信IPパケットのロケーターをオーバーライドします。効果は、sendmsg（）によって送信されたデータグラムに限定されていることに注意してください。
When there is no shim context associated with the socket, error code ENOENT is returned to the application.
ソケットに関連付けられたシムコンテキストがない場合、エラーコードenoentがアプリケーションに返されます。
Error code EINVALIDLOCATOR is returned when validation of the specified locator fails.
指定されたロケーターの検証が失敗すると、エラーコードeinvalidlocatorが返されます。
Error code EUNVERIFIEDLOCATOR is returned when reachability for the requested locator has not been verified yet. The application is recommended to use another destination locator until the reachability check for the requested locator is done.
エラーコードeunverifedlocatorは、要求されたロケーターの到達可能性がまだ検証されていない場合に返されます。アプリケーションは、要求されたロケーターの到達可能性チェックが完了するまで、別の宛先ロケーターを使用することをお勧めします。
Error code EUNREACHABLELOCATOR is returned when the requested locator is determined to be unreachable according to a reachability check. The application is recommended to use another destination locator when receiving the error.
エラーコードeunReachableLocatorは、要求されたロケーターが到達可能性チェックに従って到達不可能であると判断されたときに返されます。アプリケーションは、エラーを受信するときに別の宛先ロケーターを使用することをお勧めします。
An application MAY provide feedback to the shim sub-layer about the communication status. Such feedback is useful for the shim sub-layer to monitor the reachability status of the currently used locator pair in a given shim context.
アプリケーションは、通信ステータスに関するシムサブレイヤーにフィードバックを提供する場合があります。このようなフィードバックは、シムサブレイヤーが特定のシムコンテキストで現在使用されているロケーターペアの到達可能性ステータスを監視するのに役立ちます。
The notification can be made by sendmsg() specifying a new ancillary data called SHIM_FEEDBACK. The ancillary data can be handled by specifying the SHIM_FEEDBACK option in cmsg_type.
通知は、shim_feedbackと呼ばれる新しい補助データを指定するsendmsg（）によって行うことができます。補助データは、CMSG_TYPEでshim_feedbackオプションを指定することで処理できます。
When there is no shim context associated with the socket, error code ENOENT is returned to the application.
ソケットに関連付けられたシムコンテキストがない場合、エラーコードenoentがアプリケーションに返されます。
See Section 8.3 for details of the data structure to be used.
使用するデータ構造の詳細については、セクション8.3を参照してください。
It is outside the scope of this document to describe how the shim sub-layer would react when feedback is provided by an application.
このドキュメントの範囲外で、アプリケーションによってフィードバックが提供されたときにシムサブレイヤーがどのように反応するかを説明します。
All the ancillary data for the shim sub-layer is applicable to connected sockets.
シムサブレイヤーのすべての補助データは、接続されたソケットに適用できます。
Care is needed when the SHIM_LOC_*_RECV socket option is used for stream-oriented sockets (e.g., TCP sockets) because there is no one-to-one mapping between a single send or receive operation and the data (e.g., a TCP segment) being received. In other words, there is no guarantee that the locator(s) set in the SHIM_LOC_*_RECV ancillary data is identical to the locator(s) that appears in the IP packets received. The shim sub-layer SHOULD provide the latest locator information to the application in response to the SHIM_LOC_*_RECV socket option.
SHIM_LOC _*_ RECVソケットオプションがストリーム指向ソケット（TCPソケットなど）に使用される場合は注意が必要です。単一の送信または受信操作とデータ（TCPセグメントなど）の間に1対1のマッピングがないため受け取られている。言い換えれば、shim_loc _*_ recv補助データに設定されたロケーターが、受信したIPパケットに表示されるロケーターと同一であるという保証はありません。SHIMサブレイヤーは、shim_loc _*_ recvソケットオプションに応じて、最新のロケーター情報をアプリケーションに提供する必要があります。
This section gives data structures for the shim sub-layer. These data structures are either used as a parameter for setsockopt() or getsockopt() (as mentioned in Section 6), or as a parameter for ancillary data to be processed by sendmsg() or recvmsg() (as mentioned in Section 7).
このセクションでは、シムサブレイヤーのデータ構造を示します。これらのデータ構造は、setsockopt（）またはgetsockopt（）のパラメーターとして使用されます（セクション6に記載されている）、またはsendmsg（）またはrecvmsg（）によって処理される補助データのパラメーターとして使用されます（セクション7に記載されています）。
As defined in Section 6, the SHIM_LOC_*_PREF, SHIM_LOC_*_SEND, and SHIM_LOCLIST_* socket options need to handle one or more locator information points. Locator information includes not only the locator itself but also additional information about the locator that is useful for locator management. A new data structure is defined to serve as a placeholder for the locator information.
セクション6で定義されているように、shim_loc _*_ pref、shim_loc _*_送信、およびshim_loclist_*ソケットオプションは、1つ以上のロケーター情報ポイントを処理する必要があります。ロケーターの情報には、ロケーター自体だけでなく、ロケーター管理に役立つロケーターに関する追加情報も含まれます。新しいデータ構造は、ロケーター情報のプレースホルダーとして機能するように定義されています。
Figure 4 illustrates the data structure called shim_locator, which stores locator information.
図4は、ロケーター情報を保存するshim_locatorと呼ばれるデータ構造を示しています。
struct shim_locator {
uint8_t lc_family; /* address family */
uint8_t lc_proto; /* protocol */
uint16_t lc_port; /* port number */
uint16_t lc_prio; /* preference value */
uint16_t lc_weight; /* weight */
uint32_t lc_ifidx; /* interface index */
struct in6_addr lc_addr; /* address */
uint16_t lc_flags; /* flags */
};
Figure 4: Shim Locator Structure
図4：シムロケーター構造
lc_family Address family of the locator (e.g., AF_INET, AF_INET6). It is required that the parameter contains a non-zero value indicating the exact address family of the locator.
LC_FAMILYは、ロケーターのファミリを住所しています（例：AF_INET、AF_INET6）。パラメーターには、ロケーターの正確なアドレスファミリを示す非ゼロ値が含まれる必要があります。
lc_proto Internet Protocol number for the protocol that is used to handle a locator behind a NAT. The value MUST be set to zero when there is no NAT involved. When the locator is behind a NAT, the value MUST be set to IPPROTO_UDP.
NATの背後にあるロケーターを処理するために使用されるプロトコルのLC_Protoインターネットプロトコル番号。NATが関与していない場合、値はゼロに設定する必要があります。ロケーターがNATの背後にある場合、値はipproto_udpに設定する必要があります。
lc_port Port number that is used for handling a locator behind a NAT.
NATの背後にあるロケーターの処理に使用されるLC_PORTポート番号。
lc_prio Priority of the locator. The range is 0-65535. The lowest priority value means the highest priority.
LC_PRIOロケーターの優先度。範囲は0-65535です。最優先値は、最優先度を意味します。
lc_weight Weight value indicates a relative weight for locators with the same priority value. The range is 0-65535. A locator with higher weight value is prioritized over the other locators with lower weight values.
LC_WEIGHTの重量値は、同じ優先度の値を持つロケーターの相対的な重量を示します。範囲は0-65535です。重量値が高いロケーターは、重量値が低い他のロケーターよりも優先されます。
lc_ifidx Interface index of the network interface to which the locator is assigned. This field is applicable only to local locators, and has no effect in set operations.
ロケーターが割り当てられるネットワークインターフェイスのLC_IFIDXインターフェイスインデックス。このフィールドは、ローカルロケーターにのみ適用でき、SET操作には影響しません。
lc_addr Contains the locator. In the case of IPv4, the locator MUST be formatted in the IPv4-mapped IPv6 address as defined in [RFC4291]. The locator MUST be stored in network byte order.
LC_ADDRにはロケーターが含まれています。IPv4の場合、[RFC4291]で定義されているように、LocatorをIPv4-Mapped IPv6アドレスでフォーマットする必要があります。ロケーターは、ネットワークバイトの順序で保存する必要があります。
lc_flags Each bit of the flags represents a specific characteristic of the locator. The Hash-Based Address (HBA) is defined as 0x01. The Cryptographically Generated Address (CGA) is defined as 0x02. This field has no effect in set operations.
LC_FLAGSフラグの各ビットは、ロケーターの特定の特性を表します。ハッシュベースのアドレス（HBA）は0x01として定義されます。暗号化されたアドレス（CGA）は0x02として定義されます。このフィールドは、設定された操作に影響を与えません。
Note that the locator information MAY contain a locator behind a Network Address Translator (NAT). Such a situation may arise when 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 mechanism for HIP is defined, which allows a HIP host to tunnel control and data traffic over UDP [RFC5770]. Note also that the locator behind a NAT is not necessarily an IPv4 address and can be an IPv6 address. Below is an example where the application sets a UDP encapsulation interface as a source locator when sending IP packets.
ロケーター情報には、ネットワークアドレス翻訳者（NAT）の背後にあるロケーターが含まれている場合があることに注意してください。このような状況は、ホストがNATの後ろにいて、ローカルアドレスをソースロケーターとして使用してピアと通信すると発生する可能性があります。股関節のNATトラバーサルメカニズムが定義されていることに注意してください。これにより、股関節ホストがUDPを介したトンネル制御とデータトラフィックを可能にします[RFC5770]。また、NATの背後にあるロケーターは必ずしもIPv4アドレスではなく、IPv6アドレスになる可能性があることに注意してください。以下は、アプリケーションがIPパケットを送信するときにソースロケーターとしてUDPカプセル化インターフェイスを設定する例です。
struct shim_locator locator; struct in6_addr ia6;
struct shim_locatorロケーター;struct in6_addr ia6;
/* copy the private IPv4 address to the ia6 as an IPv4-mapped
IPv6 address */
memset(&locator, 0, sizeof(locator));
/* fill shim_locator data structure */
locator.lc_family = AF_INET;
locator.lc_proto = IPPROTO_UDP;
locator.lc_port = 50500;
locator.lc_ifidx = 0;
locator.lc_flags = 0;
locator.lc_prio = 0;
locator.lc_weight = 0;
memcpy(&locator.lc_addr, &ia6, sizeof(ia6));
setsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_SEND, &locator, sizeof(locator));
setSockopt（FD、sol_shim、shim_loc_local_send、＆locator、sizeof（locator））;
Figure 5: Handling Locator behind NAT
図5：NATの背後にあるハンドリングロケーター
As defined in Section 6, SHIM_PATHEXPLORE allows an application to set or read the parameters for path exploration and failure detection. A new data structure called shim_pathexplore is defined to store the necessary parameters. Figure 6 illustrates the data structure. The data structure can be passed to getsockopt() or setsockopt() as an argument.
セクション6で定義されているように、shim_pathexploreでは、アプリケーションがパス探索と障害検出のパラメーターを設定または読み取ることができます。shim_pathexploreと呼ばれる新しいデータ構造は、必要なパラメーターを保存するために定義されています。図6は、データ構造を示しています。データ構造は、引数としてgetSockopt（）またはsetSockopt（）に渡すことができます。
struct shim_pathexplore {
uint16_t pe_probenum; /* # of initial probes */
uint16_t pe_keepaliveto; /* Keepalive Timeout */
uint16_t pe_keepaliveint; /* Keepalive Interval */
uint16_t pe_initprobeto; /* Initial Probe Timeout */
uint32_t pe_reserved; /* reserved */
};
Figure 6: Path Explore Structure
図6：パス探索構造
pe_probenum Indicates the number of initial Probe messages to be sent. The value MUST be set as per [RFC5534].
PE_PROBENUMは、送信される初期プローブメッセージの数を示します。値は[RFC5534]に従って設定する必要があります。
pe_keepaliveto Indicates the timeout value in seconds for detecting a failure when the host does not receive any packets for a certain period of time while there is outbound traffic. When the timer expires, the path exploration procedure will be carried out by sending a REAP Probe message. The value MUST be set as per [RFC5534].
PE_KEEPALIVETOは、アウトバウンドトラフィックがある間、ホストが一定期間パケットを受け取らない場合に障害を検出するための数秒でタイムアウト値を示します。タイマーの有効期限が切れると、PATHプローブメッセージを送信することにより、パス探索手順が実行されます。値は[RFC5534]に従って設定する必要があります。
pe_keepaliveint Indicates the interval of REAP Keepalive messages in seconds to be sent by the host when there is no outbound traffic to the peer host. The value MUST be set as per [RFC5534].
PE_KEEPALIVEINTは、ピアホストへのアウトバウンドトラフィックがない場合、ホストによって送信される数秒でREAP Keepaliveメッセージの間隔を示します。値は[RFC5534]に従って設定する必要があります。
pe_initprobeto Indicates the retransmission timer of the REAP Probe message in milliseconds. Note that this timer is applied before exponential back-off is started. A REAP Probe message for the same locator pair may be retransmitted. The value MUST be set as per [RFC5534].
PE_INITPROBETOは、MillisecondsでReap Probeメッセージの再送信タイマーを示します。このタイマーは、指数関数的なバックオフが開始される前に適用されることに注意してください。同じロケーターペアのREAPプローブメッセージが再送信される場合があります。値は[RFC5534]に従って設定する必要があります。
pe_reserved A reserved field for future extension. By default, the field MUST be initialized to zero.
PE_Reserved将来の拡張のための予約済みフィールド。デフォルトでは、フィールドはゼロに初期化する必要があります。
As mentioned in Section 7.3, applications can inform the shim sub-layer about the status of unicast reachability of the locator pair currently in use. The feedback information can be handled by using ancillary data called SHIM_FEEDBACK. A new data structure named shim_feedback is illustrated in Figure 7.
セクション7.3で述べたように、アプリケーションは、現在使用されているロケーターペアのユニキャストの到達可能性のステータスについてShimサブレイヤーに通知できます。フィードバック情報は、shim_feedbackと呼ばれる補助データを使用して処理できます。shim_feedbackという名前の新しいデータ構造を図7に示します。
struct shim_feedback {
uint8_t fb_direction; /* direction of traffic */
uint8_t fb_indicator; /* indicator (1-3) */
uint16_t fb_reserved; /* reserved */
};
Figure 7: Feedback Information Structure
図7：フィードバック情報構造
fb_direction Indicates the direction of reachability between the locator pair in question. A value of 0 indicates outbound direction, and a value of 1 indicates inbound direction.
FB_Directionは、問題のロケーターペア間の到達可能性の方向を示します。値0はアウトバウンド方向を示し、値1はインバウンド方向を示します。
fb_indicator A value indicating the degree of satisfaction of a unidirectional reachability for a given locator pair.
FB_indicator特定のロケーターペアの単方向の到達可能性の満足度を示す値。
* 0: Default value. Whenever this value is specified, the feedback information MUST NOT be processed by the shim sub-layer.
* 0：デフォルト値。この値が指定されたときはいつでも、フィードバック情報をShimサブレイヤーによって処理してはなりません。
* 1: Unable to connect. There is no unidirectional reachability between the locator pair in question.
* 1：接続できません。問題のロケーターペア間に一方向の到達可能性はありません。
* 2: Unsatisfactory. The application is not satisfied with the unidirectional reachability between the locator pair in question.
* 2：不十分です。アプリケーションは、問題のロケーターペア間の単方向の到達可能性に満足していません。
* 3: Satisfactory. There is satisfactory unidirectional reachability between the locator pair in question.
* 3：満足のいく。問題のロケーターペアの間には、満足のいく一方向の到達可能性があります。
fb_reserved Reserved field. MUST be ignored by the receiver.
FB_Reserved予約済みフィールド。受信機は無視する必要があります。
As addressed in Section 6, most of the socket options and ancillary data defined in this document are applicable to connected sockets. It is assumed that the kernel is capable of maintaining the association between a connected socket and a shim context. This requirement is considered to be reasonable because a pair of source and destination IP addresses is bound to a connected socket.
セクション6で説明したように、このドキュメントで定義されているソケットオプションと補助データのほとんどは、接続されたソケットに適用されます。カーネルは、接続されたソケットとシムコンテキストの間の関連性を維持できると想定されています。ソースと宛先のIPアドレスのペアが接続されたソケットにバインドされるため、この要件は妥当であると見なされます。
This section explains the relation between the sockets API defined in this document and the existing sockets API extensions.
このセクションでは、このドキュメントで定義されているソケットAPIと既存のソケットAPI拡張機能の関係について説明します。
As mentioned in Section 6, the basic assumption is that the existing sockets API continues to work above the shim sub-layer. This means that the existing sockets API deals with identifiers, and the sockets API defined in this document deals with locators.
セクション6で述べたように、基本的な仮定は、既存のソケットAPIがシムサブレイヤーの上に動作し続けることです。これは、既存のソケットAPIが識別子を扱い、このドキュメントで定義されているソケットAPIがロケーターを扱うことを意味します。
SHIM_LOC_LOCAL_SEND and SHIM_LOC_PEER_SEND socket options are semantically similar to the IPV6_PKTINFO sockets API in the sense that both provide a means for an application to set the source IP address of outbound IP packets.
shim_loc_local_sendおよびshim_loc_peer_sendソケットオプションは、Autbound IPパケットのソースIPアドレスを設定するためのアプリケーションの手段を提供するという意味で、Semantivally Ipv6_pktinfo sockets apiに類似しています。
SHIM_LOC_LOCAL_RECV and SHIM_LOC_PEER_RECV socket options are semantically similar to the IP_RECVDSTADDR and IPV6_PKTINFO sockets APIs in the sense that both provide a means for an application to get the source and/or destination IP address of inbound IP packets.
shim_loc_local_recv and shim_loc_peer_recvソケットオプションは、IP_RECVDSTADDRおよびIPv6_pktinfoソケットAPIとセマンティックに類似しています。
getsockname() and getpeername() enable an application to get the "name" of the communication endpoints, which is represented by a pair of IP addresses and port numbers assigned to the socket. getsockname() gives the IP address and port number assigned to the socket on the local side, and getpeername() gives the IP address and port number of the peer side.
getSockName（）およびgetPeerName（）を有効にして、アプリケーションが通信エンドポイントの「名前」を取得できます。これは、ソケットに割り当てられたIPアドレスとポート番号のペアで表されます。getSockName（）は、ローカル側のソケットに割り当てられたIPアドレスとポート番号を指定し、getPeerName（）にピア側のIPアドレスとポート番号が表示されます。
This section gives operational considerations of the sockets API defined in this document.
このセクションでは、このドキュメントで定義されているソケットAPIの運用上の考慮事項を示します。
There can be a conflicting situation when different applications specify different preferences for the same shim context. For instance, suppose that applications A and B establish communication with the same EID pair while both applications have different preferences in their choice of local locator. The notion of context forking in Shim6 can resolve the conflicting situation.
異なるアプリケーションが同じシムコンテキストに対して異なる設定を指定する場合、矛盾する状況があります。たとえば、アプリケーションAとBが同じEIDペアとの通信を確立し、両方のアプリケーションがローカルロケーターの選択に異なる好みを持っていると仮定します。SHIM6のコンテキストフォーキングの概念は、矛盾する状況を解決できます。
It is possible that socket options defined in Section 6 cause a conflicting situation when the target context is shared by multiple applications. In such a case, the socket handler should inform the shim sub-layer that context forking is required. In Shim6, when a context is forked, a unique identifier called the Forked Instance Identifier (FII) is assigned to the newly forked context. The forked context is then exclusively associated with the socket through which a non-default preference value was specified. The forked context is maintained by the shim sub-layer during the lifetime of the associated socket instance. When the socket is closed, the shim sub-layer SHOULD delete the associated context.
セクション6で定義されたソケットオプションは、ターゲットコンテキストが複数のアプリケーションで共有されると、競合する状況を引き起こす可能性があります。そのような場合、ソケットハンドラーは、コンテキストフォーキングが必要であることをシムサブレイヤーに通知する必要があります。SHIM6では、コンテキストがフォークされると、Forked Instance Identifier（FII）と呼ばれる一意の識別子が、新しくフォークされたコンテキストに割り当てられます。フォークされたコンテキストは、非デフォルト選好値が指定されたソケットにのみ関連付けられます。フォークされたコンテキストは、関連するソケットインスタンスの寿命の間にシムサブレイヤーによって維持されます。ソケットが閉じた場合、シムサブレイヤーは関連するコンテキストを削除する必要があります。
When the application specifies SHIM_LOC_*_SEND specifying a different source or destination locator that 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.
*_pref。
When the peer provides preferences of the locators (e.g., a Shim6 peer sends a locator with a Locator Preferences Option) that conflict with preferences specified by the applications either by SHIM_LOC_PEER_SEND or SHIM_LOC_PEER_PREF, the shim sub-layer SHOULD supersede the preferences made by the applications over the preferences specified by the peer.
ピアがロケーターの設定を提供する場合（たとえば、shim6ピアは、ロケーター設定オプションを持つロケーターを送信しますオプション）、shim_loc_peer_sendまたはshim_loc_peer_prefのいずれかでアプリケーションによって指定された設定と競合する場合、shimサブレイヤーはアプリケーションによって行われた優先順位に課せられるはずですピアによって指定された設定について。
The shim sub-layer performs identifier/locator adaptation. Therefore, in some cases, the whole IP header can be replaced with a new IP header of a different address family (e.g., conversion from IPv4 to IPv6 or vice versa). Hence, there is an issue regarding how to make the conversion with minimum impact. Note that this issue is common in other protocol conversion techniques [RFC2765] [RFC6145].
Shimサブレイヤーは、識別子/ロケーターの適応を実行します。したがって、場合によっては、IPヘッダー全体を異なるアドレスファミリの新しいIPヘッダーに置き換えることができます（たとえば、IPv4からIPv6、またはその逆への変換）。したがって、インパクトを最小限に抑えて変換を行う方法に関する問題があります。この問題は、他のプロトコル変換技術[RFC2765] [RFC6145]で一般的であることに注意してください。
As studied in the previous works on protocol conversion [RFC2765], [RFC6145] some of the features (IPv6 routing headers, hop-by-hop extension headers, and destination headers) from IPv6 are not convertible to IPv4. In addition, the notion of source routing is not exactly the same in IPv4 and IPv6. This means that an error may occur during the conversion of the identifier and locator. It is outside the scope of this document to describe how the shim sub-layer should behave in such erroneous cases.
Protocol Conversion [RFC2765]、[RFC6145]の以前の研究で研究したように、IPv6からの機能（IPv6ルーティングヘッダー、ホップバイホップエクステンションヘッダー、および宛先ヘッダー）の一部はIPv4に変換できません。さらに、ソースルーティングの概念は、IPv4とIPv6でまったく同じではありません。これは、識別子とロケーターの変換中にエラーが発生する可能性があることを意味します。このドキュメントの範囲外で、このような誤ったケースでシムサブレイヤーがどのように動作するかを説明します。
There are no IANA considerations for the socket options (SHIM_*), the ancillary data, and the socket level (SOL_SHIM) that are defined in this document. All the numbers concerned are not under the control of the IETF or IANA, but they are platform-specific.
このドキュメントで定義されているソケットオプション（shim_*）、補助データ、ソケットレベル（sol_shim）に関するIANAの考慮事項はありません。関係するすべての数字はIETFまたはIANAの制御下にありませんが、プラットフォーム固有です。
This section defines a protocol constant.
このセクションでは、プロトコル定数を定義します。
SHIM_MAX_LOCATORS The maximum number of locators to be included in a locator list. The value is set to 32.
shim_max_locatorsロケーターリストに含まれるロケーターの最大数。値は32に設定されています。
This section gives security considerations of the API defined in this document.
このセクションでは、このドキュメントで定義されているAPIのセキュリティ上の考慮事項を示します。
When sending IP packets, there is a possibility that an application will request the use of an unknown locator for the source and/or destination locators. Note that the treatment of an unknown locator can be a subject of security considerations, because the use of an invalid source and/or destination locator may cause a redirection attack.
IPパケットを送信するとき、アプリケーションがソースおよび/または宛先ロケーターに不明なロケーターの使用を要求する可能性があります。未知のロケーターの処理は、無効なソースや宛先ロケーターの使用がリダイレクト攻撃を引き起こす可能性があるため、セキュリティ上の考慮事項の対象となる可能性があることに注意してください。
The shim sub-layer checks to determine if the requested locator is available on any local interface. If not, the shim sub-layer MUST reject the request and return an error message with the EINVALIDLOCATOR code to the application. If the locator is confirmed to be available, the shim sub-layer SHOULD initiate the procedure to update the locator list.
シムサブレイヤーは、要求されたロケーターがローカルインターフェイスで利用可能かどうかを判断するためにチェックします。そうでない場合、Shimサブレイヤーはリクエストを拒否し、einvalidlocatorコードを使用してエラーメッセージをアプリケーションに返す必要があります。ロケーターが利用可能であることが確認されている場合、シムサブレイヤーはロケーターリストを更新する手順を開始する必要があります。
Use of the following socket options and ancillary data requires treatment of an 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_LOCLIST_LOCAL
o shim_loclist_local
If the shim sub-layer turns out to be Shim6, the Shim6 layer MUST reject the request for using an unknown destination locator.
SHIMサブレイヤーがSHIM6であることが判明した場合、SHIM6層は未知の宛先ロケーターの使用の要求を拒否する必要があります。
If the shim sub-layer turns out to be HIP, the HIP layer MUST reject the request for using an unknown destination locator. There is, however, an exceptional case where the HIP layer SHOULD accept the request, provided that the HIP association is in the UNASSOCIATED state. Details of locator handling in HIP are described in Section 4.6 of [RFC6317].
シムサブレイヤーが股関節であることが判明した場合、股関節層は未知の宛先ロケーターの使用の要求を拒否する必要があります。ただし、股関節関連が関連性のない状態にある場合、股関節層がリクエストを受け入れるべき例外的なケースがあります。股関節でのロケーターの取り扱いの詳細については、[RFC6317]のセクション4.6で説明しています。
Use of the following socket options and ancillary data requires treatment of an 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_LOCLIST_PEER
o shim_loclist_peer
The authors would like to thank Jari Arkko, who participated in the discussion that led to the first version of this document, and Tatuya Jinmei, who thoroughly reviewed the early draft version of this document and provided detailed comments on sockets API-related issues. Thomas Henderson provided valuable comments, especially from the HIP perspective.
著者は、このドキュメントの最初のバージョンにつながった議論に参加したJari Arkkoと、このドキュメントの初期ドラフトバージョンを徹底的にレビューし、Sockets API関連の問題に関する詳細なコメントを提供したTatuya Jinmeiに感謝します。トーマス・ヘンダーソンは、特にヒップの観点から、貴重なコメントを提供しました。
The authors sincerely thank the following people for their helpful comments regarding the document: Samu Varjonen, Dmitriy Kuptsov, Brian Carpenter, Michael Scharf, Sebastien Barre, and Roni Even.
著者は、この文書に関する有益なコメントについて、次の人々に心から感謝します。
[POSIX] "IEEE Std. 1003.1-2008 Standard for Information Technology -- Portable Operating System Interface (POSIX). Open group Technical Standard: Base Specifications, Issue 7", September 2008, <http://www.opengroup.org/austin>.
[POSIX] "IEEEStd。1003.1-2008情報技術の標準 - ポータブルオペレーティングシステムインターフェイス（POSIX）。オープングループ技術標準：基本仕様、第7"、2008年9月、<http://www.opengroup.org/オースティン>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, "Advanced Sockets Application Program Interface (API) for IPv6", RFC 3542, May 2003.
[RFC3542] Stevens、W.、Thomas、M.、Nordmark、E。、およびT. Jinmei、「IPv6用Advanced Socketsアプリケーションプログラムインターフェイス（API）」、RFC 3542、2003年5月。
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006.
[RFC4423] Moskowitz、R。およびP. Nikander、「ホストアイデンティティプロトコル（HIP）アーキテクチャ」、RFC 4423、2006年5月。
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, June 2009.
[RFC5533] Nordmark、E。およびM. Bagnulo、「SHIM6：IPv6のレベル3マルチホミングシムプロトコル」、RFC 5533、2009年6月。
[RFC5534] Arkko, J. and I. van Beijnum, "Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming", RFC 5534, June 2009.
[RFC5534] Arkko、J。およびI. Van Beijnum、「IPv6 Multihomingの障害検出およびロケーターペア探査プロトコル」、RFC 5534、2009年6月。
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000.
[RFC2765] Nordmark、E。、「Stateless IP/ICMP翻訳アルゴリズム（SIIT）」、RFC 2765、2000年2月。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782] Gulbrandsen、A.、Vixie、P。、およびL. Esibov、「サービスの場所を指定するためのDNS RR（DNS SRV）」、RFC 2782、2000年2月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレス指定アーキテクチャ」、RFC 4291、2006年2月。
[RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, June 2009.
[RFC5535] Bagnulo、M。、「ハッシュベースのアドレス（HBA）」、RFC 5535、2009年6月。
[RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. Keranen, Ed., "Basic Host Identity Protocol (HIP) Extensions for Traversal of Network Address Translators", RFC 5770, April 2010.
[RFC5770] Komu、M.、Henderson、T.、Tschofenig、H.、Melen、J。、およびA. Keranen、ed。、 "Networkアドレス翻訳者のトラバーサルの基本ホストIDプロトコル（HIP）拡張"、RFC 5770、2010年4月。
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011.
[RFC6145] Li、X.、Bao、C。、およびF. Baker、「IP/ICMP翻訳アルゴリズム」、RFC 6145、2011年4月。
[RFC6317] Komu, M. and T. Henderson, "Basic Socket Interface Extensions for the Host Identity Protocol (HIP)", RFC 6317, July 2011.
[RFC6317] Komu、M。およびT. Henderson、「ホストIDプロトコルの基本ソケットインターフェイス拡張（HIP）」、RFC 6317、2011年7月。
[SHIM6-APP-REFER] Nordmark, E., "Shim6 Application Referral Issues", Work in Progress, July 2005.
[SHIM6-APP-REFER] Nordmark、E。、「SHIM6アプリケーション紹介の問題」、2005年7月、進行中の作業。
In this section, an issue concerning context forking and its relation to the multihoming shim API are discussed.
このセクションでは、コンテキストフォーキングとマルチホームシムAPIとの関係に関する問題について説明します。
Shim6 supports the notion of context forking. A peer may decide to fork a context for a certain reason (e.g., an upper-layer protocol prefers to use a different locator pair than the one defined in an available context). The procedure of context forking is done similarly to the normal context establishment, performing the 4-way message exchange. A peer who has decided to fork a context initiates the context establishment. Hereafter, we call this peer the "initiator". The peer of the initiator is called the "responder".
SHIM6は、コンテキストフォークの概念をサポートしています。ピアは、特定の理由でコンテキストを分岐することを決定する場合があります（たとえば、上層層プロトコルは、利用可能なコンテキストで定義されているものとは異なるロケーターペアを使用することを好みます）。コンテキストフォーキングの手順は、通常のコンテキスト確立と同様に行われ、4ウェイメッセージ交換を実行します。コンテキストをフォークすることを決めたピアは、コンテキストの確立を開始します。以下、このピアを「イニシエーター」と呼びます。イニシエーターのピアは「レスポンダー」と呼ばれます。
Once the forked context is established between the peers, on the initiator side, it is possible to apply forked context to the packet flow, since the system maintains an association between the forked context and the socket owned by the application that has requested the context forking. How this association is maintained is an implementation-specific issue. However, on the responder side, there is a question of how the outbound packet can be multiplexed by the shim sub-layer, because there is more than one Shim6 context that matches with the ULID pair of the packet flow. There is a need to differentiate packet flows not only by the ULID pairs but by some other information and associate a given packet flow with a specific context.
ピアの間にフォークコンテキストが確立されると、イニシエーター側では、フォークコンテキストにフォークコンテキストを適用することができます。これは、システムがフォークコンテキストとコンテキストフォーキングを要求したアプリケーションが所有するソケットとの関連を維持するためです。。この協会の維持方法は、実装固有の問題です。ただし、レスポンダー側では、パケットフローのulidペアと一致する複数のShim6コンテキストがあるため、Shimサブレイヤーによってアウトバウンドパケットがどのように多重化されるかについての疑問があります。ulidペアだけでなく、他の情報によってパケットフローを区別し、特定のパケットフローを特定のコンテキストと関連付ける必要があります。
Figure 8 gives an example of a scenario where two communicating peers fork a context. Initially, there has been a single transaction between the peers, by the application 1 (App1). Accordingly, another transaction is started, by application 2 (App2). Both of the transactions are made based on the same ULID pair. The first context pair (Ctx1) is established for the transaction of App1. Given the requests from App2, the shim sub-layer on Peer 1 decides to fork a context. Accordingly, a forked context (Ctx2) is established between the peers, which should be exclusively applied to the transaction of App2. Ideally, multiplexing and demultiplexing of packet flows that relate to App1 and App2 should be done as illustrated in Figure 8. However, as mentioned earlier, the responder needs to multiplex outbound flows of App1 and App2 somehow. Note that if a context forking occurs on the initiator side, a context forking needs to also occur on the responder side.
図8は、2つの通信ピアがコンテキストをフォークするシナリオの例を示しています。当初、アプリケーション1（APP1）により、ピア間で単一のトランザクションがありました。したがって、アプリケーション2（APP2）によって別のトランザクションが開始されます。両方のトランザクションは、同じ亜鉛ペアに基づいて行われます。最初のコンテキストペア（CTX1）は、APP1のトランザクションのために確立されます。App2からのリクエストを考えると、Peer 1のShimサブレイヤーはコンテキストをフォークすることを決定します。したがって、ピアの間にフォークされたコンテキスト（CTX2）が確立され、APP2のトランザクションにのみ適用する必要があります。理想的には、App1とApp2に関連するパケットフローの多重化と非複数のプレックスは、図8に示すように実行する必要があります。ただし、前述のように、ResponderはApp1とApp2のマルチプレックスアウトバウンドフローをどういうわけか必要です。イニシエーター側でコンテキストフォーキングが発生した場合、コンテキストフォーキングもレスポンダー側でも発生する必要があることに注意してください。
Peer 1 Peer 2 (initiator) (responder)
ピア1ピア2（イニシエーター）（レスポンダー）
+----+ +----+ +----+ +----+
|App1| |App2| |App1| |App2|
+----+ +----+ +----+ +----+
|^ |^ ^| ^|
v| v| |v |v
-----S1-------------S2----- -----S1-------------S2-----
|| || || ||
|| || || ||
Ctx1 Ctx2 Ctx1 Ctx2
ULID:<A1,B1> ULID:<A1,B1> ULID:<B1,A1> ULID:<B1,A1>
Loc: <A1,B2> Loc: <A1,B3> Loc: <B2,A1> Loc: <B3,A1>
FII: 0 FII: 100 FII: 0 FII: 100
|^ |^ ^| ^|
|| || || ||
|| || || ||
\..............||....................../| ||
\.............||......................./ ||
|| ||
\|...................................../|
\....................................../
Figure 8: Context Forking
図8：コンテキストフォーキング
How to solve the issue described above is a topic for further study.
上記の問題を解決する方法は、さらなる研究のためのトピックです。
Authors' Addresses
著者のアドレス
Miika Komu Aalto University Espoo Finland
ミイカ・コム・アールト大学エスポー・フィンランド
Phone: +358505734395
Fax: +358947025014
EMail: miika@iki.fi
URI: http://cse.aalto.fi/research/groups/datacommunications/people/
Marcelo Bagnulo Universidad Carlos III de Madrid Av. Universidad 30 Leganes 28911 SPAIN
Marcelo Bagnulo Universidad Carlos III de Madrid av。大学30レガネス28911スペイン
Phone: +34 91 6248837
EMail: marcelo@it.uc3m.es
URI: http://it.uc3m.es/marcelo
Kristian Slavov Ericsson Research Nomadiclab Hirsalantie 11 Jorvas FI-02420 Finland
クリスチャン・スラボフ・エリクソン研究nomadiclab hirsalantie 11 jorvas fi-02420フィンランド
Phone: +358 9 299 3286
EMail: kristian.slavov@ericsson.com
Shinta Sugimoto (editor) Nippon Ericsson K.K. Koraku Mori Building 1-4-14, Koraku, Bunkyo-ku Tokyo 112-0004 Japan
Shinta Sugimoto（編集者）Nippon Ericsson K.K.コラク森建築物1-4-14、コラク、bunkyo-ku東京112-0004日本
Phone: +81 3 3830 2241
EMail: shinta.sugimoto@ericsson.com